[Postfixbuch-users] Sinvolle Reihenfolge der Checks

[Andre Keller]

Peer Heinlein schrieb:
> 
> Ich halte nichts von Theorien, daß man die restrictions von billig nach 
> teuer aufbauen kann. Ich behaupte: Wenn man für alle Möglichkeiten 
> gewappnet sein will, dann gibt es eine zwangsläufige Reihenfolge, die 
> durch die Logik vorgegeben wird. Wenn man alles berücksichtigt hat man 
> leider keine Entscheidungsspielräume um das ernsthaft nach Performance 
> zu optimieren.
> 
> 1) postmaster und abuse durch check_recipient_maps freischalten
> 2) Syntax-Checks wie reject_unknwon_(sender|recipient)_domain und 
> reject_non_fqdn_(sender|recipient)_domain
> 3) Jeweils eine access-Map für client, helo, sender,recipient um 
> beliebig white- und blacklisten zu können (auch das eigene Netz!!!)
> 4) permit_mynetworks, _permit_sasl_authenticated und ggf.TLS-Zertifikate
> 5) RBL oder alternativ policyd_weight
> 6) Greylisting
> 7) Ggf. permit_max_backup
> 8) reject_unauth_destination
> 
> Für 4 bis 8 ist die Abfolge logisch zwingend, für 1) sowieso. Über die 
> Reihenfolge von 2) und 3) kann man diskutieren, ist aber relativ egal 
> und hier ausnahmsweise Geschmackssache.
> 

So auf den ersten Blick klingt das durchaus logisch.

> Komplexere Setups wie restriction_classes erfordern ggf. weitere 
> access-Abfragen die ergänzt werden müssen, an der Grundstruktur ändert 
> sich aber nichts.
> 
> In deiner Lösung stört mich:
> 
> a) Du hast permit_mx_backup über RBL und Greylisting. Für den 
> gevbackuppten Server wird das nicht benutzt. Damit machst Du seinen 
> Spamschutz kaputt und Du bist das Hintertürchen der Spammer. Nicht 
> nett.

Also ich habe jetzt nochmals kurz nachgelesen was der Parameter _genau_ 
macht.
Verstehe ich das richtig. Wenn mein Backupserver über die Recipients 
bescheid weiss (durch Replikation der entsprechenden Datenbank) dann 
kann ich diesen Parameter aus der Konfiguration streichen. Postfix 
entscheidet dann anhand der Empfänger ob die Mail zugestellt wird oder?

> 
> b) Du hast keien Chance, einen amoklaufenden Client oder Úser aus 
> $mynetworks zu sperren, da Deine check_*_maps zu spät sind. Das ist 
> schade, denn würdest Du sie höher packen, so hättest Du keine 
> Nachteile, wohl aber die Möglichkeit im Krisenfall einzugreifen. So wie 
> Du es jetzt hast kannst Du 6 Milliarden Leute weltweit sperren -- nur 
> Deine eigenen 60 User nicht. Das kann doch wohl kaum sein. Für den bist 
> Du Verantwortlich? Wo mußt Du aufpassen, daß nix passiert?
> 

Das war natürlich nicht so gewollt.

> 
> Wenn du hier a) und b) umsetzen willst, dann kommst Du mit allen 
> Folgeentscheidungen, die daraus erwachsen, auf oben skizzierte 
> Grundlösung.

An welcher Stelle wird Amavisd sinnvollerweise eingebunden?
Nach dem alle anderen Punkte erfüllt sind oder?

Ist die Konfiguration mit einem einfachen content_filter = ... in der 
der main.cf korrekt oder gehört das wo anders hin.

> 
> Mit freundlichen Grüßen
> 
> Peer Heinlein
> 
> 

Danke für deine Ausführungen. Ich denke langsam komm ich meiner Lösung 
näher.


Gruss André