Estou executando o postfix em um 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]
Em vez de mexer na quarentena, tenho minha instalação do postfix configurada para rejeitar emails RBL e SPFFAIL. Infelizmente, tenho uma empresa da qual preciso receber e-mails que possuem um registro SPF incorreto que está assim há algum tempo. Assim, em vez de e-mail, recebo registros legais como este:
1º de abril 10:41:42 postfix / smtpd redigido [18833]: NOQUEUE: rejeitar: RCPT de us-smtp-delivery-134.mimecast.com [216.205.24.134]: 550 5.7.1: Endereço do destinatário rejeitado: Mensagem rejeitada devido para: falha de SPF - não autorizado. Por favor, vejahttp://www.openspf.net/Why?s=mfrom;id=redacted;ip=216.205.24.134;r=redacted; de=< redigido> para=< redigido> proto=ESMTP helo=< us-smtp-delivery-134.mimecast.com>
A referida empresa não tem um contato que possa corrigir isso em seu site ou em suas informações WHOIS (presumo que um registrante @dnstinations.com [algum fornecedor terceirizado] irá ignorar um e-mail de um terceiro dizendo O DNS está configurado incorretamente).
A primeira vez que recebi esse log em vez de um e-mail, tentei colocar *.mimecast.com na lista de permissões, mas isso não fez diferença, então hoje dei uma olhada no meu main.cf. Vi que a configuração do SPF estava em uma linha diferente das minhas listas de permissões, então pensei que talvez pudesse criar uma lista de permissões específica do SPF separada. Aqui está a aparência do meu main.cf antes:
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
Aqui está o que parece agora:
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
Basicamente, tudo que fiz no main.cf foi adicionar "regexp:/etc/postfix/spf_client_regex," antes "check_policy_service unix:private/policy-spf" no "smtpd_recipient_restrictions" seção.
Também criei /etc/postfix/spf_client_regex com esta entrada (isso parece seguro o suficiente, já que o mimecast é um fornecedor de antispam):
/.*\.mimecast\.com$/ OK
Eu testei isso com postmap -q, obtive o resultado "OK" esperado, executei "postmap /etc/postfix/spf_client_regex" para atualizar tudo o que foi atualizado e recarreguei o postfix. Infelizmente, os e-mails deste remetente continuam bloqueados devido a falhas de SPF.
Portanto, eu esperava que as etapas acima estivessem corretas, considerando que são basicamente as mesmas que as etapas executadas para as regras da lista de permissões na seção smtpd_client_restrictions que fazem com que as regras submit_rbl_client sejam ignoradas, mas não está funcionando. Conforme declarado no título desta postagem: Posso substituir a política SPF usando uma lista de permissões? Como?
Responder1
OK, então li algumas coisas no manual após o comentário dePenhasco Armstronge acho que encontrei uma solução. Primeiro, descobri que, embora smtpd_client_restrictions e smtpd_sender_restrictions permitam a análise de tabelas, nenhum deles permite o processamento de políticas. A seguir, descobri quepolíticas personalizadaspode ser criado, mas isso parecia algo que não deveria exigir que eu aprendesse uma linguagem de programação para resolver, então fiz uma pesquisa que me levou aesta postagemcom algumas reclamações razoáveis sobre um delegado de política SPF específico e explicações sobre como colocar na lista de permissões ambos os delegados de política SPF que estão disponíveis atualmente.
Por sorte, eu já tinha o delegado de política "melhor" instalado, então não precisei mudar isso:
~$ 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]
Em seguida, revisei o arquivo comentado (bem, ele foi compactado no meu caso, então fiz uma cópia para o gunzip e excluí essa cópia quando terminei) e encontrei estes comentários relevantes:
# 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
Com base nisso, parecelista_de_domínios_brancasnão funcionará para mim, pois o comentário diz "definido pela aprovação na verificação do SPF, deve ser colocado na lista de permissões do SPF". Isso parece estranho (se o remetente passasse na verificação SPF do domínio, eu não precisaria colocar na lista de permissões), mas ainda tenho olista brancaopção, então eu encontreidocumentação do mimecast spfe então coletei os IPs usando 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.
Então peguei esses resultados e coloquei-os no arquivo de configuração:
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
Isso não é o ideal, pois permitirá automaticamente que esses IPs sejam enviados de outros domínios e os IPs poderão mudar de mãos, mas é bom o suficiente para minha implementação privada. Como tal, não tentarei aprender a criar meu próprio delegado ou contratar alguém para criar um para mim. Se eu obtiver outro resultado NOQUEUE semelhante, apesar dessas alterações, adicionarei uma observação a esta resposta.