We have two tracks that we can pursue for eliminating From munging from this list: They can be pursued in parallel:
Track 1: Downgrade Request We identify the small number of domains and subscribers who participate from p=reject domains, and consequently have their submissions munged. We develop a document which explains all the reasons why p=reject is a bad idea because of its impact on mailing lists. We ask the p=reject participants to ask their domains to change their DMARC status from p=reject to p=none. We see if the participants are willing to submit the request. We evaluate responses from those domains. This track could have been done a long time ago. Track 2: Exception Request 1) We fix our incoming filtering so that all submissions have verified identities. This is much easier for a list like this one than for a general mailstream. 2) We implement conditional munging. 3) We document and explain the list's operating practices, to include: - The techniques we use to achieve 100% identity verification - The message changes made by the list, with a special emphasis on the security benefits of forcing all body content to text mode. - Other content controls, such as attachment policy. - All of the ways that list messages can be distinguished from all other messages, so that a filtering exemption can be applied successfully Then we explain that because of these controls, DMARC enforcement is not needed because sender authentication has already been enforced. Because the beneficial content changes, DMARC enforcement at final delivery is actually counter-productive. 4) Finally, we ask all participants to submit an Exception Request to their email policies, to bypass DMARC enforcement for list messages. Our operating practices document is intended as supporting material for the exception request. 5) For any participant that receives a favorable response to his submission request, we skip From munging on messages sent to that that domain. Track 2 requires actual "Internet Engineering" - We SHOULD be doing 100% sender authentication. Undertaking the effort will identify technical obstacles that need to be overcome. The technical obstacles may be different for different list types. The effort will almost certainly identify authentication techniques that are effective for authentication purposes but not currently configured as an A-R or ARC authentication result. - We SHOULD provide better documentation of our operating practices. Undertaking the effort will provide a model for other lists to follow. Track 2 benefits: - From munging can be eliminated for a participant with only the cooperation of their domain administration. The solution does not require the cooperation of any other domains. - Elimination of From munging is potentially available to all participants, even those from p=reject domains - We are not fighting a battle to convince domains to lower their security posture. - Results can be obtained in months, possibly a year, based on development complexity and available resources. We have been trying some version of Track 1 for over a decade, with poor results. Can we please get started on Track 2? Doug Foster On Thu, Jul 13, 2023 at 10:55 AM Barry Leiba <[email protected]> wrote: > > The issue is not about lists being second class. What lists do to a > message is a privileged function, because > > modifying a message can be done maliciously as easily as it can be done > innocently. So the real problem > > is that DMARC demoted them from privileged to non-privileged by exposing > the risk inherent in their message > > modifications. Non-privileged parricipants do not have permission to > modify messages that they did not author. > > I do mostly agree with this, and it's a good point. > > Let me note two things: > > (1) As I've said before, telling mailing lists how they might deal > with this situation is out of scope for THIS DOCUMENT. > > (2) Telling mailing lists how they might deal with this situation is > absolutely in scope for this working group. > > Apart from rewriting the From header, which you seem to be presenting > as the only or best thing that mailing lists can do, there are other > solutions that mailing lists could adopt. For example, they could > bounce posts from p=reject domains. They could simply not modify > messages that are posted from p=reject domains. Ale has a proposal > that we will surely discuss at some point that sets up an automated > allow-list system so that receiving domains can adjust based on > information from the mailing list and the subscriber. > > We can and should discuss these and consider an update to RFC 7960, > perhaps as a BCP for mailing list managers about dealing with DMARC. > > In this document, specifying the DMARC protocol, we should say how we > think DMARC should work. I believe that means we need to say, > regardless of who we think will not pay attention, that p=reject is > not intended for domains that give out general-use email addresses to > general users. But whatever we get consensus to say needs to stay > with what the DMARC protocol is and how it's deployed... and then look > at the next (BCP) document about the rest. > > Barry >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
