RE: [Postfixbuch-users] Muss Postgrey bei geänderten Whitelists neu gestartet werden

[Thomas Schwenski]

> --- Ursprüngliche Nachricht ---
> Von: "Marcel Hartmann" <mail at marcel-hartmann.com>
<snip>Ne Menge TOFU</snip>
> 
> Also wenn der MySQLd steht, dann geht auch keine Mail mehr, da ich
> postfix, amavis und cyrus an mysql angebunden habe. Daher macht das
> kopieren der Maps in meinem Falle keinen Sinn denke ich. Mein Server
> läuft seit knapp 1,5 Jahren mit MySQL und der MySQL fiel bisher noch 
> nie aus! Zumal mir viele davon abgeraten haben, habe cih gute 
> Erfahrungen damit gemacht.

Die werden wohl Ihren Grund haben!
Könnte zum Beispiel der sein, dass das Risiko eines Stillstandes nicht durch
einen zufälligen faktor (Mysqld) vergrößert werden muss.
Ein regelmäßiges dumpen Deiner Datenbank kann aber trotzdem nicht schaden.
 
> Hier meine config:
<snip>...</snip>

Ich würde das so machen:
(unter Berücksichtigung von Jens Hinweis)


         reject_unknown_sender_domain,
         reject_non_fqdn_sender,
         permit_mynetworks,
         check_client_access hash:/etc/postfix/maps/pop-before-smtp,
         permit_sasl_authenticated,
         reject_unauth_destination,

         check_client_access hash:/etc/postfix/rbl_whitelist,

         reject_rbl_client sbl-xbl.spamhaus.org,
         reject_rbl_client list.dsbl.org,
         reject_rbl_client relays.ordb.org

         check_client_access hash:/etc/postfix/policyd_weight_whitelist,
         check_policy_service inet:127.0.0.1:10023,

         permit


Auf diese Art und Weise umgehst Du mit der Greylisting Whitelist nicht die
RBL-Prüfung.
Und für Problemfälle (Server die falsch in der RBL-Liste stehen hättest Du
auch noch eine Whiteliste (die dann aber auch Greylisting deaktiviert).

Inwiefern die vertauschte Reihenfolge (wie ich Sie vorgeschlagen habe)
unnötig ist, weiß ich nicht - das Grundprinzip ist aber richtig so!

Das Whitelisten in Postfix statt in postgrey hat den Vorteil, dass der
Postgrey-Prozess (für die betreffenden Mails) nicht mehr bemüht werden muss.
 
 
> > Eine andere Lösung wären restriction-Classes mit identischen 
> > Prüfungen aber eine mit und eine ohne Postgrey.
> > (Besonders interessant für den Fall, dass nach Postgrey noch 
> > Spam-Checks kommen müssen!)
> 
> Und wie unterscheide ich dann welche er wann einsetzen soll?

Urps ich muss zugeben, dass ich eigentlich keine Ahnung von
restriction-Classes habe, ausser dass es die gibt! =)

Aber: Man muss nicht alles wissen, man muss nur wissen wo es steht (oder
einen kennen, der eines von beiden weiß!)

Postfixbuch Seite 302 ff.


> > > also die  mail soll dann direkt zugestellt werden ohne temporäre 
> > > Feler, so dass der sendende MTA es erneut versuchen muss.
> > 
> > Das ist ein Widerspruch: warum sollte der sendende MTA die 
> > Mail erneut zustellen, wenn Sie schon direkt zugestellt wurde?
> 
> Postgrey arbeitet doch auf diese Weise! Ein MTA will eine Mail in
> das postfix system einliefern. Postfix sagt aber 4xx Temporary foo bar...
> Daraufhin stellt der sendende MTA die Mail mit pausen so lange zu, bis 
> mein postfix(also der postgrey check!) ihm erlaubt einzuliefern. Dadurch 
> wird die Zustellung ja nur verzögert. Wenn ich das richtig verstanden
> habe.

Das sit richtig.
Aber oben hast Du was andres geschrieben!

Thomas

-- 
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl