On Sun 23/Mar/2025 16:13:12 +0100 Allen Robinson wrote:
On Sun, Mar 23, 2025, 7:13 a.m. Alessandro Vesely <ves...@tana.it> wrote:
On Thu 20/Mar/2025 19:54:02 +0100 Allen Robinson wrote:
I don't think DKIM2 helps at all in that case.
A sender is well within their rights to put in a new header that specifies
the set of recipients for the message, if they were so inclined. And that's
assuming the recipients aren't already listed in destination address
headers (To/Cc) which seems to be the case in the linked example.
Having all recipients listed in a DKIM2 signature's rt= tag gives no more
guarantee that the signer actually did what it claimed it was going to do
than any other header.
A DKIM2 verifier can only verify consistency for recipients in the
transaction in question. In the linked example, if all recipients are in
the same company, addressing them all in a single transaction could make
it possible for the receiver to verify that they were all properly
addressed. A feature not (yet?) considered for DKIM2.>
That works if all recipients in a single domain are included in a single
transaction. There's no way to guarantee that in general, so interpreting
"address not listed in DKIM2 rt=" as "address didn't get a copy" seems
flawed. And it doesn't provide any signal at all for recipients across
domains.
That's right. I'm not proposing to add such feature in the protocol. Just
noting that an MTA might implement it if they wanted to.
There's also the possibility of a multi-recipient transaction rejecting
some recipients. This makes assuming that the DKIM2 rt= list and the 821.To
list are equivalent (after sorting+canonicalizing) a little bit brittle. So
we either accept signatures where 821.To is a subset of rt=,
I interpret that as saying rt= is a subset of 821.To.
which removes the property that an address being listed means that address
received the message, or reject and retry, which seems like it would need
delicate handling to not get stuck permanently.
In order to write a filter, I'd like an MTA which calls outgoing filters after
the whole RCPT TO series is done, but before DATA; having the list of accepted
recipients and the body already converted to what the receiver needs. Dunno if
any MTA currently does so. The MTAs I know are designed to filter incoming
messages, not outgoing ones. If that's not available, then I'd resort to
single-rcpt.
The spec must not hypothesize what features MTAs will offer to filters.
[...]
Another argument for allowing multiple recipients is the consideration of
what kind of hack a filter needs to employ to force a single-rcpt
transaction. This is still necessary for Bcc:, although a special
provision could be made for internal Bcc:s, such as Bcc: to themselves,
which do not need verification. However, in some cases, the ability to
use multiple recipients can actually simplify implementation.>
I assume these filters already have to take into account that receiving
servers may have upper bounds on a transaction's recipient list.
Configuring that upper bound to be one instead of whatever it is today
doesn't seem like a hack to me. Admittedly I don't have experience with a
broad set of mail implementations, but Exim does support configuring this
at least.
AFAIK receiving servers that enforce an upper bound do so by temporarily
denying RCPTs after the configured number. The client doesn't know the actual
reason for a 4xx response (unless it interprets the accompanying text.)
You need to configure an upper bound in the sending client. If it is 1, then
you know that Bcc: works well. However, if the MTA is DKIM2-aware, there is no
need to do so.
There may still be some filter hackery needed to figure out what the SMTP
splitting would look like while generating the signature(s), but I think
that's likely independent of whether or not DKIM2 imposes a lower limit
than would otherwise be used.
Yet another point, purely psychological, is that a protocol that doesn't
impose single-rcpt transactions will certainly be considered less
disruptive to SMTP than one that does.
It's very reasonable for people to consider this potentially disruptive. We
will need to have documented rationale for why DKIM2 requires this limit.
What rationale? The motivation draft says:
If the recipient wishes to forward the message on to another address,
it must apply its own DKIM2 header, signed by a key which is aligned
to the domain of the recipient address in the previous DKIM2 header,
and with a bounce address which is in the same domain.
Both of the above requirements mean that every SMTP transaction for
DKIM2 messages will, by necessity, have only a single recipient.
The reason escapes me. Why not say "If one of the recipients wishes to
forward...". You may finally obtain a tree instead of a chain, but the same
rules apply.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
