Efeitos de restrições no Postfix

Question

Minha pergunta é semelhante a esse aqui , mas eu estou rodando uma nova versão do Postfix e as respostas não responderam a minha pergunta.

Estou executando um servidor Debian Jessie com o Postfix 2.11.

Até agora entendi que o Postfix tem essas verificações:

• smtpd_client_restrictions
• smtpd_helo_restrictions
• smtpd_sender_restrictions
• smtpd_relay_restrictions
• smtpd_recipient_restrictions

Pelo que eu leia , o Postfix os processará na ordem mencionada.

1. Agora, minha pergunta é: o que acontece quando uma entrada em alguma restrição corresponde a OK ? Isso significa que o Postfix irá ignorar as verificações restantes de esse *_restriction específico ou irá pular all *_restrictions todos juntos?

2. Existem outros resultados que podem ocorrer além de OK e REJECT ou quais são os valores apropriados para essas verificações?

3. Quais são os outros _restrictions usados, se a maioria dos tutoriais menciona apenas smtpd_client_restrictions ou smtpd_recipient_restrictions ?

O que eu quero alcançar é isto:

• Bloquear clientes do MTA que são conhecidos por enviar spam (por exemplo, IPs dinâmicos ou outros clientes listados em listas negras) e / ou não são compatíveis com o RFC (por exemplo, endereço sem FQDN, etc.).
• Ao mesmo tempo, permite que determinados clientes ignorem isso com base em uma lista de permissões
• Permitir que apenas clientes autenticados por SASL retransmitam emails para outros servidores e não a todos os domínios permitidos
• Bloqueie os clientes que estão se passando por outros servidores (ou seja, SPF), incluindo os anteriormente permitidos (em outras palavras, permitir que os servidores da lista branca entreguem somente seus e-mails)
• Adicione um atraso a novos servidores para melhorar ainda mais a proteção contra spam (Postgrey). Isso já funciona muito bem e também criei as listas de permissões necessárias para ele.

Agora, se você responder à pergunta 1 de qualquer maneira, colocar todos os cheques em uma das *_restrictions mencionadas acima provavelmente não funcionará, pois uma lista de permissões substituiria a verificação de SPF, por exemplo.

Portanto, minha configuração é algo assim:

# basic configuration (myorigin, mydomain, etc.)

smtpd_helo_required = yes

smtpd_client_restrictions = check_client_access hash:/etc/postfix/blackwhitelists/whitelisted_client_addresses, 
    check_reverse_client_hostname_access hash:/etc/postfix/blackwhitelists/blacklisted_reverse_hostnames, 
    reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net,
    reject_rbl_client dnsbl.sorbs.net, reject_unknown_client

smtpd_helo_restrictions = permit_sasl_authenticated, permit_mynetworks,
    reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname,
    reject_unknown_helo_hostname, reject_unauth_pipelining

smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks,
    check_sender_access hash:/etc/postfix/blackwhitelists/blacklisted_sender_addresses

smtpd_relay_restrictions = permit_sasl_authenticated, permit_mynetworks,
    reject_unauth_destination

smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks,
    reject_unauth_destination, reject_unauth_pipelining, 
    check_sender_access hash:/etc/postfix/blackwhitelists/whitelisted_sender_addresses, reject_non_fqdn_sender,
    reject_unknown_sender_domain, check_policy_service unix:private/policyd-spf, 
    check_policy_service unix:/var/spool/postfix/postgrey/socket

smtpd_etrn_restrictions = permit_sasl_authenticated, permit_mynetworks, reject

# more basic configuration

Como você pode ver, muitas opções se repetem agora, porque eu não tenho certeza, se eu precisar delas em outras restrições também. Ao todo, eu consideraria uma grande bagunça também.

Também estou executando o SpamAssassin para o e-mail que passa em todas essas verificações.

    

Answer 1

Esses _restrictions se aplicam às informações disponíveis durante a fase específica do diálogo SMTP, ou seja:

• smtpd_client_restrictions são aplicados à conexão inicial (IP / FQDN)
• smtpd_helo_restrictions são aplicados ao comando HELO / EHLO do cliente
• smtpd_sender_restrictions são aplicados ao comando MAIL FROM
• smtpd_recipient_restrictions são aplicados ao comando RCPT TO

smtpd_relay_restrictions controle de retransmissão para domínios de terceiros.

Todos os itens dentro de cada uma dessas restrições são avaliados na ordem em que são fornecidos e, se algum item corresponder ao processamento dessa sequência de restrição, será interrompido e uma ação especificada será executada. A lista completa de ações possíveis está disponível em access(5) man page.

Se a ação for ACCEPT ou qualquer uma de suas avaliações de sinônimos, procederá ao conjunto de regras da próxima etapa. Se a ação for REJECT (ou seus irmãos), um erro será retornado ao remetente e nenhum processamento adicional será feito.

Seu conjunto de regras parece bom, mas é muito restritivo e propenso a erros - por exemplo, servidor DNS do remetente para baixo e nenhum e-mail seria aceito a partir deles, as restrições HELO / EHLO banirão servidores Exchange mal configurados e alguns outros remetentes esotéricos lá fora, etc.

Da minha experiência, eu recomendaria configurá-lo para o mínimo e substituir todas as RBLs, HELO, checagens e verificações reversas com o daemon de serviço de política de pontuação, por exemplo. %código%. Lá você pode ajustar sua política aplicada a todas essas pequenas coisas e tomar ações diferentes com base em um complexo de parâmetros e não em um único hit.