How to show Bcc recipients of sent e-mail

[VanguardLH]

Thunderbird 24.3.0
Windows 7

This has been asked before but in searches I kept hitting replies
regarding ancient versions of Thunderbird, the respondents don't know
the difference between incoming e-mail protocols (POP, IMAP) and
outgoing e-mail procotols (SMTP) so their suggestion are about POP and
IMAP instead of SMTP, or respondents claim they see a Bcc field in the
header section of the view pane but I don't.

POP and IMAP are irrelevant for the *sender* to see who were the
recipients of e-mail that he *sent*. The Bcc header is not in the
message sent to the SMTP server. The server never sees a Bcc header nor
does it even care if To or Cc headers were used. The SMTP server only
knows who are the recipients by the RCPT TO commands sent to it by the
client. The client compiles an aggregate list of recipients from the
To, Cc, and Bcc fields and sends a RCPT TO command for each recipient in
that aggregate list. The RCPT TO command only specifies the recipient's
e-mail address, not the comment field in the e-mail field and nothing
about in which field (To, Cc, or Bcc) in which the recipient was
specified in the message.

Some users note they see a "Bcc" (with a "+" next to it for expansion if
there are 4, or more, recipients in that field) in the headers section
of the view pane when selecting a message in the Sent Items folder.
Nope, don't see it. Select "All" for the headers view but Bcc isn't
included, plus it seems that just shows the typical headers in the
e-mail which would (or should) never be included in the message.

I sent a message to 4 recipients all specified in the Bcc field. To
avoid them seeing the unfriendly "<undisclosed recipients>" string in
the To header, and because this can run afoul of anti-spam filters, I
created a new contact called "Family & Friends of <myname>" that
specified my own e-mail address. So the compose window in Tunderbird
looked like:

To: Family & Friends of <myname>
Bcc: <recipient1>
Bcc: <recipient2>
Bcc: <recipient3>
Bcc: <recipient4>

I picked a recipient from the contact list (shown on the left side in
the new-mail compose window) and clicked the "Add to Bcc" button. The
result was a new Bcc field got added for each added Bcc'ed recipient.
Looks dumb but that's how Thunderbird does it. I'm used to see a list
of recipients regardless of which target field (To, Cc, or Bcc) is used
to specify multiple recipients.

I know the SMTP server got the RCPT TO commands to specify each of the
Bcc recicpients because one of them was wrong. That resulted in me
getting DSN (delivery status notification) about an NDR (non-delivery
report). So I had to "Edit as new" to resend that same message to the
correct e-mail address for that one recipient. So I have 2 copies of
the same message in the Sent Folder: one to 4 Bcc'ed recipients but 1
was invalid, and another with 2 Bcc'ed recipient. Yet when those are
selected, there is no Bcc field in the headers section of the view pane
to let me see who were the recipients.

Since the outgoing message never contains a Bcc header and since the
SMTP server never sees a Bcc header but instead only sees commands sent
to it by the client (RCPT TO for each recipient), there will never be a
list of Bcc recipients up on the server. The client has to keep track
of the Bcc recipients for a message.

Anyone have a clue why a selected sent e-mail where in the Sent Items
folder recipients were specified in the Bcc field doesn't show the Bcc
field? Did Mozilla drop showing that field? Even if I use "Edit as
new" to resend the e-mail, all the Bcc recipients are missing.

[Ken Whiton]

*-* On Tue, 11 Mar 2014, at 01:26:16 -0500,
*-* In Article <gK2dnVla0cMVMYPO...@mozilla.org>,
*-* VanguardLH wrote
*-* About How to show Bcc recipients of sent e-mail

> Thunderbird 24.3.0
> Windows 7

> This has been asked before but in searches I kept hitting replies
> regarding ancient versions of Thunderbird, the respondents don't
> know the difference between incoming e-mail protocols (POP, IMAP)
> and outgoing e-mail procotols (SMTP) so their suggestion are about
> POP and IMAP instead of SMTP, or respondents claim they see a Bcc
> field in the header section of the view pane but I don't.

[ ... ]

> Anyone have a clue why a selected sent e-mail where in the Sent
> Items folder recipients were specified in the Bcc field doesn't show
> the Bcc field? Did Mozilla drop showing that field?

I see the Bcc header displayed in items in the Mailed Folder in
both TB 1.5.0.14 and TB 17.0.5 under Windows XP, so if they've dropped
showing it it's within the past year.

<http://tinypic.com/r/294nxio/8>

The upper portion of the image is the header display in TB 1.5.0.14
and the lower portion is the header display in TB 17.0.5.

I find nothing in the Config Editor that would appear to affect
whether or not that particular header is displayed.

Have you tried restarting with add-ons disabled, to see if it
might be a conflict with an installed add-on?

Help --> Restart with Add-ons Disabled...

If nothing else works, you should be able to see the names of the
Bcc recipients by viewing the Message Source.

View --> Message Source

or use the <Ctrl-U> keyboard shortcut.

Ken Whiton
--
FIDO: 1:132/152
InterNet: kenw...@surfglobal.net.INVAL (remove the obvious to reply)

[Chris Ramsden]

>> Anyone have a clue why a selected sent e-mail where in the Sent
>> Items folder recipients were specified in the Bcc field doesn't
>> show the Bcc field? Did Mozilla drop showing that field?

Is gmail involved? They redact Bcc recipients in the copy held in the
gmail "Sent" folder. Set Thunderbird to use local storage (e.g. Local
Folders) for the Sent folder and you'll retain the Bcc addressees.
--

Chris

[VanguardLH]

I have both Hotmail and Gmail accounts. In this case, Hotmail was used
to send.

Besides, Gmail never gets a Bcc header. The client never adds it in its
message that gets sent using the DATA command. The SMTP server only
sees the RCPT-TO commands it got from the client specifying who are the
recipients. That's why the client has to track the recipients in the
Bcc field. The Bcc field is always a field in the client, never a
header in the sent message.

If Thunderbird is only showing the headers in the sent e-mail (what gets
sent in the DATA command) then how could it show the Bcc header that is
NEVER added to the e-mail?

What the SMTP server sees when there is 1 recipient (rcptA) in the To
header, 1 (rcptB) in the Cc header, and 2 (rcptC & rcptD) in the Bcc
field:

RCPT TO rcptA
RCPT TO rcptB
RCPT TO rcptC
RCPT TO rcptD
DATA
Date: ...
To: <rcptA>
Cc: <rcptB>
From: yourname <youremail>
...
.

The trailing period character alone in a line delimits the end of the
message data. The To, Cc, From, Date, and other headers are those added
by the client. The client NEVER includes a Bcc header in the DATA of
the message. Outside the DATA command the SMTP only sees RCPT TO
commands from the client listing the recipients. The RCPT TO command
only specifies e-mail address: no names and no indicator in which
client-generated header the recipient was specified.

So how could Gmail's SMTP, or anyone else's SMTP server, ever know what
was in the Bcc header when there never was one? How could any SMTP
server know which recipient was in which header in the DATA command?
Nothing inside the DATA command is used to specify a recipient.

I've used MS Outlook with both my ISP e-mail, Hotmail, and Gmail. Never
had a problem seeing the list of Bcc'ed recipients because the client
has to track that. The server doesn't know which recipient was in the
Bcc header because there isn't one.

If Thunderbird is hiding the Bcc list for e-mails sent using a Gmail
account defined in Thunderbird but shows the list for e-mails sent
through accounts other than Gmail then that is a Thunderbird bug. No
matter through which SMTP server a message is sent, the client has to
record the Bcc list for a message. It's not on the server. Plus I
didn't use Gmail to send, in this case.

[VanguardLH]

In your header section in the view pane, I see:

+ Subject
From
Reply To
Date
To
+ Bcc
User-Agent

You also show another header section but I don't know if the top one is
some special view or add-on and the bottom one is the regular header
section, or if you showed 2 separate e-mails and their header section.
Your bottom one has:

From
Subject
To
Bcc
User-Agent

All I have in mine (which only has 1 header section) is:

From
Subject
To

No Bcc or Date fields. I suspect your 1st example is when showing all
headers via View -> Headers -> All hence the scrollbar in your example.
When I pick that view and scroll up and down, there is still no Bcc
field.

I know that at least one of the e-mails using only the Bcc for
recipients got to the SMTP server and got sent out because it had the
wrong e-mail address so an NDR (non-delivery) report got sent to my
account by my SMTP server.

[»Q«]

In <news:EMGdnTeR1ODvcYPO...@mozilla.org>,

VanguardLH <V...@nguard.LH> wrote:

> Chris Ramsden wrote:
>
> >>> Anyone have a clue why a selected sent e-mail where in the Sent
> >>> Items folder recipients were specified in the Bcc field doesn't
> >>> show the Bcc field? Did Mozilla drop showing that field?
> >
> > Is gmail involved? They redact Bcc recipients in the copy held in
> > the gmail "Sent" folder. Set Thunderbird to use local storage (e.g.
> > Local Folders) for the Sent folder and you'll retain the Bcc
> > addressees.
>
> I have both Hotmail and Gmail accounts. In this case, Hotmail was
> used to send.

AFAICT, you didn't say what happened when you set Thunderbird to use
local storage for the Sent folder. If you want to retain the BCC
headers, that's your best bet.

> Besides, Gmail never gets a Bcc header.

Not via SMTP, but it can get them via IMAP.

[VanguardLH]

Since the Bcc *header* is not supposed to get added by the client then
the SMTP server never gets a DATA command containing it. The client
should have the same local copy of the message that it sent so I don't
see how IMAP is going to reveal to the server a header that isn't in the
message.

