Spamassassin sinalizou algo como spam que não é spam. Como eu digo isso?

Question

Esta é uma espécie de pergunta geral sobre o treinamento do spamassassin. Eu tenho um servidor de e-mail recém-configurado que filtra as mensagens recebidas através do spamassassin. Recentemente, recebi uma reserva de voo marcada como spam (pontuação 5) e gostaria de dizer ao spamassassin que não é spam. (Talvez fazer isso também reenvie a correspondência sem os cabeçalhos de spamassassin modificados?)

Eu tentei pesquisar e estou apenas encontrando coisas sobre o spamassassin para marcar mensagens como spam (e não sobre como corrigir falsos positivos), ou para pessoas que escrevem e-mails - como não ser sinalizado como spam.

Então, no que diz respeito a dar feedback ao spamassassin em ligações erradas:

1. Existe uma maneira de fazer isso de dentro de um cliente de email (por exemplo: Thunderbird)

2. Existe uma maneira de fazer isso através da linha de comando no servidor de email?

Eu gostaria de tornar o processo o mais fluido possível, mas o que quer que seja feito.

Detalhes do SpamAssassin sobre o email:

 0.0 FSL_HELO_NON_FQDN_1    No description available.
 0.6 HK_RANDOM_ENVFROM      Envelope sender username looks random
