Вимоги Яндекса до чесних розсилок

Цей документ відображає подання компанії «Яндекс» про чесні розсилки. Він не є офертою і не тягне за собою жодних зобов’язань з боку компанії та її поштової служби перед сервісами, які здійснюють масові розсилки.

Документ заснований на практиці найбільших провайдерів і поштових служб, що склалася, відповідає нормам і рекомендаціям ASTA, а також «Нормам користування мережею». Алгоритм поділу розсилок та спаму є ноу-хау компанії, яка не публікується і не обговорюється.

Що має бути у чесної розсилки:

1. Процес підписки:
   

   • (Обов’язково) Розсилка повинна здійснюватися тільки за явною вимогою або згодою одержувача.
   • (Обов’язково) Адреса одержувача розсилки має бути явно підтверджена самим одержувачем.
   • При додаванні до розсилочного листа адреси одержувачів повинні пройти валідацію.
2. Процес відмови від підписки:
   
   • (Обов’язково) У кожному листі мають бути дано чіткі інструкції про те, як відписатися від розсилки. При цьому процес відписки не повинен вимагати від одержувача складних дій, як відновлення пароля, реєстрація або авторизація. Одержувач повинен мати можливість відписатися від розсилки протягом 10 хвилин.
   • У тілі листа має бути явно вказана адреса передплатника.
   • (Обов’язково) У листі має бути використаний заголовок list-unsubscribe, оформлений за стандартом RFC. При переході на посилання з цього заголовка користувач повинен бути моментально відписаний від розсилки.
   • (Обов’язково) Для відписки необхідно вказувати тільки працюючі посилання.
3. Заголовок листа:
   

   • Тема повідомлення повинна бути зрозуміла користувачеві та не повинна вводити його в оману.
   • Тема повідомлення має бути однаковою всім листів однієї розсилки.
   • (Обов’язково) У полі Від кого має бути вказана реально існуюча електронна адреса, асоційована з джерелом розсилки.
   • Якщо повідомлення, що надходять на цю адресу, обробляються роботом, то у відповідь повинні надходити ясні та чіткі інструкції, які дають змогу зв’язатися з вашою службою підтримки.
4. Коректність мережної ідентифікації:

   • (Обов’язково) Програмне забезпечення, що здійснює розсилку, має перевіряти отримані відповіді. Якщо сервер, що відповідає, що зазначеного користувача не існує, то розсилка за цією адресою повинна бути припинена.
   • (Обов’язково) Хост, який здійснює розсилку, повинен мати постійну IP-адресу з коректно налаштованим зворотним DNS-запитом. При цьому реєстраційні дані власника домену мають бути актуальними та доступними публічно за протоколом WHOIS.
   • Для коректної ідентифікації доменне ім’я має бути змістовним, а не автоматичною адресою на кшталт x.y.z.w-in-addr-arpa або dsl-4-3-2-1.provider.net.
   • Хост, який здійснює розсилку, повинен відрізнятися від хоста, що надсилає звичайну кореспонденцію.
   • (Якщо попередня вимога нездійсненна.) Доменне ім’я в полі From має відрізнятися від доменного імені, що використовується для регулярного листування, і вказувати на джерело кореспонденції. Наприклад, для домену example.ru повідомлення про нові повідомлення на форумі повинні надсилатися з домену forum.example.ru, а підписка на новини сайту — з домену news.example.ru і т.п.
   • (Обов’язково) Всі повідомлення повинні бути підписані за допомогою ключа DKIM або DMARC (або має бути налаштований запис домену SPF).
5. Інші вимоги:

   • Не можна змінювати інформацію про відправника або цільову сторінку для будь-яких посилань у листах.
   • Не рекомендується використовувати скорочені посилання.
   • Всі посилання в тексті повинні вказуватися як повне доменне ім’я: не можна використовувати як посилання IP-адреси або перекодовані імена доменів (URL Encoded).
   • (Обов’язково) У листі повинні бути стандартні заголовки, які використовуються при масових або автоматичних розсилках — наприклад, Precedence: bulk (junk, list, list-unsubscribe та т. і.). Усі посилання в них повинні дозволяти автоматично відписатися від розсилки.
   • Заголовки та формат повідомлення повинні відповідати вимогам RFC 5322 та стандарту MIME. Крім того, у повідомленні мають бути коректні заголовки Date йMessage-ID.
   • Для кожної частини повідомлення має бути вказане кодування, що реально використовується. Повідомлення з текстами у двох кодуваннях одночасно неприпустимі.
   • Якщо розсилка здійснюється у форматі HTML, у листі неприпустимо використовувати елементи JavaScript, ActiveX та інші потенційно небезпечні об’єкти.

Також ви можете ознайомитись з Принципами взаємодії Яндекса с іншими мережами.

Джерело: https://yandex.ru/support/mail/web/spam/honest-mailers.html