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?!?
This approach is reminiscent of DMARC's original stance on multiple
From: mailboxes. Those uncommon messages are out of the spec.
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.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
