Participating: On Wed, Mar 26, 2025 at 3:04 AM Alessandro Vesely <ves...@tana.it> wrote:
> >> In this strawman, the "rt=" single recipient construct is meant to > support > >> Bcc and other privacy sensitive cases where it only makes sense to have > a > >> single recipient. Declaring multiple recipients that are not privacy > >> sensitive is done through RFC5322 address headers. As you point out, > it's > >> easy to extend it to also support multiple recipients. The advantage > of > >> the approach you propose is that the signed recipient list is > conveniently > >> in the DKIM2-Signature "rt=" and can better represent the recipients > that > >> will be in the SMTP envelope. The advantage of the approach of using > the > >> RFC5322 address headers is that they are already there without > duplication > >> of the addresses. > > > > Two other considerations. > > > > First a way to view the pros and cons for single vs multiple recipients > is > > the implementation tradeoff. Single recipients will require additional > > message splitting by recipients. Multiple recipients will require > signing > > and verifying envelope recipients in the message header somewhere, be it > in > > the "rt=" or in the RFC5322 address headers. Which of these is easier > to > > adopt by open source DKIM and SMTP packages? Might splitting all > > recipients be a simple config already in those open source SMTP? > > > > Second is a smaller worry about the effects of a long DKIM2-Signature > > header. If the "rt=" lists all envelope recipients, what is the effect > of > > the maximum number of recipients possible e.g. Gmail supports > > <https://support.google.com/a/answer/166852?hl=en> up to 2000 > recipients. > > I would imagine this reduces readability. > > Looks good. It's very elegant because by making rt= optional, it > minimizes the surface differences with DKIM1. > > However, I'd still allow multiple rt= recipients, in case forwarders > resend messages to multiple recipients at a time. AFAIK, most or all > mailing lists send single messages, otherwise they couldn't do VERP, but > I'm not sure it's a universal rule. One of the drafts I wrote about this previously proposed including all of the recipients in the hashed content fed to signing without adding them as a tag. That still binds the signature to a specific set of (one or more) recipient(s) without making them visible, possibly revealing a private Bcc, although as Jim correctly pointed out, you can still do brute force attacks to figure out to whom the message was addressed. -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
