<quote who="Theo Julienne"> > A much nicer way is to reject the emails at SMTP time ( at response to > DATA ) - unfortunatly this requires patches with most MTAs, but it leaves > the "bounce" up to the mail server/client that sent it.
It sounds good, but unless you have an *incredibly* robust protocol and architecture for doing it, you're doomed. Know any MTAs that write to disk during or before DATA? How are you going to guarantee that your MTA -> AV/SPAM protocol/connection won't fail? How do you communicate that failure to the MTA? What should the MTA do? What happens if the failure means you can't communicate the cause or response to the MTA? What should the MTA's default behaviour be? Can your spam/AV gear handle streaming analysis, and provide a mechanism for immediate response? Do you just kill the connection, or try to provide a sane response to the SMTP client? Legitimate (albeit bad) mail should get a sane message, but the crappy SMTP clients in your average worm won't handle the reponse. Are you going to build that entire AV/SPAM infrastructure into the MTA to get around the problems? Think about the common response case for spam and viruses: Drop the fucker and get on with life. Despite the prevalence of dumb SMTP clients in modern worms, most fall back to a sensible upstream MTA, so if you reject a mail (causing a bounce if the client is sane), you're most likely adding to the network noise, which no one appreciates. So we're still stuck discarding this mess. Is there a huge benefit to dynamic, mid-DATA detection? Perhaps the only worthy remaining argument is bandwidth, but is it worth the cost? How much do you think you can realistically save? Safely? With postfix, I can safely cut most worms off at the pass by using body and header checks (which are part of the MTA's standard operation, and do not rely on any external protocols or daemons). Everything else that gets past my in-MTA policy checks (standard postfix stuff, cutting off around 50% of spam/worms with minimal CPU/RAM requirements) is safely written to disk and queued for Amavis SPAM/AV detection, after which good mail is punted back through the system while bad mail is discarded or quarantined. Reliable, understandable, cautious. :-) - Jeff -- GVADEC 2004: Kristiansand, Norway http://2004.guadec.org/ "I believe in true love. But I am easily satisfied." - Miguel de Icaza -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
