On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy <superu...@gmail.com> wrote:
> I've been thinking about the point a few people have made now that DMARC > has two actors that cause the problem: Those who "blindly" apply > "p=reject", and those who advertise "p=reject". You do, indeed, need two > to tango; enforcement doesn't happen without an advertising sender and a > participating receiver. Maybe any "MUST NOT" advice we provide needs to > cover both ends. We need to be careful about admonishing participating > receivers though. What would we say to them about how to be selective in > application? > I'd argue that we have language already that advises receivers to be selective in application. The second paragraph of section 5.8, Policy Enforcement Considerations, currently reads as follows in DMARCbis: Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the published Domain Owner Assessment Policy is "reject". In particular, because of the considerations discussed in [RFC7960 <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html#RFC7960>], it is important that Mail Receivers SHOULD NOT reject messages solely because of a published policy of "reject", but that they apply other knowledge and analysis to avoid situations such as rejection of legitimate messages sent in ways that DMARC cannot describe, harm to the operation of mailing lists, and similar. https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html#name-policy-enforcement-consider Might that language be made stronger? Sure. Might it or other text include mention of ARC as a possible solution? Maybe. > We've talked about having signal from the enforcing receivers back to the > MLM that the bounce occurred because of DMARC, but we haven't seen much > uptake of that idea for various reasons. > > I've also been thinking about ways to push the burden back on the > advertisers. Imagine we have some kind of signaling mechanism that MLMs > can take advantage of indicating to them that the author is using a strong > policy, and so it would be possibly a bad idea for the MLM to accept, > mutate, and re-send this message. This could be a header field or an SMTP > extension (though the latter is complex to get right in a store-and-forward > system). The MLM can then decide if it is willing to pass the message > unmodified to the list, or reject it with an error like "The policies of > this list require modification of your message, which violates your > domain's apparent policy. Your submission therefore cannot be accepted. > Please contact your support organization for further assistance." There's > never an opportunity for the collateral bounce to occur if the message is > never distributed, and the author domain has to either soften its policy or > separate its regular users from its transactional stuff somehow. > > This avoids the "collateral" and "persistent" damage issues I raised in a > separate post. It still requires the MLMs to do something new, but avoids > the need to implement any of a variety of unsavory mutations. MLMs could > also determine this by querying the current DMARC policy of the author's > domain, to be sure, so it's a choice between MLMs looking for a header > field (which they already know how to do) or becoming DNS-aware (relatively > simple, but pulls in some complexities and dependencies they may not want). > My preference here would be to add text for Domain Owners to make them understand the ways that p=reject might cause some mail using their domain to not make it to its destination, with "mailing lists might reject your mail" being one such example. -- *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