If the client were sticking the Bcc header into the message then
recipients could see that header. If the client were adding the Bcc
header to the message then why wouldn't looking at all the headers
reveal that header?

For IMAP and according to RFC 3501 in section 7.4.2 "FETCH response":

The fields of the envelope structure are in the following order: date,
subject, from, sender, reply-to, to, cc, bcc, in-reply-to, and
message-id. The date, subject, in-reply-to, and message-id fields are
strings. The from, sender, reply-to, to, cc, and bcc fields are
parenthesized lists of address structures.

But that is the response for the FETCH command which means the message
on the server must already have the Bcc header; i.e., the client that
sent the message screwed up by including the Bcc header.

If the From, To, cc, and bcc header lines are absent in the
[RFC-2822] header, or are present but empty, the corresponding member
of the envelope is NIL.

When IMAP is being used, your client is keeping synchronized to the copy
up on the server hence the IMAP protocol only does fetches, not sends.
Go to section 6 that describes the IMAP commands and you won't see any
that issue send-type commands (regarding the message's content). The
CREATE command is to create mailboxes, not messages. The APPEND
command, section 6.3.11, creates a *new* message (and not a replace
because no message ID argument can be specified) to the end of the
specified mailbox. This is how, for example, your drafts get uploaded
to the server. If the client didn't add the Bcc header (which it should
never do) then there is no Bcc header in the server's copy to include in
the message that you are retrieving and keeping synchronized in your
client.

I suppose Thunderbird could be screwing around with the message content
by taking the message literal (headers and body) of a message to send as
an APPEND command to create a new message in the specified folder but
change the message literal argument to add other content, like the Bcc
header, and then issue a DELETE to get rid of the original. This would
be corruptive to e-mail fidelity, especially because the message
sequencing numbers would change.

Even if Thunderbird were using IMAP via APPEND to modify messages up on
the server to add the Bcc header, that means Thunderbird has the Bcc
list in the first to add it. So Thunderbird should be able to show the
Bcc list itself regardless of what e-mail protocol is used. The Bcc
header wasn't included in the message when sent via SMTP so the server
wouldn't have that header. If IMAP is being used to later create a new
instance of the message with the Bcc header then Thunderbird has the Bcc
list to add it, so why not just show it?

Gmail is not involved in this test case so whatever Gmail is doing to
reject APPENDs or modification of message content is not relevant.
Perhaps Mozilla decided to shove up a new copy of the message with the
Bcc header added (since APPEND does not send a copy to any recipient and
is just the sender's own copy) so the Bcc list would be available to
multiple clients instead of just the one that originally sent the
message. Yet that seems to fuck up the fidelity of the e-mails by
placing whatever local data the client wants to add to the message copy
stored up on the server. What the recipient receives does not match the
copy stored on the server.

If Thunderbird is showing its recorded Bcc list for items in only the
local Sent folder and not for the account Send folders then that seems a
bug. Thunderbird had to maintain the Bcc list itself to show it
anywhere so that it doesn't show it in other the local Sent folder is a
defect in behavor. I'm still wading through the 139 bugs (30 are still
Open) that mention "bcc". I do not want to mash up sent items from all
accounts together in one Sent folder (the local copy).

[David E. Ross]

Windows 7 (x64)
Thunderbird/24.3.0
E-mail via SMTP and POP3

Every January, I send out an annual newsletter. For those whose E-mail
addresses I have, I create a Web page for the newsletter and send a
brief E-mail message with the link; the rest of the recipients receive
the newsletter via postal mail.

For relatives, I break down the distribution between cousins on my
mother's side, cousins on my father's side, and the same for my wife's
cousins. This means four E-mail messages with the addresses for each in
the To: header field. After all, the cousins in each group know each
other; there is no point in hiding the addresses from them. For
friends, however, I send the E-mail messages with the addresses in the
Bcc: header field.

I keep the outgoing messages and any replies until the following
January, when I do a new newsletter. I just checked the outgoing
messages from January 2014. I can see the Bcc: addresses when I select
[View > Message Source] on the Thunderbird menu bar. I can also see
them if I select [View > Headers > All] on the menu bar; since I have
the Compact Headers extension installed, that also requires that I
select the boxed + at the left of the header area in the message display.

Note that I retain both outgoing and incoming E-mail messages locally on
my PC, never on my ISP's mail server.

--

David E. Ross
<http://www.rossde.com/>

On occasion, I filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam, flames, and trolling from that source.

[Good Guy]

No problems here. I used Yahoo, hotmail and another yahoo account as
bcc and I can see the bcc address in my yahoo inbox.

<https://www.flickr.com/photos/118971147@N06/13091784275/lightbox/>

Using latest version of TB; See the message header to get the version
number; I can't remember myself these days.

[VanguardLH]

Which e-mail provider are you using? In the other subthread, I found
out what Thunderbird is doing to add the Bcc *header* to sent e-mails
(i.e., they're using "versioning" to corrupt the server copy) and why
Gmail refuses to allow its users to lie in the server copy what they
sent to the recipients. I'm using Hotmail and perhaps Microsoft also
doesn't want senders to have changed copies on the server than what got
sent to the recipients. Whose e-mail service are you using?

[VanguardLH]

Just read https://bugzilla.mozilla.org/show_bug.cgi?id=693495#c3.
Mozilla is fucking up e-mail fidelity by trying to create multiple
"versions" of the same e-mail.

Thunderbird is modifying the message after sending it. The only I can
figure out how Thunderbird is doing this via IMAP is to use the APPEND
by creating a *new* message with a message literal argument that
consists of the old version plus whatever Thunderbird decides to add,
like the Bcc header (and probably following by a FLAGS \Deleted command
to flag the old version and issue EXPUNGE to then delete the original
message). Thunderbird is modifying the message (by sliding in a new
version). It means the copy on the server that the recipient got can be
modified so it no longer matches what the recipient got. That sucks.

Do other e-mail clients go modifying (versioning) the messages already
sent to the server to then add what should be local-side information?
Modifying a sent message (the copy up on the server) is really nasty
behavior. That means what users of Thunderbird send and what the
recipient(s) get may not match. Thunderbird can change anything it
wants, not just the Bcc issue, in the server-side copy. What a rude
client.

Since the behavior described for Gmail IMAP is also what I see with
Microsoft's IMAP, and I quite understand their unwillingness of
permitting clients to modify the sent copy of an e-mail, then it looks
like Hotmail also does not permit versioning to lie in the server copy

what got sent to the recipients.

Looks like I will have to use mailmerge with this client to maintain a
correct and accurate server-side copy (i.e., what's there and remains
there is what I sent, not what the client wants to later modify) while
maintaining privacy of e-mail addresses between the recipients.

[David E. Ross]

On 3/11/2014 3:22 PM, VanguardLH wrote [in part]:
>
> Do other e-mail clients go modifying (versioning) the messages already
> sent to the server to then add what should be local-side information?
> Modifying a sent message (the copy up on the server) is really nasty
> behavior. That means what users of Thunderbird send and what the
> recipient(s) get may not match. Thunderbird can change anything it
> wants, not just the Bcc issue, in the server-side copy. What a rude
> client.
>

It has been known for several years that Thunderbird changes plain-text
messages with format=flowed disabled to the extent that such messages
cannot be digitally signed. See bug #363302 at
<https://bugzilla.mozilla.org/show_bug.cgi?id=363302>. This bug was
marked Rsolved/Invalid because the Mozilla developers decided that such
changes are not wrong, that for some reason the users should appreciate
such changes.

[David E. Ross]

On 3/11/2014 3:21 PM, VanguardLH wrote:

My ISP is Sunset.net, a local service about 500 miles away in northern
California.

[Ken Whiton]

*-* On Tue, 11 Mar 2014, at 05:59:06 -0500,
*-* In Article <wIednRyxu57ncYPO...@mozilla.org>,
*-* VanguardLH wrote
*-* About Re: How to show Bcc recipients of sent e-mail

> Ken Whiton wrote:

>> *-* VanguardLH wrote

>>> Thunderbird 24.3.0
>>> Windows 7

>> [ ... ]

>>> Anyone have a clue why a selected sent e-mail where in the Sent
>>> Items folder recipients were specified in the Bcc field doesn't

>>> the Bcc field? Did Mozilla drop showing that field?

>> I see the Bcc header displayed in items in the Mailed Folder
>> in both TB 1.5.0.14 and TB 17.0.5 under Windows XP, so if they've
>> dropped showing it it's within the past year.

>> <http://tinypic.com/r/294nxio/8>

>> The upper portion of the image is the header display in TB 1.5.0.14
>> and the lower portion is the header display in TB 17.0.5.

>> I find nothing in the Config Editor that would appear to
>> affect whether or not that particular header is displayed.

>> Have you tried restarting with add-ons disabled, to see if it
>> might be a conflict with an installed add-on?

>> Help --> Restart with Add-ons Disabled...

>> If nothing else works, you should be able to see the names of
>> the Bcc recipients by viewing the Message Source.

>> View --> Message Source

>> or use the <Ctrl-U> keyboard shortcut.

> In your header section in the view pane, I see:

> + Subject
> From
> Reply To
> Date
> To
> + Bcc
> User-Agent

> You also show another header section but I don't know if the top one
> is some special view or add-on and the bottom one is the regular
> header section, or if you showed 2 separate e-mails and their header
> section. Your bottom one has:

> From
> Subject
> To
> Bcc
> User-Agent

That image is a composite showing the header sections of two
different screen shots, which show the same message displayed in two
different versions of TB. The upper one is the header section in TB
1.5.0.14 and the lower one is the header section in TB 17.0.5.

> All I have in mine (which only has 1 header section) is:

> From
> Subject
> To

> No Bcc or Date fields.

Note that my lower one has no (labeled) Date field either. TB
hasn't displayed a labeled Date header since v. 3.x. Instead it
displays the date, unlabeled, at the far right of the header section.

> I suspect your 1st example is when showing
> all headers via View -> Headers -> All hence the scrollbar in your
> example.

No. Both versions of TB are set to View -> Headers -> Normal.
The scrollbar results from an entry in my userChrome.css file, and
appears in cases like this, where it's (apparently) not needed, as a
result of a minor bug in early versions of TB.

> When I pick that view and scroll up and down, there is
> still no Bcc field.

Do the Bcc items show in the Message Source window when you open
it? That last comment of yours suggests that they're not there. I've
been working under the assumption that they're there and TB just isn't
displaying them, but if they're not in the source then of course TB
can't display them. In that case, your problem becomes "why aren't
they there?", and I have no idea in that case. :-(

[VanguardLH]

David E. Ross wrote:

> VanguardLH wrote:
>
>> Which e-mail provider are you using? In the other subthread, I found
>> out what Thunderbird is doing to add the Bcc *header* to sent e-mails
>> (i.e., they're using "versioning" to corrupt the server copy) and why
>> Gmail refuses to allow its users to lie in the server copy what they
>> sent to the recipients. I'm using Hotmail and perhaps Microsoft also
>> doesn't want senders to have changed copies on the server than what got
>> sent to the recipients. Whose e-mail service are you using?
>
> My ISP is Sunset.net, a local service about 500 miles away in northern
> California.

From the other subthread, and from what I'm told, Mozilla lets their
client alter the server-side copy of a message when using IMAP. The
only way I can think of how they are doing this is by using APPEND to
create a *new* message on the server (this does not get sent out but
just created on the server) and then deleting (expunging) the old copy.
It is unconscionable and perhaps that Mozilla behaves as though any
content of a message is their property to modify however they choose.
Since I never granted Mozilla that permission, it is also illegal.

I can fully understand why Gmail bans this behavior. I'm using Hotmail
and perhaps Microsoft also bans this rude behavior, especially since
e-mails may be used in court as evidence. Mozilla decides to modify the
content however they want as though it's their property. Gmail (and
possibly Hotmail) expose wrong behavior by Thunderbird in trying to save
client-side information (or anything Mozilla chooses) inside the message
by modifying the already-sent copy.

If users want to allow their clients to modify their e-mails after they
got sent then it should be a server-side config option in the user's
account. This is a security issue to avoid unauthorized versioning that
IMAP will permit. That you grant Mozilla access to your e-mail service
by configuring the login credentials within their client does not grant
them permission to alter your e-mails. Another security measure but
something that servers would have to implement is to allow APPEND but
then block any expunge of the original message. Of course, that means
the user will see similar duplicates of their message when using a
client like Thunderbird, plus users would get stuck with having to use a
webmail UI to delete the old versions to show the *user* decided to get
rid of the old versions rather than rude an unauthorized action by an
e-mail client.

Too bad all e-mail providers don't block "versioning" (replacing already
sent e-mails) by clients. If they did, Thunderbird would have to come
up with a polite solution to handle their own tracking of their client
information that doesn't attempt to modify already sent messages up on
the server.

