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
- [lamps] HP Issue: Bcc Handling Bernie Hoeneisen
- Re: [lamps] HP Issue: Bcc Handling Russ Housley
- Re: [lamps] HP Issue: Bcc Handling Daniel Kahn Gillmor
- Re: [lamps] HP Issue: Bcc Handling Russ Housley
- Re: [lamps] HP Issue: Bcc Handling Alexey Melnikov