It seemed like a good time to run through the current DMARC draft. I'm pleased to see that quite a few of the comments I made in my 2 Oct 2013 review of the -01 draft have been addressed.
Note that this review addresses the quality of the specification only; it intentionally doesn't address the question of whether deployment of DMARC might be harmful in some way. ===== 1. Introduction Top of page 6: "The receiver reports to the domain owner..." The receiver actually sends reports to a report receiver designated by the domain owner. 2.4 Out of Scope I still find the double negatives to be confusing, e.g., "DMARC will not make a distinction...". It's the making of a distinction that's out of scope, not the not making a distinction (forgive my own double negative, please!). Bullet 10: Again, DMARC doesn't do authentication, even for domains; it relies on other authentication mechanisms. 3. Terminology and Definitions Domain Owner: This definition refers to the domain owner as being the registrant of a DNS domain. But as used elsewhere in the spec, it can also be a delegate of that registrant that is given control over a subdomain. The document frequently refers to a domain owner publishing a DMARC record, so it's worth clarifying who has that capability. Report Receiver: "reports about the messages claiming to be from a third party" We're talking about the reports here, not the messages themselves, so I would suggest "reports from a third party about their messages". 3.1.2 General Concepts Paragraph 2: "provide feedback to the Domain Owner". Should this say a Report Receiver designated by the Domain Owner, or is that too much information at this point? Paragraph 3 doesn't quite capture the sense of alignment properly, especially for SPF. A message that is authorized by SPF might have an unaligned envelope-from address, so the validity of SPF for such messages is moot. 3.1.3 Flow Diagram Item 1: "Author constructs" and "Author also configures" -> "Domain Owner constructs" and "Domain Owner also configures" (I missed this last time) Item 7: 'e.g., a "pass" or "fail"' Are there other results? If not, remove the e.g. 3.1.4 Identifier Alignment Paragraph 5: Although this document makes it clear that "strict" and "relaxed" are different from their usage in DKIM, I'm still having trouble with those words. "strict" means that only this specific domain is affected; "relaxed" means that this domain and its subdomains are affected. So "relaxed" is really more strict in that it enforces more. I find the terms to be confusing, and would recommend something that more directly describes whether the policy applies to subdomains. 3.1.4.1 DKIM-authenticated identifiers Paragraph 4: Include section reference (3.2) to public suffix lists since the section describing it has moved after this text. 3.2 Organizational Domain I remain very concerned about this algorithm since I have been previously told very specifically not to do this by the DNS folks. I'm also concerned about the inconsistency (interoperability impact) that could result from different operators using different public suffix lists. 4. Policy Paragraph 4 basically says, if you don't want a particular authentication scheme to be considered by DMARC, don't use it at all. For a domain that is using SPF and DMARC (for example), this could be an impediment to their deployment of DKIM because they could not test with it without having it immediately affect recipients' message handling. One possibility would be to ignore DKIM if the testing (t=y) flag is set, although a campaign would be needed to get the many domains currently using t=y to turn it off. Another possibility would be to have a setting in DMARC to ignore a specific authentication method entirely. On a related note to the t=y flag for DKIM, are all types of SPF failure (-all, ~all, and ?all) treated equally, or can one of them (probably ?all) be used for testing? 5. DMARC policy record Paragraph 2: Again, "matches perfectly with the DNS" is an inaccurate characterization. If the query requirement matched perfectly with the DNS, DNS would have a way to determine the Administrative Domain without resorting to suffix lists and such. Just strike the sentence; this isn't relevant here anyway. 5.2 General Record Format fo: A colon-separated list of options is supported, but 0 and 1 conflict with each other so that either needs to be prohibited or it needs to define which wins. fo:d: "a signature": In the case of a message with multiple DKIM signatures, does that mean if any signature failed evaluation, a message is sent? Is a separate message sent for each failed signature? p:quarantine: What does "suspicious" mean? It sounds like it means something other than "place into spam folder" and "scrutinize with additional intensity" pct: "DMARC-generated reports...must be sent and received unhindered". How does one identity a DMARC-generated report to make sure it's unhindered, especially if a bad actor tries to make their messages look like reports? 5.3 Formal Definition dmarc-rfmt: Should allow a colon-separated list as described in 5.2. 7.1 Verifying External Destinations Paragraph 3: "verification steps SHOULD be taken" These steps are to protect another domain from attack. It needs to be a MUST. 7.2 Aggregate Reports The list of what SHOULD be in the reports seems like it belongs in the definitions of the report formats themselves. 7.3 Failure reports Paragraphs 1 and 2 conflict -- it looks like a change to include [IODEF] in the text was incompletely applied. 7.3.1 Reporting Format Update "Operators implementing this specification also implement": Is that a SHOULD or MUST before "also implement"? 7.4 Utility of Failure Reports Paragraph 1: "detects an authentication failure" -> "detects a DMARC failure" (since authentication can succeed but DMARC fail because of alignment) Paragraph 2 is not relevant to utility of failure reports and probably belongs in 7.3.1. 8. Policy Discovery Step 3: This implicitly says that policy directly applied to a subdomain takes precedence over that published by an Organizational Domain. That's fine, but it should be stated more clearly elsewhere. As I said before, it would be helpful to have something earlier in the specification that talks about the ability to publish a policy either directly on a subdomain or on an Organizational Domain. Also, note that subdomain policies are necessarily strict (don't apply to subdomains of the subdomain) because they won't be discovered using this algorithm. It should say that somewhere do operators don't try to apply DMARC to subtrees of their organizational domain. Second-to-last paragraph: "If the RFC5322.From domain does not exist in the DNS" is basically changing what RFC5321/5322 allow. This isn't the place to be making fundamental changes to the behavior of email. 9. Domain Owner Actions Last paragraph doesn't seem like it fits. Suggest it be removed. 10.1 Extract author domain "Such messages SHOULD be rejected": Agree where forbidden by RFC5322, but a single RFC5322.From containing multiple entities is explicitly valid. Again, this isn't the place to be making fundamental changes to the behavior of email. 11.1 Discovery Mail Receivers can also discover reporting requests from the Organizational Domain. That should be mentioned here. But I'm a little confused why we have another Discovery section at all. 11.2.1 Email The whole thing about filenames needs to go away. Since it's only a SHOULD requirement, the Report Receiver needs to be able to handle reports that don't follow this format as well as those that do. I also wonder if some operating systems have trouble with filenames containing the "!" character. Just let the filename be arbitrary. And since there's a MIME-type, the file extension shouldn't matter either. I have somewhat the same reaction to the Subject header field discussion. It's only a SHOULD, so report receivers can't depend on it. 11.2.3 Error Reports Last paragraph: If this is published as an independent submission RFC, there will be no opportunity to add something here. 14.1 Data Exposure Considerations Last paragraph: what's an "unexpected Mail Receiver"? The privacy consideration here, which isn't obvious from the wording, is that users may currently use forwarding in a way that prevents the sender from determining the ultimate delivery address. DMARC has the potential to break that. This might be important in the case of a user that is trying to distance themselves from a stalker. 14.2 Report Recipients Some potential exists for report recipients to perform traffic analysis: to obtain metadata about the receiver's traffic. In addition to verifying compliance with policies, receivers need to consider that before sending reports to a third party. 14.4 Secure Protocols This seems like it belongs more in Security Consideration than here. 15.5 Identifier Alignment Considerations "DKIM signing practices" -> "DKIM selector records" Note that actors that can gain control of SPF records or selectors can probably publish a DMARC record for the subdomain as well, which will take precedence over the record at the Organizational Domain. Last paragraph: What does "strict" have to do with this? 17.3 DNS Security Might want to make a distinction between DNSSEC publication and resolution. Publication is relevant to Domain Owners, and third-party Report Receivers. DNSSEC-aware resolution is relevant to Mail Receivers and Report Receivers. ===== I didn't particularly review the appendices this time around. -Jim _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
