headers aren't sufficient for delivery?
droid
to get an email to delivered. But in RFC 2822 "Internet Message
Format" section 3.6.3 "Destination address fields", it states:
"There are three ways in which the "Bcc:" field is used. In the first
case, when a message containing a "Bcc:" field is prepared to be sent,
the "Bcc:" line is removed even though all of the recipients
(including those specified in the "Bcc:" field) are sent a copy of the
message."
Wouldn't this require the SMTP server to send a copy of the Bcc
addresses it has removed, in tandem with the email, so the destination
server will know where to deliver it?
Thor Kottelin
news:7e560ec7-5f69-4673...@o30g2000vbc.googlegroups.com...
> "There are three ways in which the "Bcc:" field is used. In the first
> case, when a message containing a "Bcc:" field is prepared to be sent,
> the "Bcc:" line is removed even though all of the recipients
> (including those specified in the "Bcc:" field) are sent a copy of the
> message."
>
> Wouldn't this require the SMTP server to send a copy of the Bcc
> addresses it has removed, in tandem with the email, so the destination
> server will know where to deliver it?
Yes. In fact, the recipient address is always given using the RCPT command
in SMTP.
For details, please see any SMTP RFC (821, 5321, or in between).
--
Thor Kottelin
http://www.anta.net/
D. Stussy
news:7e560ec7-5f69-4673...@o30g2000vbc.googlegroups.com...
At initial mail submission, recipient (destination) information may be
taken from the headers. From there, it is placed into a virtual envelope.
It is this envelope information that directs delivery from that point
onward. The "Return-Path:" header for SMTP indicates the final envelope
sender address at the server that performs delivery.
When the "Bcc:" header is encountered at submission, its contents are moved
to this virtual envelope, thus rendering its copy in the message itself
(should the header remain) empty.
droid
assumptions were wrong.