Thanks Murray and everyone for your input. I shall put a draft together with these changes and get it posted as soon as I can.
From: [email protected] [mailto:[email protected]] On Behalf Of Murray S. Kucherawy Sent: Thursday, October 06, 2011 9:53 PM To: Message Abuse Report Format working group Subject: [marf] Suggested changes to draft-ietf-marf-authfailure-report To aid Hilda in preparing an update, here are some of the changes I think consensus appears to support with respect to a revision of draft-ietf-marf-authfailure-report. Please let me know if I have any of it wrong. Some of these are point notes and not exact text changes, but should be enough for her to make the edits. Abstract - New text: "This memo registers an extension report type to ARF for use in reporting messages that fail one or more authentication checks performed on receipt of a message, with the option to include forensic information describing the specifics of the failure." Section 1 - New text: "[ARF] defines a message format for sending reports of abuse in the messaging infrastructure, with an eye towards automating both the generation and consumption of those reports. There is now also a desire to use extend the ARF format to include reporting of messages that fail to authenticate using known authentication methods, as these are sometimes evidence of abuse that can be detected and reported through automated means. The same mechanism can be used to convey forensic information about the specific reason the authentication method failed. Thus, this memo presents such extensions to the Abuse Reporting Format to allow for detailed reporting of message authentication failures." Section 3.1 - Authentication-Results MUST appear at least once, and SHOULD report all methods that were tested by the entity generating the report. It MUST be formatted according to [AUTH-RESULTS]. - Original-Envelope-Id SHOULD be included exactly once if it is available to the entity generating the report. - Original-Mail-From and Source-IP SHOULD be included exactly once for SPF, or for other methods that evaluate authentication during the SMTP phase. Remove the stuff about 0.0.0.0. - Delete Message-ID, as it is available in the third part of the report. - Delete Arrival-Date, as it's not relevant to DKIM or SPF specifically, and can be inferred from both report generation time and the Received fields in the third part of the report. - Reported-Domain MUST appear at least once (not exactly once). - Delivery-Result is OPTIONAL, MUST NOT appear more than once. If present, it SHOULD indicate the outcome, etc. Section 3.2.2 - Move DKIM-Canonicalized-Header and DKIM-Canonicalized-Body to new section 3.2.3. New Section 3.2.3: Optional for DKIM reports - Move DKIM-Canonicalized-Header and DKIM-Canonicalized-Body here. - Add a paragraph that says DKIM-Canonicalized-Header and DKIM-Canonicalized-Body MUST NOT include redacted data. The data presented there have to be exactly the canonicalized header and body as defined by [DKIM] and computed at the verifier. This is because these fields are intended to aid in identifying message alterations that invalidate DKIM signatures in transit. Including redacted data in them renders the data unusable. (See also Section 5 and Section 7.6 for further discussion.) New Section 3.2.4: Required for ADSP Reports - DKIM-ADSP-DNS: Includes the ADSP record discovered and applied by the entity generating this report. - New Section 3.2.5: Required for SPF Reports - SPF-DNS MUST appear once for every query to an SPF record that was done, to enable the reporting of included fields and where they came from. The ABNF in Section 4 changes; see below. Section 3.3 - The new set of failure modes is: dkim-adsp, dkim-bodyhash, dkim-revoked, dkim-signature, spf-fail, spf-softfail, spf-permerror. "granularity" is no longer a valid DKIM result, so it should be deleted. The descriptive text can stay for the DKIM ones, and the SPF ones can be copy-and-pasted accordingly (should be fairly straightforward). Section 4 - SPF-DNS ABNF changes to: { "txt" / "spf" } [FWS] ":" [FWS] domain [FWS] ":" [FWS] quoted-string Section 5 - Delete the second paragraph. This seems to be a sufficient paring down given the other new text about it that I've suggested here. Section 7.1 - Correct spelling of "implementers". Section 7.4 - Replace with: "In the case of transmitted reports in the form of a new message, it is necessary to consider the construction and transmission of the message so as to avoid amplification attacks, deliberate or otherwise. See Section 5 of [ARF] for further information." New Section 7.6: Redaction Of Data In DKIM Reports - Suggested text: "This memo requires that the canonicalized header and body be returned without being subject to redaction when a DKIM failure is being reported. This is necessary to ensure that the returned canonicalized forms are useful for debugging as they must be compared to the equivalent form at the signer. If a message is altered in transit, and the returned data are also redacted, the redacted portion and the altered portion may overlap, rendering the comparison results meaningless. However, unredacted data can leak information the reporting entity considers to be private. It is for this reason the return of the canonicalized forms is rendered optional." Appendix A - Add the names of people that contributed to this feedback, although they get wrist-slapped for waiting until the last minute to do so. J Appendix B - Replace the URL in the example with "RFC5965". -MSK
_______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
