Pull to refresh

Comments 27

Спасибо за полезную информацию! В среди аббревиатур DMARC, DKIM и SPF не хватает ARC. Очень интересно, планирует ли почта mail.ru внедрение Authenticated Received Chain (http://arc-spec.org/)?

ARC еще не принят в качестве стандарта и мы активно участвуем в его обсуждении и разработке в рамках M3AAWG и IETF. Пока наша позиция в основном критическая — дело в том, что ARC фактически является заменой вайтлистов по DKIM, при этом он критикуется за избыточное использование криптографии (там где она бесполезна или не требуется для решения задач).

Если кратко — основные проблемы ARC в том, что
1. он требует установления доверия ко всей подписывающей цепочке. Каких-либо способов установления такого доверия сам стандарт не дает. Это планируется решать за счет включения модерируемого списка «доверенных» форвардеров в основные продукты, поддерживающие ARC. По этой причине ARC мало кому помогает и не является полноценной замной используемых сейчас списков доверенных форвардеров и совсем никак не помогает администраторам небольшого списка рассылки, например — т.к. алгоритм попадания в публикуемые списки не известен, а без него ARC бесполезен.
2. Используемый алгоритм цепочки подписей в ARC бесполезен, т.к. нужен для транзитивного доверия (как в цепочке сертификатов, например), которого в ARC нет, поэтому вся эта цепочка не имеет смысла, было бы достаточно только подписи последнего
хоста в цепочке.
3. ARC добавляет очень много информации к заголовкам сообщений. Это может привести к проблемам во многих MTA, где есть ограничения на размер заголовка.

Но, разумеется, если ARC будет внедрен и будет поддерживаться основными MTA/менеджерами списков рассылки, мы так же реализуем его поддержку.
Кстати, на днях опубликовали вот такой драфт по Lenient DKIM:
www.ietf.org/id/draft-vanrein-dkim-lenient-00.txt
Мысль гораздо правильней чем ARC, она позволяет отследить какие изменения были внесены в подписанное письмо. Но боюсь, что в реальности ARC будет принят, а Lenient DKIM нет, т.к. за ARC'ом стоят бородатые стандартописатели.
z3apa3a пишу Вам, может донесете до поддержки (на запрос поддержка не ответила)
Если Вы не можете ни как донести или ответить, можете отклонить комментарий.
У вас есть сервис postmaster, к нему подключен домен, и все рекомендации выполнены. Согласно статистики postmaster спама нет, но по логам почтового сервера спама где то 10%.
Почему получаются разные данные?
В статистике Postmaster@ отображаются только письма, имеющие DKIM-авторизацию вашего домена, независимо от того, с какого адреса они были отправлены, возможно, что не принимаемые письма не имеют DKIM подписи или она некорректна, это же может быть и причиной их классификации как спама.
Но лучше отправить информацию, включая логи на адрес postmaster@corp.mail.ru.
На Вас в письме можно сослаться что бы ответили :)?
Или должны обработать письмо и ответить?
Этот адрес обрабатывается вручную и на все письма обязательно отвечают.
Не, тут бы более подробный разбор бы не помешал. Допустим есть домен example.com в качестве «письменного», т.е. user@example.com. Сервер на mail.example.com, прописан в MX.

Получаем:
example.com.  IN TXT "v=spf1 mx a ~all"


Получается нужна ещё:
*.example.com.  IN TXT "v=spf1 -all"


Или для mx делается отдельная разрешающая?
Все еще сложнее. В идеале, если у вас есть зона, например:
example.com. IN MX 10 mail.example.com.
example.com. IN A 1.2.3.4
mail.example.com. IN A 1.2.3.5
www.example.com. IN A 1.2.3.4

Сервер mail.example.com имеет каноническое имя mail.example.com и сконфигурирован использовать его в команде HELO. Тогда нужны следующие записи:

; основная SPF-запись
example.com. IN TXT "v=spf1 mx a ~all"
; SPF-запись для HELO
mail.example.com. IN TXT "v=spf1 a -all"
; SPF-запись экранирующая www.example.com (при условии что это имя не каноническое и не используется в HELO)
www.example.com. IN TXT "v=spf1 -all"
; экранирующий SPF-wildcard
*.example.com. IN TXT "v=spf1 -all"


совсем в идеале вместо

example.com. IN TXT "v=spf1 mx a ~all"

лучше использовать

example.com. IN TXT "v=spf1 ip4:1.2.3.4 ip4:1.2.3.5 ~all"
А почему одна экранирующая wildcard запись не покрывает mail и www?
Так работают вайлдкарды в большинстве DNS-серверов — вайлдкард возвращается только если нет записи с таким именем любого типа. Если не сделать отдельную экранирующую запись для www, то запрос TXT-записи www.example.com. вернет 0 записей данного типа даже при наличии вайлдкарда, потому что есть A-запись www.example.com.

Для mail.example.com нужна разрешающая запись, которая разрешит серверу mail.example.com использовать это имя в команде HELO.
Да, увидел там «a». Теперь понятно, спасибо за пояснение.
Самое страшное — когда получатель почты, какая-нибудь серьезная компания, типа банка, не принимает почту от твоего сервера, ссылаясь на то, что они (выбрать по вкусу) считают контент спамом / используют кривой RBL / в твоем SPF нашли что-то, чего не поняли / попробовали проверить DKIM, и не осилили — и письмо вместо чем принять, и пометить как «возможно спам», просто не берут. А твой, скажем, главбух не может до банка дописаться — и материт всех.

И банк этот, считая, что у них все секурно, а) никогда не сменит политику «просто так», и б) не оставляет никакого вариант отправить им письмо. Ну как никакого — с gmail то же самое до дих дойдет успешно.

И никакого шанса достучаться до них и сказать — парни, вы бы свой сетап проверили, что ли — нет.
Да, такая проблема есть. По стандартам, для этих целей должен быть работающий адрес postmaster@ или abuse@, вы можете попробоваться связаться по ним. Ответ сервера 5xx так же может содержать информацию (например URI) с контактами для решения проблемы. Но, к сожалению, на практике postmaster@ часто не работает или работает, но никем не читается.

Вообще любая автоматическая фильтрация почты это зло, но реальность такова, что спам составляет более 90% писем. Отказываться от автоматической фильтрации значит перекладывать фильтрацию на пользователя, и это не вариант, т.к. пользователь ошибается нисколько не реже (может удалить или засунуть в папку спама нужное письмо). Кроме того, 15 минут рабочего времени в день, потраченные на разбор спама это итоговые потери, сравнимые с потерями по больничным листам. Поэтому надеяться, что кто-то откажется от спам-фильтрации, не стоит.

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

Когда работающая для людей компания не принимает от людей почту — это как-то неправильно.

Банки часто консервативны, потому что неотключение идиотского фильтра — это по инструкции, и сотрудника не накажут, а отключение — это мало-ли-что. И перебороть это слабо получается. Даже критика в соцсетях тут странно выглядит, пока PR передаст проблему, пока технари разберутся, пока напишут и согласуют ответ «мы работаем ради безопасности ваших денег, а вы, раз так, злобные спаммеры!» — проще банк сменить.
Банки в соцсетях отвечают очень быстро, но если это не простая задача, то ответ их будет столь же бесполезен как и любой другой способ связи. Т.е. — не могу достучаться === они передадут ваше письмо. А вот «почините спамфильтр» будет «мы работаем над этим». Через год напомните, и будет «все еще работаем».
Есть хороший сервис для DMARC, dmarcian.com.
Там все отчеты по каждому домену, в удобном виде, с графиками и т.д.
> Боле того, даже если бы все домены публиковали SPF, а все получатели запрещали получение писем без SPF-авторизации, это вряд ли привело бы к снижению уровня спама

Может, поясните широким народным массам, почему? Большинство спамерских писем с поддельными адресами отправителя не пройдут проверку SPF.

На практике полагаться на успех или неуспех проверки SPF нет смысла только потому, что у ощутимого количества легитимных отправителей до сих пор толком не настроены средства аутентификации (SPF, DKIM, DMARC и т.д.)
Потому что сейчас стоимость регистрации какого-нибудь домена $0, домена в приличной зоне — $2-3. Стоимость хостинга DNS $0. Поэтому в спаме все чаще используются не подменные адреса, а свежие домены с нулевой историей, которые регистрируются под одну рассылку, причем рассылки проводятся очень быстро (за время порядка 5 минут) с высокой интенсивностью. На таких рассылках может быть и SPF и DKIM и DMARC.
С точки зрения современных антиспам-систем это одно и то же — что на письмах с отсутствующей авторизацией, что на письмах с доменов без истории нельзя использовать репутацию домена и работают другие классификаторы и как правило эти рассылки не создают проблем. А вот для фильтров по SPF, DNSBL, простых сигнатурных антиспам-систем и т.п. такие рассылки часто «невидимы».
Нулевой домен, без истории легитимных писем — в greylist. Не самое элегантное решение, но вполне действующее с не очень большими потерями.

О своём: судя по статистике спама, приходящего на корпоративные адреса, нулевых доменов там минимум. В основном старый приём — вставка случайных адресов, которые одним SPF режутся на раз.
Если у спамера нет задачи реально доставить письма — то поможет все что угодно. Мы по статистике DMARC до сих пор видим миллионные рассылки, которые реально доходят только до единичных ящиков, на которых вообще нет спам-фильтров, потому что DMARC в отличие от SPF дает возможность строго фильтровать поддельные письма.

Против качественного спама грейлистинг сам по себе не спасет, вы просто получите спам на несколько минут позднее, если вы не умеете выделять рассылки, их классифицировать и накапливать репутацию по отдельным рассылкам. Грейлистинг используется чтобы накопить информацию о рассылке и ее классифицировать.
То что вы не видите «качественного» спама скорей всего означает, что на вас его еще не таргетировали, и вы просто неуловимый Джо.
Ну, не всё так просто — совокупно спама к нам сыплется до 200 писем в сутки на ящик, а строго фильтровать его затруднительно: когда должны доходить сообщения на адрес той же тех.поддержки, особо не пошикуешь. У клиентов в настройках аутентификации доменов обычно творится тихий ужас, и строгая фильтрация по DMARC (т.е., по итогам проверок DKIM/SPF) многие такие письма убила бы в зародыше. «Низзя!».

Фильтрация спама — занятие затейливое, решаем комплексно, естественно. В целом ситуация приемлемая.

Кроме того, в данной ситуации быть Неуловимым Джо на редкость приятно.
Здравствуйте! Почему ваш postmaster.mail.ru/security не видит DKIM у доменов, у которых DNS hosting provider — Cloudflare? У доменов используется стандартный селектор dkim. Любыми стандартными инструментами он определяется (кроме вашего):

host -t txt dkim._domainkey.mydomain.tld.
dig -t txt dkim._domainkey.mydomain.tld.
nslookup -q=txt dkim._domainkey.mydomain.tld.
В статье есть ответ на ваш вопрос:
DKIM проверяется по статистическим данным за предыдущий день и будет показываться только при наличии переписки с ящиками на Mail.Ru в предшествующий день или ранее.
И еще вопрос. Почему от спамерских рассылок вашей пресс-службы, приходящих с адреса pr@corp.mail.ru, нельзя отписаться? Там нет ссылки на отписку. Я не знаю, как мои адреса попали в их базу (это точно без моего участия), но избавиться от их спама не удается категорически.
Лучше задать этот вопрос на pr@corp.mail.ru, а если это не решит проблемы — напишите мне в личку, т.к. к содержанию статьи он нерелевантен.
Как я вижу, упоминание «спамерских рассылок вашей пресс-службы» кому-то категорически не нравится (видимо, вашей же пресс-службе?). Мой вопрос на эту тему сразу начали минусовать. :) Попал в точку, очевидно. :)
Sign up to leave a comment.