Subject: Re: [marf] draft-jdfalk-marf-reporting-discovery

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Jun 2010 12:42:22 -0700

We have in our charter the work of considering mechanisms for doing feedback reporting discovery, so this is most certainly on-topic.  That doesn't mean we need to specify something; a possible output of the working group is to decide that this is not something that should be specified.

Given that it's on-topic, is there rough consensus that JD's draft is a good starting point for discussion?  In that case, I believe the next step is we should make it a working group document and then begin discussing it.

We've also got the DKIM reporting extensions document as an active working group item, and a meeting coming up at the end of next month, so we should try re-engage discussion on these topics.

-MSK [as co-chair]

I'll make an effort to post a review of my own of the reporting discovery one shortly.

-MSK [as participant]

---

From: John Levine <[email-masked]>
Date: 22 Jun 2010 04:06:25 -0000

>Given that it's on-topic, is there rough consensus that JD's draft is
>a good starting point for discussion?

It's fine as far as it goes, but it sure would be nice to have some
expressions of interest by large senders or receivers to give us a
hint about what sorts of discovery they want to do so we know we're
not wasting our time.

R's,
John

---

From: SM <[email-masked]>
Date: Mon, 21 Jun 2010 22:47:48 -0700

Hi Murray,
At 12:42 21-06-10, Murray S. Kucherawy wrote:
>We have in our charter the work of considering mechanisms for doing 
>feedback reporting discovery, so this is most certainly 
>on-topic.  That doesn't mean we need to specify something; a 
>possible output of the working group is to decide that this is not 
>something that should be specified.

I'm fine with this WG taking on 
draft-jdfalk-marf-reporting-discovery-01 as long as the intended 
status is Experimental.  That's different from what item 4 of the WG 
Charter says but it has the advantage of lowering the bar for publication.

Regards,
-sm

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 22 Jun 2010 10:54:23 -0600

> hint about what sorts of discovery they want to do so we know we're

Well, I can tell you that the largest Feedback Generator is very interested.  But, nobody appears particularly desperate for it.

I realized a few weeks ago that I'd neglected to fully describe the most immediately interesting use case: verification of consumers.  Specifically, when a Feedback Consumer requests feedback via the current mechanisms (which are almost invariably web forms leading to a manual approval process), the Feedback Generator can use the relevant advertisement to ensure that the feedback would be going to the correct place.

On Jun 21, 2010, at 11:47 PM, SM wrote:

> I'm fine with this WG taking on draft-jdfalk-marf-reporting-discovery-01 as long as the intended status is Experimental.  That's different from what item 4 of the WG Charter says but it has the advantage of lowering the bar for publication.

What's the process for moving from Experimental to Proposed Standard once the experiment is complete?

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: SM <[email-masked]>
Date: Tue, 22 Jun 2010 11:55:55 -0700

Hi JD,
>once the experiment is complete?

According to the MARF Charter, this I-D is for Item 4 which should be 
submitted in September 2011.  draft-jdfalk-marf-reporting-discovery 
could be adopted as WG work published as Experimental before the WG 
gets into a discussion about RFC 2142.  The WG then gets into that 
discussion and determines which alternative is the best.  If it is 
draft-jdfalk-marf-reporting-discovery, the WG can propose moving the 
draft to Proposed Status, with some changes if necessary.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 22 Jun 2010 12:03:44 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> SM
> Sent: Tuesday, June 22, 2010 11:56 AM
> To: J.D. Falk
> Cc: Message Abuse Report Format working group
> Subject: Re: [marf] draft-jdfalk-marf-reporting-discovery
> 

I'd support that approach.

I would also support the idea of posting the draft, conducting the experiment with that draft as the basis and updating it as needed, and only seeking advancement by the IESG once the experiment is concluded and the document updated based on the results.

I don't think we're required to do it either way, so it's really up to the WG to decide how it wants to proceed.

A separate question is whether or not we want to make this a WG document.  So far I hear a couple of votes for but none against.

---

From: John Levine <[email-masked]>
Date: 22 Jun 2010 22:42:01 -0000

>I realized a few weeks ago that I'd neglected to fully describe the
>most immediately interesting use case: verification of consumers.
>Specifically, when a Feedback Consumer requests feedback via the
>current mechanisms (which are almost invariably web forms leading to
>a manual approval process), the Feedback Generator can use the
>relevant advertisement to ensure that the feedback would be going to
>the correct place.

It's certainly a question that's worth thinking about, but it'll be a
challenging security analysis.

For example, how do you identify which of the thousands of domains
that send and receive through gmail's mail servers can claim abuse
reports?

And if we're trying to identify the party that controls an IP address,
we're deep into the maze of twisty passages of no return.  There are
lots of ideas, but they're either provisioning nightmares like adding
an extra rDNS record for every IP, or kludges like asking the contact
for the ASN that routes the address.

We don't need to answer these now, but we need to answer them before
we can claim to have something useful.

R's,
John

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 22 Jun 2010 21:15:41 -0400

> hint about what sorts of discovery they want to do so we know we're

Hmmm... as a sender, I'd rather have the 'advertisement' in the message
itself. I imagine we are trying to avoid DOS, but allowing MAIL FROM lookups
seems to suggest otherwise. So I guess my first question is why not include
a pointer to the information in the message itself? I've seen abuse headers
in messages in the past.

-- 
Jeff Macdonald
Ayer, MA

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Jun 2010 18:19:14 -0700

> for the ASN that routes the address.
It seems that reverse DNS has caused a significant level of wasted 
resources and is unlikely to get any better when IPv6 use starts, which 
tends to make publishing and monitoring this space difficult at best.  
Determining who represents the ASN for an address can be done by 
checking for the most specific BGP announcement.  Since not everyone 
receives and processes a range of BGP feeds, Team Cymru offers a lookup 
service, feed by that process.  A process that also shows which space 
represents a bogon. :^)

http://www.team-cymru.org/Services/ip-to-asn.html

Their service offers the following:
  BGP Origin ASN
  BGP Peer ASN
  BGP Prefix
  Prefix Allocation date
  ASN Allocation date
  ASN Description

This is approximately the process we use when deciding who to contact 
before blocking a CIDR.  Since the Autonomous System is in control of 
the address space, they are held accountable for emitted abuse.  One 
might imagine they should even want to receive reports of abuse to 
mitigate issues before third-party services feel they need to block 
their space.   When that happens, then clearly someone is not doing 
their job.  They know who their customers are, they can see the traffic, 
and can stop malicious or abusive traffic when needed.  It seems rather 
dangerous to allow just anyone to advertise they handle feedback for 
unrelated domains.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 23 Jun 2010 10:04:23 +0200

> that send and receive through gmail's mail servers can claim abuse

You mean how do /they/ identify it?  Large mailbox providers have 
their own FBL assessment criteria.  Often, they explain the 
subscription process in some detail.  However, they don't publish the 
list of domains they've accepted, AFAIK.  Why?

Perhaps, if they published something like a VBR record for the domains 
they consider worth, then small and medium providers can just trust 
that, and decide on the fly whether they want to send feedback through 
the same loop, in case they get complaints from their users.

---

From: John Levine <[email-masked]>
Date: 23 Jun 2010 16:38:45 -0000

>You mean how do /they/ identify it?

Let's say you're an ISP.  You get a note from [email-masked]
saying to please send any FBL reports about his mail to
[email-masked], from this IP range which really is the IP range
that he uses, except that it's also the range that Google and all
their customers use, too.  How do you know to reject the request from
from example.com but accept a similar one from [email-masked]?

The same problem applies on web hosts with shared IPs.  example.com
may well send and receive all its mail on some set of IPs, but the
right party to receive FBL messages is the web hosting company.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 23 Jun 2010 20:13:05 +0200

> right party to receive FBL messages is the web hosting company.

There are two points about that:

1. *How to accept/reject FBL subscriptions*

Apparently, it is necessary to carry out lots of checks related to the 
underlying networking infrastructure, as described above.

2. *How to auto-subscribe senders on the fly*

I'm a tiny mailbox provider, and I get no FBL-subscription requests. 
However, a user of mines reported a message from [email-masked]: 
Was it really from that domain?  Should I forward it?  Where's their 
abuse-box?

If the message passed dkim or spf checks, I'd conclude it was really 
from them.  Furthermore, if I know that google did subscribe them to 
their FBL, e.g. looking up example.com._fbl.google.com, I may conclude 
that they are good guys, and, under suitable assumptions, learn both 
their abuse-box address and its ARF semantics --in case this WG is 
really going to deliver a format with variable semantics, which I 
still hope it won't.

This second point implies that Google (or Yahoo!, AOL, etc.) have 
their own FBL and that would want to share its subscribers and 
semantics.  Would they?

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 23 Jun 2010 13:02:50 -0600

> that send and receive through gmail's mail servers can claim abuse

If the feedback is based on the DKIM d= domain, that's easy.  If it's based on the IP, then I'd hope that the feedback generator would see that it's google and laugh at the request.  This is likely more of a best practice than a discovery protocol issue, though.

> for the ASN that routes the address.

Yep.  I dove into the shallower end of that mess in the draft; I'm surprised nobody has commented on it yet.

> we can claim to have something useful.

There's not much point in the MARF WG trying to devise the One True Perfect Practice for auditing feedback loop requests, because the feedback generators will still do whatever they (and their lawyers) feel like.

I'm hopeful (actually, I'm fairly certain) that a reporting-discovery record will be a useful additional data point they can add to their proprietary practices, but we don't have to replace those practices entirely.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jun 2010 12:25:00 -0700

On 6/23/10 11:13 AM, Alessandro Vesely wrote:
> However, a user of mines reported a message from [email-masked]: Was 
> it really from that domain?  Should I forward it?  Where's their 
> abuse-box?
>
> from them.
In the case of DKIM, a valid signature authenticates the domain handling 
the messages.  In the case of SPF,  a "pass" only indicates a server 
issuing the message was authorized.  The same server might also carry 
mail for thousands of other domains, which is not uncommon.  In 
addition, there is no assurance a return-path or purportedly responsible 
address is bound to any of these possible sources, where it is not 
uncommon for these elements not to be bound to a specific source.  Even 
when one element is bound, which one?  After all both schemes are able 
to can make use of the same record.

When acceptance of a message becomes dependent upon DNS operation, which 
may happen for nearly any acceptance scheme.  Attacking DNS could then 
divert a specific subset of email to a FBL.  The diversion might include 
otherwise legitimate and sensitive email.
> Furthermore, if I know that google did subscribe them to their FBL, 
> e.g. looking up example.com._fbl.google.com, I may conclude that they 
> are good guys, and, under suitable assumptions, learn both their 
> abuse-box address and its ARF semantics --in case this WG is really 
> going to deliver a format with variable semantics, which I still hope 
> it won't.
Expecting a large provider to list their customers seems like a 
non-starter.  Nor would be clear the customers even wished to be listed.
> their own FBL and that would want to share its subscribers and 
The tpa-label scheme offers a safe solution in the case of the provider 
using DKIM, for then sending feedback to the From domain, when signed by 
the large provider.

The tpa-label indicates the From domain has authorized the larger 
provider that adds their own signature.  (Before a larger domain is 
authorized by using a tpa-label, it should be confirmed that use of a 
 From email-address depends upon proof of ownership, such as clicking on 
a pingback message, which is common.)   A valid third-party signature in 
conjunction with a tpa-label offers a fairly noise-free criteria for 
issuing feedback to the From domain.  When the From domain is troubled 
by the level of feedback, they are able to remove the corresponding 
tpa-label, which is also likely the safest choice.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 23 Jun 2010 18:57:18 -0600

On Jun 22, 2010, at 7:15 PM, Jeff Macdonald wrote:

> Hmmm... as a sender, I'd rather have the 'advertisement' in the message itself. I imagine we are trying to avoid DOS, but allowing MAIL FROM lookups seems to suggest otherwise. So I guess my first question is why not include a pointer to the information in the message itself? I've seen abuse headers in messages in the past.

Consider the case where a European ISP can't (or believes they can't, correctly or otherwise) block outbound port 25, but would like to get reports about inappropriate mail sent from those machines.  They have no ability to insert a header.

Consider a hosting company or even a mailbox provider where a machine gets 0wned, and the bad guys can insert -- or remove -- any headers they please.

The vast majority of feedback messages, by volume, aren't complaints about mail from ESPs and other good (or mostly good) senders.  They aren't from confused people on John Levine's mailing lists.  Most of the email that users complaint about is straight-up evil spam.

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 23 Jun 2010 19:01:41 -0600

On Jun 23, 2010, at 12:13 PM, Alessandro Vesely wrote:

> Apparently, it is necessary to carry out lots of checks related to the underlying networking infrastructure, as described above.

That's how it works today.

> I'm a tiny mailbox provider, and I get no FBL-subscription requests. However, a user of mines reported a message from [email-masked]: Was it really from that domain?  Should I forward it?  Where's their abuse-box?
> 
> If the message passed dkim or spf checks, I'd conclude it was really from them.  Furthermore, if I know that google did subscribe them to their FBL, e.g. looking up example.com._fbl.google.com, I may conclude that they are good guys, and, under suitable assumptions, learn both their abuse-box address and its ARF semantics --in case this WG is really going to deliver a format with variable semantics, which I still hope it won't.
> 
> This second point implies that Google (or Yahoo!, AOL, etc.) have their own FBL and that would want to share its subscribers and semantics.  Would they?

If I understand correctly, you're asking if the big ISPs would publish a list of domains which have subscribed to their feedback loops?  Seems...unlikely.  And besides, unsolicited feedback can already go to abuse@, though few have had good luck using ARF while doing that.

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 23 Jun 2010 21:42:00 -0400

> Consider the case where a European ISP can't (or believes they can't, correctly or otherwise) block outbound port 25, but would like to get reports about inappropriate mail sent from those machines…

sure, the IP method helps in that case.

> Consider a hosting company or even a mailbox provider where a machine gets 0wned, and the bad guys can insert -- or remove -- any headers they please.

sure, and the bad guys can put whatever MAIL FROM they want:

"and/or in the DNS domain matching the one
   present in the [SMTP] MAIL commands it issues when sending mail"

did I misunderstand that?

> The vast majority of feedback messages, by volume, aren't complaints about mail from ESPs and other good (or mostly good) senders.

So commentary was asked from large senders. I apologize for thinking
that an ESP that has a monthly magnitude 7+ at times as reported by
SenderBase is not considered as such. I saw several options in the
draft that one can choose to find the advertisement. As an ESP/Sender,
I see value in having such headers as an option.

> They aren't from confused people on John Levine's mailing lists.  Most of the email that users complaint about is straight-up evil spam.

I'd think any sender would like to know how others view their email
stream, and any responsible sender would treat all feedback, no matter
how small, as a sign that things could be improved.

My two cents.

-- 
Jeff Macdonald
Ayer, MA

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Jun 2010 19:52:32 -0700

