Pull to refresh

Comments 30

Жаль, что «Яндекс» и «Рамблер» вообще не чешутся в этом смысле. Если бы все основные русские почтовики сделали FBL, то мир стал бы заметно лучше :)
«5. Подождать, пока вашу заявку проверят»
А что именно проверяете? DKIM есть, домен подтвержден. Что еще вам нужно?
В данный момент система FBL работает в режиме тестирования, это по сути основная причина. Как только все будет работать хорошо эта проверка скорее всего будет убрана.
Василий, а такое уточнение — если мы рассылаем, например, с домена my.mail.ru, то система попросит для FBL указать ящик на @my.mail.ru
Почему такое ограничение? Почему бы не разрешить использовать произвольный эмейл адрес? Или хотя бы адрес в том же домене mail.ru?
Мы думаем над этим, но пока по некоторым соображениям решили сделать такое ограничение. Кажется, это не очень усложняет жизнь рассыльщиков — у отправителя же должен быть доступ к почте домена.
Могут быть исключения. Например, если поддомен делегирован сервису рассылок, что достаточно частая практика.
gmail с некоторого времени вежливо предлагает после нажатия на кнопку «Mark as spam» отписаться от рассылки, хороший паттерн я считаю
В статье как раз упоминается — это в случае, когда отправитель письма сформировал заголовок List-Unsubscribe.
Да, это заголовок List-Unsubscribe. На практике gmail далеко не для всех рассыльщиков на него реагирует (как минимум необходим тот же DKIM) — о чем, собственно, явно предупреждает. Но проставлять его все равно стоит.
А есть ли какие-то варианты для Microsoft Exchange? Он, как известно, использует не DKIM, а SPF.
При добавлении домена DNS-проверка работает некорректно.

Во первых, непонятно описание

Иногда интерфейс управления DNS не позволяет использовать символ @ как имя домена/поддомена. В этом случае используйте имя вашего домена с точкой на конце, например: «test.ru.».

Если следовать написанному, получится запись test.ru..test.ru Вероятно имеется ввиду, что нужно оставить пустое поле name.

Я на всякий случай добавил оба варианта — подозреваю, что это из-за того, что чекер проверяет первую полученную TXT запись (в моем случае SPF), и вполне логично ругается.
Вы имеет ввиду немного другое. Точка в конце имени домена имеет специальное значение, она говорит DNS-серверу, что ничего дописывать не надо. Т.е. запись

test.ru. IN A 127.0.0.1

в зоне test.ru полностью эквивалентна записи

@ IN A 127.0.0.1

Другой вопрос, если вы используете графический интерфейс — там могут быть приняты разные соглашения, например в Microsoft'овских инструментах для управления DNS действительно для добавления записей, совпадающих с именем зоны необходимо оставить поле имени пустым.
Как часто уходят письма с уведомлениями о действии пользователя? (spam\unspam)
В соответствии с принятыми практиками FBL, письма уходят практически в реальном времени, с минимальными задержками.
Вопрос — могут ли пользователи злонамернно использовать этот механизм, чтобы навредить какому-либо сервису?

