On Fri, Oct 24, 2025, at 22:09, Inveigle.net wrote: > The only technical limitation to overcome is filters would need to be > able to update RCPT TO.
I considered this at an early stage of design, but rejected it because it required updating a LOT more email handling software in order to work at all. I have both technical and practicality objections to your proposal: *Technical:* if you sign multiple RCPT-TO values without specifying them in the content which is passed on to later hops then: a) the later hops can't see why the email came to them via this path, which I contend they have a right to know. If you're included in an alias expansion, you should know what the alias is! (I have a solution to this which would be OK except that) b) it doesn't allow splitting the RCPT-TO; you'd have to sign on-the-fly and split and re-sign if the destination server restricts the number of recipients per message. And any currently fully transparent secondary MX would have to then either sign, or forward all recipients as a single transaction to the same destination. I could imagine an MX which separates incoming email into multiple different subsystems despite the addresses being at the same domain, and this system would not handle that at all. *Practicality: *Even if the technical issues above were all solved, this requires changes to a LOT more software. Every piece of software which handles mail needs to be aware of this, rather than only the edges between systems with separate ownership or domains of trust. All this, just to protect against exposing information which is either already present in the To/Cc headers, or is explicit to the single destination if it's a BCC. > > == MAIL FROM: Eliminating pp=/nd= and Preserving Bounce Integrity > > DKIM2 proposes changing MAIL FROM between hops. Once again, this > represents a significant change in mail flow and appears completely > unnecessary to achieve all but one of the stated objectives, which > itself represents a minor edge case. Disagree that being able to safely send bounces without the risk of backscatter is a "minor edge case", > The original MAIL FROM should be preserved and bounce notifications > should be sent directly to any domain that requests them via their > DKIM2-Signature. Sending messages back up the chain only introduces > multiple points of failure and prevents the necessary information > getting back to those who depend on them for general housekeeping. How many times have you received bounce messages from a random member of a mailing list? Yeah, me too. I want the bounces from the recipients of the mail I sent, not bounces for every ongoing expansion it has had at hops that I don't control. Intermediate systems which forward mail should take responsibility for making the right choice about bounces in my opinion. AND - if you allow arbitrary machines can send bounces then you can fraudulently (particularly with your arguments about not even including the destination address) create a bounce for any message you can see a copy of; signing it from a domain you control and pretending that the message was sent legitimately to that domain. A major point of DKIM2 is to close the holes where systems can pretend that they were intended to receive an email. > The DKIM2-Signature flags could also be extended to allow relays to > request specific types of notifications. That's a potential enhancement > I think is worthy of further discussion. There's already a mention of this in the current header draft, but I'd be very happy to discuss the form and structure of a more extended set of notification requests. > Sending bounces to all verified parties that request them would > partially mitigate the problem of ESPs changing MAIL FROM as a means to > track bounces. Their doing so precludes the use of VERP to track > failures or for other purposes by the original sender and has the > unfortunate side effect of keeping bad addresses in mailing lists unless > removed through the proprietary mechanisms ESPs may provide. ESPs would > also benefit from simplified customer setup. I think we're in agreement with the goals here. Sending bounces up the chain gets you this explicitly and exactly. > RFC5321 requires MAIL FROM to be rewritten for on-sending to an alias or > list. Correctly implemented, there should be no backscatter to the > original MAIL FROM address. The argument for improved privacy forwarders > is therefore only in support of a minor edge case that exists due to > non-compliance with RFC5321. "Correctly implemented" is doing a lot of heavy lifting here. My argument is that no system should be able to sign something with a MAIL FROM that they don't control. They need to change if it they're changing the recipients, and take responsibility for bounces from those newly added recipients. A system which doesn't change the recipients, and doesn't change the content of the message, can of course keep sending it without changing the MAIL FROM, because it will still pass all the checks. > In order to verify the chain of custody and avoid editing the e-mail > each time an attempt is made to send it, the signed value would be added > to the headers by the DKIM2 filter on the receiving server, which is > already privy to MAIL FROM information. This could be inserted directly > into the next DKIM2-Signature generated by that host, resulting in > bi-directional signing of the chain of custody without adding additional > headers. No or minimal changes to filter capabilities would be needed in > order to support this. Having the receiver add the information to the > headers rather than the sender allows the signature to be added after > decisions regarding routing are made (potentially days after the DKIM2 > signature is generated) and limits the scope of changes required to > implement the DKIM2 ESMTP extension. This could work (I was even suggesting sending rewrites along that chain that would be deferred to machines on the edge of the DKIM2 network in my earliest ideas about this), but that's an even bigger and more complex lift and I don't believe it adds privacy improvements sufficient to justify the added complexity. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
