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 fixes this problem, so far no mail servers have mysteriously begun hating me.

smtp_line_length_limit = 250000