How, pray tell, shall the IETF enforce it's will upon those who fail to see the light?
For a historical parallel, I would invite you to research the IETF's historical view on Network Address Translation (NAT) for IPv4 and it's effectiveness on influencing the operational use of NAT. Scott K On October 10, 2021 5:11:34 PM UTC, 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
