Postfix als Relayhost unter Ubuntu einrichten¶

Stand: 03/2025

Verwendete Software - Ubuntu 24.04 LTS - Postfix 3.8.6 - Cyrus SASL 2.1.28 - Fail2Ban 1.0.2
Weitere Dokumentationen: - SPF, DKIM und DMARC in Postfix einrichten - SpamAssassin in Postfix einrichten

Vorwort¶

Diese Dokumentation beschreibt den Installationsvorgang von Postfix als Relayhost.

Es 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.

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:

flowchart LR
    B((Internet)) -->|SMTP| F2B["Fail2Ban
(blockt Angreifer-IPs)"]
    F2B --> SA["SpamAssassin
(filtert E-Mails)"]
    SA --> C["Postfix
(MTA)"]
    C -->|SMTP| D["Back-End-Mailserver
(enthält Nutzdaten)"]

    subgraph "Relayhost (Smarthost)"
        F2B
        SA
        C
    end

    subgraph "Intranet"
        D
    end

Ein Mailserver kann nicht sinnvoll an einem Internet-Anschluss mit dynamischer (wechselnder) IP-Adresse betrieben werden. Die meisten Mailserver lehnen dynamische Adressräume ab bzw. deklarieren sie von vorneherein als Spam.
Ihr interner Mailserver wird durch den Relayhost geschützt. Der interne Mailserver 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 Mailserver 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. 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.

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.

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, 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 Mailserver

Welche technischen Eigenschaften wird der Relayhost haben?¶

Der Relayhost wird eingehende E-Mails für Ihre Domain annehmen und Ihrem internen Mailserver 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 Mailserver mit dem Relayhost verwalten möchten, können die Domains entweder, alle dem gleichen internen Mailserver zugestellt werden, oder es kann pro Domain ein separater interner Mailserver 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. Mailserver sind regelmässig Opfer von Brute-Force-Attacken. Durch unzählige Eingaben von Kombinationen aus Benutzernamen und Passwörtern wird versucht, den Relayhost bzw. Mailserver 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 Mailserver
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/letsencrypt/live/relayhost.example.com/fullchain.pem	Ersetzen Sie diesen Wert durch den Pfad und den Namen Ihres SSL-Zertifikats.
SSL-Zertifikat Private Key	/etc/letsencrypt/live/relayhost.example.com/privkey.pem	Ersetzen Sie diesen Wert durch den Pfad und den Namen des private Keys Ihres Zertifikats.
Root-E-Mail-Adresse	[email protected]	Ersetzen Sie diesen Wert durch die E-Mail-Adresse desjenigen, der E-Mails für Root erhalten soll.
Fail2ban-E-Mail-Adresse (Absender)	[email protected]	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

beispiel.conf

content = Dokumentationen

domain  = example.com
owner   = root

Anzupassende Parameter:

[...]
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

beispiel.map

[email protected]
[email protected]

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 relayhost
cat /etc/hostname > /etc/mailname

Editieren Sie die Datei /etc/hosts und ändern Sie den Hostnamen nach folgendem Syntax:

nano /etc/hosts

/etc/hosts

127.0.1.1       relayhost.example.com relayhost
[...]

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 Mailserver die TLS-Verschlüsselung. Mailservern, 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.

Let's Encrypt-Zertifikat erstellen¶

Info

Um den Relayhost mit STARTTLS zu verwenden, wird ein gültiges SSL-Zertifikat benötigt. Dieses kann entweder bei einer offiziellen Zertifizierungsstelle gekauft oder kostenlos über Let's Encrypt bezogen werden.

Für die reine Transportverschlüsselung STARTTLS sind kostenlos ausgestellte Zertifikate von Let's Encrypt und kostenpflichtige Zertifikate technisch gleichwertig, solange sie von einer vertrauenswürdigen CA stammen und gültig sind. Die meisten modernen Mailserver akzeptieren beide Varianten problemlos.

Wenn keine besonderen Anforderungen bestehen (z. B. erweiterte Validierung oder längere Laufzeit ohne Erneuerung), empfiehlt sich die Verwendung eines kostenlosen Let's-Encrypt-Zertifikats. Diese lassen sich automatisiert verwalten und decken in der Praxis alle gängigen Anforderungen ab.

Installieren Sie zunächst snapd und certbot:

apt update
apt install snapd
snap install core
snap refresh core
snap install --classic certbot
ln -s /snap/bin/certbot /usr/bin/certbot

Erstellen Sie das Zertifkat. Geben Sie als Common Name den FQDN des Relayhosts an. Das Zertifkat befindet sich unter /etc/letsencrypt/live/relayhost.example.com/.

sudo certbot certonly --standalone -d relayhost.example.com

Let's Encrypt-Zertifikate haben eine Gültigkeit von 30 Tagen. Danach werden sie automatisch erneuert. Damit postfix erneuerte Zertifikate verwendet, müssen diese nachgeladen werden. Erstellen Sie hierzu einen Deploy-Hook:

nano /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh

reload-services.sh

#!/bin/bash
services=(
    postfix
)

for service in "${services[@]}"; do
    if systemctl is-active --quiet "$service"; then
        echo "[Certbot-Hook] Reloading $service"
        systemctl reload "$service"
    else
        echo "[Certbot-Hook] $service is not active"
    fi
done

Vergeben Sie die benötigte Berechtigung, damit die Datei ausgeführt werden kann:

chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-services.sh

Diffie-Hellman-Parameter erstellen¶

Info

Der Diffie-Hellman-Schlüsselaustausch gehört zu den asymmetrischen Kryptoverfahren und basiert auf der diskreten Exponentialfunktion. Dafür sind zwei Parameter notwendig:
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 anschließend 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 stellen wir die DH-Parameter formal für die TLS-Verschlüsselung via STARTTLS in Postfix bereit.

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
[...]

Hinweis!

In TLS 1.2 und 1.3 ist die Verwendung klassischer DH-Parameter technisch nicht mehr notwendig. TLS 1.3 ignoriert sie vollständig, und TLS 1.2 verwendet sie nur, wenn DHE-Cipher aktiv verhandelt werden. Der Parameter wird in dieser Konfiguration lediglich aus Kompatibilitätsgründen mit potenziell veralteten Gegenstellen eingebunden. Bei Einsatz moderner Cipher Suites (z.B. ECDHE) kommt er nicht zum Tragen. Eine regelmäßige Neuerzeugung ist nicht erforderlich, sofern ein starker Parameter (z. B. 4096 Bit) einmalig erzeugt wurde.

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

SASL Authentifizierung einrichten¶

Info

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
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¶

Info

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 [email protected]. 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¶

Info

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-daemon mit dem Dienst submission. Das ist unser Dienst zum authentifizierten Versenden von E-Mails zu entfernten Mailservern (relaying). cleanup-daemon mit dem Dienst submission-header_checks zur 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

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¶

Info

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 großer 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 welchen Kriterien eine E-Mail anzunehmen oder abzulehnen 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 an. Klassischer Diffie-Hellman-Schlüsselaustausch wird ausschließlich zur Abwärtskompatibilität mit älteren Mailservern unterstützt. 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

main.cf

#########################################################################

myhostname                              = relayhost.example.com
mydomain                                = example.com
myorigin                                = $mydomain
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                     = 3.6

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                     = EECDH+AESGCM:EDH+AESGCM:EECDH+AES:EDH+AES
tls_medium_cipherlist                   = EECDH+AESGCM:EDH+AESGCM:EECDH+AES:EDH+AES
tls_low_cipherlist                      = EECDH+AESGCM:EDH+AESGCM:EECDH+AES:EDH+AES

smtp_tls_mandatory_protocols            = >=TLSv1.2
smtp_tls_protocols                      = >=TLSv1.2
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           = >=TLSv1.2
smtpd_tls_protocols                     = >=TLSv1.2
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/dh4096.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/letsencrypt/live/relayhost.example.com/privkey.pem
smtpd_tls_cert_file                     = /etc/letsencrypt/live/relayhost.example.com/fullchain.pem


#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

Anzupassende Parameter:

myhostname          = relayhost.example.com
mydomain            = example.com
[...]
relay_domains       = example.com
[...]
# Nur anpassen, wenn Sie ein anderes Zertifikat verwenden!
smtpd_tls_key_file      = /etc/letsencrypt/live/relayhost.example.com/privkey.pem
smtpd_tls_cert_file     = /etc/letsencrypt/live/relayhost.example.com/fullchain.pem
[...]

(Optional) IPv6-Unterstützung einrichten¶

Info

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

Anzupassende Parameter:

[...]
mynetworks          = 127.0.0.0/8, [::1/128]
[...]
inet_protocols      = ipv4, ipv6
[...]

Relay-Transport¶

Info

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 Mailserver angeben¶

Info

In dieser Datei geben Sie an, welchem Mailserver 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 Mailserver zugewiesen werden.
Für den internen Mailserver 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.com smtp:[back-end-mailserver.tld]:25

Generieren Sie die Tranport-Datenbank mit dem Kommando postmap:

postmap hash:/etc/postfix/relay_transport

Falsche HELO-Hostnamen erkennen¶

Info

Um zu verhindern, dass Spam-Versender den Hostnamen Ihres Relayhosts als ihren eigenen Hostnamen verwenden, erstellen wir eine Regel, die mittels Regular-Expressions den eigenen Hostnamen bzw. die eigene IP-Adresse in einer ''HELO-Angabe'' erkennt.
Den entsprechenden Parameter finden Sie in der Datei /etc/postfix/main.cf:

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

helo_checks

/^example\.com$/                    550 That's not your domain
/^192\.0\.2\.42$/                   550 That's not your IP-Address

Anzupassende Parameter:

[...]
/^192\.0\.2\.42$/                   550 That's not your IP-Address
[...]

Pflicht-Empfänger definieren¶

Info

Für den Betrieb eines RFC-konformen Mailservers muss sichergestellt sein, dass zwei Empfänger als administrative Anlaufstellen immer erreichbar sein müssen. Die Qualität der Nachricht darf dabei keine Rolle spielen. Die Nachrichten müssen demnach angenommen werden, bevor diese durch einen evtl. falschen oder ungültigen HELO Hostnamen abgelehnt würden. Hierfür muss eine Ausnahme für diese zwei Empfänger definiert werden.

postmaster Definiert in RFC 2821 als zentraler Ansprechpartner für E-Mail-bezogene Fragen.
abuse Definiert in RFC 2142 als zentraler Ansprechpartner für missbrä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

abuse@ OK hostmaster@ OK webmaster@ OK

<br>
Erstellen Sie die Roleaccount-ExceptionsDatenbank für Postfix:
```bash
postmap hash:/etc/postfix/roleaccount_exceptions

Anonymisierung des E-Mail-Headers¶

Info

Im Header einer E-Mail stehen viele Informationen, die unter anderem Angaben enthalten, die einem möglichen Angreifer in die Karten spielen. Diese Informationen können z.B. die IP-Adresse Ihres internen Mailservers, die IP-Adresse und die Version des verwendeten E-Mails-Clients, usw. sein. Unser Relayhost soll nur die Informationen preisgeben, die zum eigentlichen Mail-Versand benötigt werden.

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

header_checks

# 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¶

Info

E-Mails können bekanntlich potenziell gefährliche Anhänge transportieren. Unser Relayhost soll E-Mails, die einen Anhang mit einer potenziell gefährlichen Dateinamenerweiterung enthalten, ablehnen, bevor dieser Anhang unser internes Netzwerk erreicht. Hierzu wertet Postfix den Mime-Header einer eingehenden E-Mails aus und vergleicht diesen mit der, hier verwendeten, Regular Expression. Es wird nur der Dateinname ausgewertet und es erfolgt keine Inhaltsprüfung. Diese Option ersetzt also keinen Virenschutz!
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

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¶

Info

Die Header-Information 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

add_x_envelope_from

/^<>$/ PREPEND X-Envelope-From: <>
/^(.*)$/  PREPEND X-Envelope-From: <$1>

Brute-Force-Schutz einrichten¶

Fail2Ban konfigurieren¶

Info

Der Dienst 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 = [email protected]). Diese E-Mail enthält ausführliche Informationen zu der gesperrten IP-Adresse.
In diesem Beispiel wird die IP-Adresse eines Angreifers nach 5-maliger Falscheingabe (maxretry = 5) für 24 Stunden (bantime = 24h Sekunden) gesperrt.

Erstellen Sie die Datei /etc/fail2ban/jail.local mit folgendem Inhalt:

nano /etc/fail2ban/jail.local

jail.local

destemail   = [email protected]
sender      = [email protected]

ignoreip    = 192.0.2.42

bantime     = 24h
maxretry    = 5

[postfix]
enabled     = true
mode        = aggressive
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"]

Anzupassende Parameter:

[...]
destemail   = [email protected]
sender      = [email protected]

ignoreip    = 192.0.2.42
[...]

Starten Sie den Dienst fail2ban:

service fail2ban restart

DNS-Zone konfigurieren¶

Host-A-Eintrag für den Relayhost setzen¶

Info

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:

Hostname hier geben Sie den Namen des Relayhosts an.
Typ hier geben Sie den Typ des DNS-Eintrags an. In unserem Fall muss es ein Host-A-Eintrag sein.
Ziel hier 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	AAAA	2001:db8:0:8d3:0:8a2e:70:7344

MX-Eintrag für den Relayhost setzen¶

Info

Damit der Mailserver eines Absenders weiß, welchem Mailserver er E-Mails für Ihre Domain zustellen soll, muss diese Information veröffentlicht werden. Hierzu wertet der sendende Mailserver 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 Mailserver enthalten. Sollte ein Mailserver nicht erreichbar sein, wird der sendende Mailserver die Zustellung, gemäß des MX-Eintrags, auf weitere Mailserver 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:

TYP hier geben Sie den Typ des DNS-Eintrags an. In unserem Fall muss es ein MX-Eintrag sein.
Priorität hier geben Sie Priorität an. Ein niedriger Wert bedeutet eine höhere Priorität.
Ziel hier 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¶

Info

Bei der Spam-Erkennung wird in der Regel geprüft, ob die IP-Adresse des sendenden Mailservers über DNS auflösbar ist (Reverse-DNS-Looup) und mit dem angegebenen Namen des sendenden Mailservers ü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-Adresse hier geben Sie die zu verwaltende IP-Adresse an.
TYP hier geben Sie den Typ des DNS-Eintrags an. In unserem Fall muss es ein PTR-Eintrag sein.
Ziel hier 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¶

Achtung!

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¶

Achtung!

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 Mailserver werden gerne zum Versand von Spam-Nachrichten verwendet. Oftmals ist es nur ein kleiner Konfigurations-Fehler, der einen Mailserver 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 folgenden 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:<[email protected]>
250 2.1.0 Ok
RCPT TO:<[email protected]>
554 5.7.1 <[email protected]>: 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¶

Info

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 folgenden 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:<[email protected]>
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.

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 folgenden 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: [email protected]
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

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¶

Info

Ü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 '[email protected]' | 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 folgenden Kommandos um eine ausgehende E-Mail zu versenden.
Verwenden Sie eine, zu Ihrer Domain gehörenden, Absender-E-Mail-Adresse (mail from: [email protected])
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: [email protected]
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.
.
<span style="color:green;">250 2.0.0 Ok: queued as A4D7326FD8
quit
221 2.0.0 Bye
closed

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