Subject: [marf] FBL BCP

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Apr 2011 10:09:07 -0700

Per our meeting in Prague, we'd like to get some direction on the MAAWG feedback loop BCP document and how we want to handle our deliverable of producing one of our own.

The MAAWG document has basically been translated to I-D form by JD Falk and is available here:

                http://datatracker.ietf.org/doc/draft-jdfalk-maawg-cfblbcp/

Our options come down to the following:

1) Post an informational draft that essentially endorses the MAAWG BCP as-is.

2) Propose some changes, which go back to the MAAWG Board for approval, and then they would change their published version, and then we would do (1).

3) Publish an endorsement of the MAAWG BCP, but also include a list of differences we have with it.  This would be our BCP, and doesn't require any changes to their version.

4) Make our own version, taking what we want from theirs.  It would mention attribution as appropriate but make it clear that it's not exactly their version.  This one could get BCP status.  MAAWG may or may not like this, depending on what the changes are.

All of these require MARF participants to review the above draft and comment, even if the comment is "I like it as-is".  Once we have consensus we can pick a preferred course of action and start working on it.

So that's everybody's homework on this topic.

-MSK

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 13 Apr 2011 10:46:07 -0700

On Apr 13, 2011, at 10:09 AM, Murray S. Kucherawy wrote:

> 3) Publish an endorsement of the MAAWG BCP, but also include a list of differences we have with it.  This would be our BCP, and doesn’t require any changes to their version.

[as participant] After rereading the FBL-related sections in draft-ietf-dkim-mailinglists, I'm leaning towards option 3.  Rather than (or along with) a list of differences, we could include (or refer to) additional issues which could impact feedback loops.

[as editor of the document] Whichever of those options the WG wants to pursue is fine with me.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Apr 2011 10:48:35 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of J.D. Falk
> Sent: Wednesday, April 13, 2011 10:46 AM
> To: Message Abuse Report Format working group
> Subject: Re: [marf] FBL BCP
> 
> > 3) Publish an endorsement of the MAAWG BCP, but also include a list
> of differences we have with it.  This would be our BCP, and doesn't
> require any changes to their version.
> 
> [as participant] After rereading the FBL-related sections in draft-
> ietf-dkim-mailinglists, I'm leaning towards option 3.  Rather than (or
> along with) a list of differences, we could include (or refer to)
> additional issues which could impact feedback loops.
> 

3) Makes sense to me if the consensus list of differences we have with the MAAWG BCP is small.  Otherwise, (4) might be the better option.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 14 Apr 2011 18:47:20 +0200

On 13/Apr/11 19:46, J.D. Falk wrote:
>> 3) Publish an endorsement of the MAAWG BCP, but also include a
>> list of differences we have with it.  This would be our BCP, and
>> doesn’t require any changes to their version.
> 
> [as participant] After rereading the FBL-related sections in
> draft-ietf-dkim-mailinglists, I'm leaning towards option 3.  Rather
> than (or along with) a list of differences, we could include (or
> refer to) additional issues which could impact feedback loops.

The definition of FBL given in dkim-mailinglists is much easier than
the one in maawg-cfblbcp.  For one nit, I don't understand the reason
why the latter document intentionally refrains from using the acronym
"FBL".

The reporting-discovery doc just uses the word "feedback", and talks
about feedback reports, feedback generators/consumers, and feedback
reporting advertisement.  The latter term, possibly, can be clearly
understood even when met out of context.  The others may clash with
some semiconductor devices or other stuff.

In addition, there is the Whois-based reporting approach.  Some
reworking of this model is underway, and it may eventually bring up
yet another flavor of reporting abuse.  Abusix uses the term "global
reporting" for it, which clashes with the same term as used by
globalreporting.org (see links in the footer).

IMHO, it may improve clarity if our BCP, besides endorsing the MAAWG
BCP, also endorses the other two practices, sketches the differences
among them, and possibly gives some guidance.

-- 
http://tools.ietf.org/html/draft-ietf-marf-reporting-discovery
http://tools.ietf.org/html/draft-ietf-dkim-mailinglists
http://tools.ietf.org/html/draft-jdfalk-maawg-cfblbcp
http://abusix.org/service/global-reporting
http://www.globalreporting.org/Home
http://www.ripe.net/ripe/groups/tf/abuse-contact

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 14 Apr 2011 12:28:26 -0700

