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

From: SM <[email-masked]>
Date: Wed, 29 Feb 2012 22:26:41 -0800

At 16:46 29-02-2012, 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

[snip]

>Note that this document has a downward normative reference: This 
>document makes a normative reference to SPF (RFC4408), which is Experimental.

The MARF charter [1] does not contain any mention of "SPF 
Authentication Failure Reporting using the Abuse Report Format" as a 
deliverable.  There is no mention of SPF in the charter.

According to the Abstract Section of this document:

   "This memo presents extensions to the Abuse Reporting Format (ARF),
    and Sender Policy Framework (SPF) specifications to allow for
    detailed reporting of message authentication failures in an on-demand
    fashion."

This extends a specification on which there hasn't been any 
conclusion yet.  I note that there is a downward normative reference 
to RFC 4408.  During discussions about RFC 4408, on which I don't 
have any opinion up to now, there have been comments about:

  (i)   The specification not being sufficiently clear.

  (ii)  A compelling case that there is, indeed, an error in RFC4408.

  (iii) Interoperability problems in the protocol due to DNS "incompatibility".

I suggest that the IETF waits for a migration or co-existence 
document which discusses about the non-standards track protocol on 
which there is a downward reference.

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

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

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.

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

In Section 6:

  "Security issues with respect to these reports are similar to those
   found in [DSN]."

The reference to DSN could be normative.

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

Regards,
-sm

1. https://datatracker.ietf.org/wg/marf/charter/