[Postfixbuch-users] reject_unverified_sender
Sandy Drobic
postfixbuch-users at japantest.homelinux.com
So Dez 3 14:21:02 CET 2006
Andreas Meyer wrote:
> Ralf Hildebrandt <Ralf.Hildebrandt at charite.de> schrieb:
>
>> * Andreas Winkelmann <ml at awinkelmann.de>:
>>
>>>> Und deswegen darf dann auch nicht abgewiesen werden.
>>> Ja, aber das hat er doch auch nicht.
>> Andreas Meyer behauptete was anderes. Aber er hat sich ja geirrt.
>>
>
>
> Gibt es allgemeine Erfahrungswerte über Sender address verification?
>
> Wietse schreibt:
> Unfortunately, sender address verification cannot simply be turned
> on for all email - you are likely to lose legitimate mail from
> mis-configured systems. You almost certainly will have to set up
> white lists for specific addresses, or even for entire domains.
>
> Ich könnte mir vorstellen, daß es mühsam wäre, alle Systeme
> herauszufinden, die fehlkonfiguriert sind.
> Ist es besser, Sender address verification nur für frequently forged
> domains einzusetzen? Meinungen?
Leider sind es nicht unbedingt fehlkonfigurierte Systeme, sondern häufig
Maßnahmen, die einen regelrechten Krieg gegeneinander führen. :-((
Versuche einfach mal reject_unverified_sender gegen ein System
einzusetzen, das mit Greylisting arbeitet. Wenn du dann noch, wie häufig
empfohlen, die Ergebnisse, insbesondere die negativen, in einer lokalen
Datenbank ablegst, ist die Misere komplett.
Hier mal der Ausschnitt aus den Defaults:
address_verify_map =
address_verify_negative_cache = yes
address_verify_negative_expire_time = 3d
address_verify_negative_refresh_time = 3h
address_verify_poll_count = 3
address_verify_poll_delay = 3s
Wenn du nicht cached, dann ist es nicht ganz so wild, aber du hast
erheblich höhere Last für normale Überprüfungen und riskierst den Ärger
von aufmerksamen Admins anderer Systeme, die dein verify in Anspruch
nimmt. Deshalb wird empfohlen "address_verify_map =
btree:/etc/postfix/address_verify" (Beispiel) zu verwenden, um die Zahl
der Probemails gering zu halten.
Das passiert, wenn ein Client mit Greylisting eine Mail bei dir einliefern
will, und du reject_unverified_sender verwendest:
- Client verbindet sich zu dir, will Mail einliefern
- Du verbindest dich mit Client, willst Absenderadresse prüfen
- Client lehnt deine Probe mit Greylisting 4xx ab.
- Du lehnst Client wegen negativer Probe ab mit 4xx ab und cachest das
Resultat.
- Die nächsten drei Stunden versucht Client, die Mail einzuliefern und
erhält 4xx aus dem Cache als Resultat
- Nach diesen drei Stunden wird beim nächsten Versuch des Clients wieder
eine Probe zum Client geschickt: Greylisting ist hoffentlich nicht so eng
eingestellt, dass WIEDER Greylisting beginnt und hoffentlich deine
Probemail mit 250 auf das RCPT TO akzeptiert wird.
- Du speicherst jetzt positives Ergebnis in die Verify-Datenbank und der
Client kann endlich Mails bei dir einliefern.
- Das Ergebnis wird in der Verify-Datenbank für 31 Tage beibehalten, aber
nach 7 Tagen wird für ein Refresh eine Probemail geschickt. Wenn der
Client ebenfalls eine Datenbank mit erfolgreichen Triplets (Absender,
Empfänger, Host) speichert, dann beginnt hoffentlich das Spiel nicht
erneut. Sonst fängt das Spiel wieder an mit
- Client verbindet sich zu dir, will Mail einliefern...
Deshalb, selbst wenn alles sauber konfiguriert wird, kann dies zu
Verzögerungen bei Mails von etlichen Stunden führen. Sei deshalb besser
sehr selektiv und Überprüfe nicht JEDEN Client, sondern nur Clients, die
an sich schon etwas verdächtig sind, z.B. Unknown Clients ohne rDNS.
Sandy
--
Antworten bitte nur in die Mailingliste!
PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Mehr Informationen über die Mailingliste Postfixbuch-users