I will respond to your comments regarding RCPT TO now as I believe there
is some misunderstanding about what I am proposing. Unfortunately, due
to other commitments, I will need to defer the rest of my response until
tomorrow evening or Monday (NZDT).
On 25/10/2025 4:20 pm, Bron Gondwana wrote:
> *Technical:* if you sign multiple RCPT-TO values without specifying
them in the content which is passed on to later hops then:
a) the later hops can't see why the email came to them via this path,
which I contend they have a right to know. If you're included in an
alias expansion, you should know what the alias is! (I have a solution
to this which would be OK except that)
This is a valid concern as it would remove any ambiguity over which list
(if multiple were present in To/Cc) resulted in the final e-mail. It
does raise the question of should we leak the list address if it's BCCd,
since your desire to include this would also expose that information.
I'd be interested in your solution, if not for b).
b) it doesn't allow splitting the RCPT-TO; you'd have to sign on-the-fly
and split and re-sign if the destination server restricts the number of
recipients per message. And any currently fully transparent secondary
MX would have to then either sign, or forward all recipients as a single
transaction to the same destination. I could imagine an MX which
separates incoming email into multiple different subsystems despite the
addresses being at the same domain, and this system would not handle
that at all.
This is where I believe there may be some misunderstanding. This would
not be a cumulative value that needs to be recalculated. A unique
signature would be created for each recipient when the e-mail was
initially signed or exploded, just as it would be if it were placed in
the headers.
SMTP would take care of splitting the delivery up as it does now,
without having to recalculate these values.
If the upstream hosts supports DKIM2, it would pass this information
along with RCPT TO.
RCPT TO:<[email protected]> DKIM2RCPT=i=1,s=selector,h=DOM...ygIM=
RCPT TO:<[email protected]> DKIM2RCPT=i=1,s=selector,h=WRm...uO+c=
If the upstream host doesn't support DKIM2, then messages would need to
be split and the precalculated value inserted as a header. This can be
done in a 'dumb' way, by simply adding it before the already created
e-mail headers. It also doesn't effect the SMTP session much, if at all.
Assuming the server has a list of recipients it intends to send to a
particular host, lack of DKIM2 support would likely just cause it to
switch to connection reuse and send individually.
Sending more than one of these headers in a message would be possible if
the server were to parse the e-mail headers and determine which BCCd
recipients were subject to special handling, but it would be up to the
implementer to decide if that was worthwhile given the need would
diminish with more widespread DKIM2 adoption.
*Practicality: *Even if the technical issues above were all solved, this
requires changes to a LOT more software. Every piece of software which
handles mail needs to be aware of this, rather than only the edges
between systems with separate ownership or domains of trust.
All this, just to protect against exposing information which is either
already present in the To/Cc headers, or is explicit to the single
destination if it's a BCC.
Assuming my comment above hasn't addressed these concerns, then we may
need to agree to disagree on the relative difficulty of each approach.
Using RCPT TO is a linear approach that touches isolated parts of the
delivery process to a minimal extent. If we leave change tracking aside
for now, it requires the DKIM2 filter to be invoked only once.
Creating a signature for each recipient, however, requires one of three
approaches:
1/ The SMTP server splits messages before signing and invokes the DKIM2
signer once for each recipient (worst case, assuming all are BCCd, are
being routed to different upstream servers, or a minimalist
implementation).
- Computationally inefficient, but the safest approach.
- Likely to result in premature expansion, increasing disk and network
utilisation.
- Requires code changes support e-mail parsing, e-mail splitting and if
optimised to reduce resource usage, editing e-mail headers during delivery.
- No crypto optimisation.
2/ Invoke the DKIM2 filter once and preserve only the active
DKIM2-Signatures.
- Requires the SMTP server to be able to parse e-mail headers.
- Requires the SMTP server to edit the message on the fly to remove
headers which aren't applicable, or otherwise remove and reinsert them
at the appropriate juncture.
- Significantly elevates the risk of data leakage if a filter believes
the SMTP server it is signing on behalf of is DKIM2-compatible and will
remove any additional headers it inserts.
- Offers limited room for optimisation due to lack of parity between
crypto implementations.
3/ Split e-mails within the DKIM2 filter.
- Requires both the DKIM filter protocol and SMTP servers to be altered
to allow message splitting and injection - a significant change in mail
flow.
I'm sure there won't be any disagreement that method 3 isn't practical.
Regards,
R. Latimer
Inveigle.net
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
