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

Я занимаюсь некоторыми исследованиями/испытаниями в стандартизованном формате электронной почты. В конечном счете, я ищу разработку парсера для электронной почты для приложения. Я замечаю некоторые различия в формате электронной почты, в основном между почтовыми клиентами (gmail, mac mail и т. Д.) И службами электронной почты (постоянный контакт, почтовый шимпанзе и т. Д.).Форматирование электронной почты от почтовых клиентов

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

Email Marketing Service:

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%;}

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

Email клиент:

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 отформатировал электронную почту.

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

источник

2013-11-17 Chris

Вам нужно посмотреть несколько других RFC, таких как RFC2045-2047 (MIME encodings) и как они описывают многостраничные сообщения. Я предполагаю, что ваш второй фрагмент не включает Content-Type: multipart/mixed; border = Apple-Mail = _28DD752B-7960-48 8D-994F-DA9408FCA880, который я ожидаю увидеть как часть этого (где вы можете иметь несколько подразделов, каждый из которых соответствует правилам RFC2822). Правильный и полный анализ по электронной почте является HARD. То, что разрешено, распространяется повсюду. – Joe

Обратите внимание на эту ссылку, которая ссылается на ряд связанных с электронной почтой RFC: http://www.lsoft.com/manuals/Maestro/2.1/Users/WebHelp/Appendix_D_Email_Related_RFCs.htm – Joe

@Joe - Content-Type: multipart/alternative на самом деле , Не уверен, что это имеет значение, но я просматриваю ссылки RFC, которые вы указали, чтобы узнать, могу ли я узнать больше. – Chris

[простирающийся очки, сделанные в комментарии]

является этот допустимый формат?

Да. Общая структура почтовых сообщений более сложная, чем строгий 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, который будет работать для большей части почты, немного сложнее написать тот, который будет работать практически для всей действующей почты, и разумно-сложный, чтобы написать тот, который будет безопасно обрабатывать реальный мир почты, который часто не является " t точно верна и в некоторых случаях предназначена для разрыва наивных парсеров вредоносными способами. Воспользуйтесь вырванными волосами десятилетия кодеров, которые вам предшествовали: используйте существующий парсер.

источник

2013-12-31 03:03:01

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

ответ

Смежные вопросы