Тема закрыта
Страницы: 1
Добрый день.
В версии 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'ом не читается
Отредактировано Dzirt (04-05-2017 20:50:44)
Отсутствует
yup пишетНе помню, может ли по стандарту тело письма быть бинарным, или оно обязано быть текстовым.
Бинарным оно естественно быть не может, только текст. По стандарту.
Письмо конечно несколько необычное, но в целом все соответствует, в том числе судя по заголовкам:
...
X-Mailer: SAP NetWeaver 740
Content-Type: application/pdf;
Под текстовым я, естественно, имел в виду "Content-Type: text/...". А под бинарным - всё прочее, что приходится заворачивать в Base64/UUE, и что почтовая программа не обязана уметь показывать самостоятельно.
PPPS: Thunderbird 52.1.0 не раскодирует содержимое письма, а так вот как есть и сохраняет...
Вот и я об этом. Вопрос только: это какая-то ошибка в данной версии выползла, или более строгое соответствие стандартам так проявляется?
Все письма с вложениями и без текста, которые у меня хранятся, оформлены как "Content-Type: multipart" с пустой секцией тела письма и следующей за ней секцией вложения.
Отредактировано yup (04-05-2017 21:53:44)
Отсутствует
Под текстовым я, естественно, имел в виду "Content-Type: text/..."
Естественно нет. Параметра Content-type вообще может не быть, да и не было раньше. Или наоборот - может быть несколько в multipart сообщениях. А текст - это именно текст, байты с кодами 0x20-0x7f (изначально, в более поздних реализациях расширили до 0x20-0xff), плюс естественно управляющие символы 0x0d, 0x0a - они очень важны, например пустая строка (два подряд разделителя) отделяют заголовки от тела письма. Вроде бы (раньше по крайней мере точно) было ограничение на длину одной строки, как с этим сейчас - не в курсе
это какая-то ошибка в данной версии выползла
Конечно же ошибка. Тамошние программисты последнее время только новые ошибки добавляют и ломают то, что раньше работало. Ничего нового или исправленного уже нет много-много версий, разве что редактор html-сообщений несколько улучшился. По сравнению с версией 3.0...
Отредактировано Dzirt (05-05-2017 07:56:20)
Отсутствует
Параметра Content-type вообще может не быть
В явном виде в заголовке может и не быть. Но в результате всего лишь код программ будет обрабатывать такую секцию, используя для 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.
да и не было раньше.
"Боже, как давно это было."
Или наоборот - может быть несколько в multipart сообщениях.
Но мы же говорим не о сообщении в целом, а о его секциях. В заголовке секции их тоже, конечно, может встретиться несколько, но действующим-то будет только один.
А текст - это именно текст, байты с кодами 0x20-0x7f (изначально, в более поздних реализациях расширили до 0x20-0xff), плюс естественно управляющие символы 0x0d, 0x0a
Нам явно нужно договориться. Понятно, что всё, завёрнутое в Base64/UUE/BinHex/QP и прочее подобное - это текст. Но этот текст - всего лишь транспортное представление некоего оригинала. А значение для нас (в контексте обнаруженной проблемы) имеет оригинал, а не транспорт.
Отсутствует
Нам явно нужно договориться. Понятно, что всё, завёрнутое в Base64/UUE/BinHex/QP и прочее подобное - это текст. Но этот текст - всего лишь транспортное представление некоего оригинала. А значение для нас (в контексте обнаруженной проблемы) имеет оригинал, а не транспорт.
Договариваемся - если мы говорим с точки зрения стандарта на формат почтового отправления, то это с ваших слов "транспортное представление" (мля... Транспортом всегда было явно другое, ну ладно, остановимся на "представлении"). Никакого "оригинала" с точки зрения стандарта нет, это только с точки зрения конечного пользователя может быть, так что не нужно настолько подменять понятия. Другой пример - картинка в формате .svg. С точки зрения "транспорта" файл текстовый, но для человека это "картинка"
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.
Это откуда? В стандарте RFC-822 даже слова Content-type нет, раздел 5.2 это "Date and time specification. Semantics". Слова "mime" тоже нет.
Отсутствует
Никакого "оригинала" с точки зрения стандарта нет, это только с точки зрения конечного пользователя может быть
Во-первых - да, согласен. Но мы же и рассматриваем всё это дело с точки зрения пользователя, ведь проблему в данном случае видит он, а не программа.
Во-вторых - нет, не согласен, потому как существует не только стандарт на формат сообщения электронной почты, но и стандарт, описывающий метод преобразования бинарных файлов в форму, пригодную для внедрения в это сообщение.
Другой пример - картинка в формате .svg. С точки зрения "транспорта" файл текстовый, но для человека это "картинка"
И что? А ничего. Из "текстовости" .svg вытекает только то, что для его внедрения в письмо не требуется прибегать к Base64. Однако это даёт ему "Content-Transfer-Encoding: 7bit", но никак не "Content-type: text/plain".
HTML, вон, тоже текстовый "с точки зрения транспорта", однако и он не "text/plain", и поэтому уметь показывать его почтовый клиент не обязан.
Хотя да, должен признать, что выше по странице моя делёжка на "текстовые/бинарные" была неаккуратной.
Это откуда? В стандарте RFC-822 даже слова Content-type нет
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.
(мля... Транспортом всегда было явно другое, ну ладно, остановимся на "представлении")
Увы, но в мире, в котором мы в настоящее время вынуждены жить, сплошь и рядом одно и то же в разных местах называется разными словами, а одни и те же слова в разных местах означают разное.
В UTF-8, кстати, аббревиатура "UTF" расшифровывается как "Unicode Transport Format".
Отредактировано yup (06-05-2017 03:28:57)
Отсутствует
В UTF-8, кстати, аббревиатура "UTF" расшифровывается как "Unicode Transport Format"
Ээээ... Да, really? А мне почему-то всегда казалось, что "Unicode Transformation Format". Ну то такое... Почти одно и то же, да
Отсутствует
Да, really?
Пятачок: "Да, Винни, ты смеёшься..."
Кто поможет правильно оформить баг в трекере?
Оформил жалобу: https://bugzilla.mozilla.org/show_bug.cgi?id=1362781 (изменив адреса и вложение).
Добавлено 06-05-2017 22:46:56
Ответили, что ошибка уже исправлена. Страждущим осталось дождаться выхода следующей версии.
Отредактировано yup (06-05-2017 22:46:56)
Отсутствует
Тема закрыта
Страницы: 1