Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05

From: Alessandro Vesely <[email-masked]>
Date: Wed, 01 Feb 2012 12:15:25 +0100

On 31/Jan/12 22:23, Barry Leiba wrote:
> I am re-posting this without the extra recipients; please reply to
> THIS message, and NOT to that other one.  We can discuss later who,
> exactly, should get the truncheon treatment here.......
> ---
> 
> Here begins a last call for the MARF working group on the subject
> document, detailed below.  Please make any comments you have on this
> version no later than 10 Feb 2012.  That's a week and a half, which
> should be enough for this active and vocal group, wot?  Please do not
> wait until the last minute, and especially do not wait until the
> document goes to the IESG.  You will be beaten with a rubber
> truncheon.

It looks good to me.  The only nit I'd note is in

 9.   Per Section 4.4 of [RFC6449], a network service provider MAY use
      ARF data for automated forwarding of feedabck messages to the
      originating customer.

This is a very important statement, IMHO, as it involves a number of
those "abuse addresses in WHOIS records of the IP" that are mentioned
elsewhere in the document.  I think "network service provider" is
clear enough (rfc6045-bis is changing "network provider" to "service
provider", FWIW.)

The nit is s/feedabck/feedback/, obviously.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 01 Feb 2012 15:14:13 -0500

> document goes to the IESG.  You will be beaten with a rubber

It looks good to me.  Just a couple of comments:

      3.  The Mailbox Provider SHOULD send reports to relevant parties who
       have requested to receive such reports.  The reports MUST be
       formatted per [RFC5965], and transmitted as an email message
       ([RFC5322]), typically using SMTP ([RFC5321]).  The process
       whereby such parties may request the reports is discussed in
       Section 3.5 of [RFC6449].

Although I understad the MUST here in context, it could be misread out of 
context by people trying to insist on ARF.  Could we have some kind of "To 
implement the recommendations of this draft, the reports MUST ..." or similar?

12.  Although [RFC6449] suggests that replying to feedback is not
        useful, in the case of receipt of ARF reports where no feedback
        arrangement has been established, a reply might be desirable to
        indicate that the complaint will result in action, heading off
        more severe filtering from the report generator.  Thus, a report
        generator sending unsolicited reports SHOULD ensure that a reply
        to such a report can be received.  Where an unsolicited report
        results in the establishment of contact with a responsible and
        responsive party, this can be saved for future complaint
        handling and possible establishment of a formal (solicited)
        feedback arrangement.  See Section 3.5 of [RFC6449] for a
        discussion of establishment of feedback arrangements.

The SHOULD seems strong here.  While I agree it's a nice idea, the odds of 
this actually happening are vanishingly small in my opinion.  Something 
without a RFC 2119 keyword would be better here.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Wed, 1 Feb 2012 12:21:31 -0800

> without a RFC 2119 keyword would be better here.

Unsolicited reports sent from an undeliverable address aren't terribly
useful, as you can't ask the sender for additional context (data that's
already there for FBLs). They're also more likely to be discarded or
blocked.

I think the SHOULD is a reasonable level of strength (though I
wouldn't object to MUST).

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Feb 2012 12:27:28 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Wednesday, February 01, 2012 12:14 PM
> To: [email-masked]
> Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05
> 
> Although I understad the MUST here in context, it could be misread out
> of context by people trying to insist on ARF.  Could we have some kind
> of "To implement the recommendations of this draft, the reports MUST
> ..." or similar?

Seems reasonable to me.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 1 Feb 2012 20:29:01 -0000

>implement the recommendations of this draft, the reports MUST ..." or similar?

That's implicit in any standard.  The 2119 language is relative to implementing
what the document is about.

>        to such a report can be received.

>without a RFC 2119 keyword would be better here.

I get dozens of responses to ARF reports every day, many from actual people.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 01 Feb 2012 15:29:36 -0500

>wouldn't object to MUST).

That's a much better rationale.  The draft should leave the SHOULD and add that.

Scott K

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 01 Feb 2012 08:30:26 -0500

In
<CAC4RtVCO=+UfZWY6qXi-fvLPzONcGC5=[email-masked]>,
on 01/31/2012
   at 04:23 PM, Barry Leiba <[email-masked]> said:

>document, detailed below. 

A minor point:

  3.   MUAs SHOULD NOT generate abuse reports directly to entities
       found in the message or by queries to WHOIS or other heuristic
       means.  Rather, the MUA should signal, by some means, the
       mailbox provider to which it connects to generate such a
report.

What about an MUA that prepares an abuse report and requests editing
and submission from the user?

       MUA's that generate abuse reports for manual submission by
       the user SHOULD include guidance on where to submit them
       and a warning about possible forgeries.

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

---

From: "John Levine" <[email-masked]>
Date: 2 Feb 2012 02:16:16 -0000

>       mailbox provider to which it connects to generate such a report.

>and submission from the user?

Look at RFC 2119.  SHOULD NOT more or less means don't do this unless
you're sure you understand what you're doing.  Given how few mail
users understand header parsing and mail routing, SHOULD NOT seems
right to me.

If you, one of the few users familiar with the details of SMTP mail,
want to do it, go ahead.  For the bazillion users of some random
consumer mail system, let their mail system admins handle it.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Feb 2012 19:51:18 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shmuel Metz
> Sent: Wednesday, February 01, 2012 5:30 AM
> To: [email-masked]

Does such a thing exist?  Would it make sense to build one?

I don't want us to go down the road of adding text for every conceivable idea.  We should present basic advice, and stop.

---

From: Steve Atkins <[email-masked]>
Date: Wed, 1 Feb 2012 20:05:36 -0800

On Feb 1, 2012, at 7:51 PM, Murray S. Kucherawy wrote:

> Does such a thing exist?

Kinda, yes. It's not been in much use for years, and long predates ARF, but I still occasionally hear from an abuse desk "Hey! We received a report! Blast from the past!".

>  Would it make sense to build one?

Probably, yes - while on the modern net it would probably make much more sense to centralize most the processing and decision making, having the report be emitted from the MUA wouldn't be a bad decision.

> I don't want us to go down the road of adding text for every conceivable idea.  We should present basic advice, and stop.

I think anyone developing an MUA to do that sort of thing would either deeply understand this document and read it from an appropriate perspective, or not understand it and need to be restrained from doing anything along these lines.

So I think we're fine as we are.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Feb 2012 23:30:49 -0800

> Sent: Wednesday, February 01, 2012 12:30 PM
> To: Message Abuse Report Format working group
> >I think the SHOULD is a reasonable level of strength (though I wouldn't
> >object to MUST).
> 

Done in -06.

I take it you are both otherwise happy with the AS draft as-is?

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 02 Feb 2012 10:10:13 +0100

On 01/Feb/12 21:29, John Levine wrote:
>> Although I understad the MUST here in context, it could be
>> misread out of context by people trying to insist on ARF.  Could
>> we have some kind of "To implement the recommendations of this
>> draft, the reports MUST ..." or similar?
> 
> That's implicit in any standard.  The 2119 language is relative to
> implementing what the document is about.

In addition, the context where that snippet comes from is about a
closed transmission whose details were privately agreed upon by the
participating parties.  That is, not only requiring ARF makes sense,
but also attaching definite semantics to specific fields of it.

The generic recommendation of not insisting on ARF is in bullet 10 of
Section 8:

 10.  Published abuse mailbox addresses SHOULD NOT reject messages not
      in the ARF format, as generation of ARF messages can
      occasionally be unavailable or not applicable.  [...]

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 02 Feb 2012 06:47:45 -0500

"Murray S. Kucherawy" <[email-masked]> wrote:

>wouldn't
>> That's a much better rationale.  The draft should leave the SHOULD
>and
>> add that.
>
>Done in -06.
>

Yes.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 2 Feb 2012 15:37:04 -0000

>I take it you are both otherwise happy with the AS draft as-is?

Oh, I'm sure we'll find other nits to complain about.

As an editorial suggestion, I'd suggest changing the numbered lists in
sections 6-8 back to plain paragraphs since they do not describe
sequences of things to do in order.  The numbers have been handy
during the revision process to identify what we're arguing about,
though.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Thu, 2 Feb 2012 10:32:37 -0800

> I take it you are both otherwise happy with the AS draft as-is?

Not entirely. I think that encouraging people to send unsolicited, non-human-readable
email to email addresses harvested from domain or IP registration addresses,
or to role accounts intended to receive human readable email, isn't a good idea
and we might want to spend more space on the problems with that.

The discussion we have of that now varies between the rather vague, glossing
over the operational impossibilities of actually doing what we're suggesting
people do, through to the oddly specific.

There've been enough minor changes that section 8 is significantly improved
over earlier versions, but it's still rather weak. It seems more a grab bag of unrelated
thoughts than good coverage of why and how and where you should send
unsolicited email in ARF format. Most of those are good thoughts, but they're
rather terse and without the context of why someone provided them I'm not
sure they add up to a coherent narrative.

My preference would be to focus on use of ARF format for solicited reports
in this document, rip out section 8 altogether and concentrate on that issue
more in a separate document that could provide more depth, more focus on
the difficulties with unsolicited reports that this one glosses over, possibly
combined with the work on advertising desire to receive machine-readable
reports. Expanding section 8 into a deeper discussion in this document
might work too. The rest of it looks fine, though, so if that doesn't happen
I'd consider -06 OK.

Cheers,
 Steve

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 02 Feb 2012 19:44:33 +0100

On 01/Feb/12 12:15, Alessandro Vesely wrote:
> It looks good to me[...]

At the risk of being proposed for a treatment, I retract my post and
ask that a new section be added to marf-as, about loop avoidance and
control of flow.

The new section would cover FBL traffic details such as using VERP and
replying 552, which are to be used by all of dkim-reporting,
spf-reporting, and reporting-discovery.  Read more on, e.g.
http://www.ietf.org/mail-archive/web/marf/current/msg01910.html

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Feb 2012 14:13:45 -0500

> and we might want to spend more space on the problems with that.
...
> might work too. The rest of it looks fine, though, so if that doesn't
happen

I'll leave it to Murray to say for sure what input he wants, but I'll note
that at this stage in the document's life cycle, giving the editor specific
text that you propose to be included/changed is probably the most
productive approach.

Barry, border collie

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Feb 2012 11:20:57 -0800

Yes, please.

I don't need a unified diff for something simple like "Remove Section 8", but if that leaves any connecting tissue dangling, I'd like some specific updates to resolve those.

-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Thursday, February 02, 2012 11:14 AM
To: Steve Atkins
Cc: Message Abuse Report Format working group
Subject: Re: [marf] Working Group Last Call on draft-ietf-marf-as-05

...
> might work too. The rest of it looks fine, though, so if that doesn't happen

I'll leave it to Murray to say for sure what input he wants, but I'll note that at this stage in the document's life cycle, giving the editor specific text that you propose to be included/changed is probably the most productive approach.

Barry, border collie

---

From: "John Levine" <[email-masked]>
Date: 2 Feb 2012 20:21:43 -0000

> Not entirely. I think that encouraging people to send unsolicited,
> non-human-readable email to email addresses harvested from domain or
> IP registration addresses, or to role accounts intended to receive
> human readable email, isn't a good idea and we might want to spend
> more space on the problems with that.

On the other hand, I've been sending ARF reports to random abuse
contacts for years, and have found that it works pretty well.
Remember that by design, the first part of an ARF report is free text
for the benefit of humans who might be reading it.

I'd be OK with either "do this at your own risk", or pull it out and
save it for another document.  Telling people not to send ARF reports
to abuse addresses because it won't work flies in the face of
experience.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Feb 2012 12:29:57 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Thursday, February 02, 2012 10:45 AM
> To: [email-masked]
> Subject: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05
> 
> replying 552, which are to be used by all of dkim-reporting, spf-
> reporting, and reporting-discovery.  Read more on, e.g.

I would not be opposed to taking what dkim-reporting says in Section 6 and Sections 8.4 through 8.6 (with parallel text in spf-reporting) and moving them to the AS, and making the AS an informative reference for the two reporting drafts.  That seems to be a sensible common-factoring to do.  Is there any support/objection for doing so?

However, if we also agree that we want to include the "developed relationship" example Alessandro has there, I would like to see some text that presents it but is far more concise.  A detailed, complex (or even contrived) example is more confusing than a couple of simply-presented concepts.

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Thu, 2 Feb 2012 12:35:44 -0800

> for the benefit of humans who might be reading it.

If the report is fully actionable and makes sense to a recipient
who only has access to the text/plain part, that's not a
non-human-readable email, and my concern doesn't apply.

I'm not against using ARF for unsolicited reports, I'm against
sending unsolicited reports that aren't actionable by the recipient.

Anyway, see my suggested edits in 3.. 2.. 1...

Cheers,
  Steve

---

From: Steve Atkins <[email-masked]>
Date: Thu, 2 Feb 2012 12:35:51 -0800

On Feb 2, 2012, at 11:20 AM, Murray S. Kucherawy wrote:

> Yes, please.
>  
> I don’t need a unified diff for something simple like “Remove Section 8”, but if that leaves any connecting tissue dangling, I’d like some specific updates to resolve those.
>  

Yup. Sorry for leaving it until this late (quite possibly too late) in the
process, but it wasn't until I was rereading section 8 for the n-th time
that I spotted the wood through the trees.

Removing section 8:

--- draft-ietf-marf-as-05.txt   2012-01-31 09:28:20.000000000 -0800
+++ new.txt     2012-02-02 11:35:46.000000000 -0800
@@ -143,22 +143,17 @@
    messages as spam.  We refer to these as solicited reports.
 
    Other uses for ARF involve reports sent between parties that don't
-   know each other, with the recipient address typically being
-   abuse@domain (see [RFC2142]), looked up via WHOIS, or using other
-   heuristics.  The reports may be manual, or automated due to hitting
-   spam traps, or caused by anything else that the sender of the report
-   considers to merit an abuse report.  Abuse addresses in WHOIS records
-   of the source IP and of the domain found in the results of a PTR
-   ("reverse lookup") query on that address are likely reasonable
-   candidates for receiving feedback about the message, although
-   automated parsing may be difficult, and such addresses are not
-   guaranteed to be useful.
-
-   However, it is inadvisable to generate automated reports based on
-   inline content analysis tools that apply subjective evaluation rules.
-   This can cause reports that, because of their subjective nature, are
-   not actionable by report receivers, which wastes valuable operator
-   time in processing them.
+   know each other. These unsolicited reports are sent without prior
+   agreement and without prior arrangement between the parties as to
+   the context and meaning of the reports, so the constraints on how
+   these unsolicited reports need to be generated such that they are
+   likely to be useful to the recipient, where they can usefully be
+   sent to, what issues they can be used to report and how they can
+   be handled by the receiver of the report are very different.
+
+   In this document we discuss only solicited reports. Further discussion
+   of unsolicited reports can be found in [reference].
+   

Less drastic suggestion, moving the discussion of unsolicited
reports to it's own section, removing reference to Yahoo, mentioning
that ARF reports can be crafted to be more text/plain friendly, adding
a MUST allow unsubscribes, a few other minor tweaks and a moral
at the end:

--- draft-ietf-marf-as-05.txt	2012-01-31 09:28:20.000000000 -0800
+++ new2.txt	2012-02-02 12:30:01.000000000 -0800
@@ -143,22 +143,15 @@
    messages as spam.  We refer to these as solicited reports.
 
    Other uses for ARF involve reports sent between parties that don't
-   know each other, with the recipient address typically being
-   abuse@domain (see [RFC2142]), looked up via WHOIS, or using other
-   heuristics.  The reports may be manual, or automated due to hitting
-   spam traps, or caused by anything else that the sender of the report
-   considers to merit an abuse report.  Abuse addresses in WHOIS records
-   of the source IP and of the domain found in the results of a PTR
-   ("reverse lookup") query on that address are likely reasonable
-   candidates for receiving feedback about the message, although
-   automated parsing may be difficult, and such addresses are not
-   guaranteed to be useful.
-
-   However, it is inadvisable to generate automated reports based on
-   inline content analysis tools that apply subjective evaluation rules.
-   This can cause reports that, because of their subjective nature, are
-   not actionable by report receivers, which wastes valuable operator
-   time in processing them.
+   know each other. These unsolicited reports are sent without prior
+   agreement and without prior arrangement between the parties as to
+   the context and meaning of the reports, so the constraints on how
+   these unsolicited reports need to be generated such that they are
+   likely to be useful to the recipient, where they can usefully be
+   sent to, what issues they can be used to report and how they can
+   be handled by the receiver of the report are very different.
+
+   

@@ -246,6 +239,8 @@
 
 8.  Generating and Handling Unsolicited Reports
 
+        
+
    1.   Systems that generate unsolicited reports SHOULD ensure that the
         criteria used to decide what messages to report accurately
         identify messages that the reporting entity believes in good
@@ -255,7 +250,11 @@
         failures, and virus reports.  (These applications might be
         described in future IETF documents.)  Systems SHOULD NOT report
         all mail sent from a particular sender merely because some of it
-        is determined to be abusive.
+        is determined to be abusive. Mechanical reports of mail that
+        "looks like" spam, based solely on the results of inline content
+        analysis tools SHOULD NOT be sent as, because of their subjective
+        nature, they are unlikely to provide a basis for the recipient
+        to take action.
    2.   With respect to authentication failures, these could occur for
         legitimate reasons outside of the control of the author.  A
         report generator SHOULD be cautious to generate reports only in
@@ -272,7 +271,21 @@
         SHOULD NOT send reports to the operator of every Autonomous
         System in the path between the apparent originating system and
         the operator generating the report.
-
+   X.   Deciding where to send an unsolicited report will typically
+        rely on heuristics. Abuse addresses in WHOIS records
+        of the source IP and of the domain found in the results of
+        a PTR ("reverse lookup") query on that address are likely
+        reasonable candidates, as is the abuse@domain role address
+        (see [RFC2142]) of related domains. Unsolicited reports
+        SHOULD NOT be sent to email addresses which are not intended
+        to handle abuse reports, including any personal or role address
+        found in WHOIS records or on a web site that isn't either
+        explicitly described as an abuse contact or is of the form
+        abuse@domain.
+        Additionally, a report generator MUST provide a way for
+        a report recipient to request no further reports be sent
+        to them and MAY provide a way for recipients to change
+        the address(es) reports about them are sent to.

@@ -311,19 +324,19 @@
         originating customer.
    10.  Published abuse mailbox addresses SHOULD NOT reject messages not
         in the ARF format, as generation of ARF messages can
-        occasionally be unavailable or not applicable.  Nevertheless,
-        some large messaging service providers specifically request that
-        abuse reports be sent to them in ARF format.  Experience of
+        occasionally be unavailable or not applicable. Experience of
         systems that send abuse reports in ARF format suggests that even
         automated recipient systems that haven't asked for ARF format
         reports handle them at least as well as any other format such as
-        plain text, with or without a copy of the message attached.
+        plain text, with or without a copy of the message attached, if
+        the original report has been generated with use by recipients
+        not using automated ARF parsing in mind.
         This suggests use of ARF is advisable in most contexts.
    11.  This is, however, not universally true.  Anyone sending
         unsolicited reports in ARF format can legitimately presume that
         recipients will not be able to see the ARF metadata (i.e., those
-        elements present in the second part of the report), and instead
-        MAY include all information needed in the human readable (first,
+        elements present in the second part of the report), and MAY 
+        also include all information needed in the human readable (first,
         text/plain) section of the report.  Further, they MAY ensure
         that the report is readable when viewed as plain text, to give
         low-end ticketing systems as much assistance as possible.
@@ -354,7 +367,16 @@
         reporting addresses belonging to the abusive parties themselves.
         Reports SHOULD NOT be sent to such addresses if they can be
         identified beforehand.
-
+   14.  Handling unsolicited reports has a significant cost to the
+        receiver. Senders of unsolicited reports, especially those
+        sending large volumes of them mechanically, need to be aware
+        of that and do all they reasonably can to avoid sending
+        reports that cannot be used as a basis for action by the 
+        recipient - whether that is due to the report being sent
+        about an incident that isn't abuse-related, it being sent to
+        an email address that can't take action on it, or due to the
+        content or format of the report being hard for the recipient
+        to read or use.
 
 9.  IANA Considerations
 
Cheers,
  Steve

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 03 Feb 2012 11:06:38 +0100

My comments on Steve's diffs:

On 02/Feb/12 21:35, Steve Atkins wrote:
> 
> Sorry for leaving it until this late (quite possibly too late)

Still better than never.

> Removing section 8:

That is a step toward banning mail domains below a critical size.  It
has very bigbrotherish implications on the resiliency, privacy, and
even democracy of the mail system.  I'm strongly opposed to that.

> a MUST allow unsubscribes, a few other minor tweaks and a moral

What was the reference to Yahoo?

> +++ new2.txt	2012-02-02 12:30:01.000000000 -0800

I'd add that sending unsolicited messages can be a way of initiating
an FBL.  With respect to RFC 6449, the resulting FBL is more based on
domain authentication (including SPF) and less on IP addresses.  In
particular the IP validation mentioned in Section 3.6.1 of RFC 6449
shall be fully automatic, because changing ISP cannot imply filling
out several thousands of web forms.

Advice that a message was delivered to a junk folder might be useful,
though.  I think we won't get it even if we ask for it, so putting too
much emphasis on this point is worthless.  However, perhaps it has to
be said that rejected messages must not be reported.

Very much agreed!  I suggest X be near 5 (abuse@authenticated-domain.)

> +        the address(es) reports about them are sent to.

This latter part should go to a different paragraph.  Perhaps near 12
(replying to feedback).  Replies may be mail- or web-based.

> -        occasionally be unavailable or not applicable.

Paragraph 10, for receivers, should terminate here.

>          Nevertheless,

The rest of paragraph 10 and paragraph 11 (for senders) are confusing
and need additional rewording, IMHO.

>          [snip]

Non-actionable reports could still be useful for collecting
statistics, whose evaluation may eventually result in a better
sending.  This is especially true for spf- or dkim-reporting.

Should we say that the 3rd mime part of non-actionable reports should
be "text/rfc822-headers"?

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Thu, 02 Feb 2012 06:11:58 -0500

In
<[email-masked]>,
on 02/01/2012

>Does such a thing exist?

Don't know.

>Would it make sense to build one?

Generating MARF reports from the MUA Is the natural response to a
large provider that won't accept abuse reports in plain text. IMHO it
would be prudent to provide advice on how such a tool would operate.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Thu, 02 Feb 2012 06:18:04 -0500

In <[email-masked]>, on 02/02/2012

>users understand header parsing and mail routing, SHOULD NOT seems

One would hope that the author of such a tool would understand header
parsing and mail routing. Of course, correct operation would still
require that the user be able to count.

>consumer mail system, let their mail system admins handle it.

Who's going to bell the cat? Currently, a lot of e-mail admins don't
provide the function of collecting abuse complaints and forwarding
them to the proper recipients.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Thu, 02 Feb 2012 06:25:59 -0500

In <[email-masked]>, on
02/01/2012
   at 08:05 PM, Steve Atkins <[email-masked]> said:

>Probably, yes - while on the modern net it would probably make much
>more sense to centralize most the processing and decision making,

I agree, but in the short run there will continue to be providers that
don't provide that function.

>I think anyone developing an MUA to do that sort of thing would
>either deeply understand this document and read it from an
>appropriate perspective, or not understand it and need to be
>restrained from doing anything along these lines.

The refusal of, e.g., yahoo, to accept plain text complaints provides
an incentive for MUA authors to write such tools. Given the number of
e-mail clients that are broken in one way or another, I'd rather see
some guidance in an RFC before the avalanche starts. Restraining the
MUA authors is not feasible.

---

From: "John Levine" <[email-masked]>
Date: 3 Feb 2012 16:16:32 -0000

>them to the proper recipients.

Not the IETF.  Despite a lot of wishful thinking, no standard can
force anyone to do anything they're not already inclined to do.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 3 Feb 2012 16:16:32 -0000

R's,
John

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Fri, 03 Feb 2012 11:53:13 -0500

In <[email-masked]>, on
02/02/2012

>sending unsolicited reports that aren't actionable by the recipient.

I'd suggest changing MAY to SHOULD in item 11 of 8.  Generating and
Handling Unsolicited Reports.

   11.  This is, however, not universally true.  Anyone sending
        unsolicited reports in ARF format can legitimately presume
        that some recipients will not be able to see the ARF
        metadata (e.g., those elements present in the second part of
        the report), and instead SHOULD include all information
        needed in the human readable (first, text/plain) section of
        the report.  Further, they MAY ensure that the report is
        readable when viewed as plain text, to give low-end
        ticketing systems as much assistance as possible.  Finally,
        they need to be aware that the report could be discarded or
        ignored due to failure to take these steps in the
        most extreme cases.

I fixed a couple of nits in the above; adding "some" and changing an
inappropriate "i.e." to "e.g.". I'm not sure whether the second MAY
should also be SHOULD.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Feb 2012 21:01:03 -0800

> Sent: Friday, February 03, 2012 8:53 AM
> To: [email-masked]
> >I'm not against using ARF for unsolicited reports, I'm against sending
> >unsolicited reports that aren't actionable by the recipient.
> 

Agree with the "some".

I think if you're going to change the first MAY to SHOULD, changing the second also makes sense.  I agree with it, since interoperability is the goal, so I've made the change, but of course consensus could disagree.

"i.e." is correct rather than "e.g."; "i.e." means "that is", which is more appropriate here than "e.g." which means "for example".  What's in parentheses there is precise, not an example.

Thanks,
-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Feb 2012 21:39:03 -0800

> Sent: Friday, February 03, 2012 2:07 AM
> To: [email-masked]
> > Less drastic suggestion, moving the discussion of unsolicited reports
> > to it's own section, removing reference to Yahoo, mentioning that ARF
> > reports can be crafted to be more text/plain friendly, adding a MUST
> > allow unsubscribes, a few other minor tweaks and a moral at the end:
> 

The stuff about a large service provider insisting that all abuse reports be ARF-formatted is a reference to Yahoo.

> I'd add that sending unsolicited messages can be a way of initiating an
> FBL.

We already do say that later in the same section.

> be said that rejected messages must not be reported.

I disagree, because that presumes a lot about what exactly "rejected" means.  I think we're fine with the current text.

> (replying to feedback).  Replies may be mail- or web-based.

It's enough to say "a way", I think.  The method is unspecified, and that's fine.

> Paragraph 10, for receivers, should terminate here.

Do you think the rest of what's there now is incorrect?

> and need additional rewording, IMHO.

Please provide substitute text.

> Non-actionable reports could still be useful for collecting statistics,
> whose evaluation may eventually result in a better sending.  This is
> especially true for spf- or dkim-reporting.

I think this fits under "take action on it".

> be "text/rfc822-headers"?

Why?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Feb 2012 21:40:13 -0800

> From: John Levine [mailto:[email-masked]]
> Sent: Thursday, February 02, 2012 7:37 AM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> sequences of things to do in order.  The numbers have been handy during
> the revision process to identify what we're arguing about, though.

Seems reasonable; I'll leave them in until IETF LC ends, in case we need to use them for the same reason.

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Sat, 4 Feb 2012 21:51:41 -0800

> I think this fits under "take action on it".

I don't think so. If the report is not about an abusive behaviour
on which the recipient of the report can take action, it's not something
that should be sent unsolicited.

If the recipient wants that sort of thing, they can ask for it. (And if
they've not asked for it then the non-actionable reports you're
sending are just ARF-formatted spam).

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Feb 2012 21:54:50 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Atkins
> Sent: Thursday, February 02, 2012 12:36 PM

Thanks, Steve.  I've included much of what you've said in this part with some minor copy editing for the new version.  I think it largely cleans up the presentation and says things a little better than how we had them.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Feb 2012 22:01:46 -0800

> Sent: Saturday, February 04, 2012 9:52 PM
> I don't think so. If the report is not about an abusive behaviour on
> which the recipient of the report can take action, it's not something
> they've not asked for it then the non-actionable reports you're sending
> are just ARF-formatted spam).

