Zimbra 8.6: Entregando os SPAMs independentemente da pontuação

zimbra-no-lettermark - Copy

Olá ! Nesse artigo irei falar sobre o ajuste da ação a ser aplicada no Anti Spam do Zimbra para que a mensagem seja entregue independentemente da sua pontuação (spam score). Nesta nova versão do Zimbra o suporte à ações para mensagens com pontuação de SPAM alta foi aprimorado, permitindo que o administrador defina qual ação seja aplicada.

Essa configuração é armazenada no parâmetro zimbraAmavisFinalSpamDestiny e aceita os seguintes valores:

  • D_DISCARD: Descarta silenciosamente a mensagem (valor padrão)

  • D_PASS: Entrega a mensagem independentemente do Score.

  • D_BOUNCE: Gera um Bounce para a mensagem

  • D_REJECT: Rejeita a mensagem.

Desta forma, desejamos ajustar o parâmetro para o valor D_PASS:

zmprov mcf zimbraAmavisFinalSpamDestiny D_PASS

Spamassassin: Portas para o mecanismo Razor

zimbra-no-lettermark - Copy download (2)

Olá ! Na última turma que ministrei do curso EAD de Zimbra nos deparamos com um problema ao habilitar o mecanismo Razor através de um Firewall, o mesmo não consegui se conectar no pool de servidores deste mecanismo.

Após pesquisas (gostaria de agradecer ao aluno Rickifer pelo empenho na pesquisa) foi constatado que as seguintes portas (Output) devem ser liberadas para o funcionamento deste mecanismo:

2703/tcp e 7/tcp

O mecanismo não necessita de nenhuma porta para conectar no seu servidor.

Referências:

http://wiki.apache.org/spamassassin/NetTestFirewallIssues

Configurando o Amavis em um servidor dedicado

Olá ! Neste artigo apresento as configurações para separar o Amavis em um servidor dedicado. Em alguns ambientes isso pode ser necessário devido ao trafego de mensagens, onde o MTA (neste exemplo o Postfix)e Amavis precisam ser separados em servidores dedicados.

Neste exemplo o servidor Postfix é o host mail.matriz.com.br (192.168.200.116) e o servidor dedicado para o Amavis é o host amavis.matriz.com.br (192.168.200.115)

Primeiramente, no servidor Postfix edite o main.cf adicionando a seguinte linha:

content_filter = smtp-amavis:amavis.matriz.com.br:10024

Ainda no servidor Postfix, edite o arquivo master.cf adicionando o seguinte serviço:

0.0.0.0:10025 inet n – y – – smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o mynetworks=127.0.0.0/8,192.168.200.115/32
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks
-o recipient_bcc_maps=
-o sender_bcc_maps=

Deve-se prestar atenção no parâmetro mynetworks do serviço, onde deve ser incluído o IP do servidor do Amavis para entrega das mensagens. Feito isso, após reiniciar o serviço, o Postfix já irá entregar as mensagens com as configurações feitas.

No servidor Amavis, precisamos colocar o serviço para escutar na porta 10024 e aceitar conexões do nosso MTA. No Debian e derivados o arquivo 20-debian_defaults pode ser editado para incluir as configurações ou o 50-user, que vem limpo justamente para as configurações adicionais. Para distribuições baseadas em Red Hat, o Amavis utiliza um único arquivo de configuração.

@inet_acl = qw(127.0.0.1 192.168.200.115 192.168.200.116 [::1]); # Controle acesso – Informar os IPs dos MTAs e do servidor amavis
$inet_socket_bind = ‘0.0.0.0’; # Onde escutar – Colocar as interfaces onde o Amavis deve aceitar conexões
$inet_socket_port = 10024; # Porta
### Encaminhando para o Postfix ###
$notify_method = ‘smtp:[mail.matriz.com.br]:10025’;
$forward_method = ‘smtp:[mail.matriz.com.br]:10025’;
###

Efetuada as configurações, reinicie o serviço do Amavis e tente enviar uma mensagem, nos logs do Amavis deve aparecer a conexão do MTA:

Feb  4 13:30:27 amavis amavis[3052]: (03052-01) Passed CLEAN {RelayedInternal}, MYNETS LOCAL [192.168.200.116]:51347 [192.168.200.116] <joao@matriz.com.br> -> <joao@matriz.com.br>, Message-ID: <67917efa9170c57c59fd791eb0e83c47@matriz.com.br>, mail_id: zQYc-U7HehsQ, Hits: -1.326, size: 596, queued_as: 46FAC5A6DC, dkim_new=default:matriz.com.br, 2981 ms

Utilizando o amavis para inserir Disclaimer

Olá ! Nos artigos anteriores eu expliquei sobre a inserção de Disclaimer utilizando um filtro externo escrito somente para essa funcionalidade:

https://respirandolinux.wordpress.com/2013/01/10/postfix-adicionando-disclaimer-excecoes-de-remetentes-e-arquivos-diferentes-por-dominio/

