On 11/20/2022 2:22 PM, Steve Atkins wrote:
On 20 Nov 2022, at 21:42, Dave Crocker <d...@dcrocker.net> wrote:
It’s a reasonable heuristic if Bcc is included in the DKIM signature, I just
don’t think including Bcc in the DKIM signature is a good idea.
Including Bcc: in the signature is a given, for this topic.
I've no objection if that’s the given.
Again, sorry I wasn't clear about this. I meant that a) there is a bcc
field, containing the recipient's address, and b) it's covered by the
DKIM signature.
Handling of Bcc is not terribly well-defined, particularly for forwarders
(which will sometimes strip it, and sometimes
I have no idea what 'handling' you have in mind. To: and CC: do not get
'handled' except during a Reply process.
As for 'forwarders', I'm not sure what you mean. Certainly not MTA. That
leaves post-delivery behavior, with re-posting, which is entirely outside the
scope DKIM.
Smarthosts rewrite or remove Bcc headers in mail that they accept as a
submission from an MUA before they deliver it to the next MTA, in a way that’s
implementation (and configuration) defined. Some will do so for mail received
from another MTA, not as a submission - e.g. postfix, by default, will strip
any Bcc headers after it receives an email and before it passes it to the
opendkim milter (I believe, I’ve not tested that.) or forwards it on to the
next MTA.
One of the ways we’ve tried to make DKIM signing robust across the wild west of
the email network has been to avoid signing things that might change in
transit. Bcc headers in particular are definitely one of those things, and are
special cased as “you should modify or delete this” in quite a lot of places.
But perhaps we don’t care in this particular case? If Bcc modification breaks
the signature then it’s no worse - for delivery to this single recipient - than
it would have been otherwise. I don’t think it affects the broader
identification of mail streams for reputation tracking in a way we’d care about
either?
Working on the tenuous assumption that I have adequately understood the
above:
1. If an MUA creates a BCC with the recipient address, and the MSA (or,
for that matter, any other system handling the message) either removes
the address or the field or does not sign it or breaks the signature,
then the message is operating fully outside of the suggestion I made.
(That's ok. The suggestion is intended only as a marginal benefit, not
a major fix.) We can hope that they change their behavior over time,
but it's not required for this to have utility elsewhere.
2. I think we disagree about BCC being 'one of those things'. While I
take you point that some systems might mess with an existing BCC field,
I think the general view of the field should be the same as To: and
CC:. It's not an envelope field and therefore does not support a
built-in expecatation of getting messed with.
3. Happily, we agree on your last paragraph.
d/
ps. When originally posting my suggestion, I had not yet seen the slides
from the IETF meeting and hadn't know that the basic suggestion had
already been made.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