> The vast majority of feedback messages, by volume, aren't complaints about mail from ESPs and other good (or mostly good) senders.  They aren't from confused people on John Levine's mailing lists.…
Agreed. But most evil spam is being emitted from compromised systems.  
And as ISPs and ESP start blocking port 25, the amount of spam sent from 
compromised accounts also steadily grows, at times rather dramatically 
for some of the larger providers.  Yikes!

The only solution for determining where to send abuse feedback must be 
based upon the AS associated with a particular source IP address, (the 
AS determined by the most specific BGP announcement).  This information 
must be kept current, because this is how Internet traffic is routed.

Sincerely, organizations like MAAWG could run a BGP process, similar to 
that offered by Team Cymru.  Then use the resulting information to offer 
a forwarding service based upon the source IP address contained within 
the MARF report itself. :^)

Such a service would give the organization offering the service 
authoritative insight into which Autonomous Systems are:
  1) poorly managed, or
  2) fail to inform customers of serious problems, or
  3) justify negligence on money -
     a) adequate monitoring or network controls are too expensive,
     b) increased traffic and "special" customers are too profitable.

J.D.  This comment is not aimed at you, and I am sure you have heard 
much of this before.

<rant>
Holding unauthenticated components of a transaction accountable is truly 
a waste of time, and should be considered both a disingenuous and a 
misleading effort.  This is not a problem solved by taxing or fining end 
users or domain name holders through rating systems based upon dubious 
information.  Bad actors will always find a way around contrived rating 
systems that ignore what authentication really means.

Only those who manage Autonomous Systems are really in a position to 
identify and curb abuse, both swiftly and directly.  Some illicit 
organizations are becoming their own ISP and name registry.  Being 
"clever" often ignores which Autonomous Systems need to take action, or 
be cut-off.  Being "clever" often ignores which Autonomous System is 
involved, and drives the problem deeper.  Internet related organizations 
need to find ways to take _effective_ action.  Any strategy that moves 
away from holding Autonomous Systems accountable, represents a step in 
the wrong direction.
</rant>

I hope you did not find the rant offensive. It was not meant to offend.

-Doug

Only the Autonomous System offering the routes are able to monitor the 
activity, to know who's system or account has been compromised, and is 
able to take

---

From: John Levine <[email-masked]>
Date: 24 Jun 2010 14:41:09 -0000

> And besides, unsolicited feedback can already go to abuse@, though
> few have had good luck using ARF while doing that.

I must be few. (Well, I use contact info from abuse.net rather than
just abuse@.)), I'm quite surprised at how well it works.  To the
extent that I get responses at all, they mostly understand what I sent
and do something reasonable.

R's,
John

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 24 Jun 2010 10:42:25 -0600

> did I misunderstand that?

That was mostly an attempt to work with SPF.  It could be removed, and/or we could add even stronger language about authentication identifiers.  Any other thoughts on this from the group?

> I see value in having such headers as an option.

No need to get combative.  This draft isn't an attempt to list all possible ways to request feedback.  There can be other methods, including the header that would work so well for your employer, in other drafts.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 24 Jun 2010 10:46:15 -0600

On Jun 23, 2010, at 8:52 PM, Douglas Otis wrote:

> The only solution for determining where to send abuse feedback must be based upon the AS associated with a particular source IP address, (the AS determined by the most specific BGP announcement).  This information must be kept current, because this is how Internet traffic is routed.

Routing feedback reports by ASN is certainly interesting, and I know some feedback loop systems do (or soon will) support it...but, is there an obvious standard place for an ASN's administrator to advertise their feedback recipient address & policies?  I know someone could create a proprietary system, but that's not task for this WG.

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 24 Jun 2010 14:11:41 -0400

> No need to get combative.  This draft isn't an attempt to list all possible ways to request feedback.  There can be other methods, including the header that would work so well for your employer, in…

I don't really think this would just benefit my employer. I can see
shared hosting environments finding this being useful as well. But if
the focus of the draft is advertisement via DNS, then perhaps I can
offer a slightly different title:

Advertising and Discovering Willingness to Provide or Receive ARF
Reports via DNS

-- 
Jeff Macdonald
Ayer, MA

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Jun 2010 14:21:53 -0700

On 6/24/10 9:46 AM, J.D. Falk wrote:
> > The only solution for determining where to send abuse feedback must
> > be based upon the AS associated with a particular source IP
> > address, (the AS determined by the most specific BGP announcement).
> > This information must be kept current, because this is how Internet
> > traffic is routed.
>
>  Routing feedback reports by ASN is certainly interesting, and I know
>  some feedback loop systems do (or soon will) support it...but, is
>  there an obvious standard place for an ASN's administrator to
>  advertise their feedback recipient address & policies? I know
>  someone could create a proprietary system, but that's not task for
>  this WG.

J.D.,

ICANN requires accredited registrars to collect and provide free public 
access to the name of the registered domain name and its nameservers and 
registrar, the date the domain was created and when its registration 
expires, and the contact information for the Registered Name Holder, the 
technical contact, and the administrative contact.

