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?
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). -MSK, trying to be useful here
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
