Effective dovecot+sieve extension filtering

After some recent conversations with a colleague about creating a simple shield that would stop some of the dangerous crypto/ransomeware I set about creating such a filter.

The premise was simple, move all mail containing predefined attachments under a certain size to a different folder. Sounds like a fine job for the sieve filter to me.

A quick search on the internet resulted in some basic ways to achieve this sort of behavior, however most were plain wrong in the execution of the regex statements. Which as it turns out should not even be used, the pigeonhole addon does all the required mime handling for us.

Problems with most solutions:

  • Regex statement per extension which creates an unreadable mess (and plain kills the server performance on larger emails)
  • Not limiting the search areas, this results in a lot of false positives (e.g. any of the extensions appearing AFTER the filename has been specified (within the encoded attachment) would trigger the rule)
  • Failing to correctly identify and target the different filename formats (filename=”test.zip”, filename=test.zip[\r\n] or filename=test.zip; and in extreme cases just a file= with no filename=)

The result code:

require ["body","fileinto","regex"];
 File potentially dangerous extensions into a seperate folder
  if allof (size :under 200K, header :mime :param "name" :matches ["Content-Type", "Content-Disposition"] [ "*.exe", "*.pif", "*.scr", "*.zip", "*.7z", "*.rar", "*.bat", "*.reg", "*.wmf", "*.emf", "*.wmz", "*.emz", "*.com", "*.hta", "*.cmd", "*.vb", "*.vbs", "*.ws", "*.wsf", "*.wsc", "*.wsh", "*.ps1", "*.ps1xml", "*.ps2", "*.ps2xml", "*.psc1", "*.psc2", "*.msh", "*.msh1", "*.msh2", "*.mshxml", "*.msh1xml", "*.msh2xml", "*.scf", "*.lnk", "*.inf", "*.vbe", "*.js", "*.jse", "*.ocx", "*.docm", "*.dotm", "*.docx", "*.xlsm", "*.xltm", "*.xlam", "*.pptm", "*.", "*.potm", "*.ppam", "*.ppsm", "*.sldm" ])
    fileinto "Dangerous";

Now this doesn’t solve all problems presented with the current ransomeware (or other scams/virusses), but it does prevent a lot of the current exploits which were comming in in bulk.

Don’t forget to specify the folder in doveoct as a required folder:

namespace {
  type = private
  separator = /
  inbox = yes

  mailbox Trash {
    auto = subscribe
    special_use = \Trash
  mailbox Drafts {
    auto = subscribe
    special_use = \Drafts
  mailbox Sent {
    auto = subscribe
    special_use = \Sent
  mailbox Spam {
    auto = subscribe
    special_use = \Junk
  mailbox Virus {
    auto = subscribe
  mailbox Dangerous {
    auto = subscribe

December in the it department

While December for most people is a cheerful and happy month it is also has another side most commonly experienced by the IT department.

  • Spam rises notably
  • Hack attempts rise significantly (strangely the week after the Paris attacks they skyrocketed from French ip’s)
  • Server loads become more spastic, especially in retail

This year santa claus appears to be handing out free .biz extensions as a lot of spam (neatly formed and a great pain for the spam filters I might add) is arriving from freshly registered domains.

A quick example over the last 24 hours, for every ham e-mail there are 1.6 spam! (usually it’s below a 1:1 ratio)
spam 09-12-2015
Ham 09-12-2015

Postfix, DKIM and random failed verifications

While using the ever so popular PHP to send outgoing mail through Postfix while signing them with a DKIM signature (opendkim, DKIMProxy or any other implementation) most of the time this simple setup seemed to work just fine.
However as our `application` grew some emails start to bounce or otherwise be rejected by a DKIM (body) verification error (Gmail, Hotmail etc all use DKIM verification nowadays, which is a good thing).

It took a solid hour to start figuring out what was going on, as it isn’t easy to see what broke the signature. A big clue comes from the fact that most emails verified just fine and most services specify which part fails.

The main culprit turned out to be an ancient limit on the maximum length of one line (separated by \r\n or sometimes denoted as <CR><LF>), as described in the Postfix manual: smtp line length limit

Normally this should not be a problem (one expects the DKIM filter/milter to be the final pass), except that Postfix chooses to enforce this policy after pickup or (non_)smtpd_milters…..
This problem is very easy to trigger, just insert a minified js or css into an email.

Simply adding the following code to your main.cf fixes this problem, so far no mail servers have mysteriously begun hating me.

smtp_line_length_limit = 250000