[Postfixbuch-users] policyd-weight: Fehlalarm?

[Robert Felber]

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