centos:mail_c7:postfix3_6

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

Postfix-Logo 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.

dovecot-lda - MTA und MDA auf gleichem Host

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

Konfiguration

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

 # vim /etc/postfix/master.cf
...
 
# ====================================================================
#
# Django : 2019-02-10 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 : 2019-02-10 - Relayhost: Alle Nachrichten werden an den Relayhost
#          smtp-out.dmz.nausch.org gesendet.
# default: relayhost =
# relayhost = [smtp-out.dmz.nausch.org]
 
# Django : 2019-02-10 - 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 : 2019-02-10 - Relay Domains: Postfix als eingehendes Mailrelay vor 
#          einem anderen Server
# default: relay_domains = $mydestination 
relay_domains = btree:/etc/postfix/relay_domains
 
# Django : 2019-02-10 - 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 : 2019-02-10 - 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ügen 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 : 2019-02-10
# 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 : 2019-02-10
# eMails an den Mailinglisten-Server an das Programm mailman weiterreichen
#lists.nausch.org                       mailman:
 
# Django : 2019-02-10
# 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!

  1. Der Mailtransport ist nicht sehr performant, da für jede Mailzustellung ein separater Prozess gestartet werden.
  2. 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.
  3. 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! ;)

LMTP - MTA und MDA auf gleichem bzw. getrennten Host(s)

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:

  1. echte Domains $mydestination
    Diese Variante haben wir schon bei der Installation eines sicheren Mailservers mit Postfix unter CentOS 7.x erschlagen.
  2. 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.
  3. 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 : 2019-02-10 - 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 : 2019-02-10 - 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.service

● postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2019-02-10 12:43:21 CET; 4min 22s ago
  Process: 27475 ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS)
  Process: 27592 ExecReload=/usr/sbin/postfix reload (code=exited, status=0/SUCCESS)
  Process: 27492 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
  Process: 27489 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
  Process: 27486 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
 Main PID: 27566 (master)
   CGroup: /system.slice/postfix.service
           ├─27566 /usr/libexec/postfix/master -w
           ├─27603 pickup -l -t unix -u
           └─27604 qmgr -l -t unix -u

Feb 10 12:47:39 vml000080.dmz.nausch.org systemd[1]: Reloading Postfix Mail Transport Agent.
Feb 10 12:47:39 vml000080.dmz.nausch.org postfix/master[27566]: reload -- version 3.3.2, configuration /etc/postfix
Feb 10 12:47:39 vml000080.dmz.nausch.org systemd[1]: Reloaded Postfix Mail Transport Agent.

Dovecot (LMTP)

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

Konfiguration

Zur Anbindung des MUA1) Dovecot an unseren MTA2) 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 : 2019-02-10
  # 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 restart des dovecot-Daemons durch. 

 # systemctl restart 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; vendor preset: disabled)
   Active: active (running) since Sun 2019-02-10 14:50:58 CET; 6s ago
     Docs: man:dovecot(1)
           http://wiki2.dovecot.org/
  Process: 8198 ExecStop=/usr/bin/doveadm stop (code=exited, status=0/SUCCESS)
  Process: 8209 ExecStart=/usr/sbin/dovecot (code=exited, status=0/SUCCESS)
  Process: 8203 ExecStartPre=/usr/libexec/dovecot/prestartscript (code=exited, status=0/SUCCESS)
 Main PID: 8212 (dovecot)
   CGroup: /system.slice/dovecot.service
           ├─8212 /usr/sbin/dovecot
           ├─8213 dovecot/pop3-login
           ├─8214 dovecot/imap-login
           ├─8215 dovecot/anvil [11 connections]
           ├─8216 dovecot/log
           ├─8218 dovecot/pop3-login
           ├─8219 dovecot/pop3-login
           ├─8220 dovecot/pop3-login
           ├─8221 dovecot/pop3-login
           ├─8222 dovecot/config
           ├─8223 dovecot/imap-login
           ├─8224 dovecot/imap-login
           ├─8225 dovecot/imap-login
           ├─8226 dovecot/imap-login
           └─8228 dovecot/auth [0 wait, 0 passdb, 0 userdb]

