DMARCbis WGLC: Section 4.1 DMARC Basics

[toddherr]

As posted to list by Ale Vesely:

`the last two paragraphs of section 4.1 also show a neat asymmetry between rua and ruf. The first sounds like the notification that feedback exists rather than something a mail receiver should do. The second is good, but not normative.

OLD DMARC's feedback component involves the collection of information about received messages claiming to be from the Author Domain for periodic aggregate reports to the Domain Owner or PSO. The parameters and format for such reports are discussed in [I-D.ietf-dmarc-aggregate-reporting]

A DMARC-enabled Mail Receiver might also generate per-message reports
that contain information related to individual messages that fail
authentication checks.  Per-message failure reports are a useful
source of information when debugging deployments (if messages can be
determined to be legitimate even though failing authentication) or in
analyzing attacks.  The capability for such services is enabled by
DMARC but defined in other referenced material such as [RFC6591] and
[I-D.ietf-dmarc-failure-reporting]

NEW A DMARC-enabled Mail Receiver SHOULD collect authentication results and generate aggregate reports that contain information about received messages claiming to be from the Author Domain for periodic aggregate reports to the Domain Owner or PSO. The parameters and format for such reports are discussed in [I-D.ietf-dmarc-aggregate-reporting]

A DMARC-enabled Mail Receiver MAY also generate per-message reports
that contain information related to individual messages that fail
authentication checks.  Per-message failure reports are a useful
source of information when debugging deployments (if messages can be
determined to be legitimate even though failing authentication) or in
analyzing attacks.  The capability for such services is enabled by
DMARC but defined in other referenced material such as [RFC6591] and
[I-D.ietf-dmarc-failure-reporting]`

[alevesely]

The first line in NEW should be:

A DMARC-enabled Mail Receiver MUST collect authentication results

I had forgotten of #81

[toddherr]

@alevesely Consensus in Issue 81 was recorded as reporting being a SHOULD, not a MUST

[alevesely]

SHOULD seems more reasonable to me (and MAY for failure reports.)

In that case, the last paragraph of Section 5.8 must be downgraded to SHOULD as well. It says:

   Mail Receivers MUST also implement reporting instructions of DMARC,
   even in the absence of a request for DKIM reporting [RFC6651] or SPF
   reporting [RFC6652].  Furthermore, the presence of such requests MUST
   NOT affect DMARC reporting.

It's been that way since rev -01.

BTW, there must be a better wording than reporting instructions; it's nearly incomprehensible.

[toddherr]

I'm striking the last paragraph of Section 5.8. The section is titled "Policy Enforcement Considerations", and the text at issue seems off-topic for such a section, regardless of how clearly (or not) it's worded.

Instead, I'm adding subsection 5.7.5, "Optionally Send Failure Reports" to section 5.7 "Mail Receiver Actions", with the following text:

As mentioned previously, per-message failure reports can be a useful source of information for a Domain Owner, either for debugging deployments or in analyzing attacks, and so Mail Receivers **MAY** choose to send them. Experience has shown, however, that Mail Receivers rightly concerned about protecting user privacy have either chosen to heavily redact the information in such reports (which can hinder their usefulness) or not send them at all. See [@!I-D.ietf-dmarc-failure-reporting] for further information.