The GNSO Council approved a resolution asking ICANN Staff to pursue cost 
estimates for six WHOIS study areas recommended by members of the ICANN 
community and ICANN's Government Advisory Committee.

On 23 March 2010 staff provided a report to the GNSO Council with our 
analysis of these proposals. An RFP for a third WHOIS study on Proxy and 
Privacy “Abuse” was posted on 20 May 2010. At least, this seems headed 
in the right direction and clearly needs to conclude with such a service.

Of those that receive our feedback, many only want the highest ranking 
issues when the issue becomes severe. A feature able to rate-limit or 
collapse information might initially be needed for any type of feedback 
scheme, but this would imply that it is being done as a conduit. It 
would seem that MAAWG would be in a good position to take on this task, 
to then report on the collected information.

http://www.potaroo.net/tools/asn32/
offers the following info:

** advertised as 16b 32b

AFRINIC 370 1
APNIC 4112 40
ARIN 13646 9
RIPE NCC 14586 288
LACNIC 1310 60
-----------------------------
(34422) 34024 398

Clearly, resolving IP to AS still needs to determine where feedback is 
accepted for the 34+K AS entities. When acting as a conduit, it remains 
possible to collect statistics for all submissions, even for those not 
forwarded. The number of known sources might be in the millions, but 
could be constrained to just members of the organization.

I consider Dave Rand to be an authority on this issue. Here is his reply:
.---
There is no standard place for abuse reporting, but there is a place to 
register information related to the ASN, and it can be added there. This 
is either the ARIN record or the RIPE/or other registry record for the 
ASN proper. For example:

IP address Status CC Route ASN Path
97.107.131.96 USA 97.107.128.0/20 8001 6461 6461 8001

ASN Name
8001 NET-ACCESS-CORP - Net Access Corporation

CC Country name
USA UNITED STATES

myhost$ nwhois 8001

OrgName: Net Access Corporation
OrgID: NAC-53
Address: 9 Mt. Pleasant Tpk.
City: Denville
StateProv: NJ
PostalCode: 07834
Country: US

ASNumber: 8001
ASName: NET-ACCESS-CORP
ASHandle: AS8001
Comment:
RegDate: 1996-08-22
Updated: 1998-05-18

RTechHandle: AR97-ARIN
RTechName: Rubenstein, Alex
RTechPhone: +1-973-590-5101
RTechEmail: [email-masked]
'---

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 24 Jun 2010 14:36:40 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Tuesday, June 22, 2010 12:04 PM
> To: SM; J.D. Falk
> A separate question is whether or not we want to make this a WG
> document.  So far I hear a couple of votes for but none against.

So let me make this a more explicit statement and a question:

Does the WG consider this draft a good basis for discussion?  We have this as our fourth charter item, so it is certainly within scope.  And clearly people are up for discussing it, as is evidenced by this thread.

