On Thu 20/Mar/2025 19:54:02 +0100 Allen Robinson wrote:
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.
A DKIM2 verifier can only verify consistency for recipients in the transaction
in question. In the linked example, if all recipients are in the same company,
addressing them all in a single transaction could make it possible for the
receiver to verify that they were all properly addressed. A feature not (yet?)
considered for DKIM2.
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.
Agreed. For non-DKIM2 receivers it doesn't matter.
Another argument for allowing multiple recipients is the consideration of what
kind of hack a filter needs to employ to force a single-rcpt transaction. This
is still necessary for Bcc:, although a special provision could be made for
internal Bcc:s, such as Bcc: to themselves, which do not need verification.
However, in some cases, the ability to use multiple recipients can actually
simplify implementation.
Yet another point, purely psychological, is that a protocol that doesn't impose
single-rcpt transactions will certainly be considered less disruptive to SMTP
than one that does.
Best
Ale
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
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
