[Postfixbuch-users] Sortierung der smtpd_recipient_restrictions

[Sandy Drobic]

Christian Garling wrote:
> Hi,

Ich habe zwei Anregungen für dich. Einmal zur Transparenz und einmal zur
Reihenfolge der Checks.

> meine smtpd_recipient_restrictions sehen nun so aus:
> 
> smtpd_recipient_restrictions = check_sender_access
> hash:/etc/postfix/sender_access,
> 			       check_recipient_access hash:/etc/postfix/recipient_access,
> 			       reject_unauth_pipelining,
> 			       reject_non_fqdn_sender,
> 			       reject_non_fqdn_recipient,
> 	 		       reject_unknown_sender_domain,
> 			       reject_unknown_recipient_domain,
>    			       permit_mynetworks,
> 			       reject_invalid_hostname,
> 			       reject_non_fqdn_hostname,
> 			       reject_unknown_hostname,
> 			       permit_sasl_authenticated,
> 			       reject_unauth_destination
> 
> Die Prüfungen des Hostname habe ich nach permit_mynetworks gesetzt, da
> dieser sich ja für Webmail nie ändert, also meiner Meinung nach nicht
> jedesmal aufs neue geprüft werden muss.

Leider verstehe ich deine Erklärung nicht, obwohl es heute bereits etwas
kühler ist. (^-^)

Wenn du die Schreibweise von Postfix 2.3 aufwärts betrachtest, wird die
Sache vielleicht klarer:
 - reject_invalid_helo_hostname
 - reject_non_fqdn_helo_hostname
 - reject_unknown_helo_hostname

All diese Checks beziehen sich auf den HELO-Namen, den der Client sendet,
nicht den Hostnamen, der im DNS verzeichnet ist. Dies hat also nichts mit
Webmail zu tun.

Meine Anregung zur Reihenfolge:

Überlege dir noch einmal, ob du einen User, der sich von seinem Rechner
einloggt per smtp auth, um eine Mail zu schicken, wirklich ablehnen
willst, weil er seinen Rechner "thomas.localnet" nennt.

Sortiere noch einmal nach folgender Überlegung in zwei Blöcke:

- Checks die absolut jede Mail bestehen muss, auch die von Relayclients.

dann kommt die Grenze reject_unauth_destination

- Jetzt die Checks, die nur für Mails gelten, welche von nicht
vertrauenswürdigen Clients kommen. Innerhalb dieser Blöcke kannst du dann
weiter unterteilen nach Checks, die wenig Ressourcen brauchen bzw. sehr
schnell sind und solchen die teuer sind bzw. viel Zeit brauchen.

Die zweite Anregung ist die Transparenz:
Nenne access tables niemals sender_access oder recipient_access, sondern
benenne sie nach der Funktion:
 - sender_blacklist
 - sender_whitelist
 - sender_greylisted
 - client_blacklist_pcre

Dies führt automatisch dazu, dass du nicht in einer Tabelle alle möglichen
Checks hineinklemmst. Wenn in deinen Tabellen sowohl Whitelisting als auch
Blacklisting betrieben wird, teile die Tabellen auf in die Funktionen. Das
macht das System erheblich wartbarer und du musst nicht erst überlegen,
was in welcher Tabelle steckt. Je mehr da durcheinandergeht, desto weniger
verstehst du dein eigenes System.

Ich weiß, wovon ich spreche, da es mir auch passiert ist. Jetzt habe ich
ein paar check_*_access Abfragen mehr in der Konfig, aber ich sehe sofort,
wo ich einen Eintrag hinzufügen muss.

So kann dir im Augenblick niemand sagen, ob es Sinn macht, die Abfragen
für alle Mails zu machen.


-- 
Sandy

Antworten bitte nur in die Mailingliste!
PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com