Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-04
Covering the stuff Dave didn't cover: On Wed, Apr 16, 2014 at 3:11 PM, Jim Fenton 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 >
Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-04
On Apr 23, 2014, at 15:23, S Moonesamy wrote: > Hi Martin, > At 17:30 22-04-2014, Martin Rex wrote: >> Some MTAs (sendmail?) seem to recreate an RFC5322.From from the Envelope, >> in case that it is missing in the message. > > Yes, sendmail does that. Unless you prevent it by removing the F=F equate from your mailer flags. Chris ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-04
Hi Martin, At 17:30 22-04-2014, Martin Rex wrote: Some MTAs (sendmail?) seem to recreate an RFC5322.From from the Envelope, in case that it is missing in the message. Yes, sendmail does that. Regards, S. Moonesamy ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Review of draft-kucherawy-dmarc-base-04
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, especia
