Subject: [marf] I-D Action: draft-ietf-marf-as-10.txt

From: [email-masked]
Date: Thu, 23 Feb 2012 10:03:58 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF.

	Title           : Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)
	Author(s)       : J.D. Falk
                          M. Kucherawy
	Filename        : draft-ietf-marf-as-10.txt
	Pages           : 15
	Date            : 2012-02-23

   RFC 5965 defines an extensible, machine-readable format intended for
   mail operators to report feedback about received email to other
   parties.  This Applicability Statement describes common methods for
   utilizing this format for reporting both abuse and authentication
   failure events.  Mailbox Providers of any size, mail sending
   entities, and end users can use these methods as a basis to create
   procedures that best suit them.  Some related optional mechanisms are
   also discussed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marf-as-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-as-10.txt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 23 Feb 2012 18:12:50 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, February 23, 2012 10:04 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-marf-as-10.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Messaging Abuse Reporting
> Format Working Group of the IETF.
> 
> 	Title           : Creation and Use of Email Feedback Reports: An
> Applicability Statement for the Abuse Reporting Format (ARF)
> 	Author(s)       : J.D. Falk
>                           M. Kucherawy

This version comes to you from the MAAWG meeting in San Francisco, where John, Barry and I happen to have found some time to sit down and discuss the changes John wants to see.  He's happy with this version and I think it's reasonable to initiate a second Working Group Last Call on this one.  As Barry will be shepherding, I'll let him make that announcement formally.

Early reviews and comments are welcome, of course.  If you'd like to see the changes it contains, see the datatracker and look at the History tab:

http://datatracker.ietf.org/doc/draft-ietf-marf-as/

I think the plan is to have this WGLC complete in time to get it on a telechat before the Paris IETF meeting, so please review and comment sooner rather than later.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 23 Feb 2012 13:33:58 -0500

On Thursday, February 23, 2012 06:12:50 PM Murray S. Kucherawy wrote:
...
> Early reviews and comments are welcome, of course.  
...
Looks good to me.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Thu, 23 Feb 2012 16:31:46 -0500

> I think it's reasonable to initiate a second Working Group Last Call on
this one.
> As Barry will be shepherding, I'll let him make that announcement
formally.

And here it is: please comment on this version ASAP, and in any case no
later than 2 March.  We will consider this version ready to go to the IESG
on that day, unless we hear specific objecions, with specific suggestions
of what should change.

> I think the plan is to have this WGLC complete in time to get it on a
telechat
> before the Paris IETF meeting, so please review and comment sooner rather
> than later.

There's no real chance of it being on a telechat before Paris: the last
telechat is 15 March, so there isn't time to do an IETF last call before
then.  But we can have IETF last call end before Paris, and get on the
first telechat after the meeting.  That's the goal.

Barry, as chair

---

From: Steve Atkins <[email-masked]>
Date: Thu, 23 Feb 2012 13:59:49 -0800

> I think the plan is to have this WGLC complete in time to get it on a telechat before the Paris IETF meeting, so please review and comment sooner rather than later.

Looks fine to me.

Cheers,
  Steve

---

From: Barry Leiba <[email-masked]>
Date: Thu, 23 Feb 2012 17:23:52 -0500

this one.
formally.

telechat

Barry, as chair

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Thu, 23 Feb 2012 22:34:16 -0500

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

>ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-as-10.txt

IMAP -< IMAP4

rpeorts -> reports

-- 
     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: Alessandro Vesely <[email-masked]>
Date: Fri, 24 Feb 2012 19:43:34 +0100

On 23/Feb/12 19:12, Murray S. Kucherawy wrote:
> I think the plan is to have this WGLC complete in time to get it on
> a telechat before the Paris IETF meeting, so please review and
> comment sooner rather than later.

I have four points only:

*Solicited and Unsolicited Reports*

Section 3 may sound misleading, as it may seem to exclude that
unsolicited reports may also be "due to recipients manually reporting
messages as spam."  (The introduction can be understood both ways.)

I propose to replace the first snippet of the second paragraph (Other
uses... how these unsolicited reports) with:

  In case no prior arrangement was made with the origin of a message
  that deserves being reported, it is some times fit to send the
  report just the same.  We refer to these as unsolicited reports.
  Since the context and meaning of the reports cannot be established
  beforehand, the constraints on how these unsolicited reports [...]

(Really, solicited/unsolicited sending is transparent to the user or
any other stream-wise similar input mechanisms.  Is it too late to try
and treat #1 of Section 4.1 and #2 of Section 6.2 in a unified common
section?)

*When To Generate Reports*

The title of Section 6.2 should more appropriately be "When /Not/ To
Generate Reports", except for the last paragraph that matches neither
title.  How about moving #5 to the previous (General Considerations)
subsection?

*Where To Send Reports*

SPF doesn't sign.  In paragraph #4 of Section 6.3, I'd replace:

  Where an abusive message is signed using a domain-level
  authentication technology such as DKIM ([RFC6376]) or SPF
  ([RFC4408]), the domain that has been verified by the

with:

  Where an abusive message is authenticated using a domain-level
  authentication technology such as DKIM ([RFC6376]) or SPF
  ([RFC4408]), the domain that got a "pass" ([RFC5451]) by the

(Is it possible to cite IANA's "Email Authentication Result Names"
rather than, or in addition to, [RFC5451]?)

*What To Do With Reports*

No vacation replies.  In paragraph #4 of Section 6.5, I'd replace:

  a reply might be desirable to indicate that the complaint will
  result in action

with:

  a non-automated reply might be desirable to indicate what action
  resulted from the complaint

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 24 Feb 2012 21:12:21 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Friday, February 24, 2012 10:44 AM
> To: [email-masked]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-as-10.txt

A co-chair's note: At this point I think it's prudent to say we won't make any more changes unless they achieve rough consensus or they are merely minor editorial corrections.

> messages as spam."  (The introduction can be understood both ways.)

Making a backward reference about the cause of the reports from the second paragraph to the first is possibly a simpler change than what you propose, i.e.:

"Other uses for ARF involve such reports sent between parties that don't know each other."

Is that sufficient?

> and treat #1 of Section 4.1 and #2 of Section 6.2 in a unified common

I'm somewhat partial against having a "common" section.  What do others think?

Also, what do others think of the idea of talking about spam traps in Section 4.1?  It doesn't seem to me as though it's advice specific to unsolicited reports, unless that would be something covered in the agreement implicated in a solicited feedback arrangement.

> title.  How about moving #5 to the previous (General Considerations)

I don't agree with the renaming, but I agree with the proposed rearrangement.  Others?

> rather than, or in addition to, [RFC5451]?)

I agree with changing "signed" to "authenticated", but I think the rest goes too far without making the point any more clearly.

>   resulted from the complaint

I agree with that one.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 25 Feb 2012 10:33:34 +0100

On 24/Feb/12 22:12, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
> 
> A co-chair's note: At this point I think it's prudent to say we
> won't make any more changes unless they achieve rough consensus or
> they are merely minor editorial corrections.
> 
> Making a backward reference about the cause of the reports from the
> second paragraph to the first is possibly a simpler change than
> what you propose, i.e.:
> 

Ehm, possibly; my English doesn't support me quite enough.  If "such"
unambiguously refers to the same reports that the first paragraph
alludes to, then it is sufficient.

> I'm somewhat partial against having a "common" section.  What do

This subject is peculiar in that the I-D does not specify it at all.
This consideration can justify a different editorial arrangement.

> Also, what do others think of the idea of talking about spam traps
> in Section 4.1?  It doesn't seem to me as though it's advice
> specific to unsolicited reports, unless that would be something
> covered in the agreement implicated in a solicited feedback
> arrangement.

Viruses is a similar idea, left as a hint.  But hinting twice would
become pushing.

> I don't agree with the renaming, but I agree with the proposed
> rearrangement.

Fine.

>  Others?

...

> I agree with changing "signed" to "authenticated", but I think the
> rest goes too far without making the point any more clearly.

IMHO, it'd be very pertinent to include RFC 5451 among normative
references, because of the pivotal role that it plays in reports
generation of both types.

As for leaving "pass" implied rather than explicit, it is consistent
with presenting targets selection as an heuristic process, so I can
live with it.

>>   resulted from the complaint

Thank you.