Looking at a tiny subset of mailman based lists currently in my inbox I see a couple different things.
This list (mailman): rewrites From, puts ‘Original-From’ in the headers, does not have a Reply-To address configured (either the original author or the list). Another list (mailman): rewrites From:, does not put any indication of what the original was, does have a Reply-To: address configured to point to the unmunged author address. Another list (mailster): rewrites From:, does not put any indication of what the original was, does have a Reply-To: address configured to point to the unmunged author list. It strikes me that these fields (Original From, Reply To, Original Author) may be used rather than unmunging as well. laura > On 12 Oct 2021, at 11:04, 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 -- Having an Email Crisis? 800 823-9674 Laura Atkins Word to the Wise [email protected] (650) 437-0741 Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
