Other issues in this category (16)
By hook or by crook?
Our objective is to make reading a daily habit that is rooted in the lives of our people.
Dubai Emir and UAE Vice President Mohammed bin Rashid Al Maktoum
In our publication "Who issues the spam verdict", we touched on the fact that email filtering on PCs isn’t perfect, but it is reasonably effective (we estimate that Dr.Web filters out 98% of unwanted emails). Regardless of the filtering technologies it employs, an anti-spam relies on the spam-related information it receives from virus analysts in order to do its job. Together with other updates, the information is delivered to user machines that have the Dr.Web anti-spam installed on them.
Can anti-spam filtering be 100% effective?
Sometimes employees who come to work early and open the morning email get their systems infected. When others eventually arrive and read messages, nothing bad happens. That’s because by that time their anti-viruses have already received the latest update and can detect new threats. The same is true of the anti-spam: spam gets into mailboxes because the corresponding update hasn't yet arrived.
The only way to get rid of a message that was received before an anti-virus update and didn’t get marked as spam is to delete it manually. An anti-virus cannot easily make changes ex post facto to emails that are sitting in customer inboxes, and anti-viruses that protect desktops don’t rescan previously received emails (something that could make opened messages disappear from the screen).
Is there a solution? Sometimes. Let's see how an anti-spam works on mail servers—this is where messages are processed before they get into mailboxes. Of course, that’s provided your system administrator or ISP has an anti-spam installed on their servers.
The first thing you should know is that an anti-spam on a server always works as a plugin that connects to the server. It requires an operational mail server. And this is both good and bad. On the plus side, the product for servers is not so complex—for example, it doesn't need to solve problems that involve sending and receiving emails that don't comply with established standards—this task is performed by the mail server. On the other hand, a plugin is limited by the server's functionality. Sounds logical, right? And many server features are changed regularly without notice.
Let's use a simpler example. Surely, many of you have installed browser plugins and found yourselves in a situation where a new browser version turned out to be incompatible with the plugins. On my PC this happens once a week with the Sharebutton plugin for Pinterest (by the way, here's a Dr.Web page on Pinterest).
The situation with mail servers is exactly the same. Regardless of which mail server is in use—MS Exchange, Domino, Postfix (there are a lot of them)—plugins can only operate using a mail server API. Alas, the API can be changed and sometimes the changes are for the worse, but we'll grumble about that some other time.
To prove our words, let's look at the Dr.Web for MS Exchange documentation. Why this product? Only because it’s quite popular with Doctor Web's customers.
Dr.Web for Exchange Server 2003/2007/2010 supports VSAPI (an anti-virus scanning interface that was developed by Microsoft for Exchange servers). The plugin also supports server roles for Exchange Server 2007/2010 and 2013 SP1 and can be installed on servers that have various roles. Furthermore, it supports transport agents (anti-virus and anti-spam agents) for Exchange Server 2007/2010/2013.
Skipping ahead: careful readers have probably already noticed that different mail server versions are specified for the three integration methods—and there is no guarantee that the next version won't offer another way to integrate plugins with the server.
But let's get back to the features of anti-virus solutions for mail servers. Having to operate over an API somewhat limits their capabilities. No matter which developer comes up with a solution for MS Exchange, the basic functionality will be the same. A mail server will receive emails, check whether the messages comply with certain standards, and then let the plugin do its job. The plugin will examine the received information and decide whether a message is spam or whether it contains malware. The mail server will get the verdict and use its settings to perform certain actions with the message (forward it to a certain address, delete it, notify the sender, etc.).
The advantages of using an anti-spam on a mail server are quite obvious:
- Emails are checked faster
- PC resources aren’t wasted
- Situations involving users clicking on links and getting their systems infected are less likely to happen.
However, the limited capabilities of mail servers place a limit on plugins too. For example, in the case of MS Exchange, most plugins can use only a very narrow set of technologies to filter out spam and detect malware.
"It appears that anti-spam filtering on a mail server isn't really much better than an anti-spam on PCs. Why would I need one then?" — think some system administrators who use neither an anti-virus nor an anti-spam on their mail servers!
And as far as mail server traffic-filtering is concerned, the administrators are VERY wrong. But that's a story for another Anti-virus Times issue.#email #spam #Dr.Web_technologies
- Filtering spam on mail servers helps prevent infections and data leaks caused by user carelessness purely because users won't be receiving bogus emails.
- There are a lot of information security myths even among IT professionals. Myths impregnate regulation documents and security standards. Myths are often used as the foundation for information security systems and PhD dissertation defences. I think that most of our readers have already noticed that we aren’t reinventing the wheel but are rather telling people about logical and reasonable things that go unnoticed by those who are supposed to notice them.
- There is a persistent belief that protecting PCs is enough and that email protection must consequently take a back seat. To learn how to configure mail-filtering properly, how to schedule regular mailbox checks to expose previously unknown threats, and how to scan messages while they are being opened, please refer to the documentation for the corresponding Dr.Web products.
- 4. Dear System Administrator, Information Security Heads, and Business Owners: Think! So long as you are not required by law to filter email on your servers, everything depends solely on you! ☺