Feb 10 14:50:57 vml000077.dmz.nausch.org systemd[1]: Stopped Dovecot IMAP/POP3 email server.
Feb 10 14:50:57 vml000077.dmz.nausch.org systemd[1]: Starting Dovecot IMAP/POP3 email server...
Feb 10 14:50:58 vml000077.dmz.nausch.org systemd[1]: PID file /var/run/dovecot/master.pid not readable (yet?) after start.
Feb 10 14:50:58 vml000077.dmz.nausch.org dovecot[8212]: master: Dovecot v2.2.36 (1f10bfa63) starting up for imap, pop3, lmtp, sieve (core dumps disabled)
Feb 10 14:50:58 vml000077.dmz.nausch.org systemd[1]: Started Dovecot IMAP/POP3 email server.

Dynamische Empfänger-Verifizierung

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 Konfigurationseintrag finden wir bereits in der Hauptkonfigurationsdatei von unserem Postfix 3.x 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.

Konfiguration

Als erstes legen wir uns ein Datenverzeichnis, indem Postfix die überprüften Empfangsaddressen abspeichern kann, 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 : 2019-02-10 - 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

Dann aktivieren wir in der Section SMTP RECIPIENT RESTRICTIONS den bereits bei der Konfiguration unseres MTAs Postfix 2.11 unter CentOS7 vorbereiteten Eintrag 

#          Dynamische Prüfung auf existente Relay-Empfänger
#                            (Kapitel 12.2.2 Dynamische Empfänger-Verifizierung)
           reject_unverified_recipient

. 

 # vim /etc/postfix/main.cf
################################################################################
## SMTP RECIPIENT RESTRICTIONS
#
# Django : 2019-02-10 - 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

Konfiguration aktivieren

Zur Aktivierung unserer Konfiguration benutzen wir systemctl. 

 # systemctl reload 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.service

● postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)
   Active: active (running) since Sun 2019-02-10 13:37:21 CET; 4min 22s ago
  Process: 27475 ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS)
  Process: 27592 ExecReload=/usr/sbin/postfix reload (code=exited, status=0/SUCCESS)
  Process: 27492 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
  Process: 27489 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
  Process: 27486 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
 Main PID: 27566 (master)
   CGroup: /system.slice/postfix.service
           ├─27566 /usr/libexec/postfix/master -w
           ├─27603 pickup -l -t unix -u
           └─27604 qmgr -l -t unix -u

Feb 10 13:37:39 vml000080.dmz.nausch.org systemd[1]: Reloading Postfix Mail Transport Agent.
Feb 10 13:37:39 vml000080.dmz.nausch.org postfix/master[27566]: reload -- version 3.3.2, configuration /etc/postfix
Feb 10 13:37:39 vml000080.dmz.nausch.org systemd[1]: Reloaded Postfix Mail Transport Agent.

Datenpflege der Empfangsaddressen

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öscht 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.

Tests

Erreicht nun eine Kontaktanfrage von einem fremden Mailserver, also einem Server, der nicht in $mynetworks definiert ist, kann man im Logfile des Mailservers sehr schön beobachten, wie Postfix die Adressen überprüft.

Einlieferung via LMTP beim backend-System

Als erstes testen wir, ob wir von unserem SMTP-Server aus beim IMAP-Server auf Port 24 (LMTP) eine Nachricht einliefern können. Damit wir uns beim Tippen nicht die Finger brechen und/oder vertippen, greifen wir auf das Hilfsprogramm swaks von John Jetmore zurück. 

 # swaks --to django@nausch.org --from michael@nausch.org --header-X-Test "test email" --server 10.0.0.77 --protocol LMTP
=== Trying 10.0.0.77:24...
=== Connected to 10.0.0.77.
<-  220 imap.nausch.org Dovecot ready.
 -> LHLO vml000087.dmz.nausch.org
<-  250-imap.nausch.org
<-  250-8BITMIME
<-  250-ENHANCEDSTATUSCODES
<-  250 PIPELINING
 -> MAIL FROM:<michael@nausch.org>
<-  250 2.1.0 OK
 -> RCPT TO:<django@nausch.org>
<-  250 2.1.5 OK
 -> DATA
<-  354 OK
 -> Date: Sun, 10 Feb 2019 14:45:15 +0100
 -> To: django@nausch.org
 -> From: michael@nausch.org
 -> Subject: test Sun, 10 Feb 2019 14:45:15 +0100
 -> X-Mailer: swaks v20130209.0 jetmore.org/john/code/swaks/
 -> X-Test: test email
 -> 
 -> This is a test mailing
 -> 
 -> .
