"undisclosed-recipients;"

[Peter Holsberg]

When I send an email and all the addresses are in Bcc;, TB inserts

To: undisclosed-recipients;

Short of my supplying a To: address, is there anyway to change
"undisclosed-recipients;" to something else?

Thanks.

[Vic Moz Garcia]

Several ways to do it:

Google "how to change undisclosed recipients Thunderbird".
Pick the one that fit you.

[Peter Holsberg]

Vic Moz Garcia has written on 2/20/2014 3:17 PM:

I found but two:

1) in the config editor, change mail.compose.add_undisclosed_recipients
to false

2) in the chrome folder, place a file called custom-strings.txt containing

chrome://messenger/locale/messengercompose/composeMsgs.properties#12566=Distribution
List

I did both. The "sent" message has no To: at all, but the receiver's
messages has

To: undisclosed-recipients;

[Millwood]

As I suspect you know this is possible in the underlying SMTP protocol.
I do it all the time from linux. It would be nice if thunderbird
supported it.

Basically, you send the mail containing a to: header of you choice to
each of the BCC addresses but don't insist on using the to: address.

You can use a to: address that looks ok - say dummy@dummy and it will
work and you'll get a delivery failure for dummy@dummy.

[Big_Al]

Peter Holsberg said on 2/20/2014 2:51 PM:

So you want to change an industry standard to something that is
non-standard. Thus confusing everyone with your new standard?

Outlook won't change, so all the other people that send bcc to your
friends will still be doing undisclosed recipients.

Seems like so much work for nothing.

[David E. Ross]

Outlook does not set any industry standard.

--

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.

[David E. Ross]

If my entire address list for a message is bcc, I put my own address in
the To: line. Some E-mail servers will reject any message received
without an address in the To: line.

[Vic Moz Garcia]

That probably does not work all the time.
The one I use is:
Create an entry in your AB:
Name: Distribution List
email: em...@example.com (valid address, but goes to nowhere)

Then, compose your emails as
To: Distribution List
BCC: list of valid email address.

It works like a charm.

[Millwood]

I don't know what standard you have in mind.

The smtp standard does NOT use the headers to decide where to deliver
mail. There is something called the "envelop" which is specified by
rcpt commands from the sender MTA to the receiver MTA. That's why bcc:
works at all. There is no bcc: header in the data - but the bcc:
addresses are specified in the envelop so the mail gets delivered.

[VanguardLH]

Those saying this string is standard are wrong. In fact, e-mails are
not required to even have a To field. It may appear a minimum of zero
times and a maximum of 1 times (i.e., it's optional and, if used, must
be used only once). It is NOT a header added by the server. It is
*data* added by the user's client and sent during the DATA command. It
is NOT used by the server for routing an e-mail. Your client compiles
an aggregate list of recipients from the To, Cc, and Bcc *fields* (not
headers yet) and then sends a separate RCPT TO command to the server for
each recipient in that aggregate list. That is why, for example, the
recipients that receive an e-mail may not be the ones listed by the
sender. Mailing lists work this way by having the content of an e-mail
in one file and a list of recipients in another file. The mailing list
client or bulk mail client sends a copy to each recipient in the list.

There is no requirement that the To field actually point at a recipient.
That header isn't even required per RFC. It's up to the e-mail client
to figure out from where it will get a list of recipients to specify in
the RCPT TO commands it issues to the server. So the To header (which
is *data* in the message) could specify bogus recipients that don't
match the real recipients.

Outlook Express would also add the "undisclosed recipients" string in
the To header if all recipients were specified only in the Bcc *field*
in the new-mail compose window. Outlook would complain the To field was
empty. I haven't bothered doing mailing lists in Thunderbird but I
suspect the solution is the same as for OE (where you want something
else then "undisclosed") and for Outlook: create a contact with whatever
name you want recipients to see in the To header in the received e-mail.
Create a contact with whatever name you want in the comment field (i.e.,
Username field). If you are sending a newsletter about a Sierra club
event, you could use "Sierra newsletter" as the username. You should
put your own e-mail address in that contact, or use an e-mail address to
which replies will be accepted even if replies get discarded upon
receipt (but then you should note in the body not to reply to that
address). Then when you compose a mailing where all recipients are in
the Bcc field (so not to divulge e-mail addresses between recipients
because they likely have not granted you permission to redistribute
their e-mail addresses), select the "Newletter" contact to put in the To
field (which then becomes the To header after send).

