Ausnahme(n) für "Quarantine unscannable and encrypted Content"

Your simple problem exposes multiple limitations in the UTM Email Filter.  I do not expect UTM to get any better, but perhaps Product Management will read this and understand the problem and deliver a future product with better features.

1) You need multi-factor exceptions.    UTM only supports single-factor exceptions, such as these:

• "Ignore unscannable files sent to <target user>".
• "Ignore unscannable files sent from <source user or domain>"

2) Creating an exception for "Source user or domain" is only safe if the source can be trusted.   This means that you need at least SPF validation, ideally DMARC.  Of course, DMARC is not supported at all.   To ensure that SPF is checked, you have to turn it on for everything.   My experience is that SPF will block very few spam messages that would not be blocked by another rule, but it will block some legitimate mail because a lot of legitimate senders have errors in their SPF record.   So maybe applying an exception without authentication is not a big risk in practice, but it is definitely scary in concept.

3) If you turn on SPF blocking, your only option is to enable it in block mode.   No ability to test first to evaluate the consequences.

4) After enabling SPF blocking, you need to review messages to determine if the blocked messages are legitimate or not.   If a message is not quarantined, Mail Manager does not capture enough information for you to determine whether the message was legitimate or not, so that you can create an override for the legitimate senders with incorrect SPF.

5) if you determine that a sender has an error in their SPF record, your only option is to disable SPF checking for that source address, opening yourself back up to impersonation attacks.   Ideally, a spam filter product should allow you to override the sender's SPF with supplemental or replacement rules written iusing SPF syntax.   (I have looked at a lot of spam filter products recently, and have yet to find one that allows SPF corrections, so this complaint is general, not specific to UTM.)

So, your best bet is probably to configure an additional email filter that does support mulit-factor rules.   The biggest and most expensive vendors can do this, but for those of us with lower budgets, the pickings are slim.   The SmarterMail product from SmarterTools.com can be used for free as an incoming or outgoing email gateway and spam filter.   The "Custom Rules" feature can create multiple-factor filter rules.   It might allow you to turn off the check in UTM, then have it enforced in the secondary gateway with greater control.   I use the English version, but I think they offer translations for several major languages.

Dear Douglas,

thank you!

I have one "Source Domain" which I can definitely trust and I would, at least for a test, take the risk to do that WITHOUT SPF (I have the same concerns with SPF as you).
But I don´t see how I can create such a "simple" Exception ["Ignore unscannable files sent from <source user or domain>"].
Can you point me the right way?

Under [Email Protection - SMTP - Exceptions] I found that I can make an Exception and click "Skip These Checks: Email encryption", but that is something diferent? Or not?

Thanks in advance!

TJ

Because this is configured on the "Malware" tab, I think you have to create an exception for "Malware Checking". 

This adds more risk than you probably want.

Thank you!

Of course I do NOT want to make an Exception for ANY Malware-Scan, that‘s too much, even if it is only for a single Sender-Domain.

No other way possible?

TJ

Thank you!

Of course I do NOT want to make an Exception for ANY Malware-Scan, that‘s too much, even if it is only for a single Sender-Domain.

No other way possible?

TJ

any news or workarounds on that?

we have the same issues and whitelisting the sender with "skip extension blocking" doesnt help, because its a different block reason.

Hi!

Unfortunately not, I still release every due to unscannable Content quarantined E-Mail by Hand...  :-(

TJ

For your management, you might need to explain that password-protected files (including SPX) have these problems, in order of importance:

1. Password-protected files have no breakin evasion.   
   If the file is intercepted, the attacker can crank up an automated process to guess infinitely until the password is found.   I don't know how to write or find such a program, but I assume that the code is available on the dark web. 
   HTTPS prevents a middleman from intercepting messages during transmission, but you have to study the message headers to know whether a particular message was HTTPS-protected at each hop.   
   Even then, many message flows originate or terminate on a hosting service, or relay through a cloud-based spam filter.  In these cases, neither sender nor recipient can ensure that a password-protected file was not intercepted at one of these hops.
   
   
2. Password-protected files have no password recovery.   If the password is forgotten, the data is lost forever.
   
   
3. Password-protected files complicate file management.  If the contents are not immediately extracted to a non-password file, you run the risk of having many files with many passwords, with resulting confusion about which password is associated with which file.  For zip files, immediate extraction is relatively easy and likely to happen.   For SPX, removing the password is more complicated, so it is more likely to be omitted.

On the other hand, I wonder if password-protected files are actually used by the bad guys, at least those doing random attacks.   This type of threat requires the attacker to celiver the password-protected file and the password at relatively the same time, as well as convincing the user to open the file using the password.

Are you seeing files trapped by your defenses that you discard rather than forwarding to the requested recipient?

Zip files without passwords are a different matter, since bad guys have been using zip file attacks for a long time.

S/MIME and PGP encryption methods are even more difficult for an attacker to use, because they require configuration and information sharing between sender and receiver.   Unauthorized usage of these technologies are likely to indicate an insider threat.

Thank you!

Your Post indicates (in my eyes) that it might not be neccessary to block encrypted ZIP-Files ("are actually used by the bad guys").

I do not think so. And I believe SOPHOS also doesn´t think so. After all just a few days ago I got an E-Mail from SOPHOS where they announce, that "Block encrypted Content" will be the Default Setting in comming FW-Releases. And they recommend to activate this Setting Right now.

OF COURSE encryptes ZIP-Files also have disadvantages, but at the moment this is a (may be the only) simple way to encrypt and decrypt files sent by E-Mail WITHOUT the Need to install additonal and the same Software on both sides (ZIP-Capability should be available on every Computer "out of the box").

Therefor it would be REALLY NICE to have the opportunity to define Excetions.

TJ