<-  250 2.0.0 <django@nausch.org> P90YOokWWVS8GQAArK2B9Q Saved
 -> QUIT
<-  221 2.0.0 OK
=== Connection closed with remote host.

Im Maillog des empfangendem System wird die erfolgreiche Zustellung entsprechend protokolliert. 

Feb 10 14:45:15 vml000077 dovecot: lmtp(6588): Connect from 10.0.0.87
Feb 10 14:45:15 vml000077 dovecot: lmtp(django@nausch.org): copy from <lmtp DATA>: box=INBOX, uid=8161, msgid=, size=476, from=michael@nausch.org
Feb 10 14:45:15 vml000077 dovecot: lmtp(django@nausch.org): P90YOokWWVS8GQAArK2B9Q: sieve: msgid=unspecified: stored mail into mailbox 'INBOX'
Feb 10 14:45:15 vml000077 dovecot: lmtp(6588): Disconnect from 10.0.0.87: Successful quit

erfolgreiche Einlieferung via SMTP beim frontend-System

Als nächstes liefern wir eine Nachricht bei unserem SMTP-Server auf Port 25 ein. Auch hier benutzen wir als Hilfsmittel swaks. 

 # swaks --to django@nausch.org --from michael@nausch.org --header-X-Test "test email" --server 10.0.0.80 --protocol SMTP
=== Trying 10.0.0.80:25...
=== Connected to 10.0.0.80.
<-  220 mx01.nausch.org ESMTP Postfix
 -> HELO pml010048
<-  250 mx01.nausch.org
 -> MAIL FROM:<michael@nausch.org>
<-  250 2.1.0 Ok
 -> RCPT TO:<django@nausch.org>
<-  250 2.1.5 Ok
 -> DATA
<-  354 End data with <CR><LF>.<CR><LF>
 -> Date: Sun, 10 Feb 2019 14:47:21 +0100
 -> To: django@nausch.org
 -> From: michael@nausch.org
 -> Subject: test Sun, 10 Feb 2019 14:47:54 +0100
 -> X-Mailer: swaks v20130209.0 jetmore.org/john/code/swaks/
 -> X-Test: test email
 -> 
 -> This is a test mailing
 -> 
 -> .
<-  250 2.0.0 Ok: queued as 904BBC00088
 -> QUIT
<-  221 2.0.0 Bye
=== Connection closed with remote host.

Im Maillog werden nun mehrere Dinge dokumentiert. 

 Feb 10 14:48:54 vml000080 postfix/smtpd[4934]: connect from vml000020.dmz.nausch.org[10.0.0.20]

Der Client vml000020.dmz.nausch.org mit der IP 10.0.0.20 hat sich mit dem SMTP-Server verbunden. 

 Feb 10 14:48:55 vml000080 postfix/cleanup[4941]: 8EC29C00088: message-id=<20141104195355.8EC29C00088@mx01.nausch.org>

Das Cleanup-Modul hat die Message-ID 20141104195355.8EC29C00088@mx01.nausch.org vergeben. 

 Feb 10 14:48:55 vml000080 postfix/qmgr[4933]: 8EC29C00088: from=<double-bounce@nausch.org>, size=231, nrcpt=1 (queue active)
 Feb 10 14:48:55 vml000080 postfix/lmtp[4942]: 8EC29C00088: to=<django@nausch.org>, relay=10.0.0.77[10.0.0.77]:24, delay=0.07, delays=0.02/0.02/0/0.03, dsn=2.1.5, status=deliverable (250 2.1.5 OK)
 Feb 10 14:48:55 vml000080 postfix/qmgr[4933]: 8EC29C00088: removed

Der verify-Daemon erstellt eine Test-Nachricht und schickt diese an den Zielserver. Da die Adresse zustellbar status=deliverable (250 2.1.5 ok) ist, entfernt der Queue-Manager die Testnachricht wieder. 

 Feb 10 14:48:58 vml000080 postfix/smtpd[4934]: 904BBC00088: client=vml000020.dmz.nausch.org[10.0.0.20]
 Feb 10 14:48:58 vml000080 postfix/cleanup[4941]: 904BBC00088: message-id=<>
 Feb 10 14:48:58 vml000080 postfix/qmgr[4933]: 904BBC00088: from=<michael@nausch.org>, size=427, nrcpt=1 (queue active)
 Feb 10 14:48:58 vml000080 postfix/smtpd[4934]: disconnect from vml000020.dmz.nausch.org[10.0.0.20]

