On 25/10/2025 4:20 pm, Bron Gondwana wrote:
On Fri, Oct 24, 2025, at 22:09, Inveigle.net <http://Inveigle.net> wrote:> 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.
I'm not sure what you're referring to with my "arguments about not even
including the destination address". rt=? This information would be added
to the headers when the bounce was generated (or any other terminal
condition).
It's not immediately clear how your proposal addresses the issue.
The motivation document indicates a requirement for the full set of
headers to be included in a bounce message (optional per RFC3462), but
as the rt=, mf= and dd= or nd= tags are all signed along with a hash of
the now non-existent body, it is impossible to verify the the chain of
custody even with the full set of headers. It leaves open the potential
for a malicious actor to send bounces back up the chain and even
manipulate the chain if the intermediary either doesn't or cannot store
additional state information regarding the routing of every instance of
every message they handle.
My proposal closes that hole and eliminates the need for the host to
store message state, by allowing the receiver of a bounce to
cryptographically verify the path a message has taken from itself, to
the server that generated the bounce and back again, regardless of the
path taken in either direction.
My previous e-mail may have been a little unclear in that regard - it
referred to sending to multiple hosts that could verify to the best of
their ability (which will vary both by implementation and approach)
rather than emphasising the added accountability.
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.
This is as per RFC5321. If implementations are not performing the simple
task of rewriting MAIL FROM to satisfy those requirements, they are
unlikely to implement a system that is significantly more complex.
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.
Is a 'hop' not simply a transmission between servers? If so, then I
don't see how this could work given the requirement for each hop to sign
with a matching mf= and d=.
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.
It requires a tiny bit more work than my proposed RCTP TO extension,
because it needs a copy of the added DKIM2-Signature to include in the
signed hash. Overall, it would take minimal effort to implement with the
changes being isolated to very specific functions. The additional work
(less work in my view) would be more than justified if it means bounces
can be verified and traditional mail flow preserved.
Regards,
R. Latimer
Inveigle.net
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
