If we are willing to break upward compatibility, it might be preferable to define policy in terms of what the sender knows, rather than what the receiver should do. After collecting feedback, the sender should know whether all message sources are sending with SPF PASS, DKIM PASS, or both.
This could be implemented with granularity based on the domain-part used in MAILFROM, and these four possible policy statements: Messages sent using organization domain for SMTP: · All messages with MAILFROM matching <FROM scope> will produce SPF PASS, at first hop. · All messages with MAILFROM matching <FROM scope> will produce DKIM PASS based on the FROM address, at first hop. Messages sent by mailing service providers using the service provider domain for SMTP: · All messages with MAILFROM not matching <FROM scope> will produce SPF PASS based on the SMTP address used, at first hop. · All messages with MAILFROM not matching <FROM scope> will produce DKIM PASS based on the FROM address, at first hop. We know that forwarding can affect DMARC and SPF evaluation, and that forwarding is outside the control of the sender. Consequently, when verification fails, it is the recipient system’s burden to determine whether forwarding has occurred, how the forwarding action affects the trust level of the message, and consequently whether the forwarding path is acceptable. One way to handle this would be for recipients of forwarded mail to register that fact with the system administrator, so that the system administrator could configure appropriate rules in the message evaluation system. Additionally, not all DMARC-violating impersonation is malicious, so even when impersonation is confirmed, it remains the recipient system’s burden to decide whether the impersonation should be tolerated or repudiated. Some implementations of sender authentication have used IETF specifications to simplistically implement message repudiation, without understanding the possible exceptions, and consequently without providing the necessary exception mechanisms. I am hoping that DMARCbis will include enough discussion of exceptions to reduce the likelihood of this error persisting forever. Changing the way we define policy might help achieve this goal. Doug Foster On Tue, Jul 6, 2021 at 8:46 AM Todd Herr <todd.herr= 40valimail....@dmarc.ietf.org> wrote: > Greetings. > > The theoretical goal of any domain owner that publishes a DMARC record is > to transition from an initial policy of p=none to a final one of p=reject, > because it is only at p=reject that DMARC's intended purpose of preventing > same-domain spoofing can be fully realized. > > Many domain owners see the transition from p=none to p=reject as a black > box, in that they believe they have no way of knowing what the full impact > of such a change might have on their mail, and they fear irreparable harm > to their mail if they make a mistake. > > The designers of DMARC anticipated this fear, and built several different > transitional states, or ratchets, into the protocol, including: > > - The "pct" tag (https://trac.ietf.org/trac/dmarc/ticket/47) > - The "sp" tag (https://trac.ietf.org/trac/dmarc/ticket/48) > - "quarantine" as a value for "p=" ( > https://trac.ietf.org/trac/dmarc/ticket/39) > > All of these are designed to allow the domain owner to request that some, > but not all, of its mail be held to stricter authentication standards so > that the domain owner can dip a toe in the water before jumping in. > > The ratchets have introduced some problems, though: > > - The 'pct' tag doesn't exactly work like it's intended to, and really > can't because of the nature of mail flow, unless there is a high volume of > failed authentication for the domain in question. (There is a much longer > discussion of this in section 6.7.4, Message Sampling, of > draft-ietf-dmarc-dmarcbis-02.) > - Some domain owners have taken a "more is more" approach to ratchets, > figuring if one is good, all are better, resulting in needlessly > complicated policy records > > The purpose of this email is to get folks thinking about possibly > simplifying the ratchet mechanisms, perhaps boiling them down into one. > This thinking and on-list discussion on this topic would serve as a > precursor to further face-to-face discussion at the next interim working > group meeting. > > I'll start the discussion by taking an extreme position... > > Ratchet mechanisms don't help in any way that a short TTL on your DMARC > record won't help, and in fact you need the short TTL on your record > anyway, because if you're trying a ratchet mechanism and find it's too > much, you still gotta update DNS to roll it back. > > Getting to p=reject isn't a difficult undertaking, at least from a > technical standpoint. Enumerate all your mail streams, ensure that they're > authenticating properly, and boom, you're done. The proper tools for doing > that are p=none, a rua tag pointed at a mailbox that is parsed by automated > means, active daily monitoring of the data consumed in those aggregate > reports (so that mail streams can be enumerated and authentication problems > addressed), and time. Time is the big one here, because sufficient time > must elapse to ensure that all of your legitimate mail streams are > exercised and reported upon, and that can take many months in large > organizations or at companies that are in the business of seasonal email > sending. > > The big challenge to fixing authentication issues, especially in large > organizations, is usually in just finding who owns the host/process that's > generating that unauthenticated mail. That can add time to the process, but > once you've enumerated them all, updated your SPF record and/or made sure > they're all properly DKIM signing, you can skip right from p=none to > p=reject. > > I look forward to lively conversation... > > -- > > *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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
