I don't think DKIM2 helps at all in that case. A sender is well within their rights to put in a new header that specifies the set of recipients for the message, if they were so inclined. And that's assuming the recipients aren't already listed in destination address headers (To/Cc) which seems to be the case in the linked example.
Having all recipients listed in a DKIM2 signature's rt= tag gives no more guarantee that the signer actually did what it claimed it was going to do than any other header. In the case of having a single recipient in the rt= tag, there's no advantage to claiming that a message is being sent somewhere other than the 821.To for that transaction, since the receiving server is expected to treat this as not DKIM2-authenticated. On Thu, Mar 20, 2025 at 12:48 PM Alessandro Vesely <ves...@tana.it> wrote: > 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 >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
