Письма, получаемые в Base64, не декодируются автоматически

Question

Многие агенты в моей компании получают электронные письма, которые по-прежнему содержат заголовок Barracuda (брандмауэр спама) (даже в представлении "сообщение", а не в представлении "источник") и закодированы в Base64.

Они отправляются из-за рубежа по большей части, так возможно ли, что локали конфликтуют? то есть. если есть азиатский символ, отправляемый поверх, это, в первую очередь, требует кодировки Base64.

Наш почтовый сервер - SmarterMail Enterprise 14.5 и Intermedia Exchange, прошивка Barracuda v7.1.1.003 (2015-09-28 16:36:19).

Пример:параллельное сравнение того, что видит пользователь и как выглядит источник изображения в Barracuda.

Таким образом, большая часть заголовка все еще скрыта от пользователя, но электронные письма по-прежнему не должны выглядеть так.

Я подозреваю, что причиной проблемы является следующее:

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

Эта проблема локали / кодирования сбивает с толку наш брандмауэр спама?

Answer 1

Нет, это не проблема. Content-Transfer-Encoding совершенно действителен и довольно распространен.

Проблема в том, что над заголовком received-spf вставлена пустая строка . (В левом окне по какой-то причине в этой точке находится толстая красная полоса.)

Пустая строка указывает, что заголовки сообщения заканчиваются в этой точке и начинается тело. Поскольку самое внешнее объявление Content-Type (multipart/related ) находится ниже поддельного разделителя, почтовый клиент получателя даже не смотрит на него - он просто возвращается к не-MIME-режиму "простой текст".

Выясните, на каком этапе вставляется пустая строка. Сравните то, что Barracuda получает с тем, что хранит (для этого вам может потребоваться временно отключить TLS). Проверьте, ведет ли он себя так же, если вы отправляете более простое сообщение (т.е. не из MS Exchange); попробуйте отправить тестовое сообщение непосредственно в спам-фильтр, например, используя swaks .