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.
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]
