Заголовки электронных писем [ спецификация ARPA (RFC-822) и MIME (RFC-1341) ] Вместо предисловия. Все началось с заказа на взлом электронной почты одного предприятия. Поиск дополнительной информации посредством поисковиков дал нулевой результат. Единственной зацепкой был фотоальбом в соц. сети "Мой мир", в котором лежали фотографии комплектующих для производства пластиковых окон и дверей. Был зарегестрирован сайт на бесплатном хостинге, на ту же тематику, по электронной почте завязалась "деловая" переписка с предприятием "целью". Изучением заголовков в письмах-ответах установлено, что о почтовых программах на предприятии имели лишь смутное представление. Посему было принято решение ловить на "фейк". В очередной раз отправлено письмо с ссылкой на "прайс", а на самом деле фейк, с последующей переадресацией на настоящий прайс-лист. Финита ля комедия, дело сделано. В ходе выполнения такого заказа я заинтересовался, что же именно означают конкретные поля в заголовках писем. Об этом и статья. В интернете достаточно информации по данной теме, однако у меня возникло желание собрать перечитанное воедино. Надеюсь будет полезным. 1. Вступление. 1.1. Электронная почта в Internet. Электронная почта - один из важнейших информационных ресурсов Internet. Она является самым массовым средством электронных коммуникаций. Любой из пользователей Internet имеет свой почтовый ящик в сети. Если учесть, что через Internet можно принять или послать сообщения еще в два десятка международных компьютерных сетей, некоторые из которых не имеют on-line сервиса вовсе, то становится понятным, что почта предоставляет возможности в некотором смысле даже более широкие, чем просто информационный сервис Internet. Через почту можно получить доступ к информационным ресурсам других сетей. Хорошим примером может служить доступ к архивам сети BITNET 1.2. Структура электронного письма.Электронное письмо состоит из следующих частей: - заголовков SMTP-протокола, полученных сервером. Эти заголовки могут включаться, а могут и не включаться в тело письма в дальнейшем, так что возможна ситуация, когда сервер обладает большей информацией о письме, чем содержится в самом письме. Так, например, поле RCPT TO указывает получателя письма, при этом в самом письме получатель может быть не указан. - самого письма. Непосредственно письмо в свою очередь, состоит из следующих частей, разделённых пустой строкой: - заголовков письма, иногда называемых по аналогии с бумажной почтой конвертом (англ. envelope). - тело письма. В теле письма находится, собственно, текст письма. Формат почтового сообщения был определен в документе RFC-822 ((Standard for ARPA Internet Text Message, опубликован в 1982 г.). Это довольно большой документ объемом в 47 страниц машинописного текста. 2.1. Спецификация ARPA (RFC-822) Минимально необходимыми являются следующие поля "Date:«, »From:«, »Cc:" и/или "To:" Все возможные поля заголовка, согласно стандарту ARPA (RFC-822): Code: Date: 27 Aug 76 0932 From: Ken Davis <[email protected]> Subject: Re: The Syntax in the RFC Sender: KSecy@Other-host Reply-To: [email protected] To: George Jones <[email protected]> cc: Important folks: Tom Softwood <[email protected]>, "Sam Irving"@Other-Host;, Standard Distribution: /main/davis/people/standard@Other-Host Comment: Sam is away on bisiness. In-Reply-To: <[email protected]>, George`s message X-Special-action: This is a sample of user-defined field- names. Message-ID: <4331.629.XYzi-What@Other-Host Описание каждого из полей: Date: — назначение данного заголовка очевидно: он указывает дату и время отправки письма. Если этот заголовок не был создан на компьютере отправителя, то, возможно, его добавит почтовый сервер или какой-нибудь другой компьютер, через который пройдет письмо. Его ни в коем случае нельзя принимать за непреложную истину, и дело даже не в возможности подделки — в мире чудовищно большое количество компьютеров с неверно идущими часами; From: — указывает адрес отправителя; To: — адрес(а) получателя(ей). Поле "To:" не обязано содержать адрес получателя, а также может содержать адреса нескольких получателей; Cc: (Carbon Copy) — адресация копий, этот заголовок является расширением поля «To», он указывает дополнительных получателей письма (получатель «To» видит список всех «Cc»). Различий между заголовками «To» и «Cc», в сущности, нет, если не считать, что некоторые почтовые программы рассматривают их по-разному, генерируя ответ на сообщение. Received: — "штамп" прохождения письма через почтовый сервер. Заголовки "Received:" предоставляют подробную информацию о жизни сообщения и не дадут обмануть получателя сообщения, откуда именно пришло письмо. О заголовке "Received:" можно написать отдельную статью, поэтому на данном этапе более подробно его рассматривать не будем. Message-Id: — уникальный идентификатор письма, присваиваемый каждому сообщению, — чаще всего первым почтовым сервером, который встретится у него на пути, либо же почтовым клиентом. Обычно он имеет форму "[email protected], где «abrakadabra» набор произвольных символов, а вторая часть "domain.ru" — имя машины, присвоившей идентификатор. Иногда, но редко, «abrakadabra» включает в себя имя отправителя. Message-Id используется программами доставки почты во избежание "зацикливания" письма; Bcc: (Blind Carbon Copy) — слепая/скрытая копия (получатели не подозревают о других получателях из поля «Bcc»). Скрытые копии очень популярны среди спамеров, поскольку многие неопытные пользователи оказываются сбитыми с толку, получив письмо, которое, вроде бы, не было им адресовано; Subject: — тема письма (наличие Re: означает ответ; Fwd: — переадресацию). Почтовый стандарт допускает наличие только латинских символов (US-ASCII) в поле «Subject» поэтому, несмотря на то, что многие пользователи заполняют данное поле по-русски, этого делать не рекомендуется. Нормальная ситуация — когда написанная по-русски тема письма при отправке перекодируется почтовой программой отправителя в 7-битную base64 с указанием языковой кодировки, а почтовая программа получателя декодирует тему письма в читаемый вид. Reply-To: — адрес для ответов. Несмотря на то, что этот заголовок имеет множество способов цивилизованного применения, он также используется спамерами для отведения удара от себя. Может быть, какой-нибудь наивный спамер и захочет собирать ответы на свои письма и укажет верный заголовок "Reply-to:", но большинство указывает там либо несуществующий адрес, либо адрес невинной жертвы; In-Reply-To: — показывает, что сообщение относится к типу "ответ на ответ"; Comments: — означает комментарий. Этот заголовок не является стандартным, а потому может содержать любую информацию. Подобные заголовки добавляются некоторыми почтовыми программами для идентификации отправителя, но часто прописывается вручную спамерами, так что относиться к нему следует с осторожностью; Status: — статус письма (новое, прочитанное); Apparently-To: — эти заголовки нетипичны для нормальных сообщений, они обычно являются признаком массовой рассылки. В настоящее время для массовых рассылок используется программное обеспечение, достаточно "умное", чтобы не плодить гигантские списки из этих заголовков; Organization: — абсолютно свободный заголовок, обычно содержащий название организации, через которую отправитель сообщения получает доступ к сети. Отправитель, как правило, контролирует этот заголовок, поэтому там вполне может быть что-то вроде ЗАО "Рога и Копыта"; Priority: — исключительно свободный заголовок, устанавливающий приоритет сообщения. Большинство программ его игнорируют. Errors-To: — указывает адрес для отсылки автоматически генерируемых сообщений об ошибке, таких как "нет такого пользователя". Стандарт RFC-822 — сильно устарел. Он был разработан для обмена текстовыми сообщениями. С момента опубликования стандарта возможности аппаратных средств и телекоммуникаций ушли далеко вперед. На смену ему пришел стандарт MIME (RFC-1341). 2.2. Спецификация MIME (RFC-1341).Стандарт MIME разработан как расширяемая спецификация, в которой подразумевается, что число типов данных будет расти по мере развития форм представления данных. Пример заголовка, согласно стандарту MIME (RFC-1341): Code: From [email protected] Mon Mar 21 02:04:43 2011 Return-path: <[email protected]> Received: from [96.118.147.161] (port=45090 helo=pro) by smtp6.mail.ru with asmtp id 1Q1Rfi-0003lN-00 for [email protected]; Mon, 21 Mar 2011 02:04:30 +0300 Message-ID: <D5C74EF0126641769625669A1D6DA381@pro> Reply-To: =?koi8-r?B?79TL0tnUy8kgTWFpbC5SdQ==?= <[email protected]> From: =?koi8-r?B?79TL0tnUy8kgTWFpbC5SdQ==?= <[email protected]> To: <[email protected]> Subject: =?koi8-r?B?98HNINDSydvMwSDGzNzbLc/Uy9LZ1MvBIQ==?= Date: Mon, 21 Mar 2011 01:08:14 -1200 Organization: =?koi8-r?B?79TL0tnUy8kgTWFpbC5SdQ==?= MIME-Version: 1.0 Content-Type: multipart/related; Type="multipart/alternative"; boundary="----=_NextPart_000_0000_01CBE764.746F7B00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Spam: Not detected X-Mras: Ok Остановимся подробнее на форме и назначении полей, определяемых стандартом. Поле версии MIME (MIME-Version). Поле версии указывается в заголовке почтового сообщения и позволяет определить программе рассылки почты, что сообщение подготовлено в стандарте MIME. Формат поля выглядит как: Code: MIME-Version: 1.0 Поле версии указывается в общем заголовке почтового сообщения и относится ко всему сообщению целиком. Здесь уместно отметить, что в отличие от стандарта RFC822, стандарт MIME позволяет перемешивать поля заголовка сообщения с телом сообщения. Поэтому все поля делятся на два класса: общие поля заголовка, которые записываются в начале почтового сообщения и частные поля заголовка, которые относятся только к отдельным частям составного сообщения и записываются перед ними. Поле типа содержания тела почтового сообщения (Content-Type) Поле типа используется для описания типа данных, которые содержатся в теле почтового сообщения. Это поле сообщает программе чтения почты какого сорта преобразования необходимы для того, чтобы сообщение правильно проинтерпретировать. Эта же информация используется и программой рассылки при кодировании/декодировании почты. Стандарт MIME определяет семь типов данных, которые можно передавать в теле письма: текст (text); смешанный тип (multipart); почтовое сообщение (message); графический образ (image); аудио информация (audio); фильм или видео (video); приложение (application). Общая форма записи поля выглядит как: Code: Content-Type:= type "/" subtype *[";" parameter] type := "application" / "audio" / "image" / "message" / "multipart" / "text" / "video" / x-token x-token := <Два символа "X-", за которыми без пробела следует последовательность любых символов> subtype := token parameter:= attribute "=" value attribute:= token value := token / quoted-string token := 1*<любой символ кроме пробела и управляющего символа, или tspecials> tspecials:= "(" /")" / "<" / ">" / "@" ; Обязательно / "," / ";" / ":" / "\" / <"> ; должны быть, / "/" / "[" / "]" / "?" / "." ; заключены в / "=" ; кавычки. Типы описания нетекстовой информации. Таких типов имеется четыре: * "image" для описания графических образов. Наиболее часто используются файлы форматов GIF и JPEG. * "audio" для описания аудио информации. Для воспроизведения сообщения данного типа требуется специальное оборудование. * "video" для передачи фильмов. Наиболее популярным является формат MPEG. * "application" для передачи данных любого другого формата, обычно используется для передачи двоичных данных для последующего промежуточного преобразования. Так если на машине стоит видео-карта с 512Kb памяти, а графика подготовлена в 256 цветах, то сначала ее следует преобразовать и здесь может помочь тип "application". Основной подтип данного типа - "octet-stream", но существуют "ODA" и "Postscript". В настоящее время полный перевод спецификации MIME на русский язык отсутствует. Ознакомиться с частичным переводом можно по адресу http://webi.ru/webi_files/26_15_f.html 3. Вместо заключения. Чтение заголовков писем может быть полезным - как в случае "нападения", так и в случае "защиты" от атак недоброжелателей. Не пренебрегайте возможностью получить капельку дополнительной информации. ОБращайте внимания на детали При подготовке статьи были использованы материалы: http://hostinfo.ru > заголовки e-mail стандарта RFC-822 http://citforum.ru/ > Организация и администрирование почтовых и файловых серверов Internet http://webi.ru > Неполный русский перевод спецификации RFC 1521 "MIME" А также материалы с персонального сайта Кунегина С.В. Работа с сайта Кунегина С.В. на тему "Электронная почта: функционирование сервиса электронной почты. Основные почтовые стнадарты: Mime, IMAP4, LDAP и др. Обеспечение защиты электронной почты." будет полезна всем начинающим пользователям, которым интересен данный вопрос. Ссылка: Code: http://depositfiles.com/files/0jorimjkl Статья написана для antichat.ru/ При копировании просьба указывать источник.
Автор , спасибо вполне стоящая статья , так же хотел бы почитать о шифровании почты , извиняюсь что повторяюсь за AnGeI
Думаю любой человек слышавший про вики смог бы написать такую статью менее чем за 40 минут. Но все равно спасибо =) Надо было указать что mail.ru раньше содержала xss благодаря передачи даты =)
Написал все, что узнал сам, рыская в интернете по интересующему вопросу. Любые дополнения я думаю поприветствуются, их можно было бы впихнуть в пост AnGeI'a, в виде продолжения статьи
Вообше-то думал тема сисек будет раскрыта, но нет )))) чисто как мануал - не плохо. Только вот кому они нужны - если человек не знает это они из себя представляют? Лично я смотрю RFC только для того, чтоб выяснить хотябы предлизительные кординаты отправителя... есть еще толк от заголовка?
- и какая там защита может быть ? - подмена - это понятно (с IP адресом смотрю уже) - а спам с каким боком относится с RFC ?
