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 entsprechend ein.

 # vim /etc/postfix/main.cf

# Django : 2012-02-06
# Backup Mailserver definiert
permit_mx_backup_networks = 88.217.171.167/32

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

Den notwendigen Konfigurationseintrag finden wir bereits in der Hauptkonfigurationsdatei von unserem Postfix 2.6.6 unter CentOS 6.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 main.cf folgenden Eintrag nach.

 # vim /etc/postfix/main.cf

# Postfix-eigene verify-Datenbank für die dynamische    (Kapitel 12.2.2 Dynamische Empfänger-Verifizierung)
# Empfänger-Überprüfung nutzen
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,.

#
# Django : 2012-02-06
# Schutz durch Restrictions für unser SOHO 
#
 
smtpd_recipient_restrictions =
# Postmaster, abuse und andere aufgaben- oder funktionsgebundene E-Mail-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,
# 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,
# 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,
# Zu guter Letzt alles durchlassen, was bis jetzt noch nicht beanstandet wurde
        permit

Hierzu tragen wir in die Postfix-Konfigurationsdatei noch folgende Zeilen ein.

 # vim /etc/postfix/main.cf

/etc/postfix/main.cf

# Django : 2014-04-11
# neuer Parameter ab 2.10: smtpd_relay_restrictions
smtpd_relay_restrictions =
# Unsere eigenen Nutzer zulassen-/erlauben
        permit_sasl_authenticated,
        permit_mynetworks,
# Backupserver (MX) erlauben
        permit_mx_backup,
# alles andere an relaying verbieten
        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änderungen starten wir nun noch unseren Mailserver einmal durch.

 # service postfix condrestart

Shutting down postfix:                                     [  OK  ]
Starting postfix:                                          [  OK  ]

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.

 # vim /etc/postfix/main.cf

# Django : 2009-02-02
# für den Backupmailserverbetrieb eingetragen 
# unbekannte Empfangsadressen final mit dem Fehlercode 577 ablehnen
unverified_recipient_reject_code = 577

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

 # service postfix restart

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