[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "proper" handling of BCC
- To: "Robert A. Rosenberg" <hal9001@xxxxxxxxx>
- Subject: Re: "proper" handling of BCC
- From: Hector Santos <hsantos@xxxxxxxx>
- Date: Wed, 23 May 2012 09:50:45 -0400
- Authentication-results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
- Cc: ietf-smtp@xxxxxxx
- Dkim-signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; t=1337781055; h=Received:Received:Received: Received:Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Ud6XOJ8ZjC5rEZH0ubdNZVJULZE=; b=Z3c4g9avsaNOU84WT008/odFvoL0i OmC4E2DMxUhfQkKUMBnJxEX+rNqc9OnYgGsyy3QWZ17HutYfnrRTmv54dlw6swus mzxF4xIpa66wxBRIIkeIv4WSmeRawKnsSeKWaG63q8MOKN3Xw2ZR7azrymIjD5dv tCUKfjpRv6KtPA=
- Dkim-signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; t=1337781020; h=Received:Received:Message-ID: Date:From:Organization:To:Subject:List-ID; bh=g2dRd4wk+vIs1wf0HZ pqqgGT5YOdi5Mpj0R2RugKZf8=; b=EY5xrpJvVUNRyziAQN2qxubIE2K0FUr9qO PAmGtS1GqBwCwozg7IowH8aEpZpga4kdd+i1Vkw/krxaIfgibRJHTNRQZIXsShSH jqCWCfVWkrcaN1zDNA9RVp94iZ8J2/UBDProRxe2slxISe+Zxy3WPwOxj1A+aGxC X+nokuuMw=
- In-reply-to: <>
- List-archive: <http://www.imc.org/ietf-smtp/mail-archive/>
- List-id: <ietf-smtp.imc.org>
- List-unsubscribe: <mailto:firstname.lastname@example.org?body=unsubscribe>
- Organization: Santronics Software, Inc.
- References: <> <62D6A0D471E515527CB67A25@[192.168.1.128]> <> <> <> <> <> <> <> <email@example.com> <> <> <> <> <firstname.lastname@example.org> <email@example.com> <>
- Sender: owner-ietf-smtp@xxxxxxxxxxxx
- User-agent: Thunderbird 126.96.36.199 (Windows/20100228)
Hector Santos wrote:
The point is that AFAIK for a long time, the way it worked for most
systems, the BCC is stripped and two mail streams are sent. (I am going
to do a test with my TBIRD shortly to confirm, but I use to use OE and
it was the same way.)
That means the end-point MUA will never really know unless:
- The BCC is kept in the 2nd Private Stream Only,
- A special top note is written making the reader aware of the
According to the TBIRD test, it stripped the BCC, and used one
transaction (with two RCPT TO). I just did the test with OE, and the
Our PX MUA creates two messages, one with the special privacy note. I
don't see off hand how this can be otherwise be done currently today
without some new IETF MSA proposal that the source MUA is aware of.
If its going to use a single transaction with multiple RCPT TO lines,
the RCPT TO: needs an attribute or a new command - RCPT BCC: or
something like that.
But the fact that its one transaction, to me, the design assumption by
these MUA is that the backend is not expected to do anything here, and
its doesn't expect the MSA to reconstruction the distribution list.
That would be a major flaw here when it comes to the BCC.