On Thu 12/Jun/2025 05:41:53 +0200 Bron Gondwana wrote:
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. They
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.
Agreed.
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.
As you noted, designing for commonality would not lead to anything "useful
enough". In fact, dmarcbis treats the multiple From case as a possible attack
vector, and states:
However, in a case where a Mail Receiver requires that the message
be subject to DMARC validation, a recommended approach as per [RFC7489]
is to apply the DMARC mechanism to each domain found in the RFC5322.From
field as the Author Domain and apply the most strict policy selected
among the checks that fail.
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis#section-11.5
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.
Fine. The responsibility concept overlaps with that of SPF "pass".
https://www.rfc-editor.org/rfc/rfc7208#section-8.3
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).
Wei convinced me that there must be at most one rt=, because, he said, the
official recipients, To: and Cc:, do not need to be repeated in rt=. They are
already signed and delivery to them is due. rt= is only needed for Bcc: and
forwards (which can be thought of as Bcc:). This way, there must be at most
one rt=, but there may be none.
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.
Sure. However, bugs occur more often when the task at hand is more
complicated. Depending on the system, a mail filter may need to sign messages
before enqueuing them. Recipients have already been determined by then, so to
handle Bcc: one must remove the recipient from the envelope and then reinject a
copy of the message to just that recipient. It is less complicated than doing
it for all recipients, and if the result is buggy, it will fire less often.
Letting the programmer choose seems to be the safest option.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
