> On 20 Nov 2022, at 20:48, Dave Crocker <[email protected]> wrote: > > On 11/20/2022 12:31 PM, Steve Atkins wrote: >>> On 20 Nov 2022, at 16:30, Dave Crocker <[email protected]> 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.
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. Handling of Bcc is not terribly well-defined, particularly for forwarders (which will sometimes strip it, and sometimes won’t), so even if your smarthost reliably only signs after any Bcc editing or message explosion it’s less likely to survive transit than other headers. If it’s signed it’s likely to increase the chance of a message that was signed when sent failing to verify when received. As far as delivery to the recipient is concerned it’s a reasonable argument that this only applies to messages where the recipient is not in the To or Cc header, so signing the Bcc header is going to be no worse, and may even be better in the rare case where the Bcc header includes the 821 recipient, and each individual message to each Bcc recipient is signed. ¯\_(ツ)_/¯ I still don’t think it’s a good idea, but I’m less convinced of that than I was 20 minutes ago. Cheers, Steve > > 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:@[email protected] > _______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
