On 11/20/2022 12:31 PM, Steve Atkins wrote:
On 20 Nov 2022, at 16:30, Dave Crocker <d...@dcrocker.net> wrote:
On 11/10/2022 5:32 AM, Steve Atkins wrote:
A heuristic I’ve suggested previously is “If the recipient’s email address is
not in the To: or Cc: header then treat the mail as unsigned”.
Even if it is showing in a (signed) BCC field?
Definitely. I wouldn’t want to encourage any use of the Bcc field beyond the
smarthost, let alone any belief that signing it was a good idea.
The content of the Bcc field, or even the existence of it, at the time it’s
received by the MX is at best implementation-defined. Signing it at
the smarthost is going to cause DKIM to fail far more often than not.
I don't understand the basis (or possibly even the meaning) of either of
the sentences in the above second paragraph.
Remembering that you kicked this off with a heuristic approach, I'm
merely noting that a BCC with an addressee listed in it should be just
as valid (to the heuristic) as having it occur in To: or CC:. And since
you don't agree, I am not at all understanding the basis.
The only variability I know of, for BCC, is what the originating host
chooses to put in it, and I believe it is a small range of rather simple
choices.
4871 says:
The following header fields SHOULD NOT be included in the signature:
o Return-Path
o Received
o Comments, Keywords
o Bcc, Resent-Bcc
o DKIM-Signature
6376 does not. I’m not sure why that changed.
Perhaps because there was no credible justification for the guidance?
(I can see that guidance against signing envelope fields is problematic,
given the timing, etc., of their creation, and signing DKIM-Signature
confuses me. But guidance against signing 5322 address fields makes no
sense to me at all. (And I don't recall the discussion about this for
4871.)
d/
--
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
