[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