If the evaluator domain might forward an unmunged message, the domain needs to re-mung at the domain exit MTA. How much of an obstacle will this be?
On Tue, Oct 12, 2021, 6:06 AM Alessandro Vesely <[email protected]> wrote: > From: rewriting confers 100% deliverability on messages, but has a bad > impact > on the end user. > > If we consider collaborative solutions, we see that, because of their very > nature, they cannot cover all cases. So, it is safer to look for > collaborative > solutions that allow unmunging than to solutions that avoid munging in the > first place. Indeed, in the former case the risk is to deliver a munged > message, while in the latter one the risk is to either not deliver or not > to > implement DMARC. > > Even ARC can be turned into a method to unmunge. It requires > collaboration > between MLM and receiver. My unmunging method requires cooperation > between > author's domain, MLM, and receiver. Whitelisting can be done unilaterally > by > receivers, who can restore the original From: without validating the > author's > domain signature, just because they trust the MLM. By collecting similar > techniques, we might be able to cover almost all cases while still > ensuring > deliverability. > > > Best > Ale > > > > On Tue 12/Oct/2021 04:40:12 +0200 Douglas Foster wrote: > > 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 <[email protected]> > > 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 > >> <[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 > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
