Dies ist eine alte Version des Dokuments!

Anbindung unseres MTAs Postfix 2.11 an einem Backend-Mailserver (Dovecot-IMAP-Server) unter CentOS7

In der Regel werden wir hinter unserem eigentlichen SMTP-Mailserver ein Backend System, so z.B. einen Dovecot-Server, bereithalten, von welchem unsere User ihre elektronische Post abholen. Damit unser Mailserver Postfix, der die Nachrichten von fremden Mailserver annimmt, bewertet und prüft, auch an unser internes Postoffice weiterleiten kann, sind noch Ergänzungen an der Konfiguration des Postfix-Mailservers notwendig.

Hier kommt es nun im Detail darauf an, auf welchen Hosts unser Postfix-SMTP-Server und wo der Dovecot-IMAP-Server betrieben wird.

Will man „nur“ einen kleinen Mailserver betreiben, bietet sich augenscheinlich als praktikabelste und einfachste Lösung die Methode via dovecot-lda.

In der Postfix-Konfigurationsdatei /etc/postfix/master.cf tragen wir am Ende folgende Zeilen nach.

 # vim /etc/postfix/master.cf

...
 
# ====================================================================
#
# Django : 2014-11-04 lovecot-lda aktiviert
dovecot     unix  -       n       n       -       5       pipe
  flags=DRhu user=vmail argv=/usr/libexec/dovecot/dovecot-lda -f ${sender} -d ${mailbox}
#
# ====================================================================
 
...

In der /etc/postfix/main.cf tragen wir in der Section ROUTING _ WEITERLEITEN VON NACHRICHTEN AN DAS EIGENTLICHE ZIEL noch folgende Optionen ein.

# vim /etc/postfix/main.cf

...
 
################################################################################
## ROUTING _ WEITERLEITEN VON NACHRICHTEN AN DAS EIGENTLICHE ZIEL
#
# Django : 2014-10-15 - Relayhost: Alle Nachrichten werden an den Relayhost
#          smtp-out.dmz.nausch.org gesendet.
# default: relayhost =
# relayhost = [smtp-out.dmz.nausch.org]
 
# Django : 2014-10-15 - Backup-Relayhost: Sollte der $relayhost nicht erreichbar
#          sein, soll sich unser MTA an den backup-relayhost 
#          smtp-backup.dmz.nausch.org senden
# default: smtp_fallback_relay = $fallback_relay 
# smtp_fallback_relay = [smtp-backup.dmz.nausch.org]
 
# Django : 2014-10-15 - Relay Domains: Postfix als eingehendes Mailrelay vor 
#          einem anderen Server
# default: relay_domains = $mydestination 
relay_domains = btree:/etc/postfix/relay_domains
 
# Django : 2014-10-15 - Nachrichten für eine bestimmte Richtung sollen
#          abweichend von den MX-Definitionen im DNS an dedizierte Ziele
#          geroutet/weitergeleitet werden.
# default: transport_maps =
transport_maps = btree:/etc/postfix/transport_maps
 
# Django : 2014-11-04 - Lokale Zustellung via pipe an den Dienst dovecot-lda zu 
#          unserem Dovecot-IMAP/POP3-Server 
# default: mailbox_transport =
#          dovecot_destination_recipient_limit = 1
mailbox_transport = cyrus
 
...

Damit nun unser Postfix SMTP-Server auch diese Zustellungsart verwendet kann, benötigen wir noch einen Eintrag in der transport-Tabelle. Diesen fürgen wir nun noch ans Ende der Datei ein.

 # vim /etc/postfix/transport_maps

/etc/postfix/transport_maps

# Kapitel 5.2.5 transport-Tabelle: Abweichende Zustellung
# Lookup-Tabelle zum Aktivieren einer alternativen Mailrouting bei der
# Zustellung an einen weiteren Mailserver. Nach dem Ändern und/oder
# Erweitern der Tabelle, muß noch mittels:
#               $ postmap /etc/postfix/transport_map
#
# die zugehörige Datenbank erzeugt werden.
#
# Alle eMails, die an Subdomains von nausch.org gerichtet sind
# ("." am Anfang der Zeile!) werden an den/die Mailserver von
# intra.nausch.org (MX-Records) weitergeleitet. (keine "["-Klammern!)
#.nausch.org                            smtp:intra.nausch.org
 
# Alle eMails, die an die Domain tachtler.net gerichtet sind, werden an 
# den bzw. die Mailserver der Mail-Domäne t-offline.de (MX-Records) 
# weitergeleitet. (keine "["-Klammern!) 
# tachtler.net                          smtp:t-offline.de
 
# Mails an backup.nausch.org werden an den Mailserver (A-Record) auf Port 25
# mit Namen mail.intra.nausch.org geschickt.
#backup.nausch.org                      smtp:[mail.intra.nausch.org]:25
 
# Django : 2013-02-21
# eMails an den Fax-Server an den Host vml000020 weiterleiten
fax.nausch.org                          smtp:[10.0.0.20]:25
# eMails an den Key-Server sollen an den Host vml000030 weitergeleitet
# werden.
keyserver.nausch.org                    smtp:[10.0.0.30]:25
 
# Django : 2013-02-22
# eMails an den Mailinglisten-Server an das Programm mailman weiterreichen
#lists.nausch.org                       mailman:
 
# Django : 2014-11-04
# eMails der Maildomäne nausch.org an das Programm dovecot-lda weiterleiten
nausch.org                              dovecot:

WICHTIG:

Diese Art der Anbindung ist jedoch nicht zu empfehlen und zwar aus folgenden drei Gründen!

Der Mailtransport ist nicht sehr performant, da für jede Mailzustellung ein separater Prozess gestartet werden.
Sind eMails mit mehreren Empfängern an den Dovecot-Server zu übergeben, so muss diese eMail entsprechend oft einzeln an jeden Empfänger übergeben werden.
Eine dynamische Empfängervalidierung ist bei dovecot-lda nicht möglich!

Darüber hinaus ist bei einer eventuell späteren Migration des Dovecot-IMAP-Servers auf einen separaten Server der Umprogrammierungsaufwand ungemein größer, als bei der nachfolgend beschriebenen Anbindungsvariante via LMTP. Also empfiehlt es sich lieber gleich, es vernünftig und richtig zu machen! ;)

Postfix (LMTP)

Da unser Mailserver nicht nur für die Hauptdomäne nausch.org eMails annehmen soll, sondern auch für die anderen (sub)Domains, erweiteren wir unsere Postfix-Konfiguration um ein paar Optionen.

Postfix nimmt immer dann Post außerhalb unseres $mynetworks an, wenn er sich zuständig fühlt. Hierzu kennt Postfix drei Klassen von Domains:

echte Domains $mydestination
Diese Variante haben wir schon bei der Installation eines sicheren Mailservers mit Postfix unter CentOS 7.x erschlagen.
zu relayende Domains $relay_domains
Mit diese Variante haben wir uns bereits bei der Anbingung unseres Mailservers an ein Backend-Mailgateway im Kapitel Anbindung an einem Backend-Mailserver (Cyrus-IMAP-Server) befasst.
virtuelle Domains $virtual_alias_domains
Eine alternative Einbindung virtueller Domains ist die Verwendung von virtual_alias_domains und virtual_alias_maps

Wichtig: Dabei ist es logisch ausgeschlossen, daß eine Domain mehreren dieser Klassen angehört. Also immer nur einer, aber niemals zwei oder gar drei!

Da wir unsere Maildomänen und Nutzerkonten mit Hilfe von Postfixadmin zur Verwaltung des Dovecot-IMAP-Server unter CentOS 7.x nutzen, werden wir die Option 3, also $virtual_alias_domains verwenden.

Konfiguration

In der Postfix-Konfigurationsdatei /etc/postfix/main.cf definieren wir also die nötigen Optionen zur Nutzung der virtuelle Mailboxen. Unsere Änderungen tragen wir in die Section LOOKUP-TABELLEN ein.

 # vim /etc/postfix/main.cf

...
 
# Django : 2014-10-15 - virtuelle Mail-Domains und Mailboxen mit Anbindung an
#          das mySQL-Datenbankbackend (Verwaltung mit Hilfe von postfixadmin)
# default: virtual_mailbox_domains = $virtual_mailbox_maps
#          virtual_alias_maps = $virtual_maps
#          virtual_mailbox_maps =
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf
 
virtual_alias_maps =      proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf
                          proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_maps.cf
                          proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_catchall_maps.cf
#
virtual_mailbox_maps =    proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
                          proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_mailbox_maps.cf
 
...

Für den Transport definieren wir nun den virtual_transport in Richtung Dovecot-Server, in unserem Konfigurationsbeispiel der Host mit der IP-adresse 10.0.0.77. Diese tragen wir in der Section ROUTING _ WEITERLEITEN VON NACHRICHTEN AN DAS EIGENTLICHE ZIEL nach.

 # vim /etc/postfix/main.cf

