procmail
[Top] [All Lists]

Re: BCC handling

1996-11-08 21:00:17
4.5.3.  BCC / RESENT-BCC

       This field contains the identity of additional  recipients  of
       the  message.   The contents of this field are not included in
       copies of the message sent to the primary and secondary  reci-
    pients.   Some  systems  may choose to include the text of the
       "Bcc" field only in the author(s)'s  copy,  while  others  may
    also include it in the text sent to all those indicated in the
       "Bcc" list.

So, procmail *would* handle Bcc's correctly if the sender's MUA included
the Bcc in the header in the first place.  But, since procmail is most
typically used on *incoming* email, it will never have a chance to deal
with Bcc: headers.

Originally, I thought... Ya,  enough said.  So I spoke to my ISP to see if
there was any way they could adopt your #2 approach above.  They have not
answered me yet, but something occured to me....

There MUST be some trace of the BCC destination that travels with the
e-mail.  Otherwise, how does it know its destination?  If I'm right, then
couldn't procmail use this to properly handle the message?

Mark,

Only the MTA knows the destination address because it is part of the
"envelope", the information which is passed on the "RCPT To: some-user"
SMTP line.  This information is how the MTA knows to deliver the mail,
and not by the contents of the headers.  

Of course, when invoked properly, many MTAs can read the headers to
obtain the addresses needed on subsequent "RCPT" commands in the ensuing
SMTP connections.  In fact, the Bcc: header can be read along with the
rest of the destination headers to obtain the recipient addresses, but
the Bcc: will also be removed from the headers.

The address by which an MTA receives a mail is known as the "envelope
address", which may be distinct from any headers in the message itself,
or, the same as one of them, for directly addressed mail.

With mailing lists, for example, the addressee will never see his/her
own address, but will see the mailing list in the To: or Cc: header
fields.  Even here, when mail is addressed to more than one mailing
list, there is a lack of standard for determining *the* address by which
a message is received.  There are lots of conventions followed, and
heuristics, but no clearly defined standard to indicate the cause of
delivery. 

You may be able to configure your MTA to pass along the envelope in a
new header, or pass it by argument to the local delivery program (which
can be procmail).  It is then up to the local delivery program to use
(or not) the envelope address information.

If you wish to understand the limits of your mail system, you should
read RFC822 (email formatting standards) and RFC821, which describes the
original language of SMTP.   There are several extensions in progress,
but the basic commands of "MAIL", "RCPT", and "DATA" should suffice.

Surely other procmail users must somehow be handling BCC's.  Otherwise,
there are alot of BCC messages falling through to the procmail sysops.
Seems ironic that the private messages are the only ones that get misdirected.

This is a GAPING hole.  I can't be the only one to have this difficulty -am I?

The hole is the *lack* of formatting standard for Bcc's, but not with
their usage.  Bcc's have been in wide usage for quite a long time; I use
them all the time.  I just don't expect to have a consistent formatting
of BCC headers by lots of foreign mailers because, as I said before,
there is *no* standard.

Of course, this lack of BCC standard is only one of many problems with
SMTP which are now being addressed in the Internet standards
establishment process.  As I mentioned above there are several drafts in
progress to improve SMTP for 8-bit transmission, MIME usage, and
encryption coding standards.

If you feel very strongly about this, and wish to contribute and improve
the situation, you can write a new Internet draft in which you propose a
standard for BCC handling.  This is how new standards get established
and accepted. 

Good luck.
___________________________________________________________
Alan Stebbens <aks(_at_)sgi(_dot_)com>      http://reality.sgi.com/aks

<Prev in Thread] Current Thread [Next in Thread>