Agora disponível o selor_dkim.

Todas as outras ferramentas DKIM que encontrei por ai eu achei que consumiam muita CPU e I/O de Disco por funcionarem com base na reescrita de todo o arquivo de email que já se encontra no HD do servidor, assim que é recebido.

Por exemplo:
Quando um email é recebido por qualquer MTA, ele precisa ser gravado em Disco, as diversas ferramentas DKIM precisam embutir no meio do HEADER a assinatura e isso requer a reescrita de todo o arquivo. Isto gera I/O de disco desnecessário e muito consumo de CPU.

Fiz o selor_dkim diferente. Assim que o email é recebido e já esta no disco, o programa é acionado para analisar o email e então ele imprime na STDOUT apenas a parte do header referente a DKIM. O Selor por sua vez captura esse texto e só adiciona ao email no momento em que ele esta entregando a mensagem para um MTA externo, sem reescrever o email que esta no spool.

Fiz um tutorial explicando sua instalação: http://www.mtaselor.com.br/?conteudo=15

Muitas vezes, precisamos fazer nosso servidor não entregar diretamente um email a seu destino, enviando a mensagem para outro MTA entrega-la.

Exemplo de uma situação:
Digamos que seu cliente tenta enviar uma mensagem à uma conta do Hotmail e sem qualquer motivo, as mensagens são excluídas de dentro dos servidores da Microsoft. Você já fez de tudo: configurou SPF, Reverso, o IP esta limpo no mundo das Blacklists e nada ( O Hotmail é assim mesmo ), mas, descobre que um outro servidor seu que fica em outro link esta conseguindo entregar as mensagens normalmente. A idéia então é simples: fazer o Selor encaminhar todas as mensagens com destino à @hotmail.com para este servidor secundário e ele vai entrega-las para você.

Digamos que o IP do servidor secundário seja: 10.10.10.100 ( Pode ser um IP de Internet ). Adicione a seguinte regra no evento Event.rcpt ( /usr/local/selor/rules_rcpt )

Find_in_to? "@hotmail.com" Mx_dest! "10.10.10.100"

É possível até, especificar outra porta ( além da 25 ) e até fazer o Selor se autenticar com um usuário e senha no outro servidor.

Exemplos...

Outra porta (Pode ser qualquer porta, mas aqui vou usar a 587):
Find_in_to? "@hotmail.com" Mx_dest! "10.10.10.100 587"
Autenticando-se com o usuário 'hostmaster@dominio.com.br' e a senha 'minhasenha'
Find_in_to? "@hotmail.com" Mx_dest! "10.10.10.100 587" Mx_auth! "hostmaster@dominio.com.br:minhasenha"
Você pode precisar disto para resolver muitos problemas. Alguns deles são:

- Problemas de rotas, Blacklists, Anti-Spam, Controle de fluxo, Balanceamento, etc...

Hoje em dia, quando fazemos um redirecionamento para um email externo e o endereço do remetente também é externo, temos muitos problemas de SPF.
Exemplo:
Digamos que o seu cliente insiste em mandar emails usando como remetente uma conta do @hotmail.com para um destinatário do @gmail.com

O Gmail provavelmente vai considerar a mensagem como SPAM por não passar em diversos testes, incluindo o teste de SPF, pois, o seu servidor não tem permissão para enviar email @hotmail.com

Neste caso, o correto seria você explicar ao seu cliente que ele deveria enviar os emails dele usando o servidor SMTP do Hotmail e não o seu, mas, você usar o recurso de SRS...

O SRS faz o seguinte:
Pega o email do remetente e o altera de forma a usar o seu domínio para enviar as mensagens, mas, mantém o email original do remetente codificado-o no próprio endereço e NÂO altera o endereço original do Header, ou seja, quem receber o email, vai ver e responder o email para o endereço original e não para o que foi codificado.

Exemplo:
xxxxxxxxxxxxx123@hotmail.com
Seria convertido em:
SRS0-XdSeW3WESXssss=hotmail.com=xxxxxxxxxxxxx123@dominiodoseuhost.com

O texto depois do 'SRS0', é um código interno de controle do próprio Selor, que é criado com base em uma senha que você configura dentro do selor.conf. Este código serve como autenticador de retorno. Caso uma mensagem de MAILER-DAEMON volte para este endereço, o Selor poderá checar a autenticidade do email e reconverte-lo e encaminha-lo para o endereço original. Isto impede que spammers usem o seu servidor para enviar virus/spam.

Como configurar:

Abra o selor.conf e defina uma senha para o Srs em Srs_key:

Exemplo:
Srs_key "minhasenha"
Srs_shift 0
Srs_alias_redir 1
Explicação:
Srs_key -> Liga e define qual será a senha usada para criar o codigo do SRS
Srs_shift -> Este pode ter qualquer valor entre 0 e 255. É apenas um embaralhador da senha.
Srs_alias_redir -> Liga a chamada à função Srs quando o Selor detecta um redirecionamento via Alias onde o remetente e destinatário são emails externos.

Reinicie o Selor:

Linux:
/etc/rc.d/rc.selor restart
FreeBSD:
/usr/local/etc/rc.d/selor restart
Feito. Só testar o recurso

Para fazermos uma consulta em uma ou mais Blacklists, podemos usar o evento Event.from, colocando a seguinte regra:

Rbl_test! "b.barracudacentral.org zen.spamhaus.org"
Itest? "%R>0" Reply! "550 Voce esta listado em %R Blacklists. Resp: %T" Deny!
Estas linhas recusam o host remoto se estiver em uma ou mais Blacklists.
Se quiser acrescentar mais blacklists, basta adiciona-la a lista ai em cima, separando-a por espaços.

Lembre-se de que quanto mais blacklists você adicionar, mais tempo o servidor vai levar para testar tudo.

Se os seus clientes se autenticam para enviar os emails, você pode simplesmente recusar emails cujo o domínio seja interno e não estejam autenticados.


Isso corta muito Lixo Eletrônico que tenta entregar mensagens usando como remetentes, emails do seu servidor.

Internal_from? !Auth? Reply! "550 Voce precisa autenticar-se" Deny!