...
 
# Django : 2014-10-15 - Definition zur Erreichbarkeit unseres MDA-Servers 
#          Dovecot-IMAP
# default: virtual_transport = virtual
virtual_transport = lmtp:[10.0.0.77]:24

Konfiguration aktivieren

Zur Aktivierung unserer Konfiguration benutzen wir systemctl.

 # systemctl restart postfix

Da keine Rückmeldung erfolgte können wir davon ausgehen, dass alle unsere Konfigurationsoptionen unseren Wünschen entsprechend gesetzt wurden.

Wir können aber auch den Status unseres Mailservers abfragen.

 # systemctl status postfix

postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled)
   Active: active (running) since Mon 2014-11-03 22:35:18 CET; 3s ago
  Process: 3222 ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS)
  Process: 3206 ExecReload=/usr/sbin/postfix reload (code=exited, status=0/SUCCESS)
  Process: 3236 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
  Process: 3234 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
  Process: 3231 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
 Main PID: 3309 (master)
   CGroup: /system.slice/postfix.service
           ├─3309 /usr/libexec/postfix/master -w
           ├─3310 pickup -l -t unix -u
           └─3311 qmgr -l -t unix -u

Nov 03 22:35:17 vml000087.dmz.nausch.org systemd[1]: Starting Postfix Mail Transport Agent...
Nov 03 22:35:18 vml000087.dmz.nausch.org postfix/master[3309]: daemon started -- version 2.11.3, configuration /etc/postfix
Nov 03 22:35:18 vml000087.dmz.nausch.org systemd[1]: Started Postfix Mail Transport Agent.

Auch auf Seiten unseres Dovecot-Servers muss eine kleine Konfigurationserweiterung erfolgen.

Konfiguration

Zur Anbindung des MUA¹⁾ Dovecot an unseren MTA²⁾ Postfix nutzen wir das Protokoll LMTP. In der Konfigurationsdatei /etc/dovecot/conf.d/10-master.conf sind im Abschnitt service lmtp bereits verschiedene Dovecot-Listener enthalten.

Statt der vorbereiteten Variante über einen Unix-Datei-Socket, werden wir aber einen TCP/IP-Socket verwenden. Zum einen gibt es dabei keine großen Probleme in chroot-Umgebungen, bzw. können wir so recht einfach und schnell, den IMAP-Server von einem all-in-one-Host auf mehrere Maschinen aufteilen. Hierzu werden wir den LMTP-Port 24 auf eine eigene IP-Adresse binden, die der Postfix-Mailserver dann exclusiv ansprechen darf. Damit der LMTP-Port nicht von anderen Maschinen aus erreichbar ist, werden wir mit einer geeigneten firewalld-Regel, den Zugriff streng reglemetieren.

Als erstes werden wir nun die nötige LMTP-Konfiguration in der 10-master.conf festlegen.

  # vim /etc/dovecot/conf.d/10-master.conf

/etc/dovecot/conf.d/10-master.conf

...
 
service lmtp {
  unix_listener lmtp {
    #mode = 0666
  }
 
  # Create inet listener only if you can't use the above UNIX socket
  #inet_listener lmtp {
    # Avoid making LMTP visible for the entire internet
    #address =
    #port = 
  #}
  # Django : 2014-07-22
  # Einlieferung der Nachrichten via LMTP
  inet_listener lmtp {
    address = 10.0.0.70
    port = 24
  }
}
 
...

Aktivierung

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 vorgenannten Konfigurationsbeispiel werden für alle Empfänger Nachrichten angenommen, die in der statischen Lookup-Tabelle gelistet ist. Was ist nun aber, wenn das Backend-System wiederum die Annahme einer weitergeleiteten Nachricht verweigert? Richtig, unser Mailserver würde diese als Bounce zurück zum Absender schicken. Dies wollen wir eben sowenig, wie den zusätzlichen Pflegeaufwand für die richtige und aktuelle relay_recipients-Tabelle!

Wir werden daher einfach die Entscheidung, ob nun eine Nachricht angenommen werden soll, oder nicht, an das Backendsystem delegieren.

Den notwendigen Konfogurationseintrag 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 Bachricht von einem fremden Mailserver, beim Backend-System in Erfahrung zu bringen, ob dieses die Nachricht auch abnehmen würde. Ist dies der Fall, reicht Postfix die Nachricht an das Backend weiter. 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.