Subject: Re: [feedback-report] draft-shafranovich-feedback-report-06
From: "John R. Levine" <[email-masked]>
To: "J.D. Falk" <[email-masked]>
Cc: [email-masked]
Date: Thu, 29 Jan 2009 21:57:40 +0000 (GMT)
List-Id: Public forum for discussion on the feedback-report draft <abuse-feedback-report.mipassoc.org>

> In theory, end-user tools could use ARF.  In practice, few ISPs or
> certifiers (vouching services) are currently set up to accept ARF reports
> from random users without prior arrangement.

FYI, I've been sending all my abuse reports in ARF format for about a 
year.  I'm surprised how well they're accepted.  Occasionally insists that 
it's impossible or too dangerous to open attachments, or that I didn't 
send all the headers (either because their ticketing system smashed the 
message, or their MUA doesn't show them), but for the most part it works 
amazingly well.

R's,
John

Date: Thu, 29 Jan 2009 12:27:56 -0700
From: "J.D. Falk" <[email-masked]>
To: [email-masked]
Subject: Re: [feedback-report] draft-shafranovich-feedback-report-06

Murray S. Kucherawy wrote:
> On Wed, 28 Jan 2009, SM wrote:
>> Do we really want end-users to start flooding mail systems with ARF? 
>> Some end-user tools already do that.
> 
> Users could, but I think it's more meant for tools at each service 
> provider.  Others' thoughts?

In theory, end-user tools could use ARF.  In practice, few ISPs or 
certifiers (vouching services) are currently set up to accept ARF reports 
from random users without prior arrangement.

This could change, so I wouldn't want to entirely discount the 
possibility...but on the other hand, most of the questions we've seen on 
this list have been from people who assume that the end-user case is the 
primary use case.  So, perhaps some clarification is necessary.

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

Date: Thu, 29 Jan 2009 10:11:26 -0800 (PST)
From: "Murray S. Kucherawy" <[email-masked]>
To: "John R. Levine" <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] draft-shafranovich-feedback-report-06

On Thu, 29 Jan 2009, John R. Levine wrote:
> The example we had in mind is VBR, in which certifiers can say they only
> vouch for, e.g. transactional mail, and senders can assert what kind each
> message is.

Perhaps we should be explicit about that, making at least an informative 
reference to it.

How's its status on the publication track?

Date: Thu, 29 Jan 2009 16:17:49 +0000 (GMT)
From: "John R. Levine" <[email-masked]>
To: SM <[email-masked]>
Cleverness: None detected
Cc: [email-masked]
Subject: Re: [feedback-report] draft-shafranovich-feedback-report-06

>>         To provide a method for recipients to advise providers that
>>         they disagree with the provider's certifications or other
>>         assertions about the message.
>
> How about:
>
>   To provide feedback to third parties affixing assertions about the message.

No, that's not quite it.  Certifier A vouches for mail from domain B, 
which asserts in each message what kind of message it is.  The ARF report 
alerts A that B is lying about what they're sending.

R's,
John

Date: Thu, 29 Jan 2009 07:22:19 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: [feedback-report] draft-shafranovich-feedback-report-06

At 23:16 28-01-2009, Murray S. Kucherawy wrote:
>It could perhaps be worded better, but you can flip it around to get 
>the meaning:
>
>         To provide a method for recipients to advise providers that
>         they disagree with the provider's certifications or other
>         assertions about the message.

How about:

   To provide feedback to third parties affixing assertions about the message.

>It's my understanding that Standards Track is appropriate because 
>the draft contains a specification that is used across 
>administrative boundaries.  Thus, for example, SMTP is standards 
>track, but LMTP doesn't need to be.

In my opinion, the document is appropriate for the Standards 
Track.  The Security Considerations section may require some more 
work.  One of the considerations for a Standards Track document is 
that it requires the consensus of the IETF community.  That shouldn't 
be a problem if this draft is non-controversial.  I suggest narrowing 
down the specifications to the feedback report format and having the 
DKIM extension in a separate document .

At 02:22 29-01-2009, John R. Levine wrote:
>The example we had in mind is VBR, in which certifiers can say they 
>only vouch for, e.g. transactional mail, and senders can assert what 
>kind each message is.

Please see whether the text I suggested covers that example.

Regards,
-sm 

Date: Thu, 29 Jan 2009 10:22:50 +0000 (GMT)
From: "John R. Levine" <[email-masked]>
To: SM <[email-masked]>
Cleverness: None detected
Cc: [email-masked]
Subject: Re: [feedback-report] draft-shafranovich-feedback-report-06

> Do we really want end-users to start flooding mail systems with
> ARF?  Some end-user tools already do that.

Given a choice between random unformatted flames and ARF formatted flames, 
I suspect that most mail systems would prefer the ARF so they can at least 
sort them faster.

> What does the following mean:
>
>   "To advise providers that certify or otherwise make assertions
>    about mail of recipient disagreement with the assertions."

The example we had in mind is VBR, in which certifiers can say they only 
vouch for, e.g. transactional mail, and senders can assert what kind each 
message is.

R's,
John

Date: Wed, 28 Jan 2009 23:16:48 -0800 (PST)
From: "Murray S. Kucherawy" <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [feedback-report] draft-shafranovich-feedback-report-06

On Wed, 28 Jan 2009, SM wrote:
> Do we really want end-users to start flooding mail systems with ARF? 
> Some end-user tools already do that.

Users could, but I think it's more meant for tools at each service 
provider.  Others' thoughts?

> Do we want end-users to use the report format for opting out?

That could work.  Are there any MUA implementations?

> What does the following mean:
>
>   "To advise providers that certify or otherwise make assertions
>    about mail of recipient disagreement with the assertions."

It could perhaps be worded better, but you can flip it around to get the 
meaning:

 	To provide a method for recipients to advise providers that
 	they disagree with the provider's certifications or other
 	assertions about the message.

> The new version of the document has a Standards Track intended
> status.  The proposed specification may be subject to changes on that
> track instead of documenting what is currently in use.

It's my understanding that Standards Track is appropriate because the 
draft contains a specification that is used across administrative 
boundaries.  Thus, for example, SMTP is standards track, but LMTP doesn't 
need to be.

Date: Wed, 28 Jan 2009 21:29:01 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: [feedback-report] draft-shafranovich-feedback-report-06

Hello,

These comments are about draft-shafranovich-feedback-report-06.

The Introduction Section says:

   "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."

Do we really want end-users to start flooding mail systems with 
ARF?  Some end-user tools already do that.

Do we want end-users to use the report format for opting out?

What does the following mean:

   "To advise providers that certify or otherwise make assertions
    about mail of recipient disagreement with the assertions."

The new version of the document has a Standards Track intended 
status.  The proposed specification may be subject to changes on that 
track instead of documenting what is currently in use.

Regards,
-sm

Date: Fri, 2 Jan 2009 16:14:26 -0800 (PST)
From: "Murray S. Kucherawy" <[email-masked]>
To: [email-masked]
Subject: [feedback-report] -06 draft posted

Since -05 had expired, I've posted -06 as it appeared here.

We can post a -07 after the current discussions have resolved, probably 
after the upcoming MAAWG conference.  If it seems stable at that point, I 
can start shopping around for a document shepherd and sponsoring area 
director for its IETF journey.