Re: [dmarc-ietf] Jim Fenton's review of -04
On Wed, Dec 24, 2014 at 2:40 AM, Franck Martin wrote: > -- > > *From: *"Murray S. Kucherawy" > *To: *"Franck Martin" > *Cc: *dmarc@ietf.org, "Scott Kitterman" > *Sent: *Tuesday, December 23, 2014 11:20:30 PM > *Subject: *Re: [dmarc-ietf] Jim Fenton's review of -04 > > On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin > wrote: > >> I think we should recommend something here, not sure if it needs to be >> normative. We do say to ignore the SPF policy when p!=none, though I think >> we can be normative on the lower layers. I see 2 options here: >> 1)tempfail the message is either SPF and DKIM have a tempfail status >> 2)tempfail the message if both SPF and DKIM have a tempfail status >> >> 1) is my preferred and is aggressive, therefore not sure people will like >> it. I'll settle for 2) >> >> As explained in another post, I'm worried I can run a DNS attack (or just >> a self inflicted DNS bad config) and get DMARC to reject emails it should >> have accepted (has the DMARC policy in cache, but cannot assert SPF and >> DKIM). >> >> > I think it's reasonably clear from 5.6.3 that the "fail open" choice is > possibly dangerous, as is anything that fails open. > > But more importantly, I'm also worried about making a normative decision > now about something we deliberately haven't specified up to this point for > whatever reason. We are supposed to be documenting current practice with > this effort, not establishing something new. > > Might this something best left for the standards track WG effort? > > Fair enough, but curious about standard practice. For instance what > openDMARC do? and others? > > I think DMARC got us to be "stricter" and less "lenient" with email. > > OpenDMARC gets the message only after OpenDKIM is done with it, so if OpenDKIM temp-fails, OpenDMARC never even sees it. Thus, the case we're concerned about here can't ever happen. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] draft-kucherawy-dmarc-base
Colleagues, I'm now completely caught up (as far as I can tell) on addressing feedback about the DMARC base draft that's going through the ISE process. As before, I'm resisting changes that add or change anything normative. I'm going only for things that clarify text, increase the accurate reflection of current practice, or help us to avoid IESG conflict review issues. Please let me know if I've missed anything that fits in one of those categories. Otherwise, -09 will go up soon including all of the changes that seem to fit within those boundaries. The planned diff to -08, which will become -09, is here: http://www.blackops.org/~msk/dmarc/diff.html Anything outside of those is open fodder for future working group discussion of a standards track version. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
- Original Message - > From: "Murray S. Kucherawy" > To: "Franck Martin" > Cc: dmarc@ietf.org, "Scott Kitterman" > Sent: Tuesday, December 23, 2014 11:20:30 PM > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 > On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin < fra...@peachymango.org > > wrote: > > I think we should recommend something here, not sure if it needs to be > > normative. We do say to ignore the SPF policy when p!=none, though I think > > we can be normative on the lower layers. I see 2 options here: > > > 1)tempfail the message is either SPF and DKIM have a tempfail status > > > 2)tempfail the message if both SPF and DKIM have a tempfail status > > > 1) is my preferred and is aggressive, therefore not sure people will like > > it. > > I'll settle for 2) > > > As explained in another post, I'm worried I can run a DNS attack (or just a > > self inflicted DNS bad config) and get DMARC to reject emails it should > > have > > accepted (has the DMARC policy in cache, but cannot assert SPF and DKIM). > > I think it's reasonably clear from 5.6.3 that the "fail open" choice is > possibly dangerous, as is anything that fails open. > But more importantly, I'm also worried about making a normative decision now > about something we deliberately haven't specified up to this point for > whatever reason. We are supposed to be documenting current practice with > this effort, not establishing something new. > Might this something best left for the standards track WG effort? Fair enough, but curious about standard practice. For instance what openDMARC do? and others? I think DMARC got us to be "stricter" and less "lenient" with email. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin wrote: > I think we should recommend something here, not sure if it needs to be > normative. We do say to ignore the SPF policy when p!=none, though I think > we can be normative on the lower layers. I see 2 options here: > 1)tempfail the message is either SPF and DKIM have a tempfail status > 2)tempfail the message if both SPF and DKIM have a tempfail status > > 1) is my preferred and is aggressive, therefore not sure people will like > it. I'll settle for 2) > > As explained in another post, I'm worried I can run a DNS attack (or just > a self inflicted DNS bad config) and get DMARC to reject emails it should > have accepted (has the DMARC policy in cache, but cannot assert SPF and > DKIM). > > I think it's reasonably clear from 5.6.3 that the "fail open" choice is possibly dangerous, as is anything that fails open. But more importantly, I'm also worried about making a normative decision now about something we deliberately haven't specified up to this point for whatever reason. We are supposed to be documenting current practice with this effort, not establishing something new. Might this something best left for the standards track WG effort? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
- Original Message - > From: "Murray S. Kucherawy" > To: "Scott Kitterman" > Cc: dmarc@ietf.org > Sent: Tuesday, December 23, 2014 10:32:44 PM > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 > On Mon, Dec 22, 2014 at 10:44 AM, Scott Kitterman < skl...@kitterman.com > > wrote: > > There was a recent thread on postfix-users about DMARC rejections when > > there > > > are DNS errors that caused me to review -08 to see what it says on the > > matter. > > > At the end of section 5.6.2, it says: > > > Handling of messages for which SPF and/or DKIM evaluation encounters > > > a DNS error is left to the discretion of the Mail Receiver. Further > > > discussion is available in Section 5.6.3. > > > My reading of 5.6.3 though is that it only discusses DNS errors in the > > context > > > of failing to retrieve the DMARC record. Any discussion about handling DNS > > > errors for SPF/DKIM seems to be missing. > > Yes, DMARC punts on what to do when SPF or DKIM encounter transient failures. > I imagine that's because those modules would arrange to temp-fail a message > that has that problem. I suppose my experience is that messages don't even > get to the point of DMARC evaluation when that happens, because the message > has already been temp-failed. As SPF (and DKIM) can report a message with the status tempfail, it means the message is not necessarily tempfail (bounced). > If you think about DKIM and SPF as being part of a layer below DMARC, then > I'm not sure it's wise of us to be making any kind of normative statement > about what to do when the lower layers fail. > What do you suggest? I think we should recommend something here, not sure if it needs to be normative. We do say to ignore the SPF policy when p!=none, though I think we can be normative on the lower layers. I see 2 options here: 1)tempfail the message is either SPF and DKIM have a tempfail status 2)tempfail the message if both SPF and DKIM have a tempfail status 1) is my preferred and is aggressive, therefore not sure people will like it. I'll settle for 2) As explained in another post, I'm worried I can run a DNS attack (or just a self inflicted DNS bad config) and get DMARC to reject emails it should have accepted (has the DMARC policy in cache, but cannot assert SPF and DKIM). ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
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] Jim Fenton's review of -04
On Mon, Dec 22, 2014 at 10:44 AM, Scott Kitterman wrote: > There was a recent thread on postfix-users about DMARC rejections when > there > are DNS errors that caused me to review -08 to see what it says on the > matter. > > At the end of section 5.6.2, it says: > >Handling of messages for which SPF and/or DKIM evaluation encounters >a DNS error is left to the discretion of the Mail Receiver. Further >discussion is available in Section 5.6.3. > > My reading of 5.6.3 though is that it only discusses DNS errors in the > context > of failing to retrieve the DMARC record. Any discussion about handling DNS > errors for SPF/DKIM seems to be missing. > Yes, DMARC punts on what to do when SPF or DKIM encounter transient failures. I imagine that's because those modules would arrange to temp-fail a message that has that problem. I suppose my experience is that messages don't even get to the point of DMARC evaluation when that happens, because the message has already been temp-failed. If you think about DKIM and SPF as being part of a layer below DMARC, then I'm not sure it's wise of us to be making any kind of normative statement about what to do when the lower layers fail. What do you suggest? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
For the stuff not already answered in my last reply to Dave:
On Sun, Dec 21, 2014 at 2:18 AM, Jim Fenton wrote:
> [2.4 Out of Scope]
> >> Bullet 10: Again, DMARC doesn't do authentication, even for domains; it
> >> relies on other authentication mechanisms.
> > I originally thought this, too, but in fact DMARC does do authentication:
> >
> > DMARC asserts authenticity of the rfc5322.From field domain name.
> > That's a distinct semantic increment over anything SPF or DKIM do on
> > their own.
>
> What it does is different enough from SPF and DKIM that I think it's
> overloading the term "authentication" to use it again here. It doesn't
> contribute to a clear understanding. It looks at the results of SPF and
> DKIM, which operate at the domain level, so this bullet isn't really
> necessary.
>
Doesn't RFC5322.From also operate at the domain level in our context?
DMARC's filtering function is based on whether SPF or DKIM can provide
> an authenticated, aligned identifier for the message under
> consideration. Messages that purport to be from a Domain Owner's domain
> and arrive from servers that are not authorized by that domain's SPF and
> do not contain an appropriate DKIM signature can be affected by DMARC
> policies.
>
> [I think the additional "that domain's" will do it.]
>
Added.
> >> 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.
> > -08 doesn't have this language.
>
> Now section 5.1, paragraph 2. Honestly, this reads like marketing fluff
> that doesn't belong in a specification like this.
>
I don't have any trouble removing it. I think it was added to ward off
anyone that might claim "You shouldn't be using the DNS for this."
> >> 11.1 Discovery
> > 6.2.1 in -08
> >
> >> 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.
> > The text's use of the word 'corresponds' handles the mapping to org
> > domain, IMO.
>
> This is more of a comment about document organization. The previous
> sections have been talking about things that follow discovery of the
> policy record, and now when talking about aggregate reports there's
> another section about discovery. Why here; isn't this a little redundant?
>
It's mainly to say that there isn't a specific discovery process for
aggregate report details; it's already done. This might be a legacy from
ancient versions where there was a separate process. I'll tidy it up by
merging it into the previous subsection.
> SHOULD isn't strong enough for the Report Receiver to depend on. There
> are other ways to get the information that is encoded into the filename.
>
Like what?
> If the spec wants to suggest, "here's a nice file name format that you
> MAY want to use", that's fine. But SHOULD is both too weak if the
> recipient can't depend on it and too strong if it's merely advice.
>
I'm not so sure. If we're going to go with MAY, then we also need some
kind of signal that the filename used does conform to the proposed
encoding, or else there might be some attempt to extract report parameters
that simply aren't there.
> >> 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.
> > How is that a DMARC-specific 'exposure' consideration?
>
> Because it's the retrieval (or search for) the DMARC record might
> reveals that. But on rereading this, paragraph 4 addresses this
> sufficiently.
>
> New issue: Paragraph 3 refers to "Both report types" but since iodef was
> removed, it should just say "The AFRF report type".
>
That refers to the aggregate and detailed reports ("rua" and "ruf"), not
IODEF and AFRF.
-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Jim Fenton's review of -04
On Fri, Dec 19, 2014 at 5:30 PM, Dave Crocker wrote: > > 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. > > Everyone is concerned about it. But it's the best that is currently > available. > +1, and furthermore, -08's Section 3.2 and Appendix A.6 both admit the current method is flawed and DMARC operators should switch to something better as soon as such a thing becomes available. I don't know what more can be said at this point. > > 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. > > The first possibility isn't viabile, for the reason cited. The second > possibility might be worth pursuing in the DMARC working group, rather > than in a document that captures existing DMARC practice. > > There are, of course, other possibilities, such as not having DMARC > pursue operational nuance that makes the spec more complex, trying to > handle special cases. That is, if a site isn't ready to use DMARC, it > shouldn't. > The "pct" tag was also provided to address the concern that the impact of enabling DMARC is uncertain. > > 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. > > 6.1 in -08. > > Given the problems with the search for org domain, a SHOULD is as far as > is practical here. > > I'd suggest noting that that's a reason this can't be a MUST. > I think it's SHOULD because at the time it was written, the verification process was untested. It's in production now (OpenDMARC implements it), so I agree that a MUST is appropriate. > > 8. Policy Discovery > ... > > 5.6.3 in -08 > > > > 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. > > It isn't meant to be. > > -08 text says: > > "If the RFC5322.From domain does not exist in the DNS, Mail >Receivers >SHOULD direct the receiving SMTP server to reject the message. The >choice of mechanism for such rejection and the implications of those >choices are discussed in Section 9.3." > > I suggest removing it. Although a common anti-abuse mechanism, it's out > of scope for DMARC. > I disagree. DMARC operators all seem to apply this practice, so it's correct to say that if you play this game, you reject mail from non-existent domains. Essentially in this way DMARC is a profile of RFC5321/RFC5322, which is perfectly acceptable. We are not updating those standards here, merely profiling them. > > 9. Domain Owner Actions > > 5.5 in -08 > > > Last paragraph doesn't seem like it fits. Suggest it be removed. > > While I could imagine a better place for it in the doc, having a /terse/ > pointer like this to some authentication pedagogy seems useful to me, in > an authentication-related spec... > +1. > > 11.1 Discovery > 6.2.1 in -08 > > > 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. > > The text's use of the word 'corresponds' handles the mapping to org > domain, IMO. > +1, and there isn't a second Discovery section anymore; there was a Great Consolidation at around the -05 version. > > 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. > > "SHOULD" is a very strong normative statement. Note that it permits > non-conformance only in the presence of singular knowledge by the > non-conforming party. > > Filename labeling is generally considered useful. Why wouldn't it be > useful here? > +1, not to mention again that this is current practice among DMARC operators and doesn't seem to be an issue so far. > > 14.1 Data Exposure Considerations > > > > Last paragraph: what's an "unexpected Mail Receiver"? > Reworded. > > The privacy co
Re: [dmarc-ietf] DMARC and TEMP errors was: Re: Jim Fenton's review of -04
On Mon, Dec 22, 2014 at 3:18 PM, Scott Kitterman wrote: > > As I read -08 what to do in that case is undefined. There's a dangling > pointer > to 5.6.3. It's dangling because nothing in that section addresses the > question of how to handle DKIM/SPF temporary errors. > > 5.6.3's final paragraph makes it clear that the action taken is at the discretion of the mail receiver, and gives two examples of non-destructive ways to handle that case. Do we need to say more than that? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)
Hi Rolf, getting back to your review (thanks for the nudge): On Wed, Nov 12, 2014 at 6:26 PM, Rolf E. Sonneveld < r.e.sonnev...@sonnection.nl> wrote: > > > Abstract: > > This lack of cohesion has several effects: receivers have difficulty > providing feedback to senders about authentication, senders therefore have > difficulty evaluating their authentication deployments, and as a result > neither is able to make effective use of existing authentication technology. > > > This focuses on the reporting function of DMARC, leaving out the policy > part of it. > > Suggested text: > > This lack of cohesion has several effects: senders have difficulty > providing information about their use of an authentication policy and > receivers have difficulty determining a disposition preferred by senders. > Vice versa, mail receivers have difficulty providing feedback to senders > about authentication, senders therefore have difficulty evaluating their > authentication deployments, and as a result neither is able to make > effective use of existing authentication technology. > > The Abstract appears to have been rewritten since you reviewed it, so a straight text swap won't work anymore. The new text focuses on what's being provided, not what was missing. Do you want to take another run at it? > Introduction: > > [...] mail receivers have tried to protect senders [...] > > > Suggested: > > [...] mail receivers have tried to protect senders and their own > users/customers [...] > > This text no longer appears in the draft. > Starting with "DMARC allows domain owners and receivers to collaborate > by", the terms 'domain owners', 'receivers', 'senders' and 'SMTP > receivers', 'Mail Receivers', 'mail receivers' are used throughout the > document. I'd suggest to add a definition of the term ' Mail Senders' to > the introduction part of chapter 3 and then use only the terms as defined > in 3., throughout the document. Suggested text for the term Mail Sender: > > >- Mail Sender: the sender of mail with a domain for which the Domain >Owner may have published a DKIM public key and/or an SPF authentication >record and/or a DMARC policy; > > > (although we may want to not mention DKIM or SPF here). > It looks like that got cleared up; -08 has no reference to "Mail Sender". > 2.2 Out of Scope > > Add: > > ocousin domain attacks > Covered in Section 2.4 of -08. > 3.1.2 Key Concepts > > Last sentence: add a reference to this 'other referenced material'. > Good idea; added. > 3.1.3 Flow diagram > > The box titled 'User Mailbox' could give the impression that there's only > one choice for delivery. However, quarantining can be done without delivery > to a mailbox. I'd suggest to label this box 'rMDA'. > That's already done in -08. > The part within parentheses of step 6: > > 6. Recipient transport service conducts SPF and DKIM authentication > checks by passing the necessary data to their respective modules, each of > which require queries to the Author Domain’s DNS data (when identifiers are > aligned; see below). > > > might indicate that SPF and DKIM authentication checks need not be > performed when identifiers are not aligned. However, for sake of reporting, > SPF and DKIM authentication checks will in general always be done, or am I > missing something? > I can envision a DMARC implementation that skips SPF or DKIM checks if the corresponding identifiers are not aligned, because they won't be interesting to DMARC in that case. > 3.1.4.1 DKIM-authenticated Identifiers > > remove (or change) the 'Cousin Domain' example: it doesn't hold when a bad > actor is signing the mail with d=cousindomain and > RFC5322.From=localpart@cousindomain > It's not there in -08. > 4 Use of RFC5322.From > > Last bullet (The DMARC mechanism ...). It seems the other bullets provide > reasons why RFC5322.From is chosen while the last one does not. It looks to > me as a circular reasoning. > It's not there in -08. > 5.2 DMARC URIs > > It is not clear from the text what the report originator must do when the > report payload exceeds the maximum size as indicated by the record. Should > it not send anything, should it split up reports, should it notify the > requester that there was a report exceeding the maximum size? > Section 6.2.2 in both versions explains what to do here. > 5.3 General Record Format > > adkim and aspf do not provide a list of all possible options (like is done > for fo and p). Of course it is pretty obvious that for 'strict' the 's' > must be used, but it's not clear from the text. > They're there in -08. > Next, the P: and pct: tags: they show that (in hindsight) the policy part > and the reporting part of DMARC might have been better off, when they were > defined in different specs. Now we need to complicate the text to say that > the policy tag p: is required, but not for third-party reporting records. > And for pct, that it "MUST NOT be applied to the DMARC-generated reports". > Well
