Another way to help resolve this might be to get feedback from the folks working on RFC5321/2bis documents. Presumably this is the emailcore working group. How about we Cc some condensed form of this thread there? Or email directly John Klensin?
Also I noticed that my formatting doesn't play well with the IETF list archive. Just resending w/o the formatting: ===== This note hopes to clarify the current discussion on DKIM2 signing for a single recipient vs multiple recipients, by identifying how each approach might work, and validation steps involved. From this we can identify the pros and cons of the two approaches. Single RCPT TO recipient signing has been described in draft-gondwana-dkim2-header and draft-gondwana-dkim2-motivation. We have not discussed how multiple recipients might work but it shouldn't be too hard to extend the current approach to support it. SINGLE RECIPIENT The drafts draft-gondwana-dkim2-header and draft-gondwana-dkim2-motivation describe a single recipient that is declared and signed for in the "rt=" tag of the putative DKIM2-Signature header. Upon delivery, the receiver can then check the signed for address against the RCPT TO address to check for replay. This can help discourage replay by requiring each recipient to be signed by the sender thereby identifying the party that is sending the potential spam. As Richard and Bron mentioned, this approach protects the privacy of Bcc recipients by splitting all traffic so that To, Cc and other Bcc recipients are not aware of the Bcc recipient. It is simpler in that it only compares a single address. Example: Sender: header: DKIM2-Signature: rt=u...@example.com SMTP RCPT TO: u...@example.com Receiver action: Compares RCPT TO address to rt= address. Pros: * Simple single address comparison for the receiver * Mandates Bcc privacy Cons: * Implementations MUST split multiple recipient messages to single recipient * Restricts SMTP RFC5321 to a single RCPT TO to support DKIM2 MULTIPLE RECIPIENT To support declaring and signing multiple recipients with DKIM2, we might consider where we can declare these recipients in the RFC5322 message that are then DKIM2 signed. While one place might be to support multiple recipients in the DKIM2-Signature "rt=" tag, another place is just simply use the RFC5322 headers i.e. To, Cc, Bcc, Resent-To, Resent-Cc, and Resent-Bcc. The former three are generated at message origination, while the latter three are generated at message forwarding. This does add complexity though but not that much more. It will require a validating receiver to gather into a set of signed sender-declared recipient addresses to be validated against the actual RCPT TO recipients. This also requires that these headers are signed, which the DKIM2 motivation proposes making mandatory and at the receiver validating this. (The example below uses DKIM1 style h= though this may change with DKIM2) Security Considerations in RFC5322 already call out the need for care when maintaining privacy of Bcc recipients and notes that the Bcc header need not be present. To support that use case and other scenarios where the recipient is not explicitly declared in the RFC5322 message e.g. some mailing lists, the sender can populate a DKIM2-Signature "rt=" tag. Note that "rt=" here still only supports a single recipient. Sender Example:: header: To: user....@example.com Cc: user....@example.com DKIM2-Signature: h=to:cc SMTP RCPT TO: user....@example.com RCPT TO: user....@example.com Receiver action: Verify that the RCPT TO address set is a subset of the declared and signed addresses set parsed from the To and Cc headers Mailing list example- forwarding where the expanded recipient is not explicitly declared in the message: header: To: mailingl...@example.com DKIM2-Signature: rt=user.three@forwarded.example; h=to SMTP RCPT TO: user.three@forwarded.example Pros: * Much more closely maintains RFC5321 semantics imposing much lower requirements on senders to support splitting the message (and perhaps no new work?). * Supports Bcc privacy Cons: * Some increased complexity to gather the signed recipients and verify that the actual recipients are a subset of the declared recipients. -Wei On Mon, Mar 24, 2025 at 11:02 AM Wei Chuang <wei...@google.com> wrote: > This note hopes to clarify the current discussion on DKIM2 signing for a > single recipient vs multiple recipients, by identifying how each approach > might work, and validation steps involved. From this we can identify the > pros and cons of the two approaches. Single RCPT TO recipient signing has > been described in draft-gondwana-dkim2-header > <https://datatracker.ietf.org/doc/draft-gondwana-dkim2-header/> and > draft-gondwana-dkim2-motivation > <https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motivation/>. We > have not discussed how multiple recipients might work but it shouldn't be > too hard to extend the current approach to support it as a strawman. > Single Recipient > > The drafts draft-gondwana-dkim2-header > <https://datatracker.ietf.org/doc/draft-gondwana-dkim2-header/> and > draft-gondwana-dkim2-motivation > <https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motivation/> > describe a single recipient that is declared and signed for in the "rt=" > tag of the putative DKIM2-Signature header. Upon delivery, the receiver > can then check the signed for address against the RCPT TO address to check > for replay. This can help discourage replay by requiring each recipient to > be signed by the sender thereby identifying the party that is sending the > potential spam. As Richard and Bron mentioned, this approach protects the > privacy of Bcc recipients by splitting all traffic so that To, Cc and other > Bcc recipients are not aware of the Bcc recipient. It is simpler in that > it only compares a single address. > > Example > > Sender: > > header: > > DKIM2-Signature: rt=u...@example.com > > SMTP > > RCPT TO: u...@example.com > > Receiver action: > > Compares RCPT TO address to rt= address. > > Pros: > > - > > Simple single address comparison for the receiver > - > > Mandates Bcc privacy > > Cons: > > - > > Implementations MUST split multiple recipient messages to single > recipient > - > > Restricts SMTP RFC5321 to a single RCPT TO to support DKIM2 > > Multiple Recipient > > To support declaring and signing multiple recipients with DKIM2, we might > consider where we can declare these recipients in the RFC5322 message that > are then DKIM2 signed. While one place might be to support multiple > recipients in the DKIM2-Signature "rt=" tag, another place is just simply > use the RFC5322 headers i.e. To, Cc, Bcc, Resent-To, Resent-Cc, and > Resent-Bcc. The former three are generated at message origination, while > the latter three are generated at message forwarding. This does add > complexity though but not that much more. It will require a validating > receiver to gather into a set of signed sender-declared recipient addresses > to be validated against the actual RCPT TO recipients. This also requires > that these headers are signed, which the DKIM2 motivation proposes making > mandatory and at the receiver validating this. (The example below uses > DKIM1 style h= though this may change with DKIM2) Security Considerations > in RFC5322 already call out the need for care when maintaining privacy of > Bcc recipients and notes that the Bcc header need not be present. To > support that use case and other scenarios where the recipient is not > explicitly declared in the RFC5322 message e.g. some mailing lists, the > sender can populate a DKIM2-Signature "rt=" tag. Note that "rt=" here > still only supports a single recipient. > > Sender example: > > header: > > To: user....@example.com > > Cc: user....@example.com > > DKIM2-Signature: h=to:cc > > SMTP > > RCPT TO: user....@example.com > > RCPT TO: user....@example.com > > Receiver action: > > Verify that the RCPT TO address set is a subset of the declared and signed > addresses set parsed from the To and Cc headers. > > Mailing list example: forwarding where the expanded recipient is not > explicitly declared in the message: > > header: > > To: mailingl...@example.com > > DKIM2-Signature: rt=user.three@forwarded.example; h=to > > SMTP > > RCPT TO: user.three@forwarded.example > > Pros: > > - > > Much more closely maintains RFC5321 semantics imposing much lower > requirements on senders to support splitting the message (and perhaps no > new work?). > - > > Supports Bcc privacy > > Cons: > > - > > Some increased complexity to gather the signed recipients and verify > that the actual recipients are a subset of the declared recipients. > > > > -Wei > > On Mon, Mar 24, 2025 at 7:15 AM Murray S. Kucherawy <superu...@gmail.com> > wrote: > >> On Sun, Mar 23, 2025 at 5:06 PM Michael Thomas <m...@mtcc.com> wrote: >> >>> On 3/23/25 4:47 PM, Murray S. Kucherawy wrote: >>> >>> The reason I keep harping on this is that I don't understand the value >>>> of picking fights that need not be picked, cf the advice in 5321 that Barry >>>> brought up. I doubt I will be the only person who reads this and have alarm >>>> bells going off about changing the email architecture, and why it's >>>> necessary. >>>> So if it's really such a marginal problem why are we spending a lot of time >>>> requiring a change that doesn't seem like it needs to be mandated? >>>> >>> >>> I don't see it as changing the email architecture. >>> >>> At the SMTP level, use of multiple recipients on common content can >>> still be encouraged, in the same way that SMTP itself is insecure. But on >>> the modern Internet, you basically have to use STARTTLS if you want to talk >>> to anyone. EMAILCORE has settled on the notion that SMTP doesn't need to >>> say that, but an Applicability Statement does. That's in development now >>> in that WG. (There's a massive thread cluster over there if you care to >>> read about the relevant debate.) >>> >>> That's basically what I was trying to say. We can recommand and give the >>> reasons why it's a good idea to do a single rcpt-to without mandating it >>> with a MUST. The microscopic amount of traffic that actually uses it can >>> still work with DKIM++ and the vast majority of traffic does it already >>> anyway. It's been really confusing why it was turned into a MUST like there >>> was some underlying security reason. >>> >> >> I think there's a difference between saying "all mail MUST now be sent >> single-recipient" and "if you are participating in DKIMbis, you MUST send >> single recipient". I don't think anyone is saying the former, and in fact >> would argue that doing so violates our charter. But I believe the latter >> is fair game. >> >> >>> DKIM++, by the same token, doesn't have to directly challenge the >>> "multiple recipients" guidance of SMTP. Instead, it can say, "If you want >>> to get your mail through modern authentication barriers, multiple >>> recipients are incompatible with that goal". >>> >>> Oh DKIM++, I think I can get behind that. Sort of register deferred, >>> post increment on the header vs update debate :) >>> >> >> I think I'm just trying different names until something sticks (and, of >> course, it's clear which path we're following). >> >> -MSK >> _______________________________________________ >> 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
