[Postfixbuch-users] policyd-weight: Fehlalarm?

[Robert Felber]

On Sat, Feb 09, 2008 at 11:48:45AM +0100, Peer Heinlein wrote:
> Am Freitag, 8. Februar 2008 schrieb Robert Felber:
> 
> 
> > Okay, der Eintrag ist etwas aelter (3. Feb.) und das CL_IP_NE_HELO=1.5
> > trifft _heute_ nicht mehr zu.
> 
> Dann habe ich den nicht ganz verstanden.
> 
> Ich dachte, das würde bedeuten, daß Reverse-Lookup und HELO 
> übereinstimmen.
> 
> Soll aber wohl heißen, daß der A-Record des HELO nicht auf die Client-IP 
> zeigte?

Richtig. Weder der A/MX record des HELO noch der A/MX record des envelope
loesten zur Client IP auf - auch befand sich der Client nicht im /24er bzw
/16er Netz von A/MX (HELO/SENDER).

Was die Sache spooky macht, ist, dass der client hostname, den er vom
postfix bekam, nicht "unknown" war.

Ich schau grad durch, ob ich die Kette abkuerzen kann, und mich
zu allererst auf das Ergebnis von postfix verlasse, bevor ich selber losziehe
und DNS records einsammel.


> > 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).
> 
> Naja, wohl dann nur in zusammenhang mit den einschlägigen Stichwörtern 
> wie "dsl" oder "dialup" etc.

Selbst das sorgt fuer FPs, glaub mir. Es gibt auch statische hosts, die dsl,
ppp oder dialin haben. Im Endeffekt muss es andere Wege geben, als dialups
zu behandeln. Erfahrung: es sind immer dialup Behandlungen die zu
FPs per design (und nicht per bug) fuehren.



> Und was soll das in Deinem Beispiel it mx.heinlein-support.de?
> 
> Logisch, ich kann als PTR setzen, was ich will. Keine Frage. Aber der 
> Client HATTE hier doch völlig korrekt seinen Reverse-Lookup, wenn ich die 
> Logzeilen richtig verstanden habe. 

Wenn ich als PTR mx.heinlein-support.de setze, und helo mx.heinlein-support.de
setze, glaubst du mir also. Gut zu wissen.
Wie auch immer, das ist der Hintergrund, warum der Fall NUR reverse
matcht auf HELO, sonst nix, als untrusted (bzw NOK) behandelt wird.


> > Aufgrund das eben der A record des HELOs Muell _war_ schlugen die
> 
> Okay. Macht dann Sinn -- kann man jetzt aber eben nicht mehr richtig 
> nachviollziehen. Es wäre sinnvoll, wenn in diesen Fällen dann auch der 
> A-Record geloggt wird. Sonst kann man ja gar nichts mehr beweisen oder 
> naxhvollziehen.
> 
> > Dialup Checks heftiger zu, as konnte eben nur durch nicht
> > vertrauenswuerdige reverse records vermutet werden, dass der client zur
> > helo, bzw sender domain ghoert.
> 
> Okay, verstanden. Auch wenn mich sehr wundert, daß Hosteurope hier keine 
> richtigen A-Record gehabt haben soll?!

Siehe anderes Post, es gibt schon eine Diskrepanz zwischen dem, was
polw bei der Bewertung sagt, und dem, was polw loggt. Sah ich aber
in dieser Form das erste mal und ist fuer mich nicht reproduzierbar, was
die Sache erschwert.

 
> > Wuerde ich auf jeden Fall bgruessen, ich warte auf Patches. Leider
> > kommen nur Patches, die Polw Aggressiver oder SPF-Faehig machen wollen.
> 
> Ich kann leider kaum/kein Perl, aber ich kann gerne mal Vorschläge zur 
> Umformulierung der Texte machen.


Ich haette gern jemand, der sich die Muehe macht, policyd-weight
via CGI einbindbar zu machen.

> Ein aggressiveres polw würde ich mit *nicht* wünschen. Polw ist am oberen 
> Limit der Aggressivität. Es ist schon jetzt der Faktor, der als einziger 
> und am meisten Probleme macht. Das nehme ich gerne in Kauf, denn er macht 
> eigentlich nur Probleme bei Systemen, denen man auch was vorwerfen kann. 
> Insofern ist das ergebnis des polw (abgesehen von diesem Beispiel hier) 
> stets korrekt und nachvollziehbar. Aber es ist immerhin der Dienst, wo 
> ich alle meine Kunden explizit briefen muß, ob sie das *wirklich* 
> einsetzen wollen und das akzeptieren.
> 
> Und SPF... ach nö. SPF ist der letzte Schei...

Es hat schon einige sinnolle Anwendungsbereiche. Alleine die Moeglichkeit
zigtausend Forwardings zu setzen, machen es unbrauchbar, sogar fuers 
whitelisting (ja, man kann nach dem 10. forward abbrechen - dann wurden
aber 10 DNS lookups gemacht, und die smtpd freuen sich, dass policyd-weight
Ewigkeiten zum Antworten braucht). Im SA, wo man alle Zeit der Welt in der
Queue verbraten kann, seh ich's ein.



ICH haette ja gerne eine distributed spammer datenbank. Aber bitte nicht
nach Client, sondern nach 

 user at domain.tld -> spamtrap at user1.tld
                 -> spamtrap at user2.tld
                 -> spamtrap at user2.tld
                 -> ...


Wobei der user at domain.tld nur dann als Spammer gezaehlt wird wenn
die Client-MTA definitiv was mit domain.tld zu tun hat.

Damit erwischt man dann endlich auch mal die yahoo, gmail, msn etc spammer
ohne dass man die yahoo/gmail/msn domains/clients auf eine BL hievt.

Ich wuerde sogar dafuer zahlen.

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