Covering the stuff Dave didn't cover: On Wed, Apr 16, 2014 at 3:11 PM, Jim Fenton <fen...@bluepopcorn.net> wrote:
> 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. > Fixed. > 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!). > That text is apparently gone. > 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". > Fixed and fixed. > 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? > Fixed. > 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. > This appears to have been rewritten already. > 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. > Fixed and fixed. > 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. > Since we're documenting deployed infrastructure here, it's way too late to be renaming these. > 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. > Added. > 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. > Previously addressed (Scott Kitterman brought it up). > 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? > Clarified. > p:quarantine: What does "suspicious" mean? It sounds like it means > something other than "place into spam folder" and "scrutinize with > additional intensity" > Clarified. > 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? > The syntax of a DMARC report is defined elsewhere in the document. Shouldn't it be easy to identify one? > 5.3 Formal Definition > > dmarc-rfmt: Should allow a colon-separated list as described in 5.2. > Fixed. > 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. > The report formats, defined in MARF RFCs, present the syntax you would use to report those values if you have them. For DMARC, we're saying that all of those are a SHOULD. > 7.3 Failure reports > > Paragraphs 1 and 2 conflict -- it looks like a change to include [IODEF] > in the text was incompletely applied. > Cleaned up. > 7.3.1 Reporting Format Update > > "Operators implementing this specification also implement": Is that a > SHOULD or MUST before "also implement"? > It's an implied MUST. We're being trained lately that use of RFC2119 words is not always mandatory. In essence, this is saying "If you're a DMARC site, this is what you do." 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) > Fixed (new location). > Paragraph 2 is not relevant to utility of failure reports and probably > belongs in 7.3.1. > It's all been rearranged, and the new layout seems better. > 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. > Isn't this clear from the definition of "sp:" in 5.3 (of -08)? > 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. > I'm a little confused by your example. If I put a "p" and an "sp" tag at " example.com", then "p" applies to example.com and "sp" applies to *. example.com. That seems clear from 5.3. Are you suggesting saying that there's no way to do policy hierarchies? 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. > This has already been cleaned up. > 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. > What might one want to add? 14.4 Secure Protocols > > This seems like it belongs more in Security Consideration than here. > OK. 15.5 Identifier Alignment Considerations > > "DKIM signing practices" -> "DKIM selector records" > Fixed. > 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? > If you set "strict" on example.com, you remove any ability for someone that's compromised foo.example.com from generating mail that will pass DMARC. > 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. > Done. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc