Comments 7
Сложности с грейлистом довольно большие наблюдаю я сейчас.
Во-первых, многие (те кто базируется на решениях MS) внедрили у себя защиту от спама на основе генерации липовых sender. Каждая посылка или перепосылка сообщения будет вестись от некого липового сендера с псевдорандомным local part. Таким образом грейлистить по sender стало трудновато.
Во-вторых, есть проблемы с большими сетями: mail.ru, gmail.com, yandex.ru и особенно outlook.com имеют кучу выходных MTA. Outlook.com особенно неприятен, поскольку всегда перепосылает с другого сервера, в отличии от yandex.ru, например. Правило /19, о котором говорится в статье, мне кажется не самым удачным. С одной стороны сетка у тех же MS может быть и шире /19, а с другой могут начаться ложно положительные срабатывания, когда две машины спамера находятся в пределах одной /19 сети. Короче баланс тут поймать очень сложно.
И в-третьих, проблема согласования времени повторов. К сожалению нет такого стандрата: грейлист. Это просто грязный хак. Для отправляющего сервера это выглядит как defer — временная проблема доставки. И тайминги повтора определяются каждым поставщиком индивидуально. Например все крупные игроки, стараются перепослать письмо очень быстро с этого же MTA (кроме outlook.com). Я так думаю, что с их бешенным поток им крайне не выгодно раздувать очередь, поэтому письма имеют короткий ретри на том же MTA, а потом падают на дополнительные MTA специализирующиеся на повторной доставке. А таймаут грейлиста обычно стоит на 5 минут. И в случае с yandex.ru, например, за эти пять минут он уже раза три к вам стукнется, плюнет и уйдет уже минут на десять. Это вносит раздражение для персонала. На деле, если не угадать с таймаутом, то письмо может прийти и через полчаса и через час.
Я с этим боролся следущим образом.
Для начала был составлен список условно доверенных доменов: это крупные игроки плюс все те домены, на которые хоть раз писал один из наших сотрудников (роботы не в счет).
Если приходит письмо с сендером из этого домена, то я снача проверяю spf на строгое положительное совпадение (~all разумеется не учитывается). Если совпало, то грейлист отключается. Если spf нет, то я проверяю на строгое соответствие MX или A записи для ip. Если и это не помогло, то тогда все это падает в greylist и собирается для оценки в качестве еженедельного отчета.
В качестве ключа я нынче использую домен, взятый из sender, ip MTA и rcpt. Т.е. из классики я выкинул только local part of sender.
Rspamd делает грейлистинг не только по sender/ipnet, но и по partial body hash. Так что никаких проблем с gmail или кривыми клиентами не будет.
Ну и есть, конечно же, whitelist'ы по spf/dkim/dmarc: https://rspamd.com/doc/modules/whitelist.html
С грейлистингом и рейтлимитами вполне себе можно передать удаленному MTA, через сколько ему посылать в следующий раз (например, сейчас модуль ratelimit так и делает). Другое дело, что такие сообщения не стандартизованы, хотя об этом идет дискуссия в m3aawg.
Хм. А смысл в таких сообщениях? Как только их стандартизируют спамеры начнут их использовать.
Собственно популярность грейлиста уже многими ботнетами учитывается и если ваш адрес попал в некий узкий лист, то высока вероятность, что повтор будет сделан как надо.
Хм. А смысл в таких сообщениях? Как только их стандартизируют спамеры начнут их использовать.
Ну и пусть используют. Чем им это поможет-то?
Собственно популярность грейлиста уже многими ботнетами учитывается и если ваш адрес попал в некий узкий лист, то высока вероятность, что повтор будет сделан как надо.
Поэтому грейлистинг бесполезен, да?
Простой greylisting в opensmtpd