Subject: Re: [feedback-report] "reality" check, was Revised draft charter
From: Todd Herr <[email-masked]>
To: [email-masked]
Date: Wed, 30 Sep 2009 17:09:01 -0400
List-Id: Public forum for discussion on the feedback-report draft <abuse-feedback-report.mipassoc.org>

On Wed, Sep 30, 2009 at 04:43:12PM -0400, John R. Levine wrote:
>> The abuse@ option fails in many cases because there are many working
>> Abuse desks that reject and/or discard any message containing attachments,
>> or at least pre-process their inbound Abuse stream so as to remove any
>> attachments from the message;
>
> That used to happen a lot, but I haven't seen much of it lately other 
> than at Microsoft itself.  In any event, I'm not sure that it's a good 
> long term plan to design around short term bugs in abuse desk software.

I always got the impression that the bugs were in the wetware, not the
software.  That said, I've had experiences within the past couple of
years with Abuse desks telling me that they don't accept attachments.

>
>> but even if all producers produced reports that were identical in
>> format and content, there'd still be value to the FBL/ARF consumer to
>> have separate inbound streams for different reporting agencies, simply
>> for counting purposes.
>
> What's wrong with counting the From: addresses?  Every FBL I've seen has 
> a very consistent return address.

I don't believe Occam ever existed, and so I always look for the
most complex solution to a problem.

-- 
Todd Herr
Principal Engineer and Postmaster              V: 703.345.2447
Road Runner Email Operations                   M: 571.287.0366
[email-masked]                        AIM: RRMailToddHerr

Date: 30 Sep 2009 16:43:12 -0400
From: "John R. Levine" <[email-masked]>
To: "Todd Herr" <[email-masked]>
Cleverness: None detected
Cc: [email-masked]
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

> The abuse@ option fails in many cases because there are many working
> Abuse desks that reject and/or discard any message containing attachments,
> or at least pre-process their inbound Abuse stream so as to remove any
> attachments from the message;

That used to happen a lot, but I haven't seen much of it lately other than 
at Microsoft itself.  In any event, I'm not sure that it's a good long 
term plan to design around short term bugs in abuse desk software.

> but even if all producers produced reports that were identical in
> format and content, there'd still be value to the FBL/ARF consumer to
> have separate inbound streams for different reporting agencies, simply
> for counting purposes.

What's wrong with counting the From: addresses?  Every FBL I've seen has a 
very consistent return address.

R's,
John

Date: Wed, 30 Sep 2009 13:57:29 -0400
From: Todd Herr <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

On Wed, Sep 30, 2009 at 09:56:06AM -0700, Murray S. Kucherawy wrote:
> > John R. Levine <[email-masked]> wrote:
> > 
> > > It would be technically possible to define something analogous to an
> > MX to
> > > invite abuse reports, but I have seen nothing to suggest that there
> > is any
> > > demand for such a thing.
> > 
> > Perhaps an organization might want to publish such records in order to
> > claim that they "care"... never mind that, behind the scenes, the
> > reports are blackholed upon receipt, possibly with an autoreply.  Given
> > the past behavior by certain major ISPs/carriers regarding spam
> > reports,
> > this would not surprise me at all.
> 
> I should point out that this is pretty similar to something mentioned 
> in the proposed charter for an ARF working group, and that's predicated 
> on past discussions at MAAWG (at least) where some FBL participant was 
> interested in advertising specifically this kind of information.  One 
> would think, then, that standardizing such a concept would be a Good 
> Thing(tm).
> 
> On the other hand, the group could decide through consensus that ARF 
> could just say "use the current standard abuse address, [email-masked], 
> for sending ARF reports", and that would probably be just fine as well to 
> tie up that loose end.

I'm not sure, based on what I've seen so far in both producing and
consuming FBL reports, that either approach will work here.

The abuse@ option fails in many cases because there are many working
Abuse desks that reject and/or discard any message containing attachments,
or at least pre-process their inbound Abuse stream so as to remove any
attachments from the message; I gather this is done as a defense
mechanism to prevent infections/compromises of Windows-based desktops
being used by Abuse desk staff.  Since ARF defines a message with
several attachments, absent rules in place on the abuse@ mailbox to
allow attachments from $KNOWN_FBL_PRODUCER_ADDRESSES, sending ARF to 
abuse@ will not have the intended result in all cases.

As for the MX-analogous solution, that's a better path, I believe, but 
there are many FBL consumers that seem to like to specify a different 
inbound FBL address for each FBL producer to which they're subscribing.  
This can be useful now for rules-based processing of the reports, since 
each producer has slight variances in the content of their reports 
(subject lines, actual content in the message/feedback-report content type 
sections, owing to the "Optional Fields..." sections in the drafts), 
but even if all producers produced reports that were identical in 
format and content, there'd still be value to the FBL/ARF consumer to 
have separate inbound streams for different reporting agencies, simply 
for counting purposes.  Such separation of streams can allow the consumer 
to know quickly if a change in complaint rates is localized to one domain 
or is happening across the board.

(And I suppose if the MX-analog solution were pursued, then it'd be about
five minutes till the address is harvested and spammed, and with properly
formatted ARF messages, even, but that's another bridge to cross....)

-- 
Todd Herr
Principal Engineer and Postmaster              V: 703.345.2447
Road Runner Email Operations                   M: 571.287.0366
[email-masked]                        AIM: RRMailToddHerr

From: "Murray S. Kucherawy" <[email-masked]>
To: Douglas Otis <[email-masked]>, "John R. Levine" <[email-masked]>
Date: Wed, 30 Sep 2009 11:27:40 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

> -----Original Message-----
> From: [email-masked] [mailto:abuse-
> [email-masked]] On Behalf Of Douglas Otis
> Sent: Wednesday, September 30, 2009 11:09 AM
> To: John R. Levine
> Cc: ARF mailing list
> Subject: Re: [feedback-report] "reality" check, was Revised draft
> charter
> 
> RFC5321 still states in section 4.1.1.4:
> ,---
> In sending a positive "250 OK" completion reply to the end of data
> indication, the receiver takes full responsibility for the message (see
> Section 6.1).  Errors that are diagnosed subsequently MUST be reported
> in a mail message,as discussed in Section 4.4.
> '---
> 
> What is being suggested with respect to ARF reporting is that those who
> act upon ARF reports take full responsibility for the accuracy of the
> information employed when disabling or removing email accounts.  Since
> ARF reports are often received from third-parties, it is important that
> source accuracy be continuously evaluated.  This evaluation might
> involve the visual examination of statistically significant samplings.
> Humans are better than computers at resolving Turing like problems.
> 
> > But, really, it's not our job to tell people how to do that, because
> > we don't know.
> 
> As RFC5321 demonstrates, an RFC can clearly define _who_ is responsible
> within the protocol.  The ARF draft should make it clear that the
> entity
> acting upon an ARF report takes responsibility for the accuracy of the
> information being relied upon.

How would one be able to demonstrate a positive assertion of this nature by a receiver?  That an ARF went into an SMTP server, with "abuse@..." in the envelope recipient, and a "250" was produced in response is unlikely to be successfully asserted as the ARF processing software accepted responsibility for validation of its content.

Is section 6.2 of the current draft not sufficient to cover all of this?

Date: Wed, 30 Sep 2009 11:08:55 -0700
From: Douglas Otis <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

On 9/29/09 6:52 PM, John R. Levine wrote:
>> Not at all.  Indeed, the generation of feedback is often fully
>> automated. However, use of information obtained from a complex,
>> albeit automated process, should include safeguards against
>> third-party error.
>
> Well, of course. But I think you will look in vain for any IETF
> standard that includes useful advice about how not to be stupid.

Deflecting responsibility for potentially damaging actions remains a
concern in third-party reporting schemes.  There could be SLAs that
ensure those making errors remain responsible as a means to control
the number of errors.  Nevertheless, counting reports is not enough,
especially in a multilingual world where auto-responses in foreign
languages are often mistaken for spam.  Perhaps there should be a
convention something like having all auto-generated responses be
contained within a mime type like Multipart/Report that was intended for
mail system administrative messages (RFC 5337).

> Manual inspection is one possibility, but hardly the only one. It is
> my strong impression that large FBL consumers use statistical
> techniques to figure out what's plausible, because the volume is far
> too great to manage manually.

No doubt this is how many want ARF to operate. Nevertheless, safeguards
of some form remain important.  Use of statistics is fine for deciding
what represents an adequate sampling. It would be wrong to expect
statistics will determine the exploit being used at the expense of
purported source email-address, or whether the related account has been
compromised.  While many techniques help identify the source of a
problem (this could have been made better by ensuring the capture of
source IP addresses for IP address based validations), none of these
schemes are without error nor never exploited.

Antagonists being defended against are human, and not machines.  Those
depending upon ARF must ensure the accuracy of their approach, where
often this requires visual inspection to ascertain whether mistakes are
occurring.

RFC5321 still states in section 4.1.1.4:
,---
In sending a positive "250 OK" completion reply to the end of data
indication, the receiver takes full responsibility for the message (see
Section 6.1).  Errors that are diagnosed subsequently MUST be reported
in a mail message,as discussed in Section 4.4.
'---

What is being suggested with respect to ARF reporting is that those who
act upon ARF reports take full responsibility for the accuracy of the
information employed when disabling or removing email accounts.  Since
ARF reports are often received from third-parties, it is important that
source accuracy be continuously evaluated.  This evaluation might
involve the visual examination of statistically significant samplings.
Humans are better than computers at resolving Turing like problems.

> But, really, it's not our job to tell people how to do that, because
> we don't know.

As RFC5321 demonstrates, an RFC can clearly define _who_ is responsible
within the protocol.  The ARF draft should make it clear that the entity
acting upon an ARF report takes responsibility for the accuracy of the
information being relied upon.

-Doug

From: "Murray S. Kucherawy" <[email-masked]>
To: Douglas Otis <[email-masked]>
Date: Wed, 30 Sep 2009 10:48:38 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

> -----Original Message-----
> From: Douglas Otis [mailto:[email-masked]]
> Sent: Thursday, September 24, 2009 3:33 PM
> To: Murray S. Kucherawy
> Cc: Steve Atkins; ARF mailing list
> Subject: Re: [feedback-report] Revised draft charter, call for
> participation -- Please comment
> 
> The concern was not about how to deal with DSNs where recipients of a
> DSN (such as a mailing list) can confirm it was in response to their
> message.  There are immediate methods to ensure against DSN spoofing,
> while there is also little incentive to send spoofed DSNs to some third
> party, which could be why this is not a problem. Again, the concern was
> about altering accounts based upon ARF reports when the nature of the
> message had not been visually verified.

How does an MLM definitively confirm that a DSN was sent in response to a message that actually passed through it?

If both are automated and neither are cryptographically signed, then both can be spoofed to think a user did something he/she didn't do.  In the case of an MLM responding to a fake DSN, this could result in unwarranted suspension or removal from a list; in the case of an abuse desk responding to a faked ARF message, this could result in other unwarranted corrective action taken on a user.

Perhaps FBL users can help one way or the other: Are automated responses to ARF severe, or mostly a matter of record-keeping?  My impressions are that:

a) The volume of ARFs received in an FBL are so large that a reasonable sampling isn't practical; and

b) To mitigate the fact that ARFs could be forged, the severity of response to ARFs is constrained to notification and record-keeping, with only large counts drawing human attention.

> > So, I have to disagree.
> 
> Are you saying that ARF reports should _not_ be visually reviewed
> because mailing list automatically react to DSNs?  Do you really think
> these two mechanisms are directly comparable?

I'm saying making an impractical recommendation detracts from the credibility of the work this group will produce.

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 30 Sep 2009 13:28:37 -0400
To: "Murray S. Kucherawy" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

On Wed, Sep 30, 2009 at 12:53 PM, Murray S. Kucherawy <[email-masked]> wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:abuse-
>> [email-masked]] On Behalf Of Steve Atkins
>> Sent: Tuesday, September 29, 2009 7:40 PM
>> To: ARF mailing list
>> Subject: Re: [feedback-report] "reality" check, was Revised draft
>> charter
>>
>> >> Well, of course.  But I think you will look in vain for any IETF
>> >> standard
>> >> that includes useful advice about how not to be stupid.
>> >>
>> >
>> > But it might be a good idea to have a separate draft with operational
>> > experience related to ARF so people are less likely to do stupid
>> > things.
>>
>> The (sole) value of ARF is to provide easy interoperability at the
>> transport
>> layer, and that's the sort of thing the IETF is good at.
>>
>> "Not being stupid" at the political layer is something that's likely to
>> be defined mostly by agreements between consenting parties who are
>> using ARF. It's something that's mostly orthogonal to the protocol
>> level work on ARF, and it may be something that's better
>> left to those who are actually producing or consuming feedback loops
>> - either through their contracts with each other or through an
>> organization like MAAWG that's a bit higher up the protocol stack
>> than the IETF.
>
> The IETF has produced BCP RFCs in the past.  For example, several of the documents the DKIM WG produced are information and provide guidance about implementation rather than protocol specification.
>
> An ARF WG could take that on as a task after its initial deliverables are completed.
>

The Spam OPS RFC comes to mind.

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Wed, 30 Sep 2009 10:27:35 -0700
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

On Sep 30, 2009, at 5:48 AM, John R. Levine wrote:
>
>
> ARF is quite successful as it is, and it's worth standardizing what  
> people
> actually use.  That's how normal standards organizations work.

+1

Cheers,
   Steve

From: "Murray S. Kucherawy" <[email-masked]>
To: Dave Aronson <[email-masked]>, ARF mailing list <[email-masked]>
Date: Wed, 30 Sep 2009 09:56:06 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

> -----Original Message-----
> From: [email-masked] [mailto:abuse-
> [email-masked]] On Behalf Of Dave Aronson
> Sent: Wednesday, September 30, 2009 7:11 AM
> To: ARF mailing list
> Subject: Re: [feedback-report] "reality" check, was Revised draft
> charter
> 
> John R. Levine <[email-masked]> wrote:
> 
> > It would be technically possible to define something analogous to an
> MX to
> > invite abuse reports, but I have seen nothing to suggest that there
> is any
> > demand for such a thing.
> 
> Perhaps an organization might want to publish such records in order to
> claim that they "care"... never mind that, behind the scenes, the
> reports are blackholed upon receipt, possibly with an autoreply.  Given
> the past behavior by certain major ISPs/carriers regarding spam
> reports,
> this would not surprise me at all.

I should point out that this is pretty similar to something mentioned in the proposed charter for an ARF working group, and that's predicated on past discussions at MAAWG (at least) where some FBL participant was interested in advertising specifically this kind of information.  One would think, then, that standardizing such a concept would be a Good Thing(tm).

On the other hand, the group could decide through consensus that ARF could just say "use the current standard abuse address, [email-masked], for sending ARF reports", and that would probably be just fine as well to tie up that loose end.

From: "Murray S. Kucherawy" <[email-masked]>
To: Steve Atkins <[email-masked]>, ARF mailing list <[email-masked]>
Date: Wed, 30 Sep 2009 09:53:23 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

> -----Original Message-----
> From: [email-masked] [mailto:abuse-
> [email-masked]] On Behalf Of Steve Atkins
> Sent: Tuesday, September 29, 2009 7:40 PM
> To: ARF mailing list
> Subject: Re: [feedback-report] "reality" check, was Revised draft
> charter
> 
> >> Well, of course.  But I think you will look in vain for any IETF
> >> standard
> >> that includes useful advice about how not to be stupid.
> >>
> >
> > But it might be a good idea to have a separate draft with operational
> > experience related to ARF so people are less likely to do stupid
> > things.
> 
> The (sole) value of ARF is to provide easy interoperability at the
> transport
> layer, and that's the sort of thing the IETF is good at.
> 
> "Not being stupid" at the political layer is something that's likely to
> be defined mostly by agreements between consenting parties who are
> using ARF. It's something that's mostly orthogonal to the protocol
> level work on ARF, and it may be something that's better
> left to those who are actually producing or consuming feedback loops
> - either through their contracts with each other or through an
> organization like MAAWG that's a bit higher up the protocol stack
> than the IETF.

The IETF has produced BCP RFCs in the past.  For example, several of the documents the DKIM WG produced are information and provide guidance about implementation rather than protocol specification.

An ARF WG could take that on as a task after its initial deliverables are completed.

Date: Wed, 30 Sep 2009 11:17:52 -0600
From: "J.D. Falk" <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

John R. Levine wrote:

> ARF is quite successful as it is, and it's worth standardizing what people
> actually use.

+1

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Date: Wed, 30 Sep 2009 10:10:54 -0400
From: Dave Aronson <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

John R. Levine <[email-masked]> wrote:

> It would be technically possible to define something analogous to an MX to
> invite abuse reports, but I have seen nothing to suggest that there is any
> demand for such a thing.

Perhaps an organization might want to publish such records in order to 
claim that they "care"... never mind that, behind the scenes, the 
reports are blackholed upon receipt, possibly with an autoreply.  Given 
the past behavior by certain major ISPs/carriers regarding spam reports, 
this would not surprise me at all.

-Dave

-- 
Dave Aronson, software engineer or trainer for hire.
Looking for job (or contract) in Washington DC area.
See http://davearonson.com/ for resume & other info.

Date: 30 Sep 2009 08:48:12 -0400
From: "John R. Levine" <[email-masked]>
To: "Alessandro Vesely" <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

> SMTP, for example, is structured as two loosely coordinated
> documents, one for the format and the other for the dynamics of
> exchanging the relevant data. Obviously, it cannot mandate who and
> why would send what message to whom...

Hmmn.  I gather you are not familiar with RFCs 2821 and 5321, since 
section 5 of each is about exactly that topic.  Domains invite SMTP 
traffic by publishing MX records.

It would be technically possible to define something analogous to an MX to 
invite abuse reports, but I have seen nothing to suggest that there is any 
demand for such a thing.  It wouldn't be straightforward due to the 
messiness of publishing data related to IP addresses and to subdomains, 
and there's no point in spending effort on yet another unused standard.

ARF is quite successful as it is, and it's worth standardizing what people 
actually use.  That's how normal standards organizations work.

R's,
John

Date: Wed, 30 Sep 2009 09:52:52 +0200
From: Alessandro Vesely <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

Steve Atkins wrote:
> On Sep 29, 2009, at 7:06 PM, Yakov Shafranovich wrote:
>> But it might be a good idea to have a separate draft with operational
>> experience related to ARF so people are less likely to do stupid 
>> things.
>
> The (sole) value of ARF is to provide easy interoperability at the  
> transport layer, and that's the sort of thing the IETF is good at.

SMTP, for example, is structured as two loosely coordinated 
documents, one for the format and the other for the dynamics of 
exchanging the relevant data. Obviously, it cannot mandate who and 
why would send what message to whom...

For ARF, by parallel reasoning, we would mention how an abuse report 
is originally submitted and what mechanisms allow it to reach its 
consumers. It may additional inform about where political 
settlements may affect sensible concerns.

> "Not being stupid" at the political layer is something that's likely to
> be defined mostly by agreements between consenting parties who are 
> using ARF. It's something that's mostly orthogonal to the protocol 
> level work on ARF, and it may be something that's better 
> left to those who are actually producing or consuming feedback loops 
> - either through their contracts with each other or through an 
> organization like MAAWG that's a bit higher up the protocol stack 
> than the IETF.

The political, orthogonal, part would then include any reaction that 
  an operator may take based on abuse reports. I agree this is at a 
different level and not quite standardizable.

Date: Wed, 30 Sep 2009 09:52:25 +0200
From: Alessandro Vesely <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

John R. Levine wrote:
> I think it's safe to say that the vast majority of FBL traffic currently 
> flows via bilateral agreements.

Hm... one possibility is to define FBL in that way. That would 
neatly distinguish it from, e.g., Abusix's "global reporting", 
although both may use ARF.

> Again, you need to familiarize yourself with what's already going on.

Although I've read a fair amount of docs, I never even found a 
definition of FBL (except the one on wikipedia, that I had to write 
myself.)

>> In addition, unless they share more than the FBL proper, they would
>> not offer the compensation of accepting rather than blocking senders 
>> based on the complaint ratio they rouse.
>
> Nobody promises to whitelist FBL recipients.

Although it could be done, the alternative to block senders whose 
complaint ratio exceeds a given threshold is still a means for 
compensation.

> Again, you need to familiarize yourself with what's already going on.

Any pointer to technical documentation I'm likely missing, please?

>> Yet, such standard has to be published before it can be enforced.
> 
> Um, billions of ARF messages are successfully exchanged every day. 
> Nobody "enforces" IETF standards.

That may be the reason why much confusion would result from the 
introduction of new ways to exchange those messages. And I presume 
that's the reason for proposing this WG.

> Again, you need to familiarize yourself with what's already going on.

Thinking thrice, if FBL delivery is destined to remain an obscure 
mechanism provided as-is for a few large operators only, then maybe 
I don't need to :-/

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Tue, 29 Sep 2009 19:39:35 -0700
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

On Sep 29, 2009, at 7:06 PM, Yakov Shafranovich wrote:

> On Tue, Sep 29, 2009 at 9:52 PM, John R. Levine <[email-masked]>  
> wrote:
>>> Not at all.  Indeed, the generation of feedback is often fully  
>>> automated.
>>> However, use of information obtained from a complex, albeit  
>>> automated
>>> process, should include safeguards against third-party error.
>>
>> Well, of course.  But I think you will look in vain for any IETF  
>> standard
>> that includes useful advice about how not to be stupid.
>>
>
> But it might be a good idea to have a separate draft with operational
> experience related to ARF so people are less likely to do stupid
> things.

The (sole) value of ARF is to provide easy interoperability at the  
transport
layer, and that's the sort of thing the IETF is good at.

"Not being stupid" at the political layer is something that's likely to
be defined mostly by agreements between consenting parties who are
using ARF. It's something that's mostly orthogonal to the protocol
level work on ARF, and it may be something that's better
left to those who are actually producing or consuming feedback loops
- either through their contracts with each other or through an
organization like MAAWG that's a bit higher up the protocol stack
than the IETF.

Cheers,
   Steve

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 29 Sep 2009 22:06:26 -0400
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

On Tue, Sep 29, 2009 at 9:52 PM, John R. Levine <[email-masked]> wrote:
>> Not at all.  Indeed, the generation of feedback is often fully automated.
>> However, use of information obtained from a complex, albeit automated
>> process, should include safeguards against third-party error.
>
> Well, of course.  But I think you will look in vain for any IETF standard
> that includes useful advice about how not to be stupid.
>

But it might be a good idea to have a separate draft with operational
experience related to ARF so people are less likely to do stupid
things.

Yakov

Date: 29 Sep 2009 21:52:40 -0400
From: "John R. Levine" <[email-masked]>
To: "Douglas Otis" <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

> Not at all.  Indeed, the generation of feedback is often fully automated. 
> However, use of information obtained from a complex, albeit automated 
> process, should include safeguards against third-party error.

Well, of course.  But I think you will look in vain for any IETF standard 
that includes useful advice about how not to be stupid.

Manual inspection is one possibility, but hardly the only one.  It is my 
strong impression that large FBL consumers use statistical techniques to 
figure out what's plausible, because the volume is far too great to manage 
manually.  But, really, it's not our job to tell people how to do that, 
because we don't know.

R's,
John

To: ARF mailing list <[email-masked]>
From: [email-masked]
Date: Tue, 29 Sep 2009 20:52:28 -0400
Subject: Re: [feedback-report] "reality" check, was Revised draft  charter

On Tue, 29 Sep 2009 17:30:46 -0700 Douglas Otis <[email-masked]> 
wrote:
>On 9/29/09 3:11 PM, John R. Levine wrote:
>>> The draft should temper expectations that ARF allows the creation of a
>>> fully automated administrative scheme.
>>
>> Are you claiming that the existing automated FBLs don't exist?
>
>Not at all.  Indeed, the generation of feedback is often fully 
>automated.  However, use of information obtained from a complex, albeit 
>automated process, should include safeguards against third-party error.
>
>IMHO, visual inspection, even on a sampling basis, is important.  This 
>is about human communications and not something simple.  Visual 
>inspection provides a way to discover many of the games played by bad 
>actors, and a way to protect innocent users from loss of their accounts. 
>  What harm is there in saying a provider should take responsibility for 
>their actions.  A responsible provider should visually confirm 
>information before acting upon an automated categorization of email 
>messages performed by a third-party?  This would not require all 
>messages be checked in any specific case.

