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.

Anúncios

Postfix: contornando 501 Syntax: HELO hostname

Antes de aplicar essa orientação, leia: https://respirandolinux.wordpress.com/2014/08/25/postfix-contornando-comandos-incorretos-de-conexoes-smtp/

Olá ! Compartilho com vocês como configurar o Postfix para não recusar o HELO  e EHLO com a sintaxe incorreta. As RFCs 821 e 2821 especificam claramente que o HELO e EHLO deve ser seguidos do hostname ou domínio que deseja ser informado. porém é muito comum implementar o SMTP para que diversas aplicações enviem e-mails, e certamente muitas destas não seguirão os padrões.

Em uma dessas implementações, foi observado que diversas aplicações estavam enviando o HELO ou EHLO sem nenhum parâmetro, sendo rejeitado pelo servidor:

220 SMTP
HELO
501 Syntax: HELO hostname

220 SMTP
EHLO
501 Syntax: EHLO hostname

O Postfix já estava configurado para não exigir o HELO/EHLO (smtpd_helo_required = no) e as restrições da etapa HELO (smtpd_helo_restrictions) estavam liberando as aplicações, porém a sintaxe continuava sendo testada e como o HELO/EHLO estava sendo enviado sem nenhum parâmetro, o servidor rejeitava.

Para contornar essa configuração, podemos usar o parâmetro smtpd_noop_commands que permite informar ao Postfix quais comandos passarão a ser aceitos com o código 250 – OK, sobrescrevendo qualquer outra implementação.

Edite o main.cf incluindo a seguinte linha:

smtpd_noop_commands = HELO EHLO

Feito isso, efetue um reload no serviço  do Postfix e os comandos HELO/EHLO sem parâmetro serão aceitos:

220 SMTP
HELO
250 2.0.0 Ok

220 SMTP
EHLO
250 2.0.0 Ok

Roundcube + Spamassassin: Treinando automaticamente o anti spam

Seguindo a série de artigos sobre o Spamassassin e Amavis, apresento agora um complemento (plugin) para o Roundcube que permitirá que o spamassassin “treine”  automaticamente as mensagens após os usuários marcarem como “Spam” ou “Não Spam”.

Eu havia publicado uma configuração para o Dovecot mover as mensagens marcadas como SPAM automaticamente para a pasta desejada : https://respirandolinux.wordpress.com/2013/08/21/dovecot-mover-spam-automaticamente-para-a-pasta-desejada , porém caso ocorra uma falso positivo o usuário não terá como “treinar” o anti-spam para não considerar mais essa mensagem. Como também pode ocorrer de um SPAM não ser identificado e estar chegando na caixa postal do usuário.

Utilizando o Roundcube, é possível utilizar o complemento MARKASJUNK2 para treinar automaticamente o spamassassin, primeiramente efetue o Download no mesmo neste link:

http://www.tehinterweb.co.uk/roundcube/#pimarkasjunk2

Após efetuar o Download, descompacte o mesmo dentro do diretório plugins da sua instalação do Roundcube e edite as seguintes linhas do arquivo config.inc.php:

#Estamos informando para o plugin utilizar comandos como mecanismo para treinar o anti-spam

$rcmail_config[‘markasjunk2_learning_driver’] = ‘cmd_learn’;

#Qual comando deve ser utilizado para identificar a mensagem como spam

$rcmail_config[‘markasjunk2_spam_cmd’] = ‘sa-learn –no-sync –spam –username=amavis %f’;

#Qual comando deve ser utilizado para identificar a mensagem como não-spam (HAM)

$rcmail_config[‘markasjunk2_ham_cmd’] = ‘sa-learn –no-sync –ham –username=amavis %f’

Feito isso, adicione o markasjunk2 aos plugins que serão carregados no Roundcube, no arquivo main.inc.php:

$rcmail_config[‘plugins’] = array(“managesieve”, “markasjunk2”);

Ao carregar o Webmail, serão apresentados os botões SPAM para marcar qualquer mensagem SPAM e o botão NÃO SPAM para marcar mensagens dentro da pasta SPAM do usuário como falso positivo, quando o usuário clicar em uma destas opções o spamassassin será treinado automaticamente.

Abaixo estão as capturas de tela demonstrando a funcionalidade no Roundcube:

Marcar como Não Spam:

Captura de tela de 2013-09-10 15:39:44

Marcar como SPAM:

Captura de tela de 2013-09-10 15:40:04

Dovecot: Mover SPAM automaticamente para a pasta desejada

Quem implementa uma solução anti-spam em seu ambiente, certamente pode desejar mover automaticamente as mensagens marcadas como SPAM  para uma pasta específica do usuário, muitas vezes isto é feito através do Procmail, porém é possível efetuar essa configuração diretamente no Dovecot (Se o estiver utilizando para armazenamento das caixas postais, obviamente), não sendo necessário incluir mais um componente no ambiente.

No Dovecot essa configuração é possível utilizando o serviço SIEVE ( para mais informações: http://wiki.dovecot.org/LDA/Sieve), assumindo que você já o tenha configurado no seu Dovecot, basta modificar a diretiva plugin incluindo a linha abaixo:

plugin {

sieve_global_path = /var/lib/dovecot/default.sieve

}

O script que irá mover as mensagens marcadas como SPAM automaticamente é este, portanto você deve alterar o arquivo configurado no sieve_global_path da seguinte forma:

require [“fileinto”];

# rule:[Move Spam to Junk Folder]
if header :is “X-Spam-Flag” “YES”
{
fileinto “Spam”;
stop;
}

Caso deseje mover para uma outra pasta, como Junk que é muito utilizada, basta substituir o nome da pasta após o fileinto.

Postfix: Copiar mensagens de remetentes ou destinatários específicos

Olá ! Quem trabalha com qualquer MTA conhece o recurso de copiar as mensagens que passam pelo servidor para um destinatário específico. No Postfix isso é feito com o parâmetro always_bcc, porém as vezes precisamos auditar somente o que alguns usuários  enviam ou recebem. Para isso, temos os parâmetros recipient_bcc_maps e sender_bcc_maps, onde podemos especificar usuários que terão suas mensagens recebidas ou enviadas, respectivamente, copiadas.

Vejamos um exemplo desta implementação:

Edite o arquivo main.cf da seguinte forma:

recipient_bcc_maps = hash:/etc/postfix/recipient_bcc
sender_bcc_maps = hash:/etc/postfix/sender_bcc

No arquivo recipient_bcc nós colocamos os usuários que queremos que suas mensagens recebidas serão copiadas, e no arquivo sender_bcc, a mesma lógica para as mensagens enviadas. Vamos supor que queiramos copiar todas as mensagens enviadas por fabio@teste.com.br e todas as mensagens recebidas pelo usuario@teste.com.br para o auditor@teste.com.br:

/etc/postfix/recipient_bcc:

usuario@teste.com.br              auditor@teste.com.br

/etc/postfix/sender_bcc

fabio@teste.com.br                 auditor@teste.com.br

 

Após efetuar a configuração no main.cf e criar os arquivos, basta executar o postmap nos mesmos e efetuar o reload no serviço do Postfix.

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.