Хочу всегда во "Входящие" - 3 или проверки принимающих серверов

Сегодня мы хотели бы рассказать вам о том, какие проверки проходят письма, сервера и клиенты прежде чем письмо будет обработано, отправлено и доставлено, как мы и хотим «во входящие».

В этой теме есть два раздела: общие проверки и специальные, и с вашего позволения в этой статье мы коснемся общих проверок, а специальные рассмотрены в следующей - «Хочу всегда во входящие 4 или Как понять аббревиатуры: SPF, DKIM, DMARC». Этими двумя статьями мы хотим описать для вас основные причины, по которым письмо может быть не доставлено «во входящие», а попасть в спам или же вообще быть отклоненным. Нет, к сожалению, все причины мы не сможем охватить, ибо «тысячи их», но уж основные, так постараемся.

И еще... необходимо запомнить сразу, если письмо не доставлено — это значит что:

1. Или нашлась четкая причина, по которой ваше письмо классифицировано, как спам;
2. Или оценив огромное количество показателей, сервер решил, что ваше письмо — спам.

Вы должны понимать, что чем правильней вы работаете, тем больше вероятность доставки письма.

Упрощенные схемы взаимодействия серверов

1. Схема №1: Рабочая станция (компьютер пользователя) с программой типа «The Bat», «Windows Mail» или «Mozilla Thunderbird» — SMTP сервер локальной сети — SMTP сервер конечного адресата (принимающий сервер)
2. Схема №2:  SMTP — сервер с Web-интерфейсом (почтовый сервер типа Mail.ru, Gmail.com, Yandex.ru и т. д.) — SMTP сервер конечного адресата (принимающий сервер)

Как видим, разница заключается лишь в том, что в первой схеме, письмо принимается SMTP — сервером от программы, установленной на рабочей станции по сети, а во втором случае письмо передается внутри системы (Web — интерфейс чаще всего сам передает все в MTA).

Этап 1: Подключение программы клиента к SMTP — серверу (принимающему серверу)

Итак, что может проверить SMTP — сервер когда клиент к нему только подключается?

1. IP — адрес.

• Разрешено ли с этого ip-адреса подключение к SMTP — серверу
• Разрешен ли прием почты с этого ip-адреса
• Не входит ли данный ip-адрес в «черный список»

2. Логин и пароль

Да, да! Именно логин и пароль! В случае, если на сервере требуется аутентификация, то логин и пароль должны быть предоставлены. Иначе сервер просто отбросит этого клиента.

• Верны ли логин и пароль
• Имеет ли этот пользователь право отправлять почту
• Не достиг ли этот пользователь лимитов отправки почты

Понятно, что в случае доступа к почте через браузер, это все происходит на уровне между Web-интерфейсом и MTA.

Подключение SMTP — сервера (отправляющего) к SMTP — серверу (принимающему)

Как вы помните из прошлой статьи (приколы SMTP-протокола), SMTP — протокол при взаимодействии между серверами не требует никаких логинов и паролей, т. к. подразумевается, что не может быть единой огромной базы доменов и серверов, по которой можно было бы проверять аутентичность данных, поэтому сервера вынуждены использовать огромное количество проверок, которые объединяются в одну оценку — спам или нет :)

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

1. IP — адрес передающего SMTP — сервера

• Не входит ли данный ip-адрес в «черный список» адресов, которые были замечены в распространении спама, или не входит ли данный ip-адрес в «черный список» ПОДСЕТЕЙ, из которых идет (или ранее распространялся) спам. Что это значит? Существует некоторое количество доверенных баз данных, которые содержат информацию о адресах или сетях, которые распространяют спам. И почтовые сервера, при подключении к ним других, получают их ip-адрес, связываются с базами данных и проверяют эту информацию. Иногда это приводит даже к казусам. Т.к. ip-адреса в принципе уже являются «разменной монетой» между провайдерами и хостерами, то бывает так: арендовали вы сервер, настроили на нем сайт-магазин, приходят к вам пользователи, регистрируются, а тут «БА БАЦ!» и регистрационные письма попадают в спам. А почему? А потому, что раньше какой то (нехороший человек-редиска) с этого сервера распространял спам! Потом прекратил его аренду. А след то в базах данных остался. А еще круче бывает: арендуют «китайсы» блок (подсеть) адресов в 200 штук, валят с них спам не по детски, а потом отдают другим. И все! Вся подсеть в «black list». Что бы вы с нее не слали — все в спам! И теперь задача провайдера или хостера «отбелить» этот адрес или сеть, т. е. связываться с этими базами данных, договариваться, чтобы они удалили информацию о адресе или подсетях.

• Не входит ли данный ip-адрес в «серый список». Что это такое? Это специальный подход к обработке спама. Смотрите, по разному бывает в моменты доставки почты: сервер занят, перегружен, отключен и т. д. По идее, когда вы отправили нормальное письмо, если с первой попытки не получилось доставить, то ваш сервер должен попробовать еще пару раз доставить письмо. Спамеры это практически не делают! Не получилось — и ладно! Они количеством берут. Потому, если принимающий сервер впервые видит подключение с вашего сервера. Он заносит его ip-адрес в «серый список» (а также адрес отправителя и получателя). Если через какое то время, снова ваш сервер стучится к принимающему с тем же самым письмом, то тут уже чаще всего — добро пожаловать, главное правильную паузу выдержать.

