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. :)
Appendix B
- Replace the URL in the example with "RFC5965".
-MSK
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
