Subject: why rfc822_header doesn't write bcc?

From: Vadim Zeitlin <[email-masked]>
Date: Fri, 19 Jan 2001 15:19:24 +0100 (CET)

Hello,

 Could someone please explain me the meaning of these lines
in rfc822_header() from rfc822.c:

/* bcc's are never written...
 * rfc822_address_line (&header,"bcc",env,env->bcc);
 */

 Just why exactly is the bcc header never written? I am using
this function to write message to a temp file and then call
sendmail (or whatever local MDA there is) to send it (for the
people who don't have or don't want to use SMTP). However I
needed to uncomment this line to make the bcc header work at
all and now I wonder what bad implications this might have
had?

 Thanks in advance for any help,
VZ
-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Fri, 19 Jan 2001 09:35:01 -0800 (PST)

On Fri, 19 Jan 2001 15:19:24 +0100 (CET), Vadim Zeitlin wrote:
>  Just why exactly is the bcc header never written?

Because the bcc header isn't supposed to be written, ever.

> I am using
> people who don't have or don't want to use SMTP).

Use of the -t option in sendmail (or equivalent in other programs) is the
worst possible way to send mail.  The day will come when your program writes a
bcc header that other people see inappropriately, and those people will be
very angry at you.

If you want to pass on the message to a local sendmail for delivery, you
should use sendmail's -bs option, which will use SMTP (albeit through standard
I/O) to transmit the envelope information.

---

From: Vadim Zeitlin <[email-masked]>
Date: Fri, 19 Jan 2001 19:53:40 +0100 (CET)

[please don't cc me the messages sent to the list, thanks]

> Because the bcc header isn't supposed to be written, ever.

 This is what the comment says and I can read (writing is another
matter). But just why is it so? The messages received by the
user never contain the bcc, so there is no danger here and as for
the messages the user sends out, why shouldn't he be able to save
them to a file?

> The day will come when your program writes a
> bcc header that other people see inappropriately,

 How can this possibly happen?
 
> should use sendmail's -bs option

 This seems like more work and I don't clearly see what do I gain here?
Putting apart any problems with possibly unsecure temp files, what does
this change for BCC?

 Besides, this is not the only place where it creates problems: we had to
play games with renaming bcc to x-bcc and back in the offline mode (as
cclient strips bcc from the message saved to the outbox without telling
anyone and it already cost me half an hour of debugging...) and it would
be so much simpler to avoid doing it.

 So what is exactly the problem with saving BCC headers to a file? Maybe
it's something really obvious but I just don't see it.

 Thank you for any explanation!
VZ

---

From: Mark Crispin <[email-masked]>
Date: Fri, 19 Jan 2001 10:07:07 -0800 (PST)

> [please don't cc me the messages sent to the list, thanks]

I do not maintain a customized list of addressee preferences for replies.  If
the "reply" command in my mail program is not good enough for you, then don't
ask questions.

> matter). But just why is it so?

The bcc header line contains information that can be quite sensitive.  It
requires special care.

> The messages received by the
> user never contain the bcc, so there is no danger here

Ahem.  61 years ago, the Germans could never cross the Maginot Line, so there
is no danger here.

Unforeseen occurrances can, and do, happen.  So does bad luck.

> Putting apart any problems with possibly unsecure temp files, what does

The -bs option uses SMTP to communicate with sendmail via stdio, so all email
addresses are transmitted externally from the message header.  This is the
right way to pass messages to sendmail.

It is not significant additional work, and it is much safer.