CentOS + Qmail-Toaster = SpamHaus/SpamCop com Score
Dica publicada em Linux / Correio Eletrônico
CentOS + Qmail-Toaster = SpamHaus/SpamCop com Score
Ambiente: Linux CentOS 5.0 com pacote Qmail-Toaster
Problema: usando o cliente de email, estava sendo barrado o envio de IPs que estavam em blacklist nos servidores do SpamHaus e SpamCop, pois é feita a verificação antes mesmo da autenticação.
Solução: implementar a verificação de blacklist do SpamCop e SpamHaus no Spamassassin para computar como um score alto o bastante para ocorrer o reject do email. Com o Spamassassin no ambiente que tenho libera relay para os domínio que tenho localmente, não haverá problema no envio.
1) editar arquivo /etc/mail/spamassassin/local.cf, habilitando no spamassassin para verificar blacklists:
2) adicionar as linhas abaixo ao final do arquivo com relação à consulta e score das regras:
3) caso deseje, pode alterar as regras no diretório /usr/share/spamassassin/, comentando as que fazem referência à SpamCop e SpamHaus. Fiz para não ficar redundante. A razão por ter feito as duas listas de forma manual foi por que assim pude customizar o score.
4) refaça os arquivos cdb.
sudo qmailctl cdb
Resultado:
Reloaded /etc/tcprules.d/tcp.smtp
Reloaded /var/qmail/control/badmimetypes.cdb
Reloaded /var/qmail/control/badloadertypes.cdb
Reloaded /var/qmail/control/simversions.cdb
Reloaded /var/qmail/control/simcontrol.cdb
5) pode ser feito o reload, mas não é em todas as distribuições que adianta, portanto, faça:
sudo qmailctl stop
$ sudo qmailctl start
6) no meu caso, a consulta e o bloqueio do IP é feita através do tcp.rules, sendo assim, editei o arquivo:
sudo vi /etc/tcprules.d/tcp.smtp
7) a linha que trata a conexão vinda por tcp.smtp ficou assim:
O bloqueio dos emails através da verificação no SPAMCOP e SPAMHAUS antes da autenticação reduz a utilização do processamento do servidor, uma vez que nem ao menos passa pelas regras. Nessa solução, tive que sacrificar um pouco o processamento. Os emails antes que nem entravam no servidor, por estar em blacklist, agora entram para serem processados. No meu caso, os fins justificaram os meios.
Problema: usando o cliente de email, estava sendo barrado o envio de IPs que estavam em blacklist nos servidores do SpamHaus e SpamCop, pois é feita a verificação antes mesmo da autenticação.
Solução: implementar a verificação de blacklist do SpamCop e SpamHaus no Spamassassin para computar como um score alto o bastante para ocorrer o reject do email. Com o Spamassassin no ambiente que tenho libera relay para os domínio que tenho localmente, não haverá problema no envio.
1) editar arquivo /etc/mail/spamassassin/local.cf, habilitando no spamassassin para verificar blacklists:
skip_rbl_checks 0
2) adicionar as linhas abaixo ao final do arquivo com relação à consulta e score das regras:
# SPAMHAUS blacklist
header RCVD_IN_XBL_SPAMHAUS_ORG eval:check_rbl_txt('zen', 'zen.spamhaus.org.')
describe RCVD_IN_XBL_SPAMHAUS_ORG Received via a relay in zen.spamhaus.org
tflags RCVD_IN_XBL_SPAMHAUS_ORG net
# Colocar score maior do que está em required_score. Caso queira dropar o email, colocar
# acima do que está em spam_hits no arquivo /var/qmail/control/simcontrol
score RCVD_IN_XBL_SPAMHAUS_ORG 25.0
# SPAMCOP
header RCVD_IN_SPAMCOP__NET eval:check_rbl_txt('spamcop', 'bl.spamcop.net.', '(?i:spamcop)')
describe RCVD_IN_SPAMCOP__NET Received via a relay in zen.spamcop.net
tflags RCVD_IN_SPAMCOP__NET net
# Colocar score maior do que está em required_score. Caso queira dropar o email, colocar
# acima do que está em spam_hits no arquivo /var/qmail/control/simcontrol
score RCVD_IN_SPAMCOP__NET 25.0
header RCVD_IN_XBL_SPAMHAUS_ORG eval:check_rbl_txt('zen', 'zen.spamhaus.org.')
describe RCVD_IN_XBL_SPAMHAUS_ORG Received via a relay in zen.spamhaus.org
tflags RCVD_IN_XBL_SPAMHAUS_ORG net
# Colocar score maior do que está em required_score. Caso queira dropar o email, colocar
# acima do que está em spam_hits no arquivo /var/qmail/control/simcontrol
score RCVD_IN_XBL_SPAMHAUS_ORG 25.0
# SPAMCOP
header RCVD_IN_SPAMCOP__NET eval:check_rbl_txt('spamcop', 'bl.spamcop.net.', '(?i:spamcop)')
describe RCVD_IN_SPAMCOP__NET Received via a relay in zen.spamcop.net
tflags RCVD_IN_SPAMCOP__NET net
# Colocar score maior do que está em required_score. Caso queira dropar o email, colocar
# acima do que está em spam_hits no arquivo /var/qmail/control/simcontrol
score RCVD_IN_SPAMCOP__NET 25.0
3) caso deseje, pode alterar as regras no diretório /usr/share/spamassassin/, comentando as que fazem referência à SpamCop e SpamHaus. Fiz para não ficar redundante. A razão por ter feito as duas listas de forma manual foi por que assim pude customizar o score.
4) refaça os arquivos cdb.
sudo qmailctl cdb
Resultado:
Reloaded /etc/tcprules.d/tcp.smtp
Reloaded /var/qmail/control/badmimetypes.cdb
Reloaded /var/qmail/control/badloadertypes.cdb
Reloaded /var/qmail/control/simversions.cdb
Reloaded /var/qmail/control/simcontrol.cdb
5) pode ser feito o reload, mas não é em todas as distribuições que adianta, portanto, faça:
sudo qmailctl stop
$ sudo qmailctl start
6) no meu caso, a consulta e o bloqueio do IP é feita através do tcp.rules, sendo assim, editei o arquivo:
sudo vi /etc/tcprules.d/tcp.smtp
7) a linha que trata a conexão vinda por tcp.smtp ficou assim:
:allow,REQUIREDAUTH="",BADMIMETYPE="",BADLOADERTYPE="M",\\
CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",\\
QMAILQUEUE="/var/qmail/bin/simscan",NOP0FCHECK="1"
CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",\\
QMAILQUEUE="/var/qmail/bin/simscan",NOP0FCHECK="1"
O bloqueio dos emails através da verificação no SPAMCOP e SPAMHAUS antes da autenticação reduz a utilização do processamento do servidor, uma vez que nem ao menos passa pelas regras. Nessa solução, tive que sacrificar um pouco o processamento. Os emails antes que nem entravam no servidor, por estar em blacklist, agora entram para serem processados. No meu caso, os fins justificaram os meios.