«Даже если вы получите какое-нибудь письмо, вы не сможете его прочитать»
(Марк Твен)
Мы уже писали о том, как правильно делать рассылки, улучшать их качество и эффективность. Приводили метрики, на основе которых строится репутация отправителя. Рассказывали об интерфейсе Постмастер Mail.Ru, с помощью которого их можно отслеживать. Многие компании, как находящиеся в начале своего развития, так и довольно крупные, пренебрегают этими правилами, в результате чего начинаются проблемы с доставляемостью писем, разбирательства со службой техподдержки и т.п. Но мы надеемся что вы не принадлежите к их числу.
Итак, ваш проект набирает популярность и нравится пользователям, вы собираетесь оставаться с ними на связи. Вы ознакомились с административными требованиями (о которых мы писали ранее) и собираетесь ответственно и без спама организовать рассылку для тех пользователей, которые готовы ее получать. А может быть, вы просто собираетесь настроить корпоративную почту. Поднимаете из дистрибутива почтовый сервер, пишете скрипт, запускаете и… 70% получателей письмо не доставлено, у 15% оно попало в папку «Спам», а остальные не могут прочитать то, что в нем написано. О том, что делать, чтобы этого не случилось, я попробую рассказать в этой статье.
Почему же все может не работать «из коробки» и требуются какие-то дополнительные рекомендации? Электронная почта — один из старейших протоколов интернета, который дожил до наших дней практически без изменений, но оброс огромным количеством сопутствующих стандартов и нигде не задокументированных практик применения. В самих стандартах электронной почты не заложено каких-либо методов аутентификации отправителя или предотвращения нежелательных рассылок и спама. Поэтому любой почтовый сервер выполняет ряд дополнительных проверок, чтобы отсеять нежелательную корреспонденцию (которой может быть более 90%).
Мы собрали список советов, которые помогут пройти эти дополнительные проверки. Многие из рекомендаций, перечисленных ниже, не являются обязательными, но чем больше из них вы выполните, тем выше вероятность, что проблем с доставкой писем возникать не будет.
Рекомендации для администратора почтового сервера:
Начинаем с… IP-адреса. От провайдера, хостера или регистратора вы получили IP-адрес (или целую сеть). Что нужно сделать, чтобы использовать выбранный адрес для почтового сервера, и годится ли он?
1. Убедитесь, что адрес реальный и статический.
Большая часть почтовых серверов ограничивает прием почты с динамических адресов или из сетей с трансляцией адресов. Причина в том, что в таких сетях находятся компьютеры конечных пользователей, которые не выполняют доставку почты. Соответственно, почти вся почта, которая идет из этих сетей, является спамом, отправленным через ботов. Поэтому репутация этих сетей безнадежно испорчена.
2. Проверьте whois-информацию с помощью утилиты whois или онлайновых сервисов (легко находятся поиском). Приведу список того, на что нужно обратить внимание:
2.1 У сети должно быть корректное описание. Если в описании будет информация о том, что она динамическая или предназначена для раздачи конечным индивидуальным пользователям (например, сети ADSL), скорее всего, вы также столкнетесь с множеством проблем при попытке ее использовать.
2.2 Для сети должны быть указаны abuse-контакты для жалоб, и эти контакты должны быть живыми и реагирующими. Иначе сеть (а вместе с ней и ваш IP) имеет большие шансы «влететь» в черные списки при наличии спам-инцидентов с любого из ее хостов.
2.3 Если сеть европейская (регистратор RIPE), статус сети должен быть ASSIGNED, ASSIGNED PA или ASSIGNED PI — это означает, что данная сеть используется. Многие регистраторы забывают пометить сеть как используемую, а некоторые получатели запрещают прием почты из неиспользуемых сетей.
Требуйте от регистратора внести корректную информацию в описание сети, но помните, что многие потенциальные получатели уже «помнят» старую информацию. Поэтому лучше изначально использовать IP-адреса из добросовестно администрируемых сетей с хорошей репутацией.
3. Проверьте и настройте PTR-запись для IP-адреса. PTR-запись должна указывать на реальное имя хоста. Желательно, чтобы
3.1 Это имя не напоминало имя динамического хоста, то есть не содержало слов dynamic, adsl, nat, длинных последовательностей символов или групп цифр. Например, server.example.com – хорошая, годная PTR-запись.
3.2 Если планируется действительно большой объем исходящей почты с нескольких серверов, то желательно давать наименования серверам в соответствии с черновым стандартом "DNS Naming Convention for Outbound Internet Email Servers" и создать предусмотренные этим документом зону и A-запись mxout.
3.3 Имя PTR-записи должно разрешаться обратно в тот же самый IP адрес, то есть A или CNAME запись server.example.com должна существовать и разрешаться в IP адрес сервера из примера.
Если сервер будет поддерживать несколько доменов, нет необходимости делать PTR-записи в каждый домен — вполне достаточно одной записи на любой из доменов. При проверке DNS лучше пользоваться сторонним DNS-сервером, чтобы убедиться, что записи действительно видны снаружи.
Управлением PTR-записями занимается оператор IP-сети, например, интернет- или хостинг-провайдер. Обычно это можно сделать самостоятельно через панель управления хостингом или службу поддержки провайдера.
4. Настройте MX-записи для домена, с которого будет производиться рассылка. Даже в том случае, если вы не планируете принимать какие-либо письма для этого домена. Как минимум вы должны корректно принимать и обрабатывать сообщения о невозможности доставки ваших писем и адрес postmaster@. Использование в адресе отправителя или в SMTP-конверте доменов без MX-записей негативно влияет на доставляемость писем. Некоторые получатели валидируют адреса отправителей из SMTP-конверта, поэтому желательно, чтобы сервер не давал ошибок при отправке письма на такой адрес.
5. Настройте SPF-запись. SPF позволяет указать, каким серверам разрешено отправлять почту от имени домена. SPF настраивается для адреса используемого в envelope-from (SMTP конверте).
6. Настройте DKIM:
6.1 Сгенерируйте ключевую пару DKIM и опубликуйте публичный ключ;
6.2 Не забудьте настроить подпись DKIM для всех исходящих писем (об этом чуть позже).
DKIM позволяет подписывать письма, которые отправляются от имени определенного домена. В настоящее время DKIM — это уже технология must have, она является технической основой для других — FBL, DMARC, а также для таких сервисов, как Постмастер Mail.Ru.
7. Опубликуйте политику DMARC. DMARC указывает, как именно следует использовать SPF и DKIM, и позволяет полностью исключить фишинг от имени домена с помощью публикации ограничивающей политики. А еще он дает возможность получать в виде структурированных отчетов все сведения о попытках нарушения вашей политики.
DMARC еще не принят как официальный стандарт, но уже поддерживается основными игроками на рынке электронной почты – Mail.Ru, Google, Yahoo и Microsoft. Это очень простое к внедрению и при этом крайне эффективное решение.
Вот теперь можно попытаться поднять почтовый сервер.
8. В настройках Mail Transfer Agent (почтового сервера) сконфигурируйте hostname сервера, который передается в команде HELO. Это имя должно совпадать с каноническим именем сервера из PTR-записи (server.example.com). Очень часто по умолчанию в HELO используются имена типа localhost.localdomain, и многие почтовые сервера отказываются принимать почту при таком HELO. Настройте SPF-запись для имени из HELO, это требование RFC 7208 которое позволит доставлять служебные письма с пустым адресом SMTP-конверта.
9. Включите поддержку DKIM в вашем почтовом сервере. В некоторых серверах поддержка встроена, в некоторых может быть реализована с помощью бесплатных программ (например, OpenDKIM), для Microsoft Exchange / IIS SMTP есть недорогие и бесплатные плагины. При настройке не спутайте DKIM (RFC 4871 / RFC 6376) и DomainKey (RFC 4870). DomainKey — устаревший стандарт, который так и не был принят. Делать его поддержку необязательно. DKIM можно узнать по наличию подписи DKIM-Signature в заголовках письма. Для подписи заголовков и тела письма лучше использовать relaxed режим.
10. Настройте ящик postmaster.
11. Избегайте конфигураций, приводящих к несанкционированному релеингу писем, иначе вся работа пойдет насмарку вместе с репутацией сервера.
12. Протестируйте конфигурацию вашего сервера, отправив письма на основные почтовые сервисы через стандартный почтовый клиент, например, Thunderbird. Проверьте заголовки полученных писем. Убедитесь в:
12.1 правильности HELO;
12.2 наличии и прохождении SPF-, DKIM- и DMARC-проверок на серверах, поддерживающих DMARC;
12.3 невозможности несанкционированного релеинга через ваш сервер;
12.4 том, что на postmaster@ и на адреса для отчетов DMARC и FBL доходят письма
12.5 сервером корректно формируются отчеты о невозможности доставки писем.
13. Подпишитесь на FBL (FeedBack Loop). FBL предоставляются многими крупными почтовыми сервисами. Подписка даст вам возможность получать сведения обо всех жалобах на спам на почту с вашего домена.
Теперь можно настраивать рассылки / писать скрипты для отправки писем. Приступаем.
14. Обрабатывайте сообщения о невозможности доставки писем. Помните, что есть два способа получения ошибки: в SMTP-сессии (в таком случае сообщение о невозможности доставки может формировать ваш сервер) или письмом с отчетом о невозможности доставки (NDR) от сервера получателя. Обрабатывать надо оба случая. При этом обязательно следует реагировать и исключать пользователя из рассылок при повторяющихся или постоянных (permanent) ошибках доставки на его адрес. Наличие большого количества невалидных получателей может приводить к снижению репутации и/или срабатыванию грейлистинга.
15. Устанавливайте адрес SMTP MAIL FROM: (envelope sender) – адрес отправителя, который используется на уровне протокола SMTP. Он может не совпадать с адресом отправителя из заголовка письма From:. Для нормальной работы DMARC желательно, чтобы адрес From: и адрес envelope sender были из одного домена. И, разумеется, письмо должно иметь валидную DKIM-подпись для этого домена и проходить проверки SPF. Некорректный адрес отправителя в конверте (envelope) – наиболее частая и серьезна ошибка в рассылках с различных веб-сайтов.
16. Не следует использовать в адресах From: и MAIL FROM адреса публичных почт, поскольку подобные рассылки не пройдут аутентификации SPF/DKIM в рамках DMARC. Используйте адреса вашего собственного домена.
17. В заголовках Content-Type для всех текстовых частей письма указывайте корректные кодировки. Убедитесь, что реальная кодировка текста совпадает с указанной в заголовке. Желательно использовать одну кодировку во всех заголовках и частях письма. В настоящее время рекомендуемой, наиболее широко поддерживаемой кодировкой текста является UTF-8. Если кодировка не указана (или указана неверно), текст может по-разному отображаться различными сервисами и почтовыми программами.
18. Формируйте заголовки From:, Message-ID: и Date: непосредственно в скрипте отправки письма. Убедитесь, что эти заголовки, особенно Date:, формируются в правильном формате. По стандартам эти заголовки формируются вместе с текстом письма. Если они отсутствуют или сформированы некорректно, заголовки может добавить один из транзитных серверов, что может привести к нарушению целостности DKIM-сигнатуры.
19. Убедитесь что во всех служебных и других заголовках, включая тему письма (Subject), имена вложенных файлов (Content-Type и Content-Disposition), символы, отличные от ASCII, в частности кириллица, закодированы в quoted-printable или base64. Согласно стандартам, в заголовках писем не могут встречаться некодированные восьмибитные символы; некоторые серверы не принимают такие письма. Если вы ориентируетесь на зарубежных подписчиков, то желательно чтобы письмо вообще не содержало не кодированных 8-битных символов.
20. Ограничивайте длину строки и используйте корректные терминаторы строк.
20.1 Максимальная допустимая длина строки в электронной почте — 998 8-битных символов. При использовании UTF-8 один отображаемый символ может занимать несколько октетов, поэтому старайтесь делать текст в строках короче или кодируйте текст в base64.
20.2 Корректным терминатором строк в электронной почте является CRLF (символы с кодами 13 и 10). В Unix стандартным терминатором строки является LF. Если используемый скрипт или MTA не заменяет терминаторы строк, это может приводить к проблемам — некорректному отображению письма или отрезанию части текста. Ошибки может вызвать и двойная замена терминаторов. Уточните в документации или протестируйте, следует ли в используемой вами конфигурации производить перекодировку концов строк.
20.3 Терминаторы строк не должны разбивать UTF-8 символы, чтобы не возникала ситуация, в которой терминатор в длинную строку добавляется, например, между двумя октетами одного кириллического символа. Поэтому разбивка текста должна производиться до формирования письма.
Кодирование текстовых частей в base64 увеличивает размер письма примерно на треть, но зато спасает от всех проблем, связанных с терминаторами строк в текстовых частях.
21. Старайтесь придерживаться достаточно простой структуры письма, избегайте глубокого нестирования составных (multipart) частей (то есть включения одной составной части в другую). Если в письме встречается более одной multipart-частей каждого типа (одной multipart/mixed одной multipart/alternative и одной multipart/related), скорее всего, письмо сформировано неоптимально.
22. Корректно проставляйте Content-Disposition каждой части как attachment (вложение, показываемое отдельно от письма) или inline (объект, отображаемый как часть письма, — например, картинка в тексте). Часто случается, что вложенный в письмо документ помечен как inline, хотя предназначен для скачивания пользователем, или логотип в тексте письма помечен как attachment, хотя он не должен быть виден в списке вложенных файлов.
23. Формируйте текстовую (plaintext) часть письма как альтернативную к HTML-части. Не забывайте, что пользователь может читать письмо, например, с сотового телефона. Корректно и красиво преобразовать HTML-содержимое в текст не всегда возможно. Добавив текстовую часть к письму, вы сможете быть уверены, что текст будет показан именно так, как вы этого ожидаете.
24. Протестируйте работу вашего скрипта на тестовых ящиках с разных сервисов электронной почты. Не забудьте скачать оригинал пришедшего в ящик письма и проверить:
24.1 корректность envelope sender;
24.2 прохождение SPF-, DKIM- и DMARC-проверок;
24.3 наличие и соответствие действительности кодировок текста в заголовках Content-Type для всех текстовых частей (включая HTML);
24.4 в HTML-частях – соответствие действительности кодировок, указанных в тегах meta (при их наличии);
24.5 отображение различных символов, включая кириллицу в текстовой, HTML-части и именах файлов (если планируется рассылать файлы);
24.6 наличие правильного Content-Disposition и Content-Transfer-Encoding для каждой части письма (кроме multipart);
24.7 отображение картинок и вложений;
24.8 корректность терминаторов строк;
24.9 корректное разбиение на строки и отображение длинных текстов в HTML и plain text частях;
24.10 Убедитесь, что заголовки From: Date: и Message-ID сформированы именно вашим сервером, подписаны DKIM-подписью и валидны.
Теперь можно переходить к верстке писем. Рекомендации для верстальщика:
25. Будьте проще. Не забывайте, что веб-почты вынуждены фильтровать часть тегов и атрибутов с целью обеспечения безопасности, и все они делают это по-разному. Избегайте использования классов, минимизируйте использование стилей, особенно для позиционирования. Старая добрая верстка на таблицах является наиболее переносимой.
26. Не пытайтесь верстать под веб-интерфейс определенного почтового сервера. Пользователи часто настраивают перенаправление, сборщики почты или читают письма в почтовых программах.
27. Думайте о пользователе. Он может открыть ваше письмо как на огромном ретина-дисплее, так и на старом телефоне на вершине Эвереста, пытаясь ухватить GPRS-соединение. Соответственно, письмо должно грузиться быстро, но выглядеть красиво даже при отключенных картинках.
28. Никаких надписей мелким шрифтом. Они нервируют и заставляют относиться к вам с подозрением. Не стесняйтесь показать пользователю, что вы знаете и уважаете его права и свои обязанности.
29. Выбирайте наиболее подходящий способ внедрения картинок. Есть следующие варианты, каждый со своими плюсами и минусами:
29.1 Внешние картинки: с точки зрения скорости отправки этот вариант – наиболее предпочтительный. Внешние картинки ничего не весят и не усложняют структуру письма. Однако многие приложения и почтовые сервисы требуют от пользователя разрешения на показ таких картинок. Кроме того, сервер, на котором они расположены, должен быть достаточно надежным, чтобы при открытии письма не приводить к «подвисаниям» из-за недоступности картинки. Используйте их, когда наличие картинок является опциональным.
29.2 Inline-картинки. Отправляются вместе с содержимым письма. Усложняют структуру письма и увеличивают его вес, зато могут быть достаточно большими и обычно отображаются по умолчанию.
29.3 Data URI. Содержимое картинки вставляется непосредственно в тег. Не усложняют структуры письма, почти всегда показываются в веб-почтах, иногда даже при отключенных картинках. Как правило, имеют ограничение на размер, годятся для небольших иконок.
29.4 Шрифтовые картинки. Изображения Unicode-символов из стандартных шрифтов или с помощью внедренных кастомных шрифтов. Уникальное свойство — могут масштабироваться вместе с текстом. Практически ничего не весят. Могут отображаться некорректно, в зависимости от версий операционной системы и установленных обновлений, устройства, почтовой программы или сервиса.
30. Во всех URI обязательно указывайте протокол (http://, https:// или mailto:), использование URI без протокола, например "//example.com/" недопустимо и может приводить к подвисанию письма в некоторых почтовых приложениях из-за попыток обратиться в сеть, использование протоколов отличных от перечисленных не рекомендуется, т.к. может быть зарезано фильтрами.
31. Тестируйте отображение каждой новой верстки письма на различных устройствах в разных веб почтах перед отправкой его «живым» пользователям.
Что делать, если, несмотря на соблюдение всех рекомендаций, письма все-таки не доходят до пользователей? Обращайтесь в службы поддержки получателей писем — как правило, подобные проблемы решаются оперативно. О проблемах доставки на адреса, обслуживаемые серверами Mail.Ru, можно писать на abuse@corp.mail.ru. Не забывайте как можно полнее описать проблему – очень помогут сообщения об ошибках, тексты сообщений о невозможности доставки, журналы серверов и прочая техническая информация.
К сожалению, формат статьи не позволяет детально расписать каждую из рекомендаций или дать подробные инструкции по настройке, но если у вас есть технические вопросы – с удовольствием на них отвечу в комментариях.