• Не входит ли данный ip-адрес в «белый список». Тут все просто. Есть адреса, письма с которых принимаются безоговорочно. Как попасть в такой список? Просто! - Договориться! Пишите в тех. поддержку, говорите, что вы «белые и пушистые», договаривайтесь :)

2. Домен передающего SMTP — сервера или домен отправителя письма ( нужно учитывать, что это не всегда одно и то же)

• Существует ли данный домен. На самом деле в поле From может быть любой адрес. Потому сервера проверяют, а вообще доступен ли домент. Как? Очень просто — обращаются к сервису whois и вообще доменной службе. Если домен есть — окей, нету — извините, с привидениями не общаемся.
• Не входит ли данный домен в «черный список». Аналогично с прошлым пунктом :)
• Не входит ли данный домен в «серый список». Аналогично с прошлым пунктом :)
• Не входит ли данный домен в «белый список». Аналогично с прошлым пунктом :) К примеру, ukr.net работает на момент написания статьи по белым спискам. Если сервер неизвестен ему — отправляет в сад, известен — принимает. Договаривайтесь...
• А вообще этот домен почту обрабатывает? Это очень забавная проверка, которая связана с тем, что спамеры иногда вообще берут домен на 1 день, отправляют миллиарды писем и потом продают домен дальше. А в чем замутка? Да в том, что им абсолютно не нужно принимать обратные ответы в виде писем и обрабатывать их. Потому они и не настраивают MX-записи, записи, которые отвечают за указание серверов, которые должны обрабатывать почту этого домена. Зачем это им? Кроме того, доменная структура такова, что записи прописываются и настраиваются от нескольких часов до 3 дней. Отож бо.

3. Комбинация ip-адреса сервера и домена отправителя

• PTR — запись ip-адреса. Если вы читали или слышали такие фразы, как: обратный DNS запрос, обратная DNS зона, Reverse DNS и т. д., то это оно :) Попробуем пояснить в двух словах, хотя и хлопотно это. Итак, когда вы заходите на сайт estismail.com или выполняете команду ping estismail.com (можно любой другой домен), ваш компьютер обращается к службе DNS с просьбой: А ну дайте ка мне адрес, на котором находится данный домен? Ему говорят: 87.118.112.230. Ну и тут уже компьютер связывается с этим адресом напрямую. Окей. Теперь представим ситуацию, что на одном хостинге лежит 10 сайтов. Т.е. если вы запрашиваете сайт rogaikopita.com и сайт noviekopita.com, то вам вернут один и тот же адрес, к примеру, 5.8.114.3 (вымышленный, можете не проверять :) ). Отлично. А теперь нас интересует обратная задача: А какое имя имеет сервер с адресом 87.118.112.230? Есть пара специальных команд, которые позволяют это делать. Если их использовать, то получите ответ, что адрес 87.118.112.230 имеет имя estismail.com. А как это сделать? Просто. За ваше обратное имя отвечает ваш провайдер. Именно он настраивает это имя, или же дает возможность настроить самостоятельно. Но теперь представьте, что у вас на одном сервере 10 сайтов клиентов и вы запрашиваете PTR, какое обратное имя будет? Одного из клиентов? Очень очень врядли. Скорее всего какое либо техническое провайдеровское. А теперь вопрос: к какому домену больше доверия: у которого совпадает его имя и обратная запись, или же не совпадает? Ответ очевиден :)

• Штука под названием SPF, но о ней в следующей статье, т. к. она относится с специализированным средствам проверки.

Ну как вам масштаб? И это только этап подключения! Дальше — больше (ну по крайней мере не меньше)!

Этап 2: Прием письма SMTP — сервером (принимающим сервером)

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

Поехали! (с) Ю. Гагарин

1. Проверка поля "From" — поле «от кого»

Отправитель. Тот, кто инициировал отправку письма. Забавно то, что отправитель не всегда непосредственно осуществляет доставку почты. Об этом в подпункте 3. Но чаще всего отправитель — это отправитель.

Проверки:

• Проверка существования домена отправителя. Естесственно! Зачем же доставлять письмо от пользователя несуществующего домена?:)
• Проверка MX — записей домена отправителя. Аналогично :)
• Проверка соответствия домена адреса отправителя домену отправляющего сервера. О! Вот забавно выходит тут. Допустим, что у вас на ноутбуке корпоративная почта, и отправлять почту потенциально можно только из офиса. Т.е. SMTP — сервер компании доступен только из ее локальной сети. Что же делать? Ну, если у вас есть свой или же дружеский SMTP доступный из дому, то почему нет? Можете отправить письмо с корпоративного ящика без проблем, аутентификация то не привязана к полю From — таковы «Приколы SMTP протокола» (см. предыдущую статью). И этим то спамеры и пользуются. Отправляют с любых открытых серверов письма от любых пользователей. Соответственно, приходится с этим бороться проверками доменов отправителя и PTR-записи доставляющего сервера.
• Проверка вхождения адреса в «черный список». Допустим, с этого адреса шел многодневный и многогодовой спам. И тут одно письмо нормальное. Как вы думаете, велики шансы пройти в входящие? Конечно нет. Запомнил этот адрес сервер да и блокирует письма с него.
• Проверка DKIM и DMARC домена отправителя — снова «специфика», смотрим следующую статью.