> among them, and possibly gives some guidance.

This is discussed somewhat in the 3rd appendix, though the terminology is different.  IIRC, many MAAWG members were extremely wary of unsolicited feedback, whether using WHOIS records or other methods to determine the address to flood with reports.  After years of dealing with spam, we always prefer opt-in participation models -- especially for email.

---

From: SM <[email-masked]>
Date: Fri, 15 Apr 2011 00:18:30 -0700

Hi Alessandro,
>globalreporting.org (see links in the footer).

Do you mean the unsolicited reports send to any email address that 
appears in Whois?  The coalition of the willing generally uses 
Spamcop to do that on the assumption that someone out there will take 
action.  Force feeding receivers with abuse reports is not effective 
when over 99% of the reports are incorrect.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 15 Apr 2011 11:14:46 +0200

On 15/Apr/11 09:18, SM wrote:
>> In addition, there is the Whois-based reporting approach.
> 
> appears in Whois?

Yes, IP-based Whois, and databases based on that.

> The coalition of the willing generally uses Spamcop to do that on
> the assumption that someone out there will take action.

The complainant's mailbox provider is more knowledgeable than a third
party for such job --with all due appreciation for Spamcop's activity.
Providers may carry out some simple verifications on submitted
reports, while third parties have to trust them.  In either case, this
activity of forwarding abuse reports to the /right place/ deserves to
be named and mentioned in some standard document.

We have recently standardized a report format.  Adding guidance for
its effective use seems just natural.

> Force feeding receivers with abuse reports is not effective when over
> 99% of the reports are incorrect.

Is it so already?

---

From: SM <[email-masked]>
Date: Fri, 15 Apr 2011 08:12:15 -0700

Hi Alessandro,
>Yes, IP-based Whois, and databases based on that.

I'll borrow a few words from J.D. [1].  "After years of dealing with 
spam, we always prefer opt-in participation models".  Why is the 
opt-out (I am not sure if that option exists) model acceptable for 
these reports?

>Is it so already?

Yes.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/marf/current/msg01069.html

---

From: Steve Atkins <[email-masked]>
Date: Fri, 15 Apr 2011 09:12:52 -0700

On Apr 15, 2011, at 8:12 AM, SM wrote:

> I'll borrow a few words from J.D. [1].  "After years of dealing with spam, we always prefer opt-in participation models".  Why is the opt-out (I am not sure if that option exists) model acceptable for these reports?

I think that may be the wrong thing to focus on (not least because it leads to the rathole that manually written abuse reports are usually unsolicited, and a common argument is that if 1 manually written report is OK, then 10,000 boilerplate reports must be OK).

The bigger point may be that unless a report receiver has tooled up to accept a certain level of reports in this format, they're unlikely to be able to do anything useful with them other than direct them to /dev/null. If they have tooled up to accept those reports then opting-in to receiving them by some approach is part of that process.

Several enthusiasts and companies have tried sending large volumes of unsolicited, bulk reports to addresses scraped from whois. It's not gone well, and they've often ended up routed to /dev/null.

ARF reports are in an easily recognizable format. I'd rather not encourage behaviour on the part of report senders that will make report receivers filter based on that format.

Cheers,
  Steve

> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 15 Apr 2011 19:41:47 +0200

On 15/Apr/11 18:12, Steve Atkins wrote:
>> I'll borrow a few words from J.D. [1].  "After years of dealing
>> with spam, we always prefer opt-in participation models".  Why is
>> the opt-out (I am not sure if that option exists) model
>> acceptable for these reports?

I wouldn't call it "opt-out" if the target address was that of an
incident response team, or similar abuse POC.

> I think that may be the wrong thing to focus on (not least because
> it leads to the rathole that manually written abuse reports are
> usually unsolicited, and a common argument is that if 1 manually
> written report is OK, then 10,000 boilerplate reports must be OK).

