When comparing different anti-spam solutions, there are several important features that are often overlooked.
Why SpamFilter?
Innovative, propietary anti spam filters
Many competitive products rely on existing publicly available spam filtering tools, like SpamAssassin and statistical filtering. Our SpamFilter ISP was first released in 2002. During these years, we at LogSat Software developed several proprietary filters to stop spam. Both the SFDB (SpamFilter Distributed Blacklist) and the SFDC (SpamFilter Distributed Content) are centralized databases, updated in real-time by thousands of SpamFilter installation throughout the world. SpamFilter ISP was the first product able to scan images or spam, even when they were being embedded in PDF files.
Is the sender notified when their emails are blocked?
A key feature for SpamFilter is the way spam email is rejected. When evaluating other anti spam software, ask the vendor how the sender is notified when their emails are blocked. There will be usually two kinds of responses, as is described below.
- Case #1 - the sender is not notified
- Case #2 - the software will send a non-deliverable email bounce
In many cases, the answer will be "they are not - our software is so accurate that there is no need to notify the sender as all blocked emails will be spam".
In reality, no anti spam software will even be 100% accurate, and at some point, legitimate emails will be blocked by mistake. When asking the salesperson how their software will handle the "rare" cases when good emails are blocked, again often the answer will be that "your customer can always check their quarantined emails every day to see if any good emails have been stopped by mistake". Our opinion is that if you implement an anti spam solution, you can't possibly ask end users to go thru all their blocked emails every day to see if any mistakes are made.
Imagine this scenario. John, your customer, is expecting an email from Mary, his financial advisor. mary sends John an email, advising him to purchase some stock. The email is incorrectly detected to be spam and is thus blocked. Your "potential" anti spam software will block the email and place it in John's quarantine, but does not notify Mary that the email was blocked. Since she did not receive any non-delivery notifications, Mary will assume John received the email. John did not receive any emails, and does not purchase the stock. After a few days eventually John does check his spam quarantine and see Mary's email. John calls your tech support and, rightfully so, complains about his huge monetary loss.
Some anti-spam software will actually inform the sender than an email was blocked by sending an email back to the sender to inform them that their email was blocked. It is to be noted that in most cases spammers will fake the sender's email address, using either non-existent addresses, or by using real spoofed addresses. So if the anti-spam software blocks 200,000 emails in a day, it will most likely be sending out tens of thousands of emails each day to innocent victims on the internet who had their email addresses spoofed. You are essentially sending spam yourself, and your IP address will often be itself blacklisted by other anti-spam vendors!
So how does SpamFilter handle blocked emails? Simple. When a spam email is received, SpamFilter will reject it by sending an SMTP error code back to the remote server that sent the email. This forces, per RFC, the remote server to send back a non-deliverable email to the sender, which will thus always be informed that their email was blocked. Please note that with this method SpamFilter will never send out an email to the sender to inform them their email was blocked, saving huge amounts of bandwidth, and preventing your network from being a source of spam as in case #2 above.
SpamFilter is able to reject the email with an SMTP error code as our filtering engine is so fast that we know if an email is spam or not even before the entire email has been received, and can thus decide on the spot if it should be accepted or rejected. Other systems will often first receive an email, and only after it has been received in whole will they be able to make a determination if it is spam. Of course at this point it is too late to output an SMTP error code, and thus other systems may not be able to emulate our functionality.
Handling of non-deliverable emails
Please note that is a major feature of this behavior is that SpamFilter will never send a non-delivery email for each email that is rejected. instead, this task is delegated to the remote server. This is very, very important, as some other anti spam products send themselves a non-delivery email back to the sender for each spam email that is stopped. This means that your network would be the source of potentially hundreds of thousands of non-delivery spam emails, one for every spam email you receive. This would cause your own network to become blacklisted by many other anti spam providers as you would be essentially a source of spam.
Web Interface for End-User Quarantine Access
End-users can access their quarantined emails via a web interface. This allows them the ability to view the spam emails that were blocked by SpamFilter, and to force the delivery of any valid email that was blocked by mistake. It is to be noted that once a user forces the delivery of an email from the quarantine, SpamFilter will automatically match the sender with the recipient. From then on, all future emails from that sender to that recipient will be automatically whitelisted. This will greatly reduce the risk of blocking valid emails in the future.
Related feature: Microsoft Outlook Integration
