On Thu 12/Jun/2025 20:04:55 +0200 Bron Gondwana wrote:
On Thu, Jun 12, 2025, at 09:36, Alessandro Vesely wrote:
On Thu 12/Jun/2025 05:41:53 +0200 Bron Gondwana wrote:
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.
I think there might be a misunderstanding here; either between Wei and me, or
between Wei and you (and, by the time I finish this message - maybe between you
and me as well!)
I very strongly think it's bad engineering for the `rt=` to be implicit. We
should not go down this path.
Yes, this is a point of disagreement.
How about rt=DEFAULT? (explicitly direct to official recipients.)
We should include the expected exact list of legitimate recipients in the DKIM2
header (either one rt, or some multiple address abomination if the working
group decides to go that way).
Having the validator have to look through the other headers to see if one or
more of them belong to a domain which it knows about is just really really bad,
fragile, and annoying to create and maintain the code for.
A verifier must in any case examine the header, field by field. For each
field, check whether it is signed and hash it. Also, some fields have a
relevant meaning for the verifier (at least the signatures), so there's nothing
exceptional in examining To: and Cc: in particular.
Thinking about this has made me even more persuaded that, even if we allow
multiple rt= on a single message, they MUST all have the same domain.
Otherwise, when generating a bounce, it's not clear which domain to sign the
bounce from. Likewise when generating a forward, all later hops are going to
have to check against all the rt= values to make sure at least one of them
matches the domain on the n+1 hop. It's just a lot messier.
This is where the "annoying" algorithm comes in. When parsing the To:/Cc:
fields, you can safely ignore those that do not match the envelope. The SMTP
client sorts recipients by MX, and those destined for a different domain would
be rejected by the SMTP server (unless it's an open relay).
If instead we had a multivalued rt=, don't you think a sensible filter wouldn't
compare each address with the envelope AND with To:/Cc:?
I could see an argument for a general `rt=*@destination.domain` which said "this message is
only for recipient at domain X". It's still ugly because you could then, in theory, replay
the message to other people at the same domain, e.g. if I sent a message "Bcc:
[email protected]" and it got signed with `rt=*@gmail.com` then anyone who got their
hands on a copy of that message could replay it to anyone else with a gmail address and it be
validly DKIM2 signed as if they had been the intentional BCC instead.
That's a different point. We get a similar problem when we have:
i=1; [email protected]; [email protected]; d=tana.it
i=2; [email protected]; [email protected]; d=ietf.org
Your verifier can only compare the domain parts of the 1st rt= and the 2nd mf=.
So I still prefer an exact list of addresses. Then you can only replay to the
same person again, and that's boring since it'll likely be deduplicated by the
existing SMTP retry-handling logic.
Copies resent every few minutes will all be delivered, bypassing a normal
dup-filter. SPF would prevent third party resending, but nobody uses -all anymore.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
