Unfortunately, some MUA do not support that 'feature' or only support it for
mailing addresses within the domain of the originator which is also an
interesting feature. With that as the case it may be considered that BCC is
not per se relevant as an 'evil' descriptor when detected but could be
considered as a message anomaly when crossing an MTA boundary and:
1) the message recipient is within the domain of the originator, and;
2) all BCC recipients are outside the domain of the key recipient's (To and Cc)
as opposed to the converse which would appear to be the most likely use of BCC
in message (company/organization internal) while these are interesting
considerations, they may not be viable as solutions unless a mechanism can be
established and used that identifies orig/recip affiliations (C/R,
white/blacklists, etc). To me this represents one of the problems with
focusing on 'one-size-fits-all' solution approaches (and mind you I am
interested in reading and analyzing all approaches).
On Thursday, May 01, 2003 6:52 AM, Tom Thomson
[SMTP:tthomson(_at_)neosinteractive(_dot_)com] wrote:
8<...>8
As for the bcc case, I used to use an MUA which generated n+1 copies of the
body - 1 for each bcc recipient containing a bcc line with only that
recipient, and one for all To and cc recipient containing no bcc line. These
were transmitted separately - multiple Rcpt To lines with one Data phase for
teh To and cc recipients, single Rcpt lines with a data phase for each bcc
recipient. Since Phill is as much of an antique as I am, maybe he too
remembers MUAs which did rather pleasant and intelligent things that didn't
conform to the modern desire for "efficiency" at all costs (even at the cost
of effectiveness) and maybe that's where theerrorneous statement comes from.
An easy mistake to make if you grew up with civilised MUAs.
8<...>8
(pining for the old day's Tom? ;-)
-e
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg