RFC служебные заголовки. Структура почтового сообщения

Сообщение электронной почты обычно состоит из двух частей:

заголовка (header), содержащего служебную информацию, управляющую доставкой и обработкой сообщения;

тела (body), содержащего непосредственно пользовательское сообщение: текст и прикрепленные данные (графические, звуковые файлы и т.п.).

Заголовок сообщения

Почтовое сообщение – это простой текст в формате ASCII. Поэтому заголовок сообщения представляет собой последовательность текстовых строк вида:

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

Message-ID – уникальный идентификатор сообщения. Уникальность значения этого поля гарантируется программным обеспечением узла-отправителя, поэтому оно генерируется автоматически.

Date – поле "Дата". Содержит дату отправки сообщения. Значение поля устанавливается автоматически почтовым клиентом при отправке сообщения.

From – поле "От". Содержит адрес, который отправитель сообщения указывает в качестве исходящего адреса.

Sender – поле "Отправитель". Содержит адрес, с которого было реально отправлено сообщение. Это поле может отсутствовать в заголовке, если поле "From" содержит адрес реального отправителя.

To – поле "Кому". Содержит адрес основного получателя сообщения.

Cc – поле "Копия". Содержит адреса дополнительных получателей сообщения.

Bcc – поле "Скрытая копия". Содержит адреса дополнительных получателей сообщения. Получатели, перечисленные в полях "To" и "Cc", не будут знать, что абоненты из списка "Bcc" получили копию сообщения.

Reply-to – поле "Ответить". Содержит адрес, по которому получатель должен направлять ответ. Это поле является необязательным: в случае его отсутствия ответы направляются по адресу, указанному в поле "From".

Subject – поле "Тема сообщения". В этом поле обычно указывается краткое описание (тема) сообщения.

Тело сообщения

Изначально предполагалось, что почтовые сообщения могут содержать только текст в формате ASCII. А поскольку возможность передачи нетекстовой информации не предусматривалась, то протоколы передачи электронной почты могут некорректно обрабатывать такие сообщения. В связи с этим в свое время был разработан специальный стандарт, определяющий принципы преобразования нетекстовых данных к текстовому виду. Этот стандарт получил название MIME (Multipurpose Internet Mail Extension, многоцелевое расширение почты Интернет).

MIME предполагает, что в теле сообщения могут передаваться следующие виды информации:

текст – простой текст в формате ASCII, а также текст в формате RTF или HTML;

графические изображения – файлы в формате JPEG и GIF;

аудио и видео данные;

данные в форматах различных приложений, например, документы Microsoft Office, а также данные произвольного формата (в том числе, различные исполняемые файлы).

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

Это широко используется при отправке сообщений с вложениями (attachments) – дополнительными "прикрепленными" файлами, которые могут содержать разнородную информацию. Например, к текстовому сообщению можно прикрепить графический файл c фотографией отправителя.

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

Для обеспечения корректной передачи сообщений c нетекстовыми данными в MIME предусмотрены два алгоритма перекодировки, осуществляющие преобразование таких данных к тестовому виду:

алгоритм "Quoted-printable", предназначенный для замены байтов, не являющихся ASCII-символами, на группу из трех байт, представляющих собой только стандартные символы;

алгоритм "Base64", осуществляющий преобразование трех произвольных байт в четыре ASCII-символа.

Для обеспечения корректной интерпретации данных стандартом MIME в заголовок сообщения вводятся дополнительные специальные поля.

Content-type – поле "Тип содержимого". Отвечает за корректное определение типа данных, содержащихся в сообщении заголовка сообщения. Значение поля указывает на конкретный тип данных, или информирует о том, что тело содержит несколько разнотипных блоков.

Content-Transfer-Encoding – поле "Тип кодирования содержимого". Определяет способ преобразования (перекодировки) исходных данных в текстовый вид.

