> 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
