Re: [lamps] HP Issue: Bcc Handling

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 09 November 2020 22:38 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6213A149D for <spasm@ietfa.amsl.com>; Mon, 9 Nov 2020 14:38:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.306
X-Spam-Level:
X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=Yc7Q7dtz; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=dfd7e0s6
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_RTjhhxgC0D for <spasm@ietfa.amsl.com>; Mon, 9 Nov 2020 14:38:05 -0800 (PST)
Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C9F3A149B for <spasm@ietf.org>; Mon, 9 Nov 2020 14:38:05 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1604961483; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=WFVz3E1fdMXHtuO8c3Y+NSfhSf77shlIQv1ZFGV83qU=; b=Yc7Q7dtz2qRuz7VnAmRGTk2QWpiFKkXUnGqDRoK969qup/BCaro+JzeS99U6bZ6RMLiS+ aOTD2JBQKWFlQ4LCg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1604961483; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=WFVz3E1fdMXHtuO8c3Y+NSfhSf77shlIQv1ZFGV83qU=; b=dfd7e0s6nfX1bAFvMze47Gv5yns5rd2vzNt01QLfSpT963gb1637i0jdov7OE9d9A556w NyWpa5MZu5MUDMgraOXV9AJR4h9o16qhoJGgMCGnuBG+kiUGb1I4Wc+LYtmLkc4ZyLfmqMj vRfBpiBwcZnEy4dBxaoYcDB0zeYizI+4TynrcUoV6sjHpmyIZRfDq54eTZWMxQEkF6iHwwD lTLXdqT1agWWCcS5qciKz0A7rmjLMgfcC/kAVh4U+yPfs1NUxOUB1RI0NI+f7wMelSY1EwR Z8MVDiqoYD/0WQ6XXev3Qgkvd0uFeHawcVAy4ylHcL7yY/coa09jhejFuZ4w==
Received: from fifthhorseman.net (unknown [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id CD532F9A5; Mon, 9 Nov 2020 17:38:03 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 25E7220324; Mon, 9 Nov 2020 17:37:39 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Russ Housley <housley@vigilsec.com>, Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
Cc: IETF LAMPS WG <spasm@ietf.org>
In-Reply-To: <F39D531C-A777-4318-93A7-C8C95F39A94E@vigilsec.com>
References: <alpine.DEB.2.22.394.2010021410290.55994@softronics.hoeneisen.ch> <F39D531C-A777-4318-93A7-C8C95F39A94E@vigilsec.com>
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ==
Date: Mon, 09 Nov 2020 17:37:38 -0500
Message-ID: <87r1p2gnrh.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/5hnaMLWCNnZ1btELO8Jcn9xxW2s>
Subject: Re: [lamps] HP Issue: Bcc Handling
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2020 22:38:07 -0000

On Fri 2020-10-02 10:33:10 -0400, Russ Housley wrote:

> Please take a look at RFC 5322, Section 3.6.3.  The proposed direction
> seems to be consistent, but you probably want to cite this section.

Thanks for this pointer, Russ.  Bcc is a surprisingly tricky thing to
get right in all cases.

In addition to the guidance in the section you cite, there are unusual
tricks or special cases that responsible MUAs will want to do to deal
with Bcc in "Sent" folders and "Drafts" folders (the semantics of these
folders in most MUAs are subtly different from other folders, and from
each other).  Also, there are some subtleties when dealing with Bcc for
encrypted e-mail (regardless of header protection) -- i've added a note
in the to-do list in https://gitlab.com/dkg/e2e-mail-guidance to try to
flesh those out.

But after some discussion with Alexey and Bernie, i think we're reaching
the conclusion that as complex as the work around Bcc is, it's pretty
much orthogonal to protected headers -- if you are doing the right thing
with Bcc already, you're likely going to do the right thing with Bcc
when generating a message with protected headers and Bcc.  (Conversely,
a MUA that screws up Bcc isn't likely to magically get it right because
they're implementing protected headers)

I'll make an edit to the header protection draft that simplifies the
text about Bcc, includes the reference you mention above, and otherwise
doesn't drag the draft into too much detail.

        --dkg