> I found this near the bottom of the procmailrc.5 man page. It seems to
> indicate that Bcc'd mail should be caught and routed properly.
>
> ----------
> MISCELLANEOUS
> If the regular expression contains `^TO' it will be substi-
> tuted by `(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope
> |Apparently(-Resent)?)-To):(.*[^a-zA-Z])?)', which should
> catch all destination specifications.
> ----------
>
> However, THIS receipe:
>
> :0
> * ^TO(_dot_)*sheryl(_at_)aecinfo(_dot_)com
> ! aec(_at_)inforamp(_dot_)net
>
> does NOT catch mail that is BCC'd to sheryl(_at_)aecinfo(_dot_)com(_dot_)
Why?
>
> Tests reveal that To's and CC's get handled properly. But BCC's
> do not - possibly because the BCC info is hidden in the header so
> it is not properly read by procmail (??). It seems that any mail
> processor **must** be able to properly handle BCC's. What am I
> missing?
The problem is a result of the lack of standard formatting guidelines
for outgoing Bcc: email. Procmail most typically processes incoming
email at a destination site; the BCC formatting (or lack of it) is done
on outgoing email, at the originating site.
For this discussion, let's make distinctions as to the kinds of mail
there are: (a) incoming mail, and (b) outgoing mail. Bcc's are inserted
into outgoing mail by the user, and the message is then handed to a MUA.
The MUA may then handle the BCC's or defer that to the Mail Transport
Agent (MTA), such as sendmail. Whichever agent performs the Bcc
function, that function is performed in at least three different ways:
1. Many MUAs format outgoing mail without the Bcc: headers, so that the
same message header can be sent to all recipients. The Bcc:
recipients receive an extra line in the message body, indicating the
nature of the mail. The text of the message varies from MUA to MUA;
The Rand Mailer, MH, for example inserts the lines around the
original text:
------- Blind-Carbon-Copy
...
------- End of Blind-Carbon-Copy
2. Some MUAs will send the message, separately, to each Bcc: recipient,
with the recipient address on the Bcc: header. Each Bcc recipient
thus knows that they received the message by way of the Bcc, but do
not know whom else was a Bcc recipient. All Bcc recipients are
private, even to other Bcc recipients. (It would be nice if all MUAs
behaved this way).
3. A few MUAs deliver the message without the Bcc:, but also without any
special indication; you must guess that it was a Bcc.
The original email standard RFC822 says this about Bcc:
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.
'Nuff said?
___________________________________________________________
Alan Stebbens <aks(_at_)sgi(_dot_)com> http://reality.sgi.com/aks