Subject: Re: [feedback-report] I-D ACTION: draft-shafranovich-feedback-report-02.txt
From: Dave Crocker <[email-masked]>
To: ARF mailing list <[email-masked]>
Date: Tue, 29 May 2007 22:42:06 -0700
List-Id: Public forum for discussion on the feedback-report draft <abuse-feedback-report.mipassoc.org>

pretty html and pdf versions are now at <http://mipassoc.org/arf>.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: 30 May 2007 04:21:25 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] New ARF internet draft
Organization: 
Cc: 

>We should bump the version number in 5.1 at some point.
>I'm thinking to 1.0.
>
>In 5.3 we were assuming that Reported-URI: would include the
>mailto: case. Dunno if that's worth mentioning explicitly.

I'll collect the suggestions for one more pass.

At next week's MAAWG meeting I hope we can get together with some of
the people who are sending large numbers of ARFs.  If they like it,
I think we're done, and we can push it along toward an Informational
RFC.

R's,
John

Date: Tue, 29 May 2007 18:01:05 -0400 (EDT)
From: John R Levine <[email-masked]>
To: ARF mailing list <[email-masked]>
Cleverness: None detected
Subject: [feedback-report] I-D ACTION: draft-shafranovich-feedback-report-02.txt

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--NextPart
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; FORMAT=flowed
Content-ID: <[email-masked]>

---------- Forwarded message ----------
Date: Tue, 29 May 2007 21:43:01 +0000 (UTC)
From: [email-masked]
To: [email-masked]
Newsgroups: iecc.lists.ietf
Subject: I-D ACTION: draft-shafranovich-feedback-report-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

  	Title		: An Extensible Format for Email Feedback Reports
  	Author(s)	: Y. Shafranovich, et al.
  	Filename	: draft-shafranovich-feedback-report-02.txt
  	Pages		: 21
  	Date		: 2007-5-29

This document defines an extensible format and MIME type that may be
     used by network operators to report feedback about received email to
     other parties.  This format is intended as a machine readable
     replacement for various existing report formats currently used in
     Internet email.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-shafranovich-feedback-report-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then
"get draft-shafranovich-feedback-report-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
  	[email-masked].
In the body type:
  	"FILE /internet-drafts/draft-shafranovich-feedback-report-02.txt".

NOTE:	The mail server at ietf.org can return the document in
  	MIME-encoded form by using the "mpack" utility.  To use this
  	feature, insert the command "ENCODING mime" before the "FILE"
  	command.  To decode the response(s), you will need "munpack" or
  	a MIME-compliant mail reader.  Different MIME-compliant mail readers
  	exhibit different behavior, especially when dealing with
  	"multipart" MIME messages (i.e. documents which have been split
  	up into multiple messages), so check your local documentation on
  	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess
Content-ID: <[email-masked]>
Content-Description: 

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--OtherAccess
Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server;
	SERVER="[email-masked]"
Content-ID: <[email-masked]>

--OtherAccess
Content-Type: MESSAGE/EXTERNAL-BODY;
	NAME=draft-shafranovich-feedback-report-02.txt;
	SITE=ftp.ietf.org; ACCESS-TYPE=anon-ftp;
	DIRECTORY=internet-drafts
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-ID: <[email-masked]>
Content-Description: 
Content-Disposition: INLINE

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--NextPart--

Date: Tue, 29 May 2007 11:59:24 -0700
From: "J.D. Falk" <[email-masked]>
Organization: Yahoo!
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] New ARF internet draft

On 2007-05-29 09:56, Steve Atkins wrote:

> In 5.3 we were assuming that Reported-URI: would include the
> mailto: case. Dunno if that's worth mentioning explicitly.

Probably a good idea; there's already a lot of unnecessary confusion 
around this thing.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Mail

From: Steve Atkins <[email-masked]>
Subject: Re: [feedback-report] New ARF internet draft
Date: Tue, 29 May 2007 09:56:07 -0700
To: ARF mailing list <[email-masked]>

On May 29, 2007, at 9:19 AM, John Levine wrote:

> I made one more editorial pass and few more minor text twiddles over
> the weekend and sent in the -02 version of the ARF draft.  Until Dave
> puts it on the mipassoc site and the I-D people put it in their
> respository, you can find it at http://www.taugh.com/arf.
>
> One of the things I looked for when I made the pass was to be sure not
> to make any changes to existing practice, since I presume we all agree
> that none of the outfits currently using ARF have any interest in
> changing what they're doing.
>
> This should be published as an I-D in the next few days.

Looks good.

We should bump the version number in 5.1 at some point.
I'm thinking to 1.0.

In 5.3 we were assuming that Reported-URI: would include the
mailto: case. Dunno if that's worth mentioning explicitly.

Cheers,
   Steve

Date: 29 May 2007 16:19:56 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Organization: 
Subject: [feedback-report] New ARF internet draft

I made one more editorial pass and few more minor text twiddles over
the weekend and sent in the -02 version of the ARF draft.  Until Dave
puts it on the mipassoc site and the I-D people put it in their
respository, you can find it at http://www.taugh.com/arf.  

One of the things I looked for when I made the pass was to be sure not
to make any changes to existing practice, since I presume we all agree
that none of the outfits currently using ARF have any interest in
changing what they're doing.

This should be published as an I-D in the next few days.

R's,
John

Date: Tue, 29 May 2007 11:39:49 -0400
From: "Damon Sauer" <[email-masked]>
To: [email-masked]
Subject: [feedback-report] Opt-Out and Opt-Out-List

Just getting the ball rolling here-

In my experience, both are needed. However, I would suggest a change
to the nomenclature from Opt-Out to Opt-Out-Global. It is more
descriptive.

Situations such as a telecommunications company sending email on two
or more lines of business. Cell phone, Internet, Cable TV. My
cellphone provider is not with this company and I would rather not
receive anymore email about it, while the email concerning ads or
information about their Internet service I am still interested in
because they are my ISP. I would like an Opt-Out-List.

A mortgage company sending email for insurance, lower rates, and
credit services. I would rather choose an Opt-Out-Global.

Regards,
Damon Sauer

Date: 26 May 2007 16:57:11 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] New version of the ARF draft
Organization: 
Cc: 

> Just asking for a line to allow an ISP to include information like
> this if they so choose.

The report section is extensible, sort of like mail headers.  People
can add any info lines they want.

If it turns out that ISPs do actually provide extra info, and they do
it in a consistent way, it's not a big deal to add more line types in
the future.

R's,
John

Date: Fri, 25 May 2007 18:58:55 -0700
To: [email-masked], John R Levine <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: [feedback-report] New version of the ARF draft
Cc: ARF mailing list <[email-masked]>

At 6:19 PM -0700 5/25/07, Dave Crocker wrote:
>John R Levine wrote:
>>I put it here, in xml and html: http://www.taugh.com/arf/.
>
>just so I do not duplicate effort needlessly, is this intended to 
>replace the venue that's been used for public access: 
><http:mipassoc.org/arf>?

Only temporarily. It's a pre-draft asking for (and getting!) 
responses. It will be a real Internet Draft in a few days, and that 
I-D should certainly be put on the site when published.

--Paul Hoffman, Director
--Domain Assurance Council

Date: Fri, 25 May 2007 18:19:00 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: John R Levine <[email-masked]>
Subject: Re: [feedback-report] New version of the ARF draft
Cc: ARF mailing list <[email-masked]>
Reply-To: [email-masked]

John R Levine wrote:
> I put it here, in xml and html: http://www.taugh.com/arf/.  

just so I do not duplicate effort needlessly, is this intended to replace the 
venue that's been used for public access:  <http:mipassoc.org/arf>?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: 26 May 2007 00:54:42 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: Certifier (was: [feedback-report] New version of the ARF draft)
Organization: 
Cc: 

>>Will the certifier register themselves with an ISP? Or will the Sender
>The ISP might have to register with the certifier to use their service.

Probably not.  The business models for all the certifiers I know is
that they charge the people they certify, but the list is given away
free to anyone who wants to use it.  The more people who use it, the
higher the value to the certified domain.

R's,
John

From: Douglas Otis <[email-masked]>
Subject: Re: [feedback-report] New version of the ARF draft
Date: Fri, 25 May 2007 17:20:21 -0700
To: Damon Sauer <[email-masked]>
Cc: [email-masked]

On May 25, 2007, at 8:42 AM, Damon Sauer wrote:

> Agreed and since I am going to be receiving these from not just one  
> or two ISPs but possibly hundreds or thousands, it would be  
> beneficial to me, the sender, to know via the ARF if they currently  
> have an agreement with me. Just asking for a line to allow an ISP  
> to include information like this if they so choose. Call it  
> "General Information from ISP (optional):". Some ISP's have plenty  
> of information they would be willing share with the sender.

An open rating scheme should include a field to indicate the  
Confidence Level (from 0 to 1) for the submitter before being passed  
back to the sender.  The Confidence Level could be tabulated when  
resolving issues related to erroneous categorizations.  To assist in  
this effort, these tabulation could be based upon a type of ARF that  
challenges an ARF. (ARF-Challenge).

Such a scheme should improve the quality of the response  
information.  At the same time, this might also help detect and  
defuse accounts used to game the system.

-Doug

Date: Fri, 25 May 2007 11:28:18 -0700
To: Yakov Shafranovich <[email-masked]>, ARF mailing list  <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: 
Subject: [feedback-report] Re: ABNF

At 1:39 PM -0400 5/25/07, Yakov Shafranovich wrote:
>...... Original Message .......
>On Fri, 25 May 2007 10:28:54 -0700 Paul Hoffman
><[email-masked]> wrote:
>>At 11:46 PM -0400 5/24/07, Yakov Shafranovich wrote:
>>>2. ABNF grammar will be needed at some point.
>>
>>Why? Have any developers found that the current description is not
>>good enough? And, more to the point, do we think those developers
>>would be helped by ABNF?
>>
>>I'm not a developer but I know how to read MIME stuff. I had no
>>problem reading the technical part of the spec, and the examples
>>looked exactly what I thought they would based on the spec. I don't
>>think ABNF would add much, and unless we do it perfectly, will
>>introduce errors.
>>
>
>I am not a fan of ABNF unless necessary but my understanding is that the
>IETF will require ABNF for a new MIME type (at least that was my experience
>when I wrote RFC 4080).

