On Fri, 2004-05-07 at 18:27, Mike Lambert wrote: > Again, the advantage is sending 5xx instead of 2xx. IMO, giving the > connecting mta a status code appropriate to the message disposition is > better than simply accepting _all_ messages only to drop some later (I > do not consider generating a separate "bounce" message to be an option). > The sending mta should deal with rejected messages, not the receiving > (rejecting) mta. Sorry, this is really far too long!
Disclaimer: I use MailScanner, I've also contributed to MailScanner and am the current lead developer on MailScanner-MRTG (a GPL'd monitoring tool for MailScanner servers). Obviously my opinion isn't unbiased (although I hope not totally one-sided), but I'd like to throw some often overlooked points into the mix. I don't think that there is necessarily a right or wrong answer to this one, nor is one solution necessarily best for everyone. I do agree that where a message is undeliverable (because of bad addressing, disabled accounts etc) this should be handled by a rejecting at the RCPT stage by the first MTA with the ability to make such a judgement (Since this is a matter of MTA configuration this shouldn't be an issue in the milter vs queue argument). Where the decision to reject is based on the application of policy to the content of a message (whether that be the application of virus scanning, spam filtering, file name/type filtering, other message content filtering, attachment size restrictions etc.) it is not necessarily so clear cut. I would not advocate bouncing spam or viruses as this causes a nuisance, however where a message is blocked due to pure policy descisions (for example we block mpegs) then a clear and helpful bounce message is a courtesy. I appreciate that for members of the list understanding a reject message generated by an MTA is trivial, but many users find it much less acccessible (not to mention getting confused about why their own mailserver appears to have rejected their message - when in fact it is merely reporting the rejection by the destination mailserver). A good proportion of mail passes through multiple MTA's on route, especially given the current spam/ virus tactics of delivering to secondary MX's many of which simply store and forward. I imagine that dealing with 5xx rejects of spam and viruses (usually with forged senders) is a growing burden for ISP's who offer a secondary MX store and forward service. I hope that at least some milters have the ability to discard rather than simply reject certain classes of unwanted mail. Its often overlooked that 5xx rejecting only pushes the problem back upstream, and this is not necessarily to the point of origin (as anyone who has ever been joe-jobbed will appreciate all too well). So by not accepting the mail you may be part of the problem rather than part of the solution [I'm not saying thats my opinion, I'm on the fence on that one - no flames please!]. There is however a fine line to walk, just discarding mail is a dangerous path to tread and certainly not one we choose to take. Our policy is not to bounce spam or virus. Spam mails are tagged (and stripped of html content to avoid offending people), so the recipient can filter in their MDA. Viruses are removed (or disinfected in the case of the now rare macro viruses) and the recipient notified with any deliverable portion of the mail included, except in the case of outgoing mail, where we can be reasonably sure who the sender is and notify them instead. There are also technical concerns with both methods. Others have raised technical concerns about MailScanner's approach so I won't duplicate them here. Because milters scan the mail during the SMTP transaction they need to be fairly swift about it, so that the sending server doesn't give up on them, and also out of courtesy to the senders organisation (who want's dozens of MTA processes all waiting while the recipient takes several minutes to do umpteen checks?) Please don't misunderstand me, I'm not saying that this is always the case - just that there is a risk of processing time becoming unacceptably long during times of unusually heavy load. MTA's generally restrict the maximum number of threads, so slow processing can result in mail not being delivered. Typically this pushes the problem back upstream again, if upstream happens to be the spammers server of the infected PC then this is good as its quite likely they won't attempt another delivery, if not then this is just creating problems for others [again, good or bad you decide]. On the other hand with MailScanner the MTA handles the mail as quickly as it can, making SMTP sessions as short a possible. This does mean at times of heavy load there can be a backlog in the incoming queue, and your server may be at full pelt trying to catch up, however mail is processed as soon as possible and in the order it arrived so mail will be delivered at the earliest opportunity (with the milter model the timeliness of the delivery in similar circumstances is dependent on the queue running interval on the sending server). This has got quite long so I'm going to stop soon! Whatever solution you choose, be it milter or MailScanner, it is a tool for applying your policy. And you should evaluate each tool on both its ability to apply your policy and its technical merits. These days pretty much all the sucessful (non-commercial) mail filters are soundly coded and maintained by very capable people, and are mostly well supported in forums such as this - so pick the one that meets your needs. One final point (really an advertisment for MailScanner!) MailScanner isn't just an email virus scanner, heres just a few of its capabilities (all of which can be turned on or off as needed)... Support for around 20 virus scanners (which can be used in combination, we use 4 including Clam) Extensive mail unpacking (including unzipping zips, tnef, binhex, etc.) Application of file naming policy (e.g. extensions) Application of file type policy (using magic number detection) Application of policy to encrypted messages / encrypted zips RBL checks Spam checks with SpamAssassin User defined content checks (got something you don't want leaving/ entering your site?) HTML cleaning facility (to eliminate SCRIPTS, IFRAMES, FORMS etc as required) Can turn messages into attachments (so your users need never open that farm-sex spam!) Archiving and Quarantining Dynamic reconfiguration to avoid problems caused by unresponsive RBLS etc. Powerful ruleset based configuration (whitelist / blacklist just about anything, based on address, domain, ip address, even virus name!) Plugin architecture for additional message processing, or unusual configuration requirements. BMRB International http://www.bmrb.co.uk +44 (0)20 8566 5000 _________________________________________________________________ This message (and any attachment) is intended only for the recipient and may contain confidential and/or privileged material. If you have received this in error, please contact the sender and delete this message immediately. Disclosure, copying or other action taken in respect of this email or in reliance on it is prohibited. BMRB International Limited accepts no liability in relation to any personal emails, or content of any email which does not directly relate to our business. ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