2. Проверка поля "To" — поле «кому»

• Проверка существования адресата и его доступности.Что ж тут проверять вроде? Существует или нет. А не все так просто. Очень часто логины корпоративных адресов идентичны, к примеру: admin@roga.com, admin@kopita.com, director@company.ru, director@company2.ru и т. д. Следовательно, стоит только спамерам засечь новый домен, то попробовать отправить письмо админам, директору, бухгалтеру и т. д. не составляет проблемы. Далее, спамеры пользуются собранными базами данных с сайтов, а так же ворованными базами. И мало заботятся о том, чтобы базы были адекватными. Ведь многие ящики переполняются, если за ними не следят, а многие удаляются. Как мы и говорили, спамеры числом берут. Итак, а теперь представьте, что на ваш почтовый сервер с какого то адреса почтового, с какого то ip-адреса незнакомого пытаются доставить кучу писем на несуществующие, блокированные или переполненные ящики. Подозрительно? А то! В черный список и почту, и сервер! Ну или по крайней мере присмотреться к ним повнимательней. Поставить на анализ.

3. Проверка поля «Sender» — поле «отправщик»

Что за фигня? Это ж то же самое, что и поле From. Ан нет! Накося выкуси! Если на пальцах, то "to" — кому письмо, "from" — от кого, "sender" - кто доставляет. Чаще всего from = sender. Но не всегда. К примеру, в списках корпоративной да и любой рассылки. Как оно работает: письмо от пользователя отправляется не всем подписчикам, а на определенный адрес сервера, а уже он рассылает подписчикам. Т.е. технический адрес рассыльщика и есть наш sender (отправщик).

• Проверка существования домена отправщика. Аналогично предыдущим пояснениям :)
• Проверка MX — записей домена отправщика. Аналогично предыдущим пояснениям :)
• Проверка DKIM и DMARC домена отправщика — снова «специфика», смотрим следующую статью.

Ладно, проверили мы все технические поля (ну не все, конечно, но об этом снова таки дальше), давайте принимать тело письма.

4. Проверка тела письма.

Тут целая индустрия работает. Если хотите подробнее — читайте в сторону «SpamAssasin» и его принципов работы.

• Проверка получения аналогичных или похожих писем. Как вы думаете, если сервер получил 100 000 000 000 одинаковых писем это спам? А если он получил столько же писем, но похожих на 90% это спам? Ха! Тут целая наука вычисления схожести текстов, и, поверьте, это работает. У каждого почтового сервиса свои правила вычисления схожести и классификации спамовости письма. Грубо говоря, каждый сервер по своему вычисляет и по своему принимает решение об уровне, после которого письмо приобретает черты спама.
• Проверка нахождения ключевых слов. Ну это просто. Есть целые словари слов, которые могут придавать письму элементы спамовости. Про наркотики, таблетки, девушек легкого поведения и т. д. мы уже даже не говорим :) Поверьте, что письмо вида: «Хочешь заработать миллион? Звони нам!» или вида «Красивые девушки для вас сделают, что угодно!» практически гарантированно обретет в лице почтовых серверов оценку спам.
• Проверка специальных элементов в письме (ссылок, якорей, картинок). Эх... сервисы минимизации ссылок все знают? Они под подозрением. Встретит сервер ссылочку в тексте, присмотрится пристальней. Увидит картинку специфическую — опять же присмотрится. А то много уже есть умных! Текст пишут на картинке, и картинку к письму прикладывают. Ха! На каждую хитрую «гайку» - болт с левой резьбой!
• Проверка корректности текста. Спамеры — красавцы! Чтобы не рассусоливать: текст «голые бабы» превращают в «г0лые б@бbl». Для начала работает. Потом сервера учатся. Начинают это вычислять. Оценивают чистоту и правильность текста. Смотри предыдуший пункт про гайку :)

5. Проверка подписей письма

А вот если у нас рассылка реальная, то как быть? Как сказать серверам, что все в порядке? Есть моменты. Технические характеристики будут в следующих статьях. А вот административные, которые требуют и, что самое главное, проверяют почтовые сервера это:

• Проверка наличия подписей. Подписи должны быть. Должны говорить что за рассылка, откуда, по какому праву (Вы подписаны на рассылку. Хотите отписаться — милости просим сюда. И т. д.)
• Проверка их валидности — опять же. Ссылки на отписку должны существовать. Адреса отписки должны существовать и функционировать. Проверяется.

Ну в общем, как то так. Если верхом и «по загалям» то ситуация вот такая, как было описано выше.

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

Но если прошли это все — поздравляем! Вы шарите!:) И у вас все четко настроено.

До встречи на страницах!