The current plan is to submit this as an Informational RFC, which 
doesn't need (or want) the IETF approval and oversight.

Having said that, I'm interested in RFC 4180. Did you submit that to 
the IETF, or directly to the RFC Editor? And who in specific told you 
that you needed to add ABNF? That requirement isn't in RFC 4288.

--Paul Hoffman, Director
--Domain Assurance Council

To: Paul Hoffman <[email-masked]>, ARF mailing list  <[email-masked]>
From: Yakov Shafranovich <[email-masked]>
Date: Fri, 25 May 2007 13:39 -0400
Cc: 
Subject: [feedback-report] Re: ABNF

...... Original Message .......
On Fri, 25 May 2007 10:28:54 -0700 Paul Hoffman 
<[email-masked]> wrote:
>At 11:46 PM -0400 5/24/07, Yakov Shafranovich wrote:
>>2. ABNF grammar will be needed at some point.
>
>Why? Have any developers found that the current description is not 
>good enough? And, more to the point, do we think those developers 
>would be helped by ABNF?
>
>I'm not a developer but I know how to read MIME stuff. I had no 
>problem reading the technical part of the spec, and the examples 
>looked exactly what I thought they would based on the spec. I don't 
>think ABNF would add much, and unless we do it perfectly, will 
>introduce errors.
>

I am not a fan of ABNF unless necessary but my understanding is that the 
IETF will require ABNF for a new MIME type (at least that was my experience 
when I wrote RFC 4080).

Date: Fri, 25 May 2007 10:28:54 -0700
To: Yakov Shafranovich <[email-masked]>, ARF mailing list <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: 
Subject: [feedback-report] ABNF

At 11:46 PM -0400 5/24/07, Yakov Shafranovich wrote:
>2. ABNF grammar will be needed at some point.

Why? Have any developers found that the current description is not 
good enough? And, more to the point, do we think those developers 
would be helped by ABNF?

I'm not a developer but I know how to read MIME stuff. I had no 
problem reading the technical part of the spec, and the examples 
looked exactly what I thought they would based on the spec. I don't 
think ABNF would add much, and unless we do it perfectly, will 
introduce errors.

--Paul Hoffman, Director
--Domain Assurance Council

Date: Fri, 25 May 2007 11:42:23 -0400
From: "Damon Sauer" <[email-masked]>
To: SM <[email-masked]>
Subject: Re: [feedback-report] New version of the ARF draft
Cc: [email-masked]

On 5/25/07, SM <[email-masked]> wrote:
> At 06:26 25-05-2007, Damon Sauer wrote:
> >With the ARF, I was hoping that, if we can't change the root issue,
> >maybe we can at least provide a space, whether it is used or not, for
> >some ISP to provide further information to the sender from the
> >receiver OR further insight as to our current status with ISP. I get a
> >report card from AOL, why can't this same information be incorporated
> >into the ARF so that other ISP's can provide similar information if
> >they so chose?
>
> ARF standardizes the report format used for abuse reports.  If the
> ISP is going to use the feedback loop for each "this is spam" click,
> that will only generate unnecessary reports.  Still, it is not up to
> the ISP to say that the particular complaint is about transactional mail.
>
> There are other means to make the problem manageable if the ISP and
> sender agree that the message is not abuse.

Agreed and since I am going to be receiving these from not just one or
two ISPs but possibly hundreds or thousands, it would be benificial to
me, the sender, to know via the ARF if they currently have an
agreement with me. Just asking for a line to allow an ISP to include
information like this if they so choose. Call it "General Information
from ISP (optional):". Some ISP's have plenty of information they
would be willing share with the sender.

Regards,
Damon

Date: Fri, 25 May 2007 08:39:33 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Certifier (was: [feedback-report] New version of the ARF draft)

At 06:52 25-05-2007, Jeff Macdonald wrote:
>I'm having trouble envisioning how the certifier gets into this loop.

The ISP uses a service provided by the certifier to determine the 
reputation of the sender.

>Will the certifier register themselves with an ISP? Or will the Sender

The ISP might have to register with the certifier to use their service.

>register two email addresses (sender and certifier) when registering
>for ARF messages? I think these questions are outside the scope of ARF,
>but intersting enough to ask anyway.

It's easier for the sender to deal with the certifier instead of several ISPs.

Regards,
-sm 

Date: Fri, 25 May 2007 08:09:30 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: [feedback-report] New version of the ARF draft

At 06:26 25-05-2007, Damon Sauer wrote:
>With the ARF, I was hoping that, if we can't change the root issue,
>maybe we can at least provide a space, whether it is used or not, for
>some ISP to provide further information to the sender from the
>receiver OR further insight as to our current status with ISP. I get a
>report card from AOL, why can't this same information be incorporated
>into the ARF so that other ISP's can provide similar information if
>they so chose?

ARF standardizes the report format used for abuse reports.  If the 
ISP is going to use the feedback loop for each "this is spam" click, 
that will only generate unnecessary reports.  Still, it is not up to 
the ISP to say that the particular complaint is about transactional mail.

There are other means to make the problem manageable if the ISP and 
sender agree that the message is not abuse.

Regards,
-sm

Date: Fri, 25 May 2007 09:52:06 -0400
From: Jeff Macdonald <[email-masked]>
To: John Levine <[email-masked]>
Subject: Re: [feedback-report] New version of the ARF draft
Cc: [email-masked]

On Fri, May 25, 2007 at 05:39:44AM -0000, John Levine wrote:

> It occurred to me early on that if a message were certified by
> something like VBR and the recipient hit the spam button, you'd want
> to send the exact same abuse report to the sender and to the
> certifier.

I'm having trouble envisioning how the certifier gets into this loop.
Will the certifier register themselves with an ISP? Or will the Sender
register two email addresses (sender and certifier) when registering
for ARF messages? I think these questions are outside the scope of ARF,
but intersting enough to ask anyway.

-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com

Date: Fri, 25 May 2007 06:47:10 -0700
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: [feedback-report] Designated Expert vs. first-come-first-served for

At 5:34 AM +0000 5/25/07, John Levine wrote:
>  > 1. The IANA section should be reworded from requiring an Designated
>>  Expert to first come, first serve.
>
>Paul understands IETF politics far better than I do and he tells me
>that they'll never go for first come first serve.  Designated expert
>is as close as we'll get.

I didn't say it with nearly that much force. What I (hope I) said was 
"informational documents that come with first-come-first-serve 
registries will be looked down on because it causes a lot of work for 
IANA for something that is not an IETF product". There may even be 
cases where such registries exist for non-IETF documents, but I know 
I have heard ADs express concern about that in the past.

Do people see any downsides to Designated Expert? We can switch back 
to first-come-first-served at the risk of that decision delaying 
publication.

--Paul Hoffman, Director
--Domain Assurance Council

Date: Fri, 25 May 2007 09:26:27 -0400
From: "Damon Sauer" <[email-masked]>
To: "John Levine" <[email-masked]>
Subject: Re: [feedback-report] New version of the ARF draft
Cc: [email-masked]

The root problem really is the original process.
The user opens their mailbox, puts a check mark in every email they
see as spam and ALSO every email they just don't want to read or
ignore. Then they hit the spam button. It is much easier than a two
step process: Mark spam then mark just delete, then read mail. Because
the ISP's have made it easy to get rid of the "stuff" in your box with
one button, the spam button now becomes dual purpose. It concerns me
that this same process is used to determine the reputation of the
sender. Now as the sender, we have to try and separate those that
really thought it was spam and those that were just cleaning up their
mailbox.

With the ARF, I was hoping that, if we can't change the root issue,
maybe we can at least provide a space, whether it is used or not, for
some ISP to provide further information to the sender from the
receiver OR further insight as to our current status with ISP. I get a
report card from AOL, why can't this same information be incorporated
into the ARF so that other ISP's can provide similar information if
they so chose?

Just trying to share my thoughts and views, not throw monkey wrenches.
I am ok with it as is, better than nothing.

Regards,
Damon

On 25 May 2007 05:39:44 -0000, John Levine <[email-masked]> wrote:
> >Another point is how far will this go. Are we just keeping this as a way
> >for receivers to provide feedback to people up the sending food chain,
> >or is this becoming a more general mechanism for people to exchange
> >opinions about emails. I lean towards #1 since it is a more narrow goal
> >rather than #2.
>
> I hope we agree it's #1, it's a way for a recipient (or more likely
> recipient's agent) up the food chain, not for content opinion
> negotiation.  It occurred to me early on that if a message were
> certified by something like VBR and the recipient hit the spam button,
> you'd want to send the exact same abuse report to the sender and to
> the certifier.
>
> Re the questions, it looks like your proposed answers are all the same
> as mine.  Unless I hear some disagreement, I'm inclined to consider
> them all resolved and update the draft accordingly.
>
> R's,
> John
>
> _______________________________________________
> abuse-feedback-report mailing list
> [email-masked]
> http://mipassoc.org/mailman/listinfo/abuse-feedback-report
>

Date: 25 May 2007 05:39:44 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] New version of the ARF draft
Organization: 
Cc: 

>Another point is how far will this go. Are we just keeping this as a way
>for receivers to provide feedback to people up the sending food chain,
>or is this becoming a more general mechanism for people to exchange
>opinions about emails. I lean towards #1 since it is a more narrow goal
>rather than #2.

I hope we agree it's #1, it's a way for a recipient (or more likely
recipient's agent) up the food chain, not for content opinion
negotiation.  It occurred to me early on that if a message were
certified by something like VBR and the recipient hit the spam button,
you'd want to send the exact same abuse report to the sender and to
the certifier.

Re the questions, it looks like your proposed answers are all the same
as mine.  Unless I hear some disagreement, I'm inclined to consider
them all resolved and update the draft accordingly.

R's,
John

Date: 25 May 2007 05:34:21 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] New version of the ARF draft
Organization: 
Cc: 

> 1. The IANA section should be reworded from requiring an Designated
> Expert to first come, first serve.

Paul understands IETF politics far better than I do and he tells me
that they'll never go for first come first serve.  Designated expert
is as close as we'll get.

>2. ABNF grammar will be needed at some point.

Yeah.  Anyone want to write one?

R's,
John

Date: Fri, 25 May 2007 00:37:37 -0400
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] New version of the ARF draft

John R Levine wrote:
> We added these two feedback types.  If people hate them, we can take
> them back out:
> 
>  * miscategorized - indicates that the content categorization applied in
>    connection with a certification or reputation system was incorrect
> 
>  * not-spam - indicates that a message that was tagged or categorized as
>    spam (such as by an ISP) is not spam
> 
> The former is intended to send back to a certifier or reputation
> provider, the second to your own ISP or mail host to tune their filters.
> Like every other content type, these are just assertions by whoever's
> sending the report, which the receiving system is free to interpret or
> not interpret any way it wants.
> 

Originally, the ARF standard was meant as a way to the receiver to
provide opinion on the message back to the sender. I see that we are now
looking at a slightly wider view of it as a way for receiver to provide
feedback to several parties up the email food chain (ISPs, certifiers,
senders, etc). The introduction section of the draft, plus the summary
should probably reflect that.

Another point is how far will this go. Are we just keeping this as a way
for receivers to provide feedback to people up the sending food chain,
or is this becoming a more general mechanism for people to exchange
opinions about emails. I lean towards #1 since it is a more narrow goal
rather than #2.

> 
> Near the end, there's a list of questions added in previous versions. 
> If we can agree on the answers to some or all of them we can update the
> draft and take out the questions.
> 
> 1.  Whether encoding of the machine readable part should be limited
>     to 7-bit
> 

This draft was originally meant to be a "son-of" RFC 3462 which is also
the ancestor of DSNs and MSNs. RFC 3462 restricts encoding to 7-bit as
per section 1. For 8-bit, the following is stated in the end of section 1:

>    When 8-bit or binary data not encoded in a 7 bit form is to be
>    returned, and the return path is not guaranteed to be 8-bit or binary
>    capable, two options are available.  The original message MAY be re-
>    encoded into a legal 7-bit MIME message or the Text/RFC822-Headers
>    content-type MAY be used to return only the original message headers.

To the best of my knowledge, the same approach is used in DSNs and I
don't see why we should change it. Any 8-bit data can be encoded safely
via MIME into something 7-bit.

> 2.  Whether there is a need for both "opt-out" and "opt-out-list",
>     and whether this format should be used for opt-outs at all.
> 

Is there any current work on something similar in the IETF? I vaguely
remember seeing something based on "List-Unsubscribe".

> 3.   Whether the "from" address should be required to be a human just
>     like other RFCs in the "message/report" family.
> 

There is no requirement in RFC 3462 for that, it just happens to be a
SHOULD in RFC 3464 (DSN). We can also suggest it as a SHOULD or leave
it. I don't think either way will make any difference since people will
do what they want anyway.

> 4.  Whether there is a need for a new header to indicate munging of
>     the included email message.

I don't have enough operational experience to have an opinion on this,
BUT if you do choose to include a header, we need to define what munging
is and what fields it affects. Something along the lines of a header in
DKIM which says which headers are used for signing.

> 
> 5.  Whether different type of convention should be allowed for
>     subject lines.
> 

Will anyone listen?

> 6.  Whether there should be different types defined for
>     "Reported-Uri" to better indicate to the report receiver how they are
>     related to the email message in question.
> 

Not sure what you mean but this.

Yakov

Date: Thu, 24 May 2007 21:10:49 -0700
To: ARF mailing list <[email-masked]>
From: SM <[email-masked]>
Subject: Re: [taugh.com-johnl] Re: [feedback-report] New version of the ARF draft

At 11:17 24-05-2007, Damon Sauer wrote:
>Everyday I am inundated with people marking their credit card receipts
>and shipping confirmations as spam. Since I am sending all my
>transactional from a particular domain, I suppose it is possible to do
>something with it.While the wording "This is not spam because it is
>transactional" would need some smithing it would go a long way in
>educating the user that would otherwise, for whatever reason, mark it
>as spam and thereby reducing the amount of noise in the actual
>reporting.

I doubt that the assertion the this message is not spam because it is 
transactional would help.  The message should be easily identified as 
a response to a transaction or else it will get lost in the reporting flood.

Regards,
-sm 

Date: Thu, 24 May 2007 23:46:34 -0400
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] New version of the ARF draft

John R Levine wrote:
> I put it here, in xml and html: http://www.taugh.com/arf/.  It would be
> nice to have a new draft sent in to I-D in time for MAAWG.
> 
> Paul and I went through and fixed a bunch of stuff that made xml2rfc
> complain (if it complains, the RFC editor will complain), along with
> what are intended to be minor edits for style and consistency.
> 

Two more things we still need to do:
1. The IANA section should be reworded from requiring an Designated
Expert to first come, first serve. That to have been the consensus two
weeks ago on the list. One important point though - there are TWO IANA
registries in the draft - one is for headers, and a second is for
feedback types. We discussed the second one a few weeks ago, but should
probably talk about the first one as well.
2. ABNF grammar will be needed at some point.

Yakov

Date: 25 May 2007 00:55:23 -0000
From: John Levine <[email-masked]>
To: [email-masked]
Subject: Re: "transactional" report type (was Re: [feedback-report] New version of the ARF draft)
Organization: 
Cc: 

>Sure, I am just asking that a method be in place that would allow for
>the ~possibility~ that if  an ISP does do transactional tracking, that
>it can be labeled as such.

Hmmn.  How many ISPs do this now?  What incentive do they, as
receivers, have to start doing it in the future?

The point of ARF is to communicate the fact that a recipient had an
opinion about a message.  That's all you get.  Sure, you'd like ISPs
to do more work for you, but it ain't gonna happen.

As Steve A. pointed out, if you want it badly enough you can pay them
to do it, but if you pay them, you can make any kind of bilateral
arrangements you want, and that's outside the scope of a standard
intended for the public Internet.

R's,
John

From: Steve Atkins <[email-masked]>
Subject: Re: "transactional" report type (was Re: [taugh.com-johnl] Re: [feedback-report] New version of the ARF draft)
Date: Thu, 24 May 2007 16:54:54 -0700
To: ARF mailing list <[email-masked]>

On May 24, 2007, at 4:37 PM, Damon Sauer wrote:

> On 5/24/07, J.D. Falk <[email-masked]> wrote:
>
>> On 2007-05-24 15:45, Damon Sauer wrote:
>>
>> >> Seems to me that only the sender can know for sure whether the  
>> message
>> >> was supposed to be transactional.
>> >
>> > Yes, this is true, for the first round. In which we would  
>> research the
>> > issue via the ARF and let the ISP know that it was truely a
>> > transactional message and possibly provide further information  
>> to the
>> > ISP via a back-channel about which of our servers, IP range,  
>> domains,
>> > etc. are used in transactional mailings.
>>
>> Can't you do that anyway?  A report type of "spam" doesn't mean you
>> can't attempt to contact the report generator with questions/ 
>> concerns.
>>
>>
> Sure, I am just asking that a method be in place that would allow for
> the ~possibility~ that if  an ISP does do transactional tracking, that
> it can be labeled as such.
>
>
>> >  1) Diminish or absolve the scoring for mislabeled spam reports.
>>
>> Scoring and other spam filtering techniques are entirely up to the
>> system that received the message.  Adding more report types won't  
>> change
>> that.
>>
>
> This is where we differ in thought. I see transactional messages as an
> class of email entirely on its own. Such as personal, business,
> non-delivery report, domo, auto-respond, marketing, transactional and
> spam.
>
>>
>> ARF says absolutely nothing about what either the report generator or
>> the report recipient is supposed to do with the report.  That's  
>> been one
>> of the primary design goals all along, because we can't predict  
>> how the
>> best practices will evolve.
>>
>>
> I can predict that this would be very useful.
>

If you already have an arrangement with the receiving ISP then they
will know (via DKIM or source IP based arrangement, or similar) that  
you're
claiming that this mail is transactional.

If their user claims the mail is spam, then they're still going to  
send you
a "spam" type ARF report. But there's no need for any additional
notification in either direction, as they already know that you claim
the mail is transactional. And if you and the ISP both know that you
claim the mail is transactional then including that information in the
ARF report will not add any information at all.

 From your description it sounds like you want have an ISP take
every ARF report of mail sent by you that a user complained about
and piggyback on top of it the (pretty much unrelated) data as to
whether the ISP thinks you've told them the mail is transactional or  
not.

There is nothing to stop you and an ISP coming to a private
arrangement to do that, but it doesn't sound like something that
would be of much value to most senders or recipients, so I don't
see any value in standardizing the procedure.

(I think there would be value in standardising the way that a sender
claims something about an email to an ISP, and the ISP confirms
that's the data they have, but piggybacking it on spam complaints
doesn't seem to be the place).

Cheers,
   Steve

Date: Thu, 24 May 2007 19:37:09 -0400
From: "Damon Sauer" <[email-masked]>
To: "J.D. Falk" <[email-masked]>
Subject: Re: "transactional" report type (was Re: [taugh.com-johnl] Re: [feedback-report] New version of the ARF draft)
Cc: ARF mailing list <[email-masked]>

On 5/24/07, J.D. Falk <[email-masked]> wrote:
> On 2007-05-24 15:45, Damon Sauer wrote:
>
> >> Seems to me that only the sender can know for sure whether the message
> >> was supposed to be transactional.
> >
> > Yes, this is true, for the first round. In which we would research the
> > issue via the ARF and let the ISP know that it was truely a
> > transactional message and possibly provide further information to the
> > ISP via a back-channel about which of our servers, IP range, domains,
> > etc. are used in transactional mailings.
>
> Can't you do that anyway?  A report type of "spam" doesn't mean you
> can't attempt to contact the report generator with questions/concerns.
>
Sure, I am just asking that a method be in place that would allow for
the ~possibility~ that if  an ISP does do transactional tracking, that
it can be labeled as such.

> >  1) Diminish or absolve the scoring for mislabeled spam reports.
>
> Scoring and other spam filtering techniques are entirely up to the
> system that received the message.  Adding more report types won't change
> that.

This is where we differ in thought. I see transactional messages as an
class of email entirely on its own. Such as personal, business,
non-delivery report, domo, auto-respond, marketing, transactional and
spam.
>
> ARF says absolutely nothing about what either the report generator or
> the report recipient is supposed to do with the report.  That's been one
> of the primary design goals all along, because we can't predict how the
> best practices will evolve.
>
I can predict that this would be very useful.

Regards,
Damon

Date: Thu, 24 May 2007 16:07:15 -0700
From: "J.D. Falk" <[email-masked]>
Organization: Yahoo!
To: ARF mailing list <[email-masked]>
Subject: Re: "transactional" report type (was Re: [taugh.com-johnl] Re: [feedback-report] New version of the ARF draft)

