I'm going to respond to some of this out of order, because I think it will help the flow.
> We have these situations where the verification result is unambiguous, with > or without a DMARC policy: > - A verified identifier that has the same domain as the RFC5322.From address > is always a PASS. > - A verified identifier that does not match at least the two right-most two > labels is always not aligned. > If there are no verified identifiers, or there are no identifiers that align > on at least two labels, then the > result is always FAIL. Indeed, without DMARC at all: If we have an SPF authentication of a domain name, we have information to use in a decision. If we have a DKIM authentication of a domain name, we have information to use in a decision. We can check whether an authenticated domain name matches the From, and use that additional information (whether it does or does not match) in making the decision. If we have no successful authentication, we can use that fact as part of our decision. All of that existed before. DMARC is a protocol that centers around the publication and consumption of a DMARC policy record. It specifies requirements for the record, and how to obtain and use it. That is what DMARC *is*. Without the DMARC record, DMARC is not involved. That doesn't mean that all is lost: we still have all the stuff we always did with SPF and DKIM authentication results. What is means, though, is simply that DMARC is not involved. > I think it is a disservice to press the scope definition so severely that we > cannot find a couple of > sentences to include these exceptions in the document. I understand your position here. But the rough consensus of the working group, which follows how we generally specify protocols, is that we should not discuss how to do things when the protocol is *not* involved, because this document is about specifying how to do things when the protocol *is* involved. This document is not about general advice for how to avoid domain-name forgery. It's about what DMARC is and how to use it. Should you want to write a separate draft that gives general advice about avoiding domain-name forgery, phishing, spam, and the like, perhaps aimed at becoming a BCP, you're welcome to do that and submit it as an individual draft. Perhaps it will draw interest from the community. It's not in scope for the current charter of this working group, but the DISPATCH working group could consider the best way to handle getting it done, if there's sufficient interest. So, summarizing what's above... > My concept of DMARC has been that it includes everything which can be > elucidated by using SPF and > DKIM to validate or repudiate the RFC5322.From address. No: DMARC does not include everything related to the From address, nor everything to do with using SPF and DKIM. DMARC is about how to create, obtain, and use a DMARC record. When we say "that's not DMARC" in reference to situations where there is no DMARC record, that's what we mean. > I have raised this issue before. I expect MUST or MUST NOT to > be used where failure to comply will cause harm, most likely to > the person violating the directive. For example, a mail sender > MUST start an SMTP session with HELO or EHLO. If they do not, > they will not send any email via SMTP. In this document, I find > no place which meets that level of importance. On the > contrary, evaluators can do whatever they want, with whatever > information that they have available, to reach a disposition > decision that seems to be in their self interest. In this > particular paragraph, my point is that evaluators can sometimes > use SPF and DKIM to make an intelligent disposition decision, > even when the policy is lacking. Our document should not be > saying MUST NOT when it is likely to be in the evaluator's best > interest to do the exact opposite. Well, "harm" isn't really it. Apart from it being hard to define just what "harm" is, the main point of using MUST [NOT] is to be explicitly clear when a particular choice is necessary for things like interoperability, security, stability, or general compliance with the protocol. It's in that last sense that it's used here, and that's probably the fuzziest: often we avoid BCP 14 for that and just use plain English (to use your example, RFC 5322 does *not* actually say that a client "MUST" start with EHLO (look at Section 3.2); it's sufficient for it to say, in English, that that's what happens). But sometimes we think it's important enough to emphasize that, given the options available, this is what you MUST [NOT] do. It's a matter of judgment. On the text you're questioning: > "If the set produced by the DNS Tree Walk contains no DMARC policy record > (i.e., any indication > that there is no such record as opposed to a transient DNS error), Mail > Receivers MUST NOT > apply the DMARC mechanism to the message." This is not saying that there's nothing you can do: clearly, you can do anything you want with the information you have. What it's doing is making it clear that the process described in this document is applicable when there's a DMARC record, and when there is not, the process in this document does not apply. Personally, I'm fine with the text here, but I would also be happy with removal of the BCP 14 key words here, like this: NEW If the set produced by the DNS Tree Walk contains no DMARC policy record (i.e., any indication that there is no such record as opposed to a transient DNS error), then the DMARC mechanism does not apply to this message and Mail Receivers need to use other means to decide how to handle the message. END I don't care either way, and invite others to opine why the BCP 14 key words are important. Barry _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
