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 <skl...@kitterman.com> 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 < > 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
