On Sun, Mar 23, 2025, 7:13 a.m. Alessandro Vesely <ves...@tana.it> wrote:
> 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. > That works if all recipients in a single domain are included in a single transaction. There's no way to guarantee that in general, so interpreting "address not listed in DKIM2 rt=" as "address didn't get a copy" seems flawed. And it doesn't provide any signal at all for recipients across domains. There's also the possibility of a multi-recipient transaction rejecting some recipients. This makes assuming that the DKIM2 rt= list and the 821.To list are equivalent (after sorting+canonicalizing) a little bit brittle. So we either accept signatures where 821.To is a subset of rt=, which removes the property that an address being listed means that address received the message, or reject and retry, which seems like it would need delicate handling to not get stuck permanently. > > 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. > I assume these filters already have to take into account that receiving servers may have upper bounds on a transaction's recipient list. Configuring that upper bound to be one instead of whatever it is today doesn't seem like a hack to me. Admittedly I don't have experience with a broad set of mail implementations, but Exim does support configuring this at least. There may still be some filter hackery needed to figure out what the SMTP splitting would look like while generating the signature(s), but I think that's likely independent of whether or not DKIM2 imposes a lower limit than would otherwise be used. > > 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. > It's very reasonable for people to consider this potentially disruptive. We will need to have documented rationale for why DKIM2 requires this limit. > > 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 >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
