Nur mit einem Mailserver in Produktion zu gehen, wirft natürlich für das Thema geplante Wartungsarbeiten / Downtime schon einige Fragen auf. Egal ob nun ein Hardewardefekt, eine Überlastung des Servers oder des Postmasters vorliegt, nach Ablauf der gängigen Queue-Life-Time von 3 - 6 Tagen, wären wir definitiv nicht arbeitsfähig. Bevor nun die Domäne, bei einer längeren „Abwesenheit“ unseres Mailservers, nun 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. Aus gutem Grund gibt es für fast jede ordendlich gepflegte Domäne in der Regel mindestens einen Backupmailserver.

Wir setzen aus den gerade genannten Gründen einen sog. „Store-and-Forward“-Backup-Server ein. Hierbei werden bei Bedarf die eMails vom Backup-Server angenommen und sobald der eigentlichen MX-Server wieder verfügbar ist, an diesen zugestellt.

Für unsere Domäne definieren wir die zugehörigen MX-Records und legen hierzu die entsprechenden DNS-Einträge fest. In unserem Fall hat nun unser Produktivsystem mx1.nausch.org die Priorität 10 und der Backupmailserver mx1.tachtler.net die Priorität 20.

 # dig nausch.org MX
 
 ;; ANSWER SECTION:
 nausch.org.             86400   IN      MX      10 mx1.nausch.org.
 nausch.org.             86400   IN      MX      20 mx1.tachtler.net.

Über die Variable permit_mx_backup wird unser Mailserver angewiesen, eMails anzunehmen und weiterzuleiten, sofern nur ein MX-Record auf unseren Mailserver zeigt. Mit Hilfe von permit_mx_backup_networks kann und muss dies nun soweit eingeschränkt werden, so dass der höchste MX-Host aus dem hier definierten Netzwerk kommen muss! Wir tragen also die IP-Adressen, bzw. die Netzbereiche in die main.cf am Ende der Section ZUSTÄNDIGKEITEN, VERTRAUENSWÜRDIGE NETZE UND NETZWERKK-DEFINITIONEN entsprechend ein.

 # vim /etc/postfix/main.cf

...
 
# Django : 2015-10-15 - Backup-Mailserver explizit erlauben
# default: permit_mx_backup_networks =
permit_mx_backup_networks = 88.217.171.167/32

Ähnlich wie schon bei der Anbindung unseres Postfix-Mailservers an einem Backend-Mailserver (Dovecot-IMAP-Server) verwenden wir auch hier das Modul verify.

Den notwendigen Konfigurationseintrag finden wir bereits in der Hauptkonfigurationsdatei von unserem Postfix 2.11.3 unter CentOS 7.x.

 # grep verify /etc/postfix/master.cf

 verify    unix  -       -       n       -       1       verify

Postfix wird mit Hilfe des Moduls verify versuchen, noch während der Annahme der Nachricht von einem fremden Mailserver, beim Backend-System in Erfahrung zu bringen, ob dieses die Nachricht auch abnehmen würde. Ist dies der Fall, reicht der Backup-Mailserver die Nachricht an unseren Mailserver weiter, sobald dieser wieder erreichbar ist. Anderenfalls wird die Annahme der Nachricht verweigert. Damit nun der Mailserver nicht jedesmal nachfragen muss, werden wir ihm hierzu eine kleine Datenbanktabelle spendieren, die auch nach einen Neustart des Servers zur Verfügung stehen kann.

Als erstes legen wir nun das entsprechende Verzeichnis an und schenke es dem Nutzer postfix.

 # mkdir /var/spool/postfix/data

 # chown postfix.root /var/spool/postfix/data

 # chmod 700 /var/spool/postfix/data

Als nächstes definieren wir noch die entsprechende Datenbank, bzw. den Ort wo Postfix diese Datenbank abspeichern wird. Hierzu tragen wir in die Konfigurationsdatei /etc/postfix/main.cf am ende der Sektion ## LOOKUP-TABELLEN nachfolgenden Eintrag nach.

 # vim /etc/postfix/main.cf

...
 
# Django : 2015-10-15 - Ergebnisse der Adress-Verification cachen
#          Kapitel 12.2.2 Dynamische Empfänger-Verifizierung
#          Kapitel 9.5.5 envelope sender überprüfen
# default: address_verify_map = btree:$data_directory/verify_cache
address_verify_map = btree:/var/spool/postfix/data/verify

Ferner aktivieren wir noch den in der Grundkonfiguration unserers Restrictions-Regelwerk vorbereiteten Eintrag permit_mx_backup,.

 # vim /etc/postfix/main.cf

################################################################################
## SMTP RECIPIENT RESTRICTIONS
#
# Django : 2014-10-29 - Schutz unserer Empfänger mit Hilfe der Recipient 
#          Restrictions 
# default: smtpd_recipient_restrictions =
smtpd_recipient_restrictions =
#          Postmaster, abuse und andere aufgaben- oder funktionsgebundene 
#          eMail-Adressen (Role-Accounts) whitelisten
           check_recipient_access btree:/etc/postfix/access_recipient-rfc
 
#          Black- und Whitelisting       (Kapitel 8.2.3 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
 
#          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_rhsbl_client multi.uribl.com
 
#          Greylisting via postgrey checken via Unix-Socket
#                                          (Kapitel 9.2.5 postgrey installieren)
#          check_policy_service unix:postgrey/socket,
 
#          Policyd-Weight check over TCP-Connection 
#                                      (Kapitel 9.3 policyd-weight installieren)
#          check_client_access btree:/etc/postfix/policyd_weight_client_whitelist,
#          check_policy_service inet:127.0.0.1:12525,
 
#          Dynamische Prüfung auf existente Relay-Empfänger
#                            (Kapitel 12.2.2 Dynamische Empfänger-Verifizierung)
           reject_unverified_recipient
 
#          Backupserver (MX) erlauben
           permit_mx_backup
 
#          alles andere an relaying verbieten   
#                                (Kapitel 8.2.2 Relaying erlauben und verbieten)
           reject_unauth_destination
 
#          Quota-Status-Policy-Daemon am Dovecot-Backend-System
#          Dovecotbuch (ISBN 978-3-95539-74-7) Seite 219 ff.  
#                          (Kapitel 11.11 "Der Quota-Policy-Server für Postfix")
           check_policy_service inet:10.0.0.77:10000
 
#          Zu guter Letzt alles durchlassen, was bis jetzt noch nicht 
#          beanstandet wurde
           permit

Zusätzlich aktivieren wir noch den in der Section SMTP RELAY RESTRICTIONS beim Grundkonfiguration unserers Restrictions-Regelwerk vorbereiteten Eintrag permit_mx_backup,.

 # vim /etc/postfix/main.cf

...

################################################################################
## SMTP RELAY RESTRICTIONS
#
# Django : 2014-10-27 - Definition, wer über unseren MX relayen darf oder nicht. 
#          http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions
# default: smtpd_relay_restrictions = permit_mynetworks, 
#          permit_sasl_authenticated, defer_unauth_destination
#
smtpd_relay_restrictions =
# Unsere eigenen Nutzer zulassen-/erlauben
           permit_sasl_authenticated
           permit_mynetworks
# Backupserver (MX) erlauben
#           permit_mx_backup
# alles andere an relaying verbieten, d.h. mit einem finalen error 550 abweisen
           reject_unauth_destination

Die Pflege der verify-Datenbank übernimmt dabei Postfix selbst, trägt neue Adressen ein und löscht auch regelmäßig alte Einträge - kurz und gut, der Postfix betreibt also eine Art Brutpflege. Da wir keine Änderungen an weiteren Parametern vorgenommen hatten, greifen hier die Default-Werte.

 # postconf address_verify_positive_refresh_time

 address_verify_positive_refresh_time = 7d

Nach Ablauf der sieben Tage wird das verify-Modul eine bereits bekannte und positiv gekennzeichnete eMailadresse erneuit beim Zielserver anfragen und die Aktualität des Datensatzes überprüfen.

 # postconf address_verify_positive_expire_time

 address_verify_positive_expire_time = 31d

Erst nach Ablauf von 31 Tagen wird eine bekannte und positive Adresse aus der Datenbank entfernt. Da aber bereits nach 7 Tagen eine Überprüfung der Adresse stattfindet, werden „gute Adressen“ quasi nie gelöschtm sondern stehen sofort zur Verfügung!

 # postconf address_verify_negative_refresh_time

 address_verify_negative_refresh_time = 3h

Nach drei Stunden wird das verify-Modul eine noch nicht existente gecachte Empfänger-Adresse beim Zielserver erneut anfragen.

 # postconf address_verify_negative_expire_time

 address_verify_negative_expire_time = 3d

Nicht existierende Empfängeradressen werden maximal drei Tage vorgehalten und dann gelöscht.

 # postconf address_verify_sender

 address_verify_sender = $double_bounce_sender

 # postconf double_bounce_sender

 double_bounce_sender = double-bounce

Dieser Parameter legt fest, mit welchem Envelope-From die Anfragen an den Zielserver gerichtet werden sollen.

Zum Aktivieren unserer Konfigurationsänderung führen wir einen reload des dovecot-Daemons durch.

 # systemctl reload dovecot.service

Der Reload wurde im maillog dokumentiert. Bei Bedarf können wir den Status unseres Dovecot_Servers abfragen.

 # systemctl status dovecot.service

dovecot.service - Dovecot IMAP/POP3 email server
   Loaded: loaded (/usr/lib/systemd/system/dovecot.service; enabled)
   Active: active (running) since Tue 2014-07-22 21:35:37 CEST; 24h ago
  Process: 23610 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
 Main PID: 22063 (dovecot)
   CGroup: /system.slice/dovecot.service
           ├─22063 /usr/sbin/dovecot -F
           ├─22065 dovecot/anvil [0 connections]
           ├─23613 dovecot/log
           └─23615 dovecot/config


Jul 23 21:32:16 vml000070.dmz.nausch.org dovecot[23587]: imap-login: Login: user=<michael@nausch.org>, method=PLAIN, rip=10.0.0.20, mpid=23601, TLS, TLSv1 with ciphe...YQAKAAAU>
Jul 23 21:47:21 vml000070.dmz.nausch.org systemd[1]: Reloading Dovecot IMAP/POP3 email server.
Jul 23 21:47:21 vml000070.dmz.nausch.org dovecot[22063]: master: Warning: SIGHUP received - reloading configuration
Jul 23 21:47:21 vml000070.dmz.nausch.org systemd[1]: Reloaded Dovecot IMAP/POP3 email server.
Jul 23 21:47:21 vml000070.dmz.nausch.org dovecot[23587]: imap: Server shutting down. in=548 out=1966
Hint: Some lines were ellipsized, use -l to show in full.

Im Maillog werden dann entsprechend positive wie negative Überprüfungen dokumentiert.

 # tail -f /var/log/maillog

...
Jun  4 22:11:20 vml000080 postfix/smtpd[13738]: connect from unknown[192.168.10.45]
Jun  4 22:12:06 vml000080 postfix/cleanup[13743]: 55C673A: message-id=<20120604201206.55C673A@mx1.nausch.org>
Jun  4 22:12:06 vml000080 postfix/qmgr[13643]: 55C673A: from=<double-bounce@nausch.org>, size=253, nrcpt=1 (queue active)
Jun  4 22:12:06 vml000080 postfix/lmtp[13744]: 55C673A: to=<django@nausch.org>, relay=10.0.0.70[10.0.0.70]:24, delay=0.08, delays=0.04/0.01/0.02/0.01, dsn=2.1.5, status=deliverable (250 2.1.5 ok)
Jun  4 22:12:06 vml000080 postfix/qmgr[13643]: 55C673A: removed
Jun  4 22:12:09 vml000080 postfix/smtpd[13738]: 563E13A: client=unknown[192.168.10.45]
Jun  4 22:12:17 vml000080 postfix/smtpd[13738]: disconnect from unknown[192.168.10.45]
...

Das Beispiel zeigt einen erfolgreichen Überprüfungsversuch status=deliverable (250 2.1.5 ok) ).

Wir im Gegensatz versucht an einen nicht existierenden Empfänger eine Nachricht zuzustellen, erfolgt hier der Vermerk status=undeliverable .

...
Jun  4 22:26:07 vml000080 postfix/smtpd[13753]: connect from unknown[192.168.10.45]
Jun  4 22:26:37 vml000080 postfix/cleanup[13760]: F0DAC3A: message-id=<20120604202637.F0DAC3A@mx1.nausch.org>
Jun  4 22:26:38 vml000080 postfix/qmgr[13643]: F0DAC3A: from=<double-bounce@nausch.org>, size=253, nrcpt=1 (queue active)
Jun  4 22:26:38 vml000080 postfix/lmtp[13761]: F0DAC3A: to=<peer.heinlein@nausch.org>, relay=10.0.0.70[10.0.0.70]:24, delay=0.08, delays=0.04/0.01/0.01/0.01, dsn=5.1.1, status=undeliverable (host 10.0.0.70[10.0.0.70] said: 550-Mailbox unknown.  Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT TO command))
Jun  4 22:26:38 vml000080 postfix/qmgr[13643]: F0DAC3A: removed
Jun  4 22:26:40 vml000080 postfix/smtpd[13753]: NOQUEUE: reject: RCPT from unknown[192.168.10.45]: 450 4.1.1 <peer.heinlein@nausch.org>: Recipient address rejected: unverified address: host 10.0.0.70[10.0.0.70] said: 550-Mailbox unknown.  Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT TO command); from=<swat@nausch.org> to=<peer.heinlein@nausch.org> proto=SMTP helo=<ich>
Jun  4 22:26:49 vml000080 postfix/smtpd[13753]: disconnect from unknown[192.168.10.45]
...

Werfen wir nun einen Blick in die verify-Datenbank von Postfix können wir für beide Beispiele die entsprechenden Einträge finden.

 # postmap -s btree:/var/spool/postfix/data/verify

django@nausch.org	0:0:1338840726:250 2.1.5 ok
peer.heinlein@nausch.org	2:0:1338841598:host 10.0.0.70[10.0.0.70] said: 550-Mailbox unknown.  Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT TO command)

Wollen wir, warum auch immer, einen Eintrag der verify-Datenbank manuell entfernen, greifen wir auch auf den Befehl postmap zurück.

 # postmap -d peer.heinlein@nausch.org /var/spool/postfix/data/verify

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. Hierzu aktivieren wir den bei der Basiskonfiguration vorbereiteten Eintrag in der Section ZUSTÄNDIGKEITEN, VERTRAUENSWÜRDIGE NETZE UND NETZWERKK-DEFINITIONEN

 # vim /etc/postfix/main.cf

... 
 
# default: unbekannte Empfänger sollen abgewiesen und nicht mit einem
#          temporären Fehler 450 abgewiesen werden.
# default: unknown_local_recipient_reject_code = 550
#          unverified_recipient_reject_code = 450
unverified_recipient_reject_code = 577
 
...

Anschließend werden die Änderungen wie gewohnt durch einen Reload aktiviert:

 # systemctl reload postfix

• Zurück zum Kapitel >>Mailserverinstallation unter CentOS 7<<
• Zurück zu >>Projekte und Themenkapitel<<
• Zurück zur Startseite