В самом общем случае схема обмена электронными сообщениями (электронная почта, e-mail) выглядит следующим образом
Отправитель почтового сообщения подключается к своему почтовому серверу с использованием протокола прикладного уровня SMTP (Simple Mail Transfer Protocol) и передает ему данные, необходимые для доставки отправления конечному получателю, и собственно, само послание. После чего сеанс обмена завершается. На следующем этапе доставки почты (Mail Delivery), почтовый сервер отправителя, используя данные электронного адреса получателя, находит его почтовый сервер, подобным же образом подключается к нему и передает письмо, которое помещается в почтовый ящик получателя. Получателю остается только подключиться к серверу с использованием протокола прикладного уровня POP3 (Post Office Protocol ver 3) и "забрать" из почтового ящика полученное послание.
Протокол SMTP был разработан еще в начале 80-х годов прошлого века (основные спецификации - RFC 821 RFC 822), однако, с некоторыми изменениями и дополнениями , широко используется до сих пор и, очевидно, будет использоваться в ближайшие несколько лет как основной протокол передачи электронных сообщений.
При стандартной настройке, сервер ожидает входящие соединения на TCP порт 25 (слушает TCP порт 25). Клиентская почтовая программа выполняет обычное TCP соединение на данный порт, после чего, почтовый сервер передает свое приветствие:
220 fcgp03.nicmail.ru ESMTP CommuniGate Pro 5.2.3.
Информационные и управляющие сообщения, выдаваемые сервером, состоят из номера (числового идентификатора), в данном случае - 220 (сервер готов к работе) и поясняющего текста. Данные, передаваемые клиентом, не имеют номера и передаются в виде набора отображаемых символов (обычного текста).
Для начала сессии, в соответствии со спецификацией протокола SMTP клиент должен сообщить свое локальное имя хоста с использованием директивы HELO. Вместо HELO, может быть использована (и в рассматриваемом примере, используется) директива EHLO, в ответ на которую сервер, дополнительно, передает список поддерживаемых им команд
EHLO MyComp.Mydomain
В качестве аргумента директивы EHLO передается имя компьютера.
В ответе сервера (идентификатор 250 - OK, выполнено успешно) будут перечислены поддерживаемые им команды протокола SMTP:
250-fcgp03.nicmail.ru domain name should be qualified MyComp.Mydomain
250-SIZE 31457280
250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 MSN
250-ETRN
250-TURN
250-ATRN
250-8BITMIME
250-HELP
250 EHLO
Список команд SMTP зависит от конкретных настроек сервера. В связи с проблемой СПАМа, подавляющее большинство почтовых серверов настраивается только на работу с авторизацией пользователя. Поэтому почтовая клиентская программа выдает директиву AUTH, указывающую какую процедуру проверки подлинности пользователя она будет использовать:
AUTH LOGIN
В данном случае будет использоваться проверка по имени и паролю. После чего сервер выдает сообщение c номером 334 (выполнение процедуры аутентификации):
334 VXNlcm5hbWU6
В рассматриваемом примере SMTP-сессии, на данном этапе обмен данными между клиентом и сервером выполняется также в текстовом виде, но в кодировке Base64. Данная кодировка широко используется в приложениях электронной почты для кодирования бинарных данных - программ, фото, видео и т.п. Весь диапазон кодируемых элементов данных может быть представлен набором символов английского алфавита, цифрами и некоторыми знаками. Для перекодировки данных, проще всего, воспользоваться онлайн-перекодировщиком base64.ru. Для перекодировки копируем строку Base64 в верхнее окно, и в нижнем получаем текст Username:
Строка символов VXNlcm5hbWU6 - это Username: в кодировке ASCII, т.е. запрос имени пользователя. Клиентская программа также отправляет его в кодировке Base64:
QmlsbEdhdGVzQG1pY3Jvc29mdC5jb20=
Подобным же образом, определяется, что строка
334 UGFzc3dvcmQ6
означает запрос пароля - Password:
На что клиентская программа передает пароль, также в кодировке Base64:
YXNkYXRh
Если пароль принят, сервер отвечает сообщением с номером 235:
235 BillGates@microsoft.com authenticated
Если проверка достоверности пользователя почтовым сервером не выполнена , он ответит кодом ошибки из набора сообщений с номерами 4ХХ, 5ХХ
Далее клиентская программа сообщает серверу адрес отправителя:
MAIL FROM: spam@spamhost.ru
Одним из серьезных недостатков протокола SMTP является его слабая защита от поддельных почтовых отправлений. Как в директиве HELO можно указать любой адрес хоста, так и в директиве MAIL можно указать любой адрес отправителя. На соответствующий формату адрес, сервер выдаст сообщение с номером 250 (OK, все хорошо):
250 spam@spamhost.ru sender accepted
Получив от сервера подтверждение, что адрес принят, клиентская программа передает адрес получателя с помощью директивы RCPT TO:
RCPT TO: test@rambler.ru
Если адрес задан верно, сервер ответит сообщением 250:
250 test@rambler.ru will relay mail for an authenticated user
Далее инициируется процедура передачи данных - клиентская почтовая программа передает команду DATA,
DATA
На что сервер отвечает сообщением с номером 354 ("начать ввод текста письма")
354 Enter mail, end with "." on a line by itself
В самом простейшем случае, письмо может быть набором вводимых с клавиатуры, отображаемых символов ASCII, например
Hello, World!!!
Признаком конца сообщения является отдельная строка, содержащая символ "точка".
.
На что, сервер выдает сообщение о принятии к доставке введенного сообщения:
250 message accepted for delivery
Клиент завершает сессию:
QUIT
Сервер сообщает о закрытии соединения:
221 fcgp03.nicmail.ru CommuniGate Pro SMTP closing connection
На начальном этапе использования протокола SMTP именно такой формат почтовых сообщений и использовался, однако со временем, появилась необходимость создавать красивое оформление отправлений, прикреплять файлы произвольного формата, использовать национальные алфавиты и т.п. Таким образом, в дополнение к документу RFC 821 был разработан документ RFC 822, стандартизирующий основное содержание сообщений электронной почты и документы RFC 2045 и RFC 2046, описывающие формат расширений MIME (Multipurpose Internet Mail Extensions - Многоцелевое расширение электронной почты), предназначенный для обработки составных и нестандартных сообщений.
В соответствии с современными стандартами, сообщение электронной почты состоит из 2-х частей - заголовка и тела . Заголовок письма формируется почтовым программным обеспечением и состоит из нескольких строк в кодировке ASCII. Заголовок содержит служебную информацию, необходимую для доставки и обработки электронного послания. Каждое поле заголовка состоит из названия, символа двоеточия, и данных поля. Некоторые поля заголовка имеют фиксированную структуру, например, поле From:(адрес отправителя), а некоторые - произвольную, как например, поле Subject: (тема письма). Основные поля сообщения:
From: - адрес отправителя
To: - адрес получателя
Date: - дата отправки
Cc: - копия сообщения отправляется на указанный адрес
Bc - скрытая копия
Subject: - тема сообщения
Message-ID: - идентификатор сообщения, присвоенный почтовым ПО.
Reply-To: - адрес для ответа на сообщение.
Priority - Приоритет (важность) сообщения
X-Mailer: - почтовая программа, с помощью которой отправлено сообщение.
Received: - поле с адресами и временем обработки сообщения промежуточными серверами при доставке сообщения адресату.
Минимальный заголовок сообщения должен содержать поля From:, To: (или Cc:) и Date: . При доставке сообщения конечному адресату, к первоначальному заголовку письма могут быть добавлены поля, сформированные промежуточными почтовыми серверами. Так, например, при отправке сообщения от пользователя user1@mail.ru пользователю user1@rambler.ru , письмо отправляется клиентским почтовым программным обеспечением на почтовый сервер, обслуживающий домен mail.ru, и затем пересылается им почтовому серверу, обслуживающему домен rambler.ru, откуда оно будет принято пользователем почтового ящика user1@rambler.ru. Пересылка может состоять из нескольких шагов и сопровождается добавлением полей промежуточных серверов в заголовок сообщения.
О формате содержимого письма сообщают поля :
MIME-Version: - версия расширения MIME. Означает, что в данном сообщении используется расширение MIME и указывается его версия.
Content-Type: - тип содержимого. Определяет содержание сообщения и алгоритм его обработки почтовым программным обеспечением (почтовым ПО). Так, например,
Content-Type:message/RFC-822 - указывает, что далее следует сообщение в формате RFC-822, т.е. простейшее текстовое сообщение без каких-либо расширений в кодировке ASCII.
Content-Type: text/plain; charset="windows-1251" - сообщение из последовательности символов в кодировке, определяемой значением параметра charset: (в данном случае, в кодировке Windows с кодовой страницей 1251)
Content-Type: text/html - используется текст, размеченный с использованием тегов языка HTML.
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_008D_01CC0FEF.CCB47280" - сообщение состоит из нескольких частей различного содержания. Параметр boundary задает строку - разделитель между отдельными частями.
Таким образом, поле Content-Type: может определять тип содержимого (audio, video, image), которое должно быть перекодировано при обработке почтового сообщения. Тип кодировки указывается полем Content-Transfer-Encoding:. Если указаны типы 7bit, 8bit или binary, то перекодировка не используется. Тип Base64 указывает на то, что кодирование данных выполнено с использованием упоминаемой выше кодировки Base64. Довольно часто встречается тип quoted-printable, предназначенный, как и Base64, для передачи символов, не входящих в состав отображаемой части ASCII (английского алфавита, цифр и некоторых знаков). Каждый символ преобразуется в последовательность из знака равенства = и двух символов задающих шестнадцатеричное значение кода преобразуемого символа. Так, например, заглавная русская буква Я, которой соответствует шестнадцатеричное значение 0xDF в старшей части таблицы символов , будет представлена как =DF, восклицательный знак - =21 и т.п. Правила кодирования данных описаны в документе RFC-1341
Наверно, нет ни одного пользователя электронной почты, который не получал бы электронные послания от различного толка мошенников, маскирующихся под организаторов всевозможных (беспроигрышных для них) лотерей, администрацию сайтов, сервисы электронных платежных систем и т.п. С помощью поддельных писем были взломаны многие страницы пользователей социальных сетей, учетные записи пользователей электронной почты, форумов и т.д. И наоборот, действительные письма, вызвавшие необоснованные подозрения были проигнорированы и отправлены в корзину.
Достоверность электронного послания довольно просто определить, используя обычную логику и ту информацию, которую можно извлечь из полей заголовка письма.
Принятое письмо отображается почтовым клиентским программным обеспечением в виде, удобном для просмотра без лишней детализации, однако, при необходимости, можно изменить представление данных сообщения, и получить возможность просмотреть поля заголовка. Для почтового клиента Microsoft Outlook Express, например, нужно выбрать конкретное письмо, вызвать контекстное меню правой кнопкой мышки и выбрать пункт Свойства или нажать комбинацию клавиш Alt+ENTER. Откроется окно свойств сообщения с вкладками "Общие" и "Подробно"
При выборе режима представления "Подробно" в окне свойств сообщения будут отображаться заголовки письма и, кроме того, появится возможность его просмотра в том виде, в каком оно было принято от почтового сервера при нажатии на кнопку Исходное Сообщение
Исходный вид представляет собой заголовок письма, пустую строку, и тело письма.
В других почтовых программах или в веб-интерфейсе почтовых служб также имеется возможность просмотра заголовка, так, например, при чтении письма через веб-интерфейс почтовой службы mail.ru, заголовок можно просмотреть, нажав на иконку с надписью RFC, располагающейся в строке кнопок над письмом. В веб-интерфейсе почты Яндекса, нужно в правом верхнем углу экрана нажать на иконку Cвойства письма.
Для примера, рассмотрим заголовки письма, в качестве отправителя в котором значилось "Microsoft Corporation" и c темой "You Won (View Attachment)" , где сообщалось о крупном выигрыше в электронной лотерее и предлагалось для его получения заполнить анкету в присоединенном файле. Вообще-то, подозрительное содержание сообщения в данном случае неважно. Задача заключается в том, чтобы получить максимум информации об его отправителе.
Самые ранние, по времени формирования, поля заголовка находятся в нижней части, более поздние - в верхней. Поля, начинающиеся с символов X-, как правило, относятся к программному обеспечению, используемому для отправки электронного письма, его проверки на спам, вирусы и т.п. Особо полезных сведений для определения достоверности отправителя сообщения эти поля не содержат, хотя могут быть использованы в качестве дополнительного источника информации. Например, отправителем отображается корпорация Microsoft, а для отправки используется веб-почта поисковой системы Yahoo, чего, явно быть не может.
X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950
Поля From:, To: и Reply-To: также говорят о поддельности письма.
From: Microsoft Corporation < microsoft@alwert.net >
Выводимое имя отправителя "Microsoft Corporation" а почтовый адрес " microsoft@alwert.net " (реально присутствовавшие в сообщении адреса я изменил, сохранив структуру) . В адресах электронной почты используется формат
user@domain -Имя пользователя знак @ имя домена
Имеет ли домен из адреса отправителя какое либо отношение к Майкрософт, можно проверить с использованием специального программного обеспечения, как например Win32Whois или с использованием онлайн-сервисов Whois (на сайте 2ip.ru, например).
Следующее поле, на которое следует обратить внимание
Message-ID: 306099.58326.qm@web83802.mail.sp1.yahoo.com
Это внутренний идентификатор сообщения, присваиваемый почтовой системой, имя которой располагается после символа @. Если вы получили, якобы письмо от Microsoft или администрации Яндекса, а в имени почтовой системы присутствует yahoo.com, то сразу должны возникнуть подозрения, что здесь что-то не так. Следующее (снизу вверх) поле, Received: было сформировано первым в цепочке доставки почтовым сервером и дает нам адрес (адрес изменен мной), с которого было отправлено письмо
Received: from [141.29.80.148] by web83802.mail.sp1.yahoo.com via HTTP;
C большой долей вероятности можно предположить, что это, как минимум адрес из пула адресов Интернет - провайдера отправителя. Добавлю, что в большинстве случаев в сетях провайдеров клиентам выделяются динамические IP-адреса и, так называемые, "серые" IP, когда выход в Интернет выполняется с использованием технологии NAT (Network Address Translation) и в качестве IP в поле Received: будет адрес шлюза, через который производится выход в Интернет из внутренней сети провайдера. Для получения информации об IP-адресе можно воспользоваться тем же Win32Whois. Вместо имени домена заносим в поле DOMAIN интересующий нас IP-адрес
В результате, проанализировав заголовок письма, можно с большой долей вероятности определить поддельное электронное сообщение.