https://respirandolinux.wordpress.com/2013/01/05/postfix-adicionando-disclaimer-excecoes-de-remetentes/

https://respirandolinux.wordpress.com/2012/12/18/postfix-adicionando-disclaimer-todas-as-mensagens-enviadas/

Porém, se o Amavis já estiver implementado é possível utilizar o mesmo para inserir as mensagens automáticas, portanto veremos essa implementação neste artigo.

Primeiramente, é necessário instalar o altermime, que continua sendo o programa utilizado para modificar a mensagem,

Após instalar o altermime, vamos iniciar a configuração do Disclaimer, podendo ser feita no arquivo 50-user.conf do Amavis:

### HABILITA INSERÇÃO DISCLAIMER
$defang_maps_by_ccat{+CC_CATCHALL} = [ ‘disclaimer’ ];

# Programa utilizado para modificar a mensagem
$altermime = ‘/usr/bin/altermime’;

$policy_bank{‘MYNETS’} = { # Modificar somente as mensagens geradas internamente
originating => 1,
allow_disclaimers => 1,
};

# Arquivo com o Disclaimer
@altermime_args_disclaimer = qw(–disclaimer=/etc/postfix/disclaimer/_OPTION_.txt);

@disclaimer_options_bysender_maps = ({
#Permite incluir disclaimer baseado no dominio ou usuário

#Os domínios matriz e filial terão disclaimers diferentes
‘matriz.com.br’ => ‘matriz.com.br’,
‘filial.com.br’ => ‘filial.com.br’,

#O usuario fabio terá um disclaimer pessoal
fabio@matriz.com.br’ => ‘fabio.matriz.com.br’,

#O usuario fulano não terá um disclaimer

fulano@matriz.com.br’ => ‘empty’,

# Disclaimer para ser inserido caso não se encaixe nos critérios acima
‘.’ => ‘default’,
},);

Feito isso, basta reiniciar o serviço do Amavis que as mensagens automáticas já serão inseridas, sendo preciso criar os arquivos no diretório apontado em altermime_args_disclaimer.

Spamassassin e PostgreSQL: sintaxe de entrada é inválida para tipo bytea

Continuando com a série de artigos sobre Amavis e Spamassassin, segue uma dica para quem está integrando o Spamassassin ao PostgreSQL. Após efetuar as configurações observei que não estava sendo possível gravas as mensagens como Spam ou Ham na tabela bayes do Spamassassin, no PostgreSQL era apresentado o seguinte erro:

sintaxe de entrada é inválida para tipo bytea

Isso se devia por estar utilizando a função genérica SQL para o plugin BayesStore:

Mail::SpamAssassin::BayesStore::SQL

Para corrigir, basta alterar a função para a própria do Postgres:

Mail::SpamAssassin::BayesStore::PgSQL 

Spamassassin: Melhorando a eficácia do seu anti-spam

Iniciando a série de artigos sobre o Spamassassin e Amavis, vamos aumentar a eficácia da detecção de Spams atualizando as regras do Spamassassin.

No Debian por padrão a atualização diária das regras do Spamassassin vem desativada, para ativar basta editar o arquivo /etc/default/spamassassin e mudar a varável CRON para 1:

# Cronjob
# Set to anything but 0 to enable the cron job to automatically update
# spamassassin’s rules on a nightly basis
CRON=1

Isso fará com que o script spamassassin, que está no diretório /etc/cron.daily seja executado diariamente.

Porém, há o canal SOUGHT RULES, que é atualizado 4 vezes ao dia pelo desenvolvedor do Spamassassin, e é altamente recomendável utiliza-lo, e pesquisando na internet, inclusive na própria página do projeto são apresentados as melhorias nos resultados após utilização deste canal.

Para utilizar este canal, primeiramente é necessário efetuar o Download e importar a chave do mesmo:

wget http://yerp.org/rules/GPG.KEY

sa-update –import GPG.KEY

Agora, vamos alterar o script do Spamassassin para efetuar utilizar o canal SOUGHT RULES em sua atualização diária, para isso, altere o arquivo /etc/crond.daily/spamassasin, modificando a linha 64 da seguinte forma:

sa-update -v –channel sought.rules.yerp.org –channel updates.spamassassin.org –gpgkey 6C6191E3

Feito isso, basta aguardar a próxima atualização para que as regras do canal SOUGHT sejam instalados, caso queira aplicar imediatamente basta executar o comando conforme inserido no script.


	

Amavis / Spamassassin: Série de artigos

Nas próximas semanas, irei manter uma série de artigos relacionados ao Amavis e Spamassasin, através da experiência com as últimas turmas dos treinamentos que ministro, procurarei compartilhar algumas experiências para aumentar a eficiência destes softwares, principalmente na detecção de Spams.

Um novo artigo sobre este tema será publicado a cada semana, e o primeiro será publicado amanhã (07/08).

Debian: Separando os logs do Amavis

