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? It seems more consistent and given the unpredictability of receivers handling will make a more robust overall delivery system with fewer unexpected sharp edges. 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. Best, Emanuel
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
