[Postfixbuch-users] policyd-weight: Fehlalarm?

[Peer Heinlein]

Hallo Robert,
hallo Rest der Welt.

Ich mißbrauche die Liste mal kurz als policyd-weight-Liste.

Ich habe ein Problem mit folgender Ablehnung:

/var/log/mail-20080204.bz2:Feb  3 22:15:05 weizen 
postfix/policyd-weight[23717]: weighted check:  
NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 
CL_IP_NE_HELO=1.5 CL_SEEMS_DIALUP=3.75 REV_IP_EQ_HELO=-1.25 
NOK_HELO_SEEMS_DIALUP=5 (check from: .win. - 
helo: .lvps87-230-24-220.dedicated.hosteurope. - 
helo-domain: .hosteurope.)  FROM_NOT_FAILED_HELO(DOMAIN)=6.75 
<client=87.230.24.220> <helo=lvps87-230-24-220.dedicated.hosteurope.de> 
<from=xy at kundendomain.ch> <to=abc at anderedomain.ch>, rate: 11.25

Mir fällt etwas schwer zu Begründen, was dem Absender vorzuwerfen ist, so 
daß seine Mail korrekterweise geblockt worden ist.

Klar, logisch, ein Hostname lvps87-230-24-220.dedicated.hosteurope.de ist 
für einen Mailserver zumindest "unglücklich" -- aber das alleine kann ja 
keine Begründung sein, zumal sich der Client auch völlig korrekt im HELO 
mit exakt diesem Namen gemeldet hat. HELO, Reverse-PTR und A-Record 
stimmen alle sauber überein -- geradezu mustergültig.

Okay, offensichtlich wurde das ganze als DynIP verstanden -- man sollte 
hier mal "dedicated" als Ausschluß-Wort in das entsprechende 
RegExp-Pattern nachpatchen. Das würde ich jetzt mal quasi als kleinen Bug 
werten.

Aber trotzdem: Nur die Tatsache, daß er den Namen als Dialup-IP verstanden 
hat, darf policyd-weight ja nicht zur Ablehnung bringen!

Ich muß gestehen, daß ich auch nach dem ersten Lesen des Quellcodes nicht 
ganz verstanden habe, was er hier dem Client warum vorwirft:


CL_SEEMS_DIALUP=3.75  -- Logisch. Falsch, aber nachvollziehbar.

CL_IP_NE_HELO=1.5 -- soll das "Client IP not equal HELO" heißen? Das würde 
ich ja auch akzeptieren, aber sollten hier doch keine Punkte vergeben 
werden, wenn sich der Client völlig korrekt mit seinem Reverse-Lookup 
meldet und es darum keinerlei Grund gibt, warum er sich mit seiner IP im 
HELO melden sollte. -Das würde ja theoretisch durch REV_IP_EQ_HELO wieder 
aufgehoben werden, allerdings verbleibt hier ein Restscore von 0.25 
Punkten.

NOK_HELO_SEEMS_DIALUP=5 -- was ist an diesem HELO "not okay"? Einen 
gefakten kaputten HELO mit Strafpunkten zu belegen, wenn er nach Dialup 
aussieht, sehe ich ja ein. Aber diese HELO ist doch tipptopp fehlerfrei! 
Was soll hier nicht okay sein?!

FROM_NOT_FAILED_HELO(DOMAIN)=6.75 -- hat natürlich auch nochmal schön 
rein. Ist ja auch verständlich und korrekt, wenn der HELO Murks ist. Ist 
er aber doch nicht. Laut Quelltext läuft das unter "check totaly failed 
helos" und scheint damit eine erneute Spätfolge des "not okay"-HELO zu 
sein wie schon im Punkt darüber.


Insofern ist die alleinige Frage wohl: Was soll am HELO "not okay" sein? 
Oder ist das alles nur ein unglücklicher Bug?


@Robert: Können wir nicht mal eine Initiative starten, die die 
Rückmeldungen des policyd-weight aufräumt und verständlicher macht? Hier 
wurde zurückgegeben:

Feb  3 22:15:05 weizen postfix/policyd-weight[23717]: decided action=550 
Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to 
correct HELO and DNS MX settings or to get removed from DNSBLs; MTA helo: 
lvps87-230-24-220.dedicated.hosteurope.de, MTA hostname: 
lvps87-230-24-220.dedicated.hosteurope.de[87.230.24.220] (helo/hostname 
mismatch); Please use DynDNS; delay: 0s


Und das finde ich für den Laien (und auch mich) schwer verständlich / 
nicht nachvollziehbar. 

-Oft wird pauschal "or to get removed from DNSBLs" ausgegeben -- obwohl 
die hier doch gar keine Rolle spielen und alles einwandfrei ist. Schon 
das macht es oft verwirrend weil unklar ist, WAS denn nun vorgeworfen 
wird, wenn da ein "or" in der Mitte steht...

-Ein helo/hostname-mismatch wird zitiert, obwohl die perfekt "matchen". 
Auch dann würde ich bei einem echten mismatch eine Erklärung passender 
finden: "HELO hostname *MUST* match reverse-lookup. Ask your 
Mail/DNS-Administrator to correct settings" o.ä.  Der Verweis auf den 
mismatch ist für mich zu versteckt, bzw. kapiert der Laie nicht, was ihm 
das sagen soll.


Ich würde es sehr begrüßen, wenn man hier mal aufräumen könnte und ggf. 
auch einfach eine Datenbank mit Ursachen für die Fehlermeldungen aufbauen 
könnte, auf die dann verwiesen werden kann. Ich würde mich hier gerne 
beteiligen. Wenn ich helfen kann -- gerne.

Lieben Gruß

Peer



-- 
Heinlein Professional Linux Support GmbH
Linux: Akademie - Support - Hosting

http://www.heinlein-support.de

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg, 
Geschäftsführer: Peer Heinlein  -- Sitz: Berlin