> The bigger point may be that unless a report receiver has tooled up
> to accept a certain level of reports in this format, they're
> unlikely to be able to do anything useful with them other than
> direct them to /dev/null. If they have tooled up to accept those
> reports then opting-in to receiving them by some approach is part
> of that process.

I subscribed to receive Spamcop's reports.  I received none to date.
Possibly because I try and avoid sending spam.  Or maybe because the
spam I may have happened to send was reported to some other hub.
After SM reminded me of it, I found out that my record on Spamcop was
still linked to an old range of IP addresses that I quit in 2008.
Obviously I'm unable to recall every place where I wrote IP addresses.

IP-based Whois databases are unique, in a DNS sense.  I'd prefer to
set up a finite number of DNS RRs than go hunting for every spam
reporting hub and FBL that spam originating from my server might be
reported to.  That's why I like reporting discovery: it scales.

> Several enthusiasts and companies have tried sending large volumes
> of unsolicited, bulk reports to addresses scraped from whois. It's
> not gone well, and they've often ended up routed to /dev/null.

Were they incorrect reports?  Is that the rationale behind SM's
affirmative response below?

Of course, directly setting "/dev/null" for Whois abuse POCs may
result in remarkable band optimizations, but then such setting would
betray the fact that the relevant admins couldn't care less...

> ARF reports are in an easily recognizable format. I'd rather not
> encourage behaviour on the part of report senders that will make
> report receivers filter based on that format.

Yes, we must carefully avoid that.

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 15 Apr 2011 11:42:08 -0700

>> 99% of the reports are incorrect.

Maybe for a few sites, but not for the majority of ARF Consumers today.

---

From: "John Levine" <[email-masked]>
Date: 15 Apr 2011 19:00:39 -0000

>Maybe for a few sites, but not for the majority of ARF Consumers today.

My impression is that most ARF reports are sent through FBLs, which by
their nature tend to go to the right place.

I can easily believe that the vast majority of over-the-transom reports
are wrong, when I see some of the crud that shows up at abuse.net.

R's,
John

---

From: SM <[email-masked]>
Date: Fri, 15 Apr 2011 12:30:13 -0700

At 09:12 15-04-2011, Steve Atkins wrote:
>reports then opting-in to receiving them by some approach is part of 
>that process.

Yes.

[snip]

Yes.

>incident response team, or similar abuse POC.

And I am going to find it more difficult to convince people to 
process the reports if the abuse point of contact is used in an abusive way.

>reported to.  That's why I like reporting discovery: it scales.

There are senders of abuse reports out there that have some 
difficulty reading IP-based Whois results.

>betray the fact that the relevant admins couldn't care less...

I guess that I should use "/dev/null" as an optimization 
technique.  However, there is the errant, again misdirected, denial 
of service report that could do with some attention.

Regards,
-sm

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sun, 17 Apr 2011 14:19:19 -0400

In <[email-masked]>, on 04/15/2011

>process the reports if the abuse point of contact is used in an

Whether it is abusive depends on what the feedback address is
registered for. Certainly an ARF abuse complaint should not be sent to
addresses not registered for the purposes and an unregistered provider
should not be sending to a consumer who requires registration.

-- 
     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: "John Levine" <[email-masked]>
Date: 17 Apr 2011 21:39:40 -0000

>1) Post an informational draft that essentially endorses the MAAWG BCP as-is.

Having had a certain amount to do with this document at MAAWG, I saw
the key fact that the FBLs that matter involve a vast amount of mail,
with a correspondingly large flow of FBLs.  Unless I've missed
something, this group doesn't have anywhere near as much experience
with large mail systems as the group at MAAWG who wrote it.  (If you
were wondering, I consider my 75,000 messages/day to be quite small.)

So I think we should sign off on it as is.

If people have bright ideas about how to do FBLs differently, there's
nothing keeping you from writing I-Ds intended for experimental and later
standards track RFCs.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 17 Apr 2011 19:51:44 -0400

> So I think we should sign off on it as is.

I agree.  I'm happy if we have a couple/few paragraphs to say about
it, but more than that seems to be hobbling the horse and then having
to pull the cart by ourselves.

Barry, as participant

---

From: SM <[email-masked]>
Date: Sun, 17 Apr 2011 22:53:15 -0700