On 2007-05-24 15:45, Damon Sauer wrote:

>> Seems to me that only the sender can know for sure whether the message
>> was supposed to be transactional.
> 
> Yes, this is true, for the first round. In which we would research the
> issue via the ARF and let the ISP know that it was truely a
> transactional message and possibly provide further information to the
> ISP via a back-channel about which of our servers, IP range, domains,
> etc. are used in transactional mailings.

Can't you do that anyway?  A report type of "spam" doesn't mean you 
can't attempt to contact the report generator with questions/concerns.

>  1) Diminish or absolve the scoring for mislabeled spam reports.

Scoring and other spam filtering techniques are entirely up to the 
system that received the message.  Adding more report types won't change 
that.

ARF says absolutely nothing about what either the report generator or 
the report recipient is supposed to do with the report.  That's been one 
of the primary design goals all along, because we can't predict how the 
best practices will evolve.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Mail

Date: Thu, 24 May 2007 18:45:21 -0400
From: "Damon Sauer" <[email-masked]>
To: "J.D. Falk" <[email-masked]>
Subject: Re: "transactional" report type (was Re: [taugh.com-johnl] Re: [feedback-report] New version of the ARF draft)
Cc: ARF mailing list <[email-masked]>

On 5/24/07, J.D. Falk <[email-masked]> wrote:
> On 2007-05-24 14:21, Damon Sauer wrote:
>
> > I would like to continue to participate in this forum, but please, if
> > you think I am off-base, or just plain loco, please direct those
> > comments to me (even publicly) but not my employer whom is innocent of
> > the slander here.
>
> The only part of this conversation where I think you're acting loco is
> in thinking that I'm attacking you or your employer.
>
> The use case that I thought you were describing is one that's been
> proposed before, so I wasn't exaggerating much -- but I'm glad to hear
> that you're asking for something entirely different.
>
> > I am not asking that the ~user~ further classify the messages they are
> > marking, but that the format allow for a section that could contain
> > information saying that the ISP's internal systems have checked
> > against their known transactional sending IPs, domains, whitelists,
> > etc. and that the email in question either matched or did not match.
>
> So, hopefully understanding a little better now, the use case you have
> in mind is:
>
> 1. [the sender] sends message to a user
> 2. the user reports it as spam to their ISP, via whatever mechanism
> 3. the ISP checks their own systems to determine if the message was
> likely to be transactional
> 4. the ISP reports it to [the sender], using ARF with a report type of
> "transactional"
>
> Right?
>
> Seems to me that only the sender can know for sure whether the message
> was supposed to be transactional.

Yes, this is true, for the first round. In which we would research the
issue via the ARF and let the ISP know that it was truely a
transactional message and possibly provide further information to the
ISP via a back-channel about which of our servers, IP range, domains,
etc. are used in transactional mailings. Which the ISP could then use
in consideration of the next spam report. Which could then be
reflected in the next ARF report that the ISP has matched the email to
our known transactional messaging systems, IP's, etc etc.

 I have a few goals here:

 1) Diminish or absolve the scoring for mislabeled spam reports.
 2) Take corrective actions on the appropriate systems.
 3) Inform ISP's as to the content and/or intent of the mailings.
 4) Have evidence to report to management that scoring is diminished or absolved
 5) Keep a good reputation by ensuring that transactionals are truely
transactional.
 6) Diminish or absolve the scoring for mislabeled spam reports :)

Regards,
Damon

Date: Fri, 25 May 2007 08:38:02 +1000
From: Chris Drake  <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re[2]: "transactional" report type (was Re: [taugh.com-johnl] Re: [feedback-report] New version of the ARF draft)

Hi All,

Since there's probably a few folks unaware - spam report handling is
not automatable:  99% of all spam reports (if you're a legit ISP and
not a spammer :-) are just dumb-users (mostly AOL) hitting the spam
button when they *meant* to hit the trash button beside it.  Of the
last 1000 or so ARF spam reports I've waded through over 12 months,
100.0% of them were legit messages - asking users why they report them
as spam always yields a "Oh - did I? Sorry" response. 

If spam reporting is to be made automatic - users who report spam need
to be given more choices, so robots can handle it properly:

 (x) I just want to delete this email
 (x) This email came from my ex
 (x) I don't like what this email says
 (x) This email is an unsolicited bulk advertisement

 etc etc - with a second question:
 (x) Yes - I want to send this email to several administrators, all of
     whom are going to read it and take action to block the sender

It might sound stupid, but loads of AOL folks would no doubt be
mortified if they realized that their personal nudie pics, office
affair emails, business contracts etc are getting broadcast to ISP
admins when they hit "spam" instead of "trash" by mistake - a
*serious* privacy problem.

Kind Regards,
Chris Drake

Friday, May 25, 2007, 8:16:46 AM, you wrote:

JDF> On 2007-05-24 14:21, Damon Sauer wrote:

>> I would like to continue to participate in this forum, but please, if
>> you think I am off-base, or just plain loco, please direct those
>> comments to me (even publicly) but not my employer whom is innocent of
>> the slander here.

JDF> The only part of this conversation where I think you're acting loco is
JDF> in thinking that I'm attacking you or your employer.

JDF> The use case that I thought you were describing is one that's been
JDF> proposed before, so I wasn't exaggerating much -- but I'm glad to hear
JDF> that you're asking for something entirely different.

>> I am not asking that the ~user~ further classify the messages they are
>> marking, but that the format allow for a section that could contain
>> information saying that the ISP's internal systems have checked
>> against their known transactional sending IPs, domains, whitelists,
>> etc. and that the email in question either matched or did not match.

JDF> So, hopefully understanding a little better now, the use case you have
JDF> in mind is:

JDF> 1. [the sender] sends message to a user
JDF> 2. the user reports it as spam to their ISP, via whatever mechanism
JDF> 3. the ISP checks their own systems to determine if the message was
JDF> likely to be transactional
JDF> 4. the ISP reports it to [the sender], using ARF with a report type of
JDF> "transactional"

JDF> Right?

JDF> Seems to me that only the sender can know for sure whether the message
JDF> was supposed to be transactional.

Date: Thu, 24 May 2007 15:16:46 -0700
From: "J.D. Falk" <[email-masked]>
Organization: Yahoo!
To: ARF mailing list <[email-masked]>
Subject: Re: "transactional" report type (was Re: [taugh.com-johnl] Re: [feedback-report] New version of the ARF draft)

On 2007-05-24 14:21, Damon Sauer wrote:

> I would like to continue to participate in this forum, but please, if
> you think I am off-base, or just plain loco, please direct those
> comments to me (even publicly) but not my employer whom is innocent of
> the slander here.

The only part of this conversation where I think you're acting loco is 
in thinking that I'm attacking you or your employer.

The use case that I thought you were describing is one that's been 
proposed before, so I wasn't exaggerating much -- but I'm glad to hear 
that you're asking for something entirely different.

> I am not asking that the ~user~ further classify the messages they are
> marking, but that the format allow for a section that could contain
> information saying that the ISP's internal systems have checked
> against their known transactional sending IPs, domains, whitelists,
> etc. and that the email in question either matched or did not match.

So, hopefully understanding a little better now, the use case you have 
in mind is:

1. [the sender] sends message to a user
2. the user reports it as spam to their ISP, via whatever mechanism
3. the ISP checks their own systems to determine if the message was 
likely to be transactional
4. the ISP reports it to [the sender], using ARF with a report type of 
"transactional"

Right?

Seems to me that only the sender can know for sure whether the message 
was supposed to be transactional.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Mail

Date: Thu, 24 May 2007 17:37:25 -0400
From: "Damon Sauer" <[email-masked]>
To: "J.D. Falk" <[email-masked]>
Subject: Re: "transactional" report type (was Re: [taugh.com-johnl] Re:[feedback-report] New version of the ARF draft)
Cc: ARF mailing list <[email-masked]>

I was admittedly not clear in my first post that started all of this.

I am not asking that the ~user~ further classify the messages they are
marking, but that the format allow for a section that could contain
information saying that the ISP's internal systems have checked
against their known transactional sending IPs, domains, whitelists,
etc. and that the email in question either matched or did not match.
This would help the sender do a number of things (off the top of my
head) Request whitelisting, verify the message is actually theirs,
look on the proper systems for which database the receipent address
resides as transactional email addresses and marketing addresses more
often than not live on separate databases or systems, etc. We are
genuinely interested in knowing how our reputation is with a
particular ISP and if by marking them as known transactionals means
that our reputation score is not diminished, it would help. If I am
getting too far out in the woods here... let me know.

Regards,
Damon

On 5/24/07, J.D. Falk <[email-masked]> wrote:
> On 2007-05-24 13:30, John Marlin wrote:
>
> > Is there any hope that users and ISPs would be willing to allow (or
> > require) the user to break out the spam designation further.
>
> You're right that this isn't related to the format, so I'll just quickly
> point you towards this study:
>
> http://www.returnpath.biz/resources/archives/2007/01/consumers_want.php
>
> --
> J.D. Falk, Anti-Spam Product Manager
> Yahoo! Mail
> _______________________________________________
> abuse-feedback-report mailing list
> [email-masked]
> http://mipassoc.org/mailman/listinfo/abuse-feedback-report
>

Date: Thu, 24 May 2007 17:21:17 -0400
From: "Damon Sauer" <[email-masked]>
To: "J.D. Falk" <[email-masked]>
Subject: Re: "transactional" report type (was Re: [taugh.com-johnl] Re: [feedback-report] New version of the ARF draft)
Cc: ARF mailing list <[email-masked]>

> If I'm understanding this correctly, your use case is:
>
> 1. Macy's sends (what they consider to be) a transactional message to a user
> 2. the user reports it as spam to their ISP, via whatever mechanism
> 3. the ISP reports it to Macy's, using ARF with a report type of "spam"
> (which really just means "this user complained")
> 4. now Macy's replies somehow to the ISP, using ARF with a report type
> of "transactional" (which really means "the user had no right to
> complain, tell them to suck it up")
> 5. Macy's assumes that the ISP will smack their user for mis-reporting
> the message as spam
>
> Correct?
>
> Has any ISP (or other likely report generator) expressed any interest in
> smacking their users?  Have any users expressed any interest in being
> smacked?

Holy Smokes! Not what I thinking or said at all!

Quite frankly, before even considering this type of reply, I would
have hoped you would have been more professional and sent it to me
directly rather than sullying my employer's excellent worldwide
reputation in a public forum.
<stronger words and thoughts snipped>

1) What we consider to be a transactional message is what the CAN-SPAM
ACT also considers a transactional message.

2,3) Given

4) We would reply to the ISP that this is a transactional message (if
allowed to do so, which I ~thought~ was the basis of this
conversation). Which I would hope would mean to the ISP, that a good
corporate citizen has received the complaint and has actually done
something with it rather than send to /dev/null.

5) And being good and trusted corporate citizens the ISP in question
would not diminish our reputation scores over a misclassified email.
Our excellent reputation IS what I am worried about keeping and
promoting.

I have ALWAYS supported the fine and excellent work done in this group
as well as the others you and I have both participated in. In every
company I have worked for, I have asked for and have received the
highest level of support for implementing protocols such as SPF, DKIM,
and adherence to the CAN-SPAM Act and I completely and utterly reject
your notion that something less than an actual care and loyalty to our
customers and their experience is our goal.

I would like to continue to participate in this forum, but please, if
you think I am off-base, or just plain loco, please direct those
comments to me (even publicly) but not my employer whom is innocent of
the slander here.

Regards,
Damon Sauer

Date: Thu, 24 May 2007 13:55:25 -0700
From: "J.D. Falk" <[email-masked]>
Organization: Yahoo!
To: ARF mailing list <[email-masked]>
Subject: Re: "transactional" report type (was Re: [taugh.com-johnl]	Re:[feedback-report] New version of the ARF draft)

On 2007-05-24 13:30, John Marlin wrote:

> Is there any hope that users and ISPs would be willing to allow (or
> require) the user to break out the spam designation further.

You're right that this isn't related to the format, so I'll just quickly 
point you towards this study:

http://www.returnpath.biz/resources/archives/2007/01/consumers_want.php

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Mail

Content-class: urn:content-classes:message
Subject: RE: "transactional" report type (was Re: [taugh.com-johnl] Re:[feedback-report] New version of the ARF draft)
Date: Thu, 24 May 2007 14:30:28 -0600
From: "John Marlin" <[email-masked]>
To: "ARF mailing list" <[email-masked]>

Is there any hope that users and ISPs would be willing to allow (or
require) the user to break out the spam designation further. I recall
that GoodMail was (is?) doing something like this, where the user
flagging an unwanted message would then be prompted to indicate whether
this message is: A) truly spam from an unrelated party, B) an unwanted
message from a company that I still otherwise do business with, C)
something that I signed up for but no longer wish to receive, and some
other categories that I can't seem to dredge up from my biological
memory stick.

Perhaps this doesn't really fit in this ARF discussion, but it seems
like this could be a really useful distinction to be able to feed back
through the system. Of course, in an ideal world, users would always
choose the "Unsubscribe" link in the email, but in practice we know that
users routinely hit the SPAM button instead, even when those users are
our clients, have signed up for the messages in the first place, and
often have happily been receiving these messages for months or years.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> Of J.D. Falk
> Sent: Thursday, May 24, 2007 14:10 2PM
> To: ARF mailing list
> Subject: "transactional" report type (was Re: 
> [taugh.com-johnl] Re:[feedback-report] New version of the ARF draft)
> 
> On 2007-05-24 11:17, Damon Sauer wrote:
> 
> > Everyday I am inundated with people marking their credit 
> card receipts 
> > and shipping confirmations as spam. Since I am sending all my 
> > transactional from a particular domain, I suppose it is 
> possible to do 
> > something with it.While the wording "This is not spam because it is 
> > transactional" would need some smithing it would go a long way in 
> > educating the user that would otherwise, for whatever 
> reason, mark it 
> > as spam and thereby reducing the amount of noise in the actual 
> > reporting.
> 
> If I'm understanding this correctly, your use case is:
> 
> 1. Macy's sends (what they consider to be) a transactional 
> message to a user 2. the user reports it as spam to their 
> ISP, via whatever mechanism 3. the ISP reports it to Macy's, 
> using ARF with a report type of "spam" 
> (which really just means "this user complained") 4. now 
> Macy's replies somehow to the ISP, using ARF with a report 
> type of "transactional" (which really means "the user had no 
> right to complain, tell them to suck it up") 5. Macy's 
> assumes that the ISP will smack their user for mis-reporting 
> the message as spam
> 
> Correct?
> 
> Has any ISP (or other likely report generator) expressed any 
> interest in smacking their users?  Have any users expressed 
> any interest in being smacked?
> 
> --
> J.D. Falk, Anti-Spam Product Manager
> Yahoo! Mail
> _______________________________________________
> abuse-feedback-report mailing list
> [email-masked]
> http://mipassoc.org/mailman/listinfo/abuse-feedback-report
> 

Date: Thu, 24 May 2007 13:09:45 -0700
From: "J.D. Falk" <[email-masked]>
Organization: Yahoo!
To: ARF mailing list <[email-masked]>
Subject: "transactional" report type (was Re: [taugh.com-johnl] Re: [feedback-report] New version of the ARF draft)

On 2007-05-24 11:17, Damon Sauer wrote:

> Everyday I am inundated with people marking their credit card receipts
> and shipping confirmations as spam. Since I am sending all my
> transactional from a particular domain, I suppose it is possible to do
> something with it.While the wording "This is not spam because it is
> transactional" would need some smithing it would go a long way in
> educating the user that would otherwise, for whatever reason, mark it
> as spam and thereby reducing the amount of noise in the actual
> reporting.

If I'm understanding this correctly, your use case is:

1. Macy's sends (what they consider to be) a transactional message to a user
2. the user reports it as spam to their ISP, via whatever mechanism
3. the ISP reports it to Macy's, using ARF with a report type of "spam" 
(which really just means "this user complained")
4. now Macy's replies somehow to the ISP, using ARF with a report type 
of "transactional" (which really means "the user had no right to 
complain, tell them to suck it up")
5. Macy's assumes that the ISP will smack their user for mis-reporting 
the message as spam

Correct?

Has any ISP (or other likely report generator) expressed any interest in 
smacking their users?  Have any users expressed any interest in being 
smacked?

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Mail

From: John Levine <[email-masked]>
Newsgroups: iecc.abuse
Subject: Re: [feedback-report] New version of the ARF draft
Date: Thu, 24 May 2007 18:43:01 +0000 (UTC)
Organization: Taughannock Networks, Trumansburg NY
To: [email-masked]

> Everyday I am inundated with people marking their credit card
> receipts and shipping confirmations as spam. Since I am sending all
> my transactional from a particular domain, I suppose it is possible
> to do something with it.While the wording "This is not spam because
> it is transactional" would need some smithing it would go a long way
> in educating the user that would otherwise, for whatever reason,
> mark it as spam and thereby reducing the amount of noise in the
> actual reporting.

ARF is the wrong end of the hose for this.  

It makes tons of sense for you to mark your outgoing transactional
mail (and for people to certify it so your marks are credible*), but
ARF is what happens after someone pushes the spam button, too late to
mark it there.

R's,
John

* - so come talk to me about DAC and VBR, ok?

--=154311=----

Date: Thu, 24 May 2007 14:17:48 -0400
From: "Damon Sauer" <[email-masked]>
To: "J.D. Falk" <[email-masked]>
Subject: Re: [taugh.com-johnl] Re: [feedback-report] New version of the ARF draft
Cc: ARF mailing list <[email-masked]>

On 5/24/07, J.D. Falk <[email-masked]> wrote:
> On 2007-05-24 06:49, Damon Sauer wrote:
>
> > How about adding one more:
> > I know a big one for me is * transactional. Where a user is part of a
> > group or system that sends messages regarding status or account
> > changes, billing, receipts, etc.
> > I think this would cover a great deal of the *not-spam reports and
> > would help catagorize them better.
>
> How would this be used?  Would users be shown "this is not spam" and
> "this is not spam because it is transactional" options when reporting
> miscategorization?  Or, would the report generator use some sort of
> content matching?
>
> Also, is this the CAN-SPAM definition of "transactional," or the
> Goodmail definition, or...?
>
> --
> J.D. Falk, Anti-Spam Product Manager
> Yahoo! Mail

Of course the legal definition is the one I would choose :-)
I am now wearing the hat of postmaster at Macy's. (And contrary to a
recent report in USAToday, I added DKIM sigs to all our Macys.com
transactional email 6 months ago.)

Everyday I am inundated with people marking their credit card receipts
and shipping confirmations as spam. Since I am sending all my
transactional from a particular domain, I suppose it is possible to do
something with it.While the wording "This is not spam because it is
transactional" would need some smithing it would go a long way in
educating the user that would otherwise, for whatever reason, mark it
as spam and thereby reducing the amount of noise in the actual
reporting.

I am certainly not standing on the soapbox shouting. Just offering
suggestions from the responsible neighbor (corporate) viewpoint and
letting you guys poke holes.

Damon

Date: Thu, 24 May 2007 10:04:05 -0700
From: "J.D. Falk" <[email-masked]>
Organization: Yahoo!
To: ARF mailing list <[email-masked]>
Subject: Re: [taugh.com-johnl] Re: [feedback-report] New version of the ARF draft

On 2007-05-24 06:49, Damon Sauer wrote:

> How about adding one more:
> I know a big one for me is * transactional. Where a user is part of a
> group or system that sends messages regarding status or account
> changes, billing, receipts, etc.
> I think this would cover a great deal of the *not-spam reports and
> would help catagorize them better.

How would this be used?  Would users be shown "this is not spam" and 
"this is not spam because it is transactional" options when reporting 
miscategorization?  Or, would the report generator use some sort of 
content matching?

Also, is this the CAN-SPAM definition of "transactional," or the 
Goodmail definition, or...?

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Mail

Date: Thu, 24 May 2007 12:39:01 -0400 (EDT)
From: John R Levine <[email-masked]>
To: Damon Sauer <[email-masked]>
Subject: Re: [feedback-report] New version of the ARF draft
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>

>>   * miscategorized - indicates that the content categorization applied in
>>     connection with a certification or reputation system was incorrect
>>   * not-spam - indicates that a message that was tagged or categorized as
>>     spam (such as by an ISP) is not spam