[VanguardLH]

David E. Ross wrote:

> VanguardLH wrote [in part]:
>
>> Do other e-mail clients go modifying (versioning) the messages already
>> sent to the server to then add what should be local-side information?
>> Modifying a sent message (the copy up on the server) is really nasty
>> behavior. That means what users of Thunderbird send and what the
>> recipient(s) get may not match. Thunderbird can change anything it
>> wants, not just the Bcc issue, in the server-side copy. What a rude
>> client.
>
> It has been known for several years that Thunderbird changes plain-text
> messages with format=flowed disabled to the extent that such messages
> cannot be digitally signed. See bug #363302 at
> <https://bugzilla.mozilla.org/show_bug.cgi?id=363302>. This bug was
> marked Rsolved/Invalid because the Mozilla developers decided that such
> changes are not wrong, that for some reason the users should appreciate
> such changes.

So after the hash has been computed for a message to generate the
digital signature, Mozilla decides to stupidly modify the message
afterward which invalidates the digital signature? Wouldn't this also
screw up encrypted messages? Although that bug got changed to "Closed
Invalid", it appears the rationale for closing the bug is invalid. I
could care less about possible workarounds one of which appears to let
recipients think invalidly signed messages are okay. If the recipient
gets a prompt that the message has been altered so the signature is
invalid, well, then its true regardless of Mozilla's viewpoint. Users
shouldn't have to go outside to an add-on (Enigmamail) as a workaround
to get security working in Thunderbird.

Does Thunderbird perform the same stupidity when using S/MIME to
digitally sign or encrypt messages? Altering messages during or after
transmission but after hashing or encryption is the same stupidity that
renders worthless (and alerts the recipient that a message is not
authentic or has been altered) when an e-mail provider tacks on their
spam promo signature on all outgoing messages. Usually this is a free
e-mail provider that wants to turn their users into spam affiliates.

I'm now digging into bugzilla checking what Mozilla decided about S/MIME
for digital signatures and encryption.

[VanguardLH]

Ken Whiton wrote:

> Do the Bcc items show in the Message Source window when you open
> it? That last comment of yours suggests that they're not there. I've
> been working under the assumption that they're there and TB just isn't
> displaying them, but if they're not in the source then of course TB
> can't display them. In that case, your problem becomes "why aren't
> they there?", and I have no idea in that case. :-(

Looking at the source of the message does NOT show a Bcc header but then
it shouldn't *if* Thunderbird is showing the actual content of the
message that got sent. The Bcc header should never be included in a
message; else, it obviates the entire purpose of the Bcc field if the
recipient can see it by looking in the headers.

From the other subthread, it appears when using IMAP that Mozilla
decided to alter the message to insert its client's information. This
has Mozilla altering your e-mails after they have been sent which also
means they will not match the copy the recipient got. Mozilla is
storing their client data inside the message. In this case, it means
Mozilla is inserting the Bcc header that should never had been placed
inside the message. It wasn't inside the message when connecting to the
SMTP server so that operation is correct. Later Mozilla modifies the
message for which the user never granted Mozilla permission to do so.

The problem with Gmail (and perhaps with Hotmail that I use) is that
they refuse to permit "versioning" of e-mails. That is, they don't
allow changing the e-mail after it has been sent. I understand that
behavior because the e-mail is the property of the user, not the author
of the e-mail program. It prevents clients from changing their e-mails
to differ from the copy the recipient got.

If you're looking inside the message and using IMAP so the message is a
copy of what is up on the server and you see a Bcc *header* inside that
message then it's because Mozilla altered your already sent message. It
also means Mozilla thinks they can alter your already sent e-mails
however they want. In this case, they are altering your e-mail to add a
Bcc header that was never supposed to be in that e-mail. The Bcc list
should only be client-side information tracked by the client, not by
altering e-mails already sent.

Gmail doesn't permit IMAP versioning of e-mails (i.e., altering the
server copy by creating a *new* copy using APPEND with modified message
content and then deleting the original). Perhaps Microsoft doesn't,
either. It's a security and ownership issue in permitting alteration of
e-mails after they've been sent.

[Good Guy]

On 12/03/2014 17:26, VanguardLH wrote:
>
> Looking at the source of the message does NOT show a Bcc header but then
> it shouldn't *if* Thunderbird is showing the actual content of the
> message that got sent. The Bcc header should never be included in a
> message; else, it obviates the entire purpose of the Bcc field if the
> recipient can see it by looking in the headers.
>

Your question is about seeing the bcc addresses in your sent box and if
this the case then I have no problems because I can see them but the
recipients of the message can't for obvious reasons as you have
summarized the position quite succinctly.

Even in the old version of TB on my Win7 machine (this one) there is no
problem. You need to reinstall the application under default settings
if the problem still persist on your machine.



--
Good Guy
Website: http://mytaxsite.co.uk
Website: http://html-css.co.uk
Email: http://mytaxsite.co.uk/contact-us

[David E. Ross]

When sending an E-mail message from your own computer via SMTP, the
message in your Sent folder represents what was sent to the SMTP mail
server; that includes the To:, Cc:, and Bcc: header fields. This is not
a problem since you are the one who composed the message, including
specifying the addresses for the Bcc: header field.

It is the SMTP server that strips away the Bcc: header field and
encloses the message in a SMTP envelope that contains the Bcc:
addresses. The addresses in the SMTP envelope are NOT reinserted into
the message's header section, and the SMTP envelope itself does not
appear anywhere in the message when it is received by the addressee.

See RFCs 5321 and 5322.

NOTE WELL: This process was created without the expectation that the
NSA would be collecting E-mail Internet packets in transmission. This
collection, of course, can include the SMTP envelopes. Also, a tap on
an SMTP server could collect the Bcc: header fields. While using Bcc:
to hide distribution lists from recipients works, this does NOT hide
distribution lists from the NSA.

[»Q«]

In <news:n6-dnTbUroopVL3O...@mozilla.org>,

"David E. Ross" <nob...@nowhere.invalid> wrote:

