On Thu, Jan 6, 2022 at 6:32 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> There are good reasons for talking about a default DMARC policy. It is > certainly not to give evaluators permission, because we know that > evaluators can do whatever they want, and they will do what they deem to be > in their best interest. > > The point of a specification like this is to understand each participant's > best interest and channel that toward the common goal. I perceive a false > assumption that when a sender does not publish p=reject, then his messages > cannot be blocked for failure to validate, and therefore DKIM signatures > are unnecessary. Your question about "none" equaling "ignore" comes > across that way. "None" means that the sender provides no guidance, it > does not mean that the message cannot be blocked because of sender > authentication failure. > > As an evaluator, EVERY message that does not validate is a potential > impersonation threat, and therefore needs close inspection. Inspection > may produce these outcomes: > - quarantine, manual review, and release, which produces temporary delay, > - quarantine which expires before manual review, producing the same effect > as a block > - manual review which determines that the source sends harmless but > unwanted advertising, resulting in a permanent block on the sender. > - manual review which confirms that the message contains unacceptable > impersonation, resulting in a permanent block on the sender. > > Consequently, the best way for senders to avoid delayed or blocked > messages is to avoid getting close examination. This is facilitated by > ensuring messages are both DKIM-verifiable and SPF-PASS, regardless of > DMARC policy. P=NONE or T=Y or no policy are not valid substitutes. > > It IS in the interest of an evaluator to apply the DMARC test to every > message, so I believe it is in the interest of the specification to > acknowledge that likelihood. If someone in the group believes that it is > contrary to an evaluator's best interest, we need to discuss and document > that risk also. > > I believe there is merit to what you've written here, but I don't think these ideas belong in the DMARC protocol specification but instead in a separate document. Within the IETF, it's my understanding that an Applicability Statement might be a better place for advice on how best to implement a protocol and what impacts various choices may have. Outside of the IETF, there is literature already that describes best practices for email authentication for senders, intermediaries, and receivers; here is a link to one such document - https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
