Технические Рекомендации По Рассылкам

Говорили об интерфейсе Почтмейстер Mail.Ru , с помощью которого их можно отслеживать.

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

Итак, ваш проект набирает популярность и нравится пользователям, вы будете оставаться с ними на связи.

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

Или, может быть, вы только собираетесь настроить корпоративную электронную почту.

Берешь из дистрибутива почтовый сервер, пишешь скрипт, запускаешь его и.

70% получателей не получили письмо, у 15% оно оказалось в папке "Спам", а остальные не могут прочитать то, что в нем написано.

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

Почему все может не работать «из коробки» и требуются какие-то дополнительные рекомендации? Электронная почта — один из старейших Интернет-протоколов, который дошел до наших дней практически в неизменном виде, но приобрел огромное количество сопутствующих стандартов и практик применения, которые нигде не документированы.

Сами стандарты электронной почты не предусматривают никаких методов аутентификации отправителя или предотвращения нежелательных рассылок и спама.

Поэтому любой почтовый сервер выполняет ряд дополнительных проверок для отсеивания нежелательной корреспонденции (которых может быть более 90%).

Мы собрали список советов, которые помогут вам пройти эти дополнительные проверки.

Многие из перечисленных ниже рекомендаций не являются обязательными, но чем большему количеству из них вы следуете, тем больше вероятность того, что проблем с доставкой электронной почты не возникнет. Рекомендации администратору почтового сервера: Начнем с… IP-адреса.

Вы получили IP-адрес (или всю сеть) от своего провайдера, хостера или регистратора.

Что нужно сделать, чтобы использовать выбранный адрес для почтового сервера и подходит ли он? 1. Убедитесь, что адрес реальный и статический.

Большинство почтовых серверов ограничивают прием почты с динамических адресов или из сетей трансляции адресов.

Причина в том, что такие сети содержат компьютеры конечных пользователей, которые не доставляют почту.

Соответственно, почти вся почта, приходящая из этих сетей, — это спам, рассылаемый через ботов.

Таким образом, репутация этих сетей безнадежно испорчена.

2. Проверьте информацию whois с помощью утилиты whois или онлайн-сервисов (легко найти с помощью поиска).

Вот список того, на что нужно обратить внимание: 2.1 Сеть должна иметь правильное описание.

Если в описании указано, что оно является динамическим или предназначено для распространения среди конечных пользователей (например, сеть ADSL), вы, скорее всего, также столкнетесь с множеством проблем при попытке его использования.

2.2 В сети должны быть контакты для подачи жалоб на злоупотребления, и эти контакты должны быть активными и отзывчивыми.