I think we're agreeing, really.  What I'm trying to avoid is having the AS turn into a cookbook of 101 Things You Could Do With ARF Reports Maybe.  I think we should present the most common use cases based on experience, and leave it at that, without going into navel-gazing about all sorts of neat ways they might be useful someday.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Feb 2012 22:07:19 -0800

> Sent: Thursday, February 02, 2012 3:26 AM
> To: [email-masked]
> >I think anyone developing an MUA to do that sort of thing would either
> >deeply understand this document and read it from an appropriate
> >perspective, or not understand it and need to be restrained from doing
> >anything along these lines.
> 

What do others think about this point?  Given the number of direct complaints John, Yakov and I got from Yahoo members when Yahoo decided to accept only ARF reports, it seems like we might be able to say we have experience that this creates a big problem for a lot of people.  And it's true that software to generate ARFs will start appearing, if it hasn't already.

That said, I don't think we need to talk specifically about MUAs sending abuse reports.  It seems to me any advice we have for them is the same as the advice we're already giving to report generators.  Why would it be any different?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 05 Feb 2012 01:10:53 -0500

On Saturday, February 04, 2012 10:07:19 PM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Shmuel Metz Sent: Thursday, February 02, 2012 3:26 AM
> > To: [email-masked]
> What do others think about this point?  Given the number of direct
> complaints John, Yakov and I got from Yahoo members when Yahoo decided to
> accept only ARF reports, it seems like we might be able to say we have
> experience that this creates a big problem for a lot of people.  And it's
> true that software to generate ARFs will start appearing, if it hasn't
> already.
> 
> That said, I don't think we need to talk specifically about MUAs sending
> abuse reports.  It seems to me any advice we have for them is the same as
> the advice we're already giving to report generators.  Why would it be any
> different?

