Вопросы Теги

spamassassin имеет ложные срабатывания с электронными письмами, исходящими с адресов коммутируемого доступа

Я в основном счастливый администратор spamassassin (3.4.0-6) + exim4 (4.84.2), настройки для фильтрации спама на стороне сервера в системе Debian / jessie.

Недавно пользователь сообщил о ложных срабатываниях. При более внимательном рассмотрении выясняется, что легальные электронные письма были

  1. отправлены с некоторого коммутируемого IP-адреса (который занесен в несколько черных списков)
  2. и переданы на почтовый сервер интернет-провайдера отправителя (с использованием любой аутентификации, которую они имели в place), который
  3. затем доставил письмо на мой почтовый сервер
  4. , который пометил почту как СПАМ, потому что один из IP-адресов в заголовках «Получено» был занесен в черный список

spamassassin соответствовал нескольким правилам черного списка ( RCVD_IN_BL_SPAMCOP_NET , RCVD_IN_SBL_CSS , RCVD_IN_SORBS_SPAM , RCVD_IN_SORBS_WEB ). Note that the email only got positive scores due to the IP being blacklisted.

The relevant header in the email that triggered the SPAM flagging is:

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)

now given that:

  • the mail server(s) of the sender's ISP are all clean (seemingly not listed in any blacklist)

  • I obviously don't know how the sender proves their email legit to their ISP, but I assume that some form of authentication does take place

... I think that spamassassin should not have flagged that email as spam.

To be precise: my gut feeling tells me that spamassassin should properly add SPAM score for mails directly received from blacklisted IP addresses. However, if the mail went through a "clean" MTA (the ISP's mail servers), sa should assume that "they" (the ISP) has taken proper measures to ensure the legitimacy of the email.

Since I'm running my setup for quite some time and haven't had many false positive reports until now, I wonder:

  • Is the above expected behaviour?

  • If not, is the problem on my side (e.g. i misconfigured my spam analysis to take parts of the received-chain into account which it shouldn't. if so, where should i look for a fix?)

  • If not, is the problem on the ISPs side? (e.g. they should better conceal the broken IP addresses from which they accepted authorized emails. if so, should i direct complaints to them?)

0
задан 20 April 2017 в 15:30
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)')
0
ответ дан 5 December 2019 в 08:18

Эти правила SpamAssassin соответствуют, если Ретранслятор в Полученных заголовках сообщения был указан ...

В то время как RCVD_IN_SORBS_WEB работает ближе к тому, что вы хотели бы, чтобы все они делали:

check проверяет IP-адрес последнего ненадежного реле против DNSBL, поддерживаемый SORBS.

Если вы не доверяете этим тестам, вы всегда можете изменить оценки правил . оценка RCVD_IN_BL_SPAMCOP_NET 0 не добавляет никаких оценок, если тест соответствует, в результате чего тест будет полностью отключен.

Spamassassin не должен тестировать только последнюю Получено: , поскольку это заголовок Получено от вашего собственного MTA, который мог бы провести такой же тест и фактически отклонить почту с совпадающего IP-адреса вместо того, чтобы пометить ее как СПАМ.

В Postfix 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- занесенный в черный список заголовок 

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 , содержащих «перехваченные» сетевые блоки.

0
ответ дан 5 December 2019 в 08:18

Теги

Похожие вопросы