Authentication Failure Reporting Using the Abuse Reporting Format
Note: This ballot was opened for revision 10 and is now closed.
(Pete Resnick) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
Comment (2012-01-02 for -)
I have no objection to the publicaiton of this document as an RFC, but here are a few trivial nits. --- Please expand "AF" on first use in the Abstract, and show it as the abbreviation of "Abuse Report Format" on first use in the Introduction. --- Section 3.1 Delivery-Result: As specified in Section 3.2.2. This field is OPTIONAL, but MUST NOT appear more than once. If present, it SHOULD indicate the outcome of the message in some meaningful way, but might be redacted to "other" for local policy reasons. s/might/MAY/ --- Section 3.2.2 Please expand ADMD --- Section 3.2.3 Please expand DKIM --- Section 3.2.5 Please expand ADSP --- Section 3.2.6 Please expand SPF
(Stephen Farrell) No Objection
Comment (2012-01-16 for -)
- Section 2.4 (esp the title) is a bit odd, I'm sure its there for a reason but its not at all clear to this reader. (But I don't mind) - 3.1 - who's SOURCE-IP is meant here? Might be clear from ARP but not so clear from here - same for REPORTED-DOMAIN. Better to be crystal clear really. - 3.2.1 - the "policy" value is a bit vague, but that's ok I guess. - I'm not 100% clear about the rule for handling DKIM and redaction. Is it that the sender just chooses whether to send the unredacted possibly-DKIM-valid value or the redacted version with no DKIM info, or are you just supposed to never (as in MUST NOT) send a redacted message if the message had DKIM header fields? That might be there but I missed it if so.
(David Harrington) No Objection
(Russ Housley) (was Discuss) No Objection
(Dan Romascanu) No Objection
(Peter Saint-Andre) No Objection
Comment (2012-01-17 for -)
Section 2.3 states: base64 is defined in [MIME]. Well, base64 is also defined in RFC 4648. :) Perhaps it would be better to say: This specification mandates use of base64 as defined in [MIME]. Section 3.1 states: Delivery-Result: As specified in Section 3.2.2. This field is OPTIONAL, but MUST NOT appear more than once. If present, it SHOULD indicate the outcome of the message in some meaningful way, but MAY be redacted to "other" for local policy reasons. I think "redacted" is not right here (causes confusion with the redaction I-D). I suggest "set". Section 3.1 also states: For privacy reasons, report generators might need to redact portions of a reported message such as the end user whose complaint action resulted in the report. A discussion of relevant issues and a suggested method for doing so can be found in [I-D.IETF-MARF-REDACTION]. I don't think you can redact an end user. :) I suggest "an identifier or address associated with the end user..." Section 6.2 states: "These reports may be forged" and "DKIM failure reports may produce reports". I suggest changing "may" to "can" and "might", respectively. Section 6.3 states: Limiting the rate of generation of these messages may be appropriate but threatens to inhibit the distribution of important and possibly time-sensitive information. Do you mean "MAY"? Section 6.5 states: The use of this for "near-identical" incidents in particular causes a degradation in reporting quality, however. If for example a large number of pieces of spam arrive from one attacker, a reporting agent may decide only to send a report about a fraction of those messages. While this averts a flood of reports to a system administrator, the precise details of each incident are similarly not sent. Do you mean "MAY"?
(Robert Sparks) No Objection
(Sean Turner) No Objection
Comment (2012-01-06 for -)
I find it a little odd that the requirements language for what's optional/required in the different reports (s3.2.*) appear in the section titles but not in the text.