On Wed 19/Mar/2025 17:22:06 +0100 Michael Thomas wrote:
On 3/18/25 12:30 PM, Richard Clayton wrote:
In message <746bd827-77d0-4991-ba67-507d84566...@mtcc.com>, Michael
Thomas <m...@mtcc.com> writes
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
I dunno, if the To: header is all to the same domain, say, and they match the
rcpt-to like with an email conversation, you know that it's safe to group
them.
when you get to SMTP time you may find that you are sending multiple
emails (because of limitations on RCPT TO counts) and those emails may
not go to the same server ... so how is the recipient going to do any
sensible assessment of whether a replay has occurred ?
The point here is that if an implementation can figure out how to do that, the
implementation should have that option. If the easiest way is to just do single
address rcpt-to's, that's fine but it doesn't require a protocol level MUST to
forbid multiple addresses on the rcpt-to. It would be fine to add some
informative text as to why a single address is easier, but it doesn't need to
enforced at the protocol level.
Accommodating multiple recipients in the signature would have the added value
of confirming to whom a message is destined. There are companies that need to
certify to each recipient who the other recipients of a message are. A real
case, for example, is described here:
https://sourceforge.net/p/courier/mailman/message/16554252/
An MTA may want to offer this capability as a feature.
A receiver only needs to check that the envelope value(s) are /included/ in the
signed rt=. It is not much more difficult than comparing single values.
The only drawback, AFAICS, is that when a message with multiple recipients is
forwarded by a non-DKIM2 agent, or replayed, the final recipient cannot
determine which one of the signed recipients is the culprit.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