Basically you define a contact to use in the To field that has a name to
describe that mailing with an e-mail address that points back to you.
The only reason you get "undisclosed" is because you left the
*optionaly* To header empty and your client is coded to shove something
in that header rather than omit it entirely (since its absence can run
afoul of spam/bulk filters). You can't change the coded string used
when To is empty but you can fill it with something that well describes
what that e-mail is about, like it's a newsletter or announcement.

[Mike Easter]

Personally, I think it is 'better' (more polite) if the To
'characterizes' the recipients but does not give any of the recipients
the email address of the others -- under some circumstances such as
several friends, not a large list of people who don't know each other at
all.

To that end, I create a contact which name characterizes the group such
as 'Outback Pals' and give it my address.

Then I create an outback group list which is populated with the
addresses of those in that group.

Then when I email that group I populate the To with Outback Pals and the
BCC with the outback group and then in the body I put something like
'Sent to George, Betty, Ted and Alice' if they are mutually acquainted.

That way I'm letting the members of the group know that the mail was
sent to their other acquaintances but I'm not giving out email addresses
to the members of the group. I feel that the sharing of email addresses
among acquaintances is a private matter which is up to those individuals.

What to do/ what I do/ if someone asks for the email address of a mutual
acquaintance is beyond the scope of the original question.


--
Mike Easter

[Big_Al]

Millwood said on 2/20/2014 10:20 PM:

Don't all email programs send bcc's as "undisclosed recipients"? If
so, then that is a standard. No industry made it, it was just accepted
as ... a standard way of doing it.

If not all email programs do it, then I'm wrong, and sorry I brought it up.

[Beauregard T. Shagnasty]

Big_Al wrote:

> Don't all email programs send bcc's as "undisclosed recipients"?

In the sense that BCC is hidden from recipients, yes.

But the question raised in this thread is that those exact words are
placed in the TO field if you don't supply an address in that field.
You're confusing the actual usage of those words with the loose definition
of them.

> If so, then that is a standard. No industry made it, it was just
> accepted as ... a standard way of doing it.

It *is* a standard, as defined long ago in the RFCs that govern how email
works.

--
-bts
-This space for rent, but the price is high

[Big_Al]

Beauregard T. Shagnasty said on 2/21/2014 9:07 AM:

Thanks.

[Peter Holsberg]

RFC 2822 says, "The only required header fields are the origination date
field and the originator address field(s)."

VanguardLH has written on 2/21/2014 12:03 AM:

[Peter Holsberg]

Mike Easter has written on 2/21/2014 5:05 AM:

>
> Personally, I think it is 'better' (more polite) if the To
> 'characterizes' the recipients but does not give any of the recipients
> the email address of the others -- under some circumstances such as
> several friends, not a large list of people who don't know each other at
> all.

I agree. That's why I do not care for "undisclosed recipients;".

> To that end, I create a contact which name characterizes the group such
> as 'Outback Pals' and give it my address.
>
> Then I create an outback group list which is populated with the
> addresses of those in that group.
>
> Then when I email that group I populate the To with Outback Pals and the
> BCC with the outback group and then in the body I put something like
> 'Sent to George, Betty, Ted and Alice' if they are mutually acquainted.

Wouldn't it be spiffy if there were an extension that, upon seeing a
special name such as 'Outback Group', would look for a contact list with
that name and populate Bcc automatically?

[James Moe]

On 02/21/2014 10:05 AM, Peter Holsberg wrote:
> RFC 2822 says, "The only required header fields are the origination date
> field and the originator address field(s)."
>

This does not necessarily imply a "TO:" field; it may be CC or BCC. In
SMTP-ese, the to/cc/bcc field data get converted to a RCPT-TO values
that the server uses as destination(s) for the message. In the case of
BCC entries, those are never added by the client to the message's header.

--
James Moe
jmm-list at sohnen-moe dot com

[Big_Al]

Peter Holsberg said on 2/21/2014 12:16 PM:

Wouldn't it be nice if BCC would automatically take the nickname field
from all the addresses and show them to the receivers. That I think
would be slicker.

[Vic Moz Garcia]

+10, That one would be super.

[Beauregard T. Shagnasty]

Vic Moz Garcia wrote:

