Я использую Postfix на Linode.
Linux redacted 5.3.11-x86_64-linode131 #1 SMP PREEMPT Wed Nov 13 18:51:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
amavisd-new-postfix/xenial,xenial,now 1:2.10.1-2ubuntu1 all [installed]
postfix/xenial-updates,now 3.1.0-3ubuntu0.3 amd64 [installed]
postfix-mysql/xenial-updates,now 3.1.0-3ubuntu0.3 amd64 [installed]
postfix-pcre/xenial-updates,now 3.1.0-3ubuntu0.3 amd64 [installed]
postfix-policyd-spf-python/xenial,xenial,now 1.3.2-1 all [installed,automatic]
Вместо того, чтобы возиться с карантином, я настроил свою установку Postfix на отклонение писем RBL и SPFFAIL. К сожалению, у меня есть компания, от которой мне нужно получать письма, у которой неверная запись SPF, которая была такой уже некоторое время. Таким образом, вместо писем я получаю просто красивые логи, как здесь:
1 апр 10:41:42 отредактировано postfix/smtpd[18833]: NOQUEUE: reject: RCPT from us-smtp-delivery-134.mimecast.com[216.205.24.134]: 550 5.7.1 : Адрес получателя отклонен: Сообщение отклонено из-за: Ошибка SPF - не авторизовано. См.http://www.openspf.net/Why?s=mfrom;id=redacted;ip=216.205.24.134;r=redacted; from=< отредактировано> to=< отредактировано> proto=ESMTP helo=< us-smtp-delivery-134.mimecast.com>
У указанной компании нет контакта, который мог бы исправить эту ситуацию на своем веб-сайте или в информации WHOIS (я предполагаю, что регистратор @dnstinations.com [какой-то сторонний поставщик] проигнорирует электронное письмо от третьей стороны, в котором говорится, что DNS настроен неправильно).
В первый раз, когда я получил этот журнал вместо электронного письма, я попытался добавить *.mimecast.com в белый список, но это не помогло, поэтому сегодня я взглянул на свой main.cf. Я увидел, что конфигурация SPF находится на другой строке, чем мои белые списки, поэтому я подумал, что, возможно, я мог бы создать отдельный белый список, специфичный для spf. Вот как выглядел мой main.cf раньше:
smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access regexp:/etc/postfix/rbl_client_regex, check_client_access hash:/etc/postfix/rbl_client_override, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_policy_service unix:private/policy-spf
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/access, reject_unknown_sender_domain
Вот как это выглядит сейчас:
smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, check_client_access regexp:/etc/postfix/rbl_client_regex, check_client_access hash:/etc/postfix/rbl_client_override, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.sorbs.net
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, regexp:/etc/postfix/spf_client_regex, check_policy_service unix:private/policy-spf
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/access, reject_unknown_sender_domain
По сути, все, что я сделал в main.cf, это добавил "регулярное выражение:/etc/postfix/spf_client_regex," до "служба_проверки_политики unix:private/policy-spf" в "smtpd_recipient_restrictions" раздел.
Я также создал /etc/postfix/spf_client_regex с этой записью (это кажется достаточно безопасным, поскольку mimecast — поставщик антиспам-решений):
/.*\.mimecast\.com$/ OK
Я проверил это с помощью postmap -q, получил ожидаемый результат "OK", запустил "postmap /etc/postfix/spf_client_regex", чтобы обновить все, что обновляется, и перезагрузил postfix. К сожалению, почта от этого отправителя продолжает блокироваться из-за сбоев SPF.
Итак, я ожидал, что шаги выше будут правильными, учитывая, что они в основном такие же, как шаги, предпринятые для правил белого списка в разделе smtpd_client_restrictions, которые приводят к игнорированию правил reject_rbl_client, но это не работает. Итак, как указано в названии этого поста: Могу ли я переопределить политику SPF с помощью белого списка? Как?
решение1
Хорошо, я немного почитал руководство после комментария отКлифф Армстронг, и я думаю, что нашел решение. Во-первых, я обнаружил, что хотя smtpd_client_restrictions и smtpd_sender_restrictions оба позволяют анализировать таблицы, ни один из них не позволяет обрабатывать политики. Затем я обнаружил, чтоиндивидуальные политикиможет быть создана, но мне показалось, что для ее решения не требуется изучать язык программирования, поэтому я провел поиск, который привел меня кэта почтас некоторыми обоснованными нареканиями по поводу одного конкретного делегата политики SPF и объяснениями того, как внести в белый список оба делегата политики SPF, которые доступны в настоящее время.
К счастью, у меня уже был установлен «лучший» делегат политики, поэтому мне не пришлось его менять:
~$ apt list | grep policyd-spf
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
postfix-policyd-spf-perl/xenial,xenial 2.010-2 all
postfix-policyd-spf-python/xenial,xenial,now 1.3.2-1 all [installed,automatic]
Затем я просмотрел прокомментированный файл (ну, в моем случае он был сжат с помощью gzip, поэтому я сделал копию в gunzip, а затем удалил эту копию, когда закончил) и нашел следующие соответствующие комментарии:
# Whitelist: CIDR Notation list of IP addresses not to check SPF for.
# Example (default is no whitelist):
# Whitelist = 192.168.0.0/31,192.168.1.12
# Domain_Whitelist: List of domains whose sending IPs (defined by passing
# their SPF check should be whitelisted from SPF.
# Example (default is no domain whitelist):
# Domain_Whitelist = pobox.com,trustedforwarder.org
Исходя из этого, звучит такдомен_белый_списокне будет работать для меня, так как в комментарии говорится "определено прохождением их проверки SPF, должно быть внесено в белый список SPF". Это кажется странным (если бы отправитель прошел проверку SPF домена, мне не нужно было бы вносить его в белый список), но у меня все еще естьбелый списоквариант, поэтому я нашелmimecast spf документацияа затем собрал IP-адреса с помощью nslookup:
~$ nslookup
> set type=txt
> us._extnetblocks.mimecast.com
;; Truncated, retrying in TCP mode.
Server: 50.116.58.5
Address: 50.116.58.5#53
Non-authoritative answer:
us._extnetblocks.mimecast.com text = "v=spf1 ip4:207.211.30.40 ip4:207.211.30.41 ip4:207.211.30.42 ip4:207.211.30.43 ip4:207.211.30.44 ip4:207.211.30.45 ip4:207.211.30.46 ip4:207.211.30.47 ip4:207.211.30.48 ip4:207.211.30.49 ip4:205.139.111.40 ip4:205.139.111.41 ip4:205.139.111.42 " "ip4:205.139.111.43 ip4:205.139.111.44 ip4:205.139.111.45 ip4:205.139.111.46 ip4:205.139.111.47 ip4:205.139.111.48 ip4:205.139.111.49 ~all"
Authoritative answers can be found from:
mimecast.com nameserver = dns02.mimecast.net.
mimecast.com nameserver = dns03.mimecast.net.
mimecast.com nameserver = dns04.mimecast.net.
mimecast.com nameserver = dns01.mimecast.net.
Затем я взял эти результаты и поместил их в файл конфигурации:
Whitelist = 207.211.30.40, 207.211.30.41, 207.211.30.42, 207.211.30.43, 207.211.30.44, 207.211.30.45, 207.211.30.46, 207.211.30.47, 207.211.30.48, 207.211.30.49, 205.139.111.40, 205.139.111.41, 205.139.111.42, 205.139.111.43, 205.139.111.44, 205.139.111.45, 205.139.111.46, 205.139.111.47, 205.139.111.48, 205.139.111.49
Это не идеально, так как это автоматически позволит этим IP-адресам отправлять с других доменов, и IP-адреса могут переходить из рук в руки, но этого достаточно для моей частной реализации. Таким образом, я не собираюсь пытаться научиться создавать своего собственного делегата или нанимать кого-то, чтобы он создал его для меня. Если я получу еще один похожий результат NOQUEUE, несмотря на эти изменения, я добавлю примечание к этому ответу.