Postfix Spam Filter · 12 min read · Nov 14, 2025
Filtro de Spam Postfix usando Ubuntu Dapper, MailScanner, SpamAssassin, Razor, Pyzor, DCC e ClamAV - Página 3
2.3 Configurações Anti-Spam do Postfix
Notas Preliminares:
Quando um cliente (um computador tentando nos enviar um e-mail) se conecta ao Postfix e inicia uma sessão de comunicação, o Postfix registra informações sobre essa sessão. Antes do ponto em que o Postfix aceita e-mails dessa sessão para entrega, temos a opção de avaliar a sessão e rejeitar o e-mail definindo algumas restrições em main.cf. Este link ilustra o que acontece durante uma sessão SMTP típica: http://helpdesk.islandnet.com/pep/smtp.php. As restrições abaixo ajudam a afastar alguns spams e evitar que nosso sistema se torne um relay aberto. Essas restrições fazem com que alguns e-mails sejam rejeitados pelo Postfix logo na “porta da frente”. Isso economiza recursos do sistema porque o e-mail não entrará em nosso sistema e, portanto, não será escaneado pelo MailScanner (e, subsequentemente, pelo SpamAssassin). Isso é bom e ruim. Economiza recursos do sistema, mas também não permite que você veja o e-mail rejeitado. Tudo o que você verá é uma ou duas entradas de log do Postfix dizendo essencialmente “Ei, um servidor de e-mail chamado ‘xxxxxxxx’ no endereço IP X.X.X.X tentou enviar um e-mail, mas quebrou a regra XYZ, então eu o rejeitei”. Agora, isso poderia ter sido spam (spammers muitas vezes não seguem intencionalmente os RFCs para alcançar seus objetivos), mas se fosse um e-mail “legítimo”, digamos de um cliente cujo departamento de TI simplesmente configurou incorretamente seu servidor de e-mail (isso acontece), você poderia ter algumas penas arrepiadas para lidar.
Se você quiser permitir que TODO e-mail endereçado a nós entre pela porta da frente e, portanto, permitir que o MailScanner/SpamAssassin lide com todo o controle de spam dentro do sistema, você precisaria modificar algumas das configurações abaixo. Pessoalmente, acho que uma combinação de controle anti-spam do Postfix e do SpamAssassin é a melhor. No mínimo, você precisa garantir que não desative o controle anti-relay padrão embutido no Postfix ( smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination).
A configuração abaixo é na verdade muito conservadora, permitindo que a maioria dos e-mails entre pela porta da frente para que o MailScanner e o SpamAssassin tenham sua chance. Para mim, ela (com segurança) rejeita cerca de 35% dos e-mails destinados aos meus usuários, então acho que essas configurações são bastante valiosas. Recomendo essa abordagem para começar. Adicionar restrições adicionais aumentará a probabilidade de rejeitar e-mails válidos de computadores mal configurados. Se você decidir adicionar/remover permissões/restrições no futuro, faça isso uma de cada vez e dê a si mesmo tempo suficiente para avaliar o efeito da mudança. Sugiro fortemente que você tenha uma boa compreensão de como essas restrições funcionam antes de fazer alterações nas entradas abaixo. Entre outras coisas, errar nesse aspecto pode rejeitar e-mails legítimos e/ou nos fazer tornar um relay aberto. Note que as restrições nem sempre restringem, algumas também permitem.
Se você quiser entender melhor essas configurações, bons recursos são http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt, http://www.postfix.org/SMTPD_ACCESS_README.html, http://www.securitysage.com/antispam/, o um pouco datado (2001) http://www.mengwong.com/misc/postfix-uce-guide.txt, e este excelente livro. Você notará que eu uso apenas algumas das mesmas configurações que essas, então esta configuração não é nem de longe tão restritiva. Tenha em mente que o SpamAssassin e o MailScanner entrarão em cena em breve e nos fornecerão opções muito mais flexíveis e configuráveis para reconhecer e manipular spam.
2.3.1 smtpd_helo_required
Faça qualquer servidor de e-mail conectado realizar um “aperto de mão” SMTP adequado e anunciar seu nome. Os RFCs da Internet exigem isso, então nós também exigimos.
postconf -e "smtpd_helo_required = yes"Prefácio: As etapas de restrição do Postfix são as seguintes e são processadas na seguinte ordem:
smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictionssmtpd_recipient_restrictions
smtpd_data_restrictionsNós só vamos colocar entradas nas três últimas etapas de restrição. As etapas de restrição são processadas nesta ordem, independentemente da ordem listada em main.cf.
2.3.2 smtpd_sender_restrictions
Esta etapa de restrição restringe quais endereços de remetente este sistema aceita nos comandos MAIL FROM: (o remetente do envelope). Vamos colocar três testes (restrições) nesta etapa de restrição.
Uma etapa de restrição contém uma lista de restrições (testes). Normalmente, os testes avaliam para DUNNO, REJECT ou OK. DUNNO significa “Eu não sei o que fazer, deixe o próximo teste decidir”. REJECT simplesmente rejeita o e-mail. OK significa que não mais testes são realizados nesta etapa de restrição, os testes continuam com a próxima etapa (se houver). Testes do tipo Reject* normalmente avaliam para REJECT ou DUNNO. Testes do tipo Permit normalmente avaliam para OK ou DUNNO, e testes do tipo check__access podem realizar uma variedade de ações. A ilustração mostra a lógica básica.
Sessão SMTP
|
V
etapa de restrição-------------
teste ---------------REJECT->
| \
| DUNNO
| \
| V
| próximo teste------REJECT->
| | \
OK OK DUNNO
| | \
| | V
V V
próxima etapa de restrição------->2.3.2.1 check_sender_access
Veja http://www.postfix.org/access.5.html. Aqui pedimos ao Postfix para comparar o remetente do envelope com entradas em um banco de dados /etc/postfix/sender_access e agir com base nessas entradas se uma correspondência for encontrada. Também definimos qual ação é tomada lá (OK, DUNNO, REJECT etc.) com base em cada remetente. Se o remetente não estiver listado no arquivo, o teste avalia para DUNNO, e o próximo teste é realizado. Eu fornecerei exemplos um pouco mais tarde. Um uso deste arquivo é colocar uma lista de remetentes (endereços de e-mail, domínios, endereços de rede etc.) dos quais desejamos não receber e-mails (colocá-los na lista negra). Também teremos a capacidade de colocar remetentes na lista negra no MailScanner e no SpamAssassin, mas economizará recursos se os colocarmos aqui. Também usaremos este arquivo para permitir que remetentes específicos contornem os próximos dois testes nesta etapa de restrição. Se dermos um OK aqui, não mais testes são realizados nesta etapa de restrição, os testes continuam na próxima etapa de restrição ( smtpd_recipient_restrictions). Note que se colocássemos esta configuração na etapa de restrição smtpd_recipient_restrictions antes do teste reject_unauth_destination, e déssemos a alguém o OK lá, o teste reject_unauth_destination localizado lá seria contornado. Isso seria ruim porque qualquer um a quem déssemos o OK poderia então usar nosso servidor como um relay aberto. As restrições de acesso são avaliadas na mesma ordem em que as listamos, e se uma correspondência for encontrada, isso influenciará como (se) as restrições adicionais são avaliadas.
2.3.2.2 reject_non_fqdn_sender
Rejeita quando o endereço de e-mail do remetente do envelope não está no formato adequado. Lembre-se, o “remetente do envelope” é o que o servidor de e-mail remetente fornece na linha “MAIL FROM:” durante a sessão SMTP, não a linha de cabeçalho “From:”. “Joe” não é permitido nos enviar e-mails (porque não podemos responder a “Joe”), mas “[email protected]” é, no mínimo, um endereço de e-mail. Se o remetente não for rejeitado neste ponto, este teste avalia para “DUNNO”.
2.3.2.3 reject_unknown_sender_domain
Rejeita quando a parte do domínio do remetente do envelope não possui nenhum registro DNS “A” ou “MX”. Esta configuração rejeita cerca de 35% dos e-mails que chegam ao meu servidor de e-mail. É comum que spammers usem um nome de domínio falso para não ter que lidar com a repercussão de e-mails rejeitados. Também é importante para nós não encher nossa fila com avisos de retorno que nunca poderão ser entregues devido ao fato de que o domínio do remetente nem sequer existe. Se o domínio do remetente tiver um registro “A” ou “MX”, este teste também avaliará para “DUNNO”. Ocasionalmente, você verá em um relatório que alguém de quem deseja receber e-mails foi rejeitado por esta configuração. Uma possível causa disso é quando remetentes legítimos deliberadamente usam nomes de domínio falsos para que você não responda a eles. É aqui que a lista de acesso do remetente se torna útil. Você pode dar a eles um OK lá, e este teste será contornado.
Agora para implementar essas três restrições:
postconf -e "smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access, reject_non_fqdn_sender, reject_unknown_sender_domain"2.3.3 smtpd_recipient_restrictions
As restrições de acesso que o servidor SMTP do Postfix aplica no contexto do comando RCPT TO:. Isso se refere ao “destinatário do envelope”, que é o que o cliente forneceu na linha “RCPT TO:” durante a sessão SMTP, não a linha de cabeçalho “To:”. smtpdrecipient_restrictions é outra etapa de restrição que contém uma lista de restrições específicas. Outras etapas de restrição que são avaliadas antes de smtpd_recipient_restrictions são smtpd_client_restrictions, smtpd_helo_restrictions e smtpd_sender_restrictions (nesta ordem). Restrições que normalmente iriam nessas etapas de restrição anteriores podem ser colocadas alternativamente em smtpd_recipient_restrictions. Portanto, algumas pessoas preferem colocar todas as smtpd*_restrictions que normalmente iriam nas etapas de restrição anteriores em smtpd_recipient_restrictions (na ordem correta) e deixar as etapas anteriores não configuradas (vazias). No nosso caso, é mais seguro usar smtpd_sender_restrictions e smtpd_recipient_restrictions. Vamos olhar para aquelas restrições específicas (testes) que colocamos em smtpd_recipient_restrictions:
2.3.3.1 permit_mynetworks
Permite que máquinas listadas em “mynetworks” pulem o restante dos testes nesta etapa de restrição (permit = OK). Em outras palavras, sai desta etapa e é testado na próxima etapa (smtpd_data_restrictions). Como permit_mynetworks é colocado antes de reject_unauth_destination, isso significa que máquinas em $mynetworks são permitidas para relatar e-mails para qualquer domínio. Sem isso, só poderíamos enviar e-mails para nosso(s) próprio(s) domínio(s). Se o endereço IP do remetente não estiver listado em $mynetworks, o teste avalia para “DUNNO” e continua para o próximo teste (reject_unauth_destination).
2.3.3.2 reject_unauth_destination
Isso, junto com permit_mynetworks, é usado para controle de relay. Esta configuração, em essência, significa que e-mails destinados a qualquer domínio para o qual não configuramos nossa máquina para aceitar e-mails serão rejeitados. No nosso caso, o Postfix usará a configuração relay_domains (ou tabela) que configuramos anteriormente para determinar quais são esses domínios. Veja http://www.postfix.org/postconf.5.html#reject_unauth_destination para mais detalhes. Se o domínio estiver listado em relay_domains, este teste avalia para “DUNNO” e a sessão é permitida a continuar para o próximo teste (se houver). Assim como “mynetworks”, esta configuração é extremamente crítica. Ao colocar permit_mynetworks diretamente à frente de reject_unauth_destination, garantimos que podemos enviar e-mails para domínios além do nosso, mas só aceitaremos e-mails endereçados a nós de computadores fora da nossa rede, assim permit_mynetworks e reject_unauth_destination trabalham em equipe.
2.3.3.3 reject_unauth_pipelining
Rejeita remetentes em massa que tentam usar pipelining para acelerar a entrega, sem verificar se é suportado primeiro (não-RFC, comum entre spammers).
Agora para implementar essas três restrições:
postconf -e "smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unauth_pipelining"2.3.4 smtpd_data_restrictions
Restrições de acesso opcionais que o servidor SMTP do Postfix aplica no contexto do comando SMTP DATA:. Assim como smtpd_recipient_restrictions, esta é uma etapa de restrição.
2.3.4.1 reject_unauth_pipelining
Repito esta configuração em smtpd_data_restrictions, pois não é sempre eficaz quando colocada em smtpd_recipient_restrictions. Eu a incluo em smtpd_recipient_restrictions, pois gosto de colocá-la antes de qualquer servidor de política. Note que existem apenas algumas restrições que fazem bom uso de smtpd_data_restrictions.
postconf -e "smtpd_data_restrictions = reject_unauth_pipelining"2.3.5 Arquivos de controle de filtragem de conteúdo do Postfix:
http://www.postfix.org/header_checks.5.html - /etc/postfix/header_checks e /etc/postfix/body_checks
Esses arquivos listarão certas “strings” de texto e dirão ao Postfix o que fazer com os e-mails se encontrar essas strings nos cabeçalhos de e-mail ou no corpo da mensagem. Arquivos de exemplo já foram criados para nós, com comentários explicando o que colocar neles. Você pode editá-los à vontade. Note que esses arquivos exigem o uso de “formato de expressão regular”. “regexp” é algo que você vai querer aprender para viver no mundo *nix. Pegue um livro ou pesquise na Internet em algum momento. Para um exemplo de um arquivo header_checks elaborado de alguém com atitude, dê uma olhada em http://www.geekounet.org/filters/header_checks. Mas não siga isso cegamente, é apenas um exemplo! Aqui está um exemplo de um arquivo body_checks: http://www.securitysage.com/files/body_checks. Vale a pena conferir http://www.securitysage.com/guides/postfix_uce.html quando você tiver um momento de lazer. Especificamente http://www.securitysage.com/antispam/hedchek.html e http://www.securitysage.com/antispam/bodchek.html. Recomendo não fazer um grande número de alterações em qualquer parte do Postfix sem dar a si mesmo bastante tempo para avaliar os efeitos. Como uma tartaruga, vá devagar, viva muito.
2.3.5.1 header_checks & body_checks
Vamos colocar esses dois em main.cf. header_checks é necessário porque nos permite segurar todos os e-mails recebidos para que o MailScanner faça seu trabalho:
postconf -e "header_checks = pcre:/etc/postfix/header_checks"
postconf -e "body_checks = pcre:/etc/postfix/body_checks"Edite header_checks:
vi /etc/postfix/header_checksAdicione esta linha ao arquivo header_checks, sem ela o MailScanner não funcionará:
/^Received:/ HOLDNote que não precisamos postmap tabelas do tipo pcre. Elas permanecem em texto simples e o Postfix as utiliza “como estão”.
Você também pode configurar mime_header_checks e nested_header_checks junto com header_checks e body_checks. Se você for muito criativo com filtragem de conteúdo no Postfix (usando header_checks e body_checks), isso pode ter um impacto significativo no desempenho.
2.3.5.2 /etc/postfix/sender_access http://www.postfix.org/access.5.html
Referenciamos este arquivo em smtpd_sender_restrictions. Usamos este arquivo para verificar o remetente logo na porta da frente. Neste arquivo, listaremos certos remetentes/domínios/faixas de endereços IP para tratamento especial. Abaixo estão exemplos falsos, crie os seus conforme achar adequado. Por favor, leia /etc/postfix/sender_access para mais informações. Embora você possa usar este arquivo para vários propósitos, considerando a forma como o configuramos em smtpd_sender_restrictions, sugiro usá-lo para colocar remetentes na lista negra ou permitir que certos remetentes contornem os testes restantes em smtpd_sender_restrictions.
vi /etc/postfix/sender_access#Exemplo de arquivo de mapa de acesso do remetente
[email protected] 550 Não, obrigado
allspam.tld 550 Spam não é aceito aqui
badguy.net REJECT
[email protected] REJECT
newsletter-favorite-lug.org OK
my-really-l337-test-domain.com OKComo esta é uma tabela hash, você precisa postmap como de costume:
postmap /etc/postfix/sender_access2.3.6 Última Olhada na Instalação do Postfix
Reveja as mudanças:
less /etc/postfix/main.cfVerifique o conteúdo do arquivo em busca de erros e repare se necessário. Inicie o Postfix:
postfix startVerifique se o Postfix responde:
telnet 127.0.0.1 25Você deve ver:
220 [seuFQDNaqui] ESMTP Postfix (Ubuntu)pressione [enter] algumas vezes; então digite quit para sair.
Se não responder dessa forma, abra outra janela de terminal e pare o Postfix postfix stop. Certifique-se de que você executou newaliases e todos os comandos postmap acima. Verifique todas as configurações em main.cf e master.cf. Há um bom documento sobre solução de problemas do Postfix em http://www.postfix-book.com/debugging.html, mas tenha em mente que nosso sistema não está pronto para relatar e-mails neste ponto (eles acabarão na fila).
Sempre que você fizer alterações em master.cf ou main.cf ou em tabelas de dados, na maioria (não em todos) das vezes, é necessário que você recarregue o Postfix com:
postfix reloadAgora que temos uma configuração básica do Postfix, http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall e http://www.postfix.org/BASIC_CONFIGURATION_README.html são bons lugares para obter uma melhor compreensão de algumas das configurações que usamos e, neste ponto, esses READMEs farão mais sentido.
Por padrão, nosso Postfix é executado em chroot. Se você não sabe o que isso significa, não importará muito neste momento. Deixo para você pesquisar o que chroot significa em algum momento posterior. Alguns dos arquivos do sistema que o Postfix precisa para funcionar corretamente foram copiados para a jaula chroot do Postfix (/var/spool/postfix) durante a instalação. Ocasionalmente, os arquivos originais serão modificados, e o Postfix reclamará que a cópia que possui não é a mesma que a original. Quando isso acontece, você pode copiar manualmente o(s) arquivo(s) que o postfix reclamou para a jaula chroot, ou podemos simplesmente executar um script que é fornecido com o código-fonte do Postfix (chamado LINUX2) que copiará novamente todos os arquivos que o Postfix precisa para onde precisa deles.
cd /usr/local/src/postfix-2.3.3/examples/chroot-setup
postfix start
chmod +x LINUX2
cp LINUX2 /usr/bin
LINUX2
cd
postfix checkIsso torna o script LINUX2 executável, copia-o para um diretório em nosso caminho e, em seguida, o executa. O LINUX2 geralmente resolverá quaisquer problemas ou questões com o Postfix se você ver erros nos logs com o Postfix acessando arquivos ou diretórios de configuração.
Receba novas postagens na sua caixa de entrada
Sem spam. Cancele a assinatura a qualquer momento.