Hi Murray,
At 10:09 13-04-2011, Murray S. Kucherawy wrote:
>Per our meeting in Prague, we'd like to get some direction on the 
>MAAWG feedback loop BCP document and how we want to handle our 
>deliverable of producing one of our own.
>

[snip]

>4) Make our own version, taking what we want from theirs.  It would 
>mention attribution as appropriate but make it clear that it's not 
>exactly their version.  This one could get BCP status.  MAAWG may or 
>may not like this, depending on what the changes are.

 From previous discussions, I understood that it would not be 
possible to use draft-jdfalk-maawg-cfblbcp as input for work within 
this working group.  I prefer not to see a document which MAAWG may 
not like as it is their work after all.  I suggest that the WG Chairs 
talk to MAAWG and explain to them how the IETF works.  If MAAWG is 
happy to give change control to the IETF, the MARF WG can consider 
using the work as input.  If the deliverable cannot be produced 
without the MAAWG document, I suggest taking it off the list.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 18 Apr 2011 12:00:34 +0200

On 17/Apr/11 20:19, Shmuel (Seymour J.) Metz wrote:
> addresses not registered for the purposes

I'd agree, but then what does "registered for the purposes" mean?
IMHO that's exactly the kind of thing we need to clarify.  The correct
target can be any of

1) a public reporting hub / global reputation tracker,
2) a reporting hub for users of a given domain only,
3) an FBL subscriber,
4) the abuse POC of a DKIM signer of the reported message, or
5) an abuse POC responsible for the IP of the last relay.

The MAAWG document primarily deals with (3), but appendixes B and C
contemplate cases (4) and (5), respectively. (2) was discussed on the
ASRG from December 2009 to March 2010. (1) was mentioned in DomainRep.

There is no clear-cut distinction among these methods for selecting
the report target, because they can be mixed both sequentially
(forwarding) and in parallel (multiple targets.)  For this reason, the
document that endorses the MAAWG BCP should also complement it, and
thus provide a general overview.

> nothing keeping you from writing I-Ds intended for experimental and later

Why do you say "you", you want out?

"Experimental" seems to be the right thing, but it wants a WG for
crafting it properly, and possibly provide code.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 18 Apr 2011 09:35:24 -0400

> From previous discussions, I understood that it would not be possible to use
> draft-jdfalk-maawg-cfblbcp as input for work within this working group.  I
> prefer not to see a document which MAAWG may not like as it is their work
> after all.  I suggest that the WG Chairs talk to MAAWG and explain to them
> how the IETF works.  If MAAWG is happy to give change control to the IETF,
> the MARF WG can consider using the work as input.  If the deliverable cannot
> be produced without the MAAWG document, I suggest taking it off the list.

I suggest that we stop having meta-discussion about the document, and
instead review the document and come up with working group consensus
about it.  That will let us give feedback to MAAWG based on working
group consensus, and will also allow individuals to feed their own
comments back to MAAWG.  All that will help MAAWG improve the document
in a possible revision.

After we've done that, we can see where we stand with respect to the
MAAWG document, and then have the meta-discussion of what to do about
the work item.

Barry, as chair

---

From: Dotzero <[email-masked]>
Date: Mon, 18 Apr 2011 10:18:20 -0400

I'm comfortable with leaving the document as-is and do not feel that
there is a compelling reason to come up with a separate BCP document
at this time. I'm confident that the MAAWG folks have an understanding
of how the IETF works and that their intent was asstated- to provide
the document that they produced as a reference point. The status is
informational.

Mike

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 20 Apr 2011 13:25:25 -0400

In <[email-masked]>, on 04/18/2011

>I'd agree, but then what does "registered for the purposes" mean?

My take is that we need syntax for defining both addresses and use of
the address; a consumer wanting both public and registered feedback
may not want them going to the same address.

>The correct target can be any of
>4) the abuse POC of a DKIM signer of the reported message, or 5) an
>abuse POC responsible for the IP of the last relay.

A consumer might want all of those, but not in the same mailbox.

Given the above, I suggest that we define a rr=role paramaeter and
allow multiple groups of tag-value pairs, either in a single '_report'
TXT RR or in separate '_report&foo' TXT RR's.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 21 Apr 2011 10:49:54 -0700

