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 <dougfoster.emailstanda...@gmail.com> 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 <barryle...@computer.org> 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 >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