I don't think it would be different.

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Sat, 4 Feb 2012 22:13:47 -0800

> I think we're agreeing, really.  What I'm trying to avoid is having the AS turn into a cookbook of 101 Things You Could Do With ARF Reports Maybe.  I think we should present the most common use cas…

+1 for the ARF format in general, sure.

For unsolicited reports there's something stronger - If the report is about something that's not actionable by an abuse desk, it shouldn't be sent unsolicited.

"evaluation may eventually result in a better sending." is a deliverability issue, not an abuse issue. Interesting to some people, sure, but something delivery@ should opt-in to not something abuse@everywhere should have to opt-out of.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Feb 2012 22:25:51 -0800

> http://www.ietf.org/mail-archive/web/marf/current/msg01910.html

I support the idea of common-factoring what's in draft-ietf-marf-dkim-reporting-08, Section 6 and Sections 8.4 through 8.6, and parallel text in draft-ietf-marf-spf-reporting, or very similar text, into the AS.  The AS is supposed to be a statement of "this is how we suggest you use ARF" and those strike me as reasonable things to include in such a document even without the reporting drafts.  Do others agree?

If people don't like that idea, then I would instead suggest at least removing them from one of the two -reporting drafts and having that one reference the other one.  I'm not too keen on the exact same text appearing in two documents if we can avoid it.  Again, do others agree?

