Barry, you did a nice job of talking me off the ledge. If this is about helping list operators and message evaluators to collaborate in a way that avoids From-Munging, I have no objections.
Repeatedly, the topic has seemed to turn in directions that make the evaluator appear irrelevant -- as if the Lists don't need to talk to them. The reality right now is that a lot of From-Munging is unnecessary because: - many evaluators do not enforce DMARC - some evaluators enforce DMARC but have made exceptions for active lists - some other evaluators enforce DMARC and will make exceptions if asked to do so by their users This leaves a small group, like AOL, who enforce DMARC and yet are unresponsive to their users. This small group needs From-Munging, or unmodified messages, or different email accounts for list participation. I claim, without proof, that many of the most vocal critics of From-Munging are using domains that do not require From-Munging on incoming messages. In such cases, the DMARC-enforcing sender is not the real problem, ignorance is. Once the list and the evaluator have agreed to collaborate, we have a bunch of signalling options, including options that survive forwarding. They are mostly simple extensions of things we are already doing, much simpler and more determinative than ARC. Doug Foster . On Mon, Oct 11, 2021 at 10:28 AM Barry Leiba <barryle...@computer.org> wrote: > 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 > <dougfoster.emailstanda...@gmail.com> 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 <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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