Согласно стандартам обмена электронными сообщениями, письма поддерживают некоторые заголовки, каждый из которых должен быть с новой строки. По умолчанию, в рассыльщике уже прописаны необходимые из них: MIME-Version, Content-Type, From, Reply-To, Subject, To . Записанные в поле заголовков новые RFC email , будут добавлены к имеющимся вшеуказанным.

Учтите, что все почтовые агенты воспринимают эти стандарты по разному. Хоть и указаны в официальных протоколах, они могут быть ингорированы или неверно интерпретированы, по этому перед email рассылкой их стоит тестировать.

Популярные RFC заголовки письма

* - означает например. Cc: (Carbon Copy) * Cc: [email protected]

Этот заголовок является расширением поля "To:", он указывает дополнительных получателей письма. Различий между "To:" и "Cc:" в сущности нет, если не считать, что некоторые почтовые программы рассматривают их по-разному, генерируя ответ на сообщение.

Bcc: (Blind Carbon Copy) * Bcc: [email protected]

Если вы видите этот заголовок в полученном сообщении - значит, что-то не так. Этот заголовок используется так же, как и "Cc:" (см. ниже), но не появляется в списке заголовков. Основная идея этого заголовка заключается в возможности посылать копии письма людям, которые не хотят получать ответы или появляться в заголовках. Слепые копии очень популярны среди спаммеров, поскольку многие неопытные пользователи оказываются сбитыми с толку, получив письмо, которое вроде бы не было им адресовано.

List-Unsubscribe: * List-Unsubscribe: или List-Unsubscribe:

По описанному функционалу, поле должно автоматически отписывать пользователя, если он нажал на кнопку "СПАМ", но зачастую под это поле выводится отдельная кнопака "Отписаться". Заголовок воспринимается не всеми почтовыми программами, т.к. это отличная возможнотсь проверить email адреса на используемость.

Priority: (X-MSMail-Priority: Importance:) * Priority: 1

Заголовок, устанавливающий приоритет сообщения. Иногда указывается, как X-Priority:, X-MSMail-Priority:, Importance:, принимает значения "Higt", "Normal", "Urgent", "Non-urgent" или дляX-Priority "1", "3", "5". Большинство программ его игнорируют. Часто используется спаммерами с целью привлечения внимания к сообщению установив 1.

Comments: * Comments: Люблю книги

Этот заголовок не является стандартным, может содержать любую информацию. Подобные заголовки добавляются некоторыми почтовыми программами (в частности, популярной программой Pegasus) для идентификации отправителя, но часто прописывается и вручную спаммерами, так что относиться к нему следует с осторожностью.

Organization: * Organization: ОАО Костоправ

Абсолютно свободный заголовок, обычно содержащий название организации, через которую отправитель сообщения получает доступ к сети. Отправитель, как правило, контролирует этот заголовок, поэтому там вполне может быть что-то вроде "Королевское Сообщество Постановки Одного Над Другим".

Precedence: * Precedence: bulk

Значения: "bulk", "junk", "list". Указывает принадлежность письма к массовой рассылке. Синонимы X-List:*, X-Mirror:*, X-Auto:*, X-Mailing-List:*.

List-Owner: * List-Owner:

Email адрес организатора массовой рассылки.

X-Mailer: * X-Mailer: ePochta Mailer Disposition-Notification-To: * Disposition-Notification-To: [email protected]

На указанные реквизиты будет отправлено уведомление о прочтении. Зачастую игнорируется почтовиками, в целях борьбы со спамом. Синонимы: X-Confirm-Reading-To:, Return-Receipt-To:

X-*** * X-List:, X-Mailer:, X-...

Как глосят стандарты RFC, заголовки начинающиеся на X - это собственные заголовки отдельных почтовых программ, носящие информативный характер. Но некоторые принимаются повсеместно, например X-Mailer. Ничего, кроме дополнительной информации в коде письма...

Вышепредоставленная информация, носит информативный характер. Это не означает, что указание какого либо заголовка обязательно выполнится каждой почтовой программой. Дополнительную информацию о заголовках можно получить по

Однако мало кто обращает внимание на заголовки сообщений. Некоторые из них пользователи видят при чтении электронной почты постоянно, это строки, начинающихся с To:, From: и Subject:. Однако заголовки содержат не только дружественные подсказки почтовой программы, но и другую, весьма содержательную информацию. Из заголовков можно узнать название и номер версии вашего почтового клиента, а также тип операционной системы, наименование и номер версии почтового сервера, внутренние IP-адреса и тип используемого в вашей организации брандмауэра (если он используется).

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

СТАНДАРТЫ

Заголовки электронной почты, как и все компоненты Internet, должны соответствовать стандартам, в данном случае - стандарту RFC 822. Отдельный стандарт, RFC 821, определяет формат «конверта» и описывает протоколы передачи почтовых сообщений, но это не относится к теме данной статьи. Спецификация RFC 822 была предложена для замены более раннего стандарта (RFC 733), с целью обеспечения передачи сообщений электронной почты между различными сетями. Обсуждаемые в данной статье заголовки необходимы для пересылки любого почтового сообщения через Internet или же между двумя внутренними серверами электронной почты, если они используют для этого стандартные протоколы TCP/IP. Эти понятия пояснены на Рисунке 1.

Возможно, ваша почтовая программа позволяет просматривать заголовки сообщений. Например, в случае Outlook, выбрав в меню View подменю Show Fields, вы увидите диалоговое окно с наименованиями некоторых из возможных полей, которые могут появляться в почтовых сообщениях.

Каждый заголовок начинается с наименования поля, за которым всегда следует двоеточие и пробел, например To: или Received:. Длинные строки заголовков «свернуты», или представлены несколькими строками, причем каждая дополнительная строка начинается как минимум с одного пробела. На Рисунке 1 первым полем заголовка является Received:, которое в действительности распространяется на три строки, за ним следует другое трехстрочное поле Received:.

Некоторые из названий полей, такие, как Date:, To:, Subject: и From:, сами говорят о своем назначении. Например, после имени поля From: расположен обратный адрес, а после To: - адрес получателя. Протокол SMTP (RFC 821) не требует, чтобы помещенный в поле From: адрес точно представлял отправителя. SMTP не располагает реальными средствами проверки того, что отправитель использует свой собственный адрес, хотя большинство почтовых серверов проверяет, как минимум, факт существования домена отправителя. Отсутствие контроля облегчает фальсификацию адресов отправителей сообщений, характерную, в частности, для спама.

ПОЛУЧАТЕЛИ

С точки зрения получения реальной информации об отправителе почтового сообщения заголовки Received: представляют существенно больший интерес, чем заголовки From:, которые легко фальсифицируются. Вообще говоря, любая строка заголовка может быть в какой-то мере подделана, так как заголовки представляют собой лишь текстовые данные, и только те из них, которые формируются вызывающими доверие серверами, могут считаться достоверными. Заголовки Received: добавляются каждым почтовым сервером, ретранслирующим данное сообщение, причем самый последний в цепочке почтовый сервер находится на первой позиции, а первый сервер, ретранслировавший сообщение, - на последней. На Рисунке 1 первый заголовок Received: показывает, что сервер bear.spirit.com получил сообщение для адресата [email protected] от узла 0nus.l0pht.com.

Первый заголовок предоставляет и другую интересную информацию. Данные в скобках, например (0nus.l0pht. com ), воспринимаются в качестве комментариев совместимыми почтовыми серверами. В данном случае программа sendmail на узле bear.spirit. com проверила, что система отправителя на самом деле имеет имя 0nus.l0pht.com и IP-адрес 199.201.145.3. Просмотр параметров соединения TCP/IP дал sendmail возможность определить IP-адрес, а затем поиск в системе DNS позволил узнать доменное имя сервера.