В противном случае сеть (а вместе с ней и ваш 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 для серверов исходящей электронной почты в Интернете » и создайте зону и A-запись mxout, предусмотренные в этом документе.

3.3 Имя записи PTR должно разрешаться обратно в тот же IP-адрес, то есть запись A или CNAME server.example.com должна существовать и разрешаться в IP-адрес примера сервера.

Если сервер будет поддерживать несколько доменов, нет необходимости делать PTR-записи для каждого домена — достаточно одной записи для любого из доменов.

При проверке DNS лучше всего использовать сторонний DNS-сервер, чтобы гарантировать, что записи действительно видны внешнему миру.

Записи PTR управляются оператором IP-сети, например Интернет-провайдером или хостинг-провайдером.

Обычно вы можете сделать это самостоятельно через панель управления хостингом или через службу поддержки вашего провайдера.

4. Настройте MX-записи для домена, с которого будет отправляться рассылка.

Даже если вы не планируете принимать электронные письма для этого домена.

Как минимум, вы должны корректно получать и обрабатывать сообщения о невозможности доставки ваших писем и адреса postmaster@.

Использование доменов без MX-записей в адресе отправителя или SMTP-конверте отрицательно влияет на доставляемость писем.

Некоторые получатели проверяют адреса отправителей из SMTP-конверта, поэтому желательно, чтобы сервер не выдавал ошибок при отправке письма на такой адрес.

5. Настраивать SPF-запись .

SPF позволяет указать, каким серверам разрешено отправлять почту от имени домена.

SPF настроен для адреса, используемого в конверте-от (конверте SMTP).

6. Настраивать ДКИМ : 6.1 Создайте пару ключей DKIM и опубликуйте открытый ключ; 6.2 Не забудьте настроить подпись DKIM для всех исходящих писем (подробнее об этом позже).

DKIM позволяет подписывать электронные письма, отправляемые от имени определенного домена.

В настоящее время DKIM уже является обязательной технологией; это техническая основа для других — FBL, DMARC, а также для таких сервисов, как Postmaster Mail.Ru. 7. Опубликовать политику ДМАРК .

DMARC точно определяет, как следует использовать SPF и DKIM, и позволяет полностью исключить фишинг доменных имен путем публикации ограничительной политики.

Также это дает возможность получать в виде структурированных отчетов всю информацию о попытках нарушения вашей политики.

DMARC пока не принят в качестве официального стандарта, но уже поддерживается основными игроками рынка электронной почты — Mail.Ru, Google, Yahoo и Microsoft. Это очень простое в реализации и в то же время чрезвычайно эффективное решение.

Теперь можно попробовать поднять почтовый сервер.

8. В настройках агента передачи почты (почтового сервера) настройте имя хоста сервера, которое отправляется в команде 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 в заголовках электронных писем.

Для подписи заголовков и тела письма лучше использовать расслабленный режим.

10. Настройте почтовый ящик почтмейстера.

11. Избегайте конфигураций, которые приводят к несанкционированной ретрансляции писем, иначе вся ваша работа пойдет насмарку вместе с репутацией сервера.

12. Проверьте конфигурацию своего сервера, отправив электронные письма на основные почтовые службы с помощью стандартного почтового клиента, такого как Thunderbird. Проверьте заголовки полученных писем.

Убеждаться: 12.1 HELO корректность; 12.2 наличие и прохождение проверок SPF, DKIM и DMARC на серверах, поддерживающих DMARC; 12.3 невозможность несанкционированной ретрансляции через ваш сервер; 12.4 что письма отправляются на почту postmaster@ и на адреса для отчетов DMARC и FBL 12.5 Сервер корректно формирует отчеты о невозможности доставки писем.

13. Подпишитесь на FBL (петля обратной связи).

ФБЛ предоставляются многими крупными почтовыми службами.

Подписка даст вам возможность получать информацию обо всех жалобах на спам по электронной почте с вашего домена.

Теперь вы можете настраивать рассылки/писать скрипты отправки писем.

Давайте начнем.

14. Обрабатывать сообщения о невозможности доставки писем.

Помните, что существует два способа получить сообщение об ошибке: в сеансе SMTP (в этом случае ваш сервер может сгенерировать сообщение о недоставке) или через электронное письмо с отчетом о недоставке (NDR) от сервера получателя.

Оба случая должны быть рассмотрены.

В этом случае необходимо обязательно отреагировать и исключить пользователя из рассылок в случае повторных или постоянных ошибок доставки на его адрес.

Наличие большого количества невалидных получателей может привести к снижению репутации и/или занесению в серый список.

15. Установите адрес SMTP MAIL FROM: (отправитель конверта) – адрес отправителя, который используется на уровне протокола SMTP. Он может не совпадать с адресом отправителя из заголовка письма «От:».

Для правильной работы DMARC желательно, чтобы адрес From: и адрес отправителя конверта были из одного домена.

И, конечно же, письмо должно иметь действующую для этого домена DKIM-подпись и пройти SPF-проверку.

Неправильный адрес отправителя в конверте (конверте) – самая распространенная и серьезная ошибка при рассылках с различных сайтов.

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-символы, в частности кириллицу, закодированы в кавычках-печатных или база64. Согласно стандартам, заголовки электронных писем не могут содержать незакодированные восьмибитные символы; некоторые сервера не принимают такие письма.

Если вы ориентированы на иностранных абонентов, то желательно, чтобы письмо вообще не содержало некодированных 8-битных символов.

20. Ограничьте длину линии и используйте правильные терминаторы линии.

20.1 Максимально допустимая длина строки в электронном письме — 998 8-битных символов.

При использовании UTF-8 один отображаемый символ может занимать несколько октетов, поэтому старайтесь, чтобы текст содержался в строках короче или кодируйте текст в формате Base64. 20.2 Правильный признак завершения строки в электронном письме — CRLF (символы с кодами 13 и 10).

В Unix стандартным признаком завершения строки является LF. Если используемый скрипт или MTA не заменяет терминаторы строк, это может привести к таким проблемам, как некорректное отображение буквы или обрезание части текста.

Двойная замена терминаторов также может стать причиной ошибок.

Проверьте документацию или проверьте, требует ли ваша конфигурация перекодирования конца строки.

20.3 Терминаторы строк не должны разрывать символы UTF-8, чтобы не возникала ситуация, когда терминатор добавляется в длинную строку, например, между двумя октетами одного и того же символа кириллицы.

Поэтому разбивку текста необходимо делать до того, как будет сформировано письмо.

Кодирование текстовых частей в base64 увеличивает размер буквы примерно на треть, но избавляет вас от всех проблем, связанных с разделителями строк в текстовых частях.

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

Если письмо содержит более одной многочастной части каждого типа (одну многочастную/смешанную, одну многочастную/альтернативную и одну многочастную/родственную), скорее всего, письмо сформировано не оптимально.

22. Правильно задайте Content-Disposition каждой части как вложение (вложение, отображаемое отдельно от письма) или встроенное (объект, отображаемый в составе письма — например, картинка в тексте).

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

файлы.

23. Сформируйте текстовую часть письма как альтернативу HTML-части.

Не забывайте, что пользователь может прочитать письмо, например, с мобильного телефона.

Не всегда возможно правильно и красиво преобразовать HTML-контент в текст. Добавляя текст в свое электронное письмо, вы можете быть уверены, что текст будет выглядеть именно так, как вы ожидаете.

24. Проверьте свой скрипт на тестовых почтовых ящиках разных почтовых сервисов.

Не забудьте скачать оригинал письма, пришедшего на ваш почтовый ящик, и проверить: 24.1 корректность отправителя конверта; 24.2 прохождение проверок SPF, DKIM и DMARC; 24.3 наличие и корректность кодировок текста в заголовках Content-Type для всех частей текста (включая HTML); 24.4 в HTML-частях – соответствие валидности кодировок, указанных в метатегах (при их наличии); 24.5 отображение различных символов, в том числе кириллицы в тексте, HTML-частях и именах файлов (если вы планируете отправлять файлы); 24.6 наличие корректного Content-Disposition и Content-Transfer-Encoding для каждой части письма (кроме многочастного); 24.7 отображение картинок и вложений; 24.8 исправность терминаторов линий; 24.9 правильный перенос строк и отображение длинных текстов в HTML и обычных текстовых частях; 24.10 Убедитесь, что заголовки From: Date: и Message-ID созданы вашим сервером, подписаны подписью DKIM и действительны.

Теперь можно переходить к раскладке букв.

Рекомендации верстальщику: 25. Будь проще.

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

Избегайте использования классов, сведите к минимуму использование стилей, особенно для позиционирования.

Старый добрый настольный макет является наиболее портативным.

26. Не пытайтесь писать код для веб-интерфейса конкретного почтового сервера.

Пользователи часто настраивают перенаправления, сборщики почты или читают сообщения в почтовых программах.

27. Подумайте о пользователе.

Он может открыть вашу электронную почту либо на огромном дисплее Retina, либо на старом телефоне, лежащем на вершине вереска, пытаясь подключиться к GPRS-соединению.

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

28. Никакого мелкого шрифта.

Они заставляют вас нервничать и вызывают подозрения.

Не стесняйтесь показать пользователю, что вы знаете и уважаете его права и свои обязанности.

29. Выберите наиболее подходящий способ встраивания изображений.

Существуют следующие варианты, каждый из которых имеет свои плюсы и минусы: 29.1 Внешние изображения: с точки зрения скорости отправки этот вариант наиболее предпочтителен.

Внешние картинки ничего не весят и не усложняют структуру письма.

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

Кроме того, сервер, на котором они расположены, должен быть достаточно надежным, чтобы при открытии письма не приводило к зависаниям из-за недоступности изображения.

Используйте их, когда изображения не являются обязательными.

29.2 Встроенные картинки.

Отправлено вместе с содержимым письма.

Они усложняют структуру письма и увеличивают его вес, но могут быть довольно большими и обычно отображаются по умолчанию.

29.3 URI данных.

Содержимое изображения вставляется непосредственно в тег.

Они не усложняют структуру букв; они почти всегда отображаются в веб-почте, иногда даже с отключенными изображениями.

Как правило, они имеют ограничение по размеру и подходят для небольших иконок.

29.4 Картинки шрифтов.

Изображения символов Юникода из стандартных шрифтов или встроенных пользовательских шрифтов.

Уникальное свойство — их можно масштабировать вместе с текстом.

Они практически ничего не весят. Может отображаться некорректно в зависимости от версии операционной системы и установленных обновлений, устройства, почтовой программы или службы.

30. Во всех URI обязательно указывайте протокол (http://, https:// или mailto:); использование URI без протокола, например «http://example.com/», недопустимо и может привести к зависанию сообщения в некоторых почтовых приложениях из-за попыток доступа к сети, использования протоколов, отличных от перечисленных не рекомендуется, так как может быть отрезан фильтрами.

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

Что делать, если, несмотря на выполнение всех рекомендаций, письма по-прежнему не доходят до пользователей? Обратитесь в службу поддержки получателей электронной почты – как правило, такие проблемы решаются оперативно.

О проблемах с доставкой на адреса, обслуживаемые серверами Mail.Ru, вы можете писать на адрес[email protected]. Не забудьте максимально подробно описать проблему — сообщения об ошибках, тексты сообщений о невозможности доставки, логи сервера и другая техническая информация будут очень полезны.

К сожалению, формат статьи не позволяет мне подробно описать каждую из рекомендаций или дать подробную инструкцию по настройке, но если у вас есть технические вопросы, я буду рад ответить на них в комментариях.

Теги: #почта mail.ru #Вёрстка писем #рассылки