Subject: Re: [marf] Last Call: <draft-ietf-marf-spf-reporting-08.txt> (SPF Authentication Failure Reporting using the Abuse Report Format) to Proposed Standard

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Mar 2012 19:14:20 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Wednesday, February 29, 2012 10:27 PM
> To: [email-masked]
> Subject: Re: Last Call: <draft-ietf-marf-spf-reporting-08.txt> (SPF
> Authentication Failure Reporting using the Abuse Report Format) to
> Proposed Standard

As for your non-procedural concerns:

> I'll avoid commenting on the technical angle.  Here are some editorial
> comments:
> 
> In Section 3:
> 
>    "There exist cases in which a domain name owner employing [SPF] for
>     announcing sending practices may want to know when messages are
>     received via unauthorized routing."
> 
> I suggest not using the term "domain name owner" to side-step the
> question of domain "ownership".

Would "ADMD" and an informative reference to RFC5598 be more appropriate?

>    "particular because a message arrived via an unauthorized route.
>     To generate a complete address to which the report is sent, the
>     verifier simply appends to this value an "@" followed by the
>     SPF domain per paragraph 4.1 of [SPF]."
> 
> RFC 4408 uses the term "SPF-compliant domain".

That's fine with us.

> In Section 5.1:
> 
>    "New registrations or updates MUST be published in accordance with the
>     "Specification Required" guidelines as described in
>     [IANA-CONSIDERATIONS].  New registrations and updates MUST contain
>     the following information:"
> 
> I suggest not using RFC 2119 key words in the IANA Considerations
> section unless there are interoperability issues with IANA.

We'll change "MUST" to "are to be".

>    "current:  The field is in current use
> 
>     deprecated:  The field is in current use but its use is
>        discouraged"
> 
> The difference in "current use" can end up being problematic for the
> designated expert.

A number of registries are using this wording already and there's been no objection to date.  Do you have a better suggestion?

> In Section 6:
> 
>   "Security issues with respect to these reports are similar to those
>    found in [DSN]."
> 
> The reference to DSN could be normative.

Security Considerations are never normative, so I'm not sure I agree that this should be.

>    "The HELO/EHLO command SHOULD also be selected so that it
>     will pass [SPF] HELO checks."
> 
> I could not understand what to do about the above recommendation.
> FWIW, the command is specified in RFC 5321.  That specification is not
> referenced by this draft.

Yes, that needs to be clarified, the reference added, and the typo in the section title needs correction.

Thanks,
-MSK

---

From: Barry Leiba <[email-masked]>
Date: Thu, 1 Mar 2012 16:01:20 -0500

> A number of registries are using this wording already and there's been no
> objection to date.  Do you have a better suggestion?

I suggest, "The field might still be in use, but its use is discouraged."

> Security Considerations are never normative, so I'm not sure I agree that this should be.

It should.  Just because the Security Considerations section doesn't
usually use normative language doesn't mean that it's not normative.
People reading the document and implementing the protocol certainly
have to read and understand the Security Considerations section, along
with any transitive sections in other documents.

Barry, MARF co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 03 Mar 2012 00:15:34 -0500

On Wednesday, February 29, 2012 04:46:43 PM The IESG wrote:
> The IESG has received a request from the Messaging Abuse Reporting Format
> WG (marf) to consider the following document:
> - 'SPF Authentication Failure Reporting using the Abuse Report Format'
>   <draft-ietf-marf-spf-reporting-08.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2012-03-14. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
...

For those keeping track, here's a diff based on last call comments so far.

Scott K