Some comments - splitting the message up can lead to different understanding of the recipients of the message and their relationship to the sender. Outside of that you are right that we do try and handle the message as single item in several places for various reasons.
For outbound it may well be the nature of the enterprise mail vs consumer. Would be good to dig into the broader comment on complexity, sending them singularly will add a complexity in other areas, adding a common way to enable multiple recipients means that we don't have to break the way systems operate today, and we can still achieve the goals. Regards, Ross. From: Dave Crocker <[email protected]> Sent: Monday, July 21, 2025 3:14 PM To: Ross Adams <[email protected]>; [email protected] Subject: [EXTERNAL] Re: [Ietf-dkim] Re: Multiple RCPT-To and line based deltas You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hi, Ross. Thanks for the note. Inline... On 7/21/2025 8:27 AM, Ross Adams wrote: Late to the discussion on this but in an enterprise environment the number of messages with more than 1 recipient is much higher and you can't assume that there is only 1 recipient on a message. Splitting a message up that has multiple recipients will lead to issues with how those messages are processed. I assume that is for a style of handlingmessage that ships pointers around, more than complete messages, along the lines of shared, database orientation that has long been common among closed (enterprise) email systems? This is also true in the outbound path for enterprise mail where there is a high percentage of messages that have more than 1 recipient. For email traversing the open Internet, that assessment is quite different than was consistently reported here, in the working group. I understand the need to ensure that we protect the BCC recipients, While BCC issues have been referenced, I believe they are largely irrelevant to this topic. BCC typically get a separate posting from 'regular' recipients, so they can include a BCC header field (with or without an individual recipient address. I believe the larger issue is design complexity to support multiple recipient signatures in the message itself, as well as the concern for maintain privacy of addressee information. (e.g., not showing alias mapped addresses.) Adding that complexity when it apparently is not useful except for edge condition, and then only marginally improves efficiency, rather than enhancing functionality, is not an especially good idea for a global, operational standard at scale. but I do think there are other ways of ensuring we protect against DKIM replay, ensure we can validate on return path without needing to move to a single recipient per mail. Based on the extended discussion that took place in the working group, everyone commenting (before your posting) said they see very nearly no mail with multiple SMTP RCPT-Tos. So, in practical terms, the observation was that the Internet has already moved to single SMTP recipient per SMTP session. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net bluesky: @dcrocker.bsky.social mast: @[email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
