Я в основном счастливый администратор spamassassin (3.4.0-6) + exim4 (4.84.2), настройки для фильтрации спама на стороне сервера в системе Debian / jessie.
Недавно пользователь сообщил о ложных срабатываниях. При ближайшем рассмотрении оказывается, что подлинные электронные письма были
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 (почтовые серверы ISP), sa должен предположить, что «они» (ISP) приняли надлежащие меры для обеспечения легитимности электронной почты.
Поскольку я запускаю свою установку довольно долго и до сих пор не получал много ложных срабатываний, мне интересно:
Это ожидаемое поведение?
Если нет, проблема на моей стороне (например, я неправильно сконфигурировал свой анализ спама, чтобы учесть части полученной цепочки, чего не должно быть. Если да, то где мне искать исправление?)
Если нет, то проблема на стороне интернет-провайдеров? (например, им следует лучше скрывать сломанные IP-адреса, с которых они принимали авторизованные электронные письма. Если да, следует ли мне направлять им жалобы?)
Я нашел решение, которое делает то, что я хочу. Вместо того, чтобы корректировать оценки, эти правила черного списка можно настроить так, чтобы пропустить первый (ненадежный) переход,
Вот внесенные мной изменения (изменения просто добавляют -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 содержащие "угнанные" сетевые блоки.