Грейлистинг (актуален ли сейчас?)

[Bizdelnick]

Я не особо занимаюсь администрированием почтовиков. Держу один сервер для личных нужд. Для борьбы со спамом давно настроил gross (в связке с postfix). Со своей задачей он вполне справляется, за исключением того, что не умеет пробивать адреса IPv6 по DNSBL. Но разработка давно заглохла. Задался вопросом, не стоит ли перейти вместе с очередным обновлением системы на что-то другое. Однако выяснилось, что ничего особо нового в репах Debian за последние годы не добавилось, да и вообще, похоже, новых средств грейлистинга не появляется, выбор между старым и очень старым.
В связи с этим вопрос к почтовым админам: а оно вообще имеет смысл? Может быть, я отстал от жизни, и таким примитивным способом уже не отсеять >90% спама? Кто что использует?

[Bizdelnick]

Посмотрел, что люди пишут в разных местах. Пишут, конечно, разное.
Аргументы «за»:

• грейлистинг позволяет отсеять бо́льшую часть спама с минимальными затратами ресурсов;
• для пользователя в абсолютном большинстве случаев никаких неудобств не создаётся.

Аргументы «против»:

• создаются задержки при доставке сообщений с сервера, попавшего в серый список (до тех пор, пока он не перейдёт в белый;
• бывают ложные срабатывания в случае автоматической отправки писем скриптами, например, для подтверждения регистрации или восстановления пароля на каком-нибудь сайте;
• крупные почтовые сервисы могут предпринимать повторные попытки отправки письма с разных IP-адресов, которые будут последовательно попадать в серый список, в итоге письмо может так и не быть доставлено.

Многие пишут, что разумным компромиссом является грейлистинг только адресов, не прошедших проверку SPF. Мне кажется, что подход gross по крайней мере не хуже: в серый список адреса отправляются только тогда, когда они ранее были замечены в рассылке спама и засветились в DNSBL. Разумной также представляется проверка по DNSWL, чтобы точно не грейлистить адреса известных почтовых сервисов.

[Aliech]

Можно свои пять копеек? Грейлист - хороший компонент для комплексной проверки. Но без неё - такое себе решение. Применять грейлист стоит, как мне кажется, только как последний шанс для тех, кто уже набрал должное кол-во подозрений.

Вас какой-нибудь spamassasin/rspamd религиозно не устраивают?

[Bizdelnick]

Можно свои пять копеек?

Нужно! Я для того тему и создавал, чтобы хоть чьё-то мнение услышать.

Грейлист - хороший компонент для комплексной проверки. Но без неё - такое себе решение. Применять грейлист стоит, как мне кажется, только как последний шанс для тех, кто уже набрал должное кол-во подозрений.

Отчасти согласен: да, это должен быть только один из элементов проверки. Но никак не последний, а, наоборот, первый или второй-третий после DNSBL и/или SPF, чтобы отсеять явный треш (через него явно пройдёт спам, разосланный со всяких хотмейлов и гуглодоков). Для тех писем, которые пройдут, можно уже применять более затратные методы анализа с залезанием в содержимое письма и, в дальнейшем, уже не отбрасыванием писем, а складыванием их в папку для спама.

Вас какой-нибудь spamassasin/rspamd религиозно не устраивают?

В теории устраивают. Но на практике на моём личном мини-сервачке я обхожусь без них, хватает gross и opendmarc. Посыпется массово спам — прикручу. В серьёзных кейсах, конечно, что-то такое строго необходимо.

P. S. А, да, как элемент отсеивания спама у меня также работает обязательное требование TLS. Тоже всякий треш не пролезает. Но не могу рекомендовать всем: иногда и нужные письма не пробиваются, например, от дебиановского багтрекера.

Добавлено (01:57):

Offtopic

А вот такой забавный спам иногда падает на гмыловский ящик:

Код: Выделить всё

Received: from e.armgs.team (e.armgs.team. [45.84.130.32])
        by mx.google.com with ESMTPS id 26-20020a17090600da00b0086ce37e0daasi13750031eji.789.2023.02.05.21.42.35
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 05 Feb 2023 21:42:44 -0800 (PST)
Received-SPF: pass (google.com: domain of a.zaytsev@digital.gov.ru designates 45.84.130.32 as permitted sender) client-ip=45.84.130.32;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@digital.gov.ru header.s=mailru header.b=Vsydudfd;
       spf=pass (google.com: domain of a.zaytsev@digital.gov.ru designates 45.84.130.32 as permitted sender) smtp.mailfrom=a.zaytsev@digital.gov.ru;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=digital.gov.ru

Адрес в некоторых DNSBL фигурирует, но грейлист, скорее всего, проскочит.
Пользуясь случаем, хочу передать привет to Mr. Anton ZAYTSEV, Senior Specialist, Ministry of Digital Development, Communications and Mass Media of the Russian Federation, a.zaytsev@digital.gov.ru

[SwapON]

В небольшой конторке ~ на 70 сотрудников вообще ничего антиспамного не прикручивал. Так как все средства борьбы со спамом слишком часто ложно срабатывают. Решил бороться штатными средствами постфикса. Прописал в конфигах элементарные вещи типа проверки на основе данных, переданных в HELO/EHLO hostname, запрет представляющихся, у которых нет A и МX записи, blacklist и whitelist.

Whitelist необходим для рукожопых админов, у которых не совсем правильно настроен почтовый сервер, но письма от них принимать надо.
Blacklist - вот тут я подкинул себе геморра. Настроил all_in ящик, куда дублируется вся входящая почта, ну и первые пару недель отлавливал очевидный спам и в ручную (целыми доменами) заносил в blacklist (кусок списка). На сегодняшний день в этом списке порядка ~ 150 записей ну и в принципе за день 1 - 2 нежелательных письма если проскочит, то в этот же списочек они и заезжают. Также пользователям наказал, при получении вероятного спама, для принятия мер информировать меня.

Считаете меня извращенцем...? По итогу данной настройки все говно-рассылки REJECT'утся без всяких spamassassin и прочей лабуды, а адресованные сотрудникам письма доходят!

[Aliech]

В теории устраивают. Но на практике на моём личном мини-сервачке я обхожусь без них, хватает gross и opendmarc. Посыпется массово спам — прикручу. В серьёзных кейсах, конечно, что-то такое строго необходимо.

Ну короч. Главный финт ушами в том, что на личном сервачке трафика особенного нет. А значит и SA не будет проблемой. У него отлично можно залезть в правила и поправить "вес" фильтров. И да. У него, если ничего не путаю, даже был грейлист встроенный. Но грейлист - зло, последний раз баловался им лет десять назад. Но, вроде бы, в SA что-то для этого было. Мб не в самом SA, а в exim-sa. Так что тут я не уверен.

Rspamd - вещь в себе. Как-то работает. Перешёл с SA. И там тоже был, вроде бы, встроенный грейлистинг.

Настоятельно советую посмотреть на эти два инструмента. Мне SA даже больше нравится, я его научился за десяток лет "готовить", но вот уже год как решил переехать на rspamd. И ещё НИ РАЗУ ничего не докрутил в последнем. Хз как так...

А грейлистинг... Грейлистинг - он иногда задерживает ОЧЕНЬ ожидаемые письма. Что сильно ограничивает его применение в реальном мире.

И да, в том же руенете до сих пор есть сервера без TLS, или, даже, с TLS 1.0. В корпоративном секторе. Так что смотреть на TLS... ну такое.

Добавлено (02:22):

Blacklist - вот тут я подкинул себе геморра. Настроил all_in ящик, куда дублируется вся входящая почта, ну и первые пару недель отлавливал очевидный спам и в ручную (целыми доменами) заносил в blacklist (кусок списка). На сегодняшний день в этом списке порядка ~ 150 записей ну и в принципе за день 1 - 2 нежелательных письма если проскочит, то в этот же списочек они и заезжают. Также пользователям наказал, при получении вероятного спама, для принятия мер информировать меня.

Так получилось, что с началом некоторых событий, трафик со стороны некоторых стран СНГ режется. Стран, где главные бото-фермы были, которые использовали спамеры именно для работы по РУ-сегменту. Там ребятки так шустро меняли домены в ротации, что вы бы в первые же дни отказались от подобной практики в пользу автоматизированных средств.

Ну или у вас почта не очень "засвечена". Что тоже плюс, в какой-то мере.

[SwapON]

Ну или у вас почта не очень "засвечена". Что тоже плюс, в какой-то мере.

Доменному имени у почты не менее 15-ти лет!
Возможно я в данный момент выгляжу как лягушка, которая хвалит своё болото, но в своё время ознакомившись с документацией постфикса, а именно:
smtpd_helo_restrictions
smtpd_sender_restrictions
smtpd_recipient_restrictions
smtpd_data_restrictions
smtpd_client_restrictions
и применив это на практике, в сторону других MTA я уже не смотрю.

[Bizdelnick]

Грейлистинг - он иногда задерживает ОЧЕНЬ ожидаемые письма. Что сильно ограничивает его применение в реальном мире.

Да, я об этом писал. Но можно снизить частоту этого "иногда" до "почти никогда".

в том же руенете до сих пор есть сервера без TLS, или, даже, с TLS 1.0.

В смысле — даже клиентом TLS быть не умеют? С трудом верится. Для этого ведь и настраивать ничего не надо.

В корпоративном секторе.

Мне казалось, там уже довольно чёткое разделение на тех, у кого почта в облаках, и тех, у кого админы умеют эту почту настраивать.

Добавлено (13:33):

крупные почтовые сервисы могут предпринимать повторные попытки отправки письма с разных IP-адресов, которые будут последовательно попадать в серый список, в итоге письмо может так и не быть доставлено.

Кстати, забыл написать: не знаю, как другие грейлистеры, но gross грейлистит сразу целые подсети (по умолчанию — по маске /24, а допиленный мной — и IPv6-префиксы /64 (не многовато ли?); то и другое настраивается). Как минимум отчасти это решает проблему, а в сочетании с DNSWL практически сводит к нулю.

[Aliech]

В смысле — даже клиентом TLS быть не умеют? С трудом верится. Для этого ведь и настраивать ничего не надо.

Ну вы верьте во что хотите, а лог mail.err мониторьте на предмет записей, типа "клиент отключился во время STARTTLS". И "рукопожатие не задалось". Не помню точный оригинальный текст сообщений, извините.

Мне казалось, там уже довольно чёткое разделение на тех, у кого почта в облаках, и тех, у кого админы умеют эту почту настраивать.

Кривые облака даже у уважаемых провайдеров бывают, где может быть Exchange настроенный сертифицированным специалистом на поддержку вплоть до TLSv1.2, а шифры доступны только от TLSv1.1. И всё, в логах сообщения, как выше, вторые сутки важное письмо не приходит.

Если столкнётесь с такой бодягой, то не стоит снижать защищенность своего сервера, добавляя слабые шифры, снижая минимальный уровень TLS и т.д. У Postfix есть возможность запретить клиентам (по маске ip) какие-либо команды. Например, запретить тем, кто не может в STARTTLS, делать тот самый STARTTLS. Есть и второй путь: пойти на контакт с админами "с той стороны". Но это, обычно, не срабатывает.

И да, TLS он, на данный момент, may, а не must.

[Bizdelnick]

Ну вы верьте во что хотите, а лог mail.err мониторьте на предмет записей, типа "клиент отключился во время STARTTLS". И "рукопожатие не задалось". Не помню точный оригинальный текст сообщений, извините.

Заглядываю иногда, давно такого не видел. Но у меня выборка всё же маленькая. И да,

не могу рекомендовать всем

You can ENFORCE the use of TLS, so that the Postfix SMTP server announces STARTTLS and accepts no mail without TLS encryption, by setting "smtpd_tls_security_level = encrypt". According to RFC 2487 this MUST NOT be applied in case of a publicly-referenced Postfix SMTP server. This option is off by default and should only seldom be used.

Но есть нюанс: если не требовать TLS, сервер уязвим к MITM. Да и есть ли смысл сейчас ориентироваться на RFC 1999 года? На мой взгляд, это его требование устарело.

[Aliech]

Но есть нюанс: если не требовать TLS, сервер уязвим к MITM.

Только если применять DNSSEC, TLSA. Ну и софт "с той стороны" должен их уметь и не игнорировать. В обратном случая защита будет иллюзорной.

[Bizdelnick]

Ладно, в плане TLS, конечно, более кошерным является использование MTA-STS, а не обязательное требование TLS. Просто я параноик, а отсечение части спамеров — лишь побочный эффект.
Но это всё офтоп. Мы тут про грейлистинг. И тему я создавал, главным образом, чтобы понять, стоит ли браться за допиливание gross, интересен ли он кому-то, или, может быть, имеет смысл запилить что-то аналогичное с немного другим функционалом. Или всё же есть готовые легковесные решения, о которых я не в курсе.

[Aliech]

MTA-STS

Я о нём и забыл, признаться. Но тоже... другая сторона по-прежнему обязана в DNSSEC и, теперь уже, MTA-STS. А все надежды на то, что "другая сторона обязана", на моей практике, выходят сильно не состоятельными.

Для себя решил, что реально лютую я только в части аутентификационных данных пользователей. Но это мой выбор.