> When sending an E-mail message from your own computer via SMTP, the
> message in your Sent folder represents what was sent to the SMTP mail
> server; that includes the To:, Cc:, and Bcc: header fields. This is
> not a problem since you are the one who composed the message,
> including specifying the addresses for the Bcc: header field.
>
> It is the SMTP server that strips away the Bcc: header field and
> encloses the message in a SMTP envelope that contains the Bcc:
> addresses. The addresses in the SMTP envelope are NOT reinserted into
> the message's header section, and the SMTP envelope itself does not
> appear anywhere in the message when it is received by the addressee.
>
> See RFCs 5321 and 5322.

What you describe is what the initial MTA should do if the UA does not
provide an SMTP envelope. 5321 recommends that UAs provide envelopes,
in which case sending BCC headers would be superfluous and unwise.
Hopefully, Thunderbird follows the recommendation; I'd be surprised to
find out that it doesn't.

[VanguardLH]

David E. Ross wrote:

> When sending an E-mail message from your own computer via SMTP, the
> message in your Sent folder represents what was sent to the SMTP mail
> server; that includes the To:, Cc:, and Bcc: header fields. This is not
> a problem since you are the one who composed the message, including
> specifying the addresses for the Bcc: header field.

That would mean the message you see in an IMAP folder is *not* the
message up on the server. I thought the point of IMAP was to see in
your client the same copy of the message that was up on the server.

It's possible the client is overlaying the display of the IMAP message
by making it look like a Bcc header had been added; however, again, what
the client shows you for the headers isn't what are the headers in the
server copy of the message.

If the client is going to show its own information, like the Bcc list
(which should never be a header in the message) then that should be a
separate field shown within the client's UI, not lie that it was a
header.

If Tbird was merely showing a pseudo-header on the client side for the
Bcc "header" then the bug report you mentioned would be a non-issue.
There would be no problem with Gmail if the Bcc list were merely
presented as a fake header on the client side.

If you're claiming that the headers shown by Thunderbird are not those
in the actual e-mail up on the server then IMAP isn't performing as
expected by showing you locally what is up on the server. For an e-mail
that you Bcc'ed to some recipients, and for an IMAP account, do you see
the Bcc header only in Thunderbird's view of the e-mail or do you also
see the Bcc header in that e-mail when using your e-mail provider's
webmail UI to look at the source of that e-mail? That is:

- Using an IMAP account.
- E-mail sent to Bcc recipients.
- See Bcc header in Tbird's copy of the e-mail.
- Is the Bcc header absent from the e-mail when using the webmail UI?

> It is the SMTP server that strips away the Bcc: header field and
> encloses the message in a SMTP envelope that contains the Bcc:
> addresses.

If the client includes the Bcc header in the message sent to the SMTP
server via the DATA command then the client is definitely broken. You
cannot rely on the server stripping out a Bcc header. The RFCs do *not*
demand that servers strip out the Bcc header. The RECOMMEND and SHOULD
clause cannot be relied upon as supported by the e-mail server. In
fact, there are tons of SHOULDs and RECOMMENDs that mail servers don't
honor.

The RFCs do permit the client to include the Bcc header within the
message literal (what gets sent within the DATA command to the SMTP
server). It is recommended that the client does NOT include the Bcc
header. Why? Because it is not guaranteed nor mandated that the MTAs
strip out this header. The MTAs aren't even required to look at
anything inside the DATA content to deliver the message.

http://www.rfc-editor.org/rfc/rfc5322.txt
Section 3.6.3 - Destination Address fields

The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
addresses of recipients of the message whose addresses are not to be
revealed to other recipients of the message. There are three ways in
which the "Bcc:" field is used. In the first case, when a message
containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
removed even though all of the recipients (including those specified
in the "Bcc:" field) are sent a copy of the message. In the second
case, recipients specified in the "To:" and "Cc:" lines each are sent
a copy of the message with the "Bcc:" line removed as above, but the
recipients on the "Bcc:" line get a separate copy of the message
containing a "Bcc:" line. (When there are multiple recipient
addresses in the "Bcc:" field, some implementations actually send a
separate copy of the message to each recipient with a "Bcc:"
containing only the address of that particular recipient.) Finally,
since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
sent without any addresses indicating to the recipients that blind
copies were sent to someone. Which method to use with "Bcc:" fields
is implementation dependent, but refer to the "Security
Considerations" section of this document for a discussion of each.

So, in fact, the server should NOT strip out the Bcc header if the
client included it because, for example, the client may be issuing a
separate instance of the message to each recipient and only that
recipient is specified in the Bcc header that the recipient will see.
This is akin to a mailmerge where each recipient will see a Bcc header
but it only contains that particular recipient's address. Typically a
mailmerge puts the recipient in the To header but showing it in the Bcc
header lets that recipient know they were Bcc'ed.

Section 5 - Security Considerations

For example, if using the first method
described in section 3.6.3, where the "Bcc:" line is removed from the
message, blind recipients have no explicit indication that they have
been sent a blind copy, except insofar as their address does not
appear in the header section of a message.

It is the client's responsibility to propery handle the Bcc header, not
the server's. The server may strip out the Bcc header during the SMTP
session but that requires additional overhead at the server to
interrogate and parse the message literal sent during the DATA command
and then rearrange lines up by one after stripping out the Bcc header
(since a blank line would result in improperly delineating the end of
the header section).

The only real requirement is that a Bcc recipient cannot see the *other*
Bcc'ed recipients, not that there is no Bcc header in the received copy
of the message. My [old] knowledge of a few MTAs is:

Exim: Removes the Bcc header if present in the message literal sent
using the DATA command if and only if Exim is loaded with the -t
command-line switch; else, Exim leaves the Bcc header alone (it does not
inspect and modify the message literal).

OpenWave, InterMail, MS SMTP, MS Exchange, and qmail behave the same as
Exim's default (without the -t switch). They leave the message literal
alone; i.e., they do not strip out the Bcc header.

Sendmail (in some configurations), Postfix, and Lotus Notes strip out
the Bcc header.

> The addresses in the SMTP envelope are NOT reinserted into
> the message's header section, and the SMTP envelope itself does not
> appear anywhere in the message when it is received by the addressee.

That's because the recipient never sees the list of *commands* sent from
the sender's client to their SMTP server. Those commands are all the
SMTP server requires to specify all the recipients for the message
containing in the one message copy sent to the SMTP server via the DATA
command.

> See RFCs 5321 and 5322.

I did, and it does not mandate any SMTP server must strip out the Bcc
header. Doing so can obviate the intention of the client to, for
example, show each recipient (with only their e-mail address in the Bcc
header) that they were a Bcc'ed recipient rather than have to rely on
them recognizing their e-mail address does not appear in either the To
or Cc headers. They get positive evidence they were Bcc'ed rather than
using negative evidence by the absence of their e-mail address.

Pine, MS Outlook, Outlook Express, and most MUAs never insert the Bcc
header so it doesn't matter if the MTA strips it out or not. I heard
Mutt will add the Bcc header and assumes the MTA will strip it out (but
then it doesn't know the behavior of the MTA).

You might hope the server strips out the Bcc header but that is not its
responsibility and it looks like the majority of MTA does not strip out
the Bcc or do anything on the message. The overhead to inspect and
modify the message literal in the DATA command would incur a huge
expense in resources and slow the server (unless it batches it message
transfers to allow for the overhead but then delays delivery of the
messages).

[Tanstaafl]

On 3/12/2014 1:26 PM, VanguardLH <V...@nguard.LH> wrote:
> Looking at the source of the message does NOT show a Bcc header but then

> it shouldn't*if* Thunderbird is showing the actual content of the

> message that got sent. The Bcc header should never be included in a
> message; else, it obviates the entire purpose of the Bcc field if the
> recipient can see it by looking in the headers.

Someone is very confused. Hopefully it isn't me.

Note: I'm not sure about how PGP signed messages re affected by this, but...

First, Thunderbird doesn't 'send' email messages. It submits them to an
MTA for sending. It is the MTA that actually sends the email.

AIUI, Thunderbird doesn't add the recipient headers, it simply sends the
message with the recipients as specified.

It is the MTA (in my case, postfix) that decides which headers are
actually added to the message, and which aren't. It adds the To and CC
headers when it sends the message, and omits the BCC recipients from the
headers.

The reason the BCC headers exist in the Sent copy of the message is
because the message is not SENT to the Sent folder, it is simply COPIED.

In other words, the actual sending of the email is one SMTP transaction,
and the 'Save to Sent' operation is a 'SAVE' (or 'COPY') transaction.

So, yes, *you* will see the BCC'd recipients on the copy of the email in
*your* sent folder, but the RECIPIENTS will not see ANY of the (other)
BCC'd recipients, only the other To and CC'd recipients.

Question: are these headers actually included in the computation of the
PGP 'signature'?

[David E. Ross]

No. Only the the content displayed in the compose window is signed.
The header section is not included when the message is hashed for
generating the signature. With the version of PGP that I use, the
context menu function is labeled "Current Window > Sign".

Actually, it should be possible to sign the content and then add content
beyond the signed portion without invalidating the signature. However,
doing that would indeed be strange.

[VanguardLH]

Tanstaafl wrote:

> VanguardLH wrote:
>
>> Looking at the source of the message does NOT show a Bcc header but then

>> it shouldn't *if* Thunderbird is showing the actual content of the

>> message that got sent. The Bcc header should never be included in a
>> message; else, it obviates the entire purpose of the Bcc field if the
>> recipient can see it by looking in the headers.
>
> Someone is very confused. Hopefully it isn't me.
>
> Note: I'm not sure about how PGP signed messages re affected by this, but...
>
> First, Thunderbird doesn't 'send' email messages. It submits them to an
> MTA for sending. It is the MTA that actually sends the email.

The SMTP protocol doesn't care if it's a MUA or MTA doing the sending
(which you want to differentiate by injecting the term "submit"). The
sending SMTP server is the MUA to the MTA to which it connects. How are
the SMTP commands issued by your e-mail client to submit (or send)
different than the SMTP commands used by your sending SMTP server?

Because the same SMTP protocol is used regardless of whether an e-mail
client or e-mail server, MUA, UA, and MTA are often confusing since an
MTU behaves as an MTA but merely differentiates it as the client versus
a server. Thusly, the RFCs have moved to "SMTP client" and "SMPT
server" to denote the client-server relationship which may be e-mail
client to e-mail server or e-mail server to another e-mail server.

> AIUI, Thunderbird doesn't add the recipient headers, it simply sends the
> message with the recipients as specified.

The To and CC fields, if not blank, are added as headers in the message
literal sent by the e-mail client or the SMTP server during the DATA
command to the receiving SMTP server. The client should not include the
Bcc list as a Bcc header in the message literal.

The SMTP server uses the separate RCPT TO commands to define the
recipients, not the values of the To, Cc, and Bcc (if present) in the
message literal sent by the DATA command.

Simple Mail Transfer Protocol
http://www.rfc-editor.org/rfc/rfc5321.txt
2.3.1. Mail Objects

SMTP transports a mail object. A mail object contains an envelope
and content.

The SMTP envelope is sent as a series of SMTP protocol units
(described in Section 3). It consists of an originator address (to
which error reports should be directed), one or more recipient
addresses, and optional protocol extension material.

It's the envelope from the SMTP client that tells the SMTP server who
are the recipients. The "content" is sent using the DATA command.

> It is the MTA (in my case, postfix) that decides which headers are
> actually added to the message, and which aren't. It adds the To and CC
> headers when it sends the message, and omits the BCC recipients from the
> headers.

Your server is prepending MORE headers onto the message. Your server
should not be modifying the content submitted by the DATA command which
has the To, Cc, From and other client-side specified headers unless it
is going beyond just SMTP, like ensuring the From header's value matches
the e-mail address of the account from which a message originated (i.e.,
the sender cannot lie from where they sent a message). If your server
was "adding headers", where would it get the To, Cc, From, and other
headers that it "added"? Those do not have to match the list of RCPT TO
commands issued by the SMTP client unless the server's admin wanted to
enforce some policies over the use of their service.

> The reason the BCC headers exist in the Sent copy of the message is
> because the message is not SENT to the Sent folder, it is simply COPIED.

Perhaps true for the Local Folders's Sent folder. The Sent folder shown
in the IMAP account's should be the same copy as up on the server.

> In other words, the actual sending of the email is one SMTP transaction,
> and the 'Save to Sent' operation is a 'SAVE' (or 'COPY') transaction.

For POP accounts, true. POP has no concept of folders, just a mailbox.
The folders you see in your client other than the Inbox folder (which is
the mailbox up on the server) are all local folders merely for
organization within that client. For IMAP account, the folders and
their contents you see mirror those up on the server. What you see in
an IMAP folder in your local e-mail client should reflect the same
content in the folder up on the server. Since multiple clients may be
concurrently accessing the same account, they should all be seeing the
same content.

> So, yes, *you* will see the BCC'd recipients on the copy of the email in
> *your* sent folder, but the RECIPIENTS will not see ANY of the (other)
> BCC'd recipients, only the other To and CC'd recipients.

The recipients don't see the Bcc list as a Bcc header because the client
is not supposed to add the Bcc header in the message literal sent via
the DATA command to the SMTP server.

Although the SMTP server relies on the envelope of commands to determine
who are the recipients, it can go further to deduce who were the Bcc'ed
recipients and store that information along with the message so the
sender can see the Bcc list. For example, the server may see 8 RCPT TO
commands sent to it to specify 8 recipients for a message. It can
interrogate the message literal sent in the DATA command to see there
are only 3 recipients specified in the To and Cc headers (assuming the
Bcc is not there for it to inspect). It can match up the 3 recipients
in the To and Cc headers in the message literal against the RCPT TO list
and deduce the other 5 recipients were Bcc'ed. So it is possible the
server could add info to your account to let you see the Bcc list. That
is an action performed by the server, and not because the Bcc header was
in any way transmitted to the server.

> Question: are these headers actually included in the computation of the
> PGP 'signature'?

I've not bothered with PGP since S/MIME and .x509 certs are more than
sufficient for digital signatures and/or encryption of e-mail. Ross
might know more about how PGP works. For S/MIME, everything might be
included for the DATA command's content, and that means any To, Cc,
From, and other client-generated headers it inserts into the message
literal.

Obviously the client can only encrypt all or part of the message literal
created by the client and sent during the DATA command. It is
confusing, though, whether or not headers are included.

Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
Message Specification
http://tools.ietf.org/html/rfc5751

1.5. Changes from S/MIME v3 to S/MIME 3.1

Header protection through the use of the message/rfc822 media
type has been added.

3.1. Preparing the MIME Entity for Signing, Enveloping, or
Compressing

S/MIME is used to secure MIME entities. A MIME entity can be a
sub-part, sub-parts of a message, or the whole message with all
its sub- parts. A MIME entity that is the whole message
includes only the MIME message headers and MIME body, and does
not include the RFC-822 header. ... If protection of the
RFC-822 header is required, the use of the message/rfc822 media
type is explained later in this section.
...
In order to protect outer, non-content-related message header
fields (for instance, the "Subject", "To", "From", and "Cc"
fields), the sending client MAY wrap a full MIME message in a
message/rfc822 wrapper in order to apply S/MIME security
services to these header fields. It is up to the receiving
client to decide how to present this "inner" header along with
the unprotected "outer" header.

This RFC is dated in 2010. However, if you look at RFC 3851 dated 2004
that this one obsoletes, it also mentioned the same header protection.
It is up to the client to decide what it includes.

I haven't yet used Thunderbird to digital sign or encrypt outgoing
message (using the recipient's public key) or received any back (for the
sender using my public key in a digitally signed message that I've
previously sent them) so I don't have an exhibit to inspect to see what
the header section looks like.

See http://www.mozilla.org/projects/security/pki/psm/smime_guide.html.
Alas, they chose not to include a datestamp so readers would know how
old is this article. It does not describe which parts of the message
literal gets hashed for a digital signature or for which parts get
included in the generated string for the encoded content. It isn't that
technically detailed a document. Even with an exhibit, I'm not that I
could tell if the encrypted content included the RFC-822 headers or not.

S/MIME is something that, I believe, has to be incorporate to the e-mail
client. PGP is add-on behavior (download GnuPG and use Enigmail; see
https://support.mozilla.org/en-US/kb/digitally-signing-and-encrypting-messages)
so I can see mis-timed behavior in Thunderbird of modifying a message
after the add-on generated the string could screw up PGP.

[Tanstaafl]

On 3/14/2014 3:23 PM, VanguardLH <V...@nguard.LH> wrote:
> Tanstaafl wrote:

>
>> VanguardLH wrote:
>>

> The SMTP protocol doesn't care if it's a MUA or MTA doing the sending
> (which you want to differentiate by injecting the term "submit"). The
> sending SMTP server is the MUA to the MTA to which it connects. How are
> the SMTP commands issued by your e-mail client to submit (or send)
> different than the SMTP commands used by your sending SMTP server?

MUa's do in fact 'speak SMTP', but sorry, that does not make them an MTA.

> Because the same SMTP protocol is used regardless of whether an e-mail
> client or e-mail server, MUA, UA, and MTA are often confusing since an
> MTU behaves as an MTA but merely differentiates it as the client versus
> a server.

What is an 'MTU'?

If you truly believe that amn MUA is the same as an MTA, please provide
just one example of an MUA that actually performs all of the steps to
'send' an email directly to the recipients MX.

> Thusly, the RFCs have moved to "SMTP client" and "SMPT
> server" to denote the client-server relationship which may be e-mail
> client to e-mail server or e-mail server to another e-mail server.

An MUA can *only* be an SMTP client.

An MTA can *act* as an SMTP client *or* server.

Big difference.

>> AIUI, Thunderbird doesn't add the recipient headers, it simply sends the
>> message with the recipients as specified.
>
> The To and CC fields, if not blank, are added as headers in the message
> literal sent by the e-mail client or the SMTP server during the DATA
> command to the receiving SMTP server. The client should not include the
> Bcc list as a Bcc header in the message literal.

It doesn't. That is where you acre confused.

The BCC recipient HEADER(s) is added *after* the SMTP submission to the
MTA, in the 'Save to Sent Folder' phase.

This is why you will see the BCC recipients in the message in the Sent
folder on non GMail accounts, but NOT on messages sent using GMail -
*because* the BCC recipient HEADERs are *not* generated/added by the
SMTP client (MUA).

>> The reason the BCC headers exist in the Sent copy of the message is
>> because the message is not SENT to the Sent folder, it is simply COPIED.

> Perhaps true for the Local Folders's Sent folder. The Sent folder shown
> in the IMAP account's should be the same copy as up on the server.

No clue what you mean here, you seem to be very confused.

>> In other words, the actual sending of the email is one SMTP transaction,
>> and the 'Save to Sent' operation is a 'SAVE' (or 'COPY') transaction.

> For POP accounts, true.

Sorry, but it is true for both POP and IMAP. GMail is an exception,
because it actually refuses to save your copy due to its de-duplication
bullshit (I hate that it works this way).

> The recipients don't see the Bcc list as a Bcc header because the client
> is not supposed to add the Bcc header in the message literal sent via
> the DATA command to the SMTP server.

And this is precisely how Thunderbird works - it does *not* add the BCC
headers sent via the DATA command, because MTA's couldn't care less if a
recipient is To, CC or BCC - it is simply a RCTP-TO transaction.

[VanguardLH]

Tanstaafl wrote:

> VanguardLH wrote:
>
>> The To and CC fields, if not blank, are added as headers in the message
>> literal sent by the e-mail client or the SMTP server during the DATA
>> command to the receiving SMTP server. The client should not include the
>> Bcc list as a Bcc header in the message literal.
>
> It doesn't. That is where you acre confused.
>
> The BCC recipient HEADER(s) is added *after* the SMTP submission to the
> MTA, in the 'Save to Sent Folder' phase.

So you're talking about what the *client* does with its copy of the
message, not what got sent to the SMTP server.

For IMAP then, how does the client resolve the difference between its
copy of the sent message where it added a Bcc header (that was absent in
the copy in the DATA command to the SMTP server) and the copy the server
will place in the Sent folder up on the server?

The Bcc header is not included in the message literal sent via DATA to
the server. The server is going to put a copy into its Sent folder and
that won't have a Bcc header. The local copy has a Bcc header added to
it AFTER submission to the server. So now there are 2 differing copies
of the message: one on the server without a Bcc header and one on the
client with an added-after-submission Bcc header.

Doesn't that mean to synchronize via IMAP that the client would have to
use the APPEND command to shove a new version of the same message up
onto the server and then expunge the original copy on the server?

I'm not talking about a local-only copy of sent messages in the Sent
folder under the Local Folders account. I'm talking about the Sent
folder under the IMAP account. I don't configure to save local copies
of sent messages. The Local Folders store is not used at all by my IMAP
accounts. I configure Thunderbird to save the sent messages in the Sent
folder of the IMAP account.

When you go into your IMAP account definition in Thunderbird, do you
actually have the option "Place a copy in" enabled? If so, do you have
that local copy placed in the Sent folder in the Local Folders account
or up on the IMAP server it its Sent folder? If you tell Thunderbird to
save its local copy in the IMAP's Sent folder then you will likely see 2
copies of your sent messages: one which is Thunderbird saving its local
copy into that IMAP folder along with your e-mail service saving the
copy it got via SMTP into the IMAP folder. I don't need 2 copies. I
only need the copy that the server got.

Perhaps some IMAP accounts do not save copies of sent messages from an
SMTP transaction into an IMAP folder. Some accounts will let you
configure if sent messages are saved and, if enabled, THEY store a copy
of the message from the SMTP session into your Sent folder in your IMAP
account up on the server.

Assuming you don't have an IMAP account that copies sent messages into
the server-side Sent folder in that IMAP account, we're still back to
Thunderbird modifying the message that got sent. Okay, so Thunderbird
modifies the message to add the Bcc header that only the sender can see
in their local copy of the message (to comply with RFCs that recipients
not see the Bcc list). Now what? After Thunderbird puts its local copy
in the IMAP account's folder in its local store, it doesn't synchronize
that copy up to the server? There has to be, at least, 1-way sync to
retrieve messages that some other client might've sent using the same
account, and that means downloading the message from the IMAP account's
folder.

Are you saying that what I see in an IMAP folder shown by Thunderbird is
not the same content for that message as stored up on the server? If
so, why doesn't Thunderbird's source view of the Bcc'ed message show a
Bcc header (that header certainly isn't in the server-side copy) yet all
the Bcc'ed recipients have acknowledged that they got my message.

I assumed, perhaps incorrectly, that what I see for content of a message
in an IMAP folder shown in Thunderbird is what is also synchronized to
be what is up on the server. If Thunderbird isn't retrieving messages
from IMAP folders up on the server, does it not see messages that were
sent by other clients using the same IMAP account? Or is it only blind
to the messages it sent through that IMAP account (so you only see a
local-only copy of the message)?

[VanguardLH]

The problem seems to stem from who has responsibility for populating the
IMAP Sent folder after sending a message. Does the mail server copy a
message from an SMTP session into the server-side IMAP folder and then
have clients download a copy in the Sent folder that the server put
there? Or does the client send the message twice: once to SMTP and then
again after it save a local copy in its own IMAP folder to put up on the
server?

If the mail server is copying the message from an SMTP session to an
IMAP folder and if the local e-mail client is also configured to save
its local copy of a sent message to the same IMAP folder then you end up
with a duplicated message in the same folder (except Thunderbird may
modify its local copy). That also means you probably end up with 2
copies of the message up on the mail server: one that it saved in that
folder and the uploaded (and possibly modified copy) saved there by the
client.

http://en.wikipedia.org/wiki/Internet_Message_Access_Protocol#Disadvantages

Unlike some proprietary protocols which combine sending and retrieval
operations, sending a message and saving a copy in a server-side
folder with a base-level IMAP client requires transmitting the message
content twice, once to SMTP for delivery and a second time to IMAP to
store in a sent mail folder. This is remedied by a set of extensions
defined by the IETF LEMONADE Working Group for mobile devices: URLAUTH
(RFC 4467) and CATENATE (RFC 4469) in IMAP and BURL (RFC 4468) in
SMTP-SUBMISSION

BURL is a verb to SMTP. The server ends up having the responsibility to
place a copy of the sent message into the IMAP folder (up on the
server). This eliminates the client from having to upload the message
twice: once via SMTP and again via IMAP. I don't know if BURL (and the
other extensions) were pushed because of an emerging mobile-centric
e-mail market (i.e., apps on smartphones) and the then incumbent
low-bandwidth for these devices resulting in slow performance. Not
everyone doing IMAP is doing so over a high-speed always-on cable or
fiber connection, and e-mails have progessively grown in size not only
due to HTML formatting (which doubles the size of an e-mail for one copy
in text/plain and another in text/HTML) but because of inclusion of
images, videos, and other binary attachments whether inline
(disposition=inline) or attached (disposition=attach).

E-mail account configuration up on the server often has the option
similar to "Save a copy of sent message". When using the webmail UI to
the account, the default behavior is to save a copy of the sent message
into the Sent folder. If the mail server supports the IMAP extensions
then this option may also apply to IMAP behavior in that the mail server
will save a copy of a message during an SMTP session into the Sent
folder in the IMAP folder up on the server (and clients will
retrieve/download that copy).

Whether the user employs a local e-mail client to access their IMAP
account or multiple local e-mail clients against the same account, and
because they expect the same view when using the webmail UI to their
IMAP account, like using Thunderbird at home, a mail app on a
smartphone, or a webpage when travelling or while at work to access a
personal account, they cannot simply disable the server-side option of
"Save a copy of sent message"; else, when using the webmail UI then
there will no copy saved in the Sent folder, and if this option also
applies to saving a copy of a message during an SMTP session (via BURL)
to the IMAP folder then disabling this option means there is no saved
copy in the Sent folder.

Apparently Thunderbird is still geared to the old basic IMAP scheme (no
extensions) where only 1 copy of the message is sent to the mail server
(via SMTP) and where it saves a local copy in its own local IMAP Sent
folder that it has to send again (via IMAP) up to the server to its Sent
folder. https://bugzilla.mozilla.org/show_bug.cgi?id=421779 was opened
back in 2008 and is still open. I don't know how many e-mail clients
(and servers) yet support BURL and the other IMAP extensions. It may be
that few do so IMAP providers decided to go ahead and copy the message
sent via SMTP to the IMAP Sent folder (if the "Save copy of sent
message" option is enabled). The result is that if BURL is not
supported (which it appears not to be in Thunderbird) and IMAP providers
masking this deficiency in clients that you could end up seeing 2 copies
of a sent message: a local copy saved into the Sent folder by the client
and the server-side copy saved into the Sent folder by the mail server.
Because you want the webmail UI to do the same as the local e-mail
client to save a copy of sent messages, that option must be enabled.

With servers emulating the BURL command for clients that don't use BURL
instead of DATA during an SMTP session, your choices are to disable the
"Save a copy of sent messages" option which means you won't have a saved
copy when using the webmail UI to send messages, or to leave enabled by
default this option and tell your e-mail client not to save a copy of
its [modified] message (to then duplicate the send operation by having
to upload a copy from its Sent folder up to the server again). Since I
want my webmail UI to save a copy of sent messages, I have to leave this
option enabled. Alas, that means the servers that I use also save a
copy of the message from an SMTP session despite Thunderbird doesn't use
BURL, so I have to disable Thunderbird from saving its own local copy
into the Sent folder which would result in 2 copies of the message in
that folder.

Because the server is placing a copy of the sent message in the IMAP
server's Sent folder from an SMTP session, and to eliminate duplicates
of the same message, I have Thunderbird configured to not save its own
local copy (which it would have to later upload and add a duplicate up
on the server). I only see the server's copy of the message in the IMAP
folder, not Thunderbird's modified copy. Thunderbird usurps the message
to insert client information into the message. This will not match the
message copy that was sent via SMTP and that the server places into the
IMAP Sent folder. To eliminate duplicates and so I see what the
recipient actually received, I'll stick with seeing the server's copy of
the message. That means not seeing Thunderbird's modified version.

- IMAP account is configured up on the server to "Save a copy of sent
message".
o Needed so webmail UI will save a copy.
- Mail server saves a copy of message sent via SMTP into the server-side
IMAP Sent folder.
o Probably to accomodate clients that don't support BURL.
o Since a copy is put into the Sent folder by the server, the client
putting one there results in a duplicate copy.
- Configure Thunderbird to NOT save its own local copy into its local
IMAP Sent folder.
o Eliminates local duplication of message (after Thunderbird
retrieves server-side copy of sent message).
o Eliminates uploading the duplicate (but slightly modified) version
of the message to the server.
o Eliminates other clients connecting to same IMAP account from
seeing duplicated message.
o The server emulating BURL on behalf of a client that doesn't use
it results in faster updating of the account.
* The server is immediately updated.
* Since download bandwidth typically far exceeds upload
bandwidth, the client quickly retrieves the server-side copy
of the sent message rather than [far] more slowly uploading
its own copy of it.
- Result: I don't get to see Thunderbird's modified/versioned copy of
the sent message.

If Thunderbird supported BURL (circa 2006), this thread wouldn't exist.
Because the IMAP server puts a copy of a message sent via SMTP into the
IMAP folder on the server, I can't have Thunderbird saving its
modified/versioned copy into its local Sent folder to then duplicate the
one on the server. I'll have to use mailmerge to send to multiple
recipients instead of using Bcc, or send individually for a low-count
announcement.

So the same effect of not seeing the Bcc header when using Hotmail and
Gmail have 2 different causes. Hotmail saves a copy of e-mails sent via
SMTP into the server-side IMAP Sent folder probably to mask that a
client doesn't support BURL so Thunderbird cannot also be saving its own
copy into the same folder. Gmail rejects message versioning which seems
a security issue; i.e., what the recipient got is not what is stored on
the server. Oh well, live and burn.

[Tanstaafl]

On 3/16/2014 8:24 AM, VanguardLH <V...@nguard.LH> wrote:
> The problem seems to stem from who has responsibility for populating the
> IMAP Sent folder after sending a message. Does the mail server copy a
> message from an SMTP session into the server-side IMAP folder and then
> have clients download a copy in the Sent folder that the server put
> there? Or does the client send the message twice: once to SMTP and then
> again after it save a local copy in its own IMAP folder to put up on the
> server?

The latter is correct, and always has been.

The *only* MTA that I know of that does this automatically is GMail
(again, as I described in one of my posts).

As I said, you obviously had a long standing fundamental
misunderstanding of the process - but now you have corrected that... :)

[Mark Filipak]

On 2014/3/16 11:00 AM, Tanstaafl wrote:
> On 3/16/2014 8:24 AM, VanguardLH <V...@nguard.LH> wrote:

>> The problem seems to stem from who has responsibility for populating the
>> IMAP Sent folder after sending a message. Does the mail server copy a
>> message from an SMTP session into the server-side IMAP folder and then
>> have clients download a copy in the Sent folder that the server put
>> there? Or does the client send the message twice: once to SMTP and then
>> again after it save a local copy in its own IMAP folder to put up on the
>> server?
>

> The latter is correct, and always has been.
>
> The *only* MTA that I know of that does this automatically is GMail
> (again, as I described in one of my posts).
>
> As I said, you obviously had a long standing fundamental
> misunderstanding of the process - but now you have corrected that... :)

Tanstaafl,

May I ask a question?

Does the mail client ALWAYS populate the mail server's SENT
folder/directory?

(I suspect that it does, even when it's not going to save a local copy.)

--
The Insect Hall of Fame:
Thunderbird Bug 121947 - 12 years and counting.

[VanguardLH]

Tanstaafl wrote:

> On 3/16/2014 8:24 AM, VanguardLH <V...@nguard.LH> wrote:
>> The problem seems to stem from who has responsibility for populating the
>> IMAP Sent folder after sending a message. Does the mail server copy a
>> message from an SMTP session into the server-side IMAP folder and then
>> have clients download a copy in the Sent folder that the server put
>> there? Or does the client send the message twice: once to SMTP and then
>> again after it save a local copy in its own IMAP folder to put up on the
>> server?
>
> The latter is correct, and always has been.

True if the IMAP extensions are not supported. That is, if the client
supports only the old IMAP protocol proper.

[Tanstaafl]

On 3/16/2014 11:20 PM, Mark Filipak <markfilip...@gmail.com> wrote:

> On 2014/3/16 11:00 AM, Tanstaafl wrote:
>> On 3/16/2014 8:24 AM, VanguardLH<V...@nguard.LH> wrote:

>>> The problem seems to stem from who has responsibility for populating the
>>> IMAP Sent folder after sending a message. Does the mail server copy a
>>> message from an SMTP session into the server-side IMAP folder and then
>>> have clients download a copy in the Sent folder that the server put
>>> there? Or does the client send the message twice: once to SMTP and then
>>> again after it save a local copy in its own IMAP folder to put up on the
>>> server?

>> The latter is correct, and always has been.
>>

>> The*only* MTA that I know of that does this automatically is GMail

>> (again, as I described in one of my posts).
>>
>> As I said, you obviously had a long standing fundamental
>> misunderstanding of the process - but now you have corrected that...:)

> Does the mail client ALWAYS populate the mail server's SENT
> folder/directory?
>
> (I suspect that it does, even when it's not going to save a local copy.)

The default for every MUA I've ever used is to save a copy of all Sent
Messages.

In Thunderbird (my preferred client for the last 9+ years or so), if you
set up an IMAP client, the default is to save the copy of Sent Messages
to an IMAP folder called 'Sent'.

But the bottom line is, this has historically always been a CLIENT
behavior/feature/function - with the one exception I know of currently
being GMail. I don't know about any of the other cloud based services -
Outlook.com? Yahoo.com?

[Tanstaafl]

No clue what you are talking about.

[Chris Ramsden]

On 2014-03-17 10:13, Tanstaafl wrote:
> But the bottom line is, this has historically always been a CLIENT
> behavior/feature/function - with the one exception I know of
> currently being GMail. I don't know about any of the other cloud
> based services - Outlook.com? Yahoo.com?

This is reasonable, is it not, in the general situation where the SMTP
server and IMAP servers are distinct and separate? I.e. One at the
user's ISP, the other at the mail provider. The IMAP server doesn't
necessarily have any direct view of what is being processed by the SMTP
server when sending.

And of course with POP the /only/ legitimate place for a "Sent" folder
would be within the client.
--
Chris

[VanguardLH]

Look up the BURL command (circa 2006) and already mentioned in my post
to which you replied. There's a bugzilla ticket to add support for it
but that was opened in 2008 and hasn't been addressed. Since
development on Thunderbird has ceased (other than for bugs or code they
can slide in from other projects), enhancements to catch up with IMAP
extensions aren't going to happen in Thunderbird.

[VanguardLH]

Tanstaafl wrote:

> The default for every MUA I've ever used is to save a copy of all Sent
> Messages.

Which you need to disable if the BURL command is supported by the client
since that tells the mail server to save a copy of the message sent via
SMTP into the Sent folder up on the server. It is a hell of a lot
faster to sync download from the server than sync upward. Rare few
users have symmetric Internet access. Instead they have asymmetric
speeds where upload bandwidth is a lot slower than download bandwidth.

Some mail servers, especially if configured to "Save a copy of sent
message", will emulate the BURL command knowing full well that many
clients don't yet support it. Thunderbird doesn't and never will. So
when you see duplicates of a message show up in the Sent folder, you
have to configure your client that relies only on the old IMAP protocol
alone to stop saving its local copy in the Sent folder (and then
uploading it to the server which is slow[er]).

> In Thunderbird (my preferred client for the last 9+ years or so), if you
> set up an IMAP client, the default is to save the copy of Sent Messages
> to an IMAP folder called 'Sent'.

Unless the mail server calls it something else. You need to subscribe,
refresh, and use whatever they call it (since it is unlikely the mail
server lets you rename that folder when using the webmail UI).

> But the bottom line is, this has historically always been a CLIENT
> behavior/feature/function - with the one exception I know of currently
> being GMail. I don't know about any of the other cloud based services -
> Outlook.com? Yahoo.com?

Yes, historically, up to 2006 when IMAP extensions allowed the client to
tell the server to create a sent copy up on the server. That eliminated
the client from having to send 2 copies of the same message: once via
SMTP and again via IMAP (to the Sent folder). Uploads are also
historically a lot slower than downloads. To make IMAP more responsive,
the server can be told (or will default or be configured) to save a copy
of the sent message. That means the client can use the much faster
download sync to see the message in the Sent folder.

Similarly, instead of having the local client search all through its
copies of messages in its local store, the server can be told to do the
search. I haven't yet bothered looking into this IMAP extended feature
but the premise is that it is faster for the server to do the search and
download the results than the client doing the search. Of course, this
presume the old linear search method rather than users employing
background indexing search programs.

[VanguardLH]

Correct. The BURL command would have to be supported by the client and
also the SMTP server. This tells the SMTP server to save a copy of the
sent message in the Sent folder (by default) up on the server. Then the
client uses the much faster download speed to retrieve a copy of the
sent message rather than the much slower speed to upload its copy to the
server.

The only caveat that I see with using BURL is that the SMTP and IMAP
servers you employ are with the same e-mail provider. If you use an
SMTP server at one provider but, for some reason, use IMAP at a
different e-mail provider than BURL won't work.

Thunderbird doesn't support BURL. It never will. So you're stuck with
the original scheme of having the client upload the sent copy to the
server over a much slower bandwidth. This can be a pain with some IMAP
servers that are slow or a node (host) in the route between you and the
IMAP server is slow, dead, or unresponsive. I haven't checked which
e-mail clients yet support the BURL command (the RFC is dated 2006).
Because I suspect most do not support BURL, some e-mail providers have
decided that if you enable the "Save a copy of sent message" option that
they will perform the BURL function: save a copy of a message sent via
SMTP into the server-side Sent folder and let clients retrieve it via
the much faster download speed than waiting for clients to upload via
the much slower upload speed.

Uploading the sent copy from client to the server can be excrutiatingly
slow. The route might be slow. The server might be slow. Upload
bandwidth is slow (compared to download bandwidth). That's the
historical method because extensions to SMTP to support BURL didn't
exist before 2006. That was 8 years ago. The bugzilla ticket to add
BURL support to Thunderbird is 6 years old. Thunderbird doesn't support
the IMAP extensions that would make IMAP much more responsive to the end
user of a local client.

So, in my case, because the SMTP server will effect the BURL command
whether the client uses or not (perhaps because few clients implement
BURL). That means the SMTP server will generate the server-side copy of
the sent message and the client can faster update because download speed
is far greater than upload speed. I have to disable Thunderbird from
saving its own local copy to do the historical and slow upload method to
the server. And that means I don't get to see Thunderbird's version of
the message that it modified to add the Bcc header. Considering how
much slower is uploading than downloading, I'll sacrifice being able to
see the Bcc header and let Thunderbird faster yank the server's copy of
the sent message. I won't be able to see the Bcc'ed recipients, or I'll
have to use mailmerge to send to those recipients.

[Tanstaafl]

On 3/17/2014 6:03 PM, VanguardLH <V...@nguard.LH> wrote:
> Tanstaafl wrote:
>
>> On 3/17/2014 2:09 AM, VanguardLH <V...@nguard.LH> wrote:
>>> Tanstaafl wrote:
>>>> On 3/16/2014 8:24 AM, VanguardLH <V...@nguard.LH> wrote:
>>>>> The problem seems to stem from who has responsibility for populating the
>>>>> IMAP Sent folder after sending a message. Does the mail server copy a
>>>>> message from an SMTP session into the server-side IMAP folder and then
>>>>> have clients download a copy in the Sent folder that the server put
>>>>> there? Or does the client send the message twice: once to SMTP and then
>>>>> again after it save a local copy in its own IMAP folder to put up on the
>>>>> server?
>>
>>>> The latter is correct, and always has been.
>>
>>> True if the IMAP extensions are not supported. That is, if the client
>>> supports only the old IMAP protocol proper.

>> No clue what you are talking about.

> Look up the BURL command (circa 2006) and already mentioned in my post
> to which you replied.

Oh I'm fully aware of the *potential* of BURL.

See this conversation I was a part of back in 2010 on the dovecot list:

http://www.dovecot.org/list/dovecot/2010-March/047291.html

It is one of many (some also happened on the postfix list).

So, please show me some real world examples of some real world servers
AND CLIENTS that offer full support for BURL with respect to
automatically saving Sent messages to a Sent folder.

The bottom line is, ALL email clients will, BY DEFAULT, enable 'Save to
Sent'. It has been like this for ages.

Don't get me wrong, I will be a happy man when this is not the case, but
until there is standard support in all of the most common servers AND
clients, it will be an oddity, nothing more.

> There's a bugzilla ticket to add support for it but that was opened
> in 2008 and hasn't been addressed.

Thanks, just voted for it...

https://bugzilla.mozilla.org/show_bug.cgi?id=421779

But again, there must be some kind of standardized support for this in
BOTH servers AND clients.

I believe that support for this capability is now in Dovecot through
Timo adding full support for the LEMONADE IMAP EXTENSIONS, but that the
full support for the auto Save to Sent would have to be implemented in a
plugin.

> Since development on Thunderbird has ceased (other than for bugs or
> code they can slide in from other projects), enhancements to catch up
> with IMAP extensions aren't going to happen in Thunderbird.

It is (sadly) likely you are correct - unless some wealthy benefactor
comes along...

But again - show me other mail clients and servers that fully support
this stuff... can you?

[Tanstaafl]

On 3/17/2014 6:25 PM, VanguardLH <V...@nguard.LH> wrote:
> Thunderbird doesn't support BURL. It never will. So you're stuck with
> the original scheme of having the client upload the sent copy to the
> server over a much slower bandwidth.

This is plain wrong.

According to Timo, Dovecot has this capability NOW - if some kind soul
would write the plugin - to do this NOW, with NO client support for BURL.

Basically, the dovecot submission proxy would save the copy according to
a prescribed layout (ie, you would have to define the name of the Sent
folder, etc), then dovecot would simply automatically save a copy of
every message sent using its submission proxy to that users sent folder.
No client involvement needed.

This is how GMail works NOW. No Client support needed.

[VanguardLH]

I already mentioned that the mail server can, on their own initiative,
copy to the Sent folder from the SMTP session. I don't know that
there's an RFC that mandates or even recommends that they do that.
Hotmail already does that, too. That is their choice regarding
*emulation* of BURL. That's why for some mail servers you have to
configure Thunderbird to NOT save a copy into its own Sent folder. With
Hotmail, having Thunderbird save its [modified] version along with
Hotmail saving a copy from its SMTP session results in 2 instances of
the message in the Sent folder. Gmail doesn't permit versioning so what
you end up with is 2 different versions of the e-mail that you sent:
Thunderbird's copy in its Sent folder with the Bcc header it added but
the copy of the message up on the server does not have the Bcc header
plus it has other headers not present in the local copy in Thunderbird.

Look at the bugzilla ticket that I already mentioned. It is still open.
If Thunderbird supported BURL then that ticket would've been closed. So
either you rely on the old IMAP scheme of having the client slowly
upload the message *twice* - once via SMTP and again using IMAP - or you
use a mail server that commits the BURL feature without the presence of
the BURL command from the client. If the server emulates BURL rather
than require the client to use BURL then you end up with either 2
duplicates of the message showing up in the Sent folder (the server
doesn't reject resubmission of the same message via IMAP that it already
copied from its SMTP session into the IMAP folder) or you end up with 2
different versions of the e-mail (the server rejects resubmission of the
same message via IMAP to prevent overwriting the copy it already put
into the Sent folder that it got via SMTP).

Dovecot got patched in 2.0 back in Jan 2011 to support BURL. That won't
work with Thunderbird which doesn't and probably never will support
BURL. So, like Hotmail and Gmail, and maybe Dovecot with its submission
proxy (if that happens which by implication from what you said isn't
there yet), the server itself could emulate BURL but users will end up
with differing versions on the client and server of the sent message or
they will end up with duplicates showing up in the Sent folder unless
the user configures the client to not save its own copy via IMAP.
Dovecot is just one of the many mail server programs in use. Exim
supports some LEMONADE extensions but not BURL. Looks like Postfix got
patched to support BURL in 2.7.0 back in 2010. Oracle added BURL in
their latest v7. Whether the mail admins enable BURL is another matter
as there are deployment issues regarding the trust relationship between
the submission and IMAP servers and what to do if the user resubmits via
IMAP the same message despite having issued the BURL command or the
server emulating BURL. Even mail servers that don't rely on the client
issuing BURL and emulate it on their own have these considerations. I
haven't checked if qmail supports BURL; however, if not doesn't preclude
using a workaround to emulate BURL whether the client used BURL or not.

Users don't get to dictate which mail server is used by their e-mail
provider. Mail servers may support the BURL command that is part of the
LEMONADE extensions but support on one end is worthless without support
on the other end. They can, if they choose, compensate for the client's
lack of BURL support by implementing their own workaround to do the
copy, anyway, from the SMTP session. I'm not arguing that mail server
cannot themselves do the copy from the SMTP session with or without
supporting BURL.

Dovecot already supports BURL (read its docs). Nice but worthless when
Thunderbird is the e-mail client. According to you, one day Dovecot may
do the automatic copy to the Sent folder from the message sent via SMTP
(or submission proxy) but it's not there yet. Gmail and Hotmail already
have that feature to compensate for e-mail clients that don't yet
support BURL while also keeping IMAP more responsive by having clients
download at faster bandwidth the sent copy rather than uploading at the
much slower bandwidth.

If you look at the market share of e-mail clients, mail servers have
optionally emulated BURL probably because few major e-mail clients yet
support it. Web apps, like those on smartphones, are small so they
don't have all the code to support everything a desktop client can
perform. It doesn't take much to see the mail server has BURL in its
response to say it supports it, the client to toggle between DATA and
BURL for SMTP commands, and remember not to save its own local copy of
the sent message and instead wait to retrieve it from the server but it
is more code. Do the e-mail apps on iOS devices support BURL? I
haven't found out yet if Microsoft Outlook (which versions, if any)
support BURL. Microsoft has been focused on their proprietary Deltasync
and EAS protocols. Hotmail didn't have IMAP support until Sept 2013.
Those are the 2 largest clients generating e-mail volume. Thunderbird
volume is very low (~1%) so mail servers didn't compensate just for its
lack of BURL support.

It becomes necessary for mail servers to emulate BURL probably because
the major volume generators for e-mail clients don't support BURL. Mail
servers want to reduce their load, too. Keeping an IMAP session open
for much longer for a client to upload the sent message is more
expensive than copying the message from the SMTP session to the database
to update a user's account along with the far shorter time for an IMAP
session to download the message. They help themselves while effecting
faster IMAP but it not yet a universal behavior.

So, per your mention, Dovecot already supports BURL. Thunderbird does
not. Like Hotmail, Gmail, and other mail servers that have chosen to
emulate BURL in the absence of clients using BURL, Dovecot might someday
also emulate BURL. Hotmail emulates BURL so to eliminate duplicate
copies of a sent message means not saving Thunderbird's copy. Gmail
also emulates BURL while also blocking message versioning. That
Thunderbird still implements the old scheme of uploading the sent
message to the Sent folder is still true. What the server does not
obviate that Thunderbird still uses the old scheme.