If the answer is "yes", which is what I expect (and as a participant, that's my vote), then we should make it a working group document, even if later on we decide this is not something that should be formally specified.  Note that a "yes" here doesn't mean you agree with all of the document in its current form; rather, you are agreeing that it is a reasonable place to start the conversation.  The WG can revise the document via the consensus process once we've done that.

If not, we should figure out how we do want to address that fourth charter item, and begin working on that path instead.

Please state your position for the record.

Thanks,
Murray [as co-chair]

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 24 Jun 2010 17:43:43 -0400

I think it is a good place as any to start discussion as one of the
proposals on advertising ARF receivers.

HOWEVER, we might need to step back first and look at what possible
options there are before committing to a specific one. I think that
SMTP extensions, signed headers like List-Unsubscribe, DNS, etc. may
be some of them. Perhaps a draft covering possible advertising
mechanisms may be in order.

Yakov

On Thu, Jun 24, 2010 at 5:36 PM, Murray S. Kucherawy <[email-masked]> wrote:
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 24 Jun 2010 14:49:26 -0700

> From: Yakov Shafranovich [mailto:[email-masked]]
> Sent: Thursday, June 24, 2010 2:44 PM
> To: Murray S. Kucherawy
> Cc: J.D. Falk; Message Abuse Report Format working group
> Subject: Re: [marf] Poll: Importing draft-jdfalk-marf-reporting-
> discovery
> 

I'll count that as a "yes", given your first paragraph.  As I said, we're free to modify the draft according to what you said in the second based on consensus.

---

From: [email-masked]
Date: Thu, 24 Jun 2010 18:20:14 -0400

If you are going to put together a list of potential discovery options, you might want to start by collecting a list of current approval criteria.  That would give you an idea of how acceptable the various discovery options would be.

-----Original Message-----
From: Murray S. Kucherawy <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
Cc: Message Abuse Report Format working group <[email-masked]>
Sent: Thu, Jun 24, 2010 2:49 pm
Subject: Re: [marf] Poll: Importing draft-jdfalk-marf-reporting-discovery

> mechanisms may be in order.

I'll count that as a "yes", given your first paragraph.  As I said, we're free 

to modify the draft according to what you said in the second based on consensus.

marf mailing list

[email-masked]

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 24 Jun 2010 16:26:26 -0600

> mechanisms may be in order.

The ASRG already did that, though they didn't publish it as a draft:

http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs

They were focused on MUA submissions, but I think similar logic applies -- and, indeed, I reviewed this document carefully when devising my draft.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 24 Jun 2010 16:27:21 -0600

> Please state your position for the record.

I support making draft-jdfalk-marf-reporting-discovery a WG document.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 24 Jun 2010 16:35:03 -0600

On Jun 24, 2010, at 3:21 PM, Douglas Otis wrote:

> There is no standard place for abuse reporting, but there is a place to register information related to the ASN, and it can be added there. This is either the ARIN record or the RIPE/or other registry record for the ASN proper.

Makes sense, and I think it could be a worthy effort...but with all those different agencies involved it sounds like it'd be outside of this WG's charter, and likely outside of the IETF entirely.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Jun 2010 15:35:29 -0700

> I'll count that as a "yes", given your first paragraph.  As I said, we're free to modify the draft according to what you said in the second based on consensus.
I'd say that it depends.  The discovery process needs to be highly 
conservative.   Determining where feedback is to be sent MUST NOT be 
based upon an IP address where the destination unrelated to the 
corresponding AS.

A domain offering an IP address authorization must be considered of no 
value when not found within an originating header or return-path 
parameter.  In which case, there is already a discovery convention 
covering this type of situation, abuse@<originating-domain>.

Do not rely on any unauthenticated relationship, as this runs a risk 
leaking sensitive information to unknown entities.  If it can happen, it 
will happen.  Murphy is always right.

-Doug

---

From: SM <[email-masked]>
Date: Thu, 24 Jun 2010 15:53:19 -0700

At 14:36 24-06-10, Murray S. Kucherawy wrote:
>Does the WG consider this draft a good basis for discussion?  We 
>have this as our fourth charter item, so it is certainly within 
>scope.  And clearly people are up for discussing it, as is evidenced 
>by this thread.

Yes.

>If not, we should figure out how we do want to address that fourth 
>charter item, and begin working on that path instead.

If there are any other proposals, I suggest submitting them as an I-D.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 24 Jun 2010 15:58:23 -0700

> From: SM [mailto:[email-masked]]
> Sent: Thursday, June 24, 2010 3:53 PM
> To: Murray S. Kucherawy
> Cc: Message Abuse Report Format working group; J.D. Falk

+1

> If there are any other proposals, I suggest submitting them as an I-D.

Super-duper +1.

-MSK [as participant]

---

From: Steve Atkins <[email-masked]>
Date: Thu, 24 Jun 2010 16:06:17 -0700

+1

Cheers,
  Steve

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 24 Jun 2010 19:47:50 -0400

On Thu, Jun 24, 2010 at 5:36 PM, Murray S. Kucherawy <[email-masked]> wrote:

> Does the WG consider this draft a good basis for discussion?

-- 
Jeff Macdonald
Ayer, MA

---

From: Barry Leiba <[email-masked]>
Date: Thu, 24 Jun 2010 19:57:48 -0400

>> Does the WG consider this draft a good basis for discussion?

And your answer, Jeff, is...... ?
--------------------------

Others:  Please do not discuss the options in this thread.  Please
just let us know "yes" or "no", about whether the WG should adopt the
subject document and work from there.

If you have discussion, please start another thread for it.

So far, I don't take any of the comments in this thread to say "no".
If you have posted to this thread and your vote on adoption is "no",
please re-post and make that clear.

Barry, as chair

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 24 Jun 2010 20:54:06 -0400

opps, don't know how that happened.

My answer is Yes.

-- 
Jeff Macdonald
Ayer, MA

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Jun 2010 19:29:46 -0700

On 6/24/10 4:57 PM, Barry Leiba wrote:
> On Thu, Jun 24, 2010 at 7:47 PM, Jeff Macdonald<[email-masked]>  wrote:
>    
>> On Thu, Jun 24, 2010 at 5:36 PM, Murray S. Kucherawy<[email-masked]>  wrote:
>>
>>      

Although jdfak-marf reporting is okay, I must admit to preferring the 
approach found in:
http://tools.ietf.org/html/draft-daboo-srv-email-05

This srv mail approach seems like a natural place to make these 
extensions, which allows a way to prioritize a set of preferences.

I am also a bit concerned with the number of options, especially the 
option that allows use of http.  By itself, http is fine, but we have 
seen attempts to place captcha front-ends on these types of inputs, 
which severely limits their utility.  They seem share the attitude with 
those that put spam filters on their abuse feedback.  No kidding.

There will be a number of games played by administrators seeking ways 
divert this input, perhaps to keep it off management's radar.  All of 
the options in the jdfalk-marf report approach are likely to create 
hurdles and barriers that aren't needed.   Using a simpler strategy 
found with srv-email seems better along with a more constrained set of 
input parameters.

If there is any interest in consider this as an alternative, I'd be 
happy to create a draft along these lines as well.

-Doug

---

From: John Levine <[email-masked]>
Date: 25 Jun 2010 03:29:51 -0000

>>> Does the WG consider this draft a good basis for discussion?

Sure, keeping in mind that "discussion" and "turning into an RFC" are
not synonyms.

R's,
John

---

From: Jacqui Caren-home <[email-masked]>
Date: Fri, 25 Jun 2010 09:21:17 +0100

> I'll count that as a "yes", given your first paragraph.  As I said, we're free to modify the draft according to what you said in the second based on consensus.

And thats also a yes from me - one of the quiet lurkers :-)

