Re: Bcc and it's pit falls

At 13:57 2003-07-01 +0530, Shashank V. Kolhatkar did say:

> How many of you would like to agree with me that 'BCC' getting deleted 
> from "sendmail", an MTA, is a real head-ache for Email Administrators as 
> they have to keep watch on Enterprise-data and its forwarding to others 
> for "consideration"?
I don't follow what you're saying.  As written, it looks like you're saying 
that sendmail IS removing BCC capability, and that this would be a headache 
(I would agree that it'd be a headache, but since no such change is 
happening with sendmail, so there's nothing to agree to).  Are you saying 
that the SMTP protocol shouldn't allow for BCC?  If that's what you're 
arguing, you need to spend more time evaluating how email is used by the 
rest of the world, rather than by your individual organization.
For one, I'd have absolutely ZERO interest in seeing a mailing-list message 
(such as on procmail) showing hundreds to thousands of email addresses in a 
cleartext To: or Cc: field.  If I was on an outbound-only list (i.e. one 
which users do not post to), I'd be very annoyed to see my address out 
there available to every idiot who can't manage to keep viruses off of 
their machine, or who realizes that they can harvest spammable addresses 
simply by subscribing to a few large distribution lists.
If instead, you mean that because the email arrived RCPT to your address 
that sendmail should add it into the To:/Cc: headers of your message, 
that's just plain wrong - if the message wasn't addressed To: you, then it 
shouldn't be rewritten to appear that way.  Further, if a message was 
received for multiple recipients at your domain, the MTA should not create 
a Bcc: header and dump all those addresses into it - that'd be stupid 
beyond belief, since BCC stands for *BLIND* Carbon Copy - it isn't very 
blind if it's exposing the (local) addresses the message was delivered 
to.  There are MANY legitimate uses of BCC, ranging from security (sending 
a notice to someone, and a copy to someone else so that they're aware that 
the notice was sent), and privacy (similar, but the object is that each 
recipient needn't know the details of all the other recipients), to simple 
avoidance of autoreplies (vacation messages shouldn't be sent in response 
to messages which you are not a cleartext recipient of).
If you read the SMTP RFCs, you'll find that once a message is sent around 
via SMTP, the MTA doesn't look to the headers of the message for where it 
is being delivered to - the MTA uses the _envelope_ data.
> Don't you think we all should request the "great people" who maintain 
> sendmail/procmailrc
Procmail developmen has _NOTHING_ to do with sendmail.  Further, procmail 
is an LDA, not an MTA, so if you're moaning about Bcc: not existing with 
all the local (or even remote, but that's not going to happen) recipients 
identified in it, then you shouldn't even be posting here, because procmail 
doesn't HAVE that information in the first place - that's all handled at 
the MTA level.
> Incase any one of you have overcome this problem, I shall be grateful to 
> you if you passon the methods to control thru 'bcc', what we call in 
> today's world, "Industrial Espionage".
Methinks if you have industrial espionage within your organization, you 
need to tighten use of internet services and perform body cavity searches 
of employees on entering and exiting your facility (and even then, you 
can't do anything about what they have in their heads and then go send 
someone at home).
Screwing with email protocols IS NOT going to fix your problem.

All competent email administrators know that all the recipients of a 
message are logged in the mail logs (such as /etc/maillog.  All competent 
email administrators, running worthwhile software also know that they can 
easily redirect specific external domains such that email cannot be sent to 
certain domains if you wish to block contact.  This is a function of the 
MTA, not of procmail.  HOWEVER, through simple configuration of your MTA, 
you cannot block users from sending mail directly to remote SMTP servers - 
do do that, you should properly configure a FIREWALL (and you should 
consider blocking all services from all stations, and enable only those 
which need to be enabled).  It's a trivial matter for someone to transfer 
data to a remote host via a telnet/ssh session, ftp, or even via IRC or a 
yahoo/AOL/MSN "messenger" service, all of which will go unlogged by your MTA.
Please deal with your security problem in a sensible fashion, rather than 
suggesting that the rest of the world change to meet your needs.
[snip]
Why on earth did you quote this message for inclusion in your unrelated post?

---
 Sean B. Straw / Professional Software Engineering

 Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail