It's not that the IETF shouldn't be involved with advice on what mailing lists should do. It's that if we should put out a BCP or a standard that says mailing lists MUST NOT alter messages that they forward, those who write mailing list software (and those who deploy it) will not listen. That's where Scott's "we're not the police" statement comes in.
For whatever it's worth, mailing lists have been behaving this way for, as others have said, decades, and it has been considered good practice and has been found useful. Mailing lists add footers on messages, whether to advertise the list, to add disclaimers, or whatever. They like it, and won't change. Mailing lists add the list name to the Subject line because it makes it easier to create filters, and because it makes it easier for eyeballs to filter (for the vast majority of users who don't know and don't want to know how to create filters). They like that too, and that, too, won't change. We could advise change, but it would be wasted effort. In contrast, the mailing list folks are saying that it's DMARC that came later, that is being deployed incorrectly, and that must change. Clearly, those who find benefit from strict DMARC policies disagree, and they've said clearly that they won't change. And again, we're not the police. We could put, in the standards track version of DMARC, that p=reject MUST be used ONLY for transactional mail, which MUST be isolated from mail that might go to mailing lists (worded better than that, but we all know what I mean here). It would be shouting at the wind. We do the best we can to write reasonable standards and to give reasonable advice about using them. We can identify problems and write our best advice about how to avoid/mitigate them. Beyond that.... Barry On Sun, Oct 10, 2021 at 1:13 PM Douglas Foster <[email protected]> wrote: > > This is disappointing and problematic. > > So, AOL publishes a policy which says that they do not want their outbound > messages altered in transit, and implements filtering which demonstrates that > they do not want inbound messages modified in transit. > > In opposition, we have mailing lists that claim an unrestricted right to > alter messages in transit. > > What is the justification for IETF to be involved with developing strategies > to undermine AOL's interests in favor of a Mailing List's interests? It is > capricious and misleading for you to say that we are not being the Internet > Police, because we are clearly taking sides. If we are not the Police, then > apparently we are the Internet Smuggling Cartel. This just looks wrong. > > Doug Foster > > > > > On Sat, Oct 9, 2021 at 6:09 PM Scott Kitterman <[email protected]> wrote: >> >> Technically it's pretty easy to set up a mailing list which doesn't modify >> the message in ways likely to make DKIM fail. Almost no one bothers to do >> so despite pressures resulting from widespread use of DMARC p=reject. >> >> Operators do not need to justify anything to us. We are not the internet >> police. >> >> For our purposes it's enough to know that they do and there's no evidence >> that it's likely to change. >> >> Scott K >> >> On October 9, 2021 7:39:36 PM UTC, Douglas Foster >> <[email protected]> wrote: >> >I would be pleased to see a document which explains why lists MUST or >> >SHOULD alter content. After more than 2 years following this discussion, >> >no reason for this practice has ever been documented. >> > >> >Content changes would be easier to justify if subscribers granted >> >authorization to modify as part of the subscription process. But there >> >was not informed consent when I joined this list, so I doubt that informed >> >consent occurs on other lists either. >> > >> >What if, after reviewing the SHOULD list, an organization says "That's >> >interesting but unconvincing. Please send messages to our domain without >> >alteration?" Are lists equipped to give participants what they want, or >> >not? >> > >> >Doug >> > >> >On Thu, Oct 7, 2021 at 9:58 AM Barry Leiba <[email protected]> wrote: >> > >> >> Just on one point, for us to consider: >> >> >> >> > Personally, I think mailing lists changing From has horrible UX and I >> >> don't >> >> > really think anyone disagrees. It's only advantages are that it's >> >> relatively >> >> > easy to implement in a Mailing List Manager (MLM) and it solves the >> >> entire >> >> > DMARC problem for a specific mailing list without needing anyone else to >> >> change >> >> > anything. I understand the appeal. >> >> >> >> I think Scott is right that we all agree that rewriting From mitigates >> >> problems that mailing lists have with DMARC, but at a significant cost >> >> in usability. >> >> >> >> I think it would be bad to publish From-rewriting as a standard. >> >> >> >> But here: I think it is reasonable, perhaps advisable, to >> >> informationally document From-rewriting as a mechanism that is in use, >> >> and to include in that documentation a clear exposition of the >> >> problems that it causes. Why not get those horrible UX issues down on >> >> paper so that when someone decides to deploy it they are better >> >> informed? Perhaps we can lead people to take steps to reduce the UX >> >> challenges (for example, rewriting the way the IETF is doing it at >> >> least addresses the issue of knowing who sent the message, and how to >> >> reply to the actual sender, as compared to a rewrite directly to the >> >> mailing list address). >> >> >> >> Doesn't that make sense? >> >> >> >> Barry >> >> >> >> _______________________________________________ >> >> dmarc mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/dmarc >> >> >> >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
