Hello.
(Sorry for the late reply. ..And tomorrow the rain comes back,
only sultry and hot instead of cold...)
Jesse Thompson wrote in
<9bbf617b-13c6-4be5-841f-2a36b702d...@app.fastmail.com>:
|On Wed, Aug 9, 2023, at 3:12 PM, Murray S. Kucherawy wrote:
|> On Wed, Aug 9, 2023 at 9:07 AM Steffen Nurpmeso <stef...@sdaoden.eu> \
|> wrote:
...
|Any inclusion of RCPT-TO in the headers or signature is a privacy concern \
|if the message is forwarded, but those tend to show up in Received \
|headers anyway. Seems like a wash, regardless of where you put it.
...
The aspect of DKIM-subsignatures revealing Bcc: presence (of 1+
recipients of a domain) if a Bcc: recipient replies to a message
that Murray Kucherawy adduced i obviously have not fully addressed
with my response.
I would ask you to reconsider the problem with the "new" idea that
integrates with current implementations which do DKIM, like
milters (OpenDKIM) etc. It was that:
|
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]
|
...
and
...
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.
DKIM is meant to be automated in between machines.
Today it pledges one side, the sender one, but with this, if we
throw in the american style we could call it "smart" or
"reflective" DKIM, the pledge is extended to be in between sender
and receiver.
Since DKIM subsignatures are only created for those recipient
domains which announce their willingness to accept the "new" DKIM
via exposing a "domainkey-encrypt" in the DNS, whereas older
receiver domains continue to function as of today, the "new" DKIM
could define that DKIM subsignatures should (as in "MUST") be
filtered out before the verified message is delivered to the local
mailbox.
That is: let subsignatures be a temporary phenomenon in between
the DKIM signing sender and the DKIM verifying receiver. That is:
keep out that dirty, stinking, most often megalomaniac end user,
head for full self driving, so to say.
Since it only matters for Bcc: recipients, there could also be
a "DKIM-subsig:" and a "DKIM-bsubsig" aka "blind sub signature",
and only "DKIM-bsubsig" "MUST" be removed, whereas the normal (To:
and Cc:) "DKIM-subsig" could remain part of the message.
This differentiation does even make sense since old DKIM
implementations will never filter out those DKIM subsignatures
which are included for the recipients in To: and Cc:.
[ietf.org only:
DKIM-Bsubsig: ..ditto.. ietf.org members of Bcc:]
DKIM-Subsig: ietf.org; ENCRYPTED,BASE64 [contains ietf.org
recipients of To: and Cc:, and DKIM-signature checksum]
DKIM-Subsig: xy.com; ..
...
DKIM-Signature: [FLAGS subsig presence to new implementations]
...
So with this end users never can accidentally reveal Bcc: content
via included DKIM-[B]Subsigs.
--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
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
