Faça o que fizer, não saia de casa sem:
smtpd_client_restrictions = reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net
Eles estão pegando a maioria para mim sozinhos.
Passei a última semana aprendendo sobre o que o Postfix pode fazer para ajudar a reduzir o spam. Se eu entendi corretamente os diferentes parâmetros de configuração *_restrictions controlam quando as verificações são feitas e então a lista de restrições como permit_mynetworks e check_client_access control o que é verificada . Isso está correto?
Se bem entendi, as verificações são realizadas na seguinte ordem:
Isso está correto? E se eu entendi corretamente, smtpd_delay_reject não afeta a ordem das verificações, mas só afeta quando a rejeição é enviada . Certo?
O parâmetro de configuração smtpd_relay_restrictions não parece estar configurado no meu servidor Plesk 11. Minha versão do Postfix é 2.8.4.
Também notei que algumas das verificações são listadas várias vezes em diferentes parâmetros de configuração. Eles precisam ser listados várias vezes?
Aqui está minha configuração atual:
smtpd_sender_restrictions =
check_sender_access hash:/var/spool/postfix/plesk/blacklists
permit_sasl_authenticated
check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
smtpd_client_restrictions =
permit_mynetworks
smtpd_recipient_restrictions =
permit_mynetworks
check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
permit_sasl_authenticated
reject_unauth_destination
Se bem entendi, seria o mesmo:
smtpd_sender_restrictions =
smtpd_client_restrictions =
smtpd_recipient_restrictions =
permit_mynetworks
check_sender_access hash:/var/spool/postfix/plesk/blacklists
permit_sasl_authenticated
check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
permit_mynetworks
check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
permit_sasl_authenticated
reject_unauth_destination
O arquivo de listas negras está vazio. Os arquivos no_auth têm isto:
/^/ PREPEND X-No-Auth: unauthenticated sender
e o arquivo no_relay tem isto:
/^/ PREPEND X-No-Relay: not in my network
Se bem entendi, os dois últimos adicionam os cabeçalhos a todos os e-mails que ainda não são permitidos.
Verificações repetidas
O Postfix executa a verificação novamente quando é listado várias vezes? Ou o Postfix sabe que já fez essa verificação? Se as verificações são realizadas várias vezes, isso parece um desperdício. Se eles não forem executados várias vezes, os cabeçalhos no_auh / no_relay serão adicionados adequadamente em todos os casos?
Missing smtpd_relay_restrictions
Excerto do Retransmissão SMTP do Postfix e controle de acesso
NOTE: Postfix versions before 2.10 did not have smtpd_relay_restrictions. They combined the mail relay and spam blocking policies, under smtpd_recipient_restrictions. This could lead to unexpected results. For example, a permissive spam blocking policy could unexpectedly result in a permissive mail relay policy.
Outro trecho:
Some people recommend placing ALL the access restrictions in the smtpd_recipient_restrictions list. Unfortunately, this can result in too permissive access.
Portanto, não quero listar todas as restrições em smtpd_recipient_restrictions , mas ter várias restrições e as mesmas verificações sob diferentes restrições é confuso. É seguro usar apenas smtpd_recipient_restrictions e smtpd_relay_restrictions e ignorar o cliente, helo, remetente?
Lista negra
Essa lista negra não está no começo da lista? Se o remetente fizer parte da minha rede e puder autenticar, devo realmente bloquear com base no email do remetente? No momento, a tabela está vazia, mas não tenho certeza de qual componente do Plesk pode adicionar endereços de e-mail a essa tabela. Também seria contra o RFC que exige 100% de entrega para os endereços postmaster @ e abuse @.
Em /etc/postfix/main.cf
#smtpd_client_restrictions =
#smtpd_helo_restrictions =
#smtpd_sender_restrictions =
smtpd_relay_restrictions =
permit_mynetworks
check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
permit_sasl_authenticated
check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
reject_unauth_destination
smtpd_recipient_restrictions =
check_recipient_access pcre:/etc/postfix/custom/recipient_checks.pcre
check_client_access cidr:/etc/postfix/custom/sinokorea.cidr
check_sender_access hash:/var/spool/postfix/plesk/blacklists
Em /etc/postfix/custom/recipient_checks.pcre
# Always accept mail to postmaster@ and abuse@
/^postmaster@/ OK
/^abuse@/ OK
# Reject all mail sent to mailapp.ourdomain.com
# except for certain specific recipients
# and bounce messages which may use VERP
if /@mailapp\.ourdomain\.com$/
!/^(?:validuser|anothervalid|bounces(?:\+.+)?)@/ REJECT
endif
Eu encontrei exemplos que têm o @ que escapou nas expressões regulares. Não é um personagem especial, é?
Minha configuração proposta iria realizar se eu quisesse?
(Nota para si e para qualquer outro usuário do Plesk lendo isto - Uma tarefa cron pode ser necessária para restaurar regularmente as alterações no arquivo main.cf, pois algumas ações do Plesk parecem sobrescrever este arquivo.)
Faça o que fizer, não saia de casa sem:
smtpd_client_restrictions = reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net
Eles estão pegando a maioria para mim sozinhos.
OK, esta é uma longa pergunta. Vou tentar responder uma parte da pergunta acima. E talvez desenhe um resumo baseado neles.
Disclaimer: Eu não usei o plesk, mas eu usei o postfix. Essa questão era mais de um ano, então talvez o plesk tenha atualizado sua configuração para o postfix. Mas eu acho que essa pergunta seria útil para alguém que projete e implemente a restrição de postfix
smtpd_sender_restrictions =
check_sender_access hash:/var/spool/postfix/plesk/blacklists
permit_sasl_authenticated
check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
smtpd_client_restrictions =
permit_mynetworks
smtpd_recipient_restrictions =
permit_mynetworks
check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
permit_sasl_authenticated
reject_unauth_destination
AND
smtpd_sender_restrictions =
smtpd_client_restrictions =
smtpd_recipient_restrictions =
permit_mynetworks
check_sender_access hash:/var/spool/postfix/plesk/blacklists
permit_sasl_authenticated
check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
permit_mynetworks
check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
permit_sasl_authenticated
reject_unauth_destination
Se um email vier da mynetworks, ele não será verificado por /var/spool/postfix/plesk/no_relay.re e /var/spool/postfix/plesk/no_relay.re . Isso significa que o e-mail será aceito e não será alterado . Em termos de ação pós-fixada (REJECT, ACCEPT), não será diferente, mas para o plesk talvez esses dois cabeçalhos sejam importantes .
Sim, talvez pareça um desperdício quando dois cheques são repetidos. Mas essas verificações repetidas serão colocadas em lugares / restrições diferentes. E em todas as verificações, há alguma lógica ou algoritmo como postfix tratou um email. Você pode se preocupar com a verificação repetida se a verificação foi pesada como check_policy_service ou DNSBL. Para cheques leves como permit_mynetwork , você pode ignorá-lo.
Bem, com duas smtpd_recipient_restrictions e smtpd_relay_restrictions deve ser suficiente para alguma restrição avançada. Mas é para postfix > = 2.10. Para usuário com postfix < 2.10, você pode colocar cheques em várias diretivas para que o postfix não seja muito permissivo.
Sim, bom trabalho para simplificar sua restrição atual de postfix. Mas cuidado com o fato de o postfix fazer parte do plesk. O engenheiro do plesk pode organizar essas restrições por alguns motivos, como modularidade ou manutenção simples.
Resumo:
Tags configuration postfix