[Postfixbuch-users] reject_unverified_sender

[Andreas Meyer]

Sandy Drobic <postfixbuch-users at japantest.homelinux.com> schrieb:

> 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.

Ich habe eine address_verify_map angelegt. Was mir dabei nicht klar ist,
ob alle Ergebnisse, also auch die negativen da rein geschrieben werden.
Die Option address_verify_negative_cache = yes wird nicht mehr greifen,
wenn eine map vorhanden ist, vermute ich.
 
> 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...

Danke für Deine aufschlußreichen Gedankengänge!
 
> 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.

Also werde ich nur selectiv mit reject_unverified_sender arbeiten, muß
dann halt erstmal ständig das logfile beobachten.

> Sandy
> 


-- 
   Andreas Meyer
   
Mein öffentlicher GPG-Schlüssel unter:
http://gpg-keyserver.de/pks/lookup?search=anmeyer&fingerprint=on&op=index