[Postfixbuch-users] policyd-weight: Fehlalarm?
Robert Felber
r.felber at ek-muc.de
Sa Feb 9 12:30:36 CET 2008
On Sat, Feb 09, 2008 at 12:27:03PM +0100, Robert Felber wrote:
> 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
eh, spamtrap at user3.tld war gemeint, soll soviel heissen wie,
nur die anzahl an unterschieldichen spamtrap-empfaenger domains ist
wichtig, nicht die anzahl der mails an eine einzelne spamtrap
> -> ...
>
>
> 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
> --
> _______________________________________________
> Postfixbuch-users -- http://www.postfixbuch.de
> Heinlein Professional Linux Support GmbH
>
> Postfixbuch-users at listi.jpberlin.de
> https://listi.jpberlin.de/mailman/listinfo/postfixbuch-users
--
Robert Felber (PGP: 896CF30B)
Munich, Germany
Mehr Informationen über die Mailingliste Postfixbuch-users