[Postfixbuch-users] SpamAssassin - TrustPath und Bayes von einander abhängig?

So Mär 24 16:37:30 CET 2013

Hallo!

Unser Server hat heute in kurzer Folge eine Mail als Spam geblockt und 
kurz darauf eine Mail vom gleichen Absender durchgelassen, wobei sich 
mir gerade nicht erschließt warum es in dieser Reihenfolge passiert ist. 
Insbesondere kann ich mir nicht erklären warum SpamAssassin den Trust 
Path der Mails einmal richtig und einmal falsch erkennt.

Das mail.log sieht wie folgt aus:

Mar 24 09:18:44 submit-ev postfix/smtpd[12283]: NOQUEUE: 
client=xxxxx.dip.t-dialin.net[84.185.xxx.xxx], sasl_method=PLAIN, 
sasl_username=user_xxx
Mar 24 09:18:45 submit-ev amavis[8615]: (08615-19) Blocked SPAM, 
[84.185.xxx.xxx] [84.185.xxx.xxx] <user_xxx at submit-ev.de> -> 
<user_yyy at submit-ev.de>, <user_zzz at submit-ev.de>, quarantine: 
L/spam-LpFdEG7ybDN3.gz, Message-ID: <xxxxxxxx.1020308 at submit-ev.de>, 
mail_id: xxxxxxxxx, Hits: 6.814, size: 1325, 1160 ms
Mar 24 09:18:58 submit-ev postfix/smtpd[12283]: disconnect from 
xxxxxxx.dip.t-dialin.net[84.185.xxx.xxx]
Mar 24 09:35:28 submit-ev postfix/smtpd[12361]: NOQUEUE: 
client=xxxxx.dip.t-dialin.net[84.185.xx.xxx], sasl_method=PLAIN, 
sasl_username=user_xxx
Mar 24 09:35:29 submit-ev postfix/smtpd[12366]: 27EE58C0D8: 
client=xxxxx.dip.t-dialin.net[84.185.xxx.xxx]
Mar 24 09:35:29 submit-ev amavis[12352]: (12352-01) Passed CLEAN, 
[84.185.xxxx.xxx] [84.185.xxx.xxxx] <user_xxx at submit-ev.de> -> 
<user_yyy at submit-ev.de>, Message-ID: <xxxxx.8090504 at submit-ev.de>, 
mail_id: xxxxxxxxxxx, Hits: -2.9, size: 795, queued_as: 27EE58C0D8, 444 ms
Mar 24 09:35:29 submit-ev postfix/smtpd[12361]: disconnect from 
xxxxxxx.dip.t-dialin.net[84.185.xxx.xxx]

Amavis-new ist pre-queue geschaltet und rejected SPAM-Mails direkt. Die 
Configs von SA und Amavis unterscheiden sich nicht wesentlich vom 
Standard und es gab bisher keine Probleme damit. Razor, Pyzor, o.ä. wird 
nicht verwendet. SA erkennt nicht, dass 84.185.xxx.xxx die IP des 
einliefernden Clients ist und sie eigentlich ignoriert werden kann. Ich 
vermute, dass die RBLs auf die dynamische Telekom-IP angesprungen sind.

Der Header der als SPAM erkannten Mail sieht wie folgt aus:

Die Mail wurde vom Client auf unseren Server eingeliefert und hätte 
server-intern ausgeliefert werden sollen. Auffällig ist, dass der Bayes 
anschlägt und die Mail kein ALL_TRUSTED bekommt.
Der User hat mich kurz darauf hin benachrichtigt (2. Mail im log oben), 
über den gleichen Account und abermals server-intern:

X-Spam-Status: No, score=-2.9 required=4 tests=[ALL_TRUSTED=-1, 
BAYES_00=-1.9]
     autolearn=disabled
Received: from mail.submit-ev.de ([127.0.0.1])
     by localhost (submit-ev.de [127.0.0.1]) (amavisd-new, port 10024)
     with ESMTP id xxxxxxxxx for <user_yyy at submit-ev.de>;
     Sun, 24 Mar 2013 09:35:28 +0100 (CET)
Received: from [192.168.2.90] (xxxxxxx.dip.t-dialin.net [84.185.xxx.xxx])
     by mail.submit-ev.de (Postfix) with ESMTPSA
     for <user_yyy at submit-ev.de>; Sun, 24 Mar 2013 09:35:28 +0100 (CET)

Der Spam-Header der Mail ist vollkommen sauber und obwohl sich am 
restlichen Header bis auf ein paar IDs und das Datum praktisch nichts 
geändert hat wird hier der Trust path hier richtig erkannt und 
ALL_TRUSTED gesetzt. Ich kann mir das nicht erklären, da alle IPs gleich 
geblieben sind und der zeitliche Abstand minimal ist. Es stechen zwei 
Unterschiede ins Auge: Ein Mal springt der Bayes an und ein Mal nicht. 
Außerdem hatte die als SPAM markierte Mail noch jemanden 
(user_zzz at submit-ev.de) im CC stehen.

Versionen:
amavisd-new 1:2.6.4-3
spamassassin 3.3.1-1

Könnt ihr euch erklären was hier passiert ist? Kann ich etwas tun, um 
solche Probleme in Zukunft zu verhindern?

Viele Grüße

Patrick