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