[Postfixbuch-users] policyd-weight: Fehlalarm?

[Robert Felber]

On Fri, Feb 08, 2008 at 07:24:04PM +0100, Peer Heinlein wrote:
> 
> 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.
>

Okay, der Eintrag ist etwas aelter (3. Feb.) und das CL_IP_NE_HELO=1.5
trifft _heute_ nicht mehr zu.

Nichts destotrotz ergibt es heute:

20:37:10 info: weighted check:  NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 CL_IP_EQ_HELO_IP=-2 CL_SEEMS_DIALUP=3.75 HELO_SEEMS_DIALUP=4.5 (check from: .kundendomain. - helo: .lvps87-230-24-220.dedicated.hosteurope. - helo-domain: .hosteurope.)  FROM/MX_MATCHES_NOT_HELO(DOMAIN)=1.938 <helo_ips:  lvps87-230-24-220.dedicated.hosteurope.de 193.108.137.29 193.108.136.132 87.230.24.220>; <instance=87.230.24.220xy at kundendomain.ch> <client=87.230.24.220> <helo=lvps87-230-24-220.dedicated.hosteurope.de> <from=xy at kundendomain.ch> <to=>; rate: 3.688

Mit folgendem setting kommt der erstmal fix durch:

@enforce_dyndns_score             = (0,0);

20:41:16 info: weighted check:  NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 CL_IP_EQ_HELO_IP=-2 CL_SEEMS_DIALUP=3.75 (check from: .kundendomain. - helo: .lvps87-230-24-220.dedicated.hosteurope. - helo-domain: .hosteurope.)  FROM/MX_MATCHES_NOT_HELO(DOMAIN)=1.938 <helo_ips:  lvps87-230-24-220.dedicated.hosteurope.de 193.108.137.29 193.108.136.132 87.230.24.220>; <instance=87.230.24.220xy at kundendomain.ch> <client=87.230.24.220> <helo=lvps87-230-24-220.dedicated.hosteurope.de> <from=xy at kundendomain.ch> <to=>; rate: -0.812


Ich nehms zum Anlass, die regex massiv zu entschaerfen (Auftauchen von IP-nummern in hostnames nicht
als Indikator herzunehmen - laesst sich einfach nicht sinnvoll generisch scoren).


> 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?

Ja

> 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?!

NOK weil nur der reverse hinhaut pluss eben im HELO als dialup
erscheint.

Warum der reverse kritisch ist, siehst du, wenn du 62.225.182.37 aufloest.
Habe ich eben mal von test.de auf mx.heinlein-support.de umgestellt.
 

> 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?


Aufgrund das eben der A record des HELOs Muell _war_ schlugen die Dialup
Checks heftiger zu, as konnte eben nur durch nicht vertrauenswuerdige
reverse records vermutet werden, dass der client zur helo, bzw sender
domain ghoert.

> 
> @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.

Wuerde ich auf jeden Fall bgruessen, ich warte auf Patches. Leider kommen
nur Patches, die Polw Aggressiver oder SPF-Faehig machen wollen.


-- 
    Robert Felber (PGP: 896CF30B)
    Munich, Germany