Например, пользователь получает «неприятное» письмо (напоминание о непогашенном долге, соощение о блокировке на форуме и т.п.).
В отместку он жмет «это спам». И получается, что честный сайт, который все сделал хорошо, позаботился о пользователях, чтобы все уведомления до них доходили, подписал DKIM`ом всю почту получает «минус» в репутацию. Ни за что. Даже не за рассылку.

Понятно, что почтовая система учитывает не единичный случай, а статистику за какое-то время. Очень вероятна ситуация, когда все было хорошо, но в какой-то день этот процент резко вырастет. Например, в конце месяца бухгалтерия рассылает уведомления должникам, или случилось какое-то общественно-политическое событие и на форуме столкновение противников и сторонников. Для успокоения модераторы прописали бан массе народу.
То есть получается, что любой популярный ресурс всегда будет в зоне риска.
Я недавно вдруг понял, что раньше, когда мне надоедала какая-то рассылка (на которую я сам подписывался), я избавлялся от нее, нажимая кнопку «Спам». Т.к. в большинстве случаев отписка от рассылок требовала авторизации на сайте, перехода в меню, шаманства с несколькими галочками и т.п.

Теперь вот задумался…
Вот Google это сделал очень правильно — если это рассылка и отправитель позаботился о корректной обработке, то при нажатии на кнопку «Спам» произойдет отписка от рассылки — все хорошо. Если же отправитель на парился, то рассылка будет считаться обычным письмом и обработается как спам. Все вроде бы корректно.

Но как быть с единичным письмами, даже рассылаемыми массово?
Что значит попросить отписать меня от напоминаний об оплате? А если сервис не отпишет? И вообщем-то имеет право, если пользователь ему денег должен. Заносить такого в спам-лист?
Фактически, поддержка FBL позволяет реализовать то же самое. Если «отправитель позаботился о корректной обработке» — то он в ответ на нажатие «Это спам» отпишет от рассылки. Единичным письмам (как и крупынм рассылкам) это репутацию не испортит — она изменяется плавно и с учетом многих внутренних факторов.

Поддержка заголовка List-Unsubscribe (то, что есть у gmail) тоже есть в наших планах, но никаких принципиально новых возможностей она не даст — все это уже сейчас можно сделать через FBL.
Поддержка заголовка позволит в автоматическом режиме обрабатывать отписку.
Но, в принципе, да, можно и через FBL в ручном режиме.
Так а что мешает обрабатывать FBL автоматически? Это такие же письма стандартного формата. Скрипт для его обработки можно на любом языке написать.
То есть вытащить заголовки и обработать их?
Там вроде больше ничего не надо.
Так это и есть правильное поведение. Если вам что-то не нравится — нажимайте «это спам». Сознательный отправитель получит FBL и отпишет вас от рассылки. Несознательный — не будет отписывать, и если таких пользователей будет много — постепенно понизит свою репутацию и ему придется обратить на это внимание.
Если репутация сервиса пойдет вниз — это значит реальные пользователи недовольны. Мы оперативно блокируем ботов и не учитываем их мнение. Представить же массовый сговор реальных пользователей, чтобы «насолить» сервису сложно.
Вот у меня такой вопрос: мы хотим переделать рассылки на нормальный механизм с поддержкой DKIM, чисткой списка и прочего.
Если я сейчас сделаю ключи и проведу рассылку, я получу массу проблем из-за того, что у меня список пользователей еще старый, но все нажатия на «спам» уже обрабатываются всерьез. Мусорные акки я удалю, но получается, что все равно попаду в бан из-за них.
Как вы порекомендуете постепенно внедрять нормальные механизмы рассылок?

Если я сделаю ключи только для отдельных серверов, будет ли почта приниматься с других? Или оно автоматом будет считаться отправленной нелегально?
Спасибо.
В «спам» попадают письма не из-за того, что у домена рассыльщика плохая репутация в postmaster, решение о блокировке принимается независимо от репутации, хотя и коррелирует с ней, потому что в расчет берутся примерно те же факторы, в частности количество жалоб. Если вы сделаете «грязную» рассылку с нарушением правил или по списку без opt-in, то проблемы будут независимо от того, будет использован DKIM и домен зарегистрирован в postmaster или нет, репутация в postmaster не связана с этим решением напрямую. Рассылки «влетят» в блеклисты по каким-либо параметрам, после чего вынести их будет довольно сложно. Но вот если рассыльщик «легально» зарегистрирован в постмастере, корректно оформляет рассылки и подписывает письма, то вероятность того, что будет заблокирована легальная рассылка существенно меньше.
Можно вам еще вопрос?
Подключил DKIM, mail.ru его видит, нормально понимает и принимает почту. Показал в интерфейсе, что письма с таким ключем распознаны. Но при этом возле домена висит предупреждающий знак «Статистика отсутствует — проверьте DKIM.»
Может из-за того, что пока не везде внедрено? И большая часть писем ходит без подписи?
Должен пропасть на следующий день после получения первых писем, подписанных DKIM.
Самый сок — это что письмо от noreply@corp.mail.ru с темой «Verifying address for mail.ru FBL» — падает на гугле в спам :))
Ребят, как дела с FBL? Планируется уже нормальный режим работы, когда ящик задается для блока айпи адресов, как принято, а не на том же домене?
Only those users with full accounts are able to leave comments. Log in, please.