ASK - Active Spam Killer
Procurando por uma solução para controle de SPAM, instalei o conhecido SpamAssassin, após a instalação com os falsos positivos veio junto um tremendo problema, alguns emails importantes ficavam bloqueados pelo mesmo. Com uma pequena pressão de alguns usuários, me vi obrigado a gerar uma lista do que estava sendo bloqueado, fiz isso usando ask e sed ... mas não era funcional o bastante para alegrar a todos. Encontrei um explendido software escrito em Python, feito por Marco Paganini. Com este software desenvolvi em Python um Framework ao qual batizei com o nome de ASPF (Anti Spam Policy Framework), este software usa os recursos do ASK permitindo que o mesmo interaja com o SpamAssassin. Após alguns elogios, decidi portar o software do Marco Paganini para o FreeBSD, expero que esse port facilite a vida de alguns administradores de emails. Com muita alegria recebi um email do Pav Lucistnik confirmando meu port do software para controle de SPAM ASK (Active Spam Killer). A nota foi enviada por Marcelo Araujo (araujobsd?hotmail·com) , que enviou este link para mais detalhes.
O ASK é um dos sistemas que buscam proteger contra spam com respostas automáticas pedindo aos remetentes que confirmem suas identidades.
(postado por Augusto Campos)
Comentários dos leitores
Comentário de robsontex
27/11/05 16:27 - usuário registrado #4195
Black lists, Gray Lists ...: Tanto o conceito de black lists como de gray lists possuem suas desvantagens. No caso das gray lists, o problema está em saber quais servidores estarão preparados para receber uma mensagem de temporary delivery failure. Tanto servidores utilizados por pessoas normais podem não estar preparados (e assim, podem não reenviar a mensagem) como servidores utilizados por spammers podem continuar tentando enviar a mensagem, conseguindo a sua entrega. A meu ver, quanto mais o mecanismo de gray lists se disseminar, piores serão seus resultados.
Quanto ao ASK, realmente o número de spams que chegam às caixas dos usuários é próximo de zero. O ASK também é a solução que a organização onde eu trabalho utiliza e os resultados são muito bons, a despeito da reclamação inicial dos usuários. No entanto, como você disse, é uma solução bem traumática.
PS.: Não encontrei o endereço onde o framework pode ser encontrado.
Quanto ao ASK, realmente o número de spams que chegam às caixas dos usuários é próximo de zero. O ASK também é a solução que a organização onde eu trabalho utiliza e os resultados são muito bons, a despeito da reclamação inicial dos usuários. No entanto, como você disse, é uma solução bem traumática.
PS.: Não encontrei o endereço onde o framework pode ser encontrado.
Comentário de ricleite
27/11/05 17:23 - usuário registrado #4031
Uma solução menos taumática: Sabemos que os usuários não se acostumam muito bem com ideia de ter que confirmar o envio de e-mails, aliás usuários em geral nunca veem com bons olhos qualquer mudança que ocorra, para melhor ou pior. Somado a isso o problema que tem se tornado um verdadeiro teorema:
Toda solução anti-spam tem "tempo de validade". Porque o spammer sempre acha uma brecha. Por exemplo: quando eu mando uma mensagem para mim mesmo, eu gerallmente estou aberto a receber meus próprios e-mails (quem aqui nunca mandou um email com o subject teste e conteudo teste para si mesmo a fim de testar o servidor de e-mail ?). Um spamer poderia simplesmente colocar o 'sender' igual ao e-mail da vítima do spam.
De qualquer forma exite uma maneira para tornar essas soluções de anti-spam um pouco menos traumáticas. Habilitar que todos os e-mails que um usuário mande para determinado endereço adicione-o na whitelist. Assim o usuário cria uma whitelist sem muito esforço. Claro que envio de emails deve ser controlado por ips que possam fazer relay e até um bom smtp autenticado para evitar que um spamer futuramente habilite-se a si mesmo!
Alguem já viu o que acontece com uma lista de discussão quando colocamos uma solução parecida com ask no ar ? E quando se tenta mandar um email a um outro smtp que possua esta solução ? Eles ficam eternamente mandando emails pedindo confirmação ?
Realmente o problema de SPAM é pior do que parece.
Toda solução anti-spam tem "tempo de validade". Porque o spammer sempre acha uma brecha. Por exemplo: quando eu mando uma mensagem para mim mesmo, eu gerallmente estou aberto a receber meus próprios e-mails (quem aqui nunca mandou um email com o subject teste e conteudo teste para si mesmo a fim de testar o servidor de e-mail ?). Um spamer poderia simplesmente colocar o 'sender' igual ao e-mail da vítima do spam.
De qualquer forma exite uma maneira para tornar essas soluções de anti-spam um pouco menos traumáticas. Habilitar que todos os e-mails que um usuário mande para determinado endereço adicione-o na whitelist. Assim o usuário cria uma whitelist sem muito esforço. Claro que envio de emails deve ser controlado por ips que possam fazer relay e até um bom smtp autenticado para evitar que um spamer futuramente habilite-se a si mesmo!
Alguem já viu o que acontece com uma lista de discussão quando colocamos uma solução parecida com ask no ar ? E quando se tenta mandar um email a um outro smtp que possua esta solução ? Eles ficam eternamente mandando emails pedindo confirmação ?
Realmente o problema de SPAM é pior do que parece.
Comentário de robsontex
27/11/05 20:32 - usuário registrado #4195
ASK e spams: ricleite,
"Toda solução anti-spam tem "tempo de validade". Porque o spammer sempre acha uma brecha."
É verdade. Esse é a velha história do gato e do rato, a qual vale também para toda a área de segurança da informação.
"Um spamer poderia simplesmente colocar o 'sender' igual ao e-mail da vítima do spam."
Para contronar esse problema, o ASK chuta o balde :) Os e-mails enviados para você mesmo são descartados a menos que contenham uma string específica que você determina no arquivo de configuração.
"Alguem já viu o que acontece com uma lista de discussão quando colocamos uma solução parecida com ask no ar ?"
Xi... Isso aconteceu em uma lista do Debian e o pessoal ficou tão revoltado que retirou o pacote da distribuição.
"E quando se tenta mandar um email a um outro smtp que possua esta solução ? Eles ficam eternamente mandando emails pedindo confirmação ?"
Não. O ASK utiliza um cabeçalho SMTP específico nas suas mensagens para se identificar com um outro ASK. Se não me falha a memória, a entrada é X-AskVersion (ou algo do tipo). Você pode verificar no cabeçalho da mensagem de confirmação que ele envia. Alguém viu um furo de segurança aí? :)
"Toda solução anti-spam tem "tempo de validade". Porque o spammer sempre acha uma brecha."
É verdade. Esse é a velha história do gato e do rato, a qual vale também para toda a área de segurança da informação.
"Um spamer poderia simplesmente colocar o 'sender' igual ao e-mail da vítima do spam."
Para contronar esse problema, o ASK chuta o balde :) Os e-mails enviados para você mesmo são descartados a menos que contenham uma string específica que você determina no arquivo de configuração.
"Alguem já viu o que acontece com uma lista de discussão quando colocamos uma solução parecida com ask no ar ?"
Xi... Isso aconteceu em uma lista do Debian e o pessoal ficou tão revoltado que retirou o pacote da distribuição.
"E quando se tenta mandar um email a um outro smtp que possua esta solução ? Eles ficam eternamente mandando emails pedindo confirmação ?"
Não. O ASK utiliza um cabeçalho SMTP específico nas suas mensagens para se identificar com um outro ASK. Se não me falha a memória, a entrada é X-AskVersion (ou algo do tipo). Você pode verificar no cabeçalho da mensagem de confirmação que ele envia. Alguém viu um furo de segurança aí? :)
Comentário de ricleite
28/11/05 15:13 - usuário registrado #4031
:
Não. O ASK utiliza um cabeçalho SMTP específico nas suas mensagens para se identificar com um outro ASK. Se não me falha a memória, a entrada é X-AskVersion (ou algo do tipo). Você pode verificar no cabeçalho da mensagem de confirmação que ele envia. Alguém viu um furo de segurança aí? :)
É vc está certo, tem que testar, mas pode ser que baste adicionar o tal cabeçalho que o ASK ignora como spam !!!
É como abrir relay pra uma faixa de ips de usuários hj em dia pensando que de lá não sai spam !! Nossos usuários não só as vezes "tentam" mandar spam como também acham a coisa mais normal do mundo !!! (ué !! todo mundo faz !!)
Péssimo isso !
As vezes eu fico pensando se não é hora de um novo protocolo de SMTP !! Este que está ae é dá época que se transferia via ascii em linhas seriais (tem quase a minha idade! )!! Até a "parte" de enviar anexo é na verdade uma grande gambiarra e não faz parte da especificação do SMTP. (vide rfc821 http://www.faqs.org/rfcs/rfc821.html).
Se vcs examinarem essa RFC verão que até colocar o Subject no e-mail não faz parte da especificação (vc simplesmente coloca junto com o corpo do email a palavra Subject: e coloca o dito cujo na frente).
Quanto ao problema de inserir um anexo ele é convertido a um monte de bytes visíveis em ascii o que torna o email 3x maior que o arquivo a ser anexado !!
Sem falar que emails de mais de 2M são um problema mesmo em internet médiamente rápida...
Eu pensei em fazer um proxy tipo o assp para "desanexar" os anexos e coloca-los em contas de FTP tempo?arias. Ae o email original seria alterado e ficaria com links para os arquivos tipo ftp://usertemp:senhatemp@dominio/arquivo/-anexo.zip. emails maiores que 1.5Mb entrariam nessa...
Estou sofrendo aki com inflex + mysql + clamav + um_monte_de_alterações_feitas_por_mim para resolver este problema do spam e sempre ele dura muito pouco tempo funcionando bem, atualmente estou tentando fazer isso rodar como o ask...
Não. O ASK utiliza um cabeçalho SMTP específico nas suas mensagens para se identificar com um outro ASK. Se não me falha a memória, a entrada é X-AskVersion (ou algo do tipo). Você pode verificar no cabeçalho da mensagem de confirmação que ele envia. Alguém viu um furo de segurança aí? :)
É vc está certo, tem que testar, mas pode ser que baste adicionar o tal cabeçalho que o ASK ignora como spam !!!
É como abrir relay pra uma faixa de ips de usuários hj em dia pensando que de lá não sai spam !! Nossos usuários não só as vezes "tentam" mandar spam como também acham a coisa mais normal do mundo !!! (ué !! todo mundo faz !!)
Péssimo isso !
As vezes eu fico pensando se não é hora de um novo protocolo de SMTP !! Este que está ae é dá época que se transferia via ascii em linhas seriais (tem quase a minha idade! )!! Até a "parte" de enviar anexo é na verdade uma grande gambiarra e não faz parte da especificação do SMTP. (vide rfc821 http://www.faqs.org/rfcs/rfc821.html).
Se vcs examinarem essa RFC verão que até colocar o Subject no e-mail não faz parte da especificação (vc simplesmente coloca junto com o corpo do email a palavra Subject: e coloca o dito cujo na frente).
Quanto ao problema de inserir um anexo ele é convertido a um monte de bytes visíveis em ascii o que torna o email 3x maior que o arquivo a ser anexado !!
Sem falar que emails de mais de 2M são um problema mesmo em internet médiamente rápida...
Eu pensei em fazer um proxy tipo o assp para "desanexar" os anexos e coloca-los em contas de FTP tempo?arias. Ae o email original seria alterado e ficaria com links para os arquivos tipo ftp://usertemp:senhatemp@dominio/arquivo/-anexo.zip. emails maiores que 1.5Mb entrariam nessa...
Estou sofrendo aki com inflex + mysql + clamav + um_monte_de_alterações_feitas_por_mim para resolver este problema do spam e sempre ele dura muito pouco tempo funcionando bem, atualmente estou tentando fazer isso rodar como o ask...
Apesar disto, uma solução anti-spam usando Spamhaus (SBL+XBL), SURBL e SpamAssassin é uma das menos traumáticas e ainda apresenta bons resultados.
Sugiro o guia "Effective Spam Filtering" do Spamhaus: http://www.spamhaus.org/effective_filtering.html
Quanto ao seu framework, parabenizo pela iniciativa e vou testá-lo assim que tiver oportunidade.