Steffen Nurpmeso wrote in
<20230810224050.f3o3k%[email protected]>:
|Steffen Nurpmeso wrote in
| <20230810150536.5k9uk%[email protected]>:
|
|much too much was written it seems.
So please, everybody, forgive me, but in between sleeping in the
forest and a sundowner bicycle tour to real nature (some small
places still exist, even here), one final message of mine.
I think then i ate it up.
||A nice property would be that all (possible forms of) needed
||sub-signatures could be generated in parallel, a task that (most
|
|Except for the one which requires the "domainkey-encrypt" of the
|recipient domain, of course.
|But this would be a top candidate for caching, and already the
|second message send to its domain could avoid creating any
|subsignature but that
|
||[1] + if DNS per-domain (eg) "domainkey-encrypt" is found
|| . create DKIM subsignature for domain, include all
|| rcpt-to:<> that reside on that domain within it,
|| encrypted with "domainkey-encrypt".
In hindsight to the existing infrastructure this is all nonsense,
of course. I guess IFF that would be a standardized way to go,
instead it would simply be
[verify message, put RFC 7001]
|
DKIM sign message [include 7001 etc, flag DKIM sub-signature
presence]
|
iterate recipient domains
- if DNS per-domain (eg) "domainkey-encrypt" is found the
recipient host declares its willingness to accept DKIM
subsignatures, therefore create DKIM subsignature for it,
and include all rcpt-to:<> that reside on that domain within
it, encrypted with "domainkey-encrypt". [padding etc]
|
RFC 5321 SMTP transmission
That is, simply enforce this single encrypted subsignature style,
and simply place all subsignatures in the message itself, after
(ie, before) the normal DKIM signature.
This should work with any existing infrastructure, milters etc.
They only have to be adopted to do the DNS lookup and create the
additional subsignature(s) while working the message.
Of course, to not reveal Bcc: receivers via the embedded DKIM
subsignature of their domain, even if (and i would not do that)
the domain name itself, not only the recipients, is encrypted in
the subsignature, any Bcc:-only domains must instead be sent
forked messages.
But still, this is compatible with the current (milter)
infrastructure in that any such domain (recipient) must be taken
out of the receiver list, and a per-domain only transaction that
then includes the DKIM subsignature for this Bcc:-only domain has
to be instantiated. This is doable.
So with the above (and DKIM-Store:) i would think this is fine
except for one problem. What if a message addresses one recipient
in domain A via Cc:, but a thousand in Bcc:? Then even padding
would not help to hide the fact that many blind carbon copy
receives where actually addressed by the message.
Even if the standard would define that padding to the MAX of all
receiver domains in all DKIM subsignatures shall happen, the size
of the padding alone compared to the clear text address lists
reveals this undesired fact.
Therefore Bcc: recipients would always have to be sent forked
messages.
So if say @gmail.com is addressed via a Cc: member, but with two
members in Bcc:, there would need to be two DKIM subsignatures,
but only the ones addressed in Bcc: would be sent the message with
those two subsignatures, the one Cc: recipient would only see the
message with one @gmail.com DKIM subsignature.
A nice weekend i wish everybody! (If you can!)
Greetings from Germany,
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