Die Nachricht wird dem einliefernden Mailclient abgenommen. 

 Feb 10 14:48:58 vml000080 postfix/lmtp[4942]: 904BBC00088: to=<django@nausch.org>, relay=10.0.0.77[10.0.0.77]:24, delay=4.4, delays=4.3/0/0/0.1, dsn=2.0.0, status=sent (250 2.0.0 <django@nausch.org> OAlZJdMuWVRiJQAArK2B9Q Saved)
 Feb 10 14:48:58 vml000080 postfix/qmgr[4933]: 904BBC00088: removed

Die Nachricht wurde erfolgreich an das backend-System übergeben.

Zustellversuch an nicht existierenden Empfänger via SMTP beim frontend-System

Als nächstes versuchen wir eine Nachricht an einen nicht existierenden Empfänger zu schicken. 

 $ swaks --to paeddrigg@nausch.org --from michael@nausch.org --header-X-Test "test email" --server 10.0.0.80 --protocol SMTP
=== Trying 10.0.0.80:25...
=== Connected to 10.0.0.80.
<-  220 mx01.nausch.org ESMTP Postfix
 -> HELO pml010048
<-  250 mx01.nausch.org
 -> MAIL FROM:<michael@nausch.org>
<-  250 2.1.0 Ok
 -> RCPT TO:<paeddrigg@nausch.org>
<** 450 4.1.1 <paeddrigg@nausch.org>: Recipient address rejected: unverified address: Recipient address lookup failed. Contact your postmaster/admin for technical assistance. He can achieve our postmaster via email: postmaster@nausch.org or via fax: +49 8121 883179. In any case, please provide the following information in your problem report: This error message, time (Nov 04 21:09:53), client (10.0.0.20) and server (mx01.nausch.org).
 -> QUIT
<-  221 2.0.0 Bye
=== Connection closed with remote host.

Die Annahme der Nachricht wurde verweigert, da die Adresse nicht überprüft werden konnte. Im Maillog sieht man nun sehr schön wieder den Versuch die Adresse zu überprüfen. 

 Feb 10 15:00:50 vml000080 postfix/qmgr[4933]: 14246C00088: from=<double-bounce@nausch.org>, size=231, nrcpt=1 (queue active)
 Feb 10 15:00:50 vml000080 postfix/lmtp[5001]: 14246C00088: to=<paeddrigg@nausch.org>, relay=10.0.0.77[10.0.0.77]:24, delay=0.08, delays=0.03/0.01/0.01/0.02, dsn=5.1.1, status=undeliverable (host 10.0.0.77[10.0.0.77] said: 550 5.1.1 <paeddrigg@nausch.org> User doesn't exist: paeddrigg@nausch.org (in reply to RCPT TO command))
 Feb 10 15:00:50 vml000080 postfix/qmgr[4933]: 14246C00088: removed
 Feb 10 15:00:53 vml000080 postfix/smtpd[4994]: NOQUEUE: reject: RCPT from vml000020.dmz.nausch.org[10.0.0.20]: 450 4.1.1 <paeddrigg@nausch.org>: Recipient address rejected: unverified address: Recipient address lookup failed; from=<michael@nausch.org> to=<paeddrigg@nausch.org> proto=SMTP helo=<pml010048>

Hier wurde nun der Status status=undeliverable gemeldet, da der Empfänger nicht erreichbar war.

verify-Datenbank

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
 _LAST_CACHE_CLEANUP_COMPLETED_  1415130835
 django@nausch.org       0:0:1415130835:250 2.1.5 OK
 paeddrigg@nausch.org    2:0:1415131790:host 10.0.0.77[10.0.0.77] said: 550 5.1.1 <paeddrigg@nausch.org> User doesn't exist: paeddrigg@nausch.org (in reply to RCPT TO command)

Links

1)
Mail User Agent
2)
Mail Transport Agent
Diese Website verwendet Cookies. Durch die Nutzung der Website stimmen Sie dem Speichern von Cookies auf Ihrem Computer zu. Außerdem bestätigen Sie, dass Sie unsere Datenschutzbestimmungen gelesen und verstanden haben. Wenn Sie nicht einverstanden sind, verlassen Sie die Website.Weitere Information
  • centos/mail_c7/postfix3_6.txt
  • Zuletzt geändert: 22.07.2019 15:06.
  • von 127.0.0.1