Jacqui

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 25 Jun 2010 11:41:54 +0200

+1

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 25 Jun 2010 12:13:09 +0200

> That was mostly an attempt to work with SPF.  It could be removed, and/or we could add even stronger language about authentication identifiers.  Any other thoughts on this from the group?

I vote for an even stronger specification of authentication.

It will complicate the document somewhat, as it will have to reference 
each method.  John says he uses abuse.net to lookup a domain's 
contacts, perhaps he'll also mention how he extracts the domain name...

How about a template around the lines of

   If original message was authenticated by method M,
   extract domain name D from field F,
   and send a report to address A or abuse@D
   (see also Security Considerations --Murphy is always right.)

Some email authentication methods are listed in 
http://www.iana.org/assignments/email-auth/email-auth.xhtml#email-auth-methods

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 25 Jun 2010 11:23:13 -0600

On Jun 25, 2010, at 4:13 AM, Alessandro Vesely wrote:

> It will complicate the document somewhat, as it will have to reference each method.  John says he uses abuse.net to lookup a domain's contacts, perhaps he'll also mention how he extracts the domain name...
> 
> Some email authentication methods are listed in http://www.iana.org/assignments/email-auth/email-auth.xhtml#email-auth-methods

Contributions to the draft are welcome.  *grin*