> How about adding one more:
> I know a big one for me is * transactional. Where a user is part of a
> group or system that sends messages regarding status or account
> changes, billing, receipts, etc.
> I think this would cover a great deal of the *not-spam reports and
> would help catagorize them better.

While we presumably all agree that we generally want to treat 
transactional mail better than most other mail from large senders*, I 
don't think this is a good way to do it.  We know that users won't 
distinguish between spam and opt-out, they don't even understand the 
difference between opt-out and opt-out-list, they just want whatever it is 
to stop.  Similarly, people seem somewhat willing to press a not-spam 
button, but it seems equally implausible that they will tell us why it's 
not spam.

If certification a la VBR gets any traction, a lot of mail will have 
assertions in a header about whether a message is a transaction, something 
that senders have plenty of incentive to add, so if you want to treat them 
more favorably, there's your tag.

I'm not opposed to adding subcategories at some point in the future, but 
I'd rather experiment first, add to the spec later.

Incidentally, if you're wondering why I think "miscategorized" is OK, it's 
because it's orthogonal to spam/not-spam.  It's entirely possible that I 
would get mail from a bank, and I would see that it's not a transaction, 
but it's not spam, either.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

* - note all the hedging and qualification

Date: Thu, 24 May 2007 09:49:54 -0400
From: "Damon Sauer" <[email-masked]>
To: "John R Levine" <[email-masked]>
Subject: Re: [taugh.com-johnl] Re: [feedback-report] New version of the ARF draft
Cc: ARF mailing list <[email-masked]>

On 5/23/07, John R Levine <[email-masked]> wrote:
> >>   * miscategorized - indicates that the content categorization applied in
> >>     connection with a certification or reputation system was incorrect
> >
> > What'll this be used for?
>
> I added it for VBR but it's intended to be more general.  We observe that
> certification or reputation systems will probably have different opinions
> about different kinds of mail, e.g., a bank regulator would vouch for the
> banks' transactions but not their ads.  Lacking A.I. to tell mechanically
> what category a message falls into, we expect senders to put assertions
> into a header (VBR, for example), that this is a transaction, this is an
> ad, etc.  This code means they lied, it claimed to be one thing but was
> really another.
>
> >>   * not-spam - indicates that a message that was tagged or categorized as
> >>     spam (such as by an ISP) is not spam
> >>
> >> The former is intended to send back to a certifier or reputation provider,
> >> the second to your own ISP or mail host to tune their filters.
> >
> > Doh, I should've thought of that.  *grin*

How about adding one more:
I know a big one for me is * transactional. Where a user is part of a
group or system that sends messages regarding status or account
changes, billing, receipts, etc.
I think this would cover a great deal of the *not-spam reports and
would help catagorize them better.

Date: Wed, 23 May 2007 23:37:32 -0400 (EDT)
From: John R Levine <[email-masked]>
To: "J.D. Falk" <[email-masked]>
Subject: Re: [taugh.com-johnl] Re: [feedback-report] New version of the ARF draft
Cleverness: None detected
Cc: ARF mailing list <[email-masked]>

>>   * miscategorized - indicates that the content categorization applied in
>>     connection with a certification or reputation system was incorrect
>
> What'll this be used for?

I added it for VBR but it's intended to be more general.  We observe that 
certification or reputation systems will probably have different opinions 
about different kinds of mail, e.g., a bank regulator would vouch for the 
banks' transactions but not their ads.  Lacking A.I. to tell mechanically 
what category a message falls into, we expect senders to put assertions 
into a header (VBR, for example), that this is a transaction, this is an 
ad, etc.  This code means they lied, it claimed to be one thing but was 
really another.

>>   * not-spam - indicates that a message that was tagged or categorized as
>>     spam (such as by an ISP) is not spam
>> 
>> The former is intended to send back to a certifier or reputation provider, 
>> the second to your own ISP or mail host to tune their filters.
>
> Doh, I should've thought of that.  *grin*

Yeah, the hope is to put together the pieces to enable add-ins to regular 
MUAs with a spam/not-spam button that actually works like the ones AOL and 
Yahoo have.  This is one piece, it also needs something in the mail to say 
"we delivered this to you and we thought it was/wasn't spam".  It occurs 
to me that this is only a small step beyond Murray's draft about 
authentication results.

>> 1.  Whether encoding of the machine readable part should be limited to 7-bit
> It should follow the same convention as email addresses and URIs, whatever 
> that is these days.

The scenario is that you have a spam in hand where some characters have 
the high bit set, probably because some piece of Korean spamware blatted 
it out that way.  Since SMTP is usually only 7 bit, how do you send back 
the copy of the spam.  The he-man approach is to use 8BITMIME, do content 
negotiation for each SMTP hop, and downcode if need be.  The wimpy 
approach is just to use base64 on the way out.  Since everyone in the 
world speaks base64, and downcoding on the way has all sorts of problems 
such as breaking any signature on the ARF message, I vote for the latter.

>> 2.  Whether there is a need for both "opt-out" and "opt-out-list",
>>      and whether this format should be used for opt-outs at all.
> I say change it to "unsubscribe"

Remember that we're supposed to reflect existing practice.  Has anyone 
ever seen an opt-out or opt-out-list in the wild?  If so, we gotta leave 
them in, if not, change is fine.

>> 3.   Whether the "from" address should be required to be a human just
>>      like other RFCs in the "message/report" family.
>
> No, but the address SHOULD accept messages (vs. bouncing 'em) --

Well, keeping in mind actual practice, the actual ARF messages I see 
mostly come from [email-masked] and [email-masked].  I haven't 
tried writing to those addresses.  Anyone know who or what answers?

> If there were such an indicator, would the mungers in the room use it?

Good question.

> Now for the draft itself (I may have submitted the same comments on previous 
> drafts, not sure.)

I'll collect comments for another day or so and do another version.  I'd 
like to send it off to I-D on Monday to give it a week to get into the I-D 
archive.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

Date: Wed, 23 May 2007 22:48:35 -0400 (EDT)
From: John R Levine <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] Defintion of "Received-Date: "
Cleverness: None detected

> "Received-Date:" - indicates the date the original message was received by
> the report generator.  This field MUST BE formatted as per section 3.3 of
> RFC 2822 [RFC2822].  ...

> Perhaps a better definition would be "..received in the final destination
> inbox" or something along these lines?

Good suggestion, I'll reword it.

I think we all agree that the intention is to log the time that the
offending message arrived at the reporting system. so the recipient of
the report can use the timestamp to find the offending message in
their outbound logs.

R's,
John

Date: Wed, 23 May 2007 22:09:23 -0400 (EDT)
From: John R Levine <[email-masked]>
To: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] Defintion of "Received-Date: "
Cleverness: None detected

> "Received-Date:" - indicates the date the original message was received by
> the report generator.  This field MUST BE formatted as per section 3.3 of
> RFC 2822 [RFC2822].  ...

> Perhaps a better definition would be "..received in the final destination
> inbox" or something along these lines?

Good suggestion, I'll reword it.

I think we all agree that the intention is to log the time that the
offending message arrived at the reporting system. so the recipient of
the report can use the timestamp to find the offending message in
their outbound logs.

R's,
John

Date: Wed, 23 May 2007 16:51:37 -0700
From: "J.D. Falk" <[email-masked]>
Organization: Yahoo!
To: John R Levine <[email-masked]>
Subject: Re: [feedback-report] New version of the ARF draft
Cc: ARF mailing list <[email-masked]>

On 2007-05-22 16:44, John R Levine wrote:

>   * miscategorized - indicates that the content categorization applied in
>     connection with a certification or reputation system was incorrect

What'll this be used for?

>   * not-spam - indicates that a message that was tagged or categorized as
>     spam (such as by an ISP) is not spam
> 
> The former is intended to send back to a certifier or reputation provider, the 
> second to your own ISP or mail host to tune their filters.

Doh, I should've thought of that.  *grin*

> Near the end, there's a list of questions added in previous versions.  If we 
> can agree on the answers to some or all of them we can update the draft and 
> take out the questions.
> 
> 1.  Whether encoding of the machine readable part should be limited
>      to 7-bit

It should follow the same convention as email addresses and URIs, 
whatever that is these days.

> 2.  Whether there is a need for both "opt-out" and "opt-out-list",
>      and whether this format should be used for opt-outs at all.

I say change it to "unsubscribe" (to comply with the usage in the 
List-Unsubscribe header) and include a warning that most mailing list 
management software doesn't understand ARF and possibly never will.

> 3.   Whether the "from" address should be required to be a human just
>      like other RFCs in the "message/report" family.

