company_banner
13 октября 2014 в 14:05

Технические рекомендации к почтовым рассылкам tutorial



«Даже если вы получите какое-нибудь письмо, вы не сможете его прочитать»
(Марк Твен)

Мы уже писали о том, как правильно делать рассылки, улучшать их качество и эффективность. Приводили метрики, на основе которых строится репутация отправителя. Рассказывали об интерфейсе Постмастер 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. Не забывайте как можно полнее описать проблему – очень помогут сообщения об ошибках, тексты сообщений о невозможности доставки, журналы серверов и прочая техническая информация.

К сожалению, формат статьи не позволяет детально расписать каждую из рекомендаций или дать подробные инструкции по настройке, но если у вас есть технические вопросы – с удовольствием на них отвечу в комментариях.
Автор: @z3apa3a
Mail.Ru Group
рейтинг 632,36
Строим Интернет

Комментарии (25)

  • 0
    Очень неправильно сливать в один список, и рекомендации для админов серверов (DNS, MAIL и прочих), и та часть советов которую чаще выполняют вообще не администраторы, по верстке писем, лучше разделите на два раздела вашу статью, чтобы легче было определить в какой части нужно читать тем или иным специалистам.
    • +3
      Привет, на самом деле статья разделена на три раздела: для администраторов, для разработчиков (авторов скриптов рассылок) и для верстальщиков. Выделил пожирнее, кому что предназначается.
    • 0
      Очень удобно, когда все это делает один человек.
  • 0
    Скажите пожалуйста, почему ваш Postmaster не заводится без DKIM, в то время как недавно появившийся «Почтовый офис» от Яндекса прекрасно работает без этой подписи?
    • 0
      Мы не учитываем в репутационных метриках домена статистику по неподписанным письмам, поэтому и не отображаем ее. Подробнее о репутации было в прошлой статье.
      Поэтому, если хочется, чтобы домен накапливал репутацию — DKIM подпись обязательно должна присутствовать. Иначе эта репутация может быть использована спамерами.
      • 0
        Насчет репутации — понятно. Но репутация это одно, а статистика по рассылкам — немного другое. Согласитесь, даже без подписи писем, я как отправитель имею право посмотреть процент прочитанных или отправленных в спам писем
        • +1
          Если нет подписи, ваш домен будут подделывать в спам-письмах, вместе со всеми типичными заголовками. И вы в одной цифре будете видеть усредненные значения по отправленным в спам и прочитанным по вашим рассылкам и по спам-рассылкам с поддельным адресом. Отделить одно от другого будет невозможно.

          Не поленитесь, внедрите DKIM и DMARC. Это просто и дает гарантию, что с вашего домена кроме ваших писем ничего не придет, никакие спамеры/конкуренты не попортят его репутацию. Профит и вам и окружающим.
          • –3
            В общем это заградительная мера, направленная на популяризацию DKIM, а не обусловленная техническими причинами. Спасибо, примерно так я и думал.
  • +1
    Твои бы советы и Джонсону с Джонсоном, а то они вот image
    • 0
      Вот да, с таким и боремся. Причем проблемы вылазят у рассыльщиков любого размера, очень мало кто письма генерирует вообще без «помарок». Кодировка это настоящая беда — мы и другие крупные почтовые службы в сомнительных случаях кодировку текста автодетектим. А рассыльщик на каком-нибудь одном ящике посмотрел, что все читается и шуранул по всем пользователям.
  • 0
    А вы можете прокомментировать, насколько все эти правила соблюдаются широко распространенными службами рассылок (например, MailChimp), пожалуйста?
    • 0
      По-разному соблюдают, в среднем заметно лучше, чем крупные организации, которые делают рассылки сами себе. Я попрошу коллегу, которая работает с рассыльщиками прокомментировать поподробней и возможно с примерами чуть позже.
  • +1
    Вот статья про DKIM в Exchange.
    Как я понял, бесплатно:
    habrahabr.ru/post/229401/
    • 0
      Спасибо, добавлю ссылку в текст.
  • 0
    Интересует практика. Например ваша (честная, неспамерская) рассылка попала в спам в gmail. Те google ее стал фильтровать. Ваши действия?
    • 0
      Я и не заметил, что пишу это в блоге mail.ru Тем не менее, вопрос все равно актуален. Не думаю, что с gmail или mail.ru можно оперативно решать такие вещи.
      • +1
        С mail.ru вполне можно решать такие вещи, есть адрес abuse@corp.mail.ru, с которого обязательно ответят и достаточно быстро.
        С гуглом посложнее. Мы достаточно крупный почтовый сервис, у нас есть свои каналы решения проблем, но более мелким почтовым сервисам придется искать решение самостоятельно. Гугл, например, очень подозрительно относится к ссылкам, по которым можно отслеживать переходы пользователей (с уникальным идентификатором в каждом письме) и сокращателям ссылок и у них достаточно разные требования к разным категориям писем. Здесь вам гораздо более полезные советы могут дать коллеги из компаний со схожим профилем по доставляемости.
        Такие проблемы достаточно часто обсуждаются на профильных конференциях, например Mailing Day.
  • 0
    Простите, но ваш спам-фильтр — просто издевательство. Когда вы начинаете блокировать всю почту с домена, и ваши «девочки» пишут откровенную чушь в ответ на заявки, все ваши посты здесь с описанием того что нужно сделать — просто плевок в нашу сторону. Особенно с учётом того, что эти рекомендации давно внедрены.
    • 0
      Помимо технических рекомендаций к рассылкам, есть еще административные требования и репутация. Если вы не валидируете адреса подписчиков или рассылаете то, что пользователи считают спамом, то соблюдение технических рекомендаций не поможет.
      Если вы все выполняете, то никаких проблем с общением с abuse@corp.mail.ru у вас не будет.
      • +1
        Если вы не валидируете адреса подписчиков или рассылаете то, что пользователи считают спамом, то соблюдение технических рекомендаций не поможет.

        Валидируем. Пользователь занёс в спам — больше ему ничего и никогда не отправляем. Пользователь неактивен (не существует) — аналогично. Рассылаем только уведомления о новых сообщениях на сервисе.
        При этом, как оказалось, пользователи удивлены тем, что письма вдруг стали попадать в папку спам. Это не выдуманная история. Сегодня, через личные сообщения пользователь обратился и задал вопрос, почему мы перестали присылать письма о новых сообщениях. В процессе выяснилось, что почта аккуратно лежит в спаме. Получается, что нужные письма по мнению mail.ru — НЕ нужные.

        Далее, второй день не можем ответить пользователям на заявки, оставленные через форму обратной связи. Ответы отправляются с другого домена, никаких автоматических рассылок, только человеческие ответы.
        И, сейчас, буквально несколько минут назад, «Мария С.» заявляет, что в наших письмах цитируется спам.
        Пожалуйста, покажите, где в сообщении с Error code: ED74EA72995C1AB447258D13EC06CB4F61DA7147159660CFE69F7F79EC4D68BA35DBF9F3236A521C0D276A520D94825A. ID: 0000000400009B82179455C8. содержится цитата спама?
        Да, более того, дайте уже чёткое определение того, что такое «цитируется спам»?

        • 0
          Обязательно разберемся. Но по поводу бесполезности статьи, цитата:

          Что делать, если, несмотря на соблюдение всех рекомендаций, письма все-таки не доходят до пользователей? Обращайтесь в службы поддержки получателей писем — как правило, подобные проблемы решаются оперативно. О проблемах доставки на адреса, обслуживаемые серверами Mail.Ru, можно писать на abuse@corp.mail.ru. Не забывайте как можно полнее описать проблему – очень помогут сообщения об ошибках, тексты сообщений о невозможности доставки, журналы серверов и прочая техническая информация.


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

          Но если вы напишете на abuse@corp.mail.ru и укажете, что проблема произошла с рассылками, то не придется сталкиваться с ответами от роботов или шаблонами.
          • 0
            Понял. Спасибо.

            Раньше почта с «сайтового» домена периодически раз в пол года блокировалась и после обращения на abuse@corp.mail.ru достаточно оперативно всё решалось.

            В целом, отвечают оперативно, не спорю. Но почему, вдруг, стали блокироваться 100% не автоматические письма с домена (не «сайтового»), который используется только для ответов на обращения через обратную связь остаётся загадкой. Я проверил, специально на свой адрес mail.ru отправил письмо с этого домена — не прошло. Это странно, потому что писем в ответ на заявки пользователей с адресами ваших почтовых доменов не больше 2-х десятков с день, а, обычно, и того меньше.

            Ну, вот, пока писал, ответили, что могу проверить работоспособность хождения почты. Проверил, да работает. Спасибо.
            Дальше буду ждать ответ по другому домену.
            • 0
              ОК, обращайтесь.

              Если возникают какие-то систематические проблемы (например блокировка не первый раз) — не забывайте и об этом сообщать и указывать на прошлые обращения, лучше с номерами тикетов, особенно если они были с других адресов. Тогда обязательно решим проблему как-то более глобально или посоветуем как избежать ее в дальнейшем.
      • 0
        Кстати, вот здесь:
        help.mail.ru/mail-help/rules/technical
        приведены некие правила и лимиты репутации.
        Я сейчас проверил, лимиты не превышены, «репутация» за декабрь = 0,80%
        Лимит:
        до 500,000 1,3%

        Однако, начиная со вчерашнего дня 99% почты «вероятно» спам. При этом, ни структура самих писем-уведомлений не менялась, ни валидация несуществующих не отменялась с нашей стороны, но позавчера доставляемость была 100%, а сегодня менее 1%
        • +1
          Аналогично на нескольких наших доменах именно за последние сутки. Спам не рассылаем. Пользователи в шоке. Будет рекомендовать им переходить на другую почту.

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

Самое читаемое Разработка
Интересные публикации