[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spamassassin-devel-br
Subject:    [SAbr] Re: Novo na lista
From:       "Ernesto Baschny" <ernst () baschny ! de>
Date:       2003-11-03 22:28:57
[Download RAW message or body]

On 3 Nov 2003 at 11:41, Marcio Merlone wrote:

> >   44% Spam em ingles
> >   20% Spam em portugues
> >    1% Spam em outras linguas (espanhol/alemao)
> >   30% Non-spam ingles
> >    2% Non-spam portugues
> >    3% Non-spam alemao

> Como vc gerou esta estatística? Algum script? Só pra saber, pode ser
> interessante...

Calculadora. Eu tenho separado o spam/ham ultimamente por línguas, entao
fica fácil fazer a análise. Já também estou em processo de fazer um 
script pra fazer o splitting de uma mailbox inteira por lingua
automaticamente, mas nao é 100% certo (o reconhecimento da lingua
estou fazendo com o módulo de perl Lingua::Ident, que exige um 
treinamento representativo para funcionar bem). Assim que tiver o 
script melhor, vou fazer o procmail separar o meu spam automaticamente
em portugues/alemao/outras-linguas.

> > A gente podia fazer algo parecido: Estabelecemos certas regras de 
> > repositórios particulares (no estilo CORPUS_POLICY),

> Hein? Que é CORPUS_POLICY?

Sao as regras gerais pra quem quer participar enviando os ham/spam.log
para a computacao global dos scores usando o GA. No diretório "masses"
da distribuicao do SA existem vários scripts pra esse fim, e tambem o
arquivo texto CORPUS_POLICY dizendo o que deve fazer (e o que nao) de
um corpo de emails spam e ham.

> Pelo que vejo, acho que poderíamos criar uma força-tarefa para gerarmos
> os hits-frequency de cada um e submetê-los à equipe mantenedora do SA.
> Acredito que só o que falta é mais colaboração brasileira sobre o SA
> para que ele fique mais capaz de enxergar os spams brasileiros. Ao invés
> de descentralizar o esforço, acho mais válido neste caso centralizarmos
> à equipe oficial. Nosso esforço seria gerar os hit-frequency. O tal
> "lugar central" para processar os dados seriam as já utilizadas pela
> equipe do SA, apenas teria os nossos dados juntos.
>
> Que te parece?

Me parece uma ótima idéia. Agora pelo menos num primeiro momento esse
"lugar central" nao vai calcular os scores para as nossas regras, uma
vez que elas ainda nao estao incluidas (e nem prontas pra serem) na
distribuicao. Entao pra essa combinacao de scores (distr + nossas)
precisariamos nós mesmos fazermos os calculos, pelo menos até que 
essas regras estejam nas maos dos desenvolvedores também.

Por falar nisso, também vai ter que haver um certo cuidado legal 
para incluir nossas regras no SA. O SA está caminhando para a Apache
License, e para que alguma coisa possa ser incluida, cada colaborador
precisa dar seu aval a essa licensa a Apache Org. Isso em forma escrita
(fax/carta), assinando um documento. Eu já tenho esse documento e nao
tenho problema de mandar pra la, agora é preciso ver quantos
colaboradores das regras do Lafraia realmente ainda se pode achar para
que possam dar seu OK (ou removermos as regras onde nao temos o OK).

> > > score    BR_KITNET_URI          0.8
> > > uri      BR_KITNET_URI          /\.kit\.net/i
> > > e também
> > > score    BR_FREEHOST_URI        0.8
> > > uri      BR_FREEHOST_URI        /\.freesites\.com\.br|netfirms\.com/i

> > A idéia até que é boa, mas o problema com isso é voce perde a descricao 
> > exata do problema no Spam-Header, e fica só com a informacao de que uma
> > URI foi detectada. Para efeito de calculo automático dos scores, tambem
> > imagino que uma diferenciacao de qual URI exatamente provocou o hit pode
> > ser bastante relevante, porque links com .kit.net podem ser menos nocivos
> > e com mais false positives do que netfirms.com por exemplo.

> Sei como é procurar a causa de um bloqueio mal-identificado. Mas esta
> regra não irá por si só causar o bloqueio da mensagem.

Nao é a questao do bloqueio ou nao, mas sim a questao do SCORE que cada
host vai receber. No momento o score é igual para kit.net ou
freesites.com (0.8), mas isso pode estar longe do ideal, uma vez que
isso pode ser calculado automaticamente pelo GA.

> Em caso de bloqueio, haverão outros testes também, todos indicados no
> heaer/logs.
> Eu sinceramente nunca vi uma mensagem legítima com kit dot net no corpo.

No meu corpus atual de ham tenho 4 de msgs legítimas com kit.net numa
URI, gente que manda link para algum recurso nesse servidor. Agora 
com BR_FREEHOST_URI nao tenho nenhum (nem spam nem ham), ou seja, aqui
o scoring provavelmente deve ser diferente.

As regras já estao agrupadas separadamente em BODY, HEADER e URI, e 
nesse grupo de URI nao é preciso ter tudo numa regra só, acho até bom
estar em várias regras para mais fácil edicao (adicionar e remover).

> A CRUZ: - Separar os uris para facilitar a identificação de bloqueio, e
> permitindo pesos diferentes para diferentes uris.
> A ESPADA: - Manter todos os uris em uma unica regra de forma a facilitar
> o gerenciamento do arquivo de regras, mais limpo e mais fácil edição.

Eu acho que cada URI (ou grupo de uris equivalentes) em uma regra até
mais fácil de gerenciar do que tudo em uma regular-expression só.

-- 
Ernesto Baschny <ernst@baschny.de>
 http://www.baschny.de - PGP: http://www.baschny.de/pgp.txt
 Sao Paulo/Brasil - Stuttgart/Germany
 Ernst@IRCnet - ICQ# 2955403



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Spamassassin-devel-br mailing list
Spamassassin-devel-br@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spamassassin-devel-br


[prev in list] [next in list] [prev in thread] [next in thread]