Actual Contacts: Технологии проверки адресов электронной почты

Процесс доставки письма почтовым сервером состоит из двух этапов. Вначале он определяет адрес почтового сервера, который принимает письма для адресата (будем называть его Сервер Получателя, СП). Затем он соединяется с этим сервером по протоколу SMTP и передает ему письмо.

Почтовый домен (mail.com для адреса [email protected]; а "alex" в данном случае, это почтовый ящик в домене mail.com) обычно отличается от имени почтового сервера который принимает письма для этого адреса. На момент написания этой статьи, письма для [email protected] принимали сервера mail-com.mr.outblaze.com и mail-com-bk.mr.outblaze.com. А компьютеры имеющие адреса mail.com и www.mail.com вообще не принимали почты ни для каких адресов. Поэтому напрямую связывать почтовый домен с адресом почтового сервера никак нельзя, зачастую почту принимает компьютер с совсем другим именем.

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

DNS является распределенной базой данных. Например, сервер DNS ns1.outblaze.com хранит всю информацию о домене mail.com, но ничего "не знает" о других доменах, например о hotmail.com. Сервер ns1.hotmal.com хранит информацию о домене hotmail.com, но ничего "не знает" о других доменах. Есть сервер, отвечающий за домены в зоне .com, который хранит информацию о том, на каких серверах хранится информация о доменах в этой зоне.

Сервер DNS Вашего провайдера не содержит никаких записей о mail.com или hotmail.com. Поэтому когда он получит запрос о имени mail.com, он узнает у сервера отвечающего за зону .com адрес сервера, который содержит информацию о домене mail.com (это будет ns1.outblaze.com), соединится с ним и вернет Вам ответ. Такое выполнение запроса называется рекурсивным.

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

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

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

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

По имеющейся статистике, из этих 2/3 несуществующих адресов, около 30% несуществующих адресов выявляется на первом этапе проверки, и 70% на втором этапе. Второй этап проверки в среднем требует в 10 раз больше времени и в пять раз больше сетевого трафика, чем первый этап. Практически, двухэтапная проверка требует почти столько же времени и трафика, сколько и отправка небольшого письма на проверяемый адрес.

Рассмотрим подробнее оба этапа. На первом этапе проверяющая программа выполняет синтаксический разбор адреса электронной почты, выделяет почтовый домен и отправляет запрос к серверу DNS на получение адреса почтового сервера для этого домена. Работа с сервером DNS осуществляется по протоколу UDP, этот протокол более быстр, чем протокол TCP, так как он не ориентирован на установление соединения между серверами. Обычно, время выполнения запроса к серверу DNS не превышает 1..2 секунд, и за это время отправляется один пакет с запросом (около 60 байт, вместе с заголовком пакета) и принимается один пакет с ответом (не более 512 байт; обычно не более 200..300). Соответственно, на этом этапе отсеиваются все синтаксически неверные адреса, и адреса с несуществующих доменов.

На втором этапе осуществляется подключение к почтовому серверу по протоколу SMTP (базирующемся на TCP). Протокол TCP ориентирован на соединение, поэтому вначале соединяющиеся сервера отправляют служебные пакеты для установления соединения. После установления соединения, сервера обмениваются приветствиями (см. первые три строки в журнале ниже); затем сообщается адрес отправителя, и принимающий сервер подтверждает, что готов принять почту с такого адреса; после чего сообщается адрес получателя письма:

< 220-ns.watson.ibm.com ESMTP Sendmail AIX4.3/8.9.3/8.9.0
< 220 Thu, 22 Aug 2002 20:44:07 +0500
> HELO cisco.my.net
< 250-ns.watson.ibm.com Hello cisco.my.net [12.44.72.94],
< 250 pleased to meet you
> MAIL FROM:
< 250 ... Sender is valid.
> RCPT TO:
< 550 ... User unknown
> RSET
< 250 Resetting the state.
> QUIT

В данном случае, принимающий сервер ответил, что ему неизвестен пользователь с адресом [email protected] и отказался принимать для него почту, и после этого сервера обменялись командами для завершения соединения. Сервера во время проверки адреса в сумме послали друг другу десять сообщений, суммарным размером около 500 байт; но для их пересылки потребовалось обменяться более чем 20 пакетами, и суммарный трафик составил около двух килобайт. Причем большую часть времени заняло ожидание ответа от другого сервера.