You may know that Kerio Connect has long had the ability to remove attachments or block the entire email. If nobody should ever be sending you .exe files and you can't trust your users not to click on such things, this can be a helpful feature. You can have the original email (with attachment) sent to a specific address for handling while letting a stripped message still get to the intended recipient (to let them know that it was sent).
That's all good as far as it goes, but it could be better. You can't, for example, block zip file attachments but allow certain senders to be whitelisted. That would be handy, but the spam whitelists are ignored when it comes to attachments filters. That is, whitelisting someone won't cause the attachment filter to be bypassed - they will be treated as any other sender would be.
What about the idea of adding spam score to messages with those attachments? That would allow whitelisting to work, but unfortunately there are several obstacles in your way. The first is the most obvious: Kerio's Custom Rules have no provision for identifying messages with attachments of any kind, never mind specific types. There is a way around that by adding to the Spamassasin rules already in Kerio Connect. We'll see in a minute that this is an incomplete solution, but let's just see what it takes.
Adding a custom rule
Under the Kerio/mailserver/plugins/spamassassin/rules directory you'll find a number of files. For our purpose, it's not necessary to understand what they all do; we're just going to add a new file for our attachment rule. We'll call it "80_zip_attachment" and it will contain this text:
mimeheader BAD_ZIPSRULE Content-Type:raw =~ /^application\/zip;/ score BAD_ZIPSRULE 0.2 describe BAD_ZIPSRULE filter zips
We've created it with a low score (0.2) for testing; if we actually put this into use we'd use a larger score. After restarting the mailserver, you can send yourself a test message containing a zip attachment. If you then "View source", you might see something like this in the X-Spam-Status header:
X-Spam-Status: No, hits=0.0 required=4.2 tests=AWL: 0.145,BAD_ZIPSRULE: 0.2,BAYES_00: -1.665, TOTAL_SCORE: -1.320,autolearn=no
Why do I say you might see that?
Because you might just get no X-Spam-Status header at all.
Spam Filtering Limits
Your mailserver.cfg file has a section for Spam filtering.
<table name="SpamFilter"> <variable name="AssassinEnabled">1</variable> <variable name="FilterEnabled">1</variable> <variable name="CheckRelayedMessages">0</variable> <variable name="ScoreThreshold">42</variable> <variable name="ScoreBlock">80</variable> <variable name="Action">2</variable> <variable name="BounceIfDenied">0</variable> <variable name="BounceIfBlocked">0</variable> <variable name="InsertSubjectPrefix">1</variable> <variable name="SubjectPrefix">**SPAM**</variable> <variable name="AdminNotify"></variable> <variable name="AdminNotifyDenied"></variable> <variable name="SurblEnabled">1</variable> <variable name="ShortTimeout">120</variable> <variable name="LongTimeout">120</variable> <variable name="RestartWait">120</variable> <variable name="MessageSizeLimit">128</variable> <variable name="DkimEnabled">1</variable> </table>
See that "MessageSizeLimit" I highlighted? Any message that exceeds that size (128K) doesn't get checked by Spamassassin. It's just given a pass.
Understand that this setting in no way affects the Attachment Filter. If you set that to block zip attachments, that will work regardless of message size.
Nor does it affect Spam points you might add through custom rules. If you have a custom rule that adds points and attached a zip too large to be scanned, your X-Spam-Status header might look like this:
X-Spam-Status: No, hits=2.0 required=4.2 tests=CUSTOM_RULE_TO: 2.00,TOTAL_SCORE: 2.000
That's missing the BAD_ZIPSRULE scoring because the message exceeded the MessageSizeLimit setting, but the custom rule is not affected. The MessageSizeLimit only affects Spamassassin. Points added or subtracted by Custom Rules are still applied.
Can you increase the MessageSizeLimit setting? Yes, but with caution. Spamassassin will gulp down any meal that you say is safe to eat. That is, if you stop the server, edit that file manually to tell it that Spamassassin that can examine 1024K files, and restart, Spamassassin will load larger messages into memory.
That could cause performance issues; see this "Question about Max msg size" thread for more discussion, including the rather obvious suggestion that Spamassasin could be a lot smarter about this by at least reading X bytes, which might catch some problems. By the way, this other thread implies that Spamassassin can be made to choke by the sender. I don't think that's true in Kerio Connect, at least not in my testing.
So, filtering attachments via Spamassasin wouldn't work for larger attachments. We could limit incoming message size at the server to something less than our MessageSizeLimit to avoid not processing large messages, but that is a draconian solution. It's not necessarily a bad idea, but it would seriously constrain the size of email you could receive. If you sort your INBOX by size you'll likely quickly agree that is not feasible for most of us.
A way to avoid this problem is to give your customers some other method to deliver files to you. You could have an FTP server or use something like DropBox, Samepage or many of the other competing cloud apps. Email is really not a great solution for file transfer, but convincing your customers of that might not be easy..
It would be easy enough for Kerio to add Spam score in the attachment filter configuration or allow Custom Rules to test for attachments. Unfortunately, they do not. If they did, we could effectively block by setting a high point policy but a whitelisted customer would still be able to send us attachments. Wouldn't that be nice? I have a feature suggestion in titled "Spam score for attachments"; if you agree with me and are a Kerio Connect Administrator, please click on "Suggest Idea" from your Admin panel and vote up that suggestion.
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version