I don't (currently) agree that the rest of the suggestions at that URL particularly benefit either of the documents.  Others should chime in on this point as well.

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Sat, 4 Feb 2012 22:54:24 -0800

> I support the idea of common-factoring what's in draft-ietf-marf-dkim-reporting-08, Section 6 and Sections 8.4 through 8.6, and parallel text in draft-ietf-marf-spf-reporting, or very similar text,…

Is the thought to add them to the AS document as a section on how to craft and send an ARF message that's being used for SPF or DKIM failure feedback? Or as something that's more generally applicable to all ARF usage? Or something in-between - FBL best practices, say?

(Also, if we're going to do that, should we reference 3834 - Auto-Submitted and all that - as well / instead?)

It does seem to make more sense to have them both referencing a base "reporting auth failures" document that covers the common requirements rather than referencing each other, whether that base doc is draft-ietf-marf-as or not.

Yes.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Feb 2012 23:27:25 -0800

> Sent: Saturday, February 04, 2012 10:54 PM
> Subject: Re: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05
> 
> Is the thought to add them to the AS document as a section on how to
> craft and send an ARF message that's being used for SPF or DKIM failure
> feedback? Or as something that's more generally applicable to all ARF
> usage? Or something in-between - FBL best practices, say?
> 
> (Also, if we're going to do that, should we reference 3834 - Auto-
> Submitted and all that - as well / instead?)
> 
> It does seem to make more sense to have them both referencing a base
> "reporting auth failures" document that covers the common requirements
> rather than referencing each other, whether that base doc is draft-
> ietf-marf-as or not.

It seems to me what's in Section 6 is good advice for any ARF generation case.

What's in DKIM reporting's 8.4-8.6 would go under a section that talks about any kind of automated reporting, with authentication failure reporting as the prime example.  The two reporting drafts would then reference the AS instead of including those sections themselves, and the AS could reference them as use cases.  That would turn them into a document cluster, but that's not a big deal; it just means they are published simultaneously with sequential RFC numbers.

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Sun, 5 Feb 2012 00:06:50 -0800

> It seems to me what's in Section 6 is good advice for any ARF generation case.

6.3 isn't bad advice, but the justification of some of it is rather specific to authentication failure reporting. Do we want to mandate that anyone sending ARF reports of any sort MUST also publish SPF records or send them with a NULL envelope sender? That requirement isn't unreasonable in the case where you're talking about reports sent in response to an authentication failure, where avoiding an authentication failure in response to a report of authentication failure is a reasonably belt-and-braces way to help avoid a mail loop - but beyond that narrow scope it seems a bit of a reach. There are people who consider SPF irrecoverably broken, yet still offer feedback loops.

> What's in DKIM reporting's 8.4-8.6 would go under a section that talks about any kind of automated reporting, with authentication failure reporting as the prime example.  

Some of it is specific to authentication failure reporting. As for the rest of it, are they security concerns that should be discussed in marf-as regardless of whether the DKIM/SPF docs want to reference them? I'm thinking yes.

And (I'm going to regret asking this, I'm sure) where does draft-ietf-marf-authfailure come into this? It has much the same security statements and is already referenced by the SPF and DKIM failure drafts, I think.

> The two reporting drafts would then reference the AS instead of including those sections themselves, and the AS could reference them as use cases.  That would turn them into a document cluster, but that's not a big deal; it just means they are published simultaneously with sequential RFC numbers.

Cheers,
  Steve

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 05 Feb 2012 13:40:09 +0100

On 05/Feb/12 06:39, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>
>>> @@ -311,19 +324,19 @@
>>>

It is not incorrect, it is in the wrong paragraph.  Indeed, paragraph
11 starts with "This is" as a want to be a continuation of #10.

> Please provide substitute text.

  Experience suggests use of ARF is advisable in most contexts.
  Automated recipient systems can handle abuse reports sent in ARF
  format at least as well as any other format such as plain text,
  with or without a copy of the message attached. That holds even for
  systems that didn't ask for ARF format reports, provided that
  reports are generated with use by recipients not using automated
  ARF parsing in mind. Anyone sending unsolicited reports in ARF
  format can legitimately presume that recipients will only be able
  to access the human readable (first, text/plain) part of it, and
  MAY include all information needed also in this part. Further, they
  MAY ensure that the report is readable when viewed as plain text,
  to give low-end ticketing systems as much assistance as possible.

> I think this fits under "take action on it".

Yes, in a slightly indirect sense.

BTW, publishing a _report address /is/ opt-in, isn't it?

>> be "text/rfc822-headers"?

To be more lightweight.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 5 Feb 2012 10:26:35 -0500

> to use them for the same reason.

If we inten to remove them, I suggest adding a note before each that says
something like this:

[These numbered items are not intended to be in a paricular sequence.  The
numbers are here during document development to make it easier to idenify
the items for discussion, and will be removed before publication.]

Barry

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 05 Feb 2012 10:30:33 -0500

"Murray S. Kucherawy <[email-masked]> wrote:

>I support the idea of common-factoring what's in
>draft-ietf-marf-dkim-reporting-08, Section 6 and Sections 8.4 through
>8.6, and parallel text in draft-ietf-marf-spf-reporting, or very
>similar text, into the AS.  The AS is supposed to be a statement of
>"this is how we suggest you use ARF" and those strike me as reasonable
>things to include in such a document even without the reporting drafts.
> Do others agree?
>
>If people don't like that idea, then I would instead suggest at least
>removing them from one of the two -reporting drafts and having that one
>reference the other one.  I'm not too keen on the exact same text
>appearing in two documents if we can avoid it.  Again, do others agree?
>
>I don't (currently) agree that the rest of the suggestions at that URL
>particularly benefit either of the documents.  Others should chime in
>on this point as well.

I think the auth failure draft would have been the one to factor it into. Adding the AS draft into the mix of the various auth failure drafts will confuse things. 

The auth failure and AS use cases are orthogonal in some respects. They overlap, but are definitely different.

Scott K

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sun, 05 Feb 2012 08:29:23 -0500

In
<[email-masked]>,
on 02/04/2012
   at 10:07 PM, "Murray S. Kucherawy" <[email-masked]> said:

>complaints John, Yakov and I got from Yahoo members when Yahoo
>decided to accept only ARF reports, it seems like we might be able to
>say we have experience that this creates a big problem for a lot of
>people.

"The avalanche has already started; it is too late for the pebbles to
vote." I agree that the exerience is already here and that we should
take note of it.

>And it's true that software to generate ARFs will start appearing,
>if it hasn't already.

It's on my todo list[1], and I'd be astonished if there weren't many
others.

[1] Currently hung up on some dependency issues and also waiting
    for discovery to firm up.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sun, 05 Feb 2012 08:22:15 -0500

In
<[email-masked]>,
on 02/04/2012
   at 09:01 PM, "Murray S. Kucherawy" <[email-masked]> said:

>What's in parentheses there is precise, not an example.

Yes, on re-reading it I see that.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sun, 05 Feb 2012 08:33:44 -0500

In
<[email-masked]>,
on 02/04/2012
   at 10:25 PM, "Murray S. Kucherawy" <[email-masked]> said:

>I support the idea of common-factoring

Yes; I don't see much likelyhood that they will diverge.

>If people don't like that idea, then I would instead suggest at
>least removing them from one of the two -reporting drafts and having
>that one reference the other one. 

I don't like that. If the text is moved to a single document, it
should not be one specific to DKIM or SPF. AS is a better place to
park it.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 5 Feb 2012 12:09:05 -0500

> should not be one specific to DKIM or SPF. AS is a better place to

I agree, as participant and as document shepherd.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Sun, 5 Feb 2012 12:13:21 -0500

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 05 Feb 2012 13:20:04 -0500

>I agree, as participant and as document shepherd.

Why the AS draft? There are tons of non-spam auth failures. These are often the most interesting ones.

If this belongs in the AS draft then it's probably misnamed.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 5 Feb 2012 18:36:27 -0000

>What do others think about this point?  Given the number of direct complaints John, Yakov and I got
>from Yahoo members when Yahoo decided to accept only ARF reports, it seems like we might be able to
>say we have experience that this creates a big problem for a lot of people.  And it's true that
>software to generate ARFs will start appearing, if it hasn't already.

I think I've gotten maybe a dozen complaints from people whose abuse
reports were rejected by Yahoo.  Considering how much mail Yahoo
sends, that rounds to zero.  Of those dozen complaints, it's not clear
to me how many of them would have been actionable of Yahoo did accept
them, since I didn't get the impression that people understood sending
the headers, recognizing obvious forgeries, and the like.  It may seem
rude to say this, but if you can't figure out how to send an ARF
report, you probably weren't sending actionable reports in the first
place.  Most useful reports come from other mail systems, triggered by
users pushing the spam button.

I also can't have much sympathy for the argument that there is a
desperate need for a standard to desribe a way for users of random
MUAs to force complaints into Yahoo.  How long have they been ARF
only, at least a year?  How many MUA ARF generators are there?  None
that I'm aware of.  (I can run the script I use to send all my abuse
reports from Alpine on my FreeBSD laptop, but I wouldn't wish it on
anyone else.  And even there, the vast majority of my reports are sent
from the server side.)  That's not even a descending snowflake, much
less an avalanche.

