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

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

Что должно быть у "честной" рассылки:

1. Прозрачность процесса: Рассылка должна осуществляться только по явному требованию или согласию пользователя (opt-in)
1. Почтовый адрес, указанный пользователем, должен быть обязательно явно подтвержден самим пользователем.
2. В каждом письме должны присутствовать четкие инструкции, как отписаться от рассылки, при этом процесс отписки не должен требовать от пользователя сложных действий, таких как восстановление пароля, регистрация и т.п.
3. В каждом письме должен явно присутствовать адрес, на который подписка осуществляется

2.
1. Тема сообщения должна быть понятна пользователю и не должна вводить его в заблуждение
2. В поле "от кого" должен быть указан реально существующий почтовый адрес, ассоциированный с источником рассылки. Если поступающие на этот адрес сообщения обрабатываются роботом, то в ответ должны придти ясные и четкие инструкции, позволяющие связаться с вашей службой поддержки.
3. Все ссылки в тексте должны указываться в виде полного доменного имени (недопустимо использование в качестве ссылок IP-адресов и url-encoded доменных имен).

3. Требования к программному обеспечению:
1. ПО, осуществляющее рассылку, должно проверять полученные ответы. В случае, если принимающий сервер отвечает, что такого пользователя не существует, адрес должен быть удален из базы, или должны быть предприняты другие меры по приостановке рассылки.
2. В письме должны присутствовать стандартные заголовки, используемые при массовых или автоматических рассылках: Precedence: (bulk, junk или list), list-unsubscribe, и т.п.) c работающими ссылками, позволяющими отписаться от рассылки автоматически.
3. Заголовки и формат сообщения должны соответствовать требованиям rfc 2822 и требованиям стандартов MIME, в частности, в сообщении должны присутствовать корректные заголовки Date, message-id, x-mailer
4. Для каждой части сообщения стандартным способом должна быть указана кодировка, и эта кодировка должна совпадать с реально использованной. Сообщения с текстами в двух кодировках одновременно недопустимы.
5. Если рассылка осуществляется в формате html, недопустимо использование java script, activeX и других потенциально опасных объектов

4. Корректность сетевой идентификации


Хост, осуществляющий рассылку, должен иметь постоянный ip-адрес с корректно настроенным обратным ресолвом, этот ip-адрес должен быть делегирован в соответствии со стандартами, при этом контакты, указанные в whois, должны быть актуальными и доступными. Для корректной идентификации доменное имя должно быть содержательным, а не являться автоматическим адресом на подобие x.y.z.w-in-addr-apra или dsl-4-3-2-1.provider.net.
Кроме того, очень желательно, чтобы хост, осуществляющий рассылку:
* использовал средства авторизации почтовых серверов, такие как SPF.
* отличался от хоста, посылающего обычную корреспонденцию. Если это невозможно, желательно, чтобы доменное имя в поле from или sender отличалось от используемого для регулярной переписки и указывало на источник корреспонденции. Например, для домена example.ru желательно, чтобы уведомления о новых сообщениях в форуме отправлялись из домена forum.example.ru, подписка на новости сайта из домена news.example.ru и т.п.