[Postfixbuch-users] Sinvolle Reihenfolge der Checks

[Peer Heinlein]

Am Sonntag, 11. März 2007 20:02 schrieb Andre Keller:

> smtpd_recipient_restrictions =
> 	reject_unknown_sender_domain,
> 	reject_non_fqdn_sender,
> 	permit_mynetworks,
> 	permit_sasl_authenticated,
> 	permit_mx_backup,
> 	reject_unauth_destination,
> 	check_sender_access hash:/path/to/sender_access,
> 	check_recipient_access hash:/path/to/recipient_access,
> 	reject_rbl_client relays.ordb.org,
> 	reject_rbl_client sbl.spamhaus.org,
> 	check_policy_service inet:127.0.0.1:60000,
> 	permit

Soweit okay, es WÜRDE gehen. Aber es ist nicht optimal.

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.

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.

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?


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

Mit freundlichen Grüßen

Peer Heinlein


-- 
Heinlein Professional Linux Support GmbH
Linux: Akademie - Support - Hosting

http://www.heinlein-support.de
Tel: 030 / 40 50 51 - 0  ***  Fax: - 19

Besuchen Sie uns: CeBIT 2007: Stand G64/3 im LinuxPark!

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg, 
Geschäftsführer: Peer Heinlein  --  Sitz: Berlin