(If you'd like a copy of the current XML file, let me know.)

---

From: John Levine <[email-masked]>
Date: 25 Jun 2010 19:38:01 -0000

>contacts, perhaps he'll also mention how he extracts the domain name...

A combination of rDNS of the connecting IP and a manually maintained
table of IP ranges.  The rDNS is reasonably reliable so long as you do
the usual forward/reverse checks, but the IP range table really doesn't
scale.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 26 Jun 2010 13:05:43 +0200

> (If you'd like a copy of the current XML file, let me know.)

I attach a patch to an older version, it should work just the same, as 
the added text is rather self-contained.

I added two paragraphs before section 5.1, to bind with A-R, and then 
an authentication section (tentatively section 6) with just two 
methods --DKIM and SPF.  We can add more methods if that seems the 
right thing to do.  E.g., if the relay's IP is the MX of a sender 
address (or would MX/24 suffice? Hm... bad kind of heuristics.)

Finally, I tried a "Privacy considerations" subsection.  The 
attachment should be readable, so there is a chance to discuss it even 
before committing it.
--- draft-jdfalk-marf-reporting-discovery-00.xml	2010-05-12 12:26:01.000000000 +0200
+++ draft-jdfalk-marf-reporting-discovery-01.xml	2010-06-26 12:36:52.000000000 +0200
@@ -191,6 +191,15 @@
 			<xref target="POP"/> service to that user.  For example,
 			when the user's IMAP server is imap.example.net, the applicable
 			advertisement will be found at _report.imap.example.net. </t>
+			<t> End users may also rely on trusted Authentication-Results
+			header fields: in case the Authentication Identifier ("authserv-id"
+			in <xref target="AUTH-METHODS"/>) provides a valid email domain,
+			its abuse@ mailbox may be assumed a valid target for reporting
+			abuse, according to <xref target="MAILBOX-NAMES"/>.</t>
+			<t> In any case, feedback generators should not send reports to
+			ADMDs that are not responsible for the reported message, for both
+			security and efficiency reasons.  Responsibility can be ascertained
+			as described in <xref target="auth-checks"/>.</t>
 
 			<section anchor="consumer" title="Feedback Consumers">
 				<t>
@@ -321,6 +330,26 @@
 			</section>
 		</section>
 
+		<section anchor="auth-checks" title="Authentication of Reported Message">
+			<t> <xref target="AUTH-METHODS"/> and its extensions define a number
+			of authentication methods that allow to attribute responsibility of
+			the reported message to the ADMDs identified by the relevant domain
+			names.  An initial list of domain names is obtained checking each
+			method.  Each domain name shall in turn be validated against the
+			relevant policy.</t>
+			<section title="DKIM signatures">
+				<t> Any valid DKIM signature in the reported message provides a
+				domain name, either the signature "d" tag, or the domain-part of
+				the signature "i" tag.</t>
+			</section>
+			<section title="SPF authorized sender">
+				<t> When the check_host() function described in <xref target="SPF"/>
+				results in a "pass" for the envelope sender, the domain part of
+				that address.  Otherwise, if a "pass" is obtained for the
+				HELO/EHLO name, that domain name.</t>
+			</section>
+		</section>
+
 		<section anchor="IANA" title="IANA Considerations">
 			<t> This memo includes no request to IANA, though that may change
 			in later drafts.</t>
@@ -336,6 +365,28 @@
 			<section title="TBD">
 			<t> Additional security considerations are likely, and TBD. </t>
 			</section>
+			<section title="Privacy considerations">
+				<t> When recipients report received messages as spam, they deny
+				any involvement with whoever may turn out to be responsible of
+				authoring or forwarding that mail.  Users submit that spam to
+				the community at large in the hope that a corrective action may
+				be taken.  In that respect, the only privacy issue is to avoid to
+				further divulge the email addresses of reporting users, or let
+				them be profiled.  Suitably redacted email addresses are an
+				acceptable remedy.  Responsible senders are advised to include
+				opaque tokens as necessary, in order to reconstruct needed data.</t>
+				<t> However, users may also err.  Unwanted smear may result in
+				case a message containing confidential data is erroneously
+				reported as spam.  Authentication and policies are concerned with
+				avoiding such circumstances.  Recipients of special addresses
+				at an ADMD that handled a given message could have intercepted the
+				message when they signed or relayed it, if they wanted to,
+				therefore it is less of a concern to forward abuse reports there.</t>
+				<t> Contact addresses for a given domain name should bear such
+				name as their domain parts.  Generators may treat non-conforming
+				addresses with great suspicion, possibly avoiding to relay to them.
+				</t>
+			</section>
 		</section>
 
 		<section anchor="Acknowledgements" title="Acknowledgements">
@@ -524,8 +575,74 @@
 				</front>
 				<seriesInfo name="RFC" value="1035"/>
 			</reference>
-		</references>
 
+			<reference anchor='AUTH-METHODS'>
+
+			<front>
+			<title>Message Header Field for Indicating Message Authentication Status</title>
+			<author initials='M.' surname='Kucherawy' fullname='M. Kucherawy'>
+			<organization /></author>
+			<date year='2009' month='April' />
+			<abstract>
+			<t>This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts.  Any receiver-side software, such as mail filters or Mail User Agents (MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. [STANDARDS TRACK]</t></abstract></front>
+
+			<seriesInfo name='RFC' value='5451' />
+			<format type='TXT' octets='97404' target='http://www.rfc-editor.org/rfc/rfc5451.txt' />
+			</reference>
+
+
+			<reference anchor='MAILBOX-NAMES'>
+
+			<front>
+			<title abbrev='Mailbox Names'>MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS</title>
+			<author initials='D.' surname='Crocker' fullname='Dave Crocker'>
+			<organization>Internet Mail Consortium</organization>
+			<address>
+			<postal>
+			<street>127 Segre Ave.</street>
+			<street>Santa Cruz</street>
+			<country>CA</country></postal>
+			<phone>+1 408 246 8253</phone>
+			<email>[email-masked]</email></address></author>
+			<date year='1997' month='May' />
+			<area>Applications</area>
+			<keyword>mail</keyword>
+			<abstract>
+			<t>
+			   This specification enumerates and describes Internet mail addresses
+			   (mailbox name @ host reference) to be used when contacting personnel
+			   at an organization.  Mailbox names are provided for both operations
+			   and business functions.  Additional mailbox names and aliases are not
+			   prohibited, but organizations which support email exchanges with the
+			   Internet are encouraged to support AT LEAST each mailbox name for
+			   which the associated function exists within the organization.
+			</t></abstract></front>
+
+			<seriesInfo name='RFC' value='2142' />
+			<format type='TXT' octets='12195' target='http://www.rfc-editor.org/rfc/rfc2142.txt' />
+			<format type='HTML' octets='29012' target='http://xml.resource.org/public/rfc/html/rfc2142.html' />
+			<format type='XML' octets='16712' target='http://xml.resource.org/public/rfc/xml/rfc2142.xml' />
+			</reference>
+
+
+
+			<reference anchor='SPF'>
+
+			<front>
+			<title>Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1</title>
+			<author initials='M.' surname='Wong' fullname='M. Wong'>
+			<organization /></author>
+			<author initials='W.' surname='Schlitt' fullname='W. Schlitt'>
+			<organization /></author>
+			<date year='2006' month='April' />
+			<abstract>
+			<t>E-mail on the Internet can be forged in a number of ways.  In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands.  This document describes version 1 of the ender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization.  This memo defines an Experimental Protocol for the Internet community.</t></abstract></front>
+
+			<seriesInfo name='RFC' value='4408' />
+			<format type='TXT' octets='105009' target='http://www.rfc-editor.org/rfc/rfc4408.txt' />
+			</reference>
+
+		</references>
 		<references title="Informative References">
 
 			<reference anchor="ASRG-ABUSE">

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sat, 26 Jun 2010 21:21:44 -0400

In <[email-masked]>, on 06/24/2010

>extensions, which allows a way to prioritize a set of preferences.

AOL.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

---

From: Barry Leiba <[email-masked]>
Date: Mon, 28 Jun 2010 18:07:30 -0400

> AOL.

Shmuel, is that a vote for, or against adoption of the subject document?

Barry, as MARF chair