Backupmailserver
Nur mit einem Mailserver in Produktion zu gehen, wirft natürlich für das Thema geplante Wartungsarbeiten / Downtime schon einige Fragen auf. Bevor nun die Domäne gar nicht mehr erreichbar ist, ist es schon weitaus angenehmer auf einen Backupmailserver, der unseren höchsten Ansprüchen an Sicherheits- und SPAM-Abwehrmechanismen genügt, zurück greifen zu können.
Es wird setzen einen sog. „Store-and-Forward“-Backup-Server um, d.h. es werden die eMails vom Backup-Server angenommen und sobald der eigentlichen MX-Server wieder Ververfügbarkeit ist, an diesen zugestellt.
Für unsere Domäne definieren wir die zugehörigen MX-Records.
# dig nausch.org MX ;; ANSWER SECTION: nausch.org. 86400 IN MX 10 mx1.nausch.org. nausch.org. 86400 IN MX 20 mx1.tachtler.net.
Für die dynamische Empfängeradressverifizierung lassen wir Postfix eine Datenbank anlegen. Ebenso definieren wir, für wen genau unser MX als Backup relayen darf und soll. Hierzu tragen wir in die /etc/postfix/main.cf folgende Definitionen nach:
# # Datenbank für die dynamische Adressverifizierung anlegen # eingetragen am 02.02.09 # address_verify_map=btree:/var/spool/postfix/data/verify permit_mx_backup_networks = 88.217.171.167/32
Das Verzeichnis /var/spool/postfix/data/verify ist unter Umständen nicht angelegt worden. wir überprüfen dieses und erstellen es bei Bedarf.
mkdir /var/spool/postfix/data chown postfix:root /var/spool/postfix/data chmod 700 /var/spool/postfix/data/
Die bereits unter Grundabsicherung Postfix vorbereiteten Definitionen werden nunmehr aktiviert.
smtpd_recipient_restrictions =
# Postmaster, abuse und andere aufgaben- oder funktionsgebundene E-Mail-Adressen (Role-Accounts) whitelisten
check_recipient_access hash:/etc/postfix/access_recipient-rfc,
# Black- und Whitelisting (Kapitel 8.2.3 White- und Blacklisting)
check_client_access hash:/etc/postfix/access_client,
check_helo_access hash:/etc/postfix/access_helo,
check_sender_access hash:/etc/postfix/access_sender,
check_recipient_access hash:/etc/postfix/access_recipient,
# Unsauberer eMails nicht annehmen (Kapitel 8.2.4 Anforderungen an Mailadressen)
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
# Unsere eigenen Nutzer zulassen-/erlauben (Kapitel 8.2.2 Relaying erlauben und verbieten)
permit_sasl_authenticated,
permit_mynetworks,
# RBL überprüfen (Kapitel 10.11 Realtime Blackhole Lists)
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,
reject_rhsbl_client multi.uribl.com,
# Policyd-Weight (Kapitel 9.3 policyd-weigt)
check_client_access hash:/etc/postfix/policyd_weight_client_whitelist
check_policy_service inet:127.0.0.1:12525,
# Greylisting via postgrey checken via Unix-Socket (Kapitel 9.2.5 postgrey installieren)
check_policy_service unix:postgrey/socket,
# Dynamische Prüfung auf existente Relay-Empfänger (Kapitel 12.2.2 Dynamische Empfänger-Verifizierung)
reject_unverified_recipient,
# aktiviert am 02.02.09
# Backupserver (MX) erlauben
permit_mx_backup,
# alles andere an relaying verbieten (Kapitel 8.2.2 Relaying erlauben und verbieten)
reject_unauth_destination,
# Zu guter Letzt alles durchlassen, was bis jetzt noch nicht beanstandet wurde
permit
Die eigentliche Arbeit - die der Empfänger-Adress-Verifizierung erfolgt dabei durch das Modul verify welches in der master.cf definiert ist.
verify unix - - n - 1 verify
Zur Aktivierung unserer Änderungen reloaden wir unseren Postfix einfach 1x.
# service Postfix reload
Nach den erfolgreichen Testläufen definieren wir nun noch, dass Zustellversuche an nicht existierende Empfänger auf dem eigentlichen Zielsystem auch wirklich mit einem 500er geblockt werden.
# für den Backupmailserverbetrieb eingetragen am 02.02.09 unverified_recipient_reject_code = 577
Anschließend werden die Änderungen wie gwohnt durch einen Reload aktiviert:
# service postfix reload
michi