Re: [Jmap] Submission: options for github issue

Brandon Long <blong@google.com> Wed, 26 April 2017 22:45 UTC

Return-Path: <blong@google.com>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B2A128616 for <jmap@ietfa.amsl.com>; Wed, 26 Apr 2017 15:45:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 1unVcYOG2eh3 for <jmap@ietfa.amsl.com>; Wed, 26 Apr 2017 15:45:45 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51CCB127B31 for <jmap@ietf.org>; Wed, 26 Apr 2017 15:45:45 -0700 (PDT)
Received: by mail-oi0-x231.google.com with SMTP id j201so18551028oih.2 for <jmap@ietf.org>; Wed, 26 Apr 2017 15:45:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eCy56Uu0rrDmhYP+in5ov8pMV3WQgS/CjZvdpVZyhJU=; b=HwsoQghRfoow1PWc9ANxFuqh0ou3wnARwdKJ+DDsLB+4n0+tTK/cePOPXwBUlelOSs OESE0JfkchCnq4hgPKudrpoOwCZt4VPiYrWz9XSBMbdHQ/uqEgURzKOrpfJuvQENRduq JWGB0H/XAwgbTnnn+4m3ek9l+sgmgcfKdK01xB7++gGHjVh3tkXCVGfhSKdNGE4KeXqf i3bbX5R14XL/JWVfAbIFXbH6C2zNzbuVK4XcaAykkKu8n/iq2M3gw2ki4U6q2YG5+e5/ ZUqnE1MQ5bVJrRljm74lSApjZqAszXU35R5aK0RSTGzyqmYUuGAulfjEcJDDZDQtG81d C7lA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eCy56Uu0rrDmhYP+in5ov8pMV3WQgS/CjZvdpVZyhJU=; b=SLPXmuQdFps2V9Ab74kkCwVtQ2MAixOemnCC3+pRbUpeBDLqR98tCDKfR9NpgaBmpb RJwxubSj6SXje+ffzD83ze9rvSRRgnrpysdTi2glHt7LWj7mVtChwpQ1WY1vPWe6888K bbwfZwnlkg8wy7Zldwqwzv6O8Sayiv3x/mMWqZVvZaN0Lhmx4vUoSxA46NUDWx4Jn8TZ qmwBb6nDJELOleEixQS7e8OGxAdguM+a9RnhVI57b/4w0nzMtmdWtwgm36SBC+DsJbwA M6jHR6z8LHil7GqLJaMoiSkUFEbNGxbhRfIp00q0A8Yw7EW5TcQY0o+TuMgzINasOziV HVIA==
X-Gm-Message-State: AN3rC/7P/cAt6QQCCR1NCcwyBpLthhoBDNGfEwugvEN+jpHcos43Z+vZ crbFjVLtilPw66S/NVShP3uRPlO1xbCr
X-Received: by 10.202.212.131 with SMTP id l125mr1133399oig.194.1493246744191; Wed, 26 Apr 2017 15:45:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.8.101 with HTTP; Wed, 26 Apr 2017 15:45:43 -0700 (PDT)
In-Reply-To: <CAMQk0F-E3kxWnPgZ0DGer9-FZ+n3kU0pLBDGMLVvm=nyCWniBA@mail.gmail.com>
References: <1492997737.3312553.953738776.7D27901C@webmail.messagingengine.com> <em03bd6820-d940-40b5-b3b9-ed15f51f67d4@bodybag> <BBA9201B61D28DBBB65EDBBD@cyrus.local> <43747FEE-5EBE-4F89-BE13-94701F88A5BA@fugue.com> <4A4B1A7AC839999470A6D83C@caldav.corp.apple.com> <CAMQk0F-E3kxWnPgZ0DGer9-FZ+n3kU0pLBDGMLVvm=nyCWniBA@mail.gmail.com>
From: Brandon Long <blong@google.com>
Date: Wed, 26 Apr 2017 15:45:43 -0700
Message-ID: <CABa8R6tCO=nn8+ZmyU5ORqEhHDpi_TGuCK8Kewn5hanCpjgqBA@mail.gmail.com>
To: Gren Elliot <fatkudu@gmail.com>
Cc: Ted Lemon <mellon@fugue.com>, Cyrus Daboo <cyrus@daboo.name>, jmap@ietf.org, Adrien de Croy <adrien@qbik.com>, Bron Gondwana <brong@fastmail.fm>
Content-Type: multipart/alternative; boundary="001a113acec8c076cd054e199940"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/5TW0frLL2kkUc5z1Ic0GQBBl0hI>
Subject: Re: [Jmap] Submission: options for github issue
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Apr 2017 22:45:47 -0000

Gmail does bcc splitting, has for several years now.  About once a year we
get someone complaining that it exposes private data (I didn't want people
to know they were on the losers@ mailing list) or confused that they think
this means everyone got the bcc header.

Apparently it's subtle.

Brandon

On Mon, Apr 24, 2017 at 7:43 AM, Gren Elliot <fatkudu@gmail.com> wrote:

> I have worked on a server that did BCC splitting - i.e. A separate message
> was sent to each BCC user including their address in the BCC header and a
> message sent to all the rest excluding the BCC header.
>
> Regards,
> Gren Elliot
>
> From: Cyrus Daboo <cyrus@daboo.name> <cyrus@daboo.name>
> Reply: Cyrus Daboo <cyrus@daboo.name> <cyrus@daboo.name>
> Date: 24 April 2017 at 15:26:35
> To: Ted Lemon <mellon@fugue.com> <mellon@fugue.com>
> Cc: Adrien de Croy <adrien@qbik.com> <adrien@qbik.com>, jmap@ietf.org
> <jmap@ietf.org> <jmap@ietf.org>, Bron Gondwana <brong@fastmail.fm>
> <brong@fastmail.fm>
> Subject:  Re: [Jmap] Submission: options for github issue
>
> Hi Ted,
>
> --On April 24, 2017 at 10:12:56 AM -0400 Ted Lemon <mellon@fugue.com>
> wrote:
>
> >> we may need to special Bcc headers even if the envelope is preserved -
> >> but then it because a little awkward because of the duplication of
> >> information in two places.
> >
> > Except that the bcc header shouldn't be in the message in the first
> > place, for privacy reasons. So either the message in the JMAP store is
> > different than what was actually sent, or the Bcc info should _only_ be
> > on the envelope.
> >
> > Of course, this requires the MUA to do some creative gymnastics to make
> > it all look good, but such is life.
> >
>
> Most MUAs today store Bcc information in the sent-mail copy of a message -
> of course they never include the Bcc header in the message that was
> actually sent
>
> However it is worth noting that RFC 5322
> (<https://tools.ietf.org/html/rfc5322#section-3.6.3>) does define 3
> different ways that the Bcc header can be used and in two of those the Bcc
> header is included in some fashion in a message being sent. I don't think
> those two modes are common enough to warrant support in JMAP, but I could
> be wrong.
>
> --
> Cyrus Daboo
>
> _______________________________________________
> Jmap mailing list
> Jmap@ietf.org
> https://www.ietf.org/mailman/listinfo/jmap
>
>
> _______________________________________________
> Jmap mailing list
> Jmap@ietf.org
> https://www.ietf.org/mailman/listinfo/jmap
>
>