>>> "email@example.com" <firstname.lastname@example.org> 09/19/01 05:28PM >>>
>I've been following the posts regarding sanitizing outbound mail. I would
>be very interested to know how you approached this, not so much the nitty
>gritty details, but the overall policy..
>Did you choose to simply sanitize everything (both incoming and
>outgoing) on a single box? Did you split your incoming and outgoing email
>functions to different boxes, and then customize the'sender notification'
>for outgoing only?
I am currently testing and preparing to move to a production environment my own version of sanitizer.pl. It's actually a modification to that script, but with a number of new features. Some of what I have done I need to redo because of the new code that Bjarne is putting together within the Sanitizer package--excellent stuff for adding customizations such as mine. I have sent him the code I've written for my company and once it's in a more stable form, he has my permission to add it to the contributions directory of the Sanitizer distribution.
Okay, the overall approach without so much of the nitty gritty... I have deeply integrated the script into Sendmail via the sendmail.cf rules. Basically, any email that comes into the server will be filtered through the Sanitizer system. My extension to Sanitizer, EVPS, then determines based upon the recipient Sendmail chose for the message or upon the senders listed within the RFC822 header of the email determines which configuration to apply. Thus we can have mail filtered using different policies depending on the sender address, the sender domain, the recipient address, the recipient domain, and apply some policy for all messages that don't match any known sender or recipient. Finally, the system might decide not to "filter" the message at all and just read it right back to Sendmail unmodified.
Notifications are handled by a separate system that is integrated into Sanitizer via the logging hooks in the new Log system. The notification system also chooses what kinds of notifications to perform based upon the sender and recipient in the same manner as with choosing a Sanitizer configuration.
Does this answer your questions?
>I am struggling with this very issue for my work. I have run the basic
>sanitizer for about 6 months (incoming only) with great success. It is
>only when I attempt to sanitize outgoing that I fall off the cliff.
This can only be done by integrating into the MTA itself--via modifying the sendmail.cf rules for Sendmail users. You then need some way of deciding if the messaging is incoming or outgoing. With us, we wanted much more fine grained control in case we needed to give specific users specific policies, but when you are just checking incoming versus outgoing you just need to create a host list. With Sendmail, you can make Sendmail do all the work for you through careful modification of Sendmail rules and the use of a host class file. I suggest getting _sendmail_ by Bryan Costales with Eric Allman published by O'Reilly and reading chapters 28, 29, 32, and 34 if you use Sendmail. That's where I've found most of my information on doing this--it's scary how familiar the gibberish in the .cf files have become through this project *shudder*.
>I subscribe to the belief that I should not send out partial emails with a
>sanitize log in place of the attachment. I pass all email thru
>the Sophos virus scanner, and if it is clean, send it on to recipient. If
>virus found, 'save' (i.e. quarantine) the attachment and bounce a message
>back to the sender, and send nothing to the original recipient.
For us, we have found the the inline log to be utterly useless. We are sending these mails to people with less computer knowledge than I have of how to fix an automobile--I've traded a battery out and rotated my tires, everything else I have to farm out to professionals. :-P Showing them this log will cause one of two reactions: utter panic because they read the word "virus" in it somewhere or they will read it the first 2 or 3 times and then stop because it said nothing was wrong and it takes too much time to read the log for to find that out.
Instead we just rely upon the replacement message for dropped attachments and that they will be confused when a file gets defanged with the word WARNING that they'll just call us to confirm what's going on.
>It is this last part, the sender notification, that is killing me. I've
>made quite a few infinite mail loops trying to write Sendmail rules to do
>this, and have also succeeded in doing the same thing with procmail
Be very careful with Sendmail rules (or any kind of recursive processing as is necessary for Sanitizer). I believe the newest version of Sanitizer comes with a Contrib directory that has some information on how to write Sendmail rules for Sanitizer. The key is to manipulate the recipient address so that it contains the word .CLEAN or something similar on the end after it has been sanitized and that it will not be sent on to the sanitizer if the .CLEAN is on the end, but that the .CLEAN will be stripped off before being delivered normally.
>I think that I am missing a piece of understanding regarding sender
>notification, and would appreciate any info you may wish to share.
First and most importantly about sender notification is that such a notification be in the proper format. Automated replies that discuss the nature of mail handling and delivery are called DSNs, or Delivery Status Notifications. You've seen these when a message bounces because of a mistyped email address or because DNS (not to be confused with DSN) was down. DSNs are described in RFCs 1891 through 1894 and are available at http://www.ietf.org/ for viewing. If your notification is not in this format you will seriously offend mailing list admins and others who rely upon automatic handling of such messages.
Second, make sure you do not create infinite loops when sending them. It is required for MTAs to avoid infinite loops. Sendmail will normally do this, but when you start to futz around with the rules, you can cause Sendmail to create mail loops. Mail loops can include things like sending a DSN message to notify of a security issue but successful delivery (EVPS uses code 2.7.0) and then a mailer replies back with a DSN because the original DSN was sent to the wrong address. Let's say that because of an unfortunate formatting error, the original DSN doesn't have a correct address on it and this causes another DSN to be sent back and this continues forever. Sendmail can usually detect problems such as these and stop them before they get this far, but the point is, be careful with how you formulate your notifications.
Finally, evaluate to whom and when you want to send a notification. It's important that you not send out two dozen messages because the sender sent in 25 JPEGs and your particular policy states (for whatever reason) that JPEGs are forbidden. This would be terribly irritating to the originator and may steal away precious bandwidth while your server handles the messages. It's important that you don't send notifications saying something to the effect of "Bob got your message and 0 attachments had problems." This is just superfluous. These are obvious examples, but make sure you consider the subtleties involved in when and how you send the notifications.
I can send you EVPS if you are interested in looking over it, but understand that it is still in the Beta stages of development. I definitely recommend reading RFCs 822, 1341, 1891-1894 and other related documents. There is no substitute for _sendmail_ (or Bat Book, as many of us geeks refer to it), though http://www.sendmail.org/ has some good information.
If you have any questions or I didn't clarify things for you, please let me know.
-- <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> Sterling Hanenkamp Software Consultant Network Resource Group, Inc. 1105 Hylton Heights Manhattan, KS 66502 (785) 776-5878 email@example.com