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
Cookies helfen bei der Bereitstellung von Inhalten. Durch die Nutzung dieser Seiten erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Rechner gespeichert werden. Weitere Information
  • centos/mailserver/backup_mailserver.txt
  • Zuletzt geändert: 03.12.2009 21:22.
  • von michi