A case study in troubleshooting the email pipeline, chapter 2

By | September 11, 2017

A couple of days ago, I posted a saga about troubleshooting my email server and coming to the conclusion that Constant Contact was sometimes generating emails whose “Date:” headers ended with CR rather than CRLF. I was wrong. Constant Contact’s headers are fine.

Today, I noticed some additional messages in my notspam archives showing a problem similar to the ones from Constant Contact which I noticed before, but the messages I noticed today were not sent by Constant Contact.

I investigated and discovered that these messages had gotten corrupted by a bug in spamitarium: it wasn’t handling empty headers properly. So I fixed that.

After doing that, I had a brainstorm: let’s see if any Constant Contact messages have come into my inbox since I deployed my workaround a few days ago, and if so, were they handled properly. Lo and behold, there were new Constant Contact messages, and they had the concatenated header problem that I thought I’d already fixed. D’oh!

I then flailed around a bunch trying yet again unsuccessfully to reproduce the issue, before I made a fortuitous discovery: when I was working on this issue a couple of days ago, I had modified the spamitarium script called by bogofilter to save a copy of both its input and its output in /tmp, and I had forgotten to turn that off when I (thought I) was done fixing the problem! I went and looked in /tmp and found the files associated new Constant Contact message, and at long last I was able to identify the real root cause of the issue:

Date: Fri, 8 Sep 2017 13:44:33 -0400 (EDT)
From:
  "Really Long Really Long Name" <somewhat-long-address@example.com>

Remember how I mentioned three paragraphs ago that spamitarium wasn’t handling empty headers properly. Well, it interpreted the From: line shown above, which was wrapped because its contents were so long, as an empty header, and therefore it handled it incorrectly.

Why wasn’t I able to reproduce this today or when I was debugging this a couple of days ago? Because here’s what that header looked like when the message arrived in my IMAP folder:

Date: Fri, 8 Sep 2017 13:44:33 -0400 (EDT)
From:   "Really Long Really Long Name" <somewhat-long-address@example.com>

Something between the internet and my mailbox kindly “fixed” the From: header by unwrapping it, so what I was feeding into spamitarium to try to reproduce the issue was not what spamitarium was actually getting when the original message was received by my server. *sigh*

As a result of this, I’ve completely refactored the header-parsing code in spamitarium to avoid issues like this. Frankly, that code needed to be rewritten, and now it has been.

For reading this far, you get a photo of the little field mouse that my son and I saw when biking home from ice cream yesterday:

Share

One thought on “A case study in troubleshooting the email pipeline, chapter 2”

  1. Pingback: A case study in troubleshooting the email pipeline – Something better to do

Leave a Reply

Your email address will not be published. Required fields are marked *

Your post must include a link to this post.

How does this work?
Write a response on your own website and include a link to this post. Then submit your response’s URL here. Your response may appear here after moderation. To update or remove it, edit or delete your original post and submit the same URL again. Learn more about Webmentions.