No, but the address SHOULD accept messages (vs. bouncing 'em) -- and if 
the address is one which is not read (devnull, etc) there SHOULD be a 
way to contact a responsible party for the report generator, either 
described in the human-readable portion or negotiated out-of-band 
beforehand.

> 4.  Whether there is a need for a new header to indicate munging of
>      the included email message.

I don't see the need, but I don't really care as long as it's optional.

If there were such an indicator, would the mungers in the room use it?

> 5.  Whether different type of convention should be allowed for
>      subject lines.

I doubt this will get much compliance.

> 6.  Whether there should be different types defined for
>      "Reported-Uri" to better indicate to the report receiver how they are
>      related to the email message in question.

There are so many edge cases here that I suspect our brains would 
explode if we attempted to categorize even the 100 most common.

(The #1 most common is "you own the IP and signed up to receive these 
reports," obviously, but from there it gets complicated.)

Now for the draft itself (I may have submitted the same comments on 
previous drafts, not sure.)

> 1.  Introduction
> 
>    As the spam problem has grown in the past few years, network
>    operators have begun to exchange abuse reports among themselves and
>    other parties to combat this problem.  However, different operators
>    define their own formats and the receivers are forced to write custom
>    software to interpret the many types of them.  In addition, many
>    operators use various other report formats to provide non-abuse
>    feedback about processed email.

As the spam problem continues to expand and potential solutions evolve, 
network operators are increasingly exchanging abuse reports among 
themselves and other parties.  However, different operators have defined 
their own formats, and thus the receivers of these reports are forced to 
write custom software to interpret each. In addition, many operators use 
various other report formats to provide non-abuse-related feedback about 
processed email.

  [ . . . ]
>    This format is intended primarily as an Abuse Reporting Format (ARF)
>    for reporting email abuse but also includes support for feedback
>    loops, virus reports and other similar activities.

This format is intended primarily as an Abuse Reporting Format (ARF) for 
reporting email abuse but also includes support for direct feedback via 
end user mail clients, reports of some types of virus activity, and some 
similar issues.

>    This document only defines the format and content type to be used for
>    these reports.  Determination of where these reports should be sent,
>    how trust among report senders and receivers is established, and
>    reports related to more than one message are outside the scope of
>    this document.

This document only defines the format and 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.

  [ . . . ]
> 2.  Intent
> 
>    The reports defined in this document are intended for several
>    purposes:
> 
>    o  To inform ISPs about email abuse originating from or related to
>       their networks
> 
>    o  To provide feedback about abuse complaints to email service
>       providers and relevant third parties (such as reputation
>       providers)
  [ . . . ]
>    o  To inform email service provides about opt-out requests

o To inform email service providers or other primarily outbound senders 
that there may be issues regarding their mail.  These issues include 
(but are not limited to) reports that the mail may be considered to be 
"spam" by a recipient of the message.

Need a statement about certification & reputation systems.

  [ . . . ]
> 5.  Format of 'message/feedback-report' Content Type
> 
>    This content type provides a machine-readable section intended to let
>    the report generator convey metadata to the report receiver.  The
>    intent of this section is it allow report generators to convey
>    metadata to report receivers that may not available or may not be
>    readily available from the originating email message or headers.

This content type provides a machine-readable section intended to let 
the report generator convey metadata to the report receiver.  The intent 
of this section is to convey information which may not be obvious or may 
not be easily extracted from the originating email message or headers.

>    The body of this content type consists of multiple "fields" formatted
>    according to the ABNF of RFC 822 [RFC0822] header "fields".  This
>    section defines the initial set of fields provided by this
>    specification.  Additional fields maybe registered according to the
>    procedure described later on in this document.

These fields SHOULD NOT be repeated in the header area of the message 
containing this report.

> Note that these
>    fields represent information that the receiver is asserting about the
>    report in question, but are not necessarily verifiable.  Report
>    receivers MUST NOT assume that these assertions are always true.

Maybe change "true" to "accurate?"

  [ . . . ]
> 5.1.  Required Fields
  [ . . . ]
>    o  "User-Agent:" - indicates the name and version of the software
>       program that generated the report.  The format of this field MUST
>       follow section 14.43 of RFC 2616 [RFC2616].

A report receiver MUST NOT assume that the set of potential User-Agents 
is finite.

  [ . . . ]
>    o  "Version" - indicates the version of specification that the report
>       generator is using to generate the report.  The version number in
>       this specification is set to "0.1".

Will we change that to 1.0 upon publication?

>    o  "Received-Date:" - indicates the date the original message was
>       received by the report generator.  This field MUST BE formatted as
>       per section 3.3 of RFC 2822 [RFC2822].

Likely edge case: what if the report generator isn't the user's ISP?

  [ . . . ]
>    o  "Authentication-Results:" - indicates the result of an
>       authentication check run by the report generator.  The format of
>       this field is is defined in draft-kucherawy-sender-auth-header
>       [AUTH-HEADER].  Report receivers should note that this field only
>       indicates an assertion made by the report generator.

Murray told me that he's hoping to have a new draft ready shortly.

  [ . . . ]
> 8.2.  Initial values for the "Feedback-Type" registry
  [ . . . ]
>    o  miscategorized - indicates that the content categorization applied
>       in connection with a certification or reputation system was
>       incorrect
  [ . . . ]
>    o  not-spam - indicates that a message that was tagged or categorized
>       as spam (such as by an ISP) is not spam

Looks like these two could overlap a lot.  Where's the line?

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Mail

From: "Justin Rietz" <[email-masked]>
To: <[email-masked]>
Date: Wed, 23 May 2007 12:25:10 -0700
Subject: [feedback-report] Defintion of "Received-Date:" WAS abuse-feedback-report Digest, Vol 16, Issue 6

Sorry for the late comment.

I have been working both with internal and external engineers on
implementing various systems using ARF.  Inevitably there is confusion over
the defintion of the "Received-Date:" field.

"Received-Date:" - indicates the date the original message was received by
the report generator.  This field MUST BE formatted as per section 3.3 of
RFC 2822 [RFC2822].

The confusion comes from the words "Report Generator".  Some take this to
mean the recipient of the original email (i.e. the end user) and some take
this to mean the application / process at the ISP that generates the ARF
message after a user clicks a "spam" button..  Obviously the field values
would differ based upon which definitions is followed

Perhaps a better definition would be "..received in the final destination
inbox" or something along these lines?

Justin

Justin Rietz
Goodmail Systems

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, May 23, 2007 12:00 PM
To: [email-masked]
Subject: abuse-feedback-report Digest, Vol 16, Issue 6

Send abuse-feedback-report mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	http://mipassoc.org/mailman/listinfo/abuse-feedback-report
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of abuse-feedback-report digest..."

Today's Topics:

   1. New version of the ARF draft (John R Levine)

----------------------------------------------------------------------

Message: 1
Date: Tue, 22 May 2007 19:44:17 -0400 (EDT)
From: John R Levine <[email-masked]>
Subject: [feedback-report] New version of the ARF draft
To: ARF mailing list <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

I put it here, in xml and html: http://www.taugh.com/arf/.  It would be nice
to have a new draft sent in to I-D in time for MAAWG.

Paul and I went through and fixed a bunch of stuff that made xml2rfc
complain (if it complains, the RFC editor will complain), along with what
are intended to be minor edits for style and consistency.

We added these two feedback types.  If people hate them, we can take them
back
out:

  * miscategorized - indicates that the content categorization applied in
    connection with a certification or reputation system was incorrect

  * not-spam - indicates that a message that was tagged or categorized as
    spam (such as by an ISP) is not spam

The former is intended to send back to a certifier or reputation provider,
the second to your own ISP or mail host to tune their filters. Like every
other content type, these are just assertions by whoever's sending the
report, which the receiving system is free to interpret or not interpret any
way it wants.

Near the end, there's a list of questions added in previous versions.  If we
can agree on the answers to some or all of them we can update the draft and
take out the questions.

1.  Whether encoding of the machine readable part should be limited
     to 7-bit

2.  Whether there is a need for both "opt-out" and "opt-out-list",
     and whether this format should be used for opt-outs at all.

3.   Whether the "from" address should be required to be a human just
     like other RFCs in the "message/report" family.

4.  Whether there is a need for a new header to indicate munging of
     the included email message.

5.  Whether different type of convention should be allowed for
     subject lines.

6.  Whether there should be different types defined for
     "Reported-Uri" to better indicate to the report receiver how they are
     related to the email message in question.

Suggested answers:

1. yes, everyone can decode base64 and it avoids issues of silent munging by
intermediate systems

3, 5, and 6. no, current practice is that they are whatever the reporting
party wants them to be

4. no, current practice doesn't, "it's munged" doesn't tell you anything of
use that you couldn't guess anyway, and if you ask people to tell you
exactly how it's munged, they won't.

R's,
John

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.

------------------------------

_______________________________________________
abuse-feedback-report mailing list
[email-masked]
http://mipassoc.org/mailman/listinfo/abuse-feedback-report

End of abuse-feedback-report Digest, Vol 16, Issue 6
****************************************************

Date: Tue, 22 May 2007 19:44:17 -0400 (EDT)
From: John R Levine <[email-masked]>
To: ARF mailing list <[email-masked]>
Cleverness: None detected
Subject: [feedback-report] New version of the ARF draft

I put it here, in xml and html: http://www.taugh.com/arf/.  It would be nice to 
have a new draft sent in to I-D in time for MAAWG.

Paul and I went through and fixed a bunch of stuff that made xml2rfc complain 
(if it complains, the RFC editor will complain), along with what are intended 
to be minor edits for style and consistency.

We added these two feedback types.  If people hate them, we can take them back 
out:

  * miscategorized - indicates that the content categorization applied in
    connection with a certification or reputation system was incorrect

  * not-spam - indicates that a message that was tagged or categorized as
    spam (such as by an ISP) is not spam

The former is intended to send back to a certifier or reputation provider, the 
second to your own ISP or mail host to tune their filters. Like every other 
content type, these are just assertions by whoever's sending the report, which 
the receiving system is free to interpret or not interpret any way it wants.

Near the end, there's a list of questions added in previous versions.  If we 
can agree on the answers to some or all of them we can update the draft and 
take out the questions.

1.  Whether encoding of the machine readable part should be limited
     to 7-bit

2.  Whether there is a need for both "opt-out" and "opt-out-list",
     and whether this format should be used for opt-outs at all.

3.   Whether the "from" address should be required to be a human just
     like other RFCs in the "message/report" family.

4.  Whether there is a need for a new header to indicate munging of
     the included email message.

5.  Whether different type of convention should be allowed for
     subject lines.

6.  Whether there should be different types defined for
     "Reported-Uri" to better indicate to the report receiver how they are
     related to the email message in question.

Suggested answers:

1. yes, everyone can decode base64 and it avoids issues of silent munging by 
intermediate systems

3, 5, and 6. no, current practice is that they are whatever the reporting
party wants them to be

4. no, current practice doesn't, "it's munged" doesn't tell you anything
of use that you couldn't guess anyway, and if you ask people to tell you
exactly how it's munged, they won't.

R's,
John

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: Mon, 14 May 2007 23:02:16 -0400
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
CC: ARF mailing list <[email-masked]>
Subject: Re: [feedback-report] Revised ARF draft

John R Levine wrote:
> It'd be nice to have a live draft to work on by the time of the MAAWG
> meeting. So please send me your suggestions and I will bash something
> together.
> 
> Based on last week's messages, I hear a consensus that we will not add
> any more report types, but will put in language asking IANA to establish
> a registry for them.
> 

That language is already in the last draft I did:

http://www.shaftek.org/publications/drafts/abuse-report/draft-shafranovich-feedback-report-01.html#anchor11

You just have to change it from expert managed.

Yakov

Date: Mon, 14 May 2007 22:34:31 -0400 (EDT)
From: John R Levine <[email-masked]>
To: ARF mailing list <[email-masked]>
Cleverness: None detected
Subject: [feedback-report] Revised ARF draft

It'd be nice to have a live draft to work on by the time of the MAAWG meeting. 
So please send me your suggestions and I will bash something together.

Based on last week's messages, I hear a consensus that we will not add any more 
report types, but will put in language asking IANA to establish a registry for 
them.

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: Tue, 08 May 2007 00:02:15 -0400
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
To: [email-masked]
Subject: Re: [taugh.com-johnl] Re: [feedback-report] How's that revised ARF draft coming along?

John R Levine wrote:
>> Any idea on what is left to do for it, aside for editing, etc? Where
>> there any features that need to be added?
> 
> As far as I know, it's just editing.  I might want to add another couple
> of report types for use in spam/not-spam feedback to one's own ISP, but
> it's not urgent.
> 

You can go right ahead. Unfortunatly, I don't have the time to do it
properly myself.

Yakov

Date: Mon, 07 May 2007 19:38:43 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: [taugh.com-johnl] Re: [feedback-report] How's that revised ARF draft coming along?
Reply-To: [email-masked]

John R Levine wrote:
>> Whether registry entries need policing enforcement, rather than simple 
>> bookkeeping rules, is a basic question to decide now.
> 
> I'm with you, so long as the proposed entry has a description of what it 
> does that is reasonably coherent, add it in.  We're talking about 
> strings here, it's not like we're going to run out of namespace.

My own bias is towards requiring RFC publication of a spec for the behaviors
associated with the registered name.  That's a high bar, but does not require
formal standardization.

I'm not religiously opposed to simple FCFS, but I really do think that
creating a public, formal registration ought to require an archival version of
a spec to explain it.

If we believe there will be lots of private experimentation, with some of it
migrating to more general use, then FCFS is probably the better choice.

I doubt it will be that wild and active a time for ARF...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: Steve Atkins <[email-masked]>
Subject: Re: [taugh.com-johnl] Re: [feedback-report] How's that revised ARF draft coming along?
Date: Mon, 7 May 2007 18:24:43 -0700
To: [email-masked]

On May 7, 2007, at 6:14 PM, Yakov Shafranovich wrote:

> John R Levine wrote:
>
>>> Whether registry entries need policing enforcement, rather than  
>>> simple
>>> bookkeeping rules, is a basic question to decide now.
>>>
>>
>> I'm with you, so long as the proposed entry has a description of  
>> what it
>> does that is reasonably coherent, add it in.  We're talking about
>> strings here, it's not like we're going to run out of namespace.
>>
>>
>
> Fine with me then. Here is the relevant option from IANA rfc:
>
>
>> First Come First Served - Anyone can obtain an assigned number, so
>>            long as they provide a point of contact and a brief
>>            description of what the value would be used for.  For
>>            numbers, the exact value is generally assigned by the  
>> IANA;
>>            with names, specific names are usually requested.
>>
>>            Examples: vnd. (vendor assigned) MIME types [MIME-REG],  
>> TCP
>>            and UDP port numbers.
>>

Works for me. It's not actually going to be used as reference by
anyone developing software to parse ARF reports, but if it gets
ARF senders who have the same needs to work together so they're
using the same approach then a simple registry should work
nicely.

Cheers,
   Steve

Date: Mon, 07 May 2007 21:14:12 -0400
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
To: [email-masked]
Subject: Re: [taugh.com-johnl] Re: [feedback-report] How's that revised ARF draft coming along?

John R Levine wrote:
>> Whether registry entries need policing enforcement, rather than simple
>> bookkeeping rules, is a basic question to decide now.
> 
> I'm with you, so long as the proposed entry has a description of what it
> does that is reasonably coherent, add it in.  We're talking about
> strings here, it's not like we're going to run out of namespace.
> 

Fine with me then. Here is the relevant option from IANA rfc:

> First Come First Served - Anyone can obtain an assigned number, so
>            long as they provide a point of contact and a brief
>            description of what the value would be used for.  For
>            numbers, the exact value is generally assigned by the IANA;
>            with names, specific names are usually requested.
> 
>            Examples: vnd. (vendor assigned) MIME types [MIME-REG], TCP
>            and UDP port numbers.

Date: Mon, 7 May 2007 20:53:02 -0400 (EDT)
From: John R Levine <[email-masked]>
To: [email-masked]
Subject: Re: [taugh.com-johnl] Re: [feedback-report] How's that revised ARF draft coming along?
Cleverness: None detected
Cc: [email-masked]

> Whether registry entries need policing enforcement, rather than simple 
> bookkeeping rules, is a basic question to decide now.

I'm with you, so long as the proposed entry has a description of what it 
does that is reasonably coherent, add it in.  We're talking about strings 
here, it's not like we're going to run out of namespace.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

Date: Mon, 07 May 2007 17:00:00 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Yakov Shafranovich <[email-masked]>
Subject: Re: [feedback-report] How's that revised ARF draft coming along?
Cc: [email-masked]
Reply-To: [email-masked]

Yakov Shafranovich wrote:
> According to RFC 2434, it shouldn't be a problem. I think we are looking
> at an "expert" registry where the IESG assigns one expert to be in
> charge of it and it takes about 4-6 weeks to make changes.

Or not even that.

Whether registry entries need policing enforcement, rather than simple 
bookkeeping rules, is a basic question to decide now.

Personally, I'm fine with registering entries that are useless.  If they are 
bad, no one will use them.  (I'm also a fan of minimal overhead registration...)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 07 May 2007 18:56:46 -0400
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
To: [email-masked]
Subject: Re: [feedback-report] How's that revised ARF draft coming along?

John R Levine wrote:
>> I'm inclined to suggest request publishing this as an Informational
>> RFC, to avoid the hassles of standardization.  If ARF gains a wide
>> enough base, it's easy to revisit this.
> 
> Can informational RFCs set up IANA registries?  Or would we have to do
> it ourselves?
> 

According to RFC 2434, it shouldn't be a problem. I think we are looking
at an "expert" registry where the IESG assigns one expert to be in
charge of it and it takes about 4-6 weeks to make changes.

Yakov

Date: Mon, 7 May 2007 16:20:32 -0400 (EDT)
From: John R Levine <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] How's that revised ARF draft coming along?
Cleverness: None detected
Cc: [email-masked]

> I suggest NOT adding anything for which there is not an already demonstrated 
> strong need.  Instead, report types can be a registry, so that other values 
> can be added as needed.

That's fine with me, except ...

> I'm inclined to suggest request publishing this as an Informational RFC, to 
> avoid the hassles of standardization.  If ARF gains a wide enough base, it's 
> easy to revisit this.

Can informational RFCs set up IANA registries?  Or would we have to do it 
ourselves?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

Date: Mon, 07 May 2007 12:14:23 -0700
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: "J.D. Falk" <[email-masked]>
Subject: Re: [taugh.com-johnl] Re: [feedback-report] How's that revised ARF draft coming along?
Cc: [email-masked]
Reply-To: [email-masked]

J.D. Falk wrote:
> On 2007-05-05 21:52, John R Levine wrote:
> 
>>> Any idea on what is left to do for it, aside for editing, etc? Where
>>> there any features that need to be added?
>>
>> As far as I know, it's just editing.  I might want to add another 
>> couple of report types for use in spam/not-spam feedback to one's own 
>> ISP, but it's not urgent.

I suggest NOT adding anything for which there is not an already demonstrated 
strong need.  Instead, report types can be a registry, so that other values 
can be added as needed.

> Seems like the part of the story which fits into an RFC has been 
> complete for a while, and any future efforts will revolve around 
> explaining everything else.

I'm inclined to suggest request publishing this as an Informational RFC, to 
avoid the hassles of standardization.  If ARF gains a wide enough base, it's 
easy to revisit this.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 07 May 2007 11:00:30 -0700
From: "J.D. Falk" <[email-masked]>
Organization: Yahoo!
To: [email-masked]
Subject: Re: [taugh.com-johnl] Re: [feedback-report] How's that revised ARF draft coming along?

On 2007-05-05 21:52, John R Levine wrote:

>> Any idea on what is left to do for it, aside for editing, etc? Where
>> there any features that need to be added?
> 
> As far as I know, it's just editing.  I might want to add another couple 
> of report types for use in spam/not-spam feedback to one's own ISP, but 
> it's not urgent.

Seems like the part of the story which fits into an RFC has been 
complete for a while, and any future efforts will revolve around 
explaining everything else.

Anyone on this list who's still interested in the topic and is planning 
on attending MAAWG in June should come to the small working session 
we've got planned, Tuesday afternoon.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Mail

Date: Sun, 6 May 2007 00:52:12 -0400 (EDT)
From: John R Levine <[email-masked]>
To: Yakov Shafranovich <[email-masked]>
Subject: Re: [taugh.com-johnl] Re: [feedback-report] How's that revised ARF draft coming along?
Cleverness: None detected
Cc: [email-masked]

> Any idea on what is left to do for it, aside for editing, etc? Where
> there any features that need to be added?

As far as I know, it's just editing.  I might want to add another couple 
of report types for use in spam/not-spam feedback to one's own ISP, but 
it's not urgent.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

Date: Sun, 06 May 2007 00:40:28 -0400
From: Yakov Shafranovich <[email-masked]>
Organization: SolidMatrix Technologies, Inc.
To: [email-masked]
Subject: Re: [feedback-report] How's that revised ARF draft coming along?

Any idea on what is left to do for it, aside for editing, etc? Where
there any features that need to be added?

Yakov

John R Levine wrote:
> Wasn't someone going to tidy up the 2005 ARF draft and resubmit it, so
> it's alive again and we can possible send it along to be an independent
> RFC?   If nobody else is working on it, I'd be happy to pick it up.
> 
> I have a fair amount of interest from mail certifiers in getting reports
> saying "you said this mail was good, but it wasn't" which would
> naturally be in ARF format.  This doesn't conflict at all with the
> current primary use in direct feedback loops, and it would help if the
> spec didn't appear to be abandoned.
> 

Date: Fri, 4 May 2007 22:56:41 -0400 (EDT)
From: John R Levine <[email-masked]>
To: [email-masked]
Cleverness: None detected
Subject: [feedback-report] How's that revised ARF draft coming along?

Wasn't someone going to tidy up the 2005 ARF draft and resubmit it, so it's 
alive again and we can possible send it along to be an independent RFC?   If 
nobody else is working on it, I'd be happy to pick it up.

I have a fair amount of interest from mail certifiers in getting reports saying 
"you said this mail was good, but it wasn't" which would naturally be in ARF 
format.  This doesn't conflict at all with the current primary use in direct 
feedback loops, and it would help if the spec didn't appear to be abandoned.

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.