On Sun 16/Mar/2025 04:59:57 +0100 Bron Gondwana wrote:
On Sun, Mar 16, 2025, at 04:50, Alessandro Vesely wrote:
I think an argument could be made that this definition doesn't apply to all
relays. Systems that don't need to change 821.From or 821.To and don't modify
the message being transferred would probably be able to operate without
attaching their own signatures.
AFAIUI, only backup MXes can forward a message without changing 821.To.
If signing 821.To could somehow be made into a separate signature, the
"classic" alias forwarding would not break the other (part of the) signature,
which would therefore be more compatible with DKIM1.
I'm not sure what you mean by "break" here - the signature won't be broken by having the SMTP
level "RCPT TO: <>" not be aligned with the value in the signed header; it will just
mean that the message fell out of the DKIM2 ecosystem.
So comparing the envelope values is not an integral part of the DKIM2
verification. Blocking replay implies the opposite. When a DKIM2 compliant
receiver gets a message from a DKIM1 forwarder it still needs a method to
discern "why" the message was forwarded.
We did consider having a flag saying "I know this message is leaving DKIM2 because
the next hop hasn't advertised support" but it added a lot of complexity, you would
either need additional DNS records or an SMTP extension to detect support in the next
hop; and then you'd need to make signing decisions based on that lookup, which would -
depending on your mail workflow (particularly if it's an SMTP extension so the decision
needs to be made while the connection is open) - add significant complexity to
implementations.
An SMTP extension sounds de rigueur, given the implied changes in DSNs handling
and the single-recipient mode. It would perhaps be similar to RFC 3461, which
provides for a "relayed" notification when a message leaves that DSN ecosystem.
BTW, would an ORCPT= matching the signed rt= satisfy the DKIM2 requirement?
It seems to me that DKIM2 already adds significant complexity to
implementations. For one, mail filters cannot sign before-queue as has to be
done with, for example, Courier-MTA. Indeed, a DKIM signing filter running
during the outgoing connection can take also into account any 8BITMIME and
SMTPUTF8 parameters, which current DKIM implementations can only try to guess.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
