Why_ASSP?
Why ASSP?
It has long been clear to me that the best place to stop spam is at an organization’s SMTP server. This is true for the following reasons: Most spam has an invalid bounce address, so notifying non-delivery simply bounces to Postmaster, creating even more wasted bandwidth. Failing to notify non-delivery is a problem for false-positives. The SMTP server is the only place where spam can be stopped before entering your system. The only possible feedback for spammers to void an address is from the SMTP server. Spam that passes through your SMTP server into mailboxes incurs cost to your organization: storage, transmission, backup, deletion – in all these ways spam costs you money. The only way to minimize cost is to reject it at the initial point. However, mail transport systems are slow to adopt new technology, and spammers are quick and flexible, able to adopt new technology as quickly as it becomes available. Consequently, most SMTP servers are ill equipped to stop spam.
Furthermore, one spam-stopping solution could work with all existing SMTP servers if it was implemented on a second level – a transparent SMTP filtering proxy. This was my goal for this project.
I wanted a server that accepted connections on port 25, passing the transmission on to the official SMTP server, and relaying its replies back to the SMTP client. But when enough of the message had been transmitted to validate its legitimacy the ASSP server could either pipe the remainder of the message to the official SMTP server or close the connection to the official SMTP server and ignore the remainder of the message.
The Anti-Spam SMTP Proxy (ASSP) Server project aims to create an open source platform-independent SMTP Proxy server which implements whitelists and Bayesian filtering to rid the planet of the blight of unsolicited email (UCE). UCE must be stopped at the SMTP server. Anti-spam tools must be adaptive to new spam and customized for each site’s mail patterns. This free, easy-to-use tool works with any mail transport and achieves these goals requiring no operator intervention after the initial setup phase.
Who is it for?
ASSP’s primary target audience is mail administrators or system administrators at smallish institutions. If you operate an ISP or a mailhost with a heterogeneous user base you may not have a good enough consensus about what spam is or is not. It should work well with between 1 and 300 client addresses and a mail volume of up to around 100,000 messages per day. Testing has not been done to verify these ranges – if you discover otherwise please notify the author and he’ll update the documentation. Who is it not for?
ASSP is not for the following: 1) Individual clients -- ASSP must be installed together with a SMTP server. 2) Domains which receive mail indirectly, fetchmail for example.
What features make ASSP great?
Easy browser-based setup (optional). Uses your existing message transport and existing SMTP server. Works with Sendmail, qmail, Postfix, Imail, Exchange, Courier, Mercury, Lotus Notes, and all other standard SMTP servers. Runs on Linux, Unix, Windows, OS X, OS/2, and more. Automatically customizes to your site’s unique email profile. Automatic whitelist – noone you email will ever be blocked. Senders receive immediate notification if mail is blocked but no erroneous bounces are ever generated. Redlist keeps an address off the whitelist. No-processing addresses pass through. Makes use of honeypot type spambucket addresses to automatically recognize spam and update your spam database. Bayesian filter intelligently classifies email into spam and non-spam. Supports additional site-defined regular expressions to identify spam or non-spam email. Can optionally block all non-whitelisted email (for anti-spam zelots). Mime encoded and other camouflaged spam is also recognized. Automatically maintains the spam and non-spam databases. Accepts whitelist submissions and spam error reports by authorized email. Optionally rejects executable attachments from non-whitelisted (or all) addresses. Free (as in speech) software -- Licensed under the GPL. Practically no maintenance required. Active user community and email list for support questions. Source code included if you need to customize your installation. Runs as a service in Windows NT / 2000. Optionally blocks no mail but adds an email header and/or updates the message subject. Optionally uses community-based spam statistics to identify hosts that are likely to send spam or non-spam mail. In *nix environments can switch to non-root user. Also supports chroot jail. Individual users can be configured to receive all mail. Shows detailed analysis of spam rating process for specific messages. Option to forward a copy of every rejected mail to an address. No perl modules to install -- runs complete "out of the box". Can block spam-bombs (when spammers forge your domain in the from field). Keeps spam statistics for your site. Detailed up-to-date documentation. Can listen on more than one smtp port. And much more!
What is different about how ASSP handles false positives (i.e. good mail that was blocked) and other content scanners?
If you are presenting ASSP to clients / management then you NEED to explain this to your management. With most client-based filters (POPFile, SpamBayes, SpamAssassin) senders receive NO NOTIFICATION if their mail isn't delivered. With most of these solutions, the user bears full responsibility to VERIFY that no good mail is blocked. However, this is NOT TRUE with ASSP.
ASSP is the ONLY solution I am aware of (I haven't made an exhaustive search) that when spam is blocked the SENDER RECEIVES NOTIFICATION, and it does this without generating non-delivery reports that bounce and bounce again because spammers forge their from address.
Imagine three scenerios:
1) No filter. A client sends an order by email. Your orders' desk gets roughly 10 spam for every order. Their job satisfaction is low because they spend almost as much time deleting (possibly offensive and sexually explicit) spam as they do filling orders.
2) Client-based filter: A client sends an order by email. Their message is accidently flagged as spam. It is either (a) automatically moved to a "spam" folder, or (b) manually moved there because the clerk always does that with messages marked spam. The customer thinks their email got through, but how long will it sit there before either (a) they call and complain and the clerk finds it mislabeled as spam or (b) the clerk gets around to looking at all that spam and notices the 1 in 100 that was miscategorized.
3) ASSP: A client sends an order by email. Their message is accidently flagged as spam. They IMMEDIATELY receive notification from their email server that the message was not accepted. They either call or email again, saying "How come my message wasn't accepted?" The clerk replies back, saying, "Send it again, it will get through now." And it does because they are now on your whitelist.
But let's think about this more seriously. First it is unlikely (not impossible, but unusual) that you receive critical business correspondance from someone you HAVE NEVER EMAILED before. I don't have a percentage, but I know that business doesn't work that way. Business is built on relationship, and relationship doesn't come out of the blue. Secondly, what foolish mail admin set up ASSP without putting a number of orders or "critical business correspondance" in the notspam or errors/notspam folder? Come-on, folks, this is where we start (if you take a minute to even look at the documentation, and if not, then you get what you deserve). If ASSP is going to give false positives, they're NOT going to be on your "critical business correspondance" -- orders, RFQs, and the like. What gets blocked is Thelma's ebay notification (which is kinda spammy anyway, now that you mention it, it's just that she wants it), or Ralph's porn of the day that he probably shouldn't be getting at the office anyway, but since he's the VP's kid, nobody has stopped him.
Furthermore, you have the opportunity to use "expressions to identify non-spam" to make 100% sure that mail that follows certain patters (like an order would) gets through.
I agree that false postivies are a big deal. But I want to emphasize that ASSP has been designed from the very beginning to handle false positives better than any other solution I have ever seen.
You have to filter. Spam is only going to get worse. If you filter, you will have false-positives -- it's inevitable. What solution has the best means to deal with false positives and still does a reasonably good job filtering? That's the solution to use.