Второй заголовок Received: более интересен. Заметьте, что сообщение получено от , т. е. указан абсолютный IP-адрес системы 0nus, причем он одновременно показан как 199.201.145.3. В соответствии со стандартом RFC 1918 адреса IP, начинающиеся с 172.16, зарезервированы для частных сетей, поэтому они не предназначены для передачи через Internet и могут повторяться. В нашем примере заголовок Received: говорит о том, что 0nus функционирует в качестве брандмауэра домена l0pht (или его части) и осуществляет преобразование сетевых адресов (Network Address Translation, NAT). Вместе с тем, этот заголовок Received: информирует о том, что в домене 0nus работает Postfix - новый почтовый сервер, который компания Wietse Venema разработала для обеспечения максимально возможного уровня безопасности.

В примере на Рисунке 1 сообщение содержит только два заголовка Received:. Иногда их бывает намного больше, и эти заголовки могут показать другие внутренние сетевые адреса и имена почтовых серверов, а также внутренние имена серверов. Важность строк Received: проявляется также в том, что они позволяют выявить случаи зацикливания, когда один почтовый сервер пересылает сообщение другому, а тот в свою очередь снова отправляет его обратно, создавая цикл. С другой стороны, строки поля Received: содержат также множество данных, которые могут заинтересовать внешнего злоумышленника.

К настоящему моменту по информации заголовков Received: мы определили два почтовых сервера: sendmail и Postfix. Другие почтовые серверы Unix, а также Microsoft Exchange и Lotus Notes тоже оставляют свои отметки в заголовках Received:.

С определенной долей вероятности 0nus.l0pht.com представляет собой брандмауэр домена l0pht. В некоторых случаях можно не только догадываться, но и точно определить факт присутствия брандмауэра. Иногда он будет называться «firewall», «eagle», «fw1» или каким-либо другим легко распознаваемым именем, что найдет отражение в заголовках Received:. Некоторые брандмауэры, например компании Interlock, явно заявляют о своем присутствии, добавляя комментарий к строке Received:. Брандмауэр другого производителя помещает в это поле гораздо менее информативную строку, указывая, что «частная информация была удалена». Тем не менее, так как только этот производитель использует данный специфический комментарий, присутствие его брандмауэра становится почти таким же очевидным, как и брандмауэра Interlock.

ИСЧЕЗАЮЩИЕ ЗАГОЛОВКИ

Заголовки Received: предназначены для анализа проблем доставки электронной почты. Удаление этих заголовков не считается в Сети признаком хорошего тона, но некоторыми брандмауэрами они все же удаляются по желанию администратора. Я считаю удаление таких заголовков в сообщениях, покидающих вашу организацию, обоснованным действием: если вы несете ответственность за проблемы с электронной почтой в пределах вашей организации, то у вас вряд ли появится желание предоставить посторонним лицам возможность анализировать структуру вашей почтовой системы (и сети). Пока еще не все брандмауэры позволяют это сделать. (Как правило, только межсетевые экраны со шлюзами приложений настолько «умны», чтобы корректно осуществлять подобные операции.)

Спецификация RFC 822 требует наличия в сообщении заголовков Received:, поэтому их удаление может расцениваться как противоречие стандарту Internet. В частной переписке по электронной почте с персоналом поддержки Web-узла sendmail.org консультант порекомендовал такой метод избирательного удаления заголовков Received: - модификацию sendmail и создание файла конфигурации, где содержатся удаляемые адреса серверов. В то же время служба поддержки sendmail признала подобную модификацию противоречащей духу стандарта RFC и порекомендовала скрывать частные данные в заголовках посредством их замены на хэшированные записи.

ЭТО ЕЩЕ НЕ ВСЕ

