Добрый день.
В версии 52.1.0 появилась проблема: не могу открыть некоторые вложения из писем. Возможно письма не совсем корректны, но они отправляются с другой организации и на них я повлиять не могу.
Проблема в версии 52.0.1 не наблюдалась. Специально скачал портабл версию 52.0.1 и 52.1.0 на другом компьютере и все перепроверил.
Интересное наблюдение, когда оригинальное письмо пересылается, то вложение уже открывается.
Я сравнил внутренность письма обычного и пересланного, а так же сохраняемые файлы из оригинала и пересланного письма.
Thunderbird не расшифровывает вложение из base64 оригинального письма и извлекает как есть, но из пересланного расшифровывает.
Прикладываю файл оригинального письма. Можете проверить.
https://www.dropbox.com/s/r464wd0ngsr5b … 6.eml?dl=0
В качестве решения я откатываюсь на предыдущую версию и замораживаю обновления

В выложенном письме PDF оформлен не как вложение, а как тело письма.
Может, это и является причиной. (Не помню, может ли по стандарту тело письма быть бинарным, или оно обязано быть текстовым.)

Бинарным оно естественно быть не может, только текст. По стандарту.

Письмо конечно несколько необычное, но в целом все соответствует, в том числе судя по заголовкам:

...
X-Mailer: SAP NetWeaver 740
Content-Type: application/pdf;
name="=?utf-8?Q?0=9B=D0=B5=D0=BD=D1=82=D0=B0_-_0=97=D0=B0=D0=BA=D0=B0?=
=?utf-8?Q?0=B7_=D0=BD=D0=B0_=D0=BF=D0=BE=D1=81=D1=82=D0=B0=D0=B2=D0=BA?=
=?utf-8?Q?1=83_=E2=84=96_5003291440=2Epdf?="
Content-Transfer-Encoding: base64
...

именно PDF в теле письма и ожидается.

PS: Thunderbird 24.8.1 открыл приложенный файл .eml без вопросов, вложенный PDF и сохраняет как PDF и показывает в Adobe Reader.
PPS: Outlook 2010 тоже открыл
PPPS: Thunderbird 52.1.0 не раскодирует содержимое письма, а так вот как есть и сохраняет... Естественно файл Reader'ом не читается

Под текстовым я, естественно, имел в виду "Content-Type: text/...". А под бинарным - всё прочее, что приходится заворачивать в Base64/UUE, и что почтовая программа не обязана уметь показывать самостоятельно.

Вот и я об этом. Вопрос только: это какая-то ошибка в данной версии выползла, или более строгое соответствие стандартам так проявляется?

Все письма с вложениями и без текста, которые у меня хранятся, оформлены как "Content-Type: multipart" с пустой секцией тела письма и следующей за ней секцией вложения.

Естественно нет. Параметра Content-type вообще может не быть, да и не было раньше. Или наоборот - может быть несколько в multipart сообщениях. А текст - это именно текст, байты с кодами 0x20-0x7f (изначально, в более поздних реализациях расширили до 0x20-0xff), плюс естественно управляющие символы 0x0d, 0x0a - они очень важны, например пустая строка (два подряд разделителя) отделяют заголовки от тела письма. Вроде бы (раньше по крайней мере точно) было ограничение на длину одной строки, как с этим сейчас - не в курсе

Конечно же ошибка. Тамошние программисты последнее время только новые ошибки добавляют и ломают то, что раньше работало. Ничего нового или исправленного уже нет много-много версий, разве что редактор html-сообщений несколько улучшился. По сравнению с версией 3.0...

В явном виде в заголовке может и не быть. Но в результате всего лишь код программ будет обрабатывать такую секцию, используя для Content-type умолчательное значение "text/plain". Поступать так им предписывает стандарт:

5.2.  Content-Type Defaults

   Default RFC 822 messages without a MIME Content-Type header are taken
   by this protocol to be plain text in the US-ASCII character set,
   which can be explicitly specified as:

     Content-type: text/plain; charset=us-ascii

   This default is assumed if no Content-Type header field is specified.

"Боже, как давно это было."

Но мы же говорим не о сообщении в целом, а о его секциях. В заголовке секции их тоже, конечно, может встретиться несколько, но действующим-то будет только один.

Нам явно нужно договориться. Понятно, что всё, завёрнутое в Base64/UUE/BinHex/QP и прочее подобное - это текст. Но этот текст - всего лишь транспортное представление некоего оригинала. А значение для нас (в контексте обнаруженной проблемы) имеет оригинал, а не транспорт.

Договариваемся - если мы говорим с точки зрения стандарта на формат почтового отправления, то это с ваших слов "транспортное представление" (мля... Транспортом всегда было явно другое, ну ладно, остановимся на "представлении"). Никакого "оригинала" с точки зрения стандарта нет, это только с точки зрения конечного пользователя может быть, так что не нужно настолько подменять понятия. Другой пример - картинка в формате .svg. С точки зрения "транспорта" файл текстовый, но для человека это "картинка"

Это откуда? В стандарте RFC-822 даже слова Content-type нет, раздел 5.2 это "Date and time specification. Semantics". Слова "mime" тоже нет.

Во-первых - да, согласен. Но мы же и рассматриваем всё это дело с точки зрения пользователя, ведь проблему в данном случае видит он, а не программа.
Во-вторых - нет, не согласен, потому как существует не только стандарт на формат сообщения электронной почты, но и стандарт, описывающий метод преобразования бинарных файлов в форму, пригодную для внедрения в это сообщение.

И что? А ничего. Из "текстовости" .svg вытекает только то, что для его внедрения в письмо не требуется прибегать к Base64. Однако это даёт ему "Content-Transfer-Encoding: 7bit", но никак не "Content-type: text/plain".
HTML, вон, тоже текстовый "с точки зрения транспорта", однако и он не "text/plain", и поэтому уметь показывать его почтовый клиент не обязан.
Хотя да, должен признать, что выше по странице моя делёжка на "текстовые/бинарные" была неаккуратной.

RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.
Цитата как раз и описывает интерпретацию сообщений, соответствующих RFC 822, который ничего не знает про MIME.
А RFC 822 давным-давно заменён на RFC 2822. В нём, правда, тоже нет ни слова про Content-type, зато в первом же разделе содержится отсылка на RFC 2045.

Ээээ... Да, really? А мне почему-то всегда казалось, что "Unicode Transformation Format". Ну то такое... Почти одно и то же, да

Товарищи, я все понимаю - холивар и все такое. Кто поможет правильно оформить баг в трекере?

Пятачок: "Да, Винни, ты смеёшься..."

Оформил жалобу: https://bugzilla.mozilla.org/show_bug.cgi?id=1362781 (изменив адреса и вложение).

06-05-2017 22:46:56
Ответили, что ошибка уже исправлена. Страждущим осталось дождаться выхода следующей версии.

Версия 52.1.1 не исправила случайно ошибку?

Пять дней назад разработчики писали, что "в версию 52.1.1, которая выйдет на днях, исправление этой ошибку будет включено".