If you want to write a plugin or script to send ARF reports from your
MUA, go ahead.  You don't need our permission.  But it's not something
that's going to be used by even 0.01% of mail users, so it's not worth
addressing in a standards document.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Sun, 5 Feb 2012 14:31:14 -0500

> If this belongs in the AS draft then it's probably misnamed.

I'm confused by both of the last two sentences... I don't see the
antecedents to "these", "this", and "it's".
As to "Why the AS [document]?", It's because that document is an
"applicability statement" for the work being done with MARF.  An AS is a
standards-track document that describes how to use the underlying protocols
(as opposed to a TS (technical specification), which defines the
protocol(s)).  Part of using the protocols involves dealing with feedback
loops, reporting, failures, ans so on.

We decided to split certain details off into separate documents, for
various reasons, but it all fits into the "applicability statement" box,
and it makes sense to put the common bits into the AS document.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 5 Feb 2012 20:10:47 -0800

> Sent: Sunday, February 05, 2012 12:07 AM
> 6.3 isn't bad advice, but the justification of some of it is rather
> specific to authentication failure reporting. Do we want to mandate
> that anyone sending ARF reports of any sort MUST also publish SPF
> records or send them with a NULL envelope sender? That requirement
> isn't unreasonable in the case where you're talking about reports sent
> in response to an authentication failure, where avoiding an
> authentication failure in response to a report of authentication
> failure is a reasonably belt-and-braces way to help avoid a mail loop -
> but beyond that narrow scope it seems a bit of a reach. There are
> people who consider SPF irrecoverably broken, yet still offer feedback
> loops.

