[SNIP! - complaints about limitations of BCC]
You'd all benefit by examining the spec for (E)SMTP conversations. BLIND
carbon copies are just that.
The documents in question are RFC 821 (SMTP) and RFC 1651 (ESMTP)
Here's an example conversation. The indented lines are the response from
the server (but are not actually indented)
(sending machine opens connection on port 25 of remote mail server)
HELO host.sendingFQDN (might also be EHLO, for ESMTP)
250 ... pleased to meet you
MAIL FROM: senderaddress(_at_)sendingFQDN
250 ... Sender ok
RCPT TO: recipient(_at_)domain(_dot_)com
250 ... Recipient ok
354 Enter mail, end with "." on a line by itself
(enter headers, blank line, followed by message body)
250 ... Message Accepted for delivery
221 ... closing connection
Anyway, after DATA, the headers (date, subject, to, previous receiveds,
etc) are emitted in the SMTP conversation, but these are the _VISIBLE_
headers. All the addresses ACTUALLY being delivered to are identified in
the RCPT TO: (i.e. you could have a clear-text To: in the headers, but the
message might not actually be delivered TO that address).
For instance, BCC: header wouldn't physically appear in the headers, but
would be in the envelope (RCPT TO:). Any given recipient server only gets
the RCPTs that are being delivered for/by that server, not all the OTHER RCPTs.
See 'man sendmail' look for the -t option - sendmail scans the message for
recipients, and _specifically_ deletes the Bcc: line before
transmission. Without this option, sendmail delivers the message
(reguardless of what the adressees are in the headers) to the address(es)
specified on the invocation line.
| sendmail foobar(_at_)doofus(_dot_)com
would pipe a message into sendmail, and deliver it to the shown address --
but NOT any of the addresses in the message headers.
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395
procmail mailing list