On Fri 20/Jun/2025 18:00:10 +0200 Bron Gondwana wrote:
On Fri, Jun 20, 2025, at 03:00, Alessandro Vesely wrote:
On Wed 18/Jun/2025 23:15:37 +0200 Bron Gondwana wrote:
Note that we're still signing each recipient individually. Then if Sheila has
a forwarding rule, it only keeps her i=1 header, so that forwarded message
would contain:
DKIM2: i=1; [email protected] [email protected]; d=example.com
DKIM2: i=2; [email protected]; [email protected]; d=example.org
This point relies entirely on the good faith of the forwarder. A malicious
replayer would put a different signature, in order to confuse the attribution
of reputation.
How? It's not like they can just arbitrarily make up a signature. My examples
here elide a bunch of crypto stuff which you can't actually create without
having a key in the DNS for example.org, and unless you own example.org, you
can't create that.
If you DO own example.org and you're the malicious forwarder then you're
tanking your own reputation. That's the point.
You get the same point also without having to add multiple i=i signatures. If
example.org is a throw away domain, evaluators would wonder whether to
attribute the reputation of example.com to the message, since that's where it
originated.
Blaming Sheila for the forwarding might be dubious, because the forwarder might
have kept the wrong i=1 signature. In case of fraud, Alice is more likely to
be the culprit.
[..]
Isn't it possible to explicitly request the previous rt=? That is, to have:
DKIM2: i=2; [email protected]; [email protected]; d=example.org
Sure. You could do that. I don't know what you mean by "explicitly request". There's no
"request" here; unless you mean "request that bounces be sent to". I would expect most
sites to have a dedicated bounce handling address rather than process bounces sent back to the forwarding
target, but that's entirely up to the implementation.
It seems like there must be a step where only a "weak" match is possible, i.e.
checking the alignment between the corresponding domains rather than an exact
match. We are now requiring a weak match between the previous rt= and the
current mf= and an exact match between the current mf= and the actual return
path in the envelope. Alternatively, we could settle for alignment between the
return path and the current mf= (and the signature) and instead require an
exact match between the current mf= with the previous rt=.
That is:
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DKIM2: i=1; [email protected] [email protected]; d=example.com
And then:
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DKIM2: i=1; [email protected] [email protected]; d=example.com
DKIM2: i=2; [email protected]; [email protected]; d=example.org
I believe any bounces generated after acceptance should use the actual
return-path, not rely on the signature's mf=. So having the actual return path
in the signature is of little importance. Perhaps having an exact match between
the previous rt= and the current mf= can provide more clarity in case of large
domains.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
