Solução Completa de Servidor de Email com Domínios e Usuários Virtuais (Debian Etch, Postfix, Mysql, Dovecot, DSpam, ClamAV, Postgrey, RBL) - Página 5

D. Permissões do cliente

Como estamos buscando realmente usar este servidor de email em um ambiente de produção, vamos querer restringir quem pode enviar emails através dele. Ser um relay aberto (Aceitando emails Para/De todos) é extremamente perigoso e uma ótima maneira de ser rotulado como um servidor de SPAM.

Como os Mail Exchangers realmente lidam apenas com emails PARA nosso domínio, vamos ser MUITO restritivos. Os próximos comandos dirão ao mail exchanger para permitir emails das redes internas e rejeitar QUALQUER email para um destino não autorizado.

# postconf -e 'smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, permit'

E. Prevenção simples de spam

Enquanto o DSpam lidará com a maioria das nossas medidas anti-spam, existem algumas truques simples que podemos empregar nos Mail Exchangers para aliviar um pouco a carga.

1. Postgrey

Greylisting é uma contramedida bastante eficaz contra spam, então, é claro, queremos habilitá-lo nos Mail Exchangers. Primeiro de tudo, vamos instalar o Postgrey. Como sempre, o Debian torna isso simples para nós:

# apt-get install postgrey

O Postgrey será injetado antes que o postfix envie o email para o servidor postman, então precisamos adicioná-lo no final das smtp_recipient_restrictions em main.cf.

# postconf -e 'smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_policy_service inet:127.0.0.1:60000, permit'

Abra /etc/default/postgrey em seu editor favorito e mude a linha de opções para o seguinte:

[...]  
POSTGREY_OPTS="--inet=127.0.0.1:60000 --delay=55"  
[...]  

Então reinicie o postgrey e os emails recebidos serão atrasados em 55 segundos. Você ficaria surpreso com quanto spam isso irá prevenir…

# invoke-rc.d postgrey restart

2. Postfix RBL e outras regras

O Postgrey é ótimo e definitivamente reduzirá a quantidade de spam que você vê, mas existem algumas outras restrições que podemos colocar nos exchangers antes que eles entrem em produção. Eu recomendo fortemente verificar o site e a documentação do postfix para determinar o que todos esses comandos são:

# postconf -e 'smtpd_recipient_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unauth_destination, reject_unauth_pipelining, reject_invalid_hostname, reject_unknown_sender_domain, reject_rbl_client zen.spamhaus.org, reject_rbl_client list.dsbl.org, reject_rhsbl_sender dsn.fc-ignorant.org, check_policy_service inet:127.0.0.1:60000, permit'

Vale a pena também restringir algumas outras áreas:

# postconf -e 'smtpd_data_restrictions = reject_unauth_pipelining, reject_multi_recipient_bounce, permit'

F. Palavras finais sobre o Mail Exchanger

Então, neste ponto, seus dois servidores mail exchanger (MX-1, MX-2) devem estar configurados. Esses servidores têm RBL, DNS e prevenção de SPAM do Postgrey, bem como proteção de cota.

Há um item que vale a pena discutir aqui, e que é a tabela de transporte. Algo a ter em mente é que este cenário particular foi originalmente escrito com a intenção de migrar de um sistema de entrega baseado em qmail para postfix. Assim, queríamos ser capazes de controlar uma migração lenta, um domínio de cada vez, sem ter que nos preocupar com DNS. Configuramos os dois servidores Mail Exchanger para lidar com todos os emails recebidos e, originalmente, eles apenas usavam o agente de transporte smtp para encaminhar o email para o servidor qmail (Após verificar o postgrey). Então, usando as consultas de Transporte SQL, conseguimos redirecionar um domínio de cada vez para o novo formato.

Então, na verdade, você poderia simplificar o processo de transporte se estivesse começando do zero. Nós não estávamos, portanto não pudemos.