[postfix-users] recipient verification caching
lst_hoe02 at kwsoft.de
lst_hoe02 at kwsoft.de
Do Okt 28 11:34:28 CEST 2010
Zitat von alex handle <alex.handle at gmail.com>:
> Hallo Liste!
>
> Bin gerade dabei ein Mailgateway für ein paar externe Domains aufzubauen.
> Leider habe ich nicht die Möglichkeit die Accountdaten zu
> synchronisieren, deshalb habe ich
> mir gedacht ich löse das Problem mittels Recipient Verification.
> Möchte nämlich kein Backscatter-Source sein ;)
>
> Jetzt besteht leider nur das Problem die richtigen Einstellungen für
> das Caching der Empfängeradressen zu finden.
>
> Die Standardeinstellungen zum positiv Caching finde ich ziemlich gut,
> jedoch beim negativ Caching gibts noch Probleme.
>
> Generell wollte ich das negativ Caching deaktivieren, da ich denke,
> dass die Datenbank ziemlich schnell zugemüllt ist, und
> die meisten Spammer immer neue Adressen generieren, jedoch bei der
> Einstellung "address_verify_negative_cache = no"
> wird immer beim 1. Versuch ein temporärer Fehler zurück gegeben, dies
> möchte ich jedoch vermeiden.
Sollte nicht so sein, eventuell ist der smtp timeout zu kurz
eingestellt oder der "verify" Eintrag in master.cf hat ein process
limit welches zu niedrig ist.
> Ich habe mir auch den Parameter "address_verify_negative_refresh_time
> = 3h" angesehen.
> Wenn ich das richtig verstanden habe prüft Postfix jede nicht
> existierende Adresse alle 3 Stunden am Backend-Server.
> Falls es die Adresse auf einmal doch gibt wird die expire-time
> abgwartet ansonsten wird die expire-time erneuert?
Nein, refresh meint aber diesem Zeitpunkt geht Postfix davon aus das
der Eintrag erneut geprüft werden müsste. Falls dies nicht
funktioniert wird er einfach weiter verwendet. Die expire time gibt an
ab wann der Eintrag aus der Cache Datenbank enfernt wird d.h. danach
gar nicht mehr verwendet werden kann.
> Bei einer dictionary attack würde das ja bedeuten, dass erstmal alle
> nicht gültigen Adressen in der Verfify DB landen, und dann noch
> alle 3 Stunden auf dem Backend-Server verifiziert werden. Das würde ja
> heißen, dass die Attacke den Backend-Server mehrmals belastet.
Die Adressen werden nur dann erneut verifiziert wenn die gleiche
Adresse nach über 3h erneut angefragt wird. Bei Spam Einmaladressen
fallen sie einfach nach der expire time aus der DB.
> Hab ich hier was komplett falsch verstanden?
Nicht komplett, aber in Details...
> Wie löst ihr das Problem in der Praxis?
> Was wären hier die optimalen Einstellungen um die DB nicht zuzumüllen
> und die Backend-Server nicht zu sehr zu belasten.
Generell ist es nur bei Servern mit sehr geringer Connect Rate
sinnvoll einen "langsamen" Adressen lookup durchzuführen. Die Probleme
sind folgende:
- Eine Dictionary Attack übersteht so etwas nicht bzw. diese wir an
die eigentlichen Zielserver durchgereicht.
- Das System ist Abhängig von der Verfügbarkeit der externen System
die Abgefragt werden.
- Es verdoppelt die Anzahl der benötigten Prozesse.
> Mein Idee wäre folgende:
>
> address_verify_negative_expire_time = 2h
> address_verify_negative_refresh_time = 3h
>
> Alle negativ Einträge werden nur 2 Stunden gecached, dann autom. gelöscht.
> Die refresh_time ist größer als die expire_time und ein Refresh kommt
> deshalb nie zustande.
Macht keinen Sinn. Wie oben erklärt wird ein refresh eh nur bei
erneutem auftauchen der Adresse durchgeführt. Also einfach expire auf
einen etwas niedrigeren Wert stellen und gut ist. Eventuell Postfix
2.7 in betracht ziehen, dort kann eine dateibasierte DB verwendet
werden die dann auch deutlich größer werden darf.
Gruß
Andreas
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : smime.p7s
Dateityp : application/pkcs7-signature
Dateigröße : 6046 bytes
Beschreibung: S/MIME Cryptographic Signature
URL : <http://de.postfix.org/pipermail/postfix-users/attachments/20101028/c3d486a0/attachment.bin>
Mehr Informationen über die Mailingliste postfix-users