What sampling rate would you recommend be required?

Scott K

Date: Tue, 29 Sep 2009 17:30:46 -0700
From: Douglas Otis <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

On 9/29/09 3:11 PM, John R. Levine wrote:
>> The draft should temper expectations that ARF allows the creation of a
>> fully automated administrative scheme.
>
> Are you claiming that the existing automated FBLs don't exist?

Not at all.  Indeed, the generation of feedback is often fully 
automated.  However, use of information obtained from a complex, albeit 
automated process, should include safeguards against third-party error.

IMHO, visual inspection, even on a sampling basis, is important.  This 
is about human communications and not something simple.  Visual 
inspection provides a way to discover many of the games played by bad 
actors, and a way to protect innocent users from loss of their accounts. 
  What harm is there in saying a provider should take responsibility for 
their actions.  A responsible provider should visually confirm 
information before acting upon an automated categorization of email 
messages performed by a third-party?  This would not require all 
messages be checked in any specific case.

-Doug

Date: 29 Sep 2009 18:11:16 -0400
From: "John R. Levine" <[email-masked]>
To: "Douglas Otis" <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

> The draft should temper expectations that ARF allows the creation of a
> fully automated administrative scheme.

Are you claiming that the existing automated FBLs don't exist?

R's,
John

Date: Tue, 29 Sep 2009 14:49:51 -0700
From: Douglas Otis <[email-masked]>
To: "J.D. Falk" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

On 9/29/09 10:22 AM, J.D. Falk wrote:
> Douglas Otis wrote:
>
>> Limiting category selections would fine. However, the concern regarding
>> the proper categorization of a message remains a concern, even when
>> limited to messages being categorized as spam/abusive or not. Here
>> auto-responses in foreign languages being marked as spam are one example
>> of a common mistake.
>
> That all depends on whether you believe that every complaint will be treated
> as Ultimate Truth by report recipients.  Thus far, there's no evidence to
> support that belief.
>
> Is it actually necessary to explicitly state that the report recipient is
> allowed to decide for themselves whether or not to take action on any single
> report, and allowed to decide for themselves what that action will be?

The draft should temper expectations that ARF allows the creation of a 
fully automated administrative scheme.  It remains important, especially 
when little is known about how ARF information might be used or misused, 
to also mention a need for human overview of the process where messages 
receive visual examination.

When dealing with information from some third-party's automated script, 
the draft should stress that the onus of determining the validity of 
information is with the receiver.  This point can be strengthened with a 
statement that the system's integrity can be improved through visual 
examination of automated results.  Scripts and processes often make 
mistakes, where conclusions should not be based solely upon ARF report 
counts.  Adequate inspection will not require every message be viewed, 
only that enough are sampled and reviewed for each case.

-Doug

Date: 29 Sep 2009 17:30:22 -0400
From: "John R. Levine" <[email-masked]>
To: "Alessandro Vesely" <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

>> If you're so small that a recipient may receive just one report from
>> you, then there's no mechanical way to distinguish whether that's
>> signal or that's noise.
>
> I thought a single complaint was enough for unsubscribing a user.

Usually, although as I'm sure others will tell you, opinions vary, 
particularly if a list has a history of false positives.  I get AOL spam 
reports all the time for one particular non-technical list and although my 
system unsubs them all, I suspect the majority are mistakes.

>> One obvious thing would be for you and a bunch of other tiny
>> mailbox providers to gang together to offer a FBL large enough
>> that the data may be relevant.
>
> A rather difficult task, since mailbox providers, unlike network
> providers, don't need prior arrangements among one another in order to
> operate. (Such was the goal of SMTP.)

I think it's safe to say that the vast majority of FBL traffic currently 
flows via bilateral agreements.  Again, you need to familiarize yourself 
with what's already going on.

> In addition, unless they share more than the FBL proper, they would
> not offer the compensation of accepting rather than blocking senders
> based on the complaint ratio they rouse.

Nobody promises to whitelist FBL recipients.  Again, you need to 
familiarize yourself with what's already going on.

> Yet, such standard has to be published before it can be enforced.

Um, billions of ARF messages are successfully exchanged every day. 
Nobody "enforces" IETF standards.  Again, you need to familiarize yourself 
with what's already going on.

R's,
John

Date: Tue, 29 Sep 2009 11:24:47 -0600
From: "J.D. Falk" <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

Alessandro Vesely wrote:

> I thought a single complaint was enough for unsubscribing a user.

That's an implementation decision, not a requirement imposed by the Abuse 
Reporting Format that we are discussing here.

> In rare cases I send hand written reports. Normally I hit delete, as
> that's the only button I have. If report-spam buttons result in a
> better effect, it would seem unfair to restrict their usage.

Any such restriction would also be an implementation decision, and not a 
requirement imposed by the format.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Date: Tue, 29 Sep 2009 11:22:53 -0600
From: "J.D. Falk" <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] "reality" check, was Revised draft charter

Douglas Otis wrote:

> Limiting category selections would fine. However, the concern regarding
> the proper categorization of a message remains a concern, even when
> limited to messages being categorized as spam/abusive or not. Here
> auto-responses in foreign languages being marked as spam are one example
> of a common mistake.

That all depends on whether you believe that every complaint will be treated 
as Ultimate Truth by report recipients.  Thus far, there's no evidence to 
support that belief.

Is it actually necessary to explicitly state that the report recipient is 
allowed to decide for themselves whether or not to take action on any single 
report, and allowed to decide for themselves what that action will be?

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Date: Tue, 29 Sep 2009 18:15:25 +0200
From: Alessandro Vesely <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

Steve Atkins wrote:
>> The other way around, what is the number of FBLs that a new mail site 
>> should subscribe to, if every other mail site already has one?
>
> I think what you're saying is that you don't believe you're a source 
> of enough data or valuable enough data that anyone else is 
> going to be interested in it.

Exactly!

> I think you're right.
>
> One of the big advantages of FBLs from large ISPs is that they 
> provide a volume of data that is high enough that you can derive 
> signal out of the noise.
>
> If you're so small that a recipient may receive just one report from 
> you, then there's no mechanical way to distinguish whether that's 
> signal or that's noise.

I thought a single complaint was enough for unsubscribing a user.

> One obvious thing would be for you and a bunch of other tiny 
> mailbox providers to gang together to offer a FBL large enough 
> that the data may be relevant.

A rather difficult task, since mailbox providers, unlike network 
providers, don't need prior arrangements among one another in order to 
operate. (Such was the goal of SMTP.)

In addition, unless they share more than the FBL proper, they would 
not offer the compensation of accepting rather than blocking senders 
based on the complaint ratio they rouse.

> That leads to the other problem, though. With existing FBLs it's 
> usually very, very well-defined what a report means and what 
> action is expected by the recipient of the report.
>
> Unless your co-operative of tiny ISPs were to enforce identical 
> standards across all your members you'd end up with the situation 
> where it wasn't clear what any particular report meant, meaning 
> they'll likely not have much attention paid to them, as it'll be 
> impossible to mechanically pull any signal out of the noise.

Yet, such standard has to be published before it can be enforced.

> Unless you think you can manage and enforce that sort of a setup 
> then you're best not providing a FBL and simply sending hand 
> written reports.

In rare cases I send hand written reports. Normally I hit delete, as 
that's the only button I have. If report-spam buttons result in a 
better effect, it would seem unfair to restrict their usage.

> Note also that any situation where you have ISPs sending unsolicited 
> reports directly to senders, without any sort of agreement in place, 
> is going to lead to the same sort of data consistency problems as 
> a badly run co-op. Lots of noise, hard to identify any signal.

I agree that's a problem. Also add the trust and privacy concerns, 
that can be formally avoided with FBL agreements.

Date: Tue, 29 Sep 2009 08:57:04 +0200
From: Alessandro Vesely <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

Douglas Otis wrote:
> It would be careless to expect ARF reports represent a solution allowing 
> complete automation of abusive account identification.  Such an 
> assumption runs the risk of the ARF process being used as a vehicle to 
> cause individual's the loss of their email access.  Only visual review 
> can help guard against most egregious automation mistakes.

The only case I recall --from discussions-- of unauthenticated 
abusive messages deserving some sort of treatment is dropboxes, that 
may deserve being monitored for phishing responses. A very different 
treatment than counting abuses for the sake of eventual 
administrative actions.

Date: Mon, 28 Sep 2009 17:02:24 -0700
From: Douglas Otis <[email-masked]>
To: "J.D. Falk" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

On 9/28/09 4:04 PM, J.D. Falk wrote:
> Douglas Otis wrote:
>
>> It should be stated as a good practice for providers receiving ARF
>> reports, to visually review on a sampling basis, the messages contained
>> to confirm an ARF generator's proper message categorizations.
>
> Except for a few test environments, I'm not aware of any ARF generator using
> a Feedback-Type other than "abuse".  This is why I proposed removing most of
> the other types.
>
> I'll make that proposal again once we've got a working group.

J.D.

Limiting category selections would fine.  However, the concern regarding 
the proper categorization of a message remains a concern, even when 
limited to messages being categorized as spam/abusive or not.  Here 
auto-responses in foreign languages being marked as spam are one example 
of a common mistake.

Spammers often use harvested email addresses in their spam's return 
address.  When this address represents a honey-pot, then determining 
which messages are auto-responses becomes important.  Often mistakes can 
be visually obvious, even when the language of the message is not 
understood.

Language recognition and translation tools are making this task easier, 
however support for some languages still remains limited.  In languages 
where support is good, recognition errors still represent several 
percentage points.  Message categorization has not reached a point of 
certainty that allows an assumption of categorization errors being so 
few as to be negligent, IMHO.

Strides are being made at improving this situation in our own product, 
with emphasis on several Asian and Middle Eastern languages. 
Nevertheless, spammers leverage any gray area in an automated process, 
where often no two messages are identical to thwart statistical 
analysis.  With vast computational resources at their disposal, spammers 
enjoy an advantage when it comes to automation.

-Doug

Date: Mon, 28 Sep 2009 17:04:41 -0600
From: "J.D. Falk" <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

Douglas Otis wrote:

> It should be stated as a good practice for providers receiving ARF
> reports, to visually review on a sampling basis, the messages contained
> to confirm an ARF generator's proper message categorizations.

Except for a few test environments, I'm not aware of any ARF generator using 
a Feedback-Type other than "abuse".  This is why I proposed removing most of 
the other types.

I'll make that proposal again once we've got a working group.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Date: Mon, 28 Sep 2009 14:55:28 -0700
From: Douglas Otis <[email-masked]>
To: "J.D. Falk" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

On 9/28/09 8:58 AM, J.D. Falk wrote:
> I'm not aware of any complaint feedback loop operating today in which a
> postmaster manually forwards complaints to all feedback subscribers.
> Instead, it's an automated process whereby approved subscribers receive
> complaints about messages originating from their own IP ranges, without any
> manual interaction.  Nearly all of these use ARF.

Since information generated by feedback systems represent an automated 
categorization of messages marked as abuse or spam, fraud or phish, 
virus or malware, opt-out, apart from non-spam, NDN, or auto-responses. 
There will be incorrect categorizations made.  Auto-responses are often 
mis-categorized, for example.

It should be stated as a good practice for providers receiving ARF 
reports, to visually review on a sampling basis, the messages contained 
to confirm an ARF generator's proper message categorizations.  Bad 
actors are continuously finding ways to evade categorizations, where 
counter measures might lead to a number of categorization errors. 
Ensuring prevalence of erroneous accusations of bad behavior remains 
low, would be reliant upon a provider's visual review of received ARF 
reports.

Full dependence upon message categorization filters without visual 
reviews lowers email's reliability.  This practice becomes important 
whenever accounts are disabled or removed based upon automated feedback. 
  ARF feedback can be wrong in what some might be considered more than a 
negligible number of cases.  After all, a categorization process is 
constantly evolving.

It would be careless to expect ARF reports represent a solution allowing 
complete automation of abusive account identification.  Such an 
assumption runs the risk of the ARF process being used as a vehicle to 
cause individual's the loss of their email access.  Only visual review 
can help guard against most egregious automation mistakes.

-Doug

Date: 28 Sep 2009 17:22:58 -0400
From: "John R. Levine" <[email-masked]>
To: "Alessandro Vesely" <[email-masked]>
Cleverness: None detected
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

>> Just for reference, have you ever used any of the existing MUA spam 
>> buttons?
>
> Never, as you probably already guessed.

It would really save us all a lot of wasted time if you would spend at 
least a few minutes finding out how things work now before making 
proposals that have no chance of ever being implemented.

>>  How many questions did it ask?
>
> If it asks no questions, how can it compile a "good" report? Who is going to 
> read the human readable part?

Anyone who is familiar with ARF already knows the answers to those 
questions, so there seems little reason to waste the list's time with 
them.

R's,
John

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Mon, 28 Sep 2009 12:19:32 -0700
Subject: Re: [feedback-report] reality check, was Revised draft charter

On Sep 28, 2009, at 11:51 AM, Alessandro Vesely wrote:
>
> How can you say there's no size problem? If I set up an FBL
> subscription page (either on my own or using a 3rd party as above) and
> then encourage my few users to submit abuse reports to me, what are
> the probabilities that an ISP responsible for the origin of the
> abusive message has happened to subscribe to the FBL of my tiny
> server? I'd guess ~0.0%.
>
> The other way around, what is the number of FBLs that a new mail site
> should subscribe to, if every other mail site already has one?

I think what you're saying is that you don't believe you're a source
of enough data or valuable enough data that anyone else is
going to be interested in it.

I think you're right.

One of the big advantages of FBLs from large ISPs is that they
provide a volume of data that is high enough that you can derive
signal out of the noise.

If you're so small that a recipient may receive just one report from
you, then there's no mechanical way to distinguish whether that's
signal or that's noise.

One obvious thing would be for you and a bunch of other tiny
mailbox providers to gang together to offer a FBL large enough
that the data may be relevant.

That leads to the other problem, though. With existing FBLs it's
usually very, very well-defined what a report means and what
action is expected by the recipient of the report.

Unless your co-operative of tiny ISPs were to enforce identical
standards across all your members you'd end up with the situation
where it wasn't clear what any particular report meant, meaning
they'll likely not have much attention paid to them, as it'll be
impossible to mechanically pull any signal out of the noise.

Unless you think you can manage and enforce that sort of a setup
then you're best not providing a FBL and simply sending hand
written reports.

Note also that any situation where you have ISPs sending unsolicited
reports directly to senders, without any sort of agreement in place,
is going to lead to the same sort of data consistency problems as
a badly run co-op. Lots of noise, hard to identify any signal.

Cheers,
   Steve

Date: Mon, 28 Sep 2009 20:51:31 +0200
From: Alessandro Vesely <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

IMHO, many of these infos on ARF's usage deserve being collected in 
some document. I thought they could go together with the address where 
ARF reports should be sent, as they are similar.

J.D. Falk wrote:
>> I should send [a manually composed] complaint to
>> abuse@(new ISP) but not use ARF in that case, correct?
> 
> The scenario you've described sounds more appropriate for a direct 
> conversation with the ISP, rather than an automated report via an automated 
> channel.  ARF was never intended to replace human-to-human interaction.

I'll take that as 'yes'. Thanks for confirming it.

>> Users send abuse reports to their postmasters. Abusive messages 
>> submitted within the same mail domain feed the bucket for (1). 
>> Otherwise, a postmaster might just forward the report to any FBL 
>> subscribers. This solution is apparently non-scalable, as only giant 
>> ISPs have FBLs.
>
> I'm not aware of any complaint feedback loop operating today in which a 
> postmaster manually forwards complaints to all feedback subscribers.

Nor I. I didn't mean _manually_ in that paragraph, except for users.

> It's true that the larger ISPs were faster to implement complaint feedback 
> systems, but that's due more to available resources than anything inherent 
> to size.
>
> I work on a product which handles this process for many ISPs:
>
> http://www.returnpath.net/internetserviceprovider/feedback/

How can you say there's no size problem? If I set up an FBL 
subscription page (either on my own or using a 3rd party as above) and 
then encourage my few users to submit abuse reports to me, what are 
the probabilities that an ISP responsible for the origin of the 
abusive message has happened to subscribe to the FBL of my tiny 
server? I'd guess ~0.0%.

The other way around, what is the number of FBLs that a new mail site 
should subscribe to, if every other mail site already has one?

Am I missing something?

> Please, Alessandro, let go of your preconceived notions of how abuse desks 
> could work and listen to what we're saying about how ARF is implemented. 
> It's not that complicated.

The only preconceived notion I have is that ARF should work for any 
SMTP server who wants to use it. I'm just trying to understand how.

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Mon, 28 Sep 2009 10:18:26 -0700
Subject: Re: [feedback-report] reality check, was Revised draft charter

On Sep 28, 2009, at 10:00 AM, Michael Adkins wrote:

> "I suggested that same idea years ago, but it didn't catch on. I'm not
> aware of any network provider with either huamn staff or automated
> systems which forward individual complaints (ARF or otherwise) to  
> their
> customers. Instead, a number of services have cropped up which will
> process ARF messages in order to provide aggregate reports on  
> potential
> problem areas."
>
> The only one I know of is Level 3, who request reports about their
> entire ip space and then forward them on the appropriate customer.

There are others. I know several Abacus users use it to automatically
forward reports (ARF and otherwise) on to some subset of their customers
(typically those that have demonstrated that they can handle the abuse
issues of their customers well) automatically.

And I occasionally get FBL reports about my (tiny) network space
forwarded on to me from my provider, apparently mechanically.

Works pretty well, as it allows the network provider to maintain stats
about issues at their customers with very little overhead, while  
allowing
those customers to handle their abuse issues themselves.

It's not something you can do for many ISP FBLs targeting bulk mailers,
though, as the contract you need to agree to while signing up for the
FBL tends to include terms that you cannot commit to unless you handle
all the reports yourself. That's a contractual problem, though, more  
than
an operational one, I suspect.

Cheers,
   Steve

Date: Mon, 28 Sep 2009 13:00:54 -0400
From: Michael Adkins <[email-masked]>
To: "J.D. Falk" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

"I suggested that same idea years ago, but it didn't catch on. I'm not
aware of any network provider with either huamn staff or automated
systems which forward individual complaints (ARF or otherwise) to their
customers. Instead, a number of services have cropped up which will
process ARF messages in order to provide aggregate reports on potential
problem areas."

The only one I know of is Level 3, who request reports about their
entire ip space and then forward them on the appropriate customer.

J.D. Falk wrote:
> Alessandro Vesely wrote:
>
>   
>> If I've got it right, I should never use ARF after carrying out any
>> investigation. For example, suppose I've found a link to a previous
>> conviction against the spam sender, that might convince their new
>> ISP to terminate their account: I should send that complaint to
>> abuse@(new ISP) but not use ARF in that case, correct?
>>     
>
> The scenario you've described sounds more appropriate for a direct 
> conversation with the ISP, rather than an automated report via an automated 
> channel.  ARF was never intended to replace human-to-human interaction.
>
>   
>> Users send abuse reports to their postmasters. Abusive messages
>> submitted within the same mail domain feed the bucket for (1).
>> Otherwise, a postmaster might just forward the report to any FBL
>> subscribers. This solution is apparently non-scalable, as only giant
>> ISPs have FBLs.
>>     
>
> I'm not aware of any complaint feedback loop operating today in which a 
> postmaster manually forwards complaints to all feedback subscribers. 
> Instead, it's an automated process whereby approved subscribers receive 
> complaints about messages originating from their own IP ranges, without any 
> manual interaction.  Nearly all of these use ARF.
>
> It's true that the larger ISPs were faster to implement complaint feedback 
> systems, but that's due more to available resources than anything inherent 
> to size.
>
> I work on a product which handles this process for many ISPs:
>
> http://www.returnpath.net/internetserviceprovider/feedback/
>
> (I mention this not to advertise the product, but rather as additional 
> insight into the current state of the industry.)
>
>   
>> Beyond FBLs, postmasters may forward reports to the relevant network
>> providers (NP). Abusix, for one, proposes first level RIR's
>> assignments as targets.
>>     
>
> Abusix's implementation decisions are fairly unique.
>
>   
>> That way (2) is possible. In order to make
>> (1) possible, we must presume that an NP forwards each report down
>> to further level assignments until it reaches the mailbox provider.
>>     
>
> I suggested that same idea years ago, but it didn't catch on.  I'm not aware 
> of any network provider with either huamn staff or automated systems which 
> forward individual complaints (ARF or otherwise) to their customers. 
> Instead, a number of services have cropped up which will process ARF 
> messages in order to provide aggregate reports on potential problem areas.
>
> Please, Alessandro, let go of your preconceived notions of how abuse desks 
> could work and listen to what we're saying about how ARF is implemented. 
> It's not that complicated.
>
>   

Date: Mon, 28 Sep 2009 09:58:05 -0600
From: "J.D. Falk" <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

Alessandro Vesely wrote:

> If I've got it right, I should never use ARF after carrying out any
> investigation. For example, suppose I've found a link to a previous
> conviction against the spam sender, that might convince their new
> ISP to terminate their account: I should send that complaint to
> abuse@(new ISP) but not use ARF in that case, correct?

The scenario you've described sounds more appropriate for a direct 
conversation with the ISP, rather than an automated report via an automated 
channel.  ARF was never intended to replace human-to-human interaction.

> Users send abuse reports to their postmasters. Abusive messages
> submitted within the same mail domain feed the bucket for (1).
> Otherwise, a postmaster might just forward the report to any FBL
> subscribers. This solution is apparently non-scalable, as only giant
> ISPs have FBLs.

I'm not aware of any complaint feedback loop operating today in which a 
postmaster manually forwards complaints to all feedback subscribers. 
Instead, it's an automated process whereby approved subscribers receive 
complaints about messages originating from their own IP ranges, without any 
manual interaction.  Nearly all of these use ARF.

It's true that the larger ISPs were faster to implement complaint feedback 
systems, but that's due more to available resources than anything inherent 
to size.

I work on a product which handles this process for many ISPs:

http://www.returnpath.net/internetserviceprovider/feedback/

(I mention this not to advertise the product, but rather as additional 
insight into the current state of the industry.)

> Beyond FBLs, postmasters may forward reports to the relevant network
> providers (NP). Abusix, for one, proposes first level RIR's
> assignments as targets.

Abusix's implementation decisions are fairly unique.

> That way (2) is possible. In order to make
> (1) possible, we must presume that an NP forwards each report down
> to further level assignments until it reaches the mailbox provider.

I suggested that same idea years ago, but it didn't catch on.  I'm not aware 
of any network provider with either huamn staff or automated systems which 
forward individual complaints (ARF or otherwise) to their customers. 
Instead, a number of services have cropped up which will process ARF 
messages in order to provide aggregate reports on potential problem areas.

Please, Alessandro, let go of your preconceived notions of how abuse desks 
could work and listen to what we're saying about how ARF is implemented. 
It's not that complicated.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Date: Mon, 28 Sep 2009 09:41:58 -0600
From: "J.D. Falk" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

Alessandro Vesely wrote:

> I would replace "ISPs" with the more specific "mailbox providers".

ARF is generated by (or on behalf of) mailbox providers, and then consumed 
by (or on behalf of) a fairly wide variety of email senders, including:

- fellow mailbox providers
- access providers ranging from dialup to backbones
- commercial senders
- non-commercial senders
- educational institutions
- hobbyists
- spammers (I'm not saying it's right, just saying it happens)

There are many millions of ARF messages transferred every day, and once 
we've got the WG started I'll propose editing the draft to indicate this. 
(I'll also get a more accurate estimate.)

> The user should be able to write or modify the human readable part
> of the report.  I envisage the MUA button as popping up a dialog
 > asking such questions as

Vanishingly few (if any) of the ARF messages transferred today include any 
text supplied by the end user who initiated the complaint.  Few ARF messages 
are processed by humans at any stage.

But more importantly, this list of questions doesn't seem appropriate for a 
standards project.  The developer of a particular tool may wish to include 
them, and that's fine -- every MUA is different -- but it isn't (and 
shouldn't be) required by an RFC.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Date: Sun, 27 Sep 2009 12:55:28 +0200
From: Alessandro Vesely <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

Steve Atkins wrote:
>> If [an interactive report-spam process] asks no questions, how can it compile a "good" report? 
>> Who is going to read the human readable part?
>
> People who wish to receive FBL reports, yet who don't receive
> a high enough volume for them to need to automate handling 
> them.

Does that imply that the human readable part of an ARF report should 
only consist of boilerplate text, much like MIME preambles?

>> Reports sent to abuse desks most often involve further interaction,
>
> I don't recall seeing such a thing more than a few times in years,
> and never in response to a "typical" abuse report and certainly 
> not in response to the sort of report that's intended to be handled
> mechanically, which is the target for ARF.

If I've got it right, I should never use ARF after carrying out any 
investigation. For example, suppose I've found a link to a previous 
conviction against the spam sender, that might convince their new 
ISP to terminate their account: I should send that complaint to 
abuse@(new ISP) but not use ARF in that case, correct?

Possibly, auto-responders for abuse mailboxes should only be fired 
on non-ARF messages. And ARF reports should have an empty MAIL FROM, 
and/or an "Auto-Submitted: auto-generated" header. The current draft 
doesn't make any such considerations.

> If the report doesn't include all the information needed to triage
> and handle it without further interaction with the reporter then 
> it's not a good candidate for automated report handling, and 
> not really relevant to ARF.

Fine. Even if that implies a one-way flow of information, and thus 
leaves little room for semi-automated cooperative processing, it 
seems consistent to me, now that you have explained it in deeper 
detail. Let me check I've got the picture correctly: Tentatively, 
abuse reports may eventually result in

0) dispute on whether the reported abusive message is really such,

1) administrative actions by the relevant mailbox provider, ranging 
from admonition to account termination,

2) similar actions by network providers (or registrars?) against the 
mailbox providers who failed to take the actions in (1),

3) blacklisting, or removal from whitelists, of the relevant IPs or 
registered domains,

4) possible legal actions.

Users send abuse reports to their postmasters. Abusive messages 
submitted within the same mail domain feed the bucket for (1). 
Otherwise, a postmaster might just forward the report to any FBL 
subscribers. This solution is apparently non-scalable, as only giant 
ISPs have FBLs.

Beyond FBLs, postmasters may forward reports to the relevant network 
providers (NP). Abusix, for one, proposes first level RIR's 
assignments as targets. That way (2) is possible. In order to make 
(1) possible, we must presume that an NP forwards each report down 
to further level assignments until it reaches the mailbox provider. 
Eager postmasters may do that themselves directly, but not blindly. 
In some circumstances, the report might be further forwarded to the 
original sender, to allow for (0). Each recipient can triage on its 
own, while forwarding single messages. That way, a reasonable 
timeliness can be obtained, while each downstream recipient can 
reckon the count accumulated by its sender, and guess when the next 
admonition is likely to occur; the current incidents count may also 
be written inside the report, for checking --that's not what the 
"Incidents" field is apparently for.

To avoid duplicates or failures, it should be clarified whether 
postmasters should send directly to multiple NPs rather than rely on 
each NP to forward in turn. IOW, whose behavior is better, Abusix or 
eager postmasters? Whether to send a report to the mail domain where 
the abusive message was submitted, or DKIM signed, may be decided 
using the same heuristics as for accepting FBL subscriptions. That 
may involve lengthy processes, such as requiring NP's approval by 
email, whose results deserve being cached. The "eager postmasters" 
approach resembles an FBL with auto-subscription.

Furthermore, if the abusive message had VBR credentials, the 
report's destinations should include the relevant vouching services, 
in addition to the network and mailbox providers: A future version 
of (3) --for a limited scope of (3), postmasters who maintain local 
black/whitelists may update them after users' reports.

(4) is obviously fully manual and hence out of ARF's scope, but ARF 
reports might be supplied as evidence.

Is the above correct? (I note that this one-way functioning is quite 
different from the cooperative model devised in INCH.)

What for errors or disputes? We should subtract 1 from all the 
involved counters in case of a message erroneously reported as spam.

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Sat, 26 Sep 2009 11:31:03 -0700
Subject: Re: [feedback-report] reality check, was Revised draft charter

On Sep 26, 2009, at 10:33 AM, Alessandro Vesely wrote:

> John R. Levine wrote:
>> On Sat, 26 Sep 2009, Alessandro Vesely wrote:
>>> The user should be able to write or modify the human readable part  
>>> of the
>>> report. I envisage the MUA button as popping up a dialog asking such
>>> questions as
>>>
>>> * Did the user manually examine the body of the message?
>>> * Does the user understand SMTP?
>>> * Does the user believe the From address is true?
>>> * Did the user examine the headers of the message?
>>> * Does the user believe the Return-Path, if any, is true?
>>
>> Just for reference, have you ever used any of the existing MUA spam
>> buttons?
>
> Never, as you probably already guessed.

Are you a recipient of a feedback loop of any sort? If so, how do you
handle and respond to inbound reports right now?

>
>> How many questions did it ask?
>
> If it asks no questions, how can it compile a "good" report? Who is
> going to read the human readable part?

People who wish to receive FBL reports, yet who don't receive
a high enough volume for them to need to automate handling
them.

>
> Reports sent to abuse desks most often involve further interaction,

I don't recall seeing such a thing more than a few times in years,
and never in response to a "typical" abuse report and certainly
not in response to the sort of report that's intended to be handled
mechanically, which is the target for ARF.

If the report doesn't include all the information needed to triage
and handle it without further interaction with the reporter then
it's not a good candidate for automated report handling, and
not really relevant to ARF.

> messages tagged with an incident number. Should that be directed to
> the user who originated the report? IOW, the user's mailbox provider
> forwards the message as a service done _on behalf_ of the user?

None of the above, in general.

Cheers,
   Steve

Date: Sat, 26 Sep 2009 19:33:06 +0200
From: Alessandro Vesely <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

John R. Levine wrote:
> On Sat, 26 Sep 2009, Alessandro Vesely wrote:
>> The user should be able to write or modify the human readable part of the 
>> report. I envisage the MUA button as popping up a dialog asking such 
>> questions as
>>
>> * Did the user manually examine the body of the message?
>> * Does the user understand SMTP?
>> * Does the user believe the From address is true?
>> * Did the user examine the headers of the message?
>> * Does the user believe the Return-Path, if any, is true?
> 
> Just for reference, have you ever used any of the existing MUA spam 
> buttons?

Never, as you probably already guessed.

>  How many questions did it ask?

If it asks no questions, how can it compile a "good" report? Who is 
going to read the human readable part?

Reports sent to abuse desks most often involve further interaction, 
messages tagged with an incident number. Should that be directed to 
the user who originated the report? IOW, the user's mailbox provider 
forwards the message as a service done _on behalf_ of the user?

Date: 26 Sep 2009 08:31:32 -0400
From: "John R. Levine" <[email-masked]>
To: "Alessandro Vesely" <[email-masked]>
Cleverness: None detected
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] reality check, was Revised draft charter

On Sat, 26 Sep 2009, Alessandro Vesely wrote:
> The user should be able to write or modify the human readable part of the 
> report. I envisage the MUA button as popping up a dialog asking such 
> questions as
>
> * Did the user manually examine the body of the message?
> * Does the user understand SMTP?
> * Does the user believe the From address is true?
> * Did the user examine the headers of the message?
> * Does the user believe the Return-Path, if any, is true?

Just for reference, have you ever used any of the existing MUA spam 
buttons?  How many questions did it ask?

R's,
John

Date: Sat, 26 Sep 2009 12:17:11 +0200
From: Alessandro Vesely <[email-masked]>
To: "John R. Levine" <[email-masked]>, "Murray S. Kucherawy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

John R. Levine wrote:
>> Attached is the proposed charter, modified as discussed.  Do we have consensus that this is the way we want to go?
>>
>> Feel free to propose other wording if you have some feedback other than a "+1".

+1, with two alternative wordings and one mumbling:

* In the third paragraph

  ARF as initially defined is already in widespread use at large
  ISPs, so interoperability can be demonstrated.

I would replace "ISPs" with the more specific "mailbox providers".

* In the extension list, non-message extensions (c), (d), (e), and 
(h) might be merged in a single entry, if we plan to address them in 
a similar fashion. A possible wording might be

   x) non-SMTP attacks, including SSH, FTP, and web, and DDoS reports

For the mumbling, about point 4, in the "abuse@(domain)" standard it 
is not plainly obvious to an average postmaster how to determine the 
target domain so as to avoid sending reports to the black hats. In 
case the WG will conclude that the industry should continue to use 
that standard, will the required guidelines be assumed to belong to 
an eventual rfc2142-bis?

In any case, ARF extensions (e.g. DKIM) may define their own means 
and provide guidelines to specify or suggest the target(s) for the 
corresponding ARF reports. I'm not sure whether it's worth 
mentioning this in the charter's description.

> I can live with it the way it is, but for point 4 if we're going to help 
> automate ARF reports, it's at least as important to invent some way for an 
> MUA junk button to report a message back to the user's ISP.  This could be 
> as simple as a header with an address or as baroque as added options in 
> DHCP, POP, IMAP, and SUBMIT.

+1, and I like the simple option: using abuse@(domain) even the 
extra header becomes unnecessary.

The user should be able to write or modify the human readable part 
of the report. I envisage the MUA button as popping up a dialog 
asking such questions as

* Did the user manually examine the body of the message?
* Does the user understand SMTP?
* Does the user believe the From address is true?
* Did the user examine the headers of the message?
* Does the user believe the Return-Path, if any, is true?

Assuming that the report will be sent to the user's mailbox 
provider, they may be able to forward it without further inspection 
depending on user's answers to those questions. In general, if the 
report is going to be forwarded through a trusted chain, wouldn't it 
be a waste of time to manually examine it multiple times?

Date: Fri, 25 Sep 2009 10:56:17 -0600
From: "J.D. Falk" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation 	-- Please comment

John R. Levine wrote:

>> So if I were to rework the deliverables, effectively swapping (1) and (2) from the current draft charter, it sounds like that would make everyone happy.  Specifically, we would push to get ARF finalized as minimally as possible (maybe even removing some stuff) and then work on the suggested list of things, including the DKIM stuff, as extensions.
>>
>> Do I hear any "+1"s?
>
> +1

+1

> Unlike a lot of IETF standardization efforts, ARF is already in wide use
> with rough consensus on the current format.
 >
> Hence it would be a good idea to document what its many users do now
> before blowing it up and hoping they like the changes.

+1

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Date: Thu, 24 Sep 2009 15:33:27 -0700
From: Douglas Otis <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

On 9/24/09 10:51 AM, Murray S. Kucherawy wrote:

>> Both automatic filtering OR reports generated by users pressing a
>> "junk" or "spam" button should not be considered reliable
>> categorization methods.  Even email sent to honeypots still need to
>> be automatically filtered into categories like "abuse/spam",
>> "fraud/phish", "opt-out", "virus/malware" and
>> "not-spam/NDN/auto-response".
>>
>> [...]
>>
>> The ARF report offers email providers a means to view samplings of
>> the problems their customer's systems create.  It would be a bad
>> practice for providers to react to ARF reports without their visual
>> review.  It would also be a bad practice to report any and all
>> email that can be categorized by an ARF report.  Still, providers
>> of email should ensure ARF reports are visually reviewed before
>> actions are taken.
>
> By extension, DSNs shouldn't be parsed by software to use when
> determining whether or not to remove a bouncing address from a
> mailing list, yet this is somewhat common practice.  I've not heard
> this in widespread use as an attack vector.

The concern was not about how to deal with DSNs where recipients of a 
DSN (such as a mailing list) can confirm it was in response to their 
message.  There are immediate methods to ensure against DSN spoofing, 
while there is also little incentive to send spoofed DSNs to some third 
party, which could be why this is not a problem. Again, the concern was 
about altering accounts based upon ARF reports when the nature of the 
message had not been visually verified.

It is not unusual for those generating ARF reports to lack a means to 
detect spoofed messages that would be afforded the natural recipient of 
a DSNs.  And, unlike DSNs, there are significant incentives for spammers 
to spoof messages normally captured in ARF reports.

This type of spoofing often creates multiple levels of indirection with 
respect to messages found in ARF reports.  A spammer may have determined 
the Mail From and Rcpt To using a dictionary attack against different 
domains.  Their spam will often spoof both of these addresses, where the 
return address might then receive an auto-response in a language not 
recognized by filter software run in someone's honeypot generating ARF 
reports, for example.  When it comes to reacting to issues noted 
indirectly (through an ARF third-party generator), visual inspection of 
the ARF message remains important.  It would be wrong and unfair to 
justify complacency by comparing ARF reports to DSNs.

> If automatic processing is a dangerous goal, then we must also
> conclude that DSN was a bad idea in the first place.

While the process that produces the ARF report is likely automatic, 
sorry Steve, recipients of these reports should be encouraged to 
visually examine the report's message before acting.  If not all, at 
least some of the messages should be reviewed.

> So, I have to disagree.

Are you saying that ARF reports should _not_ be visually reviewed 
because mailing list automatically react to DSNs?  Do you really think 
these two mechanisms are directly comparable?

-Doug

Date: Thu, 24 Sep 2009 15:37:45 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cleverness: None detected
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

> Attached is the proposed charter, modified as discussed.  Do we have consensus that this is the way we want to go?
>
> Feel free to propose other wording if you have some feedback other than a "+1".

I can live with it the way it is, but for point 4 if we're going to help 
automate ARF reports, it's at least as important to invent some way for an 
MUA junk button to report a message back to the user's ISP.  This could be 
as simple as a header with an adddress or as baroque as added options in 
DHCP, POP, IMAP, and SUBMIT.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Thu, 24 Sep 2009 11:47:10 -0700
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

On Sep 24, 2009, at 10:55 AM, Murray S. Kucherawy wrote:

> Attached is the proposed charter, modified as discussed.  Do we have  
> consensus that this is the way we want to go?
>
> Feel free to propose other wording if you have some feedback other  
> than a “+1”.
>
> (Silence isn’t automatic assent; please speak up!)
>
> -MSK

1 & 2 look fine to me. 4 is probably OK.

But point 3 states that integration of ARF with DKIM records is  
something that will be done by the group, which I don't think is good.

(Not that I think that doing something to report DKIM failures is  
necessarily a bad idea, it's just not something that should be a fait  
accompli in the charter. It might be better in the DKIM world than the  
ARF world too, as that's where the operational experience is.)

Cheers,
   Steve

From: "Murray S. Kucherawy" <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 24 Sep 2009 10:55:33 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

--_004_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_
Content-Type: multipart/alternative;
	boundary="_000_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_"

--_000_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Attached is the proposed charter, modified as discussed.  Do we have consen=
sus that this is the way we want to go?

Feel free to propose other wording if you have some feedback other than a "=
+1".

(Silence isn't automatic assent; please speak up!)

-MSK

--_000_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:952521165;
	mso-list-type:hybrid;
	mso-list-template-ids:67255358 -919855764 67698691 67698693 67698689 67698=
691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
@list l0:level2
	{mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Attached is the proposed
charter, modified as discussed.&nbsp; Do we have consensus that this is the=
 way we want
to go?<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Feel free to propose oth=
er
wording if you have some feedback other than a &#8220;+1&#8221;.<o:p></o:p>=
</span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>(Silence isn&#8217;t aut=
omatic assent;
please speak up!)<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>-MSK<o:p></o:p></span></=
p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</body>

</html>

--_000_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_--

--_004_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_
Content-Type: text/plain; name="arf-charter v06.txt"
Content-Description: arf-charter v06.txt
Content-Disposition: attachment; filename="arf-charter v06.txt"; size=6089;
	creation-date="Thu, 24 Sep 2009 10:46:47 GMT";
	modification-date="Thu, 24 Sep 2009 10:48:11 GMT"
Content-Transfer-Encoding: base64

--_004_BB012BD379D7B046ABE1472D8093C61C01AFA273F7EXCHC2corpclo_--

From: "Murray S. Kucherawy" <[email-masked]>
To: Douglas Otis <[email-masked]>, Steve Atkins <[email-masked]>
Date: Thu, 24 Sep 2009 10:51:59 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

> -----Original Message-----
> From: [email-masked] [mailto:abuse-
> [email-masked]] On Behalf Of Douglas Otis
> Sent: Wednesday, September 23, 2009 11:45 PM
> To: Steve Atkins
> Cc: ARF mailing list
> Subject: Re: [feedback-report] Revised draft charter, call for
> participation -- Please comment
> 
> Both automatic filtering OR reports generated by users pressing a
> "junk"
> or "spam" button should not be considered reliable categorization
> methods.  Even email sent to honeypots still need to be automatically
> filtered into categories like "abuse/spam", "fraud/phish", "opt-out",
> "virus/malware" and "not-spam/NDN/auto-response".
> 
> [...]
> 
> The ARF report offers email providers a means to view samplings of the
> problems their customer's systems create.  It would be a bad practice
> for providers to react to ARF reports without their visual review.  It
> would also be a bad practice to report any and all email that can be
> categorized by an ARF report.  Still, providers of email should ensure
> ARF reports are visually reviewed before actions are taken.

By extension, DSNs shouldn't be parsed by software to use when determining whether or not to remove a bouncing address from a mailing list, yet this is somewhat common practice.  I've not heard this in widespread use as an attack vector.

If automatic processing is a dangerous goal, then we must also conclude that DSN was a bad idea in the first place.

So, I have to disagree.

Date: Wed, 23 Sep 2009 23:44:56 -0700
From: Douglas Otis <[email-masked]>
To: Steve Atkins <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

On 9/23/09 6:29 PM, Steve Atkins wrote:
>
> On Sep 23, 2009, at 6:05 PM, Douglas Otis wrote:
>>
>> The problem this attempts to address will not be resolved through
>> automation.  Any automation 'foo' will be gamed.  Resolving these
>> issues requires wet-ware.  It should be a safe assumption that
>> automated detection of spam will represent the main force causing
>> a report to be generated.
>
> Uhm.
>
> Automated detection of spam is not a main force in causing a report
> to be generated today. It's probably a negligible fraction, actually,
> and that's not a bad thing given the quality of that sort of report
> I've seen.

Steve,

Both automatic filtering OR reports generated by users pressing a "junk"
or "spam" button should not be considered reliable categorization
methods.  Even email sent to honeypots still need to be automatically
filtered into categories like "abuse/spam", "fraud/phish", "opt-out",
"virus/malware" and "not-spam/NDN/auto-response".

Those issuing ARF reports should not be expected to have expended much
effort checking the veracity of their output, beyond ensuring their
process is active and not reporting errors.  The onus is on those
receiving ARF reports to decide what actions are needed based upon their
own inspections.

This raises a question about the "miscategorizated" status.  Is this
intended to benefit rating services?  A bad reputation would not be an
assertion against _all_ of a domain's email or even all email from a
specific email-address.  It just means the source is considered abusive
and recipients may not wish to accept or to lower their score to improve
catch rates.  Reporting instances of where a message conflicts with a 
rating can be easily gamed, and likely to be of no value.

The ARF report offers email providers a means to view samplings of the
problems their customer's systems create.  It would be a bad practice
for providers to react to ARF reports without their visual review.  It
would also be a bad practice to report any and all email that can be
categorized by an ARF report.  Still, providers of email should ensure
ARF reports are visually reviewed before actions are taken.

-Doug

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 23 Sep 2009 21:50:14 -0400
To: Douglas Otis <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation 	-- Please comment

On Wed, Sep 23, 2009 at 9:05 PM, Douglas Otis <[email-masked]> wrote:
> The problem this attempts to address will not be resolved through
> automation.  Any automation 'foo' will be gamed.  Resolving these issues
> requires wet-ware.  It should be a safe assumption that automated
> detection of spam will represent the main force causing a report to be
> generated.
>
> These reports should be considered similar to check processing at a bank
> where exceptions require visual examination.  Such examination is not
> facilitated by XML decorations.
>

It is possible to make examination by humans more efficient and
faster. For example, several US banks now use a system for their ATMs
where the checks are scanned and the scanned images are transmitted to
some other location instead of being checked by the teller at the
bank. They are already in a form that is easily analyzed and linked to
the accounts in question. Same goes here - getting the reports in a
standard format, will allow make analysis and processing faster.

Yakov

Date: Wed, 23 Sep 2009 18:05:32 -0700
From: Douglas Otis <[email-masked]>
To: Steve Atkins <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation 	-- Please comment

On 9/23/09 12:22 PM, Steve Atkins wrote:
>
> On Sep 23, 2009, at 12:07 PM, Murray S. Kucherawy wrote:
>>>
>>> I would like to participate but I have an issue with the
>>> deliverables.  Specifically, I am concerned with the possibility
>>>  that we may get stuck on discussing all the proposed extensions
>>>  before codifying the main draft. I would like to suggest that we
>>>  make standardizing the bare minimum of ARF first, and consider
>>> the extensions as a second step. If a larger scope format evolves
>>> from it, it may become ARF 2.0, but we need the 1.0 in place
>>> first.
>>
>> I believe this jives with what a few others have said.  I'm fine
>> with this approach if there's consensus.
>>
>> So if I were to rework the deliverables, effectively swapping (1)
>> and (2) from the current draft charter, it sounds like that would
>> make everyone happy.  Specifically, we would push to get ARF
>> finalized as minimally as possible (maybe even removing some stuff)
>> and then work on the suggested list of things, including the DKIM
>> stuff, as extensions.
>>
>> Do I hear any "+1"s?
>
> Yup, sounds like a good plan to me.

Yes. Start with:

,---
  The primary target for "generic" abuse reports (fraud, spam,
  virus, etcetera) would be the abuse desk of the organization
  accountable for originating the message. A document specifying where
  the target address can be found should also say how to identify such
  accountable originator, which is not a marginal task for a document or
  a WG dedicated to a format specification.
'---

The problem this attempts to address will not be resolved through
automation.  Any automation 'foo' will be gamed.  Resolving these issues
requires wet-ware.  It should be a safe assumption that automated
detection of spam will represent the main force causing a report to be
generated.

These reports should be considered similar to check processing at a bank
where exceptions require visual examination.  Such examination is not
facilitated by XML decorations.

-Doug

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Wed, 23 Sep 2009 18:29:59 -0700
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

On Sep 23, 2009, at 6:05 PM, Douglas Otis wrote:
>>
>
> Yes. Start with:
>
> ,---
> The primary target for "generic" abuse reports (fraud, spam,
> virus, etcetera) would be the abuse desk of the organization
> accountable for originating the message. A document specifying where
> the target address can be found should also say how to identify such
> accountable originator, which is not a marginal task for a document or
> a WG dedicated to a format specification.
> '---
>
> The problem this attempts to address will not be resolved through
> automation.  Any automation 'foo' will be gamed.  Resolving these  
> issues
> requires wet-ware.  It should be a safe assumption that automated
> detection of spam will represent the main force causing a report to be
> generated.

Uhm.

Automated detection of spam is not a main force in causing a report
to be generated today. It's probably a negligible fraction, actually,  
and
that's not a bad thing given the quality of that sort of report I've  
seen.

>
> These reports should be considered similar to check processing at a  
> bank
> where exceptions require visual examination.  Such examination is not
> facilitated by XML decorations.

Cheers,
   Steve

Date: Wed, 23 Sep 2009 15:55:23 -0400
From: Todd Herr <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] Revised draft charter, call for	participation  -- Please comment

+1 

On Wed, Sep 23, 2009 at 12:07:14PM -0700, Murray S. Kucherawy wrote:
> > -----Original Message-----
> > From: Yakov Shafranovich [mailto:[email-masked]]
> > Sent: Monday, September 21, 2009 7:11 PM
> > To: Murray S. Kucherawy
> > Cc: [email-masked]
> > Subject: Re: [feedback-report] Revised draft charter, call for
> > participation -- Please comment
> > 
> > I would like to participate but I have an issue with the deliverables.
> > Specifically, I am concerned with the possibility that we may get
> > stuck on discussing all the proposed extensions before codifying the
> > main draft. I would like to suggest that we make standardizing the
> > bare minimum of ARF first, and consider the extensions as a second
> > step. If a larger scope format evolves from it, it may become ARF 2.0,
> > but we need the 1.0 in place first.
> 
> I believe this jives with what a few others have said.  I'm fine with this approach if there's consensus.
> 
> So if I were to rework the deliverables, effectively swapping (1) and (2) from the current draft charter, it sounds like that would make everyone happy.  Specifically, we would push to get ARF finalized as minimally as possible (maybe even removing some stuff) and then work on the suggested list of things, including the DKIM stuff, as extensions.
> 
> Do I hear any "+1"s?
> 
> 
> _______________________________________________
> abuse-feedback-report mailing list
> [email-masked]
> http://mipassoc.org/mailman/listinfo/abuse-feedback-report

-- 
Todd Herr
Principal Engineer and Postmaster              V: 703.345.2447
Road Runner Email Operations                   M: 571.287.0366
[email-masked]                        AIM: RRMailToddHerr

Date: Wed, 23 Sep 2009 15:37:21 -0400
From: Michael Adkins <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation 	-- Please comment

+1

Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: Yakov Shafranovich [mailto:[email-masked]]
>> Sent: Monday, September 21, 2009 7:11 PM
>> To: Murray S. Kucherawy
>> Cc: [email-masked]
>> Subject: Re: [feedback-report] Revised draft charter, call for
>> participation -- Please comment
>>
>> I would like to participate but I have an issue with the deliverables.
>> Specifically, I am concerned with the possibility that we may get
>> stuck on discussing all the proposed extensions before codifying the
>> main draft. I would like to suggest that we make standardizing the
>> bare minimum of ARF first, and consider the extensions as a second
>> step. If a larger scope format evolves from it, it may become ARF 2.0,
>> but we need the 1.0 in place first.
>>     
>
> I believe this jives with what a few others have said.  I'm fine with this approach if there's consensus.
>
> So if I were to rework the deliverables, effectively swapping (1) and (2) from the current draft charter, it sounds like that would make everyone happy.  Specifically, we would push to get ARF finalized as minimally as possible (maybe even removing some stuff) and then work on the suggested list of things, including the DKIM stuff, as extensions.
>
> Do I hear any "+1"s?
>
>
> _______________________________________________
> abuse-feedback-report mailing list
> [email-masked]
> http://mipassoc.org/mailman/listinfo/abuse-feedback-report
>   

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Wed, 23 Sep 2009 12:22:54 -0700
Subject: Re: [feedback-report] Revised draft charter, call for participation 	-- Please comment

On Sep 23, 2009, at 12:07 PM, Murray S. Kucherawy wrote:
>>
>> I would like to participate but I have an issue with the  
>> deliverables.
>> Specifically, I am concerned with the possibility that we may get
>> stuck on discussing all the proposed extensions before codifying the
>> main draft. I would like to suggest that we make standardizing the
>> bare minimum of ARF first, and consider the extensions as a second
>> step. If a larger scope format evolves from it, it may become ARF  
>> 2.0,
>> but we need the 1.0 in place first.
>
> I believe this jives with what a few others have said.  I'm fine  
> with this approach if there's consensus.
>
> So if I were to rework the deliverables, effectively swapping (1)  
> and (2) from the current draft charter, it sounds like that would  
> make everyone happy.  Specifically, we would push to get ARF  
> finalized as minimally as possible (maybe even removing some stuff)  
> and then work on the suggested list of things, including the DKIM  
> stuff, as extensions.
>
> Do I hear any "+1"s?

Yup, sounds like a good plan to me.

Cheers,
   Steve

Date: 23 Sep 2009 15:22:15 -0400
From: "John R. Levine" <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cleverness: None detected
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation 	-- Please comment

> So if I were to rework the deliverables, effectively swapping (1) and (2) from the current draft charter, it sounds like that would make everyone happy.  Specifically, we would push to get ARF finalized as minimally as possible (maybe even removing some stuff) and then work on the suggested list of things, including the DKIM stuff, as extensions.
>
> Do I hear any "+1"s?

+1

Unlike a lot of IETF standardization efforts, ARF is already in wide use 
with rough consensus on the current format.

Hence it would be a good idea to document what its many users do now 
before blowing it up and hoping they like the changes.

R's,
John

From: "Murray S. Kucherawy" <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
Date: Wed, 23 Sep 2009 12:07:14 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation 	-- Please comment

> -----Original Message-----
> From: Yakov Shafranovich [mailto:[email-masked]]
> Sent: Monday, September 21, 2009 7:11 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [feedback-report] Revised draft charter, call for
> participation -- Please comment
> 
> I would like to participate but I have an issue with the deliverables.
> Specifically, I am concerned with the possibility that we may get
> stuck on discussing all the proposed extensions before codifying the
> main draft. I would like to suggest that we make standardizing the
> bare minimum of ARF first, and consider the extensions as a second
> step. If a larger scope format evolves from it, it may become ARF 2.0,
> but we need the 1.0 in place first.

I believe this jives with what a few others have said.  I'm fine with this approach if there's consensus.

So if I were to rework the deliverables, effectively swapping (1) and (2) from the current draft charter, it sounds like that would make everyone happy.  Specifically, we would push to get ARF finalized as minimally as possible (maybe even removing some stuff) and then work on the suggested list of things, including the DKIM stuff, as extensions.

Do I hear any "+1"s?

Date: Wed, 23 Sep 2009 08:43:08 +0200
From: Alessandro Vesely <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

Murray S. Kucherawy wrote:
> Attached is a revised proposed charter for an IETF working group 
> regarding the ARF work.

Thanks for that addition!

It's good to mention INCH, not only because non-message extensions 
can be addressed that way, but also for complementarity that may 
manifest, e.g., when a botnet message reported using ARF happens to 
contribute useful info to a network incident maintained using IODEF.

> [...] So after reviewing the draft charter, please reply to the 
> list with some comments along the lines of the following as you feel 
> appropriate:

I would participate in a working group with this charter.

> …and:

Formally, I represent just myself. However, I try to consider the 
needs of several small to medium mailbox providers that serve one or 
few mail domains within non-IT companies or institutions. That is to 
say, organizations that currently use neither ARF nor IODEF, but 
might adopt any of them when a clear proposal of cooperation for a 
better Internet will be made.

Date: Tue, 22 Sep 2009 10:33:11 -0400
From: Michael Adkins <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

John R. Levine wrote:
>> I'd like to participate if there were fewer deliverables.
>>
>> ARF is, at core, a way of encapsulating a clean copy of a single email
>> along with some metadata.
>>
>> The extensions you mention as possibilities cannot be added without
>> changing ARF entirely, as they are not things that can be expressed as
>> a copy of a single email.
>>
>> Alternatively, I'd also be somewhat interested in participating in
>> development of a reporting format for the non-email related issues you
>> mention, one that is not ARF, but adopts ARF's philosophy of simplicity.
>>     
>
> +1
> _______________________________________________
> abuse-feedback-report mailing list
> [email-masked]
> http://mipassoc.org/mailman/listinfo/abuse-feedback-report
>   
+1

Also -
I would participate in a working group if the charter had the sort of
changes John and Steve are talking about.
...and:
I represent an organization that already uses ARF and would like to see
it published as a proposed standard.

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 21 Sep 2009 22:10:31 -0400
To: "Murray S. Kucherawy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation 	-- Please comment

2009/9/21 Murray S. Kucherawy <[email-masked]>:
> Attached is a revised proposed charter for an IETF working group regarding
> the ARF work.  Please take a look.
>
>

Murray - once again - thanks for taking over and shepherding this along.

> -          I/we would participate in a working group if the charter had the
> following changes (e.g. additional deliverables)
>

I would like to participate but I have an issue with the deliverables.
Specifically, I am concerned with the possibility that we may get
stuck on discussing all the proposed extensions before codifying the
main draft. I would like to suggest that we make standardizing the
bare minimum of ARF first, and consider the extensions as a second
step. If a larger scope format evolves from it, it may become ARF 2.0,
but we need the 1.0 in place first.

Also, two small comments on the actual text:
1. The group referred to in the draft as originally have developed ARF
- I believe that is referring to Anti-Spam Technology Alliance.
2. The draft is referencing DSNs as a related standard. It should
probably reference RFC 3462 since it is directly based on it.

Keep up the good work!
Yakov

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Mon, 21 Sep 2009 11:05:10 -0700
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

On Sep 21, 2009, at 10:48 AM, Murray S. Kucherawy wrote:

>> -----Original Message-----
>> From: [email-masked] [mailto:abuse-
>> [email-masked]] On Behalf Of Steve Atkins
>> Sent: Monday, September 21, 2009 10:44 AM
>> To: ARF mailing list
>> Subject: Re: [feedback-report] Revised draft charter, call for
>> participation -- Please comment
>>
>> I'd like to participate if there were fewer deliverables.
>>
>> ARF is, at core, a way of encapsulating a clean copy of a single  
>> email
>> along with some metadata.
>>
>> The extensions you mention as possibilities cannot be added without
>> changing ARF entirely, as they are not things that can be expressed  
>> as
>> a copy of a single email.
>
> The charter doesn't require adoption of any or all of those proposed  
> extensions.  It just makes a commitment to their due consideration.

Yup, and that's perfectly reasonable.

However, I've seen in the past that "the phrasing of the charter  
dictates the end product", and including obviously problematic ideas  
in a charter that is explicitly about ARF is going to lead to, well,  
long and pointless discussions at the very least (which is something  
that makes me less interested in participating).

>
> A spinoff effort to consider the non-messaging extensions that have  
> been proposed also seems quite palatable to me, even if it would be  
> as simple as "here's how to use/extend INCH to do that", since  
> clearly there's a need for it.

If the goal were "How to easily automate abuse reports of these types,  
including use of ARF, INCH and potentially other approaches", rather  
than "How to extend ARF to automate abuse reports of these types" I'd  
lose most of my reservations about the charter. That'd be more likely  
to tread on INCH toes, though, I'm sure, given it's mostly revisiting  
their work.

Cheers,
   Steve

Date: Mon, 21 Sep 2009 14:01:33 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Steve Atkins <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

> I'd like to participate if there were fewer deliverables.
>
> ARF is, at core, a way of encapsulating a clean copy of a single email
> along with some metadata.
>
> The extensions you mention as possibilities cannot be added without
> changing ARF entirely, as they are not things that can be expressed as
> a copy of a single email.
>
> Alternatively, I'd also be somewhat interested in participating in
> development of a reporting format for the non-email related issues you
> mention, one that is not ARF, but adopts ARF's philosophy of simplicity.

+1

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Mon, 21 Sep 2009 10:11:42 -0700
Subject: Re: [feedback-report] FW: Another ARF expansion request

On Sep 21, 2009, at 9:59 AM, Yakov Shafranovich wrote:

> On Mon, Sep 21, 2009 at 12:51 PM, Murray S. Kucherawy <[email-masked] 
> > wrote:
>>> -----Original Message-----
>>> From: [email-masked] [mailto:abuse-
>>> [email-masked]] On Behalf Of John R. Levine
>>> Sent: Saturday, September 19, 2009 9:27 AM
>>> To: Tobias Knecht
>>> Cc: ARF mailing list
>>> Subject: Re: [feedback-report] FW: Another ARF expansion request
>>>
>>> I'll ask at MAAWG and see how willing ISPs are to add a lot of  
>>> custom
>>> additions to their ARF processing.  Designing formats that  
>>> interoperate
>>> reliably is harder than it appears (look at all the little bugs in
>>> DKIM.)
>>
>> We can mitigate some (but not all) of this concern by adopting  
>> DKIM's "if you don't recognize it, ignore it" posture with respect  
>> to tag names (or in the ARF case, abuse types, etc.).
>
> It is already in the current draft in section dealing with  
> extensibility:
>
> "In order to encourage extensibility and interoperability of this
>   format, implementors MUST ignore any fields they do not support.
> "

This makes ARF significantly less suitable for automated processing,  
as the bits you're ignoring may change the semantics of the message  
entirely - leading to automated processing taking the wrong action.

Cheers,
   Steve

From: "Murray S. Kucherawy" <[email-masked]>
To: Steve Atkins <[email-masked]>, ARF mailing list <[email-masked]>
Date: Mon, 21 Sep 2009 10:48:42 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

> -----Original Message-----
> From: [email-masked] [mailto:abuse-
> [email-masked]] On Behalf Of Steve Atkins
> Sent: Monday, September 21, 2009 10:44 AM
> To: ARF mailing list
> Subject: Re: [feedback-report] Revised draft charter, call for
> participation -- Please comment
> 
> I'd like to participate if there were fewer deliverables.
> 
> ARF is, at core, a way of encapsulating a clean copy of a single email
> along with some metadata.
> 
> The extensions you mention as possibilities cannot be added without
> changing ARF entirely, as they are not things that can be expressed as
> a copy of a single email.

The charter doesn't require adoption of any or all of those proposed extensions.  It just makes a commitment to their due consideration.

A spinoff effort to consider the non-messaging extensions that have been proposed also seems quite palatable to me, even if it would be as simple as "here's how to use/extend INCH to do that", since clearly there's a need for it.

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Mon, 21 Sep 2009 10:44:10 -0700
Subject: Re: [feedback-report] Revised draft charter, call for participation -- Please comment

On Sep 21, 2009, at 10:06 AM, Murray S. Kucherawy wrote:

> Attached is a revised proposed charter for an IETF working group  
> regarding the ARF work.  Please take a look.
>
> Also, it’s important to have “for the record” the overall response  
> in terms of potential working group participation.  I know I’ve done  
> something like this before but there appears to be some cause to re- 
> poll the group.  It may be good enough just to have the recent  
> chatter as evidence of interest but for the sake of the IETF I’d  
> like to be more explicit.  So after reviewing the draft charter,  
> please reply to the list with some comments along the lines of the  
> following as you feel appropriate:
>
> -          I/we would participate in a working group with this  
> charter or one like it
> -          I/we would participate in a working group if the charter  
> had the following changes (e.g. additional deliverables)

I'd like to participate if there were fewer deliverables.

ARF is, at core, a way of encapsulating a clean copy of a single email  
along with some metadata.

The extensions you mention as possibilities cannot be added without  
changing ARF entirely, as they are not things that can be expressed as  
a copy of a single email.

Alternatively, I'd also be somewhat interested in participating in  
development of a reporting format for the non-email related issues you  
mention, one that is not ARF, but adopts ARF's philosophy of simplicity.

But shoehorning every possible thing someone may want to communicate  
into what's currently a simple, single-use format isn't an approach I  
think will lead to a widely deployable standard.

>  …and:
>
> -          I represent an organization that already uses ARF and  
> would like to see it published as a proposed standard

I'd like to see a slightly cut-down version of the existing ARF spec  
published as a proposed standard.

I'd be interested in an effort to add additional machine readable  
abuse reporting approaches that are not ARF. There's a whole spectrum  
there, from the complexity of INCH to a very simple format that simply  
includes just the metadata needed for routing and triage[1].

> -          I represent an organization that would adopt ARF once it  
> has been published as a proposed standard
> -          I represent an organization that may not use ARF but  
> would like to see it or something like it issued as a proposed  
> standard
>
> I can say personally that I’ll participate and I represent one  
> commercial organization that may or may not use ARF directly but is  
> interested in seeing it standardized in either case, and one (an  
> open source team) that already uses it and would like it to move  
> forward.
>
> Thanks,
>

Cheers,
   Steve

[1] A major use of the ARF metadata is to aggregate multiple reports  
of the same incident into a single issue, mechanically triage that  
based on (mostly) number of reports and then have those incidents be  
handled by a human.

An extremely simple format that consisted simply of an identifier (an  
IP address, hostname, URL or email address, say) and free text would  
cover all the suggested abuse types, and provide a lot of what  
recipients need. It could also be specced fully on a single page and  
implemented fairly easily with current tools.

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 21 Sep 2009 10:06:48 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: [feedback-report] Revised draft charter, call for participation -- Please comment

--_004_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_
Content-Type: multipart/alternative;
	boundary="_000_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_"

--_000_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Attached is a revised proposed charter for an IETF working group regarding =
the ARF work.  Please take a look.

Also, it's important to have "for the record" the overall response in terms=
 of potential working group participation.  I know I've done something like=
 this before but there appears to be some cause to re-poll the group.  It m=
ay be good enough just to have the recent chatter as evidence of interest b=
ut for the sake of the IETF I'd like to be more explicit.  So after reviewi=
ng the draft charter, please reply to the list with some comments along the=
 lines of the following as you feel appropriate:

-          I/we would participate in a working group with this charter or o=
ne like it

-          I/we would participate in a working group if the charter had the=
 following changes (e.g. additional deliverables)

...and:

-          I represent an organization that already uses ARF and would like=
 to see it published as a proposed standard

-          I represent an organization that would adopt ARF once it has bee=
n published as a proposed standard

-          I represent an organization that may not use ARF but would like =
to see it or something like it issued as a proposed standard

I can say personally that I'll participate and I represent one commercial o=
rganization that may or may not use ARF directly but is interested in seein=
g it standardized in either case, and one (an open source team) that alread=
y uses it and would like it to move forward.

Thanks,

-MSK

--_000_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:952521165;
	mso-list-type:hybrid;
	mso-list-template-ids:67255358 -919855764 67698691 67698693 67698689 67698=
691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-bidi-font-family:"Times New Roman";}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Attached is a revised proposed charter for an IETF wor=
king
group regarding the ARF work.&nbsp; Please take a look.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Also, it&#8217;s important to have &#8220;for the reco=
rd&#8221;
the overall response in terms of potential working group participation.&nbs=
p; I
know I&#8217;ve done something like this before but there appears to be som=
e
cause to re-poll the group.&nbsp; It may be good enough just to have the re=
cent
chatter as evidence of interest but for the sake of the IETF I&#8217;d like=
 to
be more explicit.&nbsp; So after reviewing the draft charter, please reply =
to
the list with some comments along the lines of the following as you feel
appropriate:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New Roman"'>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>I/we would participate in a working group with this
charter or one like it<o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New Roman"'>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>I/we would participate in a working group if the
charter had the following changes (e.g. additional deliverables)<o:p></o:p>=
</p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>&#8230;and:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New Roman"'>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>I represent an organization that already uses ARF a=
nd
would like to see it published as a proposed standard<o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New Roman"'>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>I represent an organization that would adopt ARF on=
ce
it has been published as a proposed standard<o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 =
lfo1'><![if !supportLists]><span
style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New Roman"'>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>I represent an organization that may not use ARF bu=
t
would like to see it or something like it issued as a proposed standard<o:p=
></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I can say personally that I&#8217;ll participate and I
represent one commercial organization that may or may not use ARF directly =
but
is interested in seeing it standardized in either case, and one (an open so=
urce
team) that already uses it and would like it to move forward.<o:p></o:p></p=
>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thanks,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>-MSK<o:p></o:p></p>

</div>

</body>

</html>

--_000_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_--

--_004_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_
Content-Type: text/plain; name="arf-charter v05.txt"
Content-Description: arf-charter v05.txt
Content-Disposition: attachment; filename="arf-charter v05.txt"; size=5597;
	creation-date="Fri, 18 Sep 2009 09:50:14 GMT";
	modification-date="Fri, 18 Sep 2009 12:17:33 GMT"
Content-Transfer-Encoding: base64

--_004_BB012BD379D7B046ABE1472D8093C61C01AFA26F58EXCHC2corpclo_--

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 21 Sep 2009 12:59:03 -0400
To: "Murray S. Kucherawy" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] FW: Another ARF expansion request

On Mon, Sep 21, 2009 at 12:51 PM, Murray S. Kucherawy <[email-masked]> wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:abuse-
>> [email-masked]] On Behalf Of John R. Levine
>> Sent: Saturday, September 19, 2009 9:27 AM
>> To: Tobias Knecht
>> Cc: ARF mailing list
>> Subject: Re: [feedback-report] FW: Another ARF expansion request
>>
>> I'll ask at MAAWG and see how willing ISPs are to add a lot of custom
>> additions to their ARF processing.  Designing formats that interoperate
>> reliably is harder than it appears (look at all the little bugs in
>> DKIM.)
>
> We can mitigate some (but not all) of this concern by adopting DKIM's "if you don't recognize it, ignore it" posture with respect to tag names (or in the ARF case, abuse types, etc.).

It is already in the current draft in section dealing with extensibility:

"In order to encourage extensibility and interoperability of this
   format, implementors MUST ignore any fields they do not support.
"

From: "Murray S. Kucherawy" <[email-masked]>
To: "John R. Levine" <[email-masked]>, Tobias Knecht <[email-masked]>
Date: Mon, 21 Sep 2009 09:51:27 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] FW: Another ARF expansion request

> -----Original Message-----
> From: [email-masked] [mailto:abuse-
> [email-masked]] On Behalf Of John R. Levine
> Sent: Saturday, September 19, 2009 9:27 AM
> To: Tobias Knecht
> Cc: ARF mailing list
> Subject: Re: [feedback-report] FW: Another ARF expansion request
> 
> I'll ask at MAAWG and see how willing ISPs are to add a lot of custom
> additions to their ARF processing.  Designing formats that interoperate
> reliably is harder than it appears (look at all the little bugs in
> DKIM.)

We can mitigate some (but not all) of this concern by adopting DKIM's "if you don't recognize it, ignore it" posture with respect to tag names (or in the ARF case, abuse types, etc.).

Date: Sat, 19 Sep 2009 12:26:31 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Tobias Knecht <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] FW: Another ARF expansion request

PS:

> It is not commonly used. ARF is used by abuse departments and we wanna
> communicated with abuse departments.

I'll ask at MAAWG and see how willing ISPs are to add a lot of custom 
additions to their ARF processing.  Designing formats that interoperate 
reliably is harder than it appears (look at all the little bugs in DKIM.)

An important reason to use XML for complex formats is that there are 
already well debugged libraries to read and write it.

R's,
John

Date: Sat, 19 Sep 2009 12:22:57 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Tobias Knecht <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] German abuse reporting work

> "We" means Germany ISP Association (eco), German Ministry of Internet
> Securtity (BSI), several ISPs and abusix. The draft will be done by BSI
> and published for conversation. We already had the conversation at the
> meeting when we worked out the things you have seen in the email by
> Dietmar Braun. So the conversation should not last too long.

It would be nice if you could send along your results before the MAAWG 
meeting at the end of October, since it would be unfortunate if German 
ISPs used one reporting format and everyone else used another.

> So if we have to make changes in IODEF and in ARF, I would like to
> change the format that is mostly used in abuse departments. Which is ARF.

Nothing personal, but I fear that if you both think that IODEF is too 
complicated and it doesn't have enough options, you're unlikely to come up 
with anything better.

R's,
John

Date: Sat, 19 Sep 2009 18:15:23 +0200
From: Tobias Knecht <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] FW: Another ARF expansion request

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5330C60900D0640F2E306561
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

sorry for the delayed answer.

> Sounds great.  Who is "we"?  This sounds like something that needs
> coordination with MAAWG, since that's where you find the large ISPs.

"We" means Germany ISP Association (eco), German Ministry of Internet
Securtity (BSI), several ISPs and abusix. The draft will be done by BSI
and published for conversation. We already had the conversation at the
meeting when we worked out the things you have seen in the email by
Dietmar Braun. So the conversation should not last too long.

>> And yes there is INCH/IODEF and we decided that it's not sufficient fo=
r
>> the needs we have.
>=20
> I don't disagree, but what in particular makes IODEF insufficient, and
> why would you rather start over than add report types to IODEF?

It is too complicated.
It is not able to handle all sorts of abusive behavior, so there is need
to change, same as in ARF.
It is not commonly used. ARF is used by abuse departments and we wanna
communicated with abuse departments. IODEF is used by CERTs or mostly
network operation centers which will not be interested in spam issues.

So our opinion is, to have IODEF as a format for things that have to be
sent to CERTs or network operation centers and ARF will be used by abuse
departments.

So if we have to make changes in IODEF and in ARF, I would like to
change the format that is mostly used in abuse departments. Which is ARF.=

Thanks,

Tobias

--------------enig5330C60900D0640F2E306561
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig5330C60900D0640F2E306561--

Date: Sat, 19 Sep 2009 09:21:44 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: ARF mailing list <[email-masked]>
Cleverness: None detected
Subject: [feedback-report] Remember to put SIP and SPIT in the kitchen sink

Our pals over in the RUCKUS group which is considering VoIP spam remind us 
that if we're trying to invent or preferably adapt an all-purpose report 
format, it should handle reports of SIP abuse.  SIP calls have a header 
that deliberately looks a lot like a mail header. so that shouldn't be 
hard 
to do.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

Date: Sat, 19 Sep 2009 13:04:54 +0200
From: Alessandro Vesely <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] FW: Another ARF expansion request

Yakov Shafranovich wrote:
> Abuse desks that deal with ARF now are the same ones that deal with 
> all abuse issues and it would make sense to have a single format.

I doubt someone who deals with "all abuse issues" really exists. But 
even then, why should they use a single format?

> What I am also guessing is that IO-DEF/INCH and its XML base makes 
> things too heavy for most ISPs. ARF is much simpler and this is 
> probably why ISPs are interested in using it for all kinds of abuse 
> reporting [(implied:) that they do, or plan to].
+1,            ^^
ARF is good as it can be read manually by moderately trained 
postmasters, just like DSN format.

Date: Sat, 19 Sep 2009 13:04:47 +0200
From: Alessandro Vesely <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] IETF draft on dealing with bots

John R. Levine wrote:
> [...] it's really time for you to 
> stop wasting everyone's time trying to turn ARF into an all-purpose 
> reporting blob.

I never meant to promote all-purpose reporting.

> If you want INCH, you know where to find it.  It's not here.

I'm not familiar with INCH, but at a quick glance it looks as if that 
is just a rather sophisticated data model. Did they say anything about 
  who, when, where, and why?

Date: Fri, 18 Sep 2009 14:58:33 -0700
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: "[email-masked]" <[email-masked]>
Subject: [feedback-report] attr/val vs. xml
Reply-To: [email-masked]

Murray S. Kucherawy wrote:
> I suggested privately to someone else earlier today that email admins and
> developers are likely quite used to parsing "name: value" (like header
> fields), "tag=value" (like DKIM or MIME), and similar string formats versus
> full XML work, and likely by now also have a good repertoire of library
> functions 
...
> On the other hand, inertia is often not a good thing, and XML is generally
> regarded as "the way" these days.  

A simple tag/value format has the advantage of being... simple.  But it also is 
not comfortably extensible, except as a serial list of tag/values.

xml has the advantage of permitting more complex structures.

And that, I think, is a useful basis for choosing between them:  If you are sure 
that you only need an extensible list, then use a trivial attribute/value 
format.  If you expect to need any more data complexity -- such as nested values 
-- then xml is the way to go.

(xml might be the way to go for additional reasons, but I'm suggesting a simple 
guideline.)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Fri, 18 Sep 2009 16:52:13 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] FW: Another ARF expansion request

> I suggested privately to someone else earlier today that email admins 
> and developers are likely quite used to parsing "name: value" (like 
> header fields), "tag=value" (like DKIM or MIME), and similar string 
> formats versus full XML work

Oh, of course.  But if you want an abuse format that can report, say, a 
list of IP addresses in a /24 that have been attacking your ssh server, 
with the latest timestamp of each, you're going to need something more 
than tag=value, and XML for all its faults has the advantage of well 
debugged libraries to read it and write it.

It would definitely be useful to know why you decided that you couldn't 
use IODEF.

R's,
John

From: "Murray S. Kucherawy" <[email-masked]>
To: Yakov Shafranovich <[email-masked]>, Tobias Knecht <[email-masked]>
Date: Fri, 18 Sep 2009 13:39:58 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] FW: Another ARF expansion request

> -----Original Message-----
> From: Yakov Shafranovich [mailto:[email-masked]]
> Sent: Friday, September 18, 2009 12:43 PM
> To: Tobias Knecht
> Cc: Murray S. Kucherawy; [email-masked]
> Subject: Re: [feedback-report] FW: Another ARF expansion request
> 
> [...]
> 
> What I am also guessing is that IO-DEF/INCH and its XML base makes
> things too heavy for most ISPs. ARF is much simpler and this is
> probably why ISPs are interested in using it for all kinds of abuse
> reporting.

I suggested privately to someone else earlier today that email admins and developers are likely quite used to parsing "name: value" (like header fields), "tag=value" (like DKIM or MIME), and similar string formats versus full XML work, and likely by now also have a good repertoire of library functions or other code for doing so.  Though INCH might be very appropriate for general abuse reporting, the idea of converting to it may well be daunting for the average email admin these days.

On the other hand, inertia is often not a good thing, and XML is generally regarded as "the way" these days.  But I do understand the pressures to be timely rather than robust in expanding existing functionality.

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 18 Sep 2009 15:43:14 -0400
To: Tobias Knecht <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] FW: Another ARF expansion request

Tobias,

I don't think that this group is not interested, rather it is a
question of scope. ARF 1.0 was designed specifically for email abuse
reporting and it would take a lot of changes to make it more generic.
So a more correct way to put this would be is that this group does not
think that this would fit within ARF as it is currently written and
used. We might be better off keeping the two separate.

HOWEVER, if you want to talk about taking the existing ARF, making a
version 2.0 or IRF/INCH-lite, etc, as a generic abuse format, not just
for email - that is a totally different animal.

What it seems that you have in mind is a three part format - first
part for humans, second part for machines and third part for evidence.
Instead of having one ARF-1.0 report for each spam email, we are
talking about one ARF-2.0 report for each incident. Of course, mapping
INCH to ARF-2.0 is possible as well. The second part would have fields
with data in them, and the third part would be set to whatever MIME
type is used for logs and evidence.

Abuse desks that deal with ARF now are the same ones that deal with
all abuse issues and it would make sense to have a single format. It
is just that the current format of ARF is not suitable for that. It
might be prudent to fix the current format in whatever form it is used
right now (1.0), publish an RFC, and move on to 2.0 format that is
more generic.

What I am also guessing is that IO-DEF/INCH and its XML base makes
things too heavy for most ISPs. ARF is much simpler and this is
probably why ISPs are interested in using it for all kinds of abuse
reporting.

Yakov

2009/9/18 Tobias Knecht <[email-masked]>:
> Hi,
>
> this is just a information for people in this WG and has nothing to do
> with my personal opinion.
>
> This is the proposal that was made by BSI (Government Security
> Ministry), eco (German ISP Association), us (abusix.org) and a lot other
> huge European ISPs. Thanks to Dietmar for putting it in on another way.
>
> Since we got the feedback from this group, that it is not wanted to add
> these things into ARF, we decided on Monday (German Anti Spam Summit)
> that there will be an ARF extension or a complete new standard based and
> downwardly compatible to ARF for these kinds of abusive behavior.
>
> The feedback from European ISPs, and even some from the US was, that it
> would make sense to them to change to the "new format" as soon as their
> abuse departments can see more different kinds of abusive behavior
> within one standardized format.
>
> And yes there is INCH/IODEF and we decided that it's not sufficient for
> the needs we have.
>
> Thanks,
>
> Tobias
>
>
> Murray S. Kucherawy schrieb:
>> After the MAAWG conference in June, I received the following list of suggested extensions to be considered.  I've included them already in the proposed working group draft but so far the submissions were anonymous.  The author gave me permission to forward his mail to the list, and he'll be joining shortly.  Not all of them may be appropriate for ARF but they're probably worth discussing as we consider what extensions should be pursued.
>>
>> -----Original Message-----
>> From: Dietmar Braun [mailto:[email-masked]]
>> Sent: Thursday, June 25, 2009 4:48 AM
>> To: Murray S. Kucherawy
>> Subject: Re: FW: Another ARF expansion request
>>
>> Hi,
>>
>> Wednesday, June 17, 2009, 6:59:24 PM, you wrote:
>>>> We thought about extending ARF (which now is primarily for email abuse
>>>> issues) to some other types of complaints like firewall logs, scans,
>>>> brute force attacks, phishing etc...
>>>>
>>>> What do you think about that?
>>
>>> It already covers phishing ("fraud"), but the other cases are
>>> interesting.  Do you have some text written up already to add the new report types, etc.?
>>
>> We discussed the following issues:
>>
>> 1) drop boxes
>> original mail from (mail address of the sender, required)
>> arrival date (date of sending, required)
>> description (text description, required)
>> incidents (counter, how many times stolen information was sent to this
>> adress, required)
>> phishing URL (url of phishing site, optional)
>>
>> 2) spam sending botnet
>> source IP (required)
>> start date (date, required)
>> end date (date, required)
>> description (text, required)
>> incidents (counter, required)
>>
>> 3) SSH attacks
>> source IP (required)
>> start date (date, required)
>> end date (date, required)
>> description (text, required)
>> incidents (counter, required)
>> username (username which was tried, optional)
>> logdata (text log data, optional)
>>
>> 4) FTP attacks
>> source IP (required)
>> start date (date, required)
>> end date (date, required)
>> description (text, required)
>> incidents (counter, required)
>> username (username which was tried, optional)
>> logdata (text log data, optional)
>>
>> 5) web server attacks
>> source IP (required)
>> date (date, required)
>> description (text, required)
>> malware URL (text, optional)
>> malware type (text, optional)
>>
>> 6) Honeypot target
>> source IP (required)
>> date (date, required)
>> description (text, required)
>> malware URL (text, optional)
>> malware type (text, optional)
>>
>> 7) Sinkholes (malware)
>> source IP (required)
>> date (date, required)
>> description (text, required)
>> URL (text, required)
>> identifier (additional information, optional)
>>
>> 8) spam trap
>> source IP (required)
>> date (date, required)
>> description (text, required)
>> subject (text, required)
>> header (text, required)
>>
>> 9) harvester report
>> source IP (required)
>> date (date, required)
>> description (text, required)
>> user agent (text, required)
>> Operating system (text, required)
>>
>> 10) DDOS
>> source IP (required)
>> start date (date, required)
>> end date (date, required)
>> description (text, required)
>> destination IP (IP address, required)
>>
>> 11) Phishing Mail
>> mail from (mail address, required)
>> arrival date (date, required)
>> description (text, required)
>> phishing URL (required)
>> additional description (text, optional)
>>
>> 12) Others
>> mail from (mail address of the complainer, required)
>> date (date of the complaint, required)
>> description (text, required)
>>
>> Perhaps this is a bit too much (you could probably merge some of the
>> complaint types together to one), but just as ideas...
>>
>> Regards,
>> Dietmar
>>
>
>
> _______________________________________________
> abuse-feedback-report mailing list
> [email-masked]
> http://mipassoc.org/mailman/listinfo/abuse-feedback-report
>
>

From: "Murray S. Kucherawy" <[email-masked]>
To: Tobias Knecht <[email-masked]>
Date: Fri, 18 Sep 2009 12:08:16 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] FW: Another ARF expansion request

> -----Original Message-----
> From: Tobias Knecht [mailto:[email-masked]]
> Sent: Friday, September 18, 2009 10:23 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [feedback-report] FW: Another ARF expansion request
> 
> [...]
> 
> And yes there is INCH/IODEF and we decided that it's not sufficient for
> the needs we have.

Can you go into detail as to why?  If INCH is missing something, maybe they should consider adding it, and I'd like to be sure that ARF isn't missing something important as well.  On the other hand, if there's a solid answer as to why INCH won't live up to the needs of this community, that's a good argument for considering some amendments to ARF.

I think we would just want to be sure that we're not needlessly overlapping the work produced by other working groups by taking on ideas that appear to be out-of-scope.

-MSK

Date: Fri, 18 Sep 2009 15:23:51 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Tobias Knecht <[email-masked]>
Cleverness: None detected
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] FW: Another ARF expansion request

> Since we got the feedback from this group, that it is not wanted to add
> these things into ARF, we decided on Monday (German Anti Spam Summit)
> that there will be an ARF extension or a complete new standard based and
> downwardly compatible to ARF for these kinds of abusive behavior.

Sounds great.  Who is "we"?  This sounds like something that needs 
coordination with MAAWG, since that's where you find the large ISPs.

> And yes there is INCH/IODEF and we decided that it's not sufficient for
> the needs we have.

I don't disagree, but what in particular makes IODEF insufficient, and why 
would you rather start over than add report types to IODEF?

R's,
John

Date: Fri, 18 Sep 2009 19:23:09 +0200
From: Tobias Knecht <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] FW: Another ARF expansion request

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigEE9FE09675D9E693A281252F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

this is just a information for people in this WG and has nothing to do
with my personal opinion.

This is the proposal that was made by BSI (Government Security
Ministry), eco (German ISP Association), us (abusix.org) and a lot other
huge European ISPs. Thanks to Dietmar for putting it in on another way.

Since we got the feedback from this group, that it is not wanted to add
these things into ARF, we decided on Monday (German Anti Spam Summit)
that there will be an ARF extension or a complete new standard based and
downwardly compatible to ARF for these kinds of abusive behavior.

The feedback from European ISPs, and even some from the US was, that it
would make sense to them to change to the "new format" as soon as their
abuse departments can see more different kinds of abusive behavior
within one standardized format.

And yes there is INCH/IODEF and we decided that it's not sufficient for
the needs we have.

Thanks,

Tobias

Murray S. Kucherawy schrieb:
> After the MAAWG conference in June, I received the following list of su=
ggested extensions to be considered.  I've included them already in the p=
roposed working group draft but so far the submissions were anonymous.  T=
he author gave me permission to forward his mail to the list, and he'll b=
e joining shortly.  Not all of them may be appropriate for ARF but they'r=
e probably worth discussing as we consider what extensions should be purs=
ued.
>=20
> -----Original Message-----
> From: Dietmar Braun [mailto:[email-masked]]=20
> Sent: Thursday, June 25, 2009 4:48 AM
> To: Murray S. Kucherawy
> Subject: Re: FW: Another ARF expansion request
>=20
> Hi,
>=20
> Wednesday, June 17, 2009, 6:59:24 PM, you wrote:
>>> We thought about extending ARF (which now is primarily for email abus=
e
>>> issues) to some other types of complaints like firewall logs, scans,
>>> brute force attacks, phishing etc...
>>>
>>> What do you think about that?
>=20
>> It already covers phishing ("fraud"), but the other cases are
>> interesting.  Do you have some text written up already to add the new =
report types, etc.?
>=20
> We discussed the following issues:
>=20
> 1) drop boxes
> original mail from (mail address of the sender, required)
> arrival date (date of sending, required)
> description (text description, required)
> incidents (counter, how many times stolen information was sent to this
> adress, required)
> phishing URL (url of phishing site, optional)
>=20
> 2) spam sending botnet
> source IP (required)
> start date (date, required)
> end date (date, required)
> description (text, required)
> incidents (counter, required)
>=20
> 3) SSH attacks
> source IP (required)
> start date (date, required)
> end date (date, required)
> description (text, required)
> incidents (counter, required)
> username (username which was tried, optional)
> logdata (text log data, optional)
>=20
> 4) FTP attacks
> source IP (required)
> start date (date, required)
> end date (date, required)
> description (text, required)
> incidents (counter, required)
> username (username which was tried, optional)
> logdata (text log data, optional)
>=20
> 5) web server attacks
> source IP (required)
> date (date, required)
> description (text, required)
> malware URL (text, optional)
> malware type (text, optional)
>=20
> 6) Honeypot target
> source IP (required)
> date (date, required)
> description (text, required)
> malware URL (text, optional)
> malware type (text, optional)
>=20
> 7) Sinkholes (malware)
> source IP (required)
> date (date, required)
> description (text, required)
> URL (text, required)
> identifier (additional information, optional)
>=20
> 8) spam trap
> source IP (required)
> date (date, required)
> description (text, required)
> subject (text, required)
> header (text, required)
>=20
> 9) harvester report
> source IP (required)
> date (date, required)
> description (text, required)
> user agent (text, required)
> Operating system (text, required)
>=20
> 10) DDOS
> source IP (required)
> start date (date, required)
> end date (date, required)
> description (text, required)
> destination IP (IP address, required)
>=20
> 11) Phishing Mail
> mail from (mail address, required)
> arrival date (date, required)
> description (text, required)
> phishing URL (required)
> additional description (text, optional)
>=20
> 12) Others
> mail from (mail address of the complainer, required)
> date (date of the complaint, required)
> description (text, required)
>=20
> Perhaps this is a bit too much (you could probably merge some of the
> complaint types together to one), but just as ideas...
>=20
> Regards,
> Dietmar
>=20

--------------enigEE9FE09675D9E693A281252F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigEE9FE09675D9E693A281252F--

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 18 Sep 2009 13:35:11 -0400
To: "Murray S. Kucherawy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] FW: Another ARF expansion request

On Fri, Sep 18, 2009 at 1:20 PM, Murray S. Kucherawy <[email-masked]> wrote:
>> These are all entirely reasonable things to report in automated or
>> semi-automated ways, but I'd rather not try and shoehorn them all into
>> a
>> format designed to report single e-mail messages.
>>
>> I'd suggest that people look at the various INCH documments, since they
>> have already addressed a lot of these same issues.  There may turn out
>> to
>> be some fatal problem with INCH that makes it unsuitable, but since it
>> represents quite a few years' work by smart people thinking about very
>> similar problems to ours, we should at least make an informed decision
>> whether or not to use it.
>>
>> See http://www.cert.org/ietf/inch/inch.html
>
> +1 to all of that.  I was simply encouraging discussion. :)
>

I agree with both of you. I would also like to add that ARF is a "son
of" RFC 3462 which is a MIME type for "Reporting of Mail System
Administrative Messages". While spam botnets fit within the definition
(barely), things like FTP attacks are way out of scope.

> Is anyone on this list using INCH?  Or if anyone has made a conscious decision not to pursue INCH, can you share your reasons with the group?
>

I would also like to add that if anyone feels that INCH is too
complex, they can consider making an ARF-like format for INCH (I guess
INCH-lite or Incident Reporting Format / IRF?). But that again would
be out of scope for this group and is something that INCH WG or the
security AD would need to look into.

ARF works because it is simple. Making it more complicated would
dissuade people from using it.

Yakov

From: "Murray S. Kucherawy" <[email-masked]>
To: "John R. Levine" <[email-masked]>
Date: Fri, 18 Sep 2009 10:20:36 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] FW: Another ARF expansion request

> These are all entirely reasonable things to report in automated or
> semi-automated ways, but I'd rather not try and shoehorn them all into
> a
> format designed to report single e-mail messages.
> 
> I'd suggest that people look at the various INCH documments, since they
> have already addressed a lot of these same issues.  There may turn out
> to
> be some fatal problem with INCH that makes it unsuitable, but since it
> represents quite a few years' work by smart people thinking about very
> similar problems to ours, we should at least make an informed decision
> whether or not to use it.
> 
> See http://www.cert.org/ietf/inch/inch.html

+1 to all of that.  I was simply encouraging discussion. :)

Is anyone on this list using INCH?  Or if anyone has made a conscious decision not to pursue INCH, can you share your reasons with the group?

-MSK

Date: Fri, 18 Sep 2009 13:16:23 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cleverness: None detected
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] FW: Another ARF expansion request

> We discussed the following issues:
>
> 1) drop boxes
> 2) spam sending botnet
> 3) SSH attacks
> 4) FTP attacks
> 5) web server attacks
> 6) Honeypot target
> 7) Sinkholes (malware)
> 8) spam trap
> 9) harvester report
> 10) DDOS
> 11) Phishing Mail
> 12) Others

These are all entirely reasonable things to report in automated or 
semi-automated ways, but I'd rather not try and shoehorn them all into a 
format designed to report single e-mail messages.

I'd suggest that people look at the various INCH documments, since they 
have already addressed a lot of these same issues.  There may turn out to 
be some fatal problem with INCH that makes it unsuitable, but since it 
represents quite a few years' work by smart people thinking about very 
similar problems to ours, we should at least make an informed decision 
whether or not to use it.

See http://www.cert.org/ietf/inch/inch.html

R's,
John

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 18 Sep 2009 09:29:04 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: [feedback-report] FW: Another ARF expansion request

After the MAAWG conference in June, I received the following list of suggested extensions to be considered.  I've included them already in the proposed working group draft but so far the submissions were anonymous.  The author gave me permission to forward his mail to the list, and he'll be joining shortly.  Not all of them may be appropriate for ARF but they're probably worth discussing as we consider what extensions should be pursued.

-----Original Message-----
From: Dietmar Braun [mailto:[email-masked]] 
Sent: Thursday, June 25, 2009 4:48 AM
To: Murray S. Kucherawy
Subject: Re: FW: Another ARF expansion request

Hi,

Wednesday, June 17, 2009, 6:59:24 PM, you wrote:
>> We thought about extending ARF (which now is primarily for email abuse
>> issues) to some other types of complaints like firewall logs, scans,
>> brute force attacks, phishing etc...
>> 
>> What do you think about that?

> It already covers phishing ("fraud"), but the other cases are
> interesting.  Do you have some text written up already to add the new report types, etc.?

We discussed the following issues:

1) drop boxes
original mail from (mail address of the sender, required)
arrival date (date of sending, required)
description (text description, required)
incidents (counter, how many times stolen information was sent to this
adress, required)
phishing URL (url of phishing site, optional)

2) spam sending botnet
source IP (required)
start date (date, required)
end date (date, required)
description (text, required)
incidents (counter, required)

3) SSH attacks
source IP (required)
start date (date, required)
end date (date, required)
description (text, required)
incidents (counter, required)
username (username which was tried, optional)
logdata (text log data, optional)

4) FTP attacks
source IP (required)
start date (date, required)
end date (date, required)
description (text, required)
incidents (counter, required)
username (username which was tried, optional)
logdata (text log data, optional)

5) web server attacks
source IP (required)
date (date, required)
description (text, required)
malware URL (text, optional)
malware type (text, optional)

6) Honeypot target
source IP (required)
date (date, required)
description (text, required)
malware URL (text, optional)
malware type (text, optional)

7) Sinkholes (malware)
source IP (required)
date (date, required)
description (text, required)
URL (text, required)
identifier (additional information, optional)

8) spam trap
source IP (required)
date (date, required)
description (text, required)
subject (text, required)
header (text, required)

9) harvester report
source IP (required)
date (date, required)
description (text, required)
user agent (text, required)
Operating system (text, required)

10) DDOS
source IP (required)
start date (date, required)
end date (date, required)
description (text, required)
destination IP (IP address, required)

11) Phishing Mail
mail from (mail address, required)
arrival date (date, required)
description (text, required)
phishing URL (required)
additional description (text, optional)

12) Others
mail from (mail address of the complainer, required)
date (date of the complaint, required)
description (text, required)

Perhaps this is a bit too much (you could probably merge some of the
complaint types together to one), but just as ideas...

Regards,
Dietmar

-- 
NetCologne Gesellschaft fuer Telekommunikation mbH
Am Coloneum 9, 50829 Koeln
Geschaeftsfuehrer: Werner Hanf, Dipl.-Ing. Karl-Heinz Zankel
HRB 25580, AG Koeln

Date: Fri, 18 Sep 2009 11:09:10 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Alessandro Vesely <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] IETF draft on dealing with bots

I think Mike's botnet draft is just dandy, but it's really time for you to 
stop wasting everyone's time trying to turn ARF into an all-purpose 
reporting blob.

The authors of the botnet draft are quite familiar with ARF, and use it 
for their FBL reports of individual messages.  I suppose one could add a 
flag saying "this looks like bot spam" but any ISP that doesn't already 
know that spam coming directly from consumer PCs means there's a bot isn't 
likely to do anything useful with such a flag.

If you want INCH, you know where to find it.  It's not here.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

Date: Thu, 17 Sep 2009 17:01:19 +0200
From: Alessandro Vesely <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [feedback-report] IETF draft on dealing with bots

Yakov Shafranovich wrote:
> Somewhat relevant to our work:
> 
> http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03

Yes, "botnet detection" is the #2 reporting extension in Murray's WG 
draft[1]. When I mentioned this I-D[2], I hypothesized the group 
interest could be extended to the dynamics of forwarding FBLs. At any 
rate, since the I-D has been already mentioned twice in this list, I 
take the liberty to CC to its authors.
[1] 
http://mipassoc.org/pipermail/abuse-feedback-report/attachments/20090901/ffffcfcd/attachment.txt
[2] http://mipassoc.org/pipermail/abuse-feedback-report/2009q3/000319.html

In the rest of this message I just quote a few passages from the I-D. 
The term "ISP" is used right from the title, "Recommendations for the 
Remediation of Bots in ISP Networks". In section 3, "Introduction and 
Problem Statement", it is made explicit that it means those "providing 
IP connectivity, among many other services, to Internet users". That 
is, not specifically "mailbox providers".

"Detection of Bots", section 5 of the I-D, contains the two 
recommendations quoted below; I think that's where the relevance to 
our work is more evident.

  b.  An ISP may also communicate and share selected data, via feedback
      loops or other mechanisms, with various third parties.  Feedback
      loops are consistently formatted feeds of real-time (or nearly
      real-time) abuse reports offered by threat data clearinghouses,
      security alert organizations, other ISPs, and other
      organizations.  The data may include, but is not limited to,
      lists of the IP addresses computers which have or are likely to
      have a bot running, domain names or fully qualified domain names
      (FQDNs) known to host malware and/or be involved in the command
      and control of botnets, IP addresses know to host malware and/or
      be involved in the command and control of botnets, recently
      tested or discovered techniques or detecting or remediating bot
      infections, new threat vectors, and other relevant information.
      Good examples of this include SNDS from Microsoft, XBL and PBL
      from Spamhaus and the DSHIELD AS tool from the SANS Institue.

  e.  User complaints: Because hosts infected by bots are frequently
      used to send spam or participate in DDoS attacks, the ISP
      servicing those hosts will normally receive complaints about the
      malicious network traffic.  Those complaints may be sent to
      RFC2142-specified [RFC2142] role accounts, such as abuse@ or
      postmaster@ or to abuse or security addresses specified by the
      site as part of its WHOIS (or other) contact data.

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 16 Sep 2009 14:42:33 -0400
To: [email-masked]
Subject: [feedback-report] IETF draft on dealing with bots

Somewhat relevant to our work:

http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03

Date: Wed, 09 Sep 2009 09:42:32 +0200
From: Alessandro Vesely <[email-masked]>
To: "J.D. Falk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] ESP (was Re:  ARF working group interest?)

J.D. Falk wrote:
> I'm partial to the term "mailbox provider," but that's still relatively new.

+1, as it is less ambiguous.

Date: Tue, 08 Sep 2009 13:29:10 -0700
From: "J.D. Falk" <[email-masked]>
To: [email-masked]
Subject: [feedback-report] ESP (was Re:  ARF working group interest?)

Alessandro Vesely wrote:
> J.D. Falk wrote:
>> I believe your use of the acronym "ESP" may be different from others'.
>
> I use it for Email Service Provider, what is it being confused with?

Many of the folks who use ARF today use "ESP" to describe companies which 
send bulk email on behalf of other companies.  That's an email service, but 
I don't think it's the email service you're talking about.  There are a lot 
of other email services, too.

I'm partial to the term "mailbox provider," but that's still relatively new.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Date: Sat, 5 Sep 2009 16:41:55 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Steve Atkins <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?)

>> I think that's OK give or take the SMTP AUTH issue.

> I was assuming that the magic email address would be different for
> each message, and potentially long and full of crypto and message ids
> and user identifiers and per-message metadata and secret cookies and
> hashes and things. (I may just have been doing too much work with VERP
> recently).

Oh, duh, of course.  That should work fine.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Sat, 5 Sep 2009 13:03:06 -0700
Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?)

On Sep 5, 2009, at 10:12 AM, John R. Levine wrote:

>> as trivial to implement as a header, added by the mailbox provider  
>> MDA,
>> with "Feedback-Reports-To: <magic email address>" and a TiS button  
>> that
>> sends the associated message as a MIME attachment to that email
>> address would work[1].
>
> I think that's OK give or take the SMTP AUTH issue.  If I were an  
> ISP, I would think it were nice if I could be reasonably sure that I  
> knew who the reports were coming from.  I suppose we could wave our  
> hands and say to use whatever outgoing channel matches the incoming  
> channel, and that would work almost as well as something a lot more  
> complicated.  We could give a hint to the ISP that they might want  
> to put in some other header that they could use to recognize which  
> of their customers the mail was delivered to.

I was assuming that the magic email address would be different for  
each message, and potentially long and full of crypto and message ids  
and user identifiers and per-message metadata and secret cookies and  
hashes and things. (I may just have been doing too much work with VERP  
recently).

Cheers,
   Steve

Date: Sat, 5 Sep 2009 13:12:12 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Steve Atkins <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?)

> as trivial to implement as a header, added by the mailbox provider MDA,
> with "Feedback-Reports-To: <magic email address>" and a TiS button that
> sends the associated message as a MIME attachment to that email
> address would work[1].

I think that's OK give or take the SMTP AUTH issue.  If I were an ISP, I 
would think it were nice if I could be reasonably sure that I knew who the 
reports were coming from.  I suppose we could wave our hands and say to 
use whatever outgoing channel matches the incoming channel, and that would 
work almost as well as something a lot more complicated.  We could give a 
hint to the ISP that they might want to put in some other header that they 
could use to recognize which of their customers the mail was delivered to.

R's,
John

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Sat, 5 Sep 2009 09:10:33 -0700
Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?)

On Sep 4, 2009, at 10:23 AM, Yakov Shafranovich wrote:

> On Fri, Sep 4, 2009 at 10:43 AM, Michael
> Adkins<[email-masked]> wrote:
>> Yakov Shafranovich wrote:
>>> Are we talking about users sending reports to their own ISP, or to  
>>> any ISP?
>>>
>> To the mailbox provider for the specific account the spam was sent  
>> to.
>>
>
> Thanks Michael.
>
> If so, why not an SMTP SUBMIT extension?

It's not unusual for inbound mail and outbound mail to be unrelated, so
there may not be any SMTP connection related to the mailbox.

That doesn't mean that an SMTP SUBMIT extension (or one of the simpler
SMTP level ideas) isn't interesting to look at, but it wouldn't be  
usable in
all cases.

I'm not sure that attempting to support IMAP, POP3, deltasync and so on
makes any sense either. I'd rather build something that wasn't  
intimately
tied to a particular connection that an MUA happened to have open,  
rather
relying on something that any MUA can implement easily.

Depending on how much we cared about the threat model, something
as trivial to implement as a header, added by the mailbox provider MDA,
with "Feedback-Reports-To: <magic email address>" and a TiS button that
sends the associated message as a MIME attachment to that email
address would work[1].

Cheers,
   Steve

[1] Yes, this can be spoofed by spammers. But, (A), I'm not necessarily
sure that's a terrible thing and (B) it can be protected against that  
fairly
trivially.

Date: Sat, 5 Sep 2009 00:18:03 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?)

>> To the mailbox provider for the specific account the spam was sent to.

> If so, why not an SMTP SUBMIT extension?

Not a bad thought, although I worry that there are accounts with inbound 
POP or IMAP servers but no outbound server, because they either don't 
expect you to send mail from that address, or they expect you to have some 
other way to send it.

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 4 Sep 2009 13:23:14 -0400
To: Michael Adkins <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?)

On Fri, Sep 4, 2009 at 10:43 AM, Michael
Adkins<[email-masked]> wrote:
> Yakov Shafranovich wrote:
>> Are we talking about users sending reports to their own ISP, or to any ISP?
>>
> To the mailbox provider for the specific account the spam was sent to.
>

Thanks Michael.

If so, why not an SMTP SUBMIT extension?

Yakov

Date: Fri, 04 Sep 2009 10:43:31 -0400
From: Michael Adkins <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?)

Yakov Shafranovich wrote:
> Are we talking about users sending reports to their own ISP, or to any ISP?
>
> Yakov
>   
To the mailbox provider for the specific account the spam was sent to.

> On Thu, Sep 3, 2009 at 4:14 PM, J.D. Falk<[email-masked]> wrote:
>   
>> Michael Adkins wrote:
>>
>>     
>>> So would there be interest in a standard way for 3rd party mail clients
>>> to know where to send a report to their provider, who could then send it
>>> on to the originator if they chose to?
>>>       
>> I think that would be a very appropriate thing for this WG to address.
>>
>> It could be extremely simple
>> - authenticated SMTP submission of a raw message to a preconfigured address
>> - a way for the MUA to auto-discover the submission address
>>
>> --
>> J.D. Falk
>> Return Path Inc
>> http://www.returnpath.net/
>> _______________________________________________
>> abuse-feedback-report mailing list
>> [email-masked]
>> http://mipassoc.org/mailman/listinfo/abuse-feedback-report
>>
>>     
> _______________________________________________
> abuse-feedback-report mailing list
> [email-masked]
> http://mipassoc.org/mailman/listinfo/abuse-feedback-report
>   

Date: Fri, 4 Sep 2009 08:41:31 -0400
From: Todd Herr <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] ARF working group interest?

On Fri, Sep 04, 2009 at 01:01:09PM +0200, Alessandro Vesely wrote:
> J.D. Falk wrote:
> > I believe your use of the acronym "ESP" may be different from others'.
> 
> I use it for Email Service Provider, what is it being confused with?
> 
> I use it to differentiate from ISPs, who provide cables, routing, and 
> global IP ranges. It's consistent with the IP vs domain dichotomy.

Here in the US, the term ESP also means Email Service Provider, but
it refers to a class of company that's usually engaged by email senders
with a need to send a quantity of commercial email and a desire to do
the job right.  In the context of the whole ARF discussion, ESPs in the
US would, on behalf of their clients, be recievers of FBL reports, not
producers of them.

An ISP here in the US, along with, for instance, Hotmail, Yahoo, and 
Gmail, would fall into a class of company called "mailbox providers",
and their customers would be the ones generating complaints that could
be turned into FBL reports and sent along to the proper reporting
destination.

-- 
Todd Herr
Principal Engineer and Postmaster              V: 703.345.2447
Road Runner Email Operations                   M: 571.287.0366
[email-masked]                        AIM: RRMailToddHerr

Date: Fri, 04 Sep 2009 13:13:44 +0200
From: Alessandro Vesely <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: [feedback-report] ARF submission and forwarding

John R. Levine wrote:
> I can think of two general approaches.  One somehow adds the report 
> address to the per-account config, the other to the messages.  I'd prefer 
> to do the config, except that config is already a painful swamp which 
> isn't likely to be drained any time soon.

It could default to abuse@domain, where "domain" is obtained from the 
current identity of the user. In the simple cases, that implies 
submission through an already configured MSA, which is also (near to) 
the target of the message. Advanced users, with multiple accounts at 
different ESPs, may have to configure ARF-specific MSAs to avoid 
unnecessary filtering.

Hence, at the ARF target, the first decision about a report being 
received is to establish whether it is of local concern, which 
normally is the case for FBL feeds. However, spam being reported by 
local users may well have originated from the same domain. This 
justifies the usage of the same abuse@ role account.

Reports about non-local spam, may be forwarded directly or submitted 
to various third parties, as Todd has described. IMHO, this network of 
FBL exchanges is the most crippled part of the game, as it's difficult 
to establish and maintain. Postmaster should rather concentrate on 
clearing local reports.

Date: Fri, 04 Sep 2009 13:01:09 +0200
From: Alessandro Vesely <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] ARF working group interest?

J.D. Falk wrote:
> I believe your use of the acronym "ESP" may be different from others'.

I use it for Email Service Provider, what is it being confused with?

I use it to differentiate from ISPs, who provide cables, routing, and 
global IP ranges. It's consistent with the IP vs domain dichotomy.

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 3 Sep 2009 23:05:27 -0400
To: Tobias Knecht <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] ARF working group interest?

2009/9/3 Tobias Knecht <[email-masked]>:
>
> I'm not sure if I understand this discussion right. We are talking about
> a format. A format that describes the look of data. We are not talking
> about processes and business logic.
>
> If an ISP receives complaints from different sources, the trustlevel is
> a subjective estimation. Sending it to a special address or having an
> agreement does not predict that they are more trusted. Most of the time
> this will be the case, but it's is not exclusively that way. Some
> European ISPs rate "trusted" complaints different, because some
> "trusted" senders are more trusted than others.
>
> So the decision on how to handle the incoming complaints is a process
> that has to be defined in the business logic of the receiver and nowhere
> else.
>
> IMHO ARF is just the format to exchange data.

And I concur - ARF is just a format. As the current draft states:

"  This document only defines the format and [MIME] content type to be
   used for these reports.  Determination of where these reports should
   be sent, how trust among report generators and report recipients is
   established, and reports related to more than one message are outside
   the scope of this document.  It is assumed that best practices will
   evolve over time, and will be codified in future documents.
"

It might be a good idea is to write up a parallel informational RFCs
on best practices for using ARF or reporting spam, especially if we
can draw from the wide variety of experiences provided here and via
MAAWG. I believe that Carl Hutzler (AOL postmaster at the time) tried
to do something similar for spam operations in general and it was
published as RFC 5068:

http://tools.ietf.org/html/rfc5068

Yakov

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 3 Sep 2009 23:01:51 -0400
To: ARF mailing list <[email-masked]>
Subject: [feedback-report] Munging ARF reports

--0016e64714e2f2e2620472b7b950
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

We has this discussion several years ago, primarily with AOL. The
compromise at the time appears in section 2d of the current draft as
follows:

"      While some operators may choose to
       modify or redact this portion for privacy or legal reasons, it is
       RECOMMENDED that the entire original email message be included
       without any modification as such modifications can impede
       forensic work by the recipient of this report.
"

I believe that the current language should address all sides.

Yakov

---------- Forwarded message ----------
From: Tobias Knecht <[email-masked]>

John R. Levine schrieb:
>>> Sorry, but that's just wrong. =A0Several large ISPs send me fully
>>> unredacted
>>> copies of messages in FBL reports.
>>
>> Sending unredacted complaints to a third party with personal information
>> of end-users is an absolute no-go in Germany.
>
> Perhaps, but the IETF most definitely does not offer legal advice.

I just wanted to mention that it is not wise to put munging rules into
the draft, if they will make legal problems in future.

--0016e64714e2f2e2620472b7b950
Content-Type: application/pgp-signature; name="signature.asc"
Content-Disposition: attachment; filename="signature.asc"
Content-Transfer-Encoding: base64
X-Attachment-Id: 0.0.1

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC45IChHTlUv
TGludXgpCkNvbW1lbnQ6IFVzaW5nIEdudVBHIHdpdGggTW96aWxsYSAtIGh0dHA6Ly9lbmlnbWFp
bC5tb3pkZXYub3JnCgppRVlFQVJFQ0FBWUZBa3FnTnNNQUNna1F2QjRNNXlReXFEZlY4UUNlUFVP
ZDJ4WDVaaTdCelhCYnVsZnIrb3FlCkEvTUFvTUJZZHRlQjZxU1Z2YzA2Mm9MOVU3YmUvTVRTCj1m
bjBxCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo=
--0016e64714e2f2e2620472b7b950--

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 3 Sep 2009 22:58:22 -0400
To: "J.D. Falk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] end user submission of feedback (was Re: ARF working group interest?)

Are we talking about users sending reports to their own ISP, or to any ISP?

Yakov

On Thu, Sep 3, 2009 at 4:14 PM, J.D. Falk<[email-masked]> wrote:
> Michael Adkins wrote:
>
>> So would there be interest in a standard way for 3rd party mail clients
>> to know where to send a report to their provider, who could then send it
>> on to the originator if they chose to?
>
> I think that would be a very appropriate thing for this WG to address.
>
> It could be extremely simple
> - authenticated SMTP submission of a raw message to a preconfigured address
> - a way for the MUA to auto-discover the submission address
>
> --
> J.D. Falk
> Return Path Inc
> http://www.returnpath.net/
> _______________________________________________
> abuse-feedback-report mailing list
> [email-masked]
> http://mipassoc.org/mailman/listinfo/abuse-feedback-report
>

Date: Thu, 03 Sep 2009 23:57:56 +0200
From: Tobias Knecht <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] ARF working group interest?

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4FC9E1F175FFC05CC12808D9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> RFCs aren't gonna trump lawyers' interpretations here.  However, mailer=
s=20
> can (and probably should, where appropriate) use VERPs, X- headers, or =

> other header information from the complaint to identify the redacted
> information from their own logs.

Full Ack.

>> Should ESPs verify that the stuff is actually spam or just forward it?=

>=20
> Verification is not a scalable solution, IMHO.  The staff required to
> read every complaint might run to the dozens, if not hundreds, and then=
=20
> separating the obvious spam from the might be spam (e.g., it's bulk, bu=
t=20
> do you know whether or not your customer signed up for this mailing?)=20
> from the clearly not spam would require resources that most ISPs don't =

> and won't have.  Besides, who would want a job for which the descriptio=
n
> is "Read spam complaints all day"?

Full Ack.

I'm not sure if I understand this discussion right. We are talking about
a format. A format that describes the look of data. We are not talking
about processes and business logic.

If an ISP receives complaints from different sources, the trustlevel is
a subjective estimation. Sending it to a special address or having an
agreement does not predict that they are more trusted. Most of the time
this will be the case, but it's is not exclusively that way. Some
European ISPs rate "trusted" complaints different, because some
"trusted" senders are more trusted than others.

So the decision on how to handle the incoming complaints is a process
that has to be defined in the business logic of the receiver and nowhere
else.

IMHO ARF is just the format to exchange data.

Tobias

--------------enig4FC9E1F175FFC05CC12808D9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig4FC9E1F175FFC05CC12808D9--

Date: Thu, 03 Sep 2009 23:36:03 +0200
From: Tobias Knecht <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig03352E751205BD98A60236C2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

John R. Levine schrieb:
>>> Sorry, but that's just wrong.  Several large ISPs send me fully
>>> unredacted
>>> copies of messages in FBL reports.
>>
>> Sending unredacted complaints to a third party with personal informati=
on
>> of end-users is an absolute no-go in Germany.
>=20
> Perhaps, but the IETF most definitely does not offer legal advice.

I just wanted to mention that it is not wise to put munging rules into
the draft, if they will make legal problems in future.

Tobias

--------------enig03352E751205BD98A60236C2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig03352E751205BD98A60236C2--

Date: Thu, 3 Sep 2009 17:29:17 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Tobias Knecht <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

>> Sorry, but that's just wrong.  Several large ISPs send me fully unredacted
>> copies of messages in FBL reports.
>
> Sending unredacted complaints to a third party with personal information
> of end-users is an absolute no-go in Germany.

Perhaps, but the IETF most definitely does not offer legal advice.

R's,
John

Date: Thu, 3 Sep 2009 17:22:41 -0400
From: Todd Herr <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] ARF working group interest?

On Thu, Sep 03, 2009 at 08:21:00PM +0200, Alessandro Vesely wrote:
> John R. Levine wrote:
>>>> * Where do you send them if you're trusted, or if you're untrusted
>>>
>>> In my experience, we only send FBL reports to those who've asked
>>> for them (and been approved for enrollment in our FBL)
>
> Would you expand on how do you approve enrollments? (Fully/partially  
> automated WHOIS lookup, I'd guess.) And how do ESPs find out where to  
> ask for enrollment?

We (Road Runner) have our own criteria that we don't publish, but
we do try to provide a reason for rejecting any IPs that we reject
in the message sent to the requester regarding their application
being processed.

Other ISPs have other criteria that may or may not match our own.

One place to find out about what FBLs are currently available is here:

  http://www.spamhaus.org/faq/answers.lasso?section=ISP%20Spam%20Issues#119

>
>> This is a good point.  FBL data (other than AOL) tends to be unredacted 
>> because you know who you're sending it to.
>
> The last thing one would do is to confirm users' addresses, or betray  
> honeypots. Will guidance for munging be part of the ARF spec?

AOL redacts because AOL's lawyers tell them they have to.

Road Runner redacts because our lawyers tell us we have to, but for
different reasons than AOL's lawyers.  Road Runner is Time Warner Cable's
High Speed Data service, and our lawyers think the 1984 US Cable Privacy
Act requires that we redact email addresses.  Other cable companies in
the US that offer FBLs may have different interpretations of that same
law.

RFCs aren't gonna trump lawyers' interpretations here.  However, mailers 
can (and probably should, where appropriate) use VERPs, X- headers, or 
other header information from the complaint to identify the redacted
information from their own logs.

>
>>> - Mailbox holders who are clued enough to read headers and make a
>>>  reasonable guess at the right place to which to complain
>>> - Mailbox holders who aren't clued enough to read headers
>>>
>>> For the latter two classes, providing them with a method to generate
>>> an ARF report is a large hurdle
>>
>> I don't think it's a good idea.  It makes much more sense to give  
>> individual users a button they can push to ask their provider to send a 
>> report on their behalf.
>
> I see no contradiction here: either users push a button to generate ARF 
> reports for their own ESPs (updated clients), or move spam messages to 
> ad-hoc IMAP folders (problematic clients) so that an ARF header can be 
> generated directly from the file (any added delay may help 
> anonymization.)

Regardless of the outcome of the button pressing, the hurdle's still 
much larger when the MUA is not controlled by the client.  There may 
be existing plug-ins already for things like Outlook Express, and
Thunderbird, and $YOUR_FAVORITE_MUA but getting customers to use them 
is not as easy as simply sending your customers an email and saying 
"Go download this cool plug-in".  If there's not an existing plug-in,
who's gonna build and support them?
 
>
> Should ESPs verify that the stuff is actually spam or just forward it?

Verification is not a scalable solution, IMHO.  The staff required to
read every complaint might run to the dozens, if not hundreds, and then 
separating the obvious spam from the might be spam (e.g., it's bulk, but 
do you know whether or not your customer signed up for this mailing?) 
from the clearly not spam would require resources that most ISPs don't 
and won't have.  Besides, who would want a job for which the description
is "Read spam complaints all day"?

-- 
Todd Herr
Principal Engineer and Postmaster              V: 703.345.2447
Road Runner Email Operations                   M: 571.287.0366
[email-masked]                        AIM: RRMailToddHerr

Date: Thu, 03 Sep 2009 22:19:10 +0200
From: Tobias Knecht <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF32112BB7B8B9FDED644EC79
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> Sorry, but that's just wrong.  Several large ISPs send me fully unredac=
ted=20
> copies of messages in FBL reports.

Sending unredacted complaints to a third party with personal information
of end-users is an absolute no-go in Germany.

If there is a legal need to redact information, it should be allowed
without getting in problems with the standards.

On the other side there are so many discussions about privacy policy in
Germany and all over Europe at the moment. The rules change with every
court decision nearly weekly at the moment. It would not be helpful to
make decisions and create standards now which could be completely
nonsense after the next election.

Tobias

--------------enigF32112BB7B8B9FDED644EC79
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigF32112BB7B8B9FDED644EC79--

Date: Thu, 03 Sep 2009 13:43:39 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

At 09:28 02-09-2009, Alessandro Vesely wrote:
>What I would suggest is to modify the name and the description of the
>WG so as to provide for further discussion on feedback loops, after
>the publication of the first RFC. Please note that this would be a
>completion, not an upset. Tentatively,

Murray's message was about gauging interest and drawing up a charter 
for a ARF WG.  The cut-off date to request a BoF is September 7, 2009.

If there is any interest in changing the name and/or the work to be 
done by the WG, it is better to do it soon as a BoF requires AD 
approval.  Discussions about the details of ARF will not help in 
getting the Charter approved in my opinion.

Regards,
-sm 

Date: Thu, 3 Sep 2009 16:24:28 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Steve Atkins <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

>> So would there be interest in a standard way for 3rd party mail clients 
>> to know where to send a report to their provider, who could then send 
>> it on to the originator if they chose to?
>
> Yes, definitely.

It's an interesting challenge to figure out how to do that in a way that 
will work, will be resistant to misuse (e.g. spammers providing fake 
info), and won't require major surgery to existing mail software.

Since it is quite common for a single MUA to collect mail from multiple 
accounts, it's important that there be an address per provider, not just 
one address per MUA.  My copy of Thunderbird, for example, collects mail 
from Yahoo, Hotmail, Gmail, AOL, and my own mail server, which may be a 
bit extreme but should still work.

I can think of two general approaches.  One somehow adds the report 
address to the per-account config, the other to the messages.  I'd prefer 
to do the config, except that config is already a painful swamp which 
isn't likely to be drained any time soon.

The other is to add a trace header to the top of each message along the 
lines of

  ARF-Info: to [email-masked] auth [email-masked]
      via submithost.bigisp.com:587

It's a trace header so the top one wins, deterring fakes. The idea of the 
auth clause is to give the MUA a hint about which account to use.  If the 
auth doesn't match one that the MUA already knows, there's no button for 
this message.

I realize this is kind of a kludge, but this at least avoids adding more 
config state to MUA setup.  Autodiscovery sounds like a great idea, but 
I'm having trouble figuring out how it would work unless you want to 
extend POP and IMAP with commands to fetch extended config info, which I 
fear would have serious political problems with the keepers of the POP and 
IMAP specs.

R's,
John

Date: Thu, 03 Sep 2009 14:17:38 -0600
From: "J.D. Falk" <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] ARF working group interest?

Alessandro Vesely wrote:

> Would you expand on how do you approve enrollments? (Fully/partially
> automated WHOIS lookup, I'd guess.) And how do ESPs find out where to
> ask for enrollment?

That's what the MAAWG document will focus on.  Really short version: people 
talk to each other.

>> This is a good point.  FBL data (other than AOL) tends to be unredacted
>> because you know who you're sending it to.
>
> The last thing one would do is to confirm users' addresses, or betray
> honeypots. Will guidance for munging be part of the ARF spec?

See the list archives for the last dozen times we had that discussion.

> Should ESPs verify that the stuff is actually spam or just forward it?

A complaint is a complaint.  Every known implementation today (there's about 
a dozen) simply forwards it.

I believe your use of the acronym "ESP" may be different from others'.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Date: Thu, 03 Sep 2009 14:14:38 -0600
From: "J.D. Falk" <[email-masked]>
To: [email-masked]
Subject: [feedback-report] end user submission of feedback (was Re: ARF working group interest?)

Michael Adkins wrote:

> So would there be interest in a standard way for 3rd party mail clients
> to know where to send a report to their provider, who could then send it
> on to the originator if they chose to?

I think that would be a very appropriate thing for this WG to address.

It could be extremely simple
- authenticated SMTP submission of a raw message to a preconfigured address
- a way for the MUA to auto-discover the submission address

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Thu, 3 Sep 2009 11:48:56 -0700
Subject: Re: [feedback-report] ARF working group interest?

On Sep 3, 2009, at 11:14 AM, Michael Adkins wrote:

>
>> I don't think it's a good idea.  It makes much more sense to give
>> individual users a button they can push to ask their provider to  
>> send a
>> report on their behalf.
>>
>>
>>
> +1
>
> So would there be interest in a standard way for 3rd party mail  
> clients
> to know where to send a report to their provider, who could then  
> send it
> on to the originator if they chose to?

Yes, definitely.

Cheers,
   Steve

Date: Thu, 3 Sep 2009 14:43:42 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Alessandro Vesely <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

>> This is a good point.  FBL data (other than AOL) tends to be unredacted 
>> because you know who you're sending it to.
>
> The last thing one would do is to confirm users' addresses, or betray 
> honeypots. Will guidance for munging be part of the ARF spec?

Sorry, but that's just wrong.  Several large ISPs send me fully unredacted 
copies of messages in FBL reports.

> I see no contradiction here: either users push a button to generate ARF 
> reports for their own ESPs (updated clients), or move spam messages to ad-hoc 
> IMAP folders (problematic clients) so that an ARF header can be generated 
> directly from the file (any added delay may help anonymization.)

I presume you mean ISP, not ESP.  In my experience abuse reports from end 
users are almost always useless.  Senders will often trust a report from 
the ISP but not from the end user since they'll have an FBL agreement with 
the ISP.

> Should ESPs verify that the stuff is actually spam or just forward it?

Wow, talk about a research topic.

R's,
John

Date: Thu, 03 Sep 2009 20:21:00 +0200
From: Alessandro Vesely <[email-masked]>
To: Todd Herr <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] ARF working group interest?

John R. Levine wrote:
>>> * Where do you send them if you're trusted, or if you're untrusted
>>
>> In my experience, we only send FBL reports to those who've asked
>> for them (and been approved for enrollment in our FBL)

Would you expand on how do you approve enrollments? (Fully/partially 
automated WHOIS lookup, I'd guess.) And how do ESPs find out where to 
ask for enrollment?

> This is a good point.  FBL data (other than AOL) tends to be unredacted 
> because you know who you're sending it to.

The last thing one would do is to confirm users' addresses, or betray 
honeypots. Will guidance for munging be part of the ARF spec?

>> - Mailbox holders who are clued enough to read headers and make a
>>  reasonable guess at the right place to which to complain
>> - Mailbox holders who aren't clued enough to read headers
>>
>> For the latter two classes, providing them with a method to generate
>> an ARF report is a large hurdle
> 
> I don't think it's a good idea.  It makes much more sense to give 
> individual users a button they can push to ask their provider to send a 
> report on their behalf.

I see no contradiction here: either users push a button to generate 
ARF reports for their own ESPs (updated clients), or move spam 
messages to ad-hoc IMAP folders (problematic clients) so that an ARF 
header can be generated directly from the file (any added delay may 
help anonymization.)

Should ESPs verify that the stuff is actually spam or just forward it?

Date: Thu, 03 Sep 2009 14:14:47 -0400
From: Michael Adkins <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] ARF working group interest?

> I don't think it's a good idea.  It makes much more sense to give 
> individual users a button they can push to ask their provider to send a 
> report on their behalf.
>
>
>   
+1

So would there be interest in a standard way for 3rd party mail clients
to know where to send a report to their provider, who could then send it
on to the originator if they chose to?

Date: Thu, 3 Sep 2009 12:58:50 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Todd Herr <[email-masked]>
Cleverness: None detected
Cc: [email-masked]
Subject: Re: [feedback-report] ARF working group interest?

>> * Where do you send them if you're trusted, or if you're untrusted
>
> In my experience, we only send FBL reports to those who've asked
> for them (and been approved for enrollment in our FBL)

This is a good point.  FBL data (other than AOL) tends to be unredacted 
because you know who you're sending it to.

> I have found that sending untrusted ARF reports to abuse@ results in
> responses ranging the gamut of:
>
> - Reply asking to please stop sending mail with attachments to abuse@
> - Reply asking to change format to something other than ARF
> - Reply asking to please send FBL to other address
> - Silence

I realize I'm a lot smaller than you, but I send about a million a month. 
Mostly I get silence.  I used to get a lot of don't send attachments, but 
that's dropped off considerably.

> - Mail providers (i.e., actual ISP mail operations staff)
> - Mailbox holders who are clued enough to read headers and make a
>  reasonable guess at the right place to which to complain
> - Mailbox holders who aren't clued enough to read headers
>
> For the latter two classes, providing them with a method to generate
> an ARF report is a large hurdle

I don't think it's a good idea.  It makes much more sense to give 
individual users a button they can push to ask their provider to send a 
report on their behalf.

R's,
John

Date: Thu, 3 Sep 2009 12:51:35 -0400
From: Todd Herr <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] ARF working group interest?

On Thu, Sep 03, 2009 at 12:20:49PM -0400, John R. Levine wrote:
> > What, I don't count anymore? ;)
> 
> Hey, this is the IETF where anecdotes about something that happened to 
> some guy with a Sun3 in 1998 count for more than the experience of global 
> mail providers.
> 
> > The vast majority of our FBLs also go to addresses other than abuse@.
> > Keeping all of those channels straight gets to be a cumbersome task on
> > both sides, especially as more and more mailbox providers become fbl
> > providers. I would be interested in a standard way to discover where to
> > route automated reports that I don't expect a response to, whether they
> > trust me as a report sender or not. I should be able to authenticate the
> > reports as coming from my system and let the report recipients decide
> > whether to process it or not based on that authentication, instead of
> > relying on shared secrets established when the channel was created.
> 
> Let's see if we can pick that apart a little.
> 
> For senders of reports:
> 
> * Where do you send them if you're trusted, or if you're untrusted

In my experience, we only send FBL reports to those who've asked
for them (and been approved for enrollment in our FBL), and then to 
the address that the requester has specified at the time of signup.

I have found that sending untrusted ARF reports to abuse@ results in 
responses ranging the gamut of:

- Reply asking to please stop sending mail with attachments to abuse@
- Reply asking to change format to something other than ARF
- Reply asking to please send FBL to other address
- Silence

I'd also add that when we speak of untrusted senders, we must divide
them into at least three categories:

- Mail providers (i.e., actual ISP mail operations staff)
- Mailbox holders who are clued enough to read headers and make a
  reasonable guess at the right place to which to complain
- Mailbox holders who aren't clued enough to read headers

For the latter two classes, providing them with a method to generate
an ARF report is a large hurdle, because it's going to have be something
done inside the mail client, with one click of the mouse/one keystroke.
Mail providers alone cannot shoulder that burden if they don't provide
their customers with a uniform client and a uniform method of accessing
their mail.

I *heart* ARF, but I believe it's only effective at this time when 
there's a trust relationship involved.  

-- 
Todd Herr
Principal Engineer and Postmaster              V: 703.345.2447
Road Runner Email Operations                   M: 571.287.0366
[email-masked]                        AIM: RRMailToddHerr

Date: Thu, 03 Sep 2009 10:30:41 -0600
From: "J.D. Falk" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

John R. Levine wrote:

> ARF is a perfectly good way to send meta-information about messages from
> one place to another.  Don't try to make it more than that.

+1

If it helps, MAAWG's working on a BCP for complaint feedback loops; it 
recommends ARF as the standard format for messages, and suggests ways to 
create those 1:1 relationships for automated feedback.

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

Date: Thu, 3 Sep 2009 12:20:49 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Michael Adkins <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

> What, I don't count anymore? ;)

Hey, this is the IETF where anecdotes about something that happened to 
some guy with a Sun3 in 1998 count for more than the experience of global 
mail providers.

> The vast majority of our FBLs also go to addresses other than abuse@.
> Keeping all of those channels straight gets to be a cumbersome task on
> both sides, especially as more and more mailbox providers become fbl
> providers. I would be interested in a standard way to discover where to
> route automated reports that I don't expect a response to, whether they
> trust me as a report sender or not. I should be able to authenticate the
> reports as coming from my system and let the report recipients decide
> whether to process it or not based on that authentication, instead of
> relying on shared secrets established when the channel was created.

Let's see if we can pick that apart a little.

For senders of reports:

* Where do you send them if you're trusted, or if you're untrusted

* How do you tell the recipient who you are

* How can you tell if the recipient trusts you

* How do you tell the recipient you don't want an answer

For recipients

* How do you publish your reporting address

* How do you recognize a reporter

My suggestions would be pretty minimalist:

* All reports go to abuse@domain, no need to publish yet more
   contact addresses, since ARF reports are self-identifying

* Senders who want to prove who they are can sign reports with DKIM.
   Perhaps add a "Reporting-domain: example.com" line to tell
   recipients which of multiple signatures you'd like them to use

* Senders who don't want a response can put in "Response-requested: no"

Not sure how to tell if they trust your reports, perhaps a 
"Tell-me-if-you-love-me: yes" field asking for some sort of stylized
response.

Would this do it?  If not, what am I missing?  If at all possible I
would like to use existing standards rather than invent new stuff.

R's,
John

Date: Thu, 03 Sep 2009 10:33:52 -0400
From: Michael Adkins <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

> For trusted senders, there's all sorts of possible ways to set up a 
> channel, special address, passwords in the mail, even channels other than 
> SMTP.  I haven't heard any interest in standardizing that.
>
>   
What, I don't count anymore? ;)

The vast majority of our FBLs also go to addresses other than abuse@.
Keeping all of those channels straight gets to be a cumbersome task on
both sides, especially as more and more mailbox providers become fbl
providers. I would be interested in a standard way to discover where to
route automated reports that I don't expect a response to, whether they
trust me as a report sender or not. I should be able to authenticate the
reports as coming from my system and let the report recipients decide
whether to process it or not based on that authentication, instead of
relying on shared secrets established when the channel was created.

Date: Thu, 03 Sep 2009 10:15:26 +0200
From: Alessandro Vesely <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

John R. Levine wrote:
>> Please let me state once more that ARF is not sufficient. What appears
>> to be missing are the indications of when and how to use it, i.e. the
>> role of a mail domain and its "abuse" mailbox.
> 
> I fear that you misunderstand the nature of a standards process.

Granted! I try, however :-)

>  You 
> can't force people to accept abuse reports or to do anything else if they 
> don't want to, and despite a lot of wishful thinking, writing language 
> into an RFC doesn't change that.

Fine. But what about people who want to? I'd imagine any responsible 
users of an IP subnet would like to be informed about bots seizing 
their PCs, or users wandering on the dark side. Specifying how 
exactly that information is to be delivered is not functionally 
different than, say, spelling the role of an MX RR. (See the 
forwarding example below.)

> We already have abuse@domain as the preferred reporting address for domain 
> that sends mail, and I see no reason to think that any amount of standards 
> drafting will improve on the current situation.  We might consider saying 
> something in the ARF document that hosts MAY or SHOULD accept ARF 
> formatted reports at abuse@domain, but nothing beyond that.

IMHO, such a statement doesn't belong to the ARF specification proper.

> It would be nice if there were a reliable way to identify the reporting 
> address for an IP address, but we're not going to standardize that either.

Why not? Each organization doing FBLs has to invent their own 
methods. And when an ESP changes ISP, they have to rebuild the whole 
reputation-related distributed database: a loosing strategy that 
only advantages those who change domain names more often than IP 
addresses.

> The closest thing to a de-facto standard is listing it in SWIP data at 
> your RIR.  That has all sorts of lookup problems we all know, but I see no 
> reason to think that any alternative spec we might invent would be adopted
> by anyone.

Is it worth mentioning the Shared WHOIS Project and the 
abuse-mailbox field in an RFC?

Abusix's stance of only trusting 1st level (largest) ISPs, for 
example, seems reasonable. They look for an abuse mailbox in the 1st 
level RIRs' allocations. If they find none, they use the last tech-c 
contact listed there. The corresponding fellow is usually able to 
add an abuse mailbox to the record, thus abusix enforce RFC 2142 
compliance somewhat. The 1st level allocation usually corresponds to 
an ISP, not an ESP. In case the next level allocation had been 
leased to a spammer, it is reasonable to to have means to let the 
upper level be also informed. However, there are some routing issues 
here: normally, abuse reports are to be forwarded to the relevant 
postmasters. In particular,

* we need fields in the ARF format to automate forwarding, but
* determination of where to forward is out of the ARF RFC's scope.

That raises a chicken and egg problem, unless the two specifications 
are coordinated. I mention a second specification because it is 
extremely unlikely that ISPs on their own come out with some 
satisfactory practice. Although some ISPs might engineer a clever 
mechanism to route abuse reports, many won't; and even if they will, 
the likelihood that such mechanisms are portable from an ISP to 
another is scarce. Isn't that what standards processes are for?

Date: Wed, 2 Sep 2009 21:26:57 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Steve Atkins <[email-masked]>
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

>> I dunno about you, but it seems a lot more trivial to tell mail hosts 
>> to make a twiddle to their mail sorting software to directly handle ARF 
>> than to invent yet another abuse.net type database that people are 
>> supposed to query to be able to send ARF reports.

> I's not a case of "twiddling their mail sorting software" to parse ARF 
> format, it's a case of only opening up full automation to trusted 
> senders.

I think we're actually in agreement here.  I was thinking only in terms of 
your type B mail when I made that comment.  Even for untrusted senders, 
ARF should make it easier to tell what they're trying to say even if you 
don't believe it.  It is my impression that there's a fair amount of 
automation there already to look for IP addresses, URLs and email 
addresses.

For trusted senders, there's all sorts of possible ways to set up a 
channel, special address, passwords in the mail, even channels other than 
SMTP.  I haven't heard any interest in standardizing that.

I suppose we could add an optional "Authorization: xxxxx" line to ARF, but 
I would only do that if there were FBLs that said they wanted it and would 
use it.

R's,
John

From: Steve Atkins <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Wed, 2 Sep 2009 16:40:53 -0700
Subject: Re: [feedback-report] ARF working group interest?

On Sep 2, 2009, at 3:18 PM, John R. Levine wrote:

>>> mail to the "abuse@" mailbox looking for ARF reports. The issue is  
>>> not
>>> a technical one but rather one of policy - which is up to each ISP  
>>> to
>>> set as they fit.
>>
>> Indeed, and the most trivial method of such filtering seemingly in  
>> use
>> today (based on what I've seen, anyway) is for the ARF receiver to  
>> request
>> that the ARF sender send ARF reports to  
>> specialAddressThatIsNotAbuse@.
>

Lets take ARF out of the equation for a couple of paragraphs.

There are two main sorts of email that are of interest to an ESP or ISP
abuse desk.

There's mail from trusted reporters, where the receiver has an explicit
relationship with the sender of the report, and for which the receiver
doesn't have to ask any questions or consider the meaning or quality
of the report, instead they can just take action based on it in a fairly
mechanical manner. Type A email.

Then there's mail from untrusted reporters. There it's much harder to
judge what the mail means, and whether to take action based on it,
and what that action should be. It's not something that's conducive
to high levels of automation, typically, and there'll pretty much always
need to be a human in the loop (on a per-incident basis, if not a per
message basis) to judge what the mail means and whether it should
be trusted. Type B email.

Type A email is extremely conducive to 100% automation, if the messages
can be identified as solicited email from trusted reporters and if the  
messages
are of a format that can be mechanically processed easily.

Type B email is not so conducive to 100% automation.

If you are a trusted reporter then the receiver will have provided you  
with
a password of some sort to identify yourself to the receiver,  
typically a
special email address but it could equally well be a magic word to put
in the message, or DKIM validation or anything the sender and receiver
agree to, and they will have asked you to use a specific format for  
sending
reports. That format is probably ARF, but the "ARF format email" is  
otherwise
orthogonal to being a trusted reporter sending type A email.

If you don't have that password from the receiver the _you are not a
trusted reporter_. You are sending type B email to abuse@ without prior
explicit arrangement. Your mail will not be treated as special in any
way if you are not a trusted reporter, even if you send it in ARF  
format.
At best, sending email in ARF format as an untrusted reporter will
just provide a good, MIME encapsulated message to the receiver - it
is unlikely to provoke any special handling.

So, let us not confuse "ARF format" vs "Non-ARF format" email with
"trusted reporter" vs "untrusted reporter". Trusted reporters get the  
benefit
of implicit belief and full automation, untrusted reporters don't.  
Trusted
reporters may be required to use ARF format email, but that's not the
same as senders of ARF format email being trusted.

There are people who believe that by sending a steady stream of
emails to abuse@ in ARF format without any prior arrangement with
the receiving ISP it will cause them to be considered trusted in some
way. They're almost always wrong, though if the volume is high enough
they will end up getting special treatment of some sort.

I say "almost always wrong" as there are a very few reporters who,  
despite
no prior agreement with the ISP, have consistently provided useful data
and are treated as trusted reporters by receiver abuse desks and are
special cased. That's very, very rare and orthogonal to the ARFness or
otherwise of their emails (in fact, in the two cases I'm aware of they  
do
not use ARF).

>
> I dunno about you, but it seems a lot more trivial to tell mail  
> hosts to
> make a twiddle to their mail sorting software to directly handle ARF  
> than
> to invent yet another abuse.net type database that people are  
> supposed to
> query to be able to send ARF reports.

I's not a case of "twiddling their mail sorting software" to parse ARF  
format,
it's a case of only opening up full automation to trusted senders.

If they're using some sort of abuse.net type database to work out where
to send the report then they are an untrusted sender, and the format  
they
send the report in is irrelevant.

Cheers,
   Steve

Date: Wed, 02 Sep 2009 15:24:16 -0700
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: Alessandro Vesely <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?
Reply-To: [email-masked]

Alessandro Vesely wrote:
> Murray S. Kucherawy wrote:
>> One of the main functions of creating the working group will be to take 
>> on the technical work of considering whether ARF as it is currently 
>> defined is necessary and sufficient.  That is, we should consider 
>> dropping stuff that’s not actually useful or ambiguous, and adding what 
>> appears to be missing.
> 
> Please let me state once more that ARF is not sufficient. What appears 
> to be missing are the indications of when and how to use it, 

There is a difference between specifying an overall system, versus specifying a 
component of a system.

ARF is component technology.

There's nothing wrong with considering the specification of a system in which 
ARF is used, but it is a fundamentally different task than the one before us 
right now.

To consider whether the current form of ARF is necessary and and sufficient does 
require considering a larger system in which it can be used.  But it does not 
require specifying it.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 2 Sep 2009 18:18:35 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Todd Herr <[email-masked]>
Cleverness: None detected
Cc: [email-masked]
Subject: Re: [feedback-report] ARF working group interest?

>> mail to the "abuse@" mailbox looking for ARF reports. The issue is not
>> a technical one but rather one of policy - which is up to each ISP to
>> set as they fit.
>
> Indeed, and the most trivial method of such filtering seemingly in use
> today (based on what I've seen, anyway) is for the ARF receiver to request
> that the ARF sender send ARF reports to specialAddressThatIsNotAbuse@.

I dunno about you, but it seems a lot more trivial to tell mail hosts to 
make a twiddle to their mail sorting software to directly handle ARF than 
to invent yet another abuse.net type database that people are supposed to 
query to be able to send ARF reports.

R's,
John

Date: Wed, 2 Sep 2009 16:50:39 -0400
From: Todd Herr <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] ARF working group interest?

On Wed, Sep 02, 2009 at 03:59:19PM -0400, Yakov Shafranovich wrote:
> 
> There are sufficient standards and procedures in place that if an ARF
> sender and an ARF receiver wanted to communicate, that would easily be
> able to do so. For example, it would be trivial to filter incoming
> mail to the "abuse@" mailbox looking for ARF reports. The issue is not
> a technical one but rather one of policy - which is up to each ISP to
> set as they fit.

Indeed, and the most trivial method of such filtering seemingly in use 
today (based on what I've seen, anyway) is for the ARF receiver to request 
that the ARF sender send ARF reports to specialAddressThatIsNotAbuse@.

-- 
Todd Herr
Principal Engineer and Postmaster              V: 703.345.2447
Road Runner Email Operations                   M: 571.287.0366
[email-masked]                        AIM: RRMailToddHerr

Date: Wed, 2 Sep 2009 16:40:26 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
Cleverness: None detected
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

> able to do so. For example, it would be trivial to filter incoming
> mail to the "abuse@" mailbox looking for ARF reports. The issue is not
> a technical one but rather one of policy - which is up to each ISP to
> set as they fit.

I have been sending all my abuse reports in ARF format for the past couple 
of years, and can report that it works pretty well.  But I don't see what 
we as a standards group would do about that other than to say that they 
MAY or SHOULD accept and handle them.

R's,
John

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 2 Sep 2009 15:59:19 -0400
To: "John R. Levine" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Alessandro Vesely <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

On Wed, Sep 2, 2009 at 2:43 PM, John R. Levine<[email-masked]> wrote:
>> Please let me state once more that ARF is not sufficient. What appears
>> to be missing are the indications of when and how to use it, i.e. the
>> role of a mail domain and its "abuse" mailbox.
>
> I fear that you misunderstand the nature of a standards process.  You
> can't force people to accept abuse reports or to do anything else if they
> don't want to, and despite a lot of wishful thinking, writing language
> into an RFC doesn't change that.
>

Or as Jon Postel put it "be conservative in what you send, be liberal
in what you receive".

There are sufficient standards and procedures in place that if an ARF
sender and an ARF receiver wanted to communicate, that would easily be
able to do so. For example, it would be trivial to filter incoming
mail to the "abuse@" mailbox looking for ARF reports. The issue is not
a technical one but rather one of policy - which is up to each ISP to
set as they fit.

Yakov

Date: Wed, 2 Sep 2009 14:43:22 -0400 (EDT)
From: "John R. Levine" <[email-masked]>
To: Alessandro Vesely <[email-masked]>
Cleverness: None detected
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

> Please let me state once more that ARF is not sufficient. What appears
> to be missing are the indications of when and how to use it, i.e. the
> role of a mail domain and its "abuse" mailbox.

I fear that you misunderstand the nature of a standards process.  You 
can't force people to accept abuse reports or to do anything else if they 
don't want to, and despite a lot of wishful thinking, writing language 
into an RFC doesn't change that.

We already have abuse@domain as the preferred reporting address for domain 
that sends mail, and I see no reason to think that any amount of standards 
drafting will improve on the current situation.  We might consider saying 
something in the ARF document that hosts MAY or SHOULD accept ARF 
formatted reports at abuse@domain, but nothing beyond that.

It would be nice if there were a reliable way to identify the reporting 
address for an IP address, but we're not going to standardize that either. 
The closest thing to a de-facto standard is listing it in SWIP data at 
your RIR.  That has all sorts of lookup problems we all know, but I see no 
reason to think that any alternative spec we might invent would be adopted
by anyone.

I also agree that it would be nice to be able to report abuse that isn't 
tied to an individual mail messge.  INCH did that, we're not going to 
impress anyone by doing it again.

ARF is a perfectly good way to send meta-information about messages from 
one place to another.  Don't try to make it more than that.

R's,
John

Date: Wed, 02 Sep 2009 18:28:05 +0200
From: Alessandro Vesely <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

Murray S. Kucherawy wrote:
> One of the main functions of creating the working group will be to take 
> on the technical work of considering whether ARF as it is currently 
> defined is necessary and sufficient.  That is, we should consider 
> dropping stuff that’s not actually useful or ambiguous, and adding what 
> appears to be missing.

Please let me state once more that ARF is not sufficient. What appears 
to be missing are the indications of when and how to use it, i.e. the 
role of a mail domain and its "abuse" mailbox. In the draft's words:

                           Determination of where these reports should
  be sent, how trust among report generators and report recipients is
  established, and reports related to more than one message are outside
  the scope of this document.

I consider that self-imposed limitation useful, as it will likely 
allow to standardize ARF more quickly, as others have also noted on 
this list. However, while those out-of-scope issues would hardly fit 
within a single RFC, a working group might/should take them into account.

Existing specifications are not sufficient: RFC 2142 dates back to 
1997. It defines abuse@, but does not mention automated processing. 
That concept is reinforced by RFC 3013 (BCP 46), and RFC 2635 (FYI 
35); the latter additionally suggests that users submit complaints to 
the local abuse desk, or to a global one (it mentions abuse.net).

Some drafts exist that consider the concepts of abuse reporting (e.g. 
[1]) and domain-based reputation (e.g. [2]). While they may look 
distant from format discussions, the alternatives of either not 
discussing them, or discussing them in different WGs/lists, are bound 
to result in rough and inconsistent interoperability. For example, 
consider anonymization, a.k.a. munging reports; or report forwarding. 
More coordination may eventually result in a more consistent overall 
picture that ESPs and MUAs may conform to.
[1] http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation
[2] http://tools.ietf.org/html/draft-vesely-vhlo

> The most recent version of the draft charter is attached. [...]
> Of course, everyone is invited to make suggestions and participate in 
> the discussion for any work to be done by the working group.

What I would suggest is to modify the name and the description of the 
WG so as to provide for further discussion on feedback loops, after 
the publication of the first RFC. Please note that this would be a 
completion, not an upset. Tentatively,

Name: from

  Abuse Reporting Format (ARF)

to, e.g.,

  Wide-range Abuse Reporting Format And Related Extents (WARFARE)

Description (1st paragraph only): from

  Messaging anti-abuse operations between independent services often
  requires sending reports on observed fraud, spam virus or other abuse
  activity.  A standardized report format enables automated processing.
  The Abuse Reporting Format (ARF) specification has gained sufficient
  popularity to warrant formal codification, to ensure future
  interoperability with new implementations. The primary function of
  this working group will be to solicit review and refinement of the
  existing specification.

to

  Messaging anti-abuse operations between independent services often
  require sending reports on observed fraud, spam virus or other abuse
  activity.  A standardized report format enables automated processing.
  The Abuse Reporting Format (ARF) specification has gained sufficient
  popularity to warrant formal codification, to ensure future
  interoperability with new implementations. The primary function of
  this working group will be to solicit review and refinement of the
  existing format specifications.  In addition, this working group may
  review current practices for forwarding abuse reports and subscribing
  to such feeds, possibly examining the security issues implied in
  migrating from IPv4-based subscriptions to domain-based ones.

Date: Tue, 01 Sep 2009 15:01:21 -0700
To: [email-masked]
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] ARF working group interest?

At 11:40 01-09-2009, Murray S. Kucherawy wrote:
>One of the main functions of creating the working group will be to 
>take on the technical work of considering whether ARF as it is 
>currently defined is necessary and sufficient.  That is, we should 
>consider dropping stuff that's not actually useful or ambiguous, and 
>adding what appears to be missing.  ARF has seen some real-world 
>traction so the

In other words, the first objective is to define what goes in the 
base specification using draft-shafranovich-feedback-report as an 
initial proposal and to set up IANA registries.

>Finally, one of the points of the charter is to consider some 
>proposed extensions.

There is only one proposed extension at the moment 
(draft-kucherawy-dkim-reporting).  The charter mentions eight 
possible reporting extensions.  If I recall correctly, there were 
some comments from John Levine about the list and a mention of the 
work done in INCH.  The output of INCH was RFC 5070.

The goals are to deliver a document to "standardize" the reporting 
format while striving to retain backward compatibility.  Once that 
has been done, the group will work on the extensions.  I suggest 
finding out whether there is any interest to implement each of the 
eight extensions.

At 12:27 01-09-2009, Yakov Shafranovich wrote:
>I have some concern about separating the core ARF standard from the
>extensions. As I wrote it originally, the standard was meant to be
>highly extensible which is why it comes with a whole slew of IANA
>registries.Perhaps we should make this distinction more clear in the
>charter and work towards including the most widely used extensions in
>the core standard Thus, we will be focusing the work of the WG on
>getting ARF itself approved first. Work on additional extensions to
>the core standard can be done after the main work is done.

The core ARF is not being separated from the extensions.  There's the 
work on the core ARF and once that is standardized, the group can 
proceed to work on the extensions.

>I am afraid that getting bogged down in the extensions and what to
>include will get us away from approving the ARF format itself.

Yes.

Regards,
-sm 

From: Dennis Dayman <[email-masked]>
Date: Tue, 1 Sep 2009 15:47:18 -0500
To: J D Falk <[email-masked]>
Cc: MAAWG Technical Committee <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] [technical] ARF working group interest?

On Sep 1, 2009, at 1:54 PM, J D Falk wrote:

> On 01/09/2009 12:40, "Murray S. Kucherawy" <[email-masked]> wrote:
>
>> It would also be helpful to know based on list traffic how many  
>> likely
>> participants there will be.  Thus, please reply to the list (see  
>> below) if you
>> would be interested in participating both in the BoF and the  
>> working group
>> (once it starts) by being part of list conversations and, better yet,
>> attending IETF conferences and/or submitting document  
>> contributions.  The more
>> momentum we can demonstrate, the more the IETF will be willing to  
>> move
>> forward.
>
> I plan to participate (most likely in person in Hiroshima), and  
> contribute,
> and will continue to implement and evangelize ARF both personally  
> and on
> behalf of my employer.

I'm supposed to be in Barcelona end of that week, but depending on the  
date this might be on, perhaps.

I am interested.

-Dennis

Date: Tue, 01 Sep 2009 14:22:13 -0600
From: "J.D. Falk" <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

This is a multi-part message in MIME format.
--------------020301000605030900000900
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I'm subscribed under a different address here, so this got rejected.

--------------020301000605030900000900
Content-Type: message/rfc822;
	name="Re: [technical] ARF working group interest?.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename="Re: [technical] ARF working group interest?.eml"

From: J D Falk <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>,
	"[email-masked]" <[email-masked]>, 
	MAAWG Technical Committee <[email-masked]>
Date: Tue, 1 Sep 2009 12:54:05 -0600
Subject: Re: [technical] ARF working group interest?
Accept-Language: en-US
acceptlanguage: en-US

On 01/09/2009 12:40, "Murray S. Kucherawy" <[email-masked]> wrote:

> It would also be helpful to know based on list traffic how many likely
> participants there will be.  Thus, please reply to the list (see below) if you
> would be interested in participating both in the BoF and the working group
> (once it starts) by being part of list conversations and, better yet,
> attending IETF conferences and/or submitting document contributions.  The more
> momentum we can demonstrate, the more the IETF will be willing to move
> forward.

I plan to participate (most likely in person in Hiroshima), and contribute,
and will continue to implement and evangelize ARF both personally and on
behalf of my employer.

--------------020301000605030900000900--

Date: Tue, 01 Sep 2009 13:40:42 -0700
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: "Murray S. Kucherawy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?
Reply-To: [email-masked]

Murray S. Kucherawy wrote:
> I think it would be fine to propose an adjusted charter that involves
> verifying the base spec is up to IETF snuff and is reasonably minimal, moving
> some things it has now out to extension specifications as needed, and then
> considering the other already-proposed extensions as a third step.

That translates into "review existing text and make whatever deletions, changes 
and removals are deemed appropriate".

I don't recall ever seeing a wg charter with this as principal task.

spoilingly yours,

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: "Murray S. Kucherawy" <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
Date: Tue, 1 Sep 2009 13:30:48 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

> -----Original Message-----
> From: Yakov Shafranovich [mailto:[email-masked]]
> Sent: Tuesday, September 01, 2009 12:28 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]; [email-masked]
> Subject: Re: [feedback-report] ARF working group interest?
> 
> I have some concern about separating the core ARF standard from the
> extensions. As I wrote it originally, the standard was meant to be
> highly extensible which is why it comes with a whole slew of IANA
> registries.Perhaps we should make this distinction more clear in the
> charter and work towards including the most widely used extensions in
> the core standard Thus, we will be focusing the work of the WG on
> getting ARF itself approved first. Work on additional extensions to
> the core standard can be done after the main work is done.

I think it would be fine to propose an adjusted charter that involves verifying the base spec is up to IETF snuff and is reasonably minimal, moving some things it has now out to extension specifications as needed, and then considering the other already-proposed extensions as a third step.

Date: Tue, 01 Sep 2009 12:53:47 -0700
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: "Murray S. Kucherawy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Dave CROCKER <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] [technical] ARF working group interest?
Reply-To: [email-masked]

Murray S. Kucherawy wrote:
>> -----Original Message----- From: Dave CROCKER [mailto:[email-masked]] 
>> Working groups are extremely expensive, in time and effort.  The time for 
>> deciding whether changes are needed is before wg formation, not after.
> 
> Recent chatter on the ARF list suggests that there is some momentum toward
> removing stuff from the current specification.  That's not to say there's
> consensus to do so, but there is interest in discussing it.

This suggests an avenue that might note might appear to be arguing against, but 
which is entirely reasonable within IETF framework:

     There is a solid consensus to do a particular bit of work.  A bunch of folk 
agree that the spec needs pruning or that it needs to support capability x or 
that existing capability y isn't efficient enough or...

     The charter calls for doing this work.  The wg is formed.  It 
constructively pursued doing this work.  But it discovers that it can't reach 
agreement on the details.  (And, yes, this includes failing to agree on pruning. 
  Cf., recent DKIM discussions about pruning DKIM; solid constituency for doing 
it, but failure to gain consensus for the details.)

    WG agrees that the original spec is sufficient on its own.  Submits it to 
standards track.

This is an odd version of a "failed" working group, int that it failed to make 
the changes it committed to, but it still issues an RFC.

To repeat, however:  this would be predicated on consensus about the need, 
beforehand.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 01 Sep 2009 15:17:08 -0400
From: Michael Adkins <[email-masked]>
To: "Murray S. Kucherawy" <[email-masked]>
Cc: MAAWG Technical Committee <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] [technical] ARF working group interest?

J D Falk wrote:
> On 01/09/2009 12:40, "Murray S. Kucherawy" <[email-masked]> wrote:
>
>   
>> It would also be helpful to know based on list traffic how many likely
>> participants there will be.  Thus, please reply to the list (see below) if you
>> would be interested in participating both in the BoF and the working group
>> (once it starts) by being part of list conversations and, better yet,
>> attending IETF conferences and/or submitting document contributions.  The more
>> momentum we can demonstrate, the more the IETF will be willing to move
>> forward.
>>     
>
> I plan to participate (most likely in person in Hiroshima), and contribute,
> and will continue to implement and evangelize ARF both personally and on
> behalf of my employer.
>
>   
There's no chance I could make it to Hiroshima, but I would like to
participate.

From: "Murray S. Kucherawy" <[email-masked]>
To: Dave CROCKER <[email-masked]>
Date: Tue, 1 Sep 2009 12:10:47 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] [technical] ARF working group interest?

> -----Original Message-----
> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Tuesday, September 01, 2009 12:06 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]; [email-masked]
> Subject: Re: [technical] ARF working group interest?
> 
> A concern that I keep expressing about the current approach being taken
> to
> working group formation is when the decision has to be made that
> changes are
> necessary.
> 
> Working groups are extremely expensive, in time and effort.  The time
> for
> deciding whether changes are needed is before wg formation, not after.

Recent chatter on the ARF list suggests that there is some momentum toward removing stuff from the current specification.  That's not to say there's consensus to do so, but there is interest in discussing it.

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 1 Sep 2009 15:27:48 -0400
To: "Murray S. Kucherawy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] ARF working group interest?

2009/9/1 Murray S. Kucherawy <[email-masked]>:
>...
> One of the main functions of creating the working group will be to take on
> the technical work of considering whether ARF as it is currently defined is
> necessary and sufficient.  That is, we should consider dropping stuff that’s
> not actually useful or ambiguous, and adding what appears to be missing.
> ARF has seen some real-world traction so the experience of those sending
> and/or receiving ARF messages will be valuable in that process.  There have
> also been some submissions about features that should be added, and these
> need to be considered within the rigorous context of a standards working
> group.  The output of the working group will be the proposed standard
> document(s) that define ARF and any adjunct proposals.
>

Thanks for your hard work to get us this far.

I have some concern about separating the core ARF standard from the
extensions. As I wrote it originally, the standard was meant to be
highly extensible which is why it comes with a whole slew of IANA
registries.Perhaps we should make this distinction more clear in the
charter and work towards including the most widely used extensions in
the core standard Thus, we will be focusing the work of the WG on
getting ARF itself approved first. Work on additional extensions to
the core standard can be done after the main work is done.

I am afraid that getting bogged down in the extensions and what to
include will get us away from approving the ARF format itself.

>  ....
>
> It would also be helpful to know based on list traffic how many likely
> participants there will be.  Thus, please reply to the list (see below) if
> you would be interested in participating both in the BoF and the working
> group (once it starts) by being part of list conversations and, better yet,
> attending IETF conferences and/or submitting document contributions.  The
> more momentum we can demonstrate, the more the IETF will be willing to move
> forward.
>

I hope to participate remotely.

>  ...
>
> The most recent version of the draft charter is attached.  It includes some
> of the suggestions I’ve collected at past MAAWG conferences.  A few of these
> have been discussed recently on the ARF list, but all of them are subject to
> review by participants.
>

As per our email, some of the historical stuff needs to be adjusted.

Yakov

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>,  "[email-masked]" <[email-masked]>
Date: Tue, 1 Sep 2009 11:40:05 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: [feedback-report] ARF working group interest?

--_004_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_
Content-Type: multipart/alternative;
	boundary="_000_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_"

--_000_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

At IETF 75 in Stockholm in July, a presentation was made of a charter for a=
 potential Abuse Report Format (ARF) working group.  Basically, the main go=
al of the proposed working group is to move the ARF specification toward st=
andardization using the collaboration and review procedures and expertise t=
hat the IETF provides, and then extend ARF into relevant areas such as DKIM=
 reporting.

Standardization of ARF is an important goal that will have the benefits of =
incremental enhancement over the current specification, increasing the comm=
unity it supports and thus the community likely to subscribe to using it.

One of the main functions of creating the working group will be to take on =
the technical work of considering whether ARF as it is currently defined is=
 necessary and sufficient.  That is, we should consider dropping stuff that=
's not actually useful or ambiguous, and adding what appears to be missing.=
  ARF has seen some real-world traction so the experience of those sending =
and/or receiving ARF messages will be valuable in that process.  There have=
 also been some submissions about features that should be added, and these =
need to be considered within the rigorous context of a standards working gr=
oup.  The output of the working group will be the proposed standard documen=
t(s) that define ARF and any adjunct proposals.

The next step toward making this a reality is to host a Birds-of-a-Feather =
session about the idea of starting a working group.  The purpose of this is=
 to allow the IETF to observe how much interest and support there is behind=
 the effort, thus warranting the establishment of the working group.  I am =
planning to submit a BoF request for IETF 76 this coming November in Hirosh=
ima.  You can show your support for the idea of having a working group by a=
ttending the BoF either in person or remotely (they usually have a jabber s=
erver set up).  In the IETF, the best type of support is participation.  It=
 demonstrates that the industry might add the work to products and use it i=
n operations.

Due to other commitments I won't be able to attend in person in Hiroshima, =
but I will however be participating remotely.

It would also be helpful to know based on list traffic how many likely part=
icipants there will be.  Thus, please reply to the list (see below) if you =
would be interested in participating both in the BoF and the working group =
(once it starts) by being part of list conversations and, better yet, atten=
ding IETF conferences and/or submitting document contributions.  The more m=
omentum we can demonstrate, the more the IETF will be willing to move forwa=
rd.

Finally, one of the points of the charter is to consider some proposed exte=
nsions.  Although I have tried to be representative of those extensions peo=
ple have discussed with me privately, there's a lot more credibility lent t=
o the effort if those conversations are public.  So, if you have proposed e=
xtensions to ARF and you have not yet posted to this list, or if you'd like=
 to express support for the proposed extensions listed in the charter, plea=
se do so.  It may even get some discussion going right away which of course=
 will demonstrate interest.

The most recent version of the draft charter is attached.  It includes some=
 of the suggestions I've collected at past MAAWG conferences.  A few of the=
se have been discussed recently on the ARF list, but all of them are subjec=
t to review by participants.

Of course, everyone is invited to make suggestions and participate in the d=
iscussion for any work to be done by the working group.  The mailing list i=
s at [email-masked]; see http://mipassoc.org/mailman/list=
info/abuse-feedback-report for links to subscriptions and archives.

Thanks,

-MSK

--_000_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>At IETF 75 in Stockholm in July, a presentation was ma=
de of
a charter for a potential Abuse Report Format (ARF) working group.&nbsp; Ba=
sically, the
main goal of the proposed working group is to move the ARF specification to=
ward
standardization using the collaboration and review procedures and expertise
that the IETF provides, and then extend ARF into relevant areas such as DKI=
M
reporting.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Standardization of ARF is an important goal that will =
have
the benefits of incremental enhancement over the current specification,
increasing the community it supports and thus the community likely to subsc=
ribe
to using it.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>One of the main functions of creating the working grou=
p will
be to take on the technical work of considering whether ARF as it is curren=
tly
defined is necessary and sufficient.&nbsp; That is, we should consider drop=
ping
stuff that&#8217;s not actually useful or ambiguous, and adding what appear=
s to
be missing.&nbsp; ARF has seen some real-world traction so the experience o=
f those
sending and/or receiving ARF messages will be valuable in that process.&nbs=
p; There
have also been some submissions about features that should be added, and th=
ese
need to be considered within the rigorous context of a standards working
group.&nbsp; The output of the working group will be the proposed standard
document(s) that define ARF and any adjunct proposals.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>The next step toward making this a reality is to host =
a
Birds-of-a-Feather session about the idea of starting a working group.&nbsp=
; The
purpose of this is to allow the IETF to observe how much interest and suppo=
rt
there is behind the effort, thus warranting the establishment of the workin=
g
group.&nbsp; I am planning to submit a BoF request for IETF 76 this coming =
November
in Hiroshima.&nbsp; You can show your support for the idea of having a work=
ing group
by attending the BoF either in person or remotely (they usually have a jabb=
er
server set up).&nbsp; In the IETF, the best type of support is participatio=
n.&nbsp; It
demonstrates that the industry might add the work to products and use it in
operations.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Due to other commitments I won&#8217;t be able to atte=
nd in
person in Hiroshima, but I will however be participating remotely.<o:p></o:=
p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>It would also be helpful to know based on list traffic=
 how
many likely participants there will be.&nbsp; Thus, please reply to the lis=
t (see
below) if you would be interested in participating both in the BoF and the
working group (once it starts) by being part of list conversations and, bet=
ter
yet, attending IETF conferences and/or submitting document contributions.&n=
bsp; The
more momentum we can demonstrate, the more the IETF will be willing to move
forward.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Finally, one of the points of the charter is to consid=
er
some proposed extensions.&nbsp; Although I have tried to be representative =
of those
extensions people have discussed with me privately, there&#8217;s a lot mor=
e
credibility lent to the effort if those conversations are public.&nbsp; So,=
 if you
have proposed extensions to ARF and you have not yet posted to this list, o=
r if
you&#8217;d like to express support for the proposed extensions listed in t=
he
charter, please do so.&nbsp; It may even get some discussion going right aw=
ay which
of course will demonstrate interest.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>The most recent version of the draft charter is attach=
ed.&nbsp;
It includes some of the suggestions I&#8217;ve collected at past MAAWG
conferences.&nbsp; A few of these have been discussed recently on the ARF l=
ist, but
all of them are subject to review by participants.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Of course, everyone is invited to make suggestions and
participate in the discussion for any work to be done by the working group.=
&nbsp;
The mailing list is at [email-masked]; see
http://mipassoc.org/mailman/listinfo/abuse-feedback-report for links to
subscriptions and archives.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thanks,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>-MSK<o:p></o:p></p>

</div>

</body>

</html>

--_000_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_--

--_004_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_
Content-Type: text/plain; name="arf-charter v04.txt"
Content-Description: arf-charter v04.txt
Content-Disposition: attachment; filename="arf-charter v04.txt"; size=3516;
	creation-date="Mon, 20 Jul 2009 10:36:14 GMT";
	modification-date="Mon, 20 Jul 2009 10:36:14 GMT"
Content-Transfer-Encoding: base64

--_004_BB012BD379D7B046ABE1472D8093C61C0116CA29BBEXCHC2corpclo_--

Date: Tue, 01 Sep 2009 12:06:16 -0700
From: Dave CROCKER <[email-masked]>
Organization: Brandenburg InternetWorking
To: "Murray S. Kucherawy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [feedback-report] [technical] ARF working group interest?

Murray S. Kucherawy wrote:
> One of the main functions of creating the working group will be to take on
> the technical work of considering whether ARF as it is currently defined is
> necessary and sufficient.  That is, we should consider dropping stuff that’s
> not actually useful or ambiguous, and adding what appears to be missing.  ARF
> has seen some real-world traction so the experience of those sending and/or
> receiving ARF messages will be valuable in that process.  There have also
> been some submissions about features that should be added, and these need to
> be considered within the rigorous context of a standards working group.  The
> output of the working group will be the proposed standard document(s) that
> define ARF and any adjunct proposals.

In spite of being a cat person, I see this bit of work as important.

A concern that I keep expressing about the current approach being taken to
working group formation is when the decision has to be made that changes are
necessary.

Working groups are extremely expensive, in time and effort.  The time for
deciding whether changes are needed is before wg formation, not after.

That is, my view of when to have a working group decide on the particular work 
to be done is before it is chartered, not after.  There need to be a clear and
solid constituency for making particular types of changes.  The 8 items listed
in the draft charter all look reasonable.  And no, they don't need to be solved
before chartering.

But there does need to be clear support for --essentially, statements of desire 
to implement -- particular ones.

IMO.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net