Perhaps a compromise then: If we agree to move Section 6 to the AS, mention that the advice of 6.3 is specific to authentication failure reports.

> Some of it is specific to authentication failure reporting. As for the
> rest of it, are they security concerns that should be discussed in
> marf-as regardless of whether the DKIM/SPF docs want to reference them?
> I'm thinking yes.

Probably.

> And (I'm going to regret asking this, I'm sure) where does draft-ietf-
> marf-authfailure come into this? It has much the same security
> statements and is already referenced by the SPF and DKIM failure
> drafts, I think.

That's true, and probably as a result of the fact that authfailure-report was the "master" from which these others were created at some point.

If we're happy with what authfailure-report says, these sections could actually be dropped since the two reporting documents already normatively reference that one.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 5 Feb 2012 20:14:27 -0800

Good idea, works for me; added in the working copy.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Sunday, February 05, 2012 7:27 AM
To: Murray S. Kucherawy
Cc: [email-masked]
Subject: Re: Working Group Last Call on draft-ietf-marf-as-05

> to use them for the same reason.

If we inten to remove them, I suggest adding a note before each that says something like this:

[These numbered items are not intended to be in a paricular sequence.  The numbers are here during document development to make it easier to idenify the items for discussion, and will be removed before publication.]

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 5 Feb 2012 20:23:44 -0800

