More and more companies are starting to use some form of email encryption. A problem with email encryption however is that in order to scan encrypted email for viruses or spam, the email should be decrypted before scanning. A typical solution to this problem is to use a centralized email encryption gateway placed between the content scanner and the Internet (see image below). With this setup, email gets decrypted before scanning for viruses or spam.
While this setup allows you to scan all email, there are a couple of issues with this setup. The email encryption gateway has to handle all incoming email including spam (in practice most spam can be blocked at connection time using RBL checks).
Although security wise this is not really a problem, it's better to block viruses and spam as soon as possible. Handling email which will then be removed by the next server is just a waste of resources.
A bigger issue however might be that once a mail server has accepted a message, the mail server is responsible for delivering the message. If the message later turns out to be spam, the server is no longer “allowed” to bounce the message (even though it is technically possible to bounce the email, chances are that your mail server will be blacklisted because of backscatter).
Since the message cannot be bounced back, the only options left are to deliver the email, drop the email, or quarantine the email and notify the recipient.
If an email contains a virus, generally the best option would be to drop the email. If an email is flagged as spam and the spam score is high enough that a false positive is unlikely, most recipients probably want the system to drop the email instead of quarantine it.
Dropping the email however can be problematic in some countries. For example German law, and there are probably other countries with similar laws, forbid to drop email after the email has been accepted unless the email is harmful1.
So dropping an email which contains a virus is allowed, since the message is harmful, but dropping an email which is flagged as spam is not allowed. An email flagged as spam therefore either has to be delivered, alternatively with a tag added to the subject to indicate that the email was detected as spam, or quarantined. Both options are annoying for recipients if a large number of spam is received every day.
Instead of scanning for spam or viruses after the message was accepted, a better option would be to reject email at delivery time before accepting the email (i.e., place the anti-virus anti-spam scanner between the Internet and the email encryption gateway).
When a message is flagged as spam, the sender will be notified that the message was not accepted. The problem however with scanning before decryption is that the content scanner can no longer scan encrypted email. One option would be to scan again for viruses and spam after decryption. This however only partly solves the problem. Email which was initially encrypted, and could therefore not be scanned by the first scanning process, might be flagged as spam by the second scanning process. If this happens, the email is already accepted and the email can therefore not be dropped nor bounced.
The best way to solve this issue is to decrypt and scan incoming email before accepting the email, i.e., deploy the decrypt and scan process as a "before queue filter". To decrypt email before the email is accepted, we have added an email decryption Milter service to the CipherMail gateway.
The email decryption Milter should be configured before the anti-virus anti-spam Milter to scan to make sure that encrypted email is decrypted before scanning. Because the decryption and scanning process is now configured as a "before queue filter", encrypted email can be scanned for viruses and spam before the email is accepted.
The Milter service will be available in the next release of CipherMail Enterprise.