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,
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.
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.
If this page was useful to you, please help others find it:
Kerio®, and related trademarks, names and logos are the property of Kerio Technologies, Inc. and are registered and/or used in the U.S. and other countries. Used under license from Kerio Technologies, Inc.
More Articles by Anthony Lawrence
- Find me on Google+
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site:
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Publishing your articles here
Jump to Comments
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.