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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
ietf@xxxxxxxx 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/
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]