Недавно мне задали вопрос о том, как отправлять большое количество почты и при этом не попасть в спам. Если не брать во внимание текст самих сообщений, то советы достаточно простые – по сути, они отражают основные принципы, на основании которых почтовые сервера принимают решение о дальнейшей обработке писем. Причем реакция на каждый тип проверки может быть разная –
а. Отказ в обработке с подробным сообщением об ошибке (лучший вариант)
б. Добавление служебного заголовка для дальнейшей обработки
в. Повышение счетчика вероятности спама для данного письма
г. Блокировка дальнейших соединений или молчаливое «поедание» писем без какого-либо информирования отправителя
1. Использование адресов
Самая базовая проверка заключается в том, что сервер получателя проверяет наличие PTR записи и того, что она разрешается в адрес сервера отправителя. Хорошим тоном также считается, чтобы домен отправителя и строки приветствия также разрешались в адрес сервера отправителя, так что если вы планируйте отправлять почту не с того сервера, с которого обычно принимайте письма, не поленитесь и добавьте его в набор MX записей с наименьшим приоритетом. Кроме того, настройте сервер на прием и отправку писем с определенных, явно указанных адресов – это поможет избежать проблем с отправкой почты не с тех адресов из-за “случайного” появления лишнего сетевого интерфейса или каких-либо иных проблем с конфигурацией сети.
P.S. А еще некоторые сервера могут также проверять корректность настроек DNS, так что как бы вам не хотелось, избегайте ссылок на CNAME записи, т.е. MX запись может ссылаться на A/AAAA записи, но не на CNAME.
2. Отправляйте почту с существующих адресов и не используйте greylisting
Многие сервера используют reverse check, соединяясь с сервером отправителя навстречу с целью инициировать отправку почты по адресу отправителя – если ящик отправителя не существует, то вероятность попадания в спам увеличивается. Это достаточно частая проблема с настройкой серверов. Рекомендация достаточно простая – отправляйте почту с существующих ящиков. Также не рекомендуется использовать greylisting ни в мягкой (задержка prompt до 5 минут), ни в жесткой формах (разрыв соединения с неизвестных серверов в первые несколько часов в надежде, что правильный сервер повторит отправку сообщения) – многие сервера имеют настройки не соответствующие стандарту и не будут ждать положенного времени.
3. SPF и DKIM
Записи SPF (Sender Policy Framework) определяют с каких серверов можно отправлять письма с вашего домена – это действительно полезно, если вы не хотите чтобы кто-то подделывал ваши сообщения или отправлял спам от вашего имени. Рекомендуется использовать и SPF и TXT RR (DNS resource record) одновременно.
DKIM (DomainKeys Identified Mail) используется для подписи исходящих писем ключом домена, который хранится в DNS, и служит тем же целям, что и SPF. Использование обеих технологий повышает доверие к вашему домену.
4. Blacklists
Большинство серверов используют блеклисты для фильтрации почты на подходе, так что достаточно важно не попадаться в них. Причем попасть в них вы можете и не по своей воле – тот же Spamhaus может блокировать адресные диапазоны вашего оператора лишь из-за того, что он предоставляет uplink операторам, которые, по их мнению, отправляют спам (или не платят им деньги). Так что вопрос с попаданием в блеклисты стоит постоянно проверять и, если что, иметь сервера для отправки в сетях иных операторов.
Если получатели ваших писем (например, госструктуры) используют witelisting, то попасть в него бывает полезно.
5. Старайтесь не попадаться в ловушки
Для поиска спамеров отдельные компании и блеклисты используют ловуши – spam traps – адреса, написав на которые можно попасть в такую ситуацию, что письма с ваших адресов сервер начнёт молча «кушать», а сам адрес засветится в каком-нибудь блеклисте. Бывают единичные случаи атак, когда вам скармливают адреса spamtraps крупных получателей почты и блеклистов с целью того, чтобы вывести ваш сервис из строя на несколько дней. Против этого помогает только постоянные проверки существования отправителя.
6. TLS
Встречаются и такие случаи, когда сертификаты, которые используются в почтовой системе, устаревают или становятся недействительными. Такие ситуации можно избежать только имея документированные процессы работы с сертификатами - не поленитесь их описать и им следовать.
В дальнейшем, когда рабочая группа DANE IETF выпустит RFC по использованию TLSA для SMTP и ресурсной записи TRYTLS, я рекомендую начать их использовать, предварительно подписав зону DNSSEC.
7. Анализ ответов
Если вы посылайте большое количество почты, то потратьте время на внедрение мониторинга - не игнорируйте ни сообщения серверов, ни ответные письма, ни статистику прочтения сообщений конечными пользователями.
P.S. Если я что-нибудь забыл или допустил неточности, пришлите мне письмо, чтобы эти рекомендации можно было бы опубликовать в качестве BCP/BCOP.
Басков Антон <anton @t ministry.int.ru>