On Wed, Jun 4, 2025, at 05:42, Alessandro Vesely wrote: > On 03/06/2025 23:08, John Levine wrote: > > It appears that Alessandro Vesely <[email protected]> said: > >> This may be the norm in discussions, but in practice it is not. I just > >> sent a message from Gmail to three of my addresses, two on tana.it and the > >> third to a different domain > >> with the same MX. The were received in *two* transactions, not three. > >> The copy sent to a different domain even arrived via a different host, but > >> the two copies to the same > >> domain were sent in one transaction. > > > > If you review the very, very, lengthy discussions on this topic, you will > > find that > > we all agree that the vast majority of SMTP deliveries are to a single > > recipient, > > on the order of 99%. Even though it is *possible* to do multiple > > deliveries, it > > is uncommon. > > > So it wouldn't be a problem if such uncommon messages were not signed?!?
Unfortunately this would create a giant backdoor through which spammer would now drive, either meaning that they get away with spam, or by association they cause all such messages to get treated as much spammier. We can't create a solution which allows legitimate messages to be not signed, or we're not creating something useful enough. > This approach is reminiscent of DMARC's original stance on multiple > From: mailboxes. Those uncommon messages are out of the spec. Is that a thing? A message with multiple "From"? https://www.rfc-editor.org/rfc/rfc6854.html Hmm, OK - it got relaxed in 2013, however rfc5322bis says that if there are multiple addresses in "From" then there must be a single "Sender". That's pretty different from the idea of email with multiple recipients which is much more common. And the `mf=` header data is really the bounce address, and doesn't have to be the same as the `From:` or `Sender:` header, it just has to be domain aligned with the DKIM2 signature domain. DKIM2 doesn't care what the `From:` header says from a mechanical standpoint - it just cares that there is a return address and the return address is aligned with the signing domain so the signing domain is taking responsibility for handling the bounce. > > > Hence believe that if we required single deliveries, the amount of extra > > traffic would > > be very small. This is not a new argument. My mail system uses qmail > > which has been > > doing single deliveries since 1998 and it has always worked well. > > > I agree the amount of extra traffic /on the wire/ would be minimal. > However, the amount of extra gimmick a mail filter might have to do to > comply is significant if the signing occurs before the MTA starts > individual deliveries. This message, to you and to the list, will > obviously be transmitted in two sessions to different hosts, but it will > be signed before either connection is considered. > > And then, the only reason to /force/ single deliveries is Bcc:, as Bron > admitted. As far as commonality goes, Bcc:'s (excluding internal ones > to save a copy in the Sent folder) are much more uncommon than messages > with multiple recipients. Since it's about controlling recipients, > requiring special treatment for Bcc: seems to me to be way more > acceptable, from a programmer viewpoint, than forcing single recipient. >From a programmer's point of view, yes. I'm not 1000% sold that we MUST >restrict to a single rt=; there's nothing in DKIM2 that would really require >it (though any domain in any rt= could then forward the message to anyone >else, but that's already true). BUT - from a bug programmer's point of view (and let's face it, we've all written bugs) - it's much easier to accidentally leak private data by including multiple rt= fields for different people who aren't supposed to know about each other. When that's stored in a signed field, that's a privacy leak that you'd just rather not risk creating by making it easy to do so. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
