On Mon 17/Mar/2025 20:08:04 +0100 Richard Clayton wrote:
In message <af5f8fd7-32d8-4e16-b806-10510da14...@mtcc.com>, Michael Thomas
<m...@mtcc.com> writes
On 3/16/25 5:34 PM, Richard Clayton wrote:
PPS: I'm don't understand why this requires the rt= to be limited
to just one address.
simplicity ... at the point at which an email is being signed it is not
possible to know how many recipients the receiving MTA will accept after
each MAIL FROM
Why is that "simple"?
because if you don't know which recipients will be grouped together you
cannot construct the rt= part of the DKIM2 header field. It also avoids
the MTA having to assess which recipients are only bcc'd
so one recipient, one email, one signature
I agree that is simple.
However, what if the signer is confined in a before-queue filter slot of a
DKIM2 unaware MTA? Might it have to delete the current message and re-submit
new messages, one for each rcpt? Besides single-recipient an unaware MTA
wouldn't handle DSNs properly.
A DKIM2 aware MTA would call the signing filter after it has seen the remote
MX's greeting line but before issuing the DATA command. In this case,
recipients are already grouped. Depending on the MTA's design, they have been
divided in "compatible" groups. Bcc'ed recipients have to be singled out
anyway. For simplicity, an MTA can decide to do a transaction —and a filter
call— for each single recipient anyway. But it wouldn't be difficult to do
otherwise, since most of the code is already there.
A reason why the protocol may want to always force single recipients is that,
in case of forwarding, new recipients will know who triggered it.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
