On Sun, Mar 23, 2025, at 04:53, Michael Thomas wrote: > > > I'm about half way through the audio session and just finished the rationale > for a single rcpt-to. I'd like to turn that rationale on it's head: if this > is pretty much the way the world operates now (which I have no reason to > doubt), why are we going out of our way to codify it with as a protocol level > MUST? >
Because this new protocol (if done the way I've written it up so far) creates a new protocol element which either needs to be single-valued or multi-valued. Making it multi-valued has many more failure modes and adds complexity to every entity which needs to interact with compliant messages forever - so if we can encode it as a single-value mandatory field then we simplify almost all cases. BUT - as I said in the session; there is the alternative argument (particularly supporting the corporate environment where many people are in the To/Cc on large messages and you could get both delivery and maybe storage benefits from sending identical messages) for allowing multiple "rcptto" addresses for parties who are already allowed to know of the existence of each other. If the working group chose this path, I'd want a very prominent security considerations along the lines of "if you f*($ this algorithm up you'll leak BCC'd people's identities to each other". Having a singleton "rcptto" address baked into the protocol means it's much harder and less likely to have a bug leak privacy data. And I believe in designing for the majority case and for greater safety, which is why I favour the single rcptto case. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
