When comparing different anti-spam solutions, there are several important features that are often overlooked.
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.
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
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.
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.
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
For corporations using Microsoft Outlook email clients, a very nice feature is the ability to display a "SpamFilter" folder within the Outlook client itself. This web-enabled folder then allows the end users to see their quarantined emails directly within their Outlook client without the need of an external web browser. From Outlook they can then view/deliver any emails in the quarantine.