On Thu, Nov 12, 2026 at 10:28 AM Pete Resnick <resnick= [email protected]> wrote:
> On 11 Nov 2026, at 11:04, Emanuel Schorsch wrote: > > On Wed, Nov 11, 2026 at 8:09 AM Pete Resnick <resnick= > [email protected]> wrote: > > I basically agree with both Pietro and Richard here: I suspect that in the > end, common practice is going to be "If the change recipe only modified the > Subject and added a minimal (amount TBD) to the end of the body, then by > policy I'll accept the message without a change to the From. Otherwise, by > policy I'm going to bounce it unless I have a pre-existing trust > relationship with the intermediary who did it." This is why I think the who > discussion of From alignment and donotmodify is really kind of moot and not > worth mentioning in the spec: If the changes are deemed to be "minimal", > then the end system is going to let it through, and if the changes are more > than "minimal" (which would include absolutely any deletion of bits of the > body) by an unknown intermediary, they'll be rejected, regardless of a > donotmodify or canmodify flag. > > Pete I agree with you that that seems like a likely prediction. That seems > like a chaotic and unpredictable arrangement. Isn't it better to have a > consistent way of handling it? If p=none or canmodify then do whatever you > want. If p=quarantine/reject then munge the fromHeader when making changes. > If the receiver considers them minimal then they'll undo the fromMunging. > If not, they'll leave the from unmunged. This seems better than the > receiver rejecting the mail entirely if the changes are too large. > > Pete, can you share more on what you consider the downside of that > approach? > > [Again, this part not as chair; obviously if the WG disagrees with this, I > make the call as chair that I am myself "in the rough".] > > Let's call the downside "the Yahoo problem" (sorry Richard). Back when > Yahoo implemented p=reject, it wasn't because they really wanted to > disallow people posting to non-modifying mailing lists or going through > alumni forwarders. It was because p=reject seemed like the "most secure". > And everybody else followed suit, and we are no in a world where a bunch of > very useful functionality is very broken. My guess is that if we continue > the practice of allowing senders to say donotmodify (or the equivalent) and > having receivers blindly follow that instruction, that's exactly what most, > if not all, senders are going to do. The result will be that we will not > have solved the problem that DKIM2 was (in part) designed to solve. > I'm more positive than you, Pete, that if there is a "donotmodify" flag, its usage will be modest, because originators will want their users identified as the author rather than attributed to the forwarder. The proposal would recommend (SHOULD) that the From header field be unmunged through forwarding, without modifications and with modifications if they are simple and relatively safe. As you mentioned, a Best Common Practice could limit unmunged From addresses to simple safer scenarios. Such limited scenarios could be defined as: 1) simple, modest additive changes to the Subject (e.g., prefix) or to the Body (e.g., footer); 2) the addition does not obscure the original content (e.g., unicode hacks). When the "donotmodify" flag is present, the forwarder MUST From munge if modifications are present. Subsequent receivers can validate this and reject messages that don't follow this guidance. Despite this, such a flag is really a hint requested by the originator, and the sender can't fully control what forwarding relays will do. However I think the originator would still rather have some say in the identity of their message than the alternative where it's completely up to the MUA to decide what to do. A couple of other observations. As noted already, mailing lists and others today do From munging when they break the DKIM signature due to DMARC. DKIM2 senders will also support DKIM behavior for a while; From munging will also continue. Things like DMARC reports might make it possible for senders to identify when the ecosystem is safe enough to revert to an unmunged From address. Despite agents making it easy for the MUA to unmung the From address in the UI, I suspect many enterprises won't have that convenience, and will have to live with various legacy systems that depend on the From header field and cannot be updated. The current From munging patterns confuse these systems, which is part of the current friction. To me that use case still remains an important motivation for supporting unmunging. A flag can distinguish those scenarios vs the "IRS" scenarios that Emanuel mentioned. Lastly there needs to be a standardization of the proposed dkim2History so that 3p MUAs can work with Mailbox Providers. -Wei > It seems more consistent and given the unpredictability of receivers > handling will make a more robust overall delivery system with fewer > unexpected sharp edges. > > Here, I think "consistent" and "predictable" turn out to be the equivalent > of "make the code easy at the expense of functionality for the end user." > When you have to do From munging, it means that the intermediary has to be > responsible for forwarding replies. It means that the receiving user gets > their address book screwed up because instead of "Pete Resnick > [email protected]" appearing in their address book, they get "Pete > Resnick [email protected]" in their address book. > Etcetera. A look at the IAB's RFC 8890 is worth it. > > I understand the downside of receivers needing to update their code to do > fromUnmunging but as Richard has pointed out given LLMs this is an easy > change for receivers to make and goes along naturally with needing to add > logic to decide what modifications the receiver considers acceptable. > > Two things on this: 1) It seems highly likely that (even if it's easy) > receivers will not update their code to do fromUnmunging because doing that > requires them to also evaluate the message and see whether it really is > worthy of being unmunged, something that you've already claimed is > unpredictable, chaotic, and leaves unexpected sharp edges. I don't think it > is as bad as you say it is, but I think receivers are likely to come to the > same conclusion that you did and refuse to unmunge. 2) Unmunging is a good > bit of work. I think we can come up with a much simpler set of principles > for an anti-spam mechanism to use along the lines of "bounce anything more > than minimal additions to bodies and prefixes to Subjects" that are easier > to implement and maintain the functionality that is desirable. > > Now, with my chair hat momentarily on: I do want to remind folks that the > charter says: > > - There is a desire to maintain validation of a message's signing > identifier across common transit and forwarding modifications. When a > message goes through a re-posting, such as through a mailing list, the > validation signature typically does not survive and cannot be recovered. > Fixing this would permit a more robust evaluation of the message. > > You could make the argument that signing the munged From addresses that > bullet, but I would say that some folks would find that a "surprising" > outcome and not really in the spirit of what that bullet intended to > accomplish. > > And while RFC 8990 is not a BCP, the IESG does often take the advice of > the IAB. > > pr > > -- > Pete Resnick https://www.episteme.net/ > All connections to the world are tenuous at best > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
