OK, fine, got me again, I meant an MSA -- which is generally, in
practice, the same code as an MTA, but functioning as an MSA (e.g.
sendmail listening on port 25 or 587 for message submission).
As to why this is worse than the similar situation with To/CC/etc
(Keith's question) -- nobody ever *intends* for those field values to
be hidden from the recipient, as they do with bcc. -- Nathaniel
On Aug 13, 2004, at 10:03 PM, Tony Hansen wrote:
Nathaniel Borenstein wrote:
I stand corrected: Three different functions. The line
BCC: nsb(_at_)guppylake(_dot_)com
might better be represented as
I-Sent-a-BCC-To: nsb(_at_)guppylake(_dot_)com (for my files)
BCC-Should-Be-Sent-To: nsb(_at_)guppylake(_dot_)com
(written by a UA as a request to an MTA)
Why-You-Got-This: You were BCC'ed as nsb(_at_)guppylake(_dot_)com
(for viewing by the bcc recipient)
Nit here on your second item: An MTA never looks at the header of a
message! The MTA is expected to look at an envelope, not the header.
If you're passing a message to something that IS expected to look at
the To/Cc/Bcc headers and act on them, that thing is NOT an MTA.
Even MSA's are not expected to look at the To/Cc/Bcc headers.
Now, if you want to argue that some software DOES look at those
headers to determine the addresses to send a message to, that's fine.
Those software packages are working as part of the MUA system, and
it's a private contract between those software packages to do so.
But an MTA should NOT be looking at the To/Cc/Bcc headers.
Tony Hansen
tony(_at_)att(_dot_)com