Форматирование электронной почты из почтовых клиентов

Я проводил некоторые исследования/тесты стандартизированного формата электронной почты. В конечном итоге я хочу разработать парсер электронной почты для приложения. Я заметил некоторые различия в формате электронной почты, в основном между почтовыми клиентами (gmail, mac mail и т. д.) и службами почтового маркетинга (Constant Contact, Mail Chimp и т. д.).

Насколько я понимаю формат (RFC2822), \n\n отделяет заголовки от тела. Похоже, что они согласуются с электронными письмами, полученными от служб электронного маркетинга. Однако почтовые клиенты, по-видимому, имеют дополнительный набор заголовков или инструкций для сообщения. См. примеры строк электронной почты ниже. Обратите внимание, что я вытащил эти строки через канал электронной почты. Также обратите внимание, что это только фрагменты заголовка/тела.

Служба электронного маркетинга:

Content-Type: text/html;
    charset="utf-8"
Content-Transfer-Encoding: 8bit


<html>
<head>
    <title>Welcome to Banana Republic. Enjoy 25% off!   </title>
<STYLE type="text/css">
.ReadMsgBody
{ width: 100%;}
.ExternalClass
{width: 100%;}

Здесь вы увидите разрыв строки, отделяющий заголовки от тела. Все хорошо по формату. Теперь посмотрим на почтовый клиент.

Почтовый клиент:

Mime-Version: 1.0 (Mac OS X Mail 7.0 (1816))
X-Mailer: Apple Mail (2.1816)


--Apple-Mail=_28DD752B-7960-488D-994F-DA9408FCA880
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
    charset=windows-1252

Testing Mac Mail. This is the body.

Вы видите, что в этом случае есть дополнительный набор «заголовков», которые кажутся инструкциями о том, как в этом случае Mac Mail отформатировал электронное письмо.

Я думаю, мой вопрос в том, является ли это допустимым форматом? Есть ли какая-то спецификация на него? Существуют ли какие-либо хорошо известные/задокументированные способы проверки и анализа формата этого типа, не зная, какой тип формата принимается?


email format standards rfc2822
person Chris    schedule 17.11.2013    source источник
comment
Вам нужно просмотреть несколько других RFC, таких как RFC2045-2047 (кодировки MIME) и то, как они описывают составные сообщения. Я предполагаю, что ваш второй фрагмент не включает Content-Type: multipart/mixed; border=Apple-Mail=_28DD752B-7960-48 8D-994F-DA9408FCA880, который я ожидаю увидеть как часть этого (где у вас может быть несколько подразделов, каждый из которых соответствует правилам RFC2822). Правильный и полный анализ электронной почты ТРУДНЫЙ. То, что разрешено, разбросано повсюду.   -  person Joe    schedule 18.11.2013
comment
Обратите внимание на эту ссылку, которая ссылается на ряд RFC, связанных с электронной почтой: lsoft.com/manuals/Maestro/2.1/Users/WebHelp/   -  person Joe    schedule 18.11.2013
comment
@Joe - Content-Type: на самом деле multipart/alternative. Не уверен, что это имеет значение, но я просматриваю предоставленные вами ссылки на RFC, чтобы посмотреть, смогу ли я узнать больше.   -  person Chris    schedule 18.11.2013
comment
Как автор нескольких надежных парсеров электронной почты (GMime, MimeKit, Camel и т. д.) - ПОЖАЛУЙСТА, ПОЖАЛУЙСТА, ПОЖАЛУЙСТА, не внедряйте свой собственный парсер/генератор, если вы не стремитесь реализовать все правильно, а не еще один быстрый и грязный парсер, который только в конечном итоге усложняет работу людей, пишущих настоящие синтаксические анализаторы, потому что так много людей пишут синтаксические анализаторы/генераторы, которые так сильно ошибаются.   -  person jstedfast    schedule 19.11.2013

Ответы (1)


arrow_upward
0
arrow_downward

[расширение пунктов, сделанных в комментариях]

это допустимый формат?

Да. Общая структура для почтовых сообщений, более сложная, чем строгий 7-битный текст ASCII, известна как MIME. Он включает в себя спецификацию заголовка «Content-Type» в вашем первом примере, который информирует клиента о том, что все сообщение представляет собой HTML, а не обычный текст. Многие (возможно, большинство) сообщений в наши дни имеют тип «multipart/alternative» на самом внешнем уровне, инкапсулируя 2 (или более!) версии тела сообщения, чаще всего текстовое/простое представление и текстовую/html-версию, которая сама по себе является часто внутри составного/смешанного контейнера, включая встроенные изображения.

Есть ли какая-то спецификация на него?

Да. Основы MIME описаны в RFC 2045-2049, и во многих более поздних RFC и документах по регистрации типов было описано множество расширений и исправлений. MIME также предоставляет основные компоненты для спецификации документов HTTP, поэтому многие из расширений почти не имеют отношения к электронной почте.

Существуют ли какие-либо хорошо известные/задокументированные способы проверки и анализа формата этого типа, не зная, какой тип формата принимается?

Да. Хотя почти вся современная электронная почта имеет формат MIME, формально вы можете обнаружить его, выполнив поиск по заголовку «MIME-Version». Подробности см. в RFC2045. Обратите внимание, что ваш первый пример не показывает этот заголовок, но он должен существовать в полном оригинале, потому что в противном случае показанные вами заголовки были бы бессмысленными.

Это демонстрирует, почему вам, вероятно, следует пересмотреть идею написания собственного парсера почты. То, что вы видели как 2 формата, на самом деле не так, а просто разные приложения структуры формата MIME. MIME значительно старше RFC2822 (который, кстати, сам устарел в соответствии с RFC5322) и имеет множество зрелых и надежных синтаксических анализаторов. Легко написать синтаксический анализатор MIME, который будет работать с большинством писем, немного сложнее написать такой, который будет работать почти со всей допустимой почтой, и сложно написать такой, который будет безопасно обрабатывать реальный мир почты, что часто бывает не так просто. Это совершенно правильно и в некоторых случаях предназначено для злонамеренного взлома наивных парсеров. Воспользуйтесь вырванными волосами десятилетий программистов, которые предшествовали вам: используйте существующий парсер.

person Bill Cole    schedule 31.12.2013