I'm looking at this through the lens of formerly being a domain owner for a complex organization doing a successful DMARC deployment which ended at p=quarantine for the organization domain primarily housing user-generated email. A subdomain strategy is employed for most other non-user generated mail. I have not worked there for 2+ years.
I now work for a much much larger organization which has the same organizational complexities, but much much more complex. It also houses user traffic on the organization domain, and it's more mixed-use. It is also at p=quarantine currently. My organization also happens to be a large ESP (and as of a few months ago my primary hat is as a sender). Often, it is the authors within a domain who are the primary customer instead of the domain owner; DNS records are sometimes hard to get in place, sometimes impossible. Other times it is the domain owner who is the primary customer and they express a need to govern the use of our ESP (and every other ESP) being used by authors within their domains. We also happen to be in the receiver role for many of our customers, and sometimes received mail needs to be emitted back outbound. I wanted to jump in on this thread at some point to stick my foot in my mouth. I'm not sure which hat I'm wearing. All opinions expressed are my own. On Fri, Mar 31, 2023, at 10:49 AM, Hector Santos wrote: > > On 3/29/2023 9:16 PM, John Levine wrote: > > It appears that Murray S. Kucherawy <superu...@gmail.com> said: > >> > >> This is laid out in RFC 6377, Section 5.2, if it would be helpful to have > >> something published to reference. Indeed, ADSP threatened the same damage > >> that DMARC "p=reject" causes, which I think was one of the reasons it never > >> got adopted. > > It wasn't just a threat -- someone got bounced off an IETF list shortly > > after the ADSP draft came out when some eager beaver implemented it. > > > > I was the one who first reported the problem of what will happen when > the SSP (DKIM Policy) was split from DKIM. I was able to show this > when the IETF was not yet supporting DKIM. > > With the split, DKIM became DKIM-BASE and SSP became ADSP with all the > 3rd party (re)signer concepts from SSP removed. It went from SSP > policy which considered 3rd party signers: > > o=? WEAK (signature optional, no third party) > o=~ NEUTRAL (signature optional, 3rd party allowed) > o=- STRONG (signature required, 3rd party allowed) > o=! EXCLUSIVE (signature required, no 3rd party) > o=. NEVER (no mail expected) > o=^ USER > > to a very limited 1st party only policy. > > DKIM=DISCARD always expect to be signed by the Author Domain > DKIM=ALL always expect to be signed but by who? > > The only flexibility was DKIM=ALL. We presumed it could allow for a > 3rd party signer and it would be useful by mailing list servers. > Unfortunately, we could not resolve how to authorize the 3rd party > signers and ATPS was said not to scale. > > So in my view, its not ADSP, DMARC as the problem -- its a lack of a > 3rd Party Authorization model in the protocol. > > I see more domains are being "dmarca-tized" without their domain owner > knowledge of what the hosting system is doing nor how the MDA hosting > will handle mail. This is causing major problems that requires > drastic mail handling actions. > > I now have forwarding mail logic that determine the sender's DMARC > policy. If weak or none it can be forwarded. If strong, it stays for > mail pickup. > > I long had mailing list subscripting logic to stop a subscriber with a > strong DMARC policy. > > I will probably begin to add a From Rewrite but I would prefer if the > DMARC record has a domain authorization to do so, with perhaps a > `-rewrite` tag to signify any form of rewriting allowed. > > I think we need to focus more on DMARC having extended tags that > address many of the issues and ideas we have encountered. Receivers > want to honor the author domain wishes for handling failure when > various parts fail to meet their protocol-defined expectations. But > if honoring going to cause more problems, then we either abandon DMARC > like we did with ADSP or we add 3rd party domain considerations. > > Reject domain polices should support these ideas for handling outbound > and inbound mail handling. > > -p=reject -rewrite -atps > > -rewrite > > says if the first initiate signer succeeded and you need to resign, > then you are allowed to rewrite the ADID. This handles list > distribution problems. If a domain does not have -rewrite, a > subscriber and list submission MUST be denied. -rewrite would send a clear signal to the intermediary that the domain owner wishes for mail to be handled the same way most intermediaries have already been doing for p=reject|quarantine domains that do not have -rewrite. I don't think this adds much value for domains that are already p=reject, and it would cause issues for intermediaries who stop rewriting email for domains that have not yet become aware of -rewrite being a feature they should adopt I do like that -rewrite potentially replaces the "p=quarantine pct=0" hack for domain owners that wish to expose their users to DMARC effects before their DMARC deployment reaches p=reject. Is this better than the current language in DMARCbis A.7. Removal of the "pct" Tag, and the description of the "t" tag t: DMARC policy test mode (plain-text; OPTIONAL; default is 'n'). For the RFC5322.From domain to which the DMARC record applies, the "t" tag serves as a signal to the actor performing DMARC verification checks as to whether or not the domain owner wishes the assessment policy declared in the "p=", "sp=", and/or "np=" tags to actually be applied. This parameter does not affect the generation of DMARC reports. Possible values are as follows: y: A request that the actor performing the DMARC verification check not apply the policy, but instead apply any special handling rules it might have in place, such as rewriting the RFC5322.From header. The domain owner is currently testing its specified DMARC assessment policy. n: The default is a request to apply the policy as specified to any message that produces a DMARC "fail" result. I can see the argument that "rewrite" is more descriptive than "policy test", especially if inducing rewriting is the sole purpose of the "t" tag. And it allows the domain owner to indicate rewriting is preferred after a p=reject deployment, long after "policy testing" is complete. This wording might imply that rewriting might stop after ""testing" is complete after a p=reject deployment > -atps > > says if we ADID does not equal SDID then we will do an SDID ATPS > lookup at the ADID zone. This handles reception for all mail. If a > domain does not have -atps, then the receiver MUST honor the domain > reject policy for failures. I just read https://datatracker.ietf.org/doc/rfc6541/ (or, re-read, I can't remember) I'm struggling to understand how ATPS is significantly better than delegation via DKIM CNAME records. I can see that it's simpler for a domain owner because they need only set 1 ATPS record vs. sometimes 3 CNAME records (for key rotation). But that's not enough to justify adoption. Consider domain owners who (1) have a strong brand association with their organizational domain, (2) the domain allows normal user email as the primary use case, (3) and is moving to p=reject despite IETF's warnings not to. These security-minded domain owners also aren't willing, or are reluctant, to authorize an ESP to have delegated authorship over 100% of its email address space just because one use case within their organization has a valid reason to use the ESP. Hence they may not do DKIM CNAME delegation any more/less than they might use ATPS. They might resort to pushing their sub-organizations to sub-domains over time and take advantage of psd=y, but it's already past the point; the domain will have a ratio of mixed-use indefinitely. Does ATPS help solve that problem? Perhaps, if it can offer more fine-grained authorization. I could see these domain owners willing to leverage a protocol like ATPS if they could authorize delegated authorship down to individual email addresses. That level of control may be enough to pique the interests of security-minded domain owners who want to allow tightly-controlled mixed-use of the organizational domain. What would the freemail domains do with ATPS? Maybe the same thing, more slowly, if they care. I can only speculate here. The authors within the domain (users of the MBP) aren't allowed to publish anything in DNS and the domain owners see no point in explicitly authorizing every ESP to use every address within their domains. Leave it for the receivers to figure out. There is some assumption that freemail domains need to be spoofable by any potential ESP (maybe with some batteries/reputational model required by the receiver); and this assumption is being codified by MUST NOT p=reject [*]. Address-level delegation via ATPS might be something MBPs would be willing to support since they are typically also the receivers and may have a desire to reduce dependence on the required batteries. But in the end, they will need to share some of the same motivation of non-freemail domains to protect their domain from spoofing or a desire to have stronger governance. Considering both scenarios, we would be in a state where ATPS is allowing for more mail to be authenticated, but not in a state where we know all of the mail is being authenticated for any particular domain. I read that -atps would mean that the domain supports ATPS, but doesn't convey that it has 100% coverage. Without knowing that there is an acceptable level of coverage, to prevent complaints, the intermediary may err on the side of caution and continue to rewrite for domains with p=reject|quarantine, and not rewrite otherwise. So, ATPS offers a status quo for the intermediaries' rewrite logic. But I do like the idea of more fine-grained authentication, if it's even possible. How about from the point of view of an ESP? Should an ESP behave any differently than an intermediary when emitting mail from domains with p=reject? If the domain has p=reject and no mechanism has been provided for the ESP to send authenticated email. Which makes more sense? (1) The ESP honors the domain owner's policy and it does not allow its customer to emit mail using the domain. (AKA the winserver.com approach). The ESP could offer its customers to use a provided domain, perhaps with the original address encoded within the address/friendly from, setting the Reply-to, and some other approach to effectively emit the mail with some brand/authorship association while honoring the domain owner's policy (AKA the rewrite approach) (2) The ESP determines that the domain is used by humans, which it does by means of its author verification process, ignores the domain owner's policy, and allows its verified-authors to choose to have the ESP emit the mail using their verified address within the domain, relying on the receiver to decide if the mail is trustworthy without an authentication mechanism (AKA the approach of a MLM who has not mitigated DMARC's damaging effects because they must not be forced to) It seems, with (2), we're presuming every receiver has an ability to know of the author verification process of each non-authorized sender (ESP, intermediary, or otherwise), and they feed it into their opaque/individualized reputation models. With (1), receivers only need to rely on domain reputation and less on a non-existent intermediary reputation mechanism. In summary: a. -rewrite seems to be more logical than t=y to signal a permanent desire for intermediaries and ESPs not to emit non-authenticated mail using the domain, regardless of the domain's policy (possibly with a different term like -no-squatters ;-) b. An address-level authentication mechanism via a modified version of ATPS could reduce the amount of non-authenticated mail and reduce ambiguity regarding the domain owner's preferences Jesse [*] and all non-freemail domains have to choose between being lumped into the same mail handling treatment, or opt for p=reject by ignoring the MUST NOT
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc