[Postfixbuch-users] rbl und rwl

[Daniel Luttermann]

Alois Kratochwill schrieb:

> Hallo Daniel,

>> Beide verfolgen einen anderen Ansatz,wobei sich postfwd flexibler
>> einsetzen lässt,da du relativ einfach neue Regeln mit verschiedenen
>> Aktionen implementieren kannst.

>> policyd-weight funktioniert nach der Installation bereits
>> "Out-of-the-Box", bei postfwd sollte man noch einiges anpassen,um gute
>> Ergebnisse zu erzielen.

>> Einen sinnvollen Grund zu einer Umstellung könnte ich dir nicht
>> nennen,da beide Policy-Server zuverlässig arbeiten - persönlich setze
>> ich wegen der Flexibilität postfwd ein.

> Ich habe postfix-policyd im Einsatz, nicht policyd-weight!

'tschuldigung,habe ich irgendwie durcheinander gebracht.

> postfix-policyd kann nicht mit RBL umgehen, deshalb ist reject_rbl_client im
> Einsatz. Mein Gedankenansatz lag im DNS-Cache: Einsparung von Traffic und
> vor allem Zeit[!].

Nun könnte ich dir einige Gründe für den Einsatz von postfwd nennen...

RBL's lassen sich ohne Probleme einbinden,auch lässt sich das
Cache-Verhalten etwas beeinflussen (TTL,cleanup...).

Nützlich sind auch die Statistiken von postfwd,mit welchen man schnell
sehen kann, wie oft welche Regeln treffend waren, wie hoch die
Cache-Hit Rate ist etc. (wird im Mail-Log protokolliert).

Man könnte mit postfwd (und auch policyd) ein effektives Regelwerk
aufbauen (selektives Greylisting in Abhängigkeit von RBL-Hits,
Hostname etc.) - Möglichkeiten gibt's da einige.

>> Auch verwende ich reject_rbl_client in Postfix nicht mehr,da ich dies
>> komplett an postfwd übergeben habe,um ggf. noch weitere Kriterien
>> (HELO,weitere RBL's...) prüfen zu können. Sinnvoll ist auch der
>> DNS-Cache,den beide Policy-Server zur Verfügung stellen.


Grüße,
Daniel

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : PGP.sig
Dateityp    : application/pgp-signature
Dateigröße  : 488 bytes
Beschreibung: nicht verfügbar
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20091124/c33d119d/attachment.sig>