Emails being received in Base64, not being automatically decoded

Question

A lot of agents at my company are receiving emails that still include the Barracuda (spam firewall) header (even in "message" view, not "source" view) and are encoded in Base64.

They are being sent from overseas for the most part, so is it possible that the locales are conflicting? ie. if there's an Asian character being sent over that necessitates the Base64 encoding in the first place.

Our mail server is SmarterMail Enterprise 14.5 and Intermedia Exchange, Barracuda Firmware v7.1.1.003 (2015-09-28 16:36:19)

Example: Side-by-side comparison of what the user sees and what the source of the image looks like in Barracuda.

So most of the header is still hidden from the user, but emails still shouldn't appear like this.

What I suspect is causing the problem is the following:

Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Is this a locale/encoding issue confusing our spam firewall?

Answer 1

No, that's not the problem. Content-Transfer-Encoding is perfectly valid and quite common.

The problem is that there is a blank line inserted right above the received-spf header. (In your left window, for some reason there's a thick red bar at exactly that point.)

A blank line indicates that the message headers end at that point and the body begins. Since the outermost Content-Type declaration (the multipart/related one) is below the bogus separator, the recipient's mail client doesn't even look at it – merely falls back to the non-MIME "plain text" mode.

Figure out at which step that empty line is inserted. Compare what Barracuda receives with what it stores (you might have to temporarily turn off TLS for that). Check if it behaves the same if you send a simpler message (i.e. not from MS Exchange); try sending a test message directly to the spamfilter, e.g. using swaks.