> Big_Al wrote:
>> Wouldn't it be nice if BCC would automatically take the nickname field
>> from all the addresses and show them to the receivers. That I think
>> would be slicker.
>>
> +10, That one would be super.

No, it wouldn't. You've just removed the "B" from BCC.

[Vic Moz Garcia]

On 02/22/14 00:01, Beauregard T. Shagnasty wrote:
> Vic Moz Garcia wrote:
>
>> Big_Al wrote:
>>> Wouldn't it be nice if BCC would automatically take the nickname field
>>> from all the addresses and show them to the receivers. That I think
>>> would be slicker.
>>>
>> +10, That one would be super.
>
> No, it wouldn't. You've just removed the "B" from BCC.

No, in my case ... but ... after checking some of the nicknames in my AB ...
I have to agree with you, it would be a really bad idea.
I get somewhat 'creative' with nick's ...

[Jay Garcia]

On 21.02.2014 17:00, Big_Al wrote:

--- Original Message ---

> Wouldn't it be nice if BCC would automatically take the nickname field
> from all the addresses and show them to the receivers. That I think
> would be slicker.

That, IMHO, would defeat the purpose of the BLIND-carbon-copy intention.
However, if you use "Group List"
in the TO: field like Mike Easter mentioned, then everyone in that group
should know who the members are anyway.

--
Jay Garcia - www.ufaq.org - Netscape - Firefox - SeaMonkey - Thunderbird
Mozilla Contribute Coordinator Team - www.mozilla.org/contribute/
Mozilla Mozillian Member - www.mozillians.org
Mozilla Contributor Member - www.mozilla.org/credits/

[VanguardLH]

Peter Holsberg wrote:

> VanguardLH has written:

>
>> Those saying this string is standard are wrong. In fact, e-mails are
>> not required to even have a To field. It may appear a minimum of zero
>> times and a maximum of 1 times (i.e., it's optional and, if used, must
>> be used only once). It is NOT a header added by the server. It is
>> *data* added by the user's client and sent during the DATA command.
>

> RFC 2822 says, "The only required header fields are the origination date
> field and the originator address field(s)."

http://www.rfc-editor.org/rfc/rfc5322.txt
(obsoletes 2822)

Section 3.6 Field Definitions
Page 21

Field | Min | Max number
---------------+--------+-----------
... | |
to | 0 | 1

Section 3.6.2 Originator Fields
Page 22
The originator fields of a message consist of the from field, the sender
field (when applicable), and optionally the reply-to field.

The To header, if present (since it is optional), is *NOT* an originator
field. Originator info is about the sender, not the recipient. You've
confused the To header as an originator field. The To header identifies
the recipient, not the sender. The *sender* is the originator.

[EE]

BCC stands for Blind Carbon Copy. The idea is that the recipients do
not know who the other recipients are, hence the word "Blind".

[David E. Ross]

That does not change the fact that some ISPs have their mail servers
reject incoming (and possibly outgoing) messages that have no To:
address. This is because messages with only Bcc: addresses are very
often spam.

[VanguardLH]

David E. Ross wrote:

> That does not change the fact that some ISPs have their mail servers
> reject incoming (and possibly outgoing) messages that have no To:
> address. This is because messages with only Bcc: addresses are very
> often spam.

Yes, e-mail providers as well as NNTP providers can impose any
anti-abuse, anti-spam, or other rules or quotas none of which have
anything to do with complying with the RFCs.

