[Postfixbuch-users] restrictions - Musterlösung aus dem Buch

[Sascha Peters]

Hallo Liste,

ich habe wieder das Buch zur Hand genommen und noch mal mehr oder 
weniger ganz gelesen. Ich bin immer weider erstaunt was man nicht so 
alles mit der Zeit vergisst :)

Ich habe mir dann die Musterlösung auf Seite 212 angesehen, und bei der 
letzten Diskussion hier auf der Liste von "Whitelisten" die ich hatte 
über einen Satz auf Seite 211 nachgedacht.


Satz auf Seite 211:

- Die Überprüfung der Existenz der Absender-/Empfängerdomain soll und 
muss gerade auch dür Mails aus dem eigenen Netzwerk stattfinden, für das 
man ja die Verwantwortung trägt. Ein permit_mynetworks oder 
permit_sasl_authenticated kann also erst danach kommen.



Müsterlösung Seite 212:
mit Korrektur von "http://www.postfixbuch.de/web/service/korrekturen/"


smtpd_recipient_restrictions =
# Postmaster, abuse, und andere Role-Accounts whitelisten
	check_recipient_access btree:/etc/postfix/access_recipient-rfc,
# White- und Blacklisting
	check_client_access cidr:/etc/postfix/access_client,
	check_helo_access btree:/etc/postfix/access_helo,
	check_sender_access btree:/etc/postfix/access_sender,
	check_recipient_access btree:/etc/postfix/access_recipient,
# Keine unsauberen Mails annehmen!
	reject_non_fqdn_sender,
	reject_non_fqdn_recipient,
	reject_unknown_sender_domain,
	reject_unknown_recipient_domain,
# Unsere Nutzer erlauben!
	permit_sasl_authenticated,
	permit_mynetworks,
# RBL checken (könnte auch nur über policyd-weight erfolgen)
	reject_rbl_client zen.spamhaus.org,
	reject_rbl_client ix.dnsbl.manitu.net,
	reject_rbl_client bl.spamcop.net,
	reject_rbl_client dnsbl.njabl.org,
# Policyd-Weight
	check_policy_service inet:127.0.0.1:12525,
# Greylisting checken!
	check_policy_service inet:127.0.0.1:10023,
# Wir prüfen dynamisch auf existente Relay-Empfänger
	reject_unverified_recipient,
# Backup MX erlauben!
	permit_mx_backup,
# Alles andere Relaying verbieten!
	reject_unauth_destination,
# was jetzt noch ist darf durch!
	permit


Müssten die "White- und Blacklisting" Einträge nicht gleich mit dern 
"Unseree Nutzer erlauben" sein? Zumindest die "Whitelist" davon. Denn 
wenn ich einen Client mit seiner IP-Adresse oder einen Recipient von mir 
Whiteliste, dann bin nehme ich auch wieder unsaubere Adressen an.

Ist es nicht "schöner" dann die Listen zu mischen, so das Blacklisting 
weiterhin mit einer 5xx beantwortet wird, und nicht eventuell ein 4xx 
der andere Checks die Sache verlängert.

Dann stimmt der Text oben wieder von Seite 211.

# Blacklisting
	check_client_access cidr:/etc/postfix/access_client_bl,
	check_helo_access btree:/etc/postfix/access_helo_bl,
	check_sender_access btree:/etc/postfix/access_sender_bl,
	check_recipient_access btree:/etc/postfix/access_recipient_bl,
# Keine unsauberen Mails annehmen!
	reject_non_fqdn_sender,
	reject_non_fqdn_recipient,
	reject_unknown_sender_domain,
	reject_unknown_recipient_domain,
# Whitelisting
	check_client_access cidr:/etc/postfix/access_client_wl,
	check_helo_access btree:/etc/postfix/access_helo_wl,
	check_sender_access btree:/etc/postfix/access_sender_wl,
	check_recipient_access btree:/etc/postfix/access_recipient_wl,
# Unsere Nutzer erlauben!
	permit_sasl_authenticated,
	permit_mynetworks,


Ist es so nicht ein bisschen Sauberer? Oder eben den ganzen White- und 
Blacklisting Block hinter die Prüfung auf saubere Mails.

Weiterhin würde ich die "access_helo" als "pcre" einbinden. Das nutze 
zumindest ich mehr.


Für mich kommt dann folgendes dabei raus .-)

smtpd_recipient_restrictions =
# Postmaster, abuse, und andere Role-Accounts whitelisten
	check_recipient_access hash:/etc/postfix/access_recipient_rfc,
# Blacklisting
	check_client_access cidr:/etc/postfix/access_client_wl,
	check_helo_access pcre:/etc/postfix/access_helo_bl,
	check_sender_access hash:/etc/postfix/access_sender_bl,
	check_recipient_access hash:/etc/postfix/access_recipient_bl,
# Keine unsauberen Mails annehmen!
	reject_non_fqdn_sender,
	reject_non_fqdn_recipient,
	reject_unknown_sender_domain,
	reject_unknown_recipient_domain,
# Whitelisting
	check_client_access cidr:/etc/postfix/access_client_wl,
	check_helo_access pcre:/etc/postfix/access_helo_wl,
	check_recipient_access hash:/etc/postfix/access_recipient_wl,
# Unsere Nutzer erlauben!
	permit_sasl_authenticated,
	permit_tls_clientcerts,
	permit_mynetworks,
# Fehlerhafter helo
	reject_invalid_helo_hostname,
# RBL checken (könnte auch nur über policyd-weight erfolgen)
	reject_rbl_client zen.spamhaus.org,
	reject_rbl_client ix.dnsbl.manitu.net,
# Postfwd
	check_policy_service inet:127.0.0.1:10045,
# Policyd-Weight
	check_policy_service inet:127.0.0.1:12525,
# Greylisting checken!
	check_policy_service inet:127.0.0.1:10023,
# Wir prüfen dynamisch auf existente Relay-Empfänger
	reject_unverified_recipient,
# Wir prüfen (selektiv pro Domain) auf existente Relay-Absender
	check_sender_accesss hash:/etc/postfix/verify-sender,
# Alles andere Relaying verbieten
	reject_unauth_destination,
# was jetzt noch ist darf durch!
	permit



Eventuell wird einiges später über den postfwd2 gemacht. Und ab die
RBL, Policyd-Weight und Postgrey Blocks damit ersetzt.

# Policyd-Weight, Greylisting und RBL eventuell über
# Restriction Classes oder postfwd steuern.
	# check_policy_service inet:127.0.0.1:10045,
	# check_recipient_access hash:/etc/postfix/restrictions,



an Peer Heinlein:

überlege mal ob hier 
"http://www.postfixbuch.de/web/service/korrekturen/" nicht folgendes 
auch noch ergänst werden könnte/sollte?

Blackhole, siehe Link...
http://www.heise.de/ix/meldung/Letzte-Zuckungen-der-SecuritySage-Blacklist-211004.html



-- 

Gruß
Sascha