On Thu, Aug 4, 2022 at 7:04 PM Douglas Foster < [email protected]> wrote:
> Sorry, Barry. I should have included the problematic text. here it is: > > 4.7. DMARC Policy Discovery > > > 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. > > > The purpose of DMARC is (or should be) to help evaluators make better > disposition decisions, because when they do, senders of wanted messages > will benefit from improved delivery as a result of the improved decision > making, > > DMARC uses available information to produce a result of "Authenticated" or > "Not Authenticated". Sometimes, the message can be reliably categorized > as "Authenticated" or "Not Authenticated" without reference to the > specifics of a domain owner policy. "Authenticated" is certain if the > RFC5322.From address matches the domain which generated SPF PASS domain or > a domain which generated DKIM PASS. Conversely "Not Authenticated" is > certain if no domains match at the right-most two labels. > > But this language says that the evaluator must not consider results > certain, even if DMARC's logic clearly indicates that they are certain, > when the policy is missing. If "Authenticated" and "Not Authenticated" > are not allowed, then the result becomes "Unknown." This design is asking > the evaluator to do something which defies common sense and defies his own > self-interest. If an illogical design causes an evaluator to make > sub-optimal disposition decisions, then it hurts the domain owner also. > > Does this clarify the issue? > There's a thing that was proposed some time ago called "Best Guess SPF", wherein a receiver would apply a default SPF policy if none was found in the DNS. I think the policy was a simple "a mx" or something close to that. It had the flavor of "I'm going to assume this is what you meant, since you didn't actually say anything else", and on that basis was discouraged because it could result in false bounces under the SPF moniker. This has a similar feel. In this case I think you're arguing that if something has a positive signal from one of the supported authentication methods and the resulting identifier falls within strict alignment, we should consider that a "pass" irrespective of what policy may or may not have been published (and, in fact, there's no need to go look). That's certainly a change since RFC 7489 and would have to be explained. It does save the verifier some redundant DNS work though. I wonder if it matters. For instance, is there any evidence that "pass" reliably gets better handling than "none" in such cases? -MSK, participating
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