Gmail, for example, had a rule (don't know if it is still employed)
where they would reject incoming e-mails where sender = recipient. That
is, any e-mails sent to yourself from yourself were considered spam
because rarely do users send e-mails to themselves from the same
account. Gmail also ignores the DELEte command (following a RETRieve
command) and instead has the user configure a server-side option rather
than let their POP client control the retention of articles. Gmail also
treats the TOP command like it's a RETR command which results in
articles missing in a later UIDL command which lists new articles to the
client.

Hotmail limits the number of outbound e-mails that can be sent to 300
recipients (not e-mails but recipients) per day for webmail users and
100/day for SMTP access (but is an unspecified lower limit for new
accounts for an unspecified trust period). Obviously none of that has
anything to do with the e-mail protocols but rules imposed by the e-mail
provider. There are some, for example, that will not let you specify a
From header with a different e-mail address than the account through
which you send an e-mail; that is, the From header must match the e-mail
account from which you sent the e-mail. That's not an RFC requirement
but something the provider decided to enforce. E-mail providers limit
how many recipients can be specified per message but that's not an RFC
standard. Obviously RFC standards do not establish the maximum storage
space for an e-mail account or the maximum size for e-mails.

I wasn't addressing the peculiarities of a particular e-mail provider.
Neither were the respondents that claimed "undisclosed recipients" was
some standard and a requirement when all recipients are specified via
Bcc (which is not even seen by the e-mail server) and to which I
supplied a counter argument showing what *is* the standard.

That an e-mail provider demands a non-blank To header that is in the
message *data* (and not via the RCPT TO commands) is an arbitrary limit
established by that e-mail provider. It also means that e-mail provider
must interrogate your message to look at its data to see if a To header
was specified or not, and that is a LOT of overhead by the e-mail
provider to peek inside your e-mails. The RCPT TO commands from the
client tell the SMTP server who are the recipients. That is what the
server uses to determine where to send your e-mails. Digging into your
e-mails is NOT required for delivery of your e-mails, incurs overhead
(which slows delivery), and means your e-mail provider is spying on the
content of your e-mails.

[Peter Holsberg]

VanguardLH has written on 2/22/2014 2:12 PM:

I don't think I've confused anything, pal. You said that emails are not
required to have a To: field. I said, right!

[Beauregard T. Shagnasty]

VanguardLH wrote:

> when all recipients are specified via Bcc (which is not even seen by the
> e-mail server)

If the email server could not see the BCCs, how does it deliver the mail?

(Hint: all the servers see the BCCs. Only the recipients don't.)

--
-bts
-Think about it

[»Q«]

In <news:re-dnUtRk6hA3JTO...@mozilla.org>,

No server sees BCC *headers*. The servers see whatever the user put in
the BCC fields, but in the form of SMTP command arguments, not in the
form of BCC headers.

[Jay Garcia]

On 22.02.2014 19:49, »Q« wrote:

--- Original Message ---

And even looking in the maillog the BCC's are not in a form that is
recognizable as a BCC for "spying" purposes.

[Beauregard T. Shagnasty]

»Q« wrote:

> "Beauregard T. Shagnasty" wrote:
>> VanguardLH wrote:
>> > when all recipients are specified via Bcc (which is not even seen by
>> > the e-mail server)
>>
>> If the email server could not see the BCCs, how does it deliver the
>> mail?
>>
>> (Hint: all the servers see the BCCs. Only the recipients don't.)
>
> No server sees BCC *headers*. The servers see whatever the user put in
> the BCC fields, but in the form of SMTP command arguments, not in the
> form of BCC headers.

I didn't say "sees headers." I just mentioned that if the servers could
not see the BCC "information" as VanguardLH wants to believe, the mail
would not/could not be delivered.

[»Q«]

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

"Beauregard T. Shagnasty" <a.non...@example.invalid> wrote:

I think Vanguard has it straight, but I haven't read everything he or
she's written. Sorry if my post was just noise.

[VanguardLH]

Your e-mail client compiles an aggregate list of recipients from the To,
Cc, and Bcc fields in the new-mail compose window. The client then
sends a *separate* RCPT TO command to the server for each recipient.
The server doesn't bother to read headers in the data of the message.
If there are 10 recipients in the To field, 5 recipients in the Cc
field, and 20 recipients in the Bcc field then the client compiles a
list of 10+5+20 recipients which it then uses to issue 35 RCPT TO
commands to the server. The server collects the recipients using the
RCPT TO commands. Then the client sends ONE copy of the message,
including the From, To, Date, and other headers using the DATA command.
So the sequence would be 35 RCPT TO commands for all the 35 recipients
followed by one DATA command to transfer the message. The server sends
that one copy to each of the recipients.

Mailing lists work similarly. They have a file that lists all the
recipients and one file containing the message. The bulk mailer issues
a RCPT TO command for each recipient in the file with the list of
recipients and sends one copy of the message file using the DATA
command.

Nothing in the message specifies the recipients. Those are fields added
as data within the message. The client issues separate RCPT TO commands
to specify the recipients. That's why, for example, bulk mailers and
spammers can deliver to recipients that are never specified in the
*data* fields within the message.

The server never sees those fields (that you see as headers upon
receipt) that your new-mail compose window showed you. To, Cc, From,
Date, Organization, X-headers, etc are all transferred by the DATA
command and that command does not specify the recipients but only the
message content. The client should NOT insert a Bcc field in the data
of your message because it isn't used to tell the server those
recipients and because those recipients are supposed to remain hidden.
Of course, you could always add the list of recipients in the body of
your message if you wanted to be rude and divulge their e-mail addresses
to each other. The server should check if a defective MTA added the Bcc
field in the content delivered via the DATA command to strip it out;
however, that means the server has to do much more work to interrogate
the contents of the DATA command rather than just send it to each
recipient. The client should not add the Bcc field in the message
content (transferred by the DATA command). The server should not accept
or strip out the Bcc field if present but might not because of the
overhead involved to peek inside the message.

Commands sent to the server are not tied to the fields your client adds
to the data of the message. The server only cares about the *commands*
your client sends it. You don't add RCPT TO headers to your e-mails.
Those are commands your client sends to the server.

[VanguardLH]

Peter Holsberg wrote:

> VanguardLH has written:
>
>> Peter Holsberg wrote:
>>
>>> VanguardLH has written:
>>>
>>>> Those saying this string is standard are wrong. In fact, e-mails are
>>>> not required to even have a To field.
>>>

>>> RFC 2822 says, "The only required header fields are the origination date
>>> field and the originator address field(s)."
>>

>> The To header, if present (since it is optional), is *NOT* an originator
>> field.
>

> I don't think I've confused anything, pal. You said that emails are not
> required to have a To: field. I said, right!

Sorry. I thought your reply meant you thought the To header was an
originator field. It didn't seem a "you're right" reply.

[Mike Easter]

This VanguardLH msg is pertinent to the clarification of the discussion
of the server handling of BCC (content in RCPT TO), but is (now)
missing/deleted/expired from the moz server.

http://al.howardknight.net/msgid.cgi?ID=139317672000

Posted to Tb support & .general, f/ups to .general



--
Mike Easter

[James Moe]

On 02/22/2014 05:33 PM, Beauregard T. Shagnasty wrote:
>
>> when all recipients are specified via Bcc (which is not even seen by the
>> e-mail server)
>
> If the email server could not see the BCCs, how does it deliver the mail?
>

The client handles this part of the process. It adds the TO and CC and
whatever else to the header except, of course, BCC.
The client collects all of the recipient addresses and sends a series
of RCPT-TO commands to the server that contain the addresses before
sending the message itself.

[NFN Smith]

This digs down further into the mechanics of SMTP.

At server level, there is an "envelope" that contains all the addresses,
including To:, Cc: and Bcc:. This envelope is created at the time the
message is submitted to the server Mail Transport Agent (MTA), and stays
in place only until the message has been accepted by the receiving
server, and then the envelope is discarded.

The MTA will insert To: and Cc: (but not Bcc:) into the headers of the
message content, but all of that is incidental to what is happening in
the envelope.

Dating back to the days of when RFC 821 was the governing standard, it's
possible to telnet into port 25 of SMTP server, and pass the server raw
SMTP commands, creating your own envelope. Working from memory, the
general form is:

HELO something.com
MAIL FROM: sen...@whatever.com
RCPT TO: y...@example.com
DATA



In this, the sending server identifies itself to the receiver with a
HELO, identifies the purported server with MAIL FROM:, but the key for
delivery is what is put in RCPT TO:. That's what tells the receiving
server the true recipient address(es).

For DATA, what is submitted after that (and not shown here) is the
entire contents of the message, both headers and body -- that is
*everything* you see in a Thunderbird inbox, if you press CTRL-U to show
the raw content of the message. The transmission is completed when the
server sends a hard return (CRLF) followed by a dot, followed by another
hard return.

On servers that I have admin access to, I occasionally will do this, as
a demonstration of how the mechanics of SMTP work, including the
difference between envelope and content, and how easy it is to forge any
or all of the message contents.

Basically, once you get to the DATA command, you can put in anything at
all, and the contents don't have to be don't have to be compliant with
RFC-822 (and successor standards). Thus, for what follows the data
command, I can paste in anything I want, including pasting in the entire
raw content of another message.

In that raw content, I can put To: or Cc: lines, which may or may not
correspond to your address, as well as putting whatever From: line that
I want.

This is stuff commonly done by spammers, as a way of trying to hide
their tracks.

Thus, if I have necessary server access, I can forge almost any content
into the message that reaches your inbox, including purporting to send
as bill....@microsoft.com or pres...@whitehouse.gov, even if I don't
have access to those servers.

Moving back to the "undisclosed-recipients;" question, that's what's
used by a lot of mail clients (outgoing) to ensure that the message has
a To: line (with some content), even if all addressees are specified
with Bcc:. For the purposes of delivery and envelope handling, it
doesn't make any difference what is put there. "To:
undisclosed-recipients;" is there to tell the recipient that the entire
list of addressees was specified by Bcc:.

That said, how individual servers handle such addressing will vary,
usually as a part of spam handling. Some may reject messages where the
raw content has identical addresses for To: and From:. Others may
reject (or throttle) messages where the envelopes have more than a
certain number of addresses in the envelope (that is, RCPT TO).

This is why, if you're doing bulk-mailing, you want to be doing it
through a server that's designed for doing bulk mailing, rather than
just sending batches of messages with big To:, Cc: or Bcc: distribution
lists. With a bulk mail server, there's a lot more control for
recipients to opt in and opt out of mailings, but when messages are
sent, each addressee gets a message with a separate envelope, rather
than the sending server trying to stuff all the addressees with the same
domain into a single envelope. Plus, with bulk mail servers, messages
are sent with a Priority: header set to "Bulk" or "Low".

But I digress...

Smith

[Beauregard T. Shagnasty]

NFN Smith wrote:

> Beauregard T. Shagnasty wrote:
>> VanguardLH wrote:
>>> when all recipients are specified via Bcc (which is not even seen by
>>> the e-mail server)
>>
>> If the email server could not see the BCCs, how does it deliver the
>> mail?
>>
>> (Hint: all the servers see the BCCs. Only the recipients don't.)
>
> This digs down further into the mechanics of SMTP.

<snip>

You, and others, have provided the "how" that mail servers do in fact see
the BCC addresses. Thanks for confirming that Vanguard's statement was not
true.

> But I digress...

Yes. ;-)

[VanguardLH]

Beauregard T. Shagnasty wrote:

> NFN Smith wrote:
>
>> Beauregard T. Shagnasty wrote:
>>> VanguardLH wrote:
>>>> when all recipients are specified via Bcc (which is not even seen by
>>>> the e-mail server)
>>>
>>> If the email server could not see the BCCs, how does it deliver the
>>> mail?
>>>
>>> (Hint: all the servers see the BCCs. Only the recipients don't.)
>>
>> This digs down further into the mechanics of SMTP.
>
> <snip>
>
> You, and others, have provided the "how" that mail servers do in fact see
> the BCC addresses. Thanks for confirming that Vanguard's statement was not
> true.

But he did prove what I said is true. The To, Cc, and Bcc fields are in
the *data* of the message sent via the DATA command. Before that, the
client aggregates a list of all recipients in the To, Cc, and Bcc fields
and sends a RCPT TO command for each recipients. If there are 5 To
recipients, 2 CC recipients, and 3 BCC recipients then the client will
issue 10 RCPT TO commands to the server.

The client doesn't even need to look at what you specified in the To,
Cc, and Bcc fields. Bulk mailers have one file listing all the
recipients and another file containing the message. It doesn't matter
if the message includes To, CC, and Bcc fields since they won't be used.
The client will issue a RCPT TO command to the server for each recipient
listed in the SEPARATE list and then send one copy of the message in the
DATA command. That means the To and Cc (the Bcc should not be included)
headers will NOT match on the actual recipients of an e-mail.

Guess my 1st-level reply was too long for you to bother reading to see
how I explained a RCPT TO *command* (not a field in the message) from
the client tells the server who is/are the recipient/s.

The To header is optional because it is the the message sent in the DATA
command which is issued *after* the client issues a RCPT TO *command*
for each recipient. The server only knows who are the recipients from
the RCPT TO command. It knows nothing about the recipients listed in
the To and Cc headers within the message's *data*.

[Beauregard T. Shagnasty]

VanguardLH wrote:

> Beauregard T. Shagnasty wrote:
>> NFN Smith wrote:
>>> Beauregard T. Shagnasty wrote:
>>>> VanguardLH wrote:
>>>>> when all recipients are specified via Bcc (which is not even seen by
>>>>> the e-mail server)
>>>>
>>>> If the email server could not see the BCCs, how does it deliver the
>>>> mail?
>>>>
>>>> (Hint: all the servers see the BCCs. Only the recipients don't.)
>>>
>>> This digs down further into the mechanics of SMTP.
>>
>> <snip>
>>
>> You, and others, have provided the "how" that mail servers do in fact
>> see the BCC addresses. Thanks for confirming that Vanguard's statement
>> was not true.
>
> But he did prove what I said is true.

You said the mail servers can't see BCC addresses. That's false.

> ... It knows nothing about the recipients listed in

> the To and Cc headers within the message's *data*.

So what? It still sees the addresses, else it couldn't deliver the mail.

[»Q«]

In <news:qdydncpk-c83WJbO...@mozilla.org>,

"Beauregard T. Shagnasty" <a.non...@example.invalid> wrote:

> >>>> VanguardLH wrote:

> >>>>> when all recipients are specified via Bcc (which is not even
> >>>>> seen by the e-mail server)

> You said the mail servers can't see BCC addresses. That's false.

Vanguard didn't say that. The tense of the parenthetical is singular,
which means it has to be referring to 'Bcc', not to 'recipients'.

But all this has prompted some pretty good explanations of how some
facets of SMTP work. :)

[VanguardLH]

Beauregard T. Shagnasty wrote:

> VanguardLH wrote:
>
>> Beauregard T. Shagnasty wrote:
>>> NFN Smith wrote:
>>>> Beauregard T. Shagnasty wrote:
>>>>> VanguardLH wrote:
>>>>>> when all recipients are specified via Bcc (which is not even seen by
>>>>>> the e-mail server)
>>>>>
>>>>> If the email server could not see the BCCs, how does it deliver the
>>>>> mail?
>>>>>
>>>>> (Hint: all the servers see the BCCs. Only the recipients don't.)
>>>>
>>>> This digs down further into the mechanics of SMTP.
>>>
>>> <snip>
>>>
>>> You, and others, have provided the "how" that mail servers do in fact
>>> see the BCC addresses. Thanks for confirming that Vanguard's statement
>>> was not true.
>>
>> But he did prove what I said is true.
>
> You said the mail servers can't see BCC addresses. That's false.

Yep, EXACTLY. The server never sees ANY of the headers you add in your
message because that gets transferred using the DATA command. The
server only sees the RCPT TO *commands* sent by your e-mail client, one
for each recipient. The server doesn't see a To header. It doesn't see
a Cc header. It doesn't see a Bcc header (which your client should
*never* include).

Your client compiles an aggregate list of recipients from whatever
source it is told. Could be fields in a new-mail compose window called
To, Cc, and Bcc. Could be an input field with a list of e-mail
addresses. For each recipient, your client issues a RCPT TO command.
That is ALL the server sees for who are the recipients.

Because your message along with any headers you add (To, Cc, From, Date,
Organization, X-headers, or whatever) is transferred using the DATA
command, the server doesn't see any of that. That's the message, not a
list of recipients. Because the server relies on the RCPT TO commands
to tell it where to deliver your message is why the actual recipients
may not match the headers in the message. That is the case, for
example, when using the Bcc field because it is NOT in your message.
Bcc recipients aren't listed anywhere in your message. So how does the
server know to those recipients? Well, by the RCPT TO *commands* it
gets from the server.

I'm done explaining how SMTP works. If you can't get it then me going
on and on about the difference between RCPT TO commands and the
*content* of a message via DATA isn't going to enlighten you.

>> ... It knows nothing about the recipients listed in
>> the To and Cc headers within the message's *data*.
>
> So what? It still sees the addresses, else it couldn't deliver the mail.

You're the one that asked how the server knows the recipients if it
can't see the Bcc header. And, gee, after you realize that I'm right
which you hate to admit you now claim it wasn't important. Uh huh.

[Jay Garcia]

On 24.02.2014 16:20, Beauregard T. Shagnasty wrote:

--- Original Message ---

>> But he did prove what I said is true.
>
> You said the mail servers can't see BCC addresses. That's false.

The statement is true as written ... but ... the mail server CAN see the
Bcc addresses but has no clue that they are in fact Bcc's. I see this
all the time in my mail logs off the server.

>> ... It knows nothing about the recipients listed in
>> the To and Cc headers within the message's *data*.
>
> So what? It still sees the addresses, else it couldn't deliver the mail.

Of course.