Ubuntu 16.04 - Postfix als Relayhost (Smarthost)
Vorwort
Diese Dokumentation beschreibt den Installationsvorgang von Postfix als Relayhost.
Bitte vergewissern Sie sich, dass Ihr System über die nötigen Voraussetzungen verfügt, wie in der Infobox beschrieben. Weiterhin sind Grundkenntnisse im Umgang mit Linux erforderlich, da die Vorgehensweise, wie sie hier beschrieben ist, in manchen Teilen abweichen kann. Kein System ist wie das Andere. Die Dokumentation wurde sorgfältig von mir geprüft. Dennoch kann ich keinerlei Haftung für Schäden an Ihrem System oder eine Gewährleistung übernehmen. Bitte verwenden Sie diese Dokumentation auf eigene Gefahr.
Verwendete Software:
Voraussetzungen:
- Ubuntu 16.04 LTS
- Feste IP-Adresse mit PTR
- öffentliche Domain mit Zugriff auf DNS
- funktionierender Back-End Mailserver, z.B.:
Weitere, empfohlene Dokumentationen:
- SPF, DKIM und DMARC in Postfix einrichten
- SpamAssassin in Postfix einrichten
- Postfix als Mailserver mit Dovecot und PostfixAdmin
Warum ein Relayhost?
Zum Betrieb eines sicheren Mail-Systems ist kann es sinnvoll sein, ein externes Mail-Relay zum Empfangen und Versenden von E-Mails zu verwenden. Die Gründe sind vielfältig:
- Ein Mail-Server kann nicht sinnvoll an einem Internet-Anschluss mit dynamischer (wechselnder) IP-Adresse betrieben werden. Die meisten Mail-Server lehnen dynamische Adressräume ab bzw. deklarieren sie von vorneherein als Spam.
- Ihr interner Mail-Server wird durch den Relayhost geschützt. Der interne Mail-Server enthält die eigentlichen Nutzdaten (E-Mails, Adressbücher, usw.) und muss nicht mehr komplett aus dem Internet erreichbar sein. Somit bieten Sie, durch den Einsatz eines Relayhosts, deutlich weniger Angriffsfläche für Hacker.
- Der Relayhost kann eigenständig unerwünschte Absender filtern. Dadurch wird der interne Mail-Server entlastet.
- Sollte Ihr interner Mailserver ausfallen oder aufgrund einer Wartung vorübergehend nicht erreichbar sein, werden eingehende Emails auf dem Relayhost gepuffert und zugestellt, sobald der interne Mailserver wieder erreichbar ist. Damit erhöhen Sie Ausfallsicherheit und die Verfügbarkeit Ihres Mailsystems.
Was brauche ich dafür?
Fangen wir mit den technischen Voraussetzungen an:
Wie schon weiter oben erwähnt, macht es keinen Sinn, einen Mailserver an einem privaten Internet-Anschluss zu betreiben. E-Mails aus IP-Adress-Kreisen für privat genutze Internet-Anschlüsse werden von den meisten Mailservern abgelehnt oder wie Spam behandelt.
Sie benötigen also einen Linux-Root-Server oder Linux-vHost mit fester IP-Adresse und die Möglichkeit, einen PTR zu setzen. Dies ist bei den meisten Hosting-Anbietern problemlos möglich. Ein geeigneter vHost ist schon ab 5€/Monat bei, z.B. 1&1 IONOS zu haben. Sollten Sie bereits über einen solchen Server verfügen, setzen Sie diesen am besten zurück und verwenden Sie ein frisch installiertes Betriebsystem mit aktuellem Patchstand.
Weiterhin benötigen Sie mindestens eine eigene Domain mit Zugriff auf die DNS-Konfiguration. Gute Erfahrungen habe ich mit DomainFactory gemacht.
Für die Verschlüsselung empfehle ich ein gültiges SSL-Zertifikat. Zwar lehnen die meisten Mailserver ein selbstsigniertes oder ungültiges SSL-Zertikat nicht ab, aber ein vernünftiger Relayhost sollte so regelkonform wie möglich betrieben werden. Günstige SSL-Zertifikate sind z.B. bei DomainFactory oder interSSL erhältlich.
Natürlich benötigen Sie auch einen funktionierenden Back-End-Mailserver, der an den Relayhost angebunden wird. Das kann grundsätzlich jeder Mailserver sein. Egal ob Postfix, Lotus Domino, Microsoft Exchange, usw.
Sie können auch einen eigenen Back-End-Mailserver aufsetzen. Die entsprechende Dokumentation finden Sie hier Postfix als Mailserver mit Dovecot und PostfixAdmin.
Zusammengefasst:
- Linux-Root-Server oder vHost
- feste IP-Adresse mit PTR
- mindestens eine eigene Domain mit Zugriff auf DNS
- 1 SSL-Zertifikat pro Domain oder WildCard
- funktionierender Mail-Server
Weiter geht es mit den persönlichen Voraussetzungen:
Sie müssen kein Profi sein. In dieser Dokumentation sind wichtige Konfigurations-Parameter und Begriffe erklärt oder verlinkt. Alle erforderlichen Schritte sind aufgeführt. Die Dokumentation ist allerdings kein Lehrbuch. Jeden Parameter zu erklären würde den Rahmen völlig sprengen.
Sie sollten über grundlegende Linux-Kenntnisse verfügen und sicher im Umgang mit dem Bearbeiten und Lesen von Konfigurations-Dateien sein. Ausdrücke, wie z.B. Kommandozeile, Editor, SSH-Zugang oder PuTTY, sollten Ihnen ein Begriff sein. Auch sollten Sie wissen, wie ein Mailserver, auf SMTP-Ebene, grundsätzlich arbeitet.
Lassen Sie sich nicht entmutigen, wenn etwas nicht funktioniert. Die meisten Probleme sind mit wenigen Handgriffen zu lösen und es gibt haufenweise Tips im Internet. Wenn Sie aber feststellen, dass in dieser Dokumentation etwas unklar oder falsch ist, dann lassen Sie mich das bitte wissen. Senden Sie hierzu einfach eine E-Mail an twilight[at]twlnet.com.
Zusammengefasst:
- grundlegende Linux-Kenntnisse
- sicherer Umgang mit Konfig-Dateien
- grundlegende SMTP-Kenntnisse
Welche technischen Eigenschaften wird der Relayhost haben?
Der Relayhost wird eingehende E-Mails für Ihre Domain annehmen und Ihrem internen Mail-Server zustellen. E-Mails, die potenziell gefährliche Anhänge enthalten (z.B. *.exe, *.bat, etc.) werden geblockt. Der Absender wird über diesen Vorgang informiert. Eingehende E-Mails können verschlüsselt übertragen werden. Die Verschlüsselung enthält Perfect Forward Secrecy mit täglich wechselnden Diffie-Hellman-Parametern.
Falls Sie mehrere Domains und/oder mehrere interne Mail-Server mit dem Relayhost verwalten möchten, können die Domains entweder, alle dem gleichen internen Mail-Server zugestellt werden, oder es kann pro Domain ein separater interner Mail-Server angegeben werden.
Der Versand von E-Mails (das eigentliche Relaying) wird nur authentifizierten Benutzern ermöglicht. Die Authentifizierung läuft über Cyrus-SASL und ist immer verschlüsselt. Bei ausgehenden E-Mails werden die Header-Informationen bereinigt. Dem Empfänger werden nur Header-Informationen übermittelt, die Pflichangaben nach RFC 5322 sind bzw. zum E-Mail-Versand benötigt werden.
Öffentliche Relayhosts bzw. Mail-Server sind regelmässig Opfer von Brute-Force-Attacken. Durch unzählige Eingaben von Kombinationen aus Benutzernamen und Passwörtern wird versucht, den Relayhost bzw. Mail-Server für eigene Zwecke zu mißbrauchen. In der Regel wird dabei auch auf Passwortlisten zurückgegriffen. Unser Relayhost wird bei einem sochen Vorfall, die IP-Adresse des Angreifers für eine festgelegte Zeit sperren und den Administraor ausführlich über den Vorfall informieren.
Zusammengefasst:
Dienste und Ports:
- Port TCP 25 SMTP, für die Annahme und Weiterleitung von E-Mails
- Port TCP 587 Submission, für die Authentifizierung am Relayhost und die Anbindung interner Mail-Server
Authentifizierung:
- SASL, über lokale sasldb
Verschlüsselung:
- STARTTLS, PFS mit Diffie-Hellman-Schlüsselaustausch
Weitere Sicherheitsmerkmale:
- Blockierung gefährlicher Dateinamen über RegEx
- Anonymisierung des E-Mails-Headers
- Diffie-Hellman-Parameter werden täglich erneuert
- Brute-Force-Schutz
Wie kann die Sicherheit weiter erhöht werden?
Grundsätzlich können Sie den Relay-Host, so wie hier beschrieben, betreiben.
Ein Mail-System sollte aber weitere Aufgaben erfüllen können, die über das schlichte Versenden und Empfangen von E-Mails hinaus gehen. Es sollte zuverlässig Spam erkennen, die Authentizität versendeter E-Mails gewährleisten und weitere, vertrauenswürdige Eigenschaften aufweisen.
Meine Empfehlung ist, im Anschluss an diese Dokumentation, den Relayhost um folgende Funktionen zu erweitern:
Was muss ich in der Konfiguration anpassen?
Einige Parameter müssen auf Ihre Umgebung angepasst werden. Im Verlauf dieser Dokumentation müssen Sie nur die Parameter anpassen, die in der nachfolgenden Tabelle aufgelistet sind. Sie können also ganz einfach durch die Funktion "Suchen und Ersetzen" (STRG + H), die Konfigurationsdateien auf Ihre Umgebung anpassen. Das Gleiche gilt für auszuführende Kommandos.
Folgende Parameter werden verwendet:
| Wert | Hinweis | |
|---|---|---|
| Hostname Relayhost | relayhost.example.com | Ersetzen Sie diesen Wert durch den FQDN Ihres Servers. |
| Hostname Back-End-Mailserver | back-end-mailserver.tld | Ersetzen Sie diesen Wert durch den FQDN Ihres Back-End-Mailservers. |
| IPv4-Adresse | 192.0.2.42 | Ersetzen Sie diesen Wert durch die öffentliche IPv4-Adresse Ihres Servers. |
| IPv6-Adresse (falls vorhanden) | 2001:db8:0:8d3:0:8a2e:70:7344 | Ersetzen Sie diesen Wert, durch die öffentliche IPv6-Adresse Ihres Servers. |
| Domain | example.com | Ersetzen Sie diesen Wert durch Ihre Domain. |
| SSL-Zertifikat | /etc/ssl/private/selfsigned-cert.crt | Ersetzen Sie diesen Wert durch den Pfad und den Namen Ihres SSL-Zertifikats. |
| SSL-Zertifikat Private Key | /etc/ssl/private/selfsigned-cert.key | Ersetzen Sie diesen Wert durch den Pfad und den Namen des private Keys Ihres SSL-Zertifikats. |
| Root-E-Mail-Adresse | root@example.com | Ersetzen Sie diesen Wert durch die E-Mail-Adresse desjenigen, der E-Mails für Root erhalten soll. |
| Fail2ban-E-Mail-Adresse(Absender) | fail2ban@example.com | Absender-Adresse für den Dienst Fail2ban. Passen Sie hier einfach nur die Mail-Domain an. |
Konfigurations-Dateien werden immer nach dem gleichen Muster erstellt. Unter jeder Datei, die eine Anpassung erfordert, finden Sie die nötigen Hinweise.
Dateien, die zwar Parameter aber keine eigentliche Konfiguration enthalten, werden nach dem vorgegebenen Syntax erstellt.
Beispiel:
Im folgenden Beispiel ist die Datei /home/beispiel.conf zu erstellen und der Parameter domain anzupassen.
Erstellen Sie eine neue Datei /home/beispiel.conf mit folgendem Inhalt:
# nano /home/beispiel.conf
url = www.twlnet.com
content = Dokumentationen
domain = example.com
owner = root
# beispiel.conf
[...]
domain = example.com
[...]
Im folgenden Beispiel ist die Datei /home/beispiel.map mit einer Liste Ihrer E-Mail-Adressen zu erstellen.
Erstellen Sie eine neue Datei /home/beispiel.map nach folgendem Syntax:
# nano /home/beispiel.map
benutzer1@example.com
benutzer2@example.com
benutzer3@example.com
Server vorbereiten
Root-Rechte einräumen
Während der gesamten Dokumentation werden Root-Rechte benötigt. Um auf das Voranstellen von sudo zu verzichten, verschaffen Sie sich für die gesamte Sitzung erhöhte Rechte mit:
# sudo -i
Update durchführen
Bringen Sie den Server auf den aktuellen Patchstand:
# apt update && apt upgrade
Hostname vergeben
Vergeben Sie den hostname und den mailname:
# hostnamectl set-hostname mailserver.example.com # cat /etc/hostname > /etc/mailname
Editieren Sie die Datei /etc/hosts und ändern Sie den Hostnamen nach folgendem Syntax:
# nano /etc/hosts
127.0.0.1 localhost
127.0.1.1 mailserver.example.com mailserver
[...]
Software herunterladen und installieren
Laden Sie Postfix, SASL und Fail2ban aus dem offieziellen Ubuntu-Repository herunter:
# apt-get install postfix postfix-pcre sasl2-bin libsasl2-2 libsasl2-modules fail2ban whois
Wählen Sie im Fenster Postfix Configuration Internet-Site aus und bestätigen Sie mit der Enter-Taste:
Im nächsten Fenster ist keine Anpassung erforderlich (der Parameter wird im weiteren Verlauf der Dokumentation angepasst). Bestätigen Sie das Fenster einfach mit der Enter-Taste:
TLS-Verschlüsselung einrichten
Der Relayhost soll zum Einen verhindern, dass bei der Authentifizierung der Benutzername und das Passwort im Klartext übertragen wird und zum Anderen die Möglichkeit bieten, E-Mails verschlüsselt zu empfangen. Mittlerweile nutzen die meisten Mail-Server die TLS-Verschlüsselung. Mail-Servern, die immer noch kein STARTTLS unterstützen, räumt der Relayhost dennoch den unverschlüsselten Übertragungsweg ein. Das ist leider gängige Praxis, die auch in dieser Dokumentation berücksichtigt wird.
SSL-Zertifikat erstellen
Um den Relayhost mit STARTTLS zu verwenden, muss ein SSL-Zertifikat erstellt werden. Dieses SSL-Zertifikat können Sie entweder offiziell signieren lassen (i.d.R. kostenpflichtig) oder ein kostenloses, selbstsigniertes Zertifikat erstellen.
Meine Empfehlung ist ein, von einer offiziellen Zertifizierungsstelle siginiertes, SSL-Zertifikat zu erwerben. Zwar lehnen die meisten Mail-Server ein selbstsigniertes oder ungültiges SSL-Zertikat nicht ab, aber ein vernünftiger Relayhost sollte so regelkonform wie möglich betrieben werden. Günstige SSL-Zertifikate sind z.B. bei DomainFactory oder interSSL erhältlich.
Wechseln Sie in den Ordner /etc/ssl/private und erstellen Sie ein selbstsiginiertes Zertifikat:
# cd /etc/ssl/private # openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout selfsigned-cert.key -out selfsigned-cert.crt
Geben Sie die Informationen ein, die das Zertifikat enthalten soll. Wichtig ist hierbei nur der Common Name. Geben Sie als Common Name den FQDN des Mailservers an.
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []: mailserver.example.com
Email Address []:
Passen Sie die Berechtigungen auf den Private Key an:
# chmod 600 *.key
Diffie-Hellman-Parameter erstellen
Der erste Parameter p besteht aus einer grossen Primzahl und der Zweite gibt den sogenannten Generator-Wert g an (bei OpenSSL ist dieser Wert "2").
Beide Parameter werden anschliessend in einer Datei abgelegt.
Da die, in RFC 2409 empfohlene, Schlüssellänge von 1024 Bit als nicht mehr sicher gilt, generieren wir die Parameter mit einer Schlüssellänge von 4096 Bit ("4096-bit MODP Group" gemäß RFC 3526).
In unserem Setup verwenden wir die DH-Parameter für die TLS-Verschlüsselung (STARTTLS) von Postfix.
Den entsprechden Parameter finden Sie später in der Datei /etc/postfix/main.cf:
# main.cf
[...]
#TLS
##################################################
[...]
smtpd_tls_dh1024_param_file = /etc/ssl/private/dh4096.pem
[...]
Erstellen Sie die Diffie-Hellman-Parameter im Ordner /etc/ssl/private:
# cd /etc/ssl/private # openssl dhparam -out dh4096.tmp 4096 && mv dh4096.tmp dh4096.pem # chmod 600 dh4096.pem
Diffie-Hellman-Parameter täglich erneuern
Grosse Organisationen, wie z.B. die NSA, könnten Rainbow Tables für Default-Diffie-Hellman-Parameter besitzen. Schenkt man dem NSA-Whistleblower Edward Snowden Glauben, ist diese Annahme sogar plausibel. Mit der entsprechenden Rechenleistung könnten demnach für häufig verwendete Diffie-Hellman-Parameter Rainbow Tables berechnet werden. Hier hilft eine gute Server-Konfiguration, die auf maximale Sicherheit ausgelegt ist. Unser Mailserver soll daher täglich die verwendeten Diffie-Hellman-Parameter erneuern.
Erstellen Sie die Datei /etc/cron.daily/dh-param-regeneration mit folgendem Inhalt:
# nano /etc/cron.daily/dh-param-regeneration
#!/bin/sh
#
#########################################################################
# Script Name : dh-param-regeneration #
# Description : Regenerates Diffie Hellman Parameter and sets #
# File-Permission #
# Args : #
# #
# Version : 1.00 #
# Last Update : 03.02.2021 #
# Author : Twilight #
# Email : twilight@twlnet.com #
# Web: : https://www.twilight-networks.com #
#########################################################################
# Tested with : Ubuntu 16.04 LTS #
#########################################################################
# File-Dir
DHDIR='/etc/ssl/private/'
# Key-Size
DHBIT='4096'
# Normaly there is no need to change anything below this comment line!
#########################################################################
if [ ! -d ${DHDIR} ]; then
echo Error: Directory "'"${DHDIR}"'" does not exist!
exit 1
fi
FILE=`mktemp` ;
openssl dhparam -out $FILE ${DHBIT} > /dev/null 2>&1 && mv -f $FILE ${DHDIR}dh${DHBIT}.pem
chmod 600 ${DHDIR}dh${DHBIT}.pem
exit 0
#end
Setzen Sie die nötigen Zugriffsrechte, damit die Datei ausgeführt werden kann:
# chmod 755 /etc/cron.daily/dh-param-regeneration
SASL Authentifizierung einrichten
Als Authentifizierungs-Verfahren für die Anmeldung am Submission-Dienst von Postfix wählen wir plain und login. Zwar sind das Verfahren, bei denen der Benutzername und das Kennwort unverschlüsselt übertragen werden, da wir aber strikte TLS-Verschlüsselung fordern, stellt das kein Problem dar.
Das Verfahren plain ist im RFC 4616 festgelegt.
Cyrus-SASL konfigurieren
Erstellen Sie die Datei /etc/postfix/sasl/smtpd.conf mit folgendem Inhalt:
# nano /etc/postfix/sasl/smtpd.conf
pwcheck_method: saslauthd mech_list: PLAIN LOGIN log_level: 9
Editieren Sie die Datei /etc/default/saslauthd und ändernd Sie folgende Parameter:
# nano /etc/default/saslauthd
START=yes MECHANISMS="sasldb"
Fügen Sie den Benutzer postfix der Gruppe sasl hinzu, damit Postfix mit dem SASL-Daemon kommunizieren darf:
# adduser postfix sasl
Starten Sie den Dienst saslauthd neu, damit die Konfiguration angewendet wird:
# service saslauthd restart
Relay-Benutzer anlegen
Für das Versenden von E-Mails, also die Zustellung einer E-Mail an einen externen Mailserver, ist ein authentifizierter Benutzer erforderlich.
Nur einem authentifizierten Benutzer werden die sogenannten Relay-Rechte eingeräumt.
In diesem Abschnitt erstellen wir den Benutzer relay-benutzer@example.com. Diesen Benutzer wird der interne Mailserver für die Authentifizierung am Relayhost verwenden. Sollten Sie mehrere Relay-Benutzer benötigen, erstellen Sie einfach Weitere nach dem gleichen Syntax.
Der Syntax lautet:
saslpasswd2 -c -u DOMAIN BENUTZERNAME
Erstellen Sie einen Relay-Benutzer mit dem Kommando saslpasswd2 nach folgendem Syntax:
# saslpasswd2 -c -u example.com relay-benutzer Password: Again (for verification):
Postfix konfigurieren
Master.cf anlegen
In der Datei master.cf wird der sogennannte Master-Prozess konfiguriert. Der Master-Prozess ist die oberste Ebene der Postfix-Architektur und legt fest, wie andere, untergeordnete Prozesse (z.B. der smtpd-daemon) zu starten sind. Er ist die erste Anlaufstelle für eingehende Postfix-Aufgaben und delegiert diese an andere Prozesse weiter. Bei mehreren gleichartigen Aufgaben kann der Master-Prozess auch weitere Instanzen eines Prozesses starten.
Die Datei master.cf enthält nicht sehr viel Konfiguration und muss in den meisten Fällen auch nicht in grösserem Umfang angepasst werden.
Wir konfigurieren für unser Setup den
smtpd-daemonmit dem Dienstsubmission. Das ist unser Dienst zum authentifizierten Versenden von E-Mails zu entfernten Mailservern (relaying).cleanup-daemonmit dem Dienstsubmission-header_checkszur Bereinigung des E-Mail-Headers von ausgehenden E-Mails.
Löschen Sie die Datei /etc/postfix/master.cf:
# rm /etc/postfix/master.cf
Erstellen Sie eine neue Datei /etc/postfix/master.cf mit folgendem Inhalt:
# nano /etc/postfix/master.cf
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (no) (never) (100)
# ==========================================================================
smtp inet n - n - - smtpd
submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject_unauth_destination
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o smtpd_helo_restrictions=permit_sasl_authenticated,reject
-o smtpd_sender_restrictions=permit_sasl_authenticated,reject
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o cleanup_service_name=submission-header_checks
submission-header_checks unix n - n - 0 cleanup
-o header_checks=pcre:${config_directory}/header_checks
pickup unix n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discard unix - - n - - discard
#local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1 scache
#
# ====================================================================
Main.cf anlegen
Die Datei main.cf ist die zentrale Konfigurations-Datei von Postfix. Sie enthält fast die gesamte Server-Konfiguration und kann sehr umfangreich werden. Es ist daher von grosser Bedeutung, die Datei übersichtlich zu gestalten.
Der wichtigste Teil sind die sogenannten SMTPD Restrictions. Diese regeln die Kommunikation zwischen Mailclient und Mailserver und legen fest, nach welchten Kriterien eine E-Mail anzunehmen oder abzulehnen oder ist. Auch das Relay-Recht, also die Zustellung einer E-Mail an einen externen Mailserver wird innerhalb der SMTPD Restrictions geregelt.
Unser Mailserver läuft, so weit es für die Praxis Sinn macht, RFC-konform. Wir nehmen also nur E-Mails an, die den Kriterien der RFC 821 und RFC 2821 entsprechen und versenden selber natürlich genauso. Weiterhin bieten wir STARTTLS mit sicherer Cipher Suite und Diffie-Hellman-Schlüsselaustausch an. Für die Benutzer-Authentifizierung wird Dovecot als SASL-Provider verwendet.
Es würde den Umfang dieser Dokumentation sprengen, wenn ich auf die gesamte Konfiguration der main.cf eingehen würde.
Alle Konfigurations-Parameter finden Sie auf der offiziellen Seite von Postfix.
Löschen Sie die Datei /etc/postfix/main.cf:
# rm /etc/postfix/main.cf
Erstellen Sie die Datei /etc/postfix/main.cf mit folgendem Inhalt:
# nano /etc/postfix/main.cf
# HOST CONFIGURATION
#########################################################################
myhostname = relayhost.example.com
mydomain = example.com
myorigin = $mydomain
mynetworks = 127.0.0.0/8
mynetworks_style = host
mydestination =
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
setgid_group = postdrop
local_transport = error:no local delivery
local_recipient_maps =
transport_maps = hash:${config_directory}/relay_transport
delay_warning_time = 4h
alias_maps = hash:${config_directory}/aliases
alias_database = $alias_maps
config_directory = /etc/postfix
compatibility_level = 2
parent_domain_matches_subdomains = debug_peer_list smtpd_access_maps
relay_recipient_maps = hash:${config_directory}/relay_recipient_maps
relay_domains = example.com
# maximale Nachrichtengrösse in Byte (50 MByte)
message_size_limit = 52428800
# SMTPD CONFIGURATION
#########################################################################
smtpd_banner = $myhostname ESMTP Service Ready
smtpd_helo_required = yes
smtpd_delay_reject = yes
smtpd_error_sleep_time = 1s
smtpd_soft_error_limit = 10
smtpd_hard_error_limit = 20
smtpd_recipient_limit = 16
smtpd_client_message_rate_limit = 30
smtpd_client_connection_count_limit = 100
smtpd_client_connection_rate_limit = 100
smtp_helo_timeout = 60s
soft_bounce = no
disable_vrfy_command = yes
mime_header_checks = regexp:${config_directory}/mime_header_checks.regexp
#SMTPD Restrictions
#########################################################################
# CLIENT
smtpd_client_restrictions =
permit_mynetworks
reject_unknown_client_hostname
reject_unknown_reverse_client_hostname
reject_unauth_pipelining
# HELO
smtpd_helo_restrictions =
permit_mynetworks
check_recipient_access hash:${config_directory}/roleaccount_exceptions
reject_invalid_helo_hostname
reject_unknown_helo_hostname
reject_non_fqdn_helo_hostname
check_helo_access pcre:/etc/postfix/helo_checks
reject_unauth_pipelining
# MAIL FROM:<...>
smtpd_sender_restrictions =
permit_mynetworks
reject_non_fqdn_sender
reject_unknown_sender_domain
reject_unauth_pipelining
# RCPT TO:<...>
smtpd_relay_restrictions =
check_sender_access regexp:${config_directory}/add_x_envelope_from
permit_mynetworks
reject_unauth_destination
reject_unauth_pipelining
smtpd_recipient_restrictions =
reject_unverified_recipient
permit_mynetworks
reject_unauth_pipelining
# DATA
smtpd_data_restrictions =
reject_multi_recipient_bounce
reject_unauth_pipelining
#TLS
#########################################################################
tls_eecdh_strong_curve = prime256v1
tls_eecdh_ultra_curve = secp384r1
tls_random_source = dev:/dev/urandom
tls_preempt_cipherlist = yes
tls_high_cipherlist = kEECDH:kEDH:!3DES:!MD5:!PSK:!SRP:!DSS:!RC4:!aNULL:!eNULL:!SSLv2:!EXPORT:!LOW:@STRENGTH
tls_medium_cipherlist = kEECDH:kEDH:!3DES:!MD5:!PSK:!SRP:!DSS:!RC4:!aNULL:!eNULL:!SSLv2:!EXPORT:!LOW:@STRENGTH
tls_low_cipherlist = kEECDH:kEDH:!3DES:!MD5:!PSK:!SRP:!DSS:!RC4:!aNULL:!eNULL:!SSLv2:!EXPORT:!LOW:@STRENGTH
smtp_tls_mandatory_protocols = !SSLv2 !SSLv3
smtp_tls_protocols = !SSLv2 !SSLv3
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_session_cache_timeout = 3600
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
smtpd_tls_protocols = !SSLv2 !SSLv3
smtpd_tls_security_level = may
smtpd_tls_auth_only = no
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high
smtpd_tls_eecdh_grade = strong
smtpd_tls_dh1024_param_file = /etc/ssl/private/dh2048.pem
smtpd_client_new_tls_session_rate_limit = 60
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtpd_tls_key_file = /etc/ssl/private/selfsigned-cert.key
smtpd_tls_cert_file = /etc/ssl/private/selfsigned-cert.crt
#SASL Authentication
#########################################################################
smtpd_sasl_local_domain =
smtpd_sasl_path = smtpd
smtpd_sasl_auth_enable = no
smtpd_sasl_security_options = noanonymous
smtpd_sasl_authenticated_header = yes
broken_sasl_auth_clients = yes
# Queue
#########################################################################
queue_run_delay = 300s
maximal_queue_lifetime = 5d
bounce_queue_lifetime = 5d
minimal_backoff_time = 300s
maximal_backoff_time = 4000s
qmgr_message_active_limit = 10000
qmgr_message_recipient_limit = 10000
# DEBUG CONFIGURATION
#########################################################################
smtp_tls_loglevel = 1
smtpd_tls_loglevel = 1
debug_peer_level = 2
debugger_command =
PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id & sleep 5
# main.cf
myhostname = relayhost.example.com
mydomain = example.com
[...]
relay_domains = example.com
[...]
# Nur anpassen, wenn Sie ein anderes Zertifikat verwenden!
smtpd_tls_key_file = /etc/ssl/private/selfsigned-cert.key
smtpd_tls_cert_file = /etc/ssl/private/selfsigned-cert.crt
[...]
(Optional) IPv6-Unterstützung einrichten
Wenn Ihr Server, zusätzlich zu IPv4, über einen IPv6-Uplink verfügt (Dual-Stack), spricht nichts dagegen IPv6 auch mit Postfix zu nutzen.
Editieren Sie die Datei /etc/postfix/main.cf und passen Sie die folgenden Parameter an:
# nano /etc/postfix/main.cf
# main.cf
[...]
mynetworks = 127.0.0.0/8, [::1/128]
[...]
inet_protocols = ipv4, ipv6
[...]
Relay-Transport
Geben Sie in dieser Datei die Relay-Empfänger-Domain an, also die Domain, für die der Relayhost E-Mails annehmen soll. Wenn der Relayhost mehrere Domains verwalten soll, können auch weitere Domains nach dem gleichen Syntax angegeben werden.
Der Syntax lautet:
@MAILDOMAIN x
Erstellen Sie die Datei /etc/postfix/relay_recipient_maps nach folgendem Syntax:
# nano /etc/postfix/relay_recipient_maps
@example.com x
Generieren Sie die Relay-Empfänger-Datenbank mit dem Kommando postmap:
# postmap hash:/etc/postfix/relay_recipient_maps
Internen Mail-Server angeben
In dieser Datei geben Sie an, welchem Mail-Server der Relayhost eingehende E-Mails zustellen soll. Wenn der Relayhost mehrere Domains verwalten soll, können auch weitere Domains nach dem gleichen Syntax angegeben werden. Den einzelnen Domains, können auch unterschiedliche Mail-Server zugewiesen werden.
Für den internen Mail-Server kann auch eine IP-Adresse angegeben werden.
Der Syntax lautet:
MAILDOMAIN smtp:[INTERNERMAILSERVER]:PORT x
Erstellen Sie die Datei /etc/postfix/relay_transport nach folgendem Syntax:
# nano /etc/postfix/relay_transport
example.comsmtp:[back-end-mailserver.tld]:25
Generieren Sie die Tranport-Datenbank mit dem Kommando postmap:
# postmap hash:/etc/postfix/relay_transport
Falsche HELO-Hostnamen erkennen
Den entsprechenden Parameter finden Sie in der Datei /etc/postfix/main.cf:
smtpd_helo_restrictions =
[...]
reject_invalid_helo_hostname
reject_unknown_helo_hostname
reject_non_fqdn_helo_hostname
check_helo_access pcre:/etc/postfix/helo_checks
Erstellen Sie eine neue Datei /etc/postfix/helo_checks nach folgendem Syntax:
# nano /etc/postfix/helo_checks
/^mailserver\.example\.com$/ 550 That's not your hostname
/^example\.com$/ 550 That's not your domain
/^192\.0\.2\.42$/ 550 That's not your IP-Address
Pflicht-Empfänger definieren
postmaster
Definiert in RFC 2821 als zentraler Ansprechpartner für E-Mail-bezogene Fragen.
abuse
Definiert in RFC 2142 als zentraler Ansprechpartner für mißbräuchliche Verwendung des Mailservers.
Ebenso wie für einen Mailserver, definiert der RFC 2142 auch zwei Empfänger für den Betrieb eines Webservers. Nachrichten an diese zwei Empfänger sollten nach den gleichen Kriterien angenommen werden, müssen aber nicht.
Falls Sie also einen Webserver betreiben, können Sie die Ausnahme auch für diese Empfänger definieren.
webmaster
Zentraler Ansprechpartner für Fragen zu Ihrer Webseite.
hostmaster
Zentraler Ansprechpartner für Fragen zum DNS-Server bzw. der DNS-Zone.
Den entsprechenden Parameter finden Sie in der Datei /etc/postfix/main.cf:
# main.cf smtpd_helo_restrictions = [...] check_recipient_access hash:${config_directory}/roleaccount_exceptions reject_invalid_helo_hostname reject_unknown_helo_hostname reject_non_fqdn_helo_hostname check_helo_access pcre:/etc/postfix/helo_checks [...]
Erstellen Sie die Datei /etc/postfix/roleaccount_exceptions mit folgendem Inhalt:
# nano /etc/postfix/roleaccount_exceptions
postmaster@ OK
abuse@ OK
hostmaster@ OK
webmaster@ OK
Erstellen Sie die Roleaccount-ExceptionsDatenbank für Postfix:
# postmap hash:/etc/postfix/roleaccount_exceptions
Anonymisierung des E-Mail-Headers
Die Datei /etc/postfix/header_checks enhält Regular Expressions, die von einem Postfix-Cleanup-Job in der Datei /etc/postfix/master.cf ausgewertet werden. Übereinstimmende Einträge werden vor dem E-Mail-Versand aus dem E-Mail-Header entfernt.
# master.cf
[...]
submission inet n - n - - smtpd
[...]
#Hier wird angegeben, dass der Cleanup-Job "submission-header_checks" ausgeführt werden soll
-o cleanup_service_name=submission-header_checks
[...]
#Cleanup-Job "submission-header_checks"
submission-header_checks unix n - n - 0 cleanup
-o header_checks=pcre:${config_directory}/header_checks
[...]
Erstellen Sie die Datei /etc/postfix/header_checks mit folgendem Inhalt:
# nano /etc/postfix/header_checks
## Anonymisierung
# SPAM-Agent
/^X-Spam-Checker-Version:/ IGNORE
/^X-Sanitizer:/ IGNORE
# Mail-Client
/^Received:/ IGNORE
/^User-Agent:/ IGNORE
/^X-Forward:/ IGNORE
/^X-Mailer:/ IGNORE
/^X-MimeOLE:/ IGNORE
/^X-Originating-IP:/ IGNORE
/^X-MSMail-Priority:/ IGNORE
Blockieren gefährlicher Dateinamenerweiterungen
Schickt Ihnen jemand einen hier aufgeführten Anhang, erhält er folgende Hinweismeldung und wird somit über die Nichtzustellung seiner E-Mail informiert.
Attachment type not allowed. File <DATEI> has the unacceptable extension <ERWEITERUNG>
Den entsprechenden Parameter finden Sie in der Datei /etc/postfix/main.cf:
# main.cf
[...]
mime_header_checks = regexp:${config_directory}/mime_header_checks.regexp
[...]
Erstellen Sie die Datei /etc/postfix/mime_header_checks.regexp mit folgendem Inhalt:
# nano /etc/postfix/mime_header_checks.regexp
/^\s*Content-(Disposition|Type).*name\s*=\s*"?(.+\.(lnk|asd|hlp|ocx|reg|bat|dat|c[ho]m|cmd|exe|dll|vxd|pif|scr|hta|jse?|sh[mbs]|vb[esx]|ws[fh]|mov|wmf|xl))"?\s*$/
REJECT Attachment type not allowed. File "$2" has the unacceptable extension "$3"
X-Envelope-From dem Header hinzufügen
X-Envelope-From ist keine Pflichangabe nach RFC 5322. Es handelt sich um eine optionale Angabe, die grundsätzlich zum Mail-Versand nicht erforderlich ist. Dennoch wird diese Information von einigen E-Mail-Clients ausgewertet. Ohne diese Angabe kann es passieren, dass ein E-Mail-Client den Absender nicht korrekt darstellt. Um usereren Relayhost möglichst kompatibel zu betreiben, fügen wir diese Option dem Header hinzu.
Den entsprechenden Paramater finden Sie in der Datei /etc/postfix/main.cf:
# main.cf
[...]
smtpd_relay_restrictions =
[...]
check_sender_access regexp:${config_directory}/add_x_envelope_from
[...]
[...]
Erstellen Sie die Datei /etc/postfix/add_x_envelope_from mit folgendem Inhalt:
# nano /etc/postfix/add_x_envelope_from
/^<>$/ PREPEND X-Envelope-From: <> /^(.*)$/ PREPEND X-Envelope-From: <$1>
Brute-Force-Schutz einrichten
Fail2Ban konfigurieren
fail2ban wertet in Echtzeit entsprechende Log-Dateien des Relayhosts aus und sperrt nach Überschreiten einer festgelegten Schwelle von Falscheingaben, die IP-Adresse des Angreifers für eine festgelegte Zeit und informiert den Administrator über die Sperre per E-Mail (destemail = root@example.com). Diese E-Mail enthält ausführliche Informationen zu der gesperrten IP-Adresse.
maxretry = 5) für 24 Stunden (bantime = 86400 Sekunden) gesperrt.
Erstellen Sie die Datei /etc/fail2ban/jail.local mit folgendem Inhalt:
# nano /etc/fail2ban/jail.local
[DEFAULT]
destemail = root@example.com
sender = fail2ban@example.com
ignoreip = 192.0.2.42
bantime = 86400
maxretry = 5
[postfix]
enabled = true
logpath = /var/log/mail.log
action = %(banaction)s[name=%(__name__)s, bantime="%(bantime)s", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois[name=%(__name__)s, sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]
[postfix-sasl]
enabled = true
logpath = /var/log/mail.log
action = %(banaction)s[name=%(__name__)s, bantime="%(bantime)s", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois[name=%(__name__)s, sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]
[postfix-auth]
enabled = true
port = smtp,465,submission
logpath = /var/log/mail.log
action = %(banaction)s[name=%(__name__)s, bantime="%(bantime)s", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois[name=%(__name__)s, sender="%(sender)s", dest="%(destemail)s", protocol="%(protocol)s", chain="%(chain)s"]
# jail.local
[...]
destemail = root@example.com
sender = fail2ban@example.com
ignoreip = 192.0.2.42
[...]
Erstellen Sie die Datei /etc/fail2ban/filter.d/postfix-auth.conf mit folgendem Inhalt:
# nano /etc/fail2ban/filter.d/postfix-auth.conf
# Fail2Ban filter for Postfix unknown-auth-attemps
#
#
[INCLUDES]
# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf
[Definition]
_daemon = postfix/(submission/)?smtp(d|s)
failregex = lost connection after AUTH from (.*)\[<HOST>\]
ignoreregex =
[Init]
journalmatch = _SYSTEMD_UNIT=postfix.service
# Author: Twilight
Starten Sie den Dienst fail2ban:
# service fail2ban restart
DNS-Zone konfigurieren
Host-A-Eintrag für den Relayhost setzen
Damit der Relayhost aus dem Internet erreichbar ist, muss der Hostname und die zugehörige IP-Adresse veröffentlich werden. Dafür wird auf dem zuständigen DNS-Server ein Host-A-Eintrag gesetzt. Dieser enthält die notwendigen Informationen.
Erstellen Sie auf dem DNS-Server, der für Ihre Mail-Domain zuständig ist, einen Host-A-Eintrag nach folgendem Syntax:
Hostnamehier geben Sie den Namen des Relayhosts an.Typhier geben Sie den Typ des DNS-Eintrags an. In unserem Fall muss es ein Host-A-Eintrag sein.Zielhier geben Sie die öffentliche IP-Adresse des Relayhosts an.
IPv4
Host-A-Eintrag für die Domain example.com
| Hostname | Typ | Ziel |
| relayhost | A | 192.0.2.42 |
IPv6
Host-AAAA-Eintrag für die Domain example.com
| Hostname | Typ | Ziel |
| relayhost | A | 2001:db8:0:8d3:0:8a2e:70:7344 |
MX-Eintrag für den Relayhost setzen
Damit der Mail-Server eines Absenders weiß, welchem Mail-Server er E-Mails für Ihre Domain zustellen soll, muss diese Information veröffentlicht werden. Hierzu wertet der sendende Mail-Server den MX-Eintrag für Ihre DNS-Zone aus und sendet die E-Mail an den, im MX-Eintrag hinterlegten, Mailserver.
Ein MX-Eintrag kann mehrere Mail-Server enthalten. Sollte ein Mail-Server nicht erreichbar sein, wird der sendende Mail-Server die Zustellung, gemäß des MX-Eintrags, auf weitere Mail-Server versuchen. Die Reihenfolge wird über die angegebene Priorität festgelegt. Ein niedriger Wert bedeutet eine höhere Priorität.
Erstellen Sie auf dem DNS-Server, der für Ihre Mail-Domain zuständig ist, einen MX-Eintrag nach folgendem Syntax:
TYPhier geben Sie den Typ des DNS-Eintrags an. In unserem Fall muss es ein MX-Eintrag sein.Prioritäthier geben Sie Priorität an. Ein niedriger Wert bedeutet eine höhere Priorität.Zielhier geben Sie den FQDN des Relayhosts an.
MX-Eintrag für die DNS-Zone example.com
| Typ | Priorität | Ziel |
| MX | 10 | relayhost.example.com |
PTR-Eintrag für den Relayhost setzen
Bei der Spam-Erkennung wird in der Regel geprüft, ob die IP-Adresse des sendenden Mail-Servers über DNS auflösbar ist (Reverse-DNS-Looup) und mit dem angegebenen Namen des sendenden Mail-Servers übereinstimmt.
Ein PTR-Eintrag (Reverse-DNS-Eintrag) ist das Gegenteil eines "normalen" DNS-Eintrags. Im Gegensatz zum "normalen" DNS-Eintrag, mit dem für einen bekannten Hostnamen eine unbekannte IP-Adresse ermittelt wird, wird beim PTR-Eintrag zu einer bekannten IP-Adresse ein unbekannter Hostname ermittelt.
Der PTR-Eintrag wird daher auf dem DNS-Server gesetzt, der für die IP-Adresse Ihres Relayhosts zuständig ist. Das ist normalerweise der Provider, bei dem Sie den Root-Server oder vHost gemietet haben. Den PTR-Eintrag können Sie fast immer eigenständig über die Web-Oberfläche des Providers setzen.
Beispiel IONOS:
Erstellen Sie auf dem DNS-Server, der für die öffentliche IP-Adresse Ihres Relayhosts zuständig ist, einen PTR-Eintrag nach folgendem Syntax:
IP-Adressehier geben Sie die zu verwaltende IP-Adresse an.TYPhier geben Sie den Typ des DNS-Eintrags an. In unserem Fall muss es ein PTR-Eintrag sein.Zielhier geben Sie den FQDN des Relayhosts an.
IPv4
PTR-Eintrag für die öffentliche IP-Adresse 192.0.2.42
| IP-Adresse | Typ | Ziel |
| 192.0.2.42 | PTR | relayhost.example.com |
IPv6
PTR-Eintrag für die öffentliche IP-Adresse 2001:db8:0:8d3:0:8a2e:70:7344
| IP-Adresse | Typ | Ziel |
| 2001:db8:0:8d3:0:8a2e:70:7344 | PTR | relayhost.example.com |
Inbetriebnahme und Test
Führen Sie die Tests nicht auf der Kommandozeile des Relayhosts durch. Der Relayhost verfügt über wesentlich mehr Rechte als ein externer Client. Die Ergebnisse wären nicht repräsentativ.
Verwenden Sie für die Tests einen Client mit gültigem Host-A- und PTR-Eintrag, da ansonsten der Hostname- und der Reverse-DNS-Check fehlschlägt.
Auf der Seite MX-Toolbox können Sie Ihren Relayhost auch online testen lassen. Der Relayhost muss alle Tests bestehen, um als Produktiv-System genutzt werden zu können.
Postfix neustarten
Starten Sie zunächst Postfix neu und kontrollieren Sie, ob der Dienst ohne Fehlermeldungen startet:
# service postfix restart # service postfix status [...] Jan 29 15:17:21 ubuntu-1604-server-amd64-template systemd[1]: Starting LSB: Postfix Mail Transport Agent... Jan 29 15:17:21 ubuntu-1604-server-amd64-template postfix[13975]: * Starting Postfix Mail Transport Agent postfix Jan 29 15:17:21 ubuntu-1604-server-amd64-template postfix[13975]: ...done. Jan 29 15:17:21 ubuntu-1604-server-amd64-template systemd[1]: Started LSB: Postfix Mail Transport Agent. Jan 29 15:17:21 ubuntu-1604-server-amd64-template postfix/master[14041]: daemon started -- version 3.1.0, configuration /etc/postfix
Open-Relay-Test
Ein Open-Relay ist ein Mailserver, der es beliebigen Absendern ermöglicht, E-Mails an beliebige Empfänger zu übermitteln, ohne das hierzu eine Authentifizierung erforderlich ist. Diese Mail-Server werden gerne zum Versand von Spam-Nachrichten verwendet. Oftmals ist es nur ein kleiner Konfigurations-Fehler, der einen Mail-Server zu einem Open-Relay macht. Daher ist dieser Test wichtig und unbedingt durchzuführen!
Prüfen Sie unbedingt, ob der Server sicher arbeitet und kein offenes Relay darstellt, bevor Sie den Relayhost produktiv nutzen.
Stellen Sie eine Telnet-Verbindung zum Relayhost auf Port 25 (SMTP) her und verwenden Sie die rot markierten Kommandos für den Test.
(example.net ist eine gültige Domain und kann daher für den Test verwendet werden)
# telnet relayhost.example.com 25 Trying 192.0.2.42... Connected to relayhost.example.com. Escape character is '^]'. 220 relayhost.example.com ESMTP Postfix EHLO example.net 250-relayhost.example.com 250-PIPELINING 250-SIZE 26214400 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN MAIL FROM:<test@example.net> 250 2.1.0 Ok RCPT TO:<test@example.net> 554 5.7.1 <test@example.net>: Relay access denied
Kontrollieren Sie die letzte Zeile. Wenn Sie die Meldung ...Relay access denied erhalten, ist der Test erfolgreich abgeschlossen.
E-Mail-Empfang testen
Unser Relayhost wartet auf SMTP-Port 25 auf eingehende E-Mails. Die Übertragung von E-Mails kann unverschlüsselt oder mit STARTTLS durchgeführt werden.
Der E-Mail-Empfang kann ganz einfach über die Kommandozeile getestet werden. Alternativ können Sie natürlich auch sofort eine "echte" E-Mail an den Relayhost senden. Bei einer Fehlersuche ist der Test über die Kommandozeile allerdings besser.
Beachten Sie, dass der Relayhost zum E-Mail-Empfang den Back-End-Mailserver erreichen muss. Die Test-E-Mails verbleiben ansonsten in der Mail-Queue (Warteschlange).
Ohne STARTTLS
Stellen Sie eine Telnet-Verbindung zum Relayhost auf Port 25 (SMTP) her und verwenden Sie die rot markierten Kommandos um eine eingehende E-Mail zu versenden.
Senden Sie die E-Mail an eine gültige, zu Ihrer Maildomain gehörenden E-Mail-Adresse (RCPT TO:<GÜLTIGE-E-MAIL-ADRESSE>).
(example.net ist eine gültige Domain und kann daher für den Test verwendet werden)
# telnet relayhost.example.com 25 Trying relayhost.example.com... Connected to relayhost.example.com. Escape character is '^]'. 220 relayhost.example.com ESMTP Postfix EHLO example.net 250-relayhost.example.com 250-PIPELINING 250-SIZE 26214400 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN MAIL FROM:<test@example.net> 250 2.1.0 Ok RCPT TO:<GÜLTIGE-E-MAIL-ADRESSE> 250 2.1.5 Ok DATA 354 End data with <CR><LF>.<CR><LF> Subject: Testmail Test E-Mail-Empfang. . 250 2.0.0 Ok: queued as 1191727019 QUIT 221 2.0.0 Bye Connection closed by foreign host.
Kontrollieren Sie die grün markierte Zeile. Wenn Sie die Meldung 250 2.0.0 Ok: queued as... erhalten und die Test-E-Mail empfangen haben, ist der Test erfolgreich abgeschlossen.
Mit STARTTLS
Stellen Sie eine OpenSSL-Verbindung zum Relayhost auf Port 25 (SMTP) her und verwenden Sie die rot markierten Kommandos um eine eingehende E-Mail zu versenden.
Senden Sie die E-Mail an eine gültige, zu Ihrer Maildomain gehörenden E-Mail-Adresse (rcpt to: GÜLTIGE-E-MAIL-ADRESSE).
(example.net ist eine gültige Domain und kann daher für den Test verwendet werden)
# openssl s_client -starttls smtp -connect relayhost.example.com:25
[...]
Start Time: 1551023261
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
250 DSN
ehlo example.net
250-relayhost.example.com
250-PIPELINING
250-SIZE 26214400
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail from: test@example.net
250 2.1.0 Ok
rcpt to: GÜLTIGE-E-MAIL-ADRESSE
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
Subject: Testmail
Test E-Mail-Empfang mit STARTTLS.
.
250 2.0.0 Ok: queued as EC70C26FD8
quit
221 2.0.0 Bye
closed
Kontrollieren Sie die grün markierte Zeile. Wenn Sie die Meldung 250 2.0.0 Ok: queued as... erhalten und die Test-E-Mail empfangen haben, ist der Test erfolgreich abgeschlossen.
E-Mail-Versand testen
Über den Submission-Port 587 können E-Mails über den Relayhost versendet werden.
Der E-Mail-Versand (Relay-Access) steht ausschliesslich authentifizierten Benutzern zur Verfügung und verlangt STARTTLS.
Auch dieser Test kann ganz einfach über die Kommandozeile durchgeführt werden. Alternativ können Sie natürlich auch sofort eine "echte" E-Mail über Ihren Back-End-Mailserver versenden. Bei einer Fehlersuche ist auch hier der Test über die Kommandozeile besser.
Zunächst muss der Benutzername des Relay-Benutzers und das dazugehörige Kennwort Base64 codiert werden.
Benutzen Sie dazu folgendes Kommando und notieren Sie die Ausgabe:
# echo -n 'relay-benutzer@example.com' | openssl base64 cmVsYXktYmVudXR6ZXJAZXhhbXBsZS5jb20=
# echo -n 'SicheresPasswort' | openssl base64 U2ljaGVyZXNQYXNzd29ydA==
Stellen Sie eine OpenSSL-Verbindung zum Relayhost auf Port 587 (Submission) her und verwenden Sie die rot markierten Kommandos um eine ausgehende E-Mail zu versenden.
Verwenden Sie eine, zu Ihrer Domain gehörenden, Absender-E-Mail-Adresse (mail from: test@example.com)
und senden Sie die E-Mail an eine gültige, externe E-Mail-Adresse (rcpt to: GÜLTIGE-E-MAIL-ADRESSE).
# openssl s_client -starttls smtp -connect relayhost.example.com:587
[...]
Start Time: 1551012088
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
250 DSN
ehlo example.net
250-relayhost.example.com
250-PIPELINING
250-SIZE 26214400
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
auth login
334 VXNlcm5hbWU6
cmVsYXktYmVudXR6ZXJAZXhhbXBsZS5jb20= (base64-Benutzername)
334 UGFzc3dvcmQ6
U2ljaGVyZXNQYXNzd29ydA== (base64-Passwort)
235 2.7.0 Authentication successful
mail from: test@example.com
250 2.1.0 Ok
rcpt to: GÜLTIGE-E-MAIL-ADRESSE
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
Subject: Test
Test E-Mail-Versand.
.
250 2.0.0 Ok: queued as A4D7326FD8
quit
221 2.0.0 Bye
closed
Kontrollieren Sie die grün markierte Zeile. Wenn Sie die Meldung 250 2.0.0 Ok: queued as... erhalten und die Test-E-Mail empfangen haben, ist der Test erfolgreich abgeschlossen.
Abschluss
Wenn der Open-Relay-Test erfolgreich verlief, die versendeten E-Mails ihr Ziel erreicht haben und die Authentifizierung funktioniert, ist Ihr Relayhost einsatzbereit.
Nützliche Befehle
Die folgenden Befehle sollten Ihnen im täglichen Umgang mit Ihrem Relayhost helfen.
Im Gegensatz zu einem anderen, weit verbreiteten, Betriebssystem, lassen sich die Vorgänge auf einem Linux-System hervorragend darstellen. Für eine Fehlerdiagnose empfehle ich daher den Befehl tail -f /var/log/syslog. Damit können Sie die System-Log-Datei in Echtzeit auswerten und schnell feststellen, wo ein Fehler auftritt.
Postfix - Warteschlange anzeigen
Listet den Inhalt der Postfix Warteschlange auf.
# postqueue -p
Postfix - Warteschlange flushen
Versucht den Inhalt der Warteschlange erneut zuzustellen.
# postfix flush
Postfix - Warteschlange löschen
Löscht den Inhalt der Warteschlange.
# postsuper -d ALL