> Sent: Sunday, February 05, 2012 4:40 AM
> To: [email-masked]

So you're suggesting that the remainder of 10 be merged into 11?  That seems to make sense.

>   to give low-end ticketing systems as much assistance as possible.

Thanks, that works (with the warning about what might happen if you don't comply included from the previous version).

> BTW, publishing a _report address /is/ opt-in, isn't it?

That's a "reporting-discovery" thing, which I think we've essentially dropped now.

> >> be "text/rfc822-headers"?

I think we need to discuss it further if we want to use the word SHOULD.  As it is, either message/rfc822 and text/rfc822-headers is acceptable and the report generator can choose to use either.  I don't think we need to say anything normative about that.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Feb 2012 06:57:13 -0500

> antecedents to "these", "this", and "it's".

These are auth failure arfs.  This is the text from the DKIM and SPF drafts 
being proposed be consolidated into the AS draft and it's is the AS draft.

> and it makes sense to put the common bits into the AS document.

For auth failure reports we (tried to anyway) put the common bits needed to 
extend arf to send messages about authentication failures in draft-ietf-marf-
authfailure-report.  If there is further factoring to be done from the DKIM 
and SPF drafts, that's where it seems to be sensible to put it (I know that's 
procedurally complex at this point).

I don't think what's being discussed fits a draft about anti-spam.  Anti-spam 
and auth failure are different concepts.  In many cases the most interesting 
(to the sender) cases are the ones where legitimate messages failed 
authentication.  There are also interesting authentication failure cases where 
the message is spam, but it's certainly not limited to that.

It would seem odd to me to have to go read an RFC about anti-spam in order to 
implement authentication failure reporting, so if what's in the anti-spam 
draft is really necessary to authentication failure reporting, then I suspect 
it is misnamed.

That's a longer (and hopefully clearer) version of what I was trying to 
communicate yesterday.

Scott K

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Mon, 06 Feb 2012 08:37:20 -0500

In <[email-masked]>, on 02/05/2012
   at 06:36 PM, "John Levine" <[email-masked]> said:

>MUAs to force complaints into Yahoo.

Accepting abuse complaints is part and parcel of, e.g., sending
e-mail. I don't see how you can legitimately describe sending such
complaints as forcing them on yahoo.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Mon, 06 Feb 2012 09:13:01 -0500

In

>Agree with the "some".

I notice "some" that it isn't in draft-ietf-marf-as-06.txt; is that
deliberate or inadvertent?

   13.  Experience suggests use of ARF is advisable in most contexts.
        Automated recipient systems can handle abuse reports sent in
ARF
        format at least as well as any other format such as plain
text,
        with or without a copy of the message attached.  That holds
even
        for systems that did not request ARF format reports, provided
        that reports are generated with use by recipients not using
        automated ARF parsing in mind.  Anyone sending unsolicited
        reports in ARF format can legitimately presume that recipients

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 6 Feb 2012 10:07:06 -0800

> Sent: Monday, February 06, 2012 6:13 AM
> To: [email-masked]

The paragraph was overhauled by the submission of some text from Alessandro.  Where would you like to see "some" inserted in this version?

-MSK

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Mon, 06 Feb 2012 18:34:46 -0500

In
<[email-masked]>,
on 02/06/2012
   at 10:07 AM, "Murray S. Kucherawy" <[email-masked]> said:

>The paragraph was overhauled by the submission of some text from
>Alessandro.  Where would you like to see "some" inserted in this
>version?

   13.  Experience suggests ... can legitimately presume that some
recipients ...

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 Feb 2012 09:26:16 -0800

> Sent: Monday, February 06, 2012 3:35 PM
> To: [email-masked]

Done.