Quem trabalha com o Amavis no Debian sabe que o mesmo gera os seus logs no arquivo /var/log/mail.log, isso causa bastante incomodo ao tentar visualizar o arquivo de log para rastrear mensagens, procurar por erros, etc… Com os filtros do Rsyslog podemos direcionar as mensagens do Amavis para um arquivo específico, como pode ser visto abaixo:

Crie o arquivo /etc/rsyslog.d/amavisd-new.conf com o conteúdo abaixo:

if $programname == ‘amavis’ then -/var/log/amavis.log
if $programname == ‘amavis’ then ~

Esse filtro direcionar todos os logs gerados pela aplicação Amavis para o arquivo /var/log/amavis.log e não envia mais nenhum outro caminho.

Convém também que seja configurada a rotatividade deste log, para isso, crie o arquivo /etc/logrotate.d/amavisd-new com o seguinte conteúdo:

/var/log/amavis.log {
rotate 12
weekly
compress
delaycompress
create 640 amavis amavis
postrotate
/etc/init.d/amavis force-reload > /dev/null
endscript
}

Isso fará com que o arquivo de log do Amavis seja rotacionado a cada semana e sejam mantidos os últimos 12 arquivos.

Dkim – Parte 1 – Assinando mensagens com o Amavis

Esse tutorial foi criado para apresentar o Framework DKIM, que utiliza chaves públicas para autenticação de e-mail. O remetente assina a mensagem no envio permitindo que o receptor efetue consulta no DNS para confirmar sua autenticidade. Decidi escrever sobre este tema devido a muitos relatos de problemas ao entregar mensagens para grandes provedores que efetuam verificação DKIM como o Gmail, Yahoo e Hotmail por exemplo.

Nesse texto não entrarei em detalhes sobre o funcionamento deste mecanismo, e sim apresentei uma forma rápida para implementar caso já tenha o Amavis implementado, nos próximos artigos sobre este tema apresentei todas as definições do framework.

Neste exemplo utilizamos o Debian Squeeze, portanto o arquivo de configuração do Amavis onde iremos implementar o DKIM é /etc/amavis/conf.d/20-debian_defaults. Criaremos o diretório /etc/dkim/keys/ para armazenar nossas chaves, utilizaremos o domínio laboratorio.com.br.

Primeiramente, vamos criar a chave para assinatura :

amavisd-new genrsa /etc/dkim/keys/laboratorio.pem

Agora vamos editar o arquivo 20-debian_defaults incluindo as linhas abaixo, destacando que não estamos habilitando verificação com DKIM, e sim assinando nossas mensagens:

$enable_dkim_verification = 0; #não iremos verificar DKIM, apenas assinar
$enable_dkim_signing = 1;
dkim_key(‘laboratorio.com.br‘, ‘default’, ‘/etc/dkim/keys/laboratorio.pem‘);
@dkim_signature_options_bysender_maps = (
{ ‘.’ => { ttl => 21*24*3600, c => ‘relaxed/simple’ } } );
@mynetworks = qw(192.168.0.0/24); # coloque aqui suas faixas de rede

Agora precisamos incluir nossa chave pública no DNS para que os destinatários possam verificar nossa assinatura, execute o comando abaixo, que irá apresentar na tela a saída que deve ser incluida no DNS, se estiver utilizando o BIND basta copiar e colar:

amavisd-new showkeys

Exemplo:

; Deve ser incluido na configuração do seu DNS
default._domainkey.laboratorio.com.br.       3600 TXT (
“v=DKIM1; p=”
“MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4ZkmIpubptTSpHV7365iB7j7m”
“/46sYWN/PTHweK1LQmq4aGiXD5XfPlmZ2E78kgsCEw0weMG5q5+Q+VSBLxV+f6If”
“MOG+B9ruNx8MkoNgNQlCwsUiEV9knvMyx2+ou/KmypZv2i/wRUwOh4jT+NTcr4Ur”
“WNCLWJSH34L/eYoHvwIDAQAB”)

Feito isso, reinicie o serviço do Amavis e efetue um “reload” no seu servidor DNS.

O comando amavisd-new testkeys permite validarmos a configuração:

TESTING#1: default._domainkey.laboratorio.com.br  => pass

Agora basta enviar uma mensagem e confirmar se o amavis efetuou a assinatura:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=laboratorio.com.br; h=
	user-agent:message-id:subject:subject:from:from:date:date
	:content-transfer-encoding:content-type:content-type
	:mime-version:received:received; s=default; t=1355229764; x=
	1357044164; bh=IZzGk5hdbwv1XsfTE2Dngp1hMDfBwbnO3RaSFfeDt+k=; b=P
	AQ7bFr1vCck1ZHI6Elqm3lWxhc1Widsq4qw3hlfGvNK6xwtRYRfxFkEBM7t9sxRv
	+QLjMO8iLZb3qGDigFJNw8kfiaUX9tHI6FbexB44M0UJfh0XGSL2Cnc9hsOxk7Or
	vTXMSUBbuq8Td6Ow7b7IDaGwZw2Ly4iwc9uCyiVRkQ=