> TXT RR or in separate '_report&foo' TXT RR's.

This sounds a lot like draft-ietf-marf-reporting-discovery, plus a few additional POC options.  Only question is whether anyone would want to advertise all of those separate addresses in DNS -- and whether anyone would want to take the time to look them up, or just send ARF to the advertised address and non-ARF to abuse@.

(Either way, it doesn't sound at all like a CURRENT practice to add to a BCP document.)

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Thu, 21 Apr 2011 14:55:29 -0400

In <[email-masked]>, on
04/21/2011
   at 10:49 AM, "J.D. Falk" <[email-masked]> said:

>This sounds a lot like draft-ietf-marf-reporting-discovery,

It's a suggestion for a change to that document.

>plus a few additional POC options.

Along with the ability to specify more than one POC.

>Only question is whether anyone would want to advertise all of those
>separate addresses in DNS

Alessandro seemed to be suggesting that there was a need to allow
separation.

>and whether anyone would want to take the time to look them up, or
>just send ARF to the advertised address and non-ARF to abuse@.

There wouldn't be a separate lookup. It would be one lookup with
parsing.

>(Either way, it doesn't sound at all like a CURRENT practice to add

Correct.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 22 Apr 2011 19:25:20 +0200

> In <[email-masked]>, on

No, not exactly...  Let me repeat that list:

(Also in http://en.wikipedia.org/wiki/Spam_reporting --new.)

(1) and (3) are private mechanisms that are currently not fully
standardized.  Spamcop is a peculiar kind of (1) where subscribers can
specify their address.  For (3), the CFBL BCP gives some hints in Sec.
3.5.  Subscription involves specifying an email address (that Sec.
4.1#2 recommends be "dedicated".)

(5) is the address that the ISP registered at RIR's Whois db.
Apparently, it is out of our charter's scope.

For (2) and (4), separation could have come by itself if addresses
were given at different places.  Specifically:

(2) is not standardized.  It has to be triggered by a button, which
eases its use for web mail.  For reports sent via email, it could be
specified as an update to RFC 6186.  Alternatively, last year I
proposed a "Report-To" tag in the last item of "More A-R bits...":
http://mipassoc.org/pipermail/mail-vet-discuss/2010q2/000597.html

(4) is not related to dkim-reporting --indeed, it implies successful
verification of the relevant DKIM signature-- but an abuse reporting
address could be standardized in a similar way.  The same goes for
spam relayed by SPF-authenticated senders.

Instead, it is certainly more practical to define the addresses for
reporting DKIM- or SPF- authenticated spam (4) homogeneously in the
reporting-discovery document.  The draft already mentions DKIM.
Possibly, the ISP's abuse address (2) can also be defined that way,
but there are a few more details to be worked out.  So, the domain
part to put after "_report." for querying would be:

DKIM   the domain defined in d= (already mentioned in Sec. 5),
SPF    the domain where the TXT or SPF record was found, and
ISP    the authserv-id of the A-R record, for authenticated messages.

With such homogeneous definition, one can define the same target
address for all methods. Using different (sub-) addresses may seem to
be consistent with the CFBL BCP recommendation mentioned above.
However, if the rationale behind that recommendation is to use secret
addresses, I note that no published address can be kept secret.  If
one automates that stuff, sorting reports by type will take a fraction
of the effort required for verifying them.

In case separation is needed inside a single domain, I'm not sure
whether it is better to look up a single record for all types, or have
different records for each type.  That is, for example,

   "rf=ARF; r=[email-masked]; r.dkim=[email-masked];"

versus

   _dkim._report.example.com

Is such functionality needed?

>>(Either way, it doesn't sound at all like a CURRENT practice to add

They are not yet current.  (2) and (4) need to be defined, otherwise
people will have to resort to RFC 2142's abuse@.  I think they can be
defined by this WG, one way or the other.

Apologies for a longer-than-planned message

-- 
BTW: I've split the FBL wikipedia page, according to what Steve
suggested back in November 2008:
http://en.wikipedia.org/wiki/Abuse_Reporting_Format
http://en.wikipedia.org/wiki/Feedback_loop_%28email%29