toddherr
commented
7 months ago John Levine's on-list reply to the above:
I mostly agree but here's a few comments.
It appears that Seth Blank seth@valimail.com said:
Section 4:2: Use of RFC5322.From:
Is it also worth it to call out that time and operational impact have proven this to be the right choice?
Since we never tried anything else, we don't know. I suppose we might note that DMARC remains surprisingly effective even though most MUAs no longer show the domain name it uses.
Section 4.4.1 and 4.4.2:
Naive question: Both sections call out requiring the aligned identifier to be an FQDN. Is this sufficient with the extension of DMARC to PSDs? Would this mean that .google can never be a source of authenticated mail? Is that desirable?
You're conflating two things here. Back in ye olden days it used to be common for people to put partial domain names in their mail, e.g. joe@sales, and it added a default like joe@sales.bigcorp.com. That ended fairly quickly when Czechoslovakia got its own domain and comp sci departments around the world found that mail to joe@cs was now getting lost somewhere near Prague.
An FQDN can have one component so GOOGLE is a FQDN. However, a decade ago in RFC 7085 we found that a fair number of TLDs had MX records, and none of them worked. I checked again more recently, same thing. So the update to RFC 5321 is going to say that you shouldn't try to send mail to addresses with single label FQDNs.
Do we want to remove the reference to FQDN and say that an aligned identifier must be at or below a valid Organizational Domain?
The FQDN reference is fine, and I don't think we need to try and duplicate advice about whether or not single label names work.
Section 4.6: DNS Tree Walk:
I strongly believe that N needs to be 8 to meet operational use cases we see today, and may still fall short in the future as this use case is unlocked by the tree walk.
OK with me.
Section 5.3: General Record Format:
Shouldn't the RUF options be defined in the RUF document, as opposed to the primary bis document?
I'd rather leave all the syntax in the main document so people know how to construct or parse a DMARC record, but put the usage into the other docs. I don't feed strongly about where we say that the only URLs that work are mailto:.
Section 11.4: Display Name Attacks:
This feels out of place. Even though it's mentioned as a different problem, this is a lot of content irrelevant to the spec itself. Do we need it at all outside the second paragraph?
I'm with you -- I don't think it makes sense to talk about what we don't do since the list of potential topics is infinite.
alevesely
As posted to the working group mailing list on 30 March by Seth Blank, participating as an individual:
Top line:
The document needs to consistently use "verification" "validation" or "authentication" -- 7489 used "validation" in its abstract, and I'd recommend we stick with that.
The abstract, introduction section 2.2 still needs to be tightened up after the rest of the document settles. In particular, alignment is the most critical component of DMARC, and it is not mentioned in the abstract. The introduction and anti-phishing (2.2) sections can be made much tighter and to the point, and with fewer subjective parantheticals. I'm happy to propose text here once the rest of the document is settled.
Domain Owner Actions section needs cleanup; notes below. I'm also willing to propose text for this.
Consistency and definition of terms: In general, terms should be defined before they're used. Probably because some of the document has been reordered, there are several places that begin text without properly referencing or defining terms. For example, the term "target domain" appears three times in the document but is never defined. Is this an accidental shorthand for Author Domain? Something else? There are a bunch of throw away terms like "DMARC-Compliant" which are only used once. Can we get rid of these and use simple descriptive language like "Receiving mail systems that properly evaluate DMARC"?
To channel Crocker: always "header field" never just "header"
Specific nits:
Section 1: Introduction:
"As with SPF and DKIM, DMARC reports results as "pass" or "fail"." is confusing to someone expecting the introduction to cover reporting. Clearer would be "As with SPF and DKIM, DMARC validation results in a "pass" or "fail" verdict."
The introduction should also more clearly and simply call out that DMARC is about Aligned Authentication, Reporting, and Policy Conformance and how they interrelate in one place, before describing them separately.
I have many other concerns/recommendations in this section, but will provide text separately.
Section 4:2: Use of RFC5322.From:
Is it also worth it to call out that time and operational impact have proven this to be the right choice?
Section 4.4: Identifier Alignment Explained:
Both relaxed and strict alignment are defined in the midst of paragraphs in this section, but have no section headings nor earlier high level definitions in 3.2. As they're such core concepts, this feels lacking.
Section 4.4.1 and 4.4.2:
Naive question: Both sections call out requiring the aligned identifier to be an FQDN. Is this sufficient with the extension of DMARC to PSDs? Would this mean that .google can never be a source of authenticated mail? Is that desirable?
Do we want to remove the reference to FQDN and say that an aligned identifier must be at or below a valid Organizational Domain?
Section 4.6: DNS Tree Walk:
The text is correct, but N is wrong. I've shared my notes with this list but we never reached consensus: https://mailarchive.ietf.org/arch/msg/dmarc/GoExCeJYWhxnvH8lwjbr7nAcFh4/
tl;dr: N of 5 works for org domain discovery but falls short policy/reporting discovery. The algorithm can stay the same, but N needs to be increased and the text to match.
I strongly believe that N needs to be 8 to meet operational use cases we see today, and may still fall short in the future as this use case is unlocked by the tree walk.
Section 4.7: Policy Discovery:
The policy discovery that covers p=, sp=, and np= is technically correct, but confusing to parse. I'd recommend this be a clear algorithm like the preceding tree walk and the following org domain discovery.
Section 4.8: Organizational Domain Discovery:
The algorithm (step 2) that covers the psd=y case could use an example. "One label below" is technically correct, but anyone not intimately familiar with DNS terminology might make a mistake, so a precise example would help.
Section 5.3: General Record Format:
Shouldn't the RUF options be defined in the RUF document, as opposed to the primary bis document?
psd: "n: The DMARC policy record is published for a PSD, but it is the Organizational Domain for itself and its subdomain."
-> "subdomains."
Section 5.5. Domain Owner Actions
This section makes sense piecemeal, but doesn't quite work as a whole.
The text in 5.5, 5.5.1, and 5.5.2 should be reordered a touch and cleaned up. Explanation for both SPF and DKIM is in the SPF section, and the DKIM section covers too much about SPF. Also, the "SHOULD first ensure SPF and DKIM" in 5.5.1. seems strange, as there's no way to do this prior to section 5.5.4.
I would argue the 5.5.1 and 5.5.2 should be moved after 5.5.4.
There also appears to be a missing section between sections 5.5.5. and 5.5.6. which should be "remediate unaligned or unauthenticated mail streams" i.e. use the output from collecting and analyzing reports to actually make sure all your mail flow is properly authenticated, ideally with both SPF and DKIM, with at least one aligned.
Section 5.5.6. Decide Whether to Update DMARC Policy:
The final paragraph mentions "deliverability" which I do not think is appropriate for this document. It is also worth calling out here the interoperability challenges of NOT sending aligned mail that is capable of receiving an aligned pass, as this mail is increasingly likely to get rejected regardless of what policy you publish.
Section: 5.7.2. Determine Handling Policy
I know we say the steps MAY be done in parallel, but even so shouldn't step 4 (SPF) come before step 3 (DKIM)? In practice, SPF was designed to be validated as early in the mail flow as possible (during 5321), and this could be an unintended normative change to SPF in a DMARC context by requiring evaluation after DKIM can validate 5322.
The penultimate paragraph also exposes a nasty security consideration. If an attacker can get SPF and DKIM responses to return temperrors, then DMARC evaluation will fail and advertised policy will not be applied. This doesn't seem desirable. If there's a policy that is not none, and SPF and DKIM can't pass, why wouldn't the policy get applied?
Section 7.6: Expansion of Domain Owner Actions Section
Already covered by Todd, but this should be SHOULD NOT, not MUST NOT.
Section 8.1. Issues Specific to SPF:
This is a real operational problem, so I wanted to expand guidance. The note about best practice may or may not be appropriate here, but I think it works. There are multiple M3AAWG documents which cover this use case, and we can also link them if valuable.
OLD:
Some Mail Receiver architectures might implement SPF in advance of any DMARC operations. This means that a "-" prefix on a sender's SPF mechanism, such as "-all", could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place. Operators choosing to use "-all" should be aware of this.
NEW:
Some Mail Receiver architectures implement SPF in advance of any DMARC operations. This means that an SPF hard fail ("-") prefix on a sender's SPF mechanism, such as "-all", could cause that rejection to go into effect early in handling, causing message rejection before any DMARC processing takes place, and DKIM has a chance to validate the message instead of SPF. Operators choosing to use "-all" to terminate SPF records should be aware of this. Since DMARC only relies on an SPF pass, all failures are treated equally. Therefore, it is considered best practice when using SPF in a DMARC context for domains that send email to end records with a soft fail ("~" / "~all").
Section 10.2. Failure Report Considerations:
Add a preceding sentence before "out of band" that says "Due to the nature of the email contents which may be shared through Failure Reports, most major receivers refuse to send these reports on privacy grounds."
Section 11.4: Display Name Attacks:
This feels out of place. Even though it's mentioned as a different problem, this is a lot of content irrelevant to the spec itself. Do we need it at all outside the second paragraph?