Некоторые из известных атак оказались возможны благодаря использованию ошибок синтаксического разбора заголовков. Совсем недавно Microsoft выпустила «заплатку» для модуля inetcomm.dll, к которому программы Outlook и Outlook Express обращаются для анализа, помимо прочего, заголовок Date:. При переполнении поля Date: в этих почтовых программах наблюдались сбои или даже выполнение произвольного кода (если переданные данные использовали переполнение буфера).

Как можно узнать, с какой программой работает данный пользователь: Outlook, Outlook Express или какой-либо другой? Посмотрите на заголовок x-mailer:. В случае, изображенном на Рисунке 1, отправитель Джолли пользовался почтовым клиентом Claris Emailer, что говорит также о том, что он работает на компьютере Macintosh (пакет прикладных программ Claris доступен только для Macintosh).

Почта Internet, как и большая часть его элементов, не разрабатывалась для отражения внутренних атак. Многие годы Internet был средством общения энтузиастов, объединяя компьютеры на основе общих протоколов, определенных стандартами RFC. Безопасность же и исходная цель Internet - обеспечение межсоединения - находятся в противоречии друг с другом.

Средства шифрования и цифровой подписи для электронной почты, такие, как, например, PGP (Pretty Good Privacy), не решают проблемы, так как они только обеспечивают конфиденциальность почтовых сообщений и аутентифицируют отправителя. Для предотвращения злоупотреблений, с которыми мы сталкиваемся сегодня, стандарты почтовых сообщений должны быть изменены радикально. Но уже сейчас заголовки исходящей электронной корреспонденции вашей организации можно фильтровать, удаляя из них внутреннюю информацию, которой может воспользоваться внешний злоумышленник.

Рик Фэрроу - независимый консультант по вопросам безопасности. С ним можно связаться по адресу: [email protected] .

Ресурсы Internet

Стандарт Internet на заголовки почтовых сообщений опубликован по адресу: http://www.faqs.org/rfcs/rfc822.html .

Почтовый сервер Postfix компании Wietse Venema расположен на странице http://www.porcupine.org/postfixmirror/start.html .

Рекомендации Microsoft относительно ошибок в модуле inetcomm.dll для разбора ряда заголовков почтового сообщения можно найти по адресу: http://www.microsoft.com/technet/security/bulletin/ms00-043.asp .

Полезные советы по использованию sendmail для маскировки (перезапись заголовков сообщений так, чтобы все они содержали адрес домена, а не адреса внутренних систем вашего домена) можно найти по адресу:

Технические заголовки

Согласно стандартам обмена электронными сообщениями, письма поддерживают некоторые заголовки, каждый из которых должен быть с новой строки. По умолчанию уже прописаны необходимые из них: MIME-Version, Content-Type, From, Reply-To, Subject, To. Записанные в поле заголовков новые, будут добавлены к имеющимся вшеуказанным.

Все почтовые агенты воспринимают эти стандарты по разному. Хотя эти заголовки email и указаны в официальных протоколах RFC, они могут быть ингорированы или неверно интерпретированы, по этому перед email рассылкой их стоит тестировать на себе.

Просмотр заголовков сообщений Интернета

В Outlook для Office 365, 2016, 2013 или 2010 на Компьютере

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

Выберите файл > свойства.

Сведения заголовка будут отображены в поле Заголовки Интернета .
Совет : выделять сведения в это поле, нажмите клавиши Ctrl + C , чтобы скопировать и вставьте в Блокнот или Word, чтобы увидеть весь верхний одновременно.

Содержимое заголовков сообщений электронной почты

Рассмотрим переписку по электронной почте между двумя пользователями: Сергеем Зайцевым и Ольгой Зуевой. Адрес электронной почты Сергея - [email protected] , адрес Ольги - [email protected] . Ольга использует Microsoft Office Outlook 2007. Заголовок Интернета из письма Ольги Сергею выглядит следующим образом:

Microsoft Mail Internet Headers Version 2.0Received: from mail.litwareinc.com () by mail.proseware.com with Microsoft SMTPSVC(6.0.3790.0);Wed, 12 Dec 2007 13:39:22 -0800Received: from mail ( RDNS failed) by mail.litware.com with Microsoft SMTPSVC(6.0.3790.0);Wed, 12 Dec 2007 13:38:49 -0800From: "Kelly J. Weadock" To: Cc: Subject: Review of staff assignmentsDate: Wed, 12 Dec 2007 13:38:31 -0800MIME-Version: 1.0Content-Type: multipart/mixed;X-Mailer: Microsoft Office Outlook, Build 12.0.4210X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165Thread-Index: AcON3CInEwkfLOQsQGeK8VCv3M+ipA==Return-Path: [email protected]: X-OriginalArrivalTime: 12 Dec 2007 21:38:50.0145 (UTC)

Когда Ольга отправляет сообщение на адрес [email protected] , она создает его на своем компьютере, который определяется как (i101-177.nv.litwareinc.com ). Текст сообщения передается с ее компьютера на сервер электронной почты mail.litwareinc.com. Больше Ольга не увидит своего сообщения - дальнейшая обработка выполняется почтовым серверами без ее участия. Когда почтовый сервер Ольги получит сообщение, отправленное на адрес [email protected] , он свяжется с почтовым сервером компании Proseware и доставит на него сообщение. Оно будет храниться на сервере proseware.com до тех пор, пока Сергей не проверит свою рабочую почту.

Интерпретация заголовки сообщений электронной почты

Ниже приведено описание стандартных полей заголовков сообщений электронной почты.

Microsoft Mail Internet Headers Version 2.0

Этот заголовок добавляется Outlook.

Received: from mail.litwareinc.com () by mail.proseware.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Dec 2017 13:39:22 -0800

Эта информация указано, что произошло передачи сообщения на вторник, 12 декабря 2017 г., в 13:39:22 (1: США) стандартному тихоокеанскому времени (это на 8 часов позже, чем по Гринвичу (по Гринвичу); таким образом «– 0800»).

Received: from mail ( RDNS failed) by mail.litware.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Dec 2017 13:38:49 -0800

Эта передача произошла в Вторник, 12 декабря 2017 г., в 13:38:49 (1: по) стандартному тихоокеанскому времени (это на 8 часов позже чем время по Гринвичу (UTC); таким образом «– 0800»).

From: "Kelly J. Weadock"

Сообщение отправила Ольга Зуева с адреса электронной почты [email protected] .

To:

Получатель сообщения.

Cc:

Получатели копий сообщения.

Примечание: Получатели скрытых копий (СК) в заголовке не указываются.

Subject: Review of staff assignments

Тема сообщения электронной почты.

Дата и время отправки сообщения электронной почты по часам компьютера отправителя.

MIME-Version: 1.0

Версия протокола MIME, использованная отправителем.

Content-Type: multipart/mixed;

Дополнительный заголовок MIME. Он предназначен для MIME-совместимых почтовых программ и указывает, какой тип содержимого следует ожидать в сообщении.

X-Mailer: Microsoft Office Outlook, Build 12.0.4210

Сообщение отправлено с использованием Microsoft Office Outlook, версия сборки 12.0.4210.

X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165

Почтовая программа (программное обеспечение MIME OLE), использованная отправителем.

Thread-Index: AcON3CInEwkfLOQsQGeK8VCv3M+ipA==

Этот заголовок используется для объединения нескольких сообщений в один поток. Например, в Microsoft Outlook эти сведения могут быть использованы в представлении беседы для поиска сообщений в рамках одного потока разговора.

Return-Path: [email protected]

Адрес отправителя сообщения.

Message-ID:

Номер, присвоенный сообщению сервером mail.litware.com в целях идентификации. Этот идентификатор всегда будет сопровождать сообщение.

Метка времени, которая добавляется в сообщение при его первом прохождении через сервер Microsoft Exchange.