-0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no trust [82.150.225.129 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H3      RBL: Good reputation (+3) [82.150.225.129 listed in wl.mailspike.net]
 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
 1.6 SUBJ_ALL_CAPS          Subject is all capitals
 1.1 MIME_HTML_ONLY         BODY: Message only has text/html MIME parts
 0.7 HTML_IMAGE_ONLY_20     BODY: HTML: images with 1600-2000 bytes of words
 0.0 HTML_MESSAGE           BODY: HTML included in message
-0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 0.0 UNPARSEABLE_RELAY      Informational: message has unparseable relay lines
 0.0 T_REMOTE_IMAGE         Message contains an external image

É evidente que os principais culpados são a linha de assunto de todas as letras maiúsculas SUBJ_ALL_CAPS e a MIME_HTML_ONLY (eu acho, nenhuma alternativa de texto).

O e-mail era para uma confirmação de reserva de voo e o assunto era assim:

 Subject: JENNINGS/NICHOLAS KOSSOW MR 24 JAN MOF DPS

Cabeçalhos:

X-Envelope-From: <[email protected]>
X-Envelope-To: <[email protected]>
Received: from mail1.amadeus.net (unknown)
    by 147-49-15-51.rev.cloud.scaleway.com(Postfix 3.1.0/8.13.0) with SMTP id unknown
    Fri, 20 Jan 2017 07:55:10 +0000
    (envelope-from <[email protected]>
Received: from obeap115 (nat-dns-mnp.amadeus.net [82.150.225.129])
    by mail1.amadeus.net (Postfix) with ESMTP id 3F7A9200042
    for <[email protected]>; Fri, 20 Jan 2017 07:55:10 +0000 (GMT)
From: [email protected]
TO: [email protected]
Message-ID: <CTS/GA/C50D54421A07/[email protected]>
FND-Request-ID: <CTS/GA/C50D54421A07/[email protected]>
Job-ID: 1
Subject: JENNINGS/NICHOLAS KOSSOW MR 24 JAN MOF DPS
Date: Fri, 20 Jan 2017 07:55:09 +0000
Content-Type: multipart/mixed; 
    boundary="----=_Part_191904_1900935199.1484898909762"
MIME-Version: 1.0

    

Answer 1

Há conselhos específicos e gerais que podem ser úteis neste caso.

Específico

O problema subjacente aqui é que a Garuda Airlines, que abençoa suas pequenas meias de algodão, está enviando e-mails de confirmação que trazem muitas das marcas registradas do spam. A linha de assunto é MUITO SHOUTY, eles enviam e-mails somente HTML que contêm muitas imagens e muito pouco texto, o envelope-remetente ( [email protected] ) é claramente um construtor fabricado por máquina e o provedor de e-mail é terceirizado ) o sistema de confirmação (amadeus.com) tem um registro SPF inútil (apesar de todos os nossos conselhos ao contrário , algumas pessoas pensam erroneamente existe um valor em um registro que lista alguns de seus sistemas de envio e termina ~all ).

Não há muito o que fazer sobre isso. Se você quiser ter certeza de que essas etapas serão concluídas, uma linha no seu ~/.spamassassin/user_prefs informa que whitelist_from *@amadeus.com enviará essas mensagens para você. Indo mais além e adulterando os pesos das regras que foram acionadas é provavelmente uma má ideia. O conjunto de regras SpamAssassin (SA) é criado filtrando um grande peso de spam e determinando quais características se aplicam à maior parte dele; é provável que você abra sua caixa de entrada para muito mais do que apenas os e-mails de confirmação da Garuda desativando essas regras.

Geral

Este é exatamente o tipo de situação em que o mecanismo Bayesiano lida bem. Ele foi projetado para filtrar e-mails que não acionam as outras regras, mas contém informações que você não deseja ler, enquanto ajuda com o e-mail que aciona essas regras, mas contém informações que você faz deseja ler .

IIRC, o motor não fará nada se você não estiver treinando. A maneira mais fácil de treiná-lo é manter duas pastas, chamadas (digamos) spam e ham . Em spam você colocou cópias de e-mail que foram colocadas na sua caixa de entrada, mas você não queria; em ham você colocou cópias de e-mails que foram reprovados pela SA, mas você queria, como este e-mail de confirmação.

Em seguida, todas as noites (ou mais) você tem um cron job que diz

sa-learn --spam --mbox mail/spam
sa-learn --ham  --mbox mail/ham

modificando os caminhos de acordo. Com o tempo, isso ensinará ao mecanismo o que você faz e não gosta de ler. Como uma pontuação Bayesiana alta pode adicionar +4,0 pontos à pontuação SA de um e-mail, enquanto uma pontuação baixa pode subtrair 1,9, um mecanismo bem treinado pode realmente ajudar a SA a diferenciar o que você quer ler do que > você não - mas você tem que se esforçar para ensiná-lo .

    

Answer 2

Você parece estar usando o dovecot. Passei algumas semanas tentando descobrir uma integração tranquila, que permite aos usuários treinar facilmente os filtros de spam do lado do servidor sem ter que copiar e-mails.

A parte principal é o Antispam do plug-in Dovecot. O plug-in antispam é acionado em operações mover entre três grupos de pastas: trash , unsure e spam . Especificamente, quando uma transição de qualquer coisa (mas spam ) para spam é detectada, uma ação de aprendizado de spam é acionada e quando uma transição de spam para unsure é detectada, uma ação de aprendizado de ham é acionada.

Ele suporta diferentes backends de treinamento. Um simples é mailtrain , que simplesmente executa um comando e coloca o correio na entrada padrão. Uma configuração para isso pode ser assim:

plugin {
   antispam_backend = mailtrain
   antispam_mail_sendmail = /usr/local/bin/sa-learn-stdin.sh
   antispam_mail_spam = spam
   antispam_mail_notspam = ham
   antispam_mail_sendmail_args = -L
   antispam_spam = Junk;INBOX.Junk
   antispam_trash = Trash;INBOX.Trash
   antispam_allow_append_to_spam = no
}

Juntamente com /usr/local/bin/sa-learn-stdin.sh :

#!/bin/bash
/usr/bin/spamc "$@" >> /tmp/sa-learn-log
exit 0

A configuração diz "Para aprender como spam, execute /usr/local/bin/sa-learn-stdin.sh -L spam e saiba como ham, execute /usr/local/bin/sa-learn-stdin.sh -L ham ." Os argumentos são configurados por antispam_mail_spam , antispam_mail_notspam e antispam_mail_sendmail_args .

Isso já é bem legal. Se você puder configurar seu cliente para mover e-mails que você marcou como spam na pasta de spam, isso já é uma integração bastante automática entre o cliente e o servidor. Da mesma forma, se você configurar o servidor para armazenar emails classificados como spam na pasta de spam na entrega (por exemplo, usando o Sieve), a mensagem será aprendida como presunto quando o usuário a mover da pasta Spam.

Para melhorar a integração com o Thunderbird e o KMail, eu escrevi um patch para o antispam , que infelizmente não obteve nenhum feedback do upstream; use por sua conta e risco .

Adiciona uma opção de configuração ao antispam, que pode ser simplesmente adicionada à seção plugin na configuração dovecot:

   antispam_spam_flags = "Junk;$JUNK"

(As aspas são importantes para evitar que o $ faça algo engraçado.)

Com o patch, o antispam também acionará uma ação de aprendizado se uma mensagem receber um sinalizador de spam ou perder todos os seus sinalizadores de spam. Sinalizadores são um recurso IMAP e usado por clientes para armazenar bits de informações do lado do servidor. Acontece que o Thunderbird e o KMail usam esses sinalizadores para armazenar o status de lixo / spam das mensagens.

O Junk flag é definido pelo Thunderbird quando você marca uma mensagem como lixo eletrônico. Da mesma forma para o $JUNK sinalizar um KMail. Assim, com essa configuração, você pode acionar o aprendizado do lado do servidor sinalizando o e-mail como Junk / NonJunk no Thunderbird no KMail.

Outros clientes, como o K9-Mail, ainda funcionam bem, porque o padrão é mover o lixo na pasta Spam, que o antispam também acionará.

Você pode implementar a mesma funcionalidade, eu acho, em IMAPSieve . Isso está no meu TODO, mas infelizmente eu atualmente não tenho um ambiente pronto para teste com um pombal suficientemente recente.