spamassassin имеет ложные срабатывания с электронными письмами, исходящими от адресов удаленного доступа
Я в основном счастливый администратор spamassassin (3.4.0-6) + exim4 (4.84.2), настроенный для фильтрации спама на стороне сервера в системе Debian/jessie.
Недавно пользователь сообщил о ложных срабатываниях. При ближайшем рассмотрении выясняется, что законные электронные письма были
- отправлено с некоторого коммутируемого IP-адреса (который указан в нескольких черных списках)
- передается на почтовый сервер интернет-провайдера отправителя (используя любую аутентификацию, которую они имели), которая
- затем доставил письмо на мой почтовый сервер
- который пометил почту как СПАМ, потому что один из IP-адресов в заголовках "Получено" был занесен в черный список
spamassassin соответствует правилам черного списка (RCVD_IN_BL_SPAMCOP_NET
, RCVD_IN_SBL_CSS
, RCVD_IN_SORBS_SPAM
, RCVD_IN_SORBS_WEB
). Обратите внимание, что электронная почта получила только положительные оценки из-за того, что IP занесен в черный список.
Соответствующий заголовок в электронном письме, который вызвал пометку СПАМА:
Received: from [10.126.95.175] (unknown [109.126.64.1])
by smtpfilter1.public.one.com (Halon) with ESMTPSA
id ee1f1e82-251c-11e7-8f0e-b8ca3afa9d73;
Wed, 19 Apr 2017 16:26:25 +0000 (UTC)
Теперь, учитывая, что:
почтовые серверы провайдера отправителя все чистые (по-видимому, не указаны ни в одном черном списке)
Я, очевидно, не знаю, как отправитель доказывает свою электронную почту законным для своего интернет-провайдера, но я предполагаю, что некоторая форма аутентификации имеет место
... Я думаю, что spamassassin не должен был помечать это письмо как спам.
Чтобы быть точным: мое интуитивное чувство говорит мне, что spamassassin должен правильно добавить оценку СПАМа для писем, напрямую полученных с занесенных в черный список IP-адресов. Однако, если почта проходила через "чистый" MTA (почтовые серверы провайдера), sa следует предположить, что "они" (провайдер) предприняли надлежащие меры для обеспечения легитимности письма.
Так как я уже довольно долго запускаю свою установку и до сих пор не получал много ложных положительных отзывов, мне интересно:
Вышеуказанное ожидаемое поведение?
Если нет, то является ли проблема моей стороной (например, я неправильно настроил свой анализ спама, чтобы принять во внимание части полученной цепочки, чего не следует делать. Если да, то где мне искать исправление?)
Если нет, то проблема на стороне интернет-провайдеров? (например, они должны лучше скрывать сломанные IP-адреса, с которых они принимали авторизованные электронные письма. Если это так, я должен направлять им жалобы?)
2 ответа
Я нашел решение, которое делает то, что я хочу. Вместо того, чтобы корректировать оценки, эти правила черного списка можно настроить так, чтобы пропустить первый (ненадежный) переход,
Вот изменения, которые я сделал (изменения просто добавляют -notfirsthop
суффикс к выражениям; например zen
становится zen-notfirsthop
пропустить проверку на исходящий IP):
header RCVD_IN_SBL eval:check_rbl_sub('zen-notfirsthop', '127.0.0.2')
header RCVD_IN_SBL_CSS eval:check_rbl_sub('zen-notfirsthop', '127.0.0.3')
header RCVD_IN_BL_SPAMCOP_NET eval:check_rbl_txt('spamcop-notfirsthop', 'bl.spamcop.net.', '(?i:spamcop)')
Эти правила SpamAssassin совпадают, если в списке " Полученные" заголовки сообщения есть список "Реле"...
RCVD_IN_BL_SPAMCOP_NET
... в Spamcop DNSBL, автоматический список блокировки на основе времени.RCVD_IN_SBL_CSS
для Spamhaus CSS, кажется, больше не существует, ноRCVD_IN_SBL
делает то же самое для Spamhaus SBL, который включает в себя компонент CSS.
В то время как RCVD_IN_SORBS_WEB
работает ближе к тому, что вы хотели бы, чтобы они все сделали:
check проверяет IP-адрес последнего ненадежного ретранслятора на DNSBL, поддерживаемый SORBS.
Если вы не доверяете этим тестам, вы всегда можете скорректировать оценки правил. score RCVD_IN_BL_SPAMCOP_NET 0
не добавляет баллы, если тест соответствует, в результате чего тест будет полностью отключен.
Spamassassin не нужно проверять только последние Received:
заголовок, как это Received
от вашего собственного MTA, который мог бы выполнить тот же тест и фактически отклонил письмо от совпадения IP-адреса вместо того, чтобы пометить его как СПАМ.
В постфиксе main.cf
эквивалентные ограничения получателя будут:
smtpd_recipient_restrictions =
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client dnsbl.sorbs.net
И с Exim 4.x в acl_rcpt
ACL в exim.conf
:
deny message = Access denied - $sender_host_address\
listed by $dnslist_domain\n$dnslist_text
dnslists = sbl.spamhaus.org : \
bl.spamcop.net : \
dnsbl.sorbs.net
Если вы используете Exim dnslists
в warn
режим, вы могли бы имитировать RCVD_IN_*
правила стиля только для последней доставки MTA, добавив X-blacklisted-at
заголовок
warn message = X-blacklisted-at: $dnslist_domain
dnslists = sbl.spamhaus.org : \
bl.spamcop.net : \
dnsbl.sorbs.net
а затем оценивать наличие (или содержание) этого заголовка в Spamassassin вместо RCVD_IN_*
:
header LAST_RCVD_BLACKLISTED exists:X-blacklisted-at
score LAST_RCVD_BLACKLISTED 10.0
Обратите внимание, что эти списки отклонений могут быть слишком широкими для того, что вам действительно нужно, например, для dnsbl.sorbs.net
является агрегатной зоной, содержащей почти все доступные зоны SORBS. Прежде чем отклонить или даже пометить на основе этого списка, вы должны ознакомиться с назначением каждого списка и решить, насколько агрессивным вы хотите быть.
Лично я бы больше доверял SPF, DMARC и байесовской фильтрации и был бы очень чувствителен к доверию DNSBL, то есть только с использованием списков с IP-адресами, которые, конечно, используются только для спама, например smtp.dnsbl.sorbs.net
для открытых серверов ретрансляции SMTP или edrop.spamhaus.org
содержащие "захваченные" сетевые блоки.