Blog background

Anleitung zur Einrichtung eines sicheren SMTP E-Mail-Relays für Debian und Ubuntu Linux Server mit OpenSMTPD

Ultimativer Leitfaden zur Einrichtung eines OpenSMTPD Mailrelays zum Weiterleiten von E-Mails mit Gmail, Office365, Zoho und anderen auf Debian und Ubuntu Linux Servern

Dieser Blogpost wurde von einer Maschine aus dem Englischen übersetzt. Die Originalversion finden Sie hier: Howto setup a secure SMTP Email Relay for Debian and Ubuntu Linux Servers using OpenSMTPD

Bitte kontaktieren Sie uns , wenn etwas nicht eindeutig beschrieben ist, nicht funktioniert, fehlerhaft wirkt oder wenn Sie Unterstützung benötigen.

Dieses Tutorial beschreibt, wie Sie ein sicheres SMTP Mail-Relay auf Debian oder Ubuntu Servern mit OpenSMTPD anstelle von Postfix einrichten, um E-Mails von (Web-)Anwendungen an E-Mail-Provider wie Google Workspace oder Gmail , Microsoft Outlook oder Office 365 , ZOHO Mail , Amazon Workmail (AWS) und andere weiterzuleiten.

Die Befehle in diesem Blogpost wurden mit Debian 12 und Ubuntu 22.04 getestet und sollten mit allen anderen Debian-basierten Distributionen und allen anderen Linux-Distributionen funktionieren, die ein opensmtpd-Paket bereitstellen. Alle Konfigurationsdateien werden im Detail erklärt. Sie erhalten kopierbare Beispiele, alles was Sie anpassen müssen, sind Ihre Versand-E-Mail-Adressen und SMTP-Zugangsdaten.

Inhaltsverzeichnis

Was ist ein Linux Server Mailrelay?

Ein SMTP Relay, oder Mail Relay, das auf den meisten Linux (Web-)Servern eingerichtet ist, nimmt E-Mails von Ihrer (Web-)Anwendung entgegen, legt sie in eine Warteschlange und leitet sie an große Mail-Provider wie Google Workspace oder Gmail , Microsoft Outlook oder Office 365 , ZOHO Mail , Amazon Workmail (AWS) oder andere weiter, die dann die E-Mail an den tatsächlichen Empfänger zustellen: Ihren Kunden, der ein Passwort-Reset anfordert oder auf eine Buchungsbestätigung wartet.

Wenn E-Mails vom Mailrelay-Programm empfangen werden, werden sie in eine Warteschlange gelegt. Das Mailrelay öffnet dann eine authentifizierte SMTP-Verbindung zum großen Mail-Provider. Dies funktioniert genauso wie das E-Mail-Programm Ihrer Workstation: Es meldet sich bei Ihrem E-Mail-Provider mit einem SMTP-Benutzernamen und Passwort an und sagt ihm “leite diese E-Mail an customer@example.com weiter”.

Wenn es ein Problem gibt, wie wenn Ihr Mail-Provider Ihr Konto durch das Versenden von 50.000 Newslettern auf einmal begrenzt, bleibt die E-Mail in der Warteschlange und die Weiterleitung wird immer wieder versucht. Die Zeit bis zum nächsten Versuch erhöht sich mit jedem Versuch, beginnend von wenigen Sekunden bis zu mehreren Minuten.

Die Vorteile sind, dass E-Mails in der Warteschlange bleiben, wenn es ein Problem gibt. Die Anzahl der E-Mails in der Warteschlange ist normalerweise null und eine Mailwarteschlange, die länger als ein paar Minuten voll ist, würde einen Alarm in Ihrem bevorzugten Überwachungssystem auslösen, um Sie oder das Blunix Hosting Team zu benachrichtigen. Sie müssen Ihre Anwendung nicht so konfigurieren, dass sie mit den vielen Problemen umgeht, die beim Weiterleiten von E-Mails (in großen Mengen) auftreten können, da OpenSMTPD dafür entwickelt wurde, dies zu handhaben.

Schlechter Ansatz: E-Mails direkt in Ihrer Anwendung weiterleiten

Ein häufig gewählter, aber schlechter Ansatz zur Handhabung von E-Mails, die von Webanwendungen generiert werden, besteht darin, die SMTP-Zugangsdaten Ihres E-Mail-Providers direkt in der Konfigurationsdatei Ihrer Webapp einzurichten. Wenn Ihre Webapp eine Buchungsbestätigung oder eine Passwort-Reset-E-Mail generiert und Ihr E-Mail-Provider vorübergehend nicht verfügbar ist oder es ein Netzwerk- oder ein anderes Problem gibt, wird die E-Mail mit einer Fehlermeldung in Ihrem Anwendungsprotokoll verworfen, die Sie möglicherweise nicht bemerken.

Ein weiterer schlechter Ansatz: E-Mails direkt von Ihren Webservern mit SPF-Einträgen senden

Früher war es gängige Praxis, SPF-Einträge für die öffentlichen IP-Adressen Ihrer Webserver einzurichten und E-Mails direkt von Ihren Webservern zu senden. Diese Praxis wird heute DRINGEND abgeraten, da Sie an Tausende verschiedener Mail-Provider zustellen, von denen die meisten unzufrieden sein werden, wenn Sie keine Mail von einem großen Unternehmens-Mailsystem senden. Das direkte Versenden von Mails von Ihren Webservern ohne Weiterleitung über einen großen Provider wie Google oder ähnliche wird ziemlich oft fehlschlagen und ist unserer Meinung nach den Aufwand nicht wert.

Um ein praktisches Beispiel zu nennen: Office365 führt eine Whitelist von Mail-Server-IPs , von denen es E-Mails akzeptiert, und wenn Sie an Office365 zustellen möchten, müssen Sie deren Kontaktformular verwenden, um die IPs Ihrer Webserver auf diese Whitelist zu setzen. Zusammen mit allen anderen Problemen, denen Sie in Produktionsumgebungen begegnen werden, wenn Sie täglich Tausende bis Zehntausende von E-Mails versenden, ist dies Zeitverschwendung und Sie sollten dies an große E-Mail-Provider auslagern.

Möglicherweise schlechter Ansatz: Mails direkt an Ihren Provider über eine API weiterleiten

Einige E-Mail-Provider wie Mailchimp bieten das Versenden von E-Mails über API-Aufrufe an, was bedeutet, dass auf Seiten Ihrer Anwendung überhaupt kein SMTP beteiligt ist. Das ist sehr gut, es sei denn, die API ist ausgefallen. In diesem Fall müssen Sie Ihre Anwendung so konfigurieren, dass sie die Mail selbst in eine Warteschlange legt, bis die API wieder verfügbar ist.

Mailrelays machen Ihnen die Arbeit sehr einfach - Sie geben ihm die Mails, die Sie versenden möchten, und überlassen es Ihrem freundlichen Linux-Administrator , auf Überwachungsalarme zu reagieren, wenn sich die E-Mails in der Warteschlange ansammeln, weil es ein Problem gibt.

Warum OpenSMTPD statt Postfix?

Ich (der Autor) habe etwa 15 Jahre lang Postfix-Systeme administriert und es ist einfach schrecklich nervig, dies zu tun. Postfix hat seinen Namen Post-Fix (später repariert) aus einem Grund erhalten. Es gibt ganze Bücher darüber, wie man es konfiguriert, was für ein einfaches Mailrelay absoluter Overkill ist.

Bei Postfix ist die Aufteilung zwischen main.cf und master.cf äußerst verwirrend, besonders für neue Benutzer oder unsere Kunden. Es ist nicht hilfreich, Software zu entwickeln, die äußerst schwer zu verstehen ist. Große E-Mail-Provider erfordern möglicherweise ein sehr funktionsreiches und etwas komplexes Mailprogramm, für das Postfix in bestimmten Randfällen besser geeignet sein könnte, aber für ein Mailrelay ist es das nicht. Um das ZEN of Python zu zitieren: Einfach ist besser als komplex.

Für ein Mailrelay auf einem Webserver, das nichts anderes tut, als eine E-Mail von einer Webanwendung zu nehmen und sie an einen Mail-Provider wie Google weiterzuleiten, wird die Komplexität von Postfix nur Probleme bringen, wenn Sie versuchen, etwas zu debuggen. Daher ist OpenSMTPD die perfekte Wahl für ein Mailrelay.

OpenSMTPD installieren und konfigurieren

Die Installation von OpenSMTPD für ein Mailrelay auf Debian und Ubuntu erfordert nur ein apt-Paket. Installieren Sie auch das Paket mailutils , das das Kommandozeilen-Tool “mail” bereitstellt, das wir später zum Debuggen und Senden von Test-Mails benötigen werden.

apt install opensmtpd mailutils

Während der Installation des opensmtpd-Pakets wird apt Sie nach dem “mail name” für diesen speziellen Server fragen. Wenn Ihre Webapp unter example.com erreichbar ist, sollten Sie hier example.com eingeben. Wenn Sie 20 Webserver hinter einem Load Balancer haben, jeder mit seinem eigenen lokalen Mailrelay (das ist der richtige Ansatz), dann sollten Sie auf all diesen Webservern example.com als Mail-Namen eingeben.

GEBEN SIE NICHT!!! den tatsächlichen Hostnamen des Servers hier ein! Wenn (und wenn nicht) Sie dem Blunix-Benennungsschema für Server folgen, geben Sie NICHT so etwas wie “exa-www-prod-web-1” oder “web-5.example.com” hier ein. Der Mail-Name wird später in die Header aller E-Mails geschrieben, die Sie weiterleiten. Es gibt keinen Grund, den Endbenutzern (oder einem potenziellen Angreifer) mitzuteilen, wie Sie Ihre Server benennen.

Konfigurieren des Mailnamens

Die nächste Frage ist für die Verwendung von OpenSMTPD als tatsächlicher Mailserver und nicht als Relay gedacht. Sie können sie vorerst leer lassen, da wir Aliase später manuell und detaillierter konfigurieren werden.

Konfigurieren des Empfängers für root- und postmaster-Mails

Vorbereitungen

Standardmäßig erstellt opensmtpd nur eine beispielhafte “/etc/smtpd.conf”. Wir werden die SMTP-Authentifizierungsdaten für Ihre Mail-Konten in einer OpenSMTPD-Tabelle speichern, die unter “/etc/smtpd/tables/” abgelegt wird.

mkdir -p /etc/smtpd/tables

Die relay_secrets SMTP-Authentifizierungsdatei erstellen

Richten Sie als Nächstes die SMTP-Authentifizierungsdaten ein - die Benutzernamen und Passwörter Ihrer E-Mail-Konten. Diese erhalten Sie von Ihrem E-Mail-Provider (Gmail und ähnliche). Dies ist dasselbe, was Sie in Ihrem Thunderbird , Microsoft Outlook oder einem anderen lokalen E-Mail-Client für Workstations einrichten würden.

OpenSMTPD erfordert einen Alias für jede Benutzer:Passwort-Kombination. Wir werden diesen Alias später verwenden, um zuzuordnen, wie E-Mails weitergeleitet werden sollen.

cat << EOF > /etc/smtpd/tables/relay_secrets
# Syntax: alias smtp-username:smtp-password

# SMTP-Konto für Buchungsbestätigungs-E-Mails
webapp_booking booking@example.com:very-secure-password

# SMTP-Konto für Passwort-Reset-E-Mails
webapp_pw_reset password-reset@example.com:super-secure-password

# SMTP-Konto für alle anderen E-Mails
monitoring monitoring@example.com:extremely-secret-password
EOF

chmod 750 /etc/smtpd/
chmod 640 /etc/smtpd/tables/relay_secrets
chown -R root:opensmtpd /etc/smtpd/

/etc/smtpd.conf verstehen

Die folgenden Code-Schnipsel erklären den Inhalt einer beispielhaften /etc/smtpd.conf-Datei. Sie müssen diese Zeilen nicht kopieren und einfügen - es gibt ein vollständiges kopierbares Beispiel weiter unten . Die folgenden Zeilen dienen nur Ihrem Verständnis der Konfigurationsdatei von OpenSMTPD.

Die table relay_secrets Direktive

table relay_secrets file:/etc/smtpd/tables/relay_secrets

OpenSMTPD verwendet Tabellen , die wie kleine Datenbanken in Textdateien sind. Die hier beschriebene Tabelle bezieht sich auf die Datei, die wir oben erstellt haben , die die SMTP-Authentifizierungsdaten für die E-Mail-Adressen enthält, die wir zum Weiterleiten von E-Mails verwenden möchten.

Die listen Direktive

listen on lo \
    port 25 \
    hostname example.com \
    mask-src

Die listen-Direktive deklariert, auf welcher IP und welchem Port OpenSMTPD lauschen soll.

“lo” bezieht sich auf das Loopback-Interface , das nur für die Kommunikation mit dem lokalen Host verfügbar ist:

ip address show lo
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever

Die Konfiguration der listen-Direktive auf diese Weise führt dazu, dass OpenSMTPD nur auf 127.0.0.1:25 lauscht (Port 25 ist der Standard-SMTP-Port), da wir keine eingehenden E-Mails aus der Außenwelt akzeptieren möchten, sondern nur E-Mails von lokalen Anwendungen weiterleiten. Ihre (Web-)Anwendung wird ihre E-Mails an OpenSMTPD auf dieser IP:Port übergeben.

Die listen-hostname-Direktive deklariert den Hostnamen, den OpenSMTPD beim Start des SMTP-Dialogs zurückgeben wird.

Dies kann durch Öffnen einer Telnet-Sitzung zu localhost:25 angezeigt werden:

telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 example.com ESMTP OpenSMTPD     <== HIER

OpenSMTPD wird dies auch in den Header aller E-Mails schreiben, die es verarbeitet. Hier ist ein Beispielausschnitt aus einem E-Mail-Header, den wir mit diesem Typ von Mailrelay senden:

Received: from [127.0.0.1] (localhost [::1])
        by example.com (OpenSMTPD) with ESMTP id e9ad62c1     &lt;== HIER
        for &lt;info@blunix.com&gt;;
        Thu, 7 Mar 2024 05:43:15 +0000 (UTC)

Beachten Sie, dass Sie OpenSMTPD daran hindern können, diese IP-Adresse in den Received-Header zu schreiben, indem Sie die mask-src-Direktive verwenden, die im nächsten Satz beschrieben wird:

Die listen-mask-src-Direktive konfiguriert OpenSMTPD so, dass der “from”-Teil beim Voranstellen von “Received”-Headern weggelassen wird. Der Zweck der Verwendung von mask-src besteht darin, die Privatsphäre und Sicherheit zu verbessern, indem die Quell-IP-Adresse des Clients (Ihrer Webanwendung), der E-Mails über den OpenSMTPD-Server sendet, nicht offengelegt wird. Es ist keine gute Praxis, die interne Netzwerkstruktur preiszugeben.

Hier ist ein Beispiel mit mask-src:

Received:                                      &lt;== NICHTS HIER
        by example.com (OpenSMTPD) with ESMTP
        for ;
        Fri, 8 Mar 2024 13:11:11 +0000 (UTC)

Und ohne mask-src:

Received: from localhost (localhost [::1])     &lt;== CLIENT-HOST-INFORMATIONEN HIER
        by example.com (OpenSMTPD) with ESMTP id a87e4b85
        for ;
        Fri, 8 Mar 2024 13:14:29 +0000 (UTC)

Zusätzlich zum Lauschen auf 127.0.0.1:25 können wir OpenSMTPD so konfigurieren, dass es auf einem UNIX-Socket lauscht “/var/run/smtpd.sock” und dort SMTP-Verbindungen akzeptiert:

listen on socket \
    mask-src

Sie können mehrere listen-Direktiven für alle IPs und Sockets verwenden, die Sie konfigurieren möchten, aber für ein Mailrelay möchten Sie höchstwahrscheinlich nur auf 127.0.0.1 und/oder einem UNIX-Socket lauschen.

Wenn Sie möchten, dass andere Server E-Mails über einen bestimmten SMTP-Relay-Server weiterleiten können, können Sie OpenSMTPD so konfigurieren, dass es auf einer öffentlich erreichbaren Netzwerkschnittstelle lauscht, die üblicherweise etwa eth0 heißt:

listen on eth0 \
    port 25 \
    hostname example.com \
    mask-src

Die Schnittstelle eth0 hat eine öffentliche IP-Adresse:

ip address show eth0
2: eth0:  mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    altname enp1s0
    inet 5.75.164.46/32 brd 5.75.164.46 scope global dynamic eth0     <== HIER
       valid_lft 71144sec preferred_lft 71144sec
    inet6 fe80::9400:3ff:fe13:99ab/64 scope link
       valid_lft forever preferred_lft forever

Die action Direktive

action "relay_monitoring" \
    relay \
    tls \
    host smtp://monitoring@smtp.gmail.com:587 \
    auth &lt;relay_secrets&gt;

Die action-Direktive verwendet die MAIL FROM-Adresse, um zu bestimmen, welche E-Mails an welchen Relay-Server (wie Gmail, Office365, Zoho, …) und wie weitergeleitet werden sollen. Sie definiert zum Beispiel, dass alle E-Mails, die VON booking@example.com gesendet werden, über smtp.gmail.com Port 587 mit erforderlichem TLS unter Verwendung der in der Tabelle “relay_secrets” definierten SMTP-Authentifizierungsdaten weitergeleitet werden.

Die action-relay-Direktive definiert, dass diese Aktion E-Mails an einen anderen Server (wie Gmail) weiterleiten soll.

Die action-tls-Direktive definiert, dass alle Verbindungen ein GÜLTIGES(!) TLS-Zertifikat erfordern. Es ist leider sehr üblich, dass Mailserver-Anbieter ein ungültiges TLS-Zertifikat bereitstellen, das entweder selbst signiert, abgelaufen oder nur für eine andere Domain gültig ist. Diese Direktive wird das nicht akzeptieren, ähnlich wie Ihr Browser keine Verbindung zu einer Website mit einem fehlerhaften TLS-Zertifikat öffnen würde.

Wenn Sie einen kleineren E-Mail-Provider zum Weiterleiten Ihrer E-Mails verwenden und Sie beim Debuggen Ihrer neuen Mailrelay-Einrichtung TLS-Fehler in Ihrer Logdatei erhalten, könnten Sie gezwungen sein, diese Direktive zu entfernen (oder Ihren Mail-Provider zu kontaktieren, um sein Zertifikat zu reparieren - was unserer Erfahrung nach leider nie passiert).

Die action-host-Direktive definiert, an welchen Mailserver E-Mails weitergeleitet werden sollen. Diese ist ein bisschen knifflig:

Beachten Sie die Zeichenfolge in “monitoring@example.com”: Die Zeichenfolge “monitoring” bezieht sich auf den Alias “monitoring” in der “relay_secrets”-Tabelle, die oben beschrieben wurde .

Das bedeutet, dass in diesem Beispiel für die action-Direktive “monitoring@example.com” KEINE E-Mail-Adresse ist! “monitoring” ist der Alias, den wir in “/etc/smtpd/tables/relay_secrets” definiert haben, und “example.com” ist der Mailserver, mit dem wir E-Mails weiterleiten möchten.

Die Syntax für die action-host-Direktive lautet: “protocol://relay_secrets_table_alias@mailserver:port”

Die action-auth-Direktive sagt OpenSMTPD einfach, dass es Authentifizierungsdaten in der “auth_secrets”-Tabelle nachschlagen soll, die oben beschrieben wurde .

Die match Direktive

match \
    from local \
    mail-from "monitoring@example.com" \
    for any \
    action "relay_monitoring"

Die match-Direktive paart die oben definierte Aktion mit bestimmten “MAIL FROM”-Adressen - wenn Sie eine Mail von monitoring@example.com senden, benötigen wir die folgende match-Direktive, um OpenSMTPD mitzuteilen, dass es sie mit der Aktion verknüpfen soll, die wir dafür oben definiert haben.

Aus irgendeinem Grund haben die oben verlinkten OpenSMTPD-Handbuchseiten-Abschnitte zu action-Direktiven-Optionen Anker-Links, während die match-Direktiven keine haben. Bitte beziehen Sie sich auf den match-Direktiven-Handbuch-Abschnitt und scrollen Sie nach unten.

Die match from-local Direktive gibt an, dass die Verbindung nur von localhost stammen kann. Da unsere obige listen-Direktive bereits 127.0.0.1:25 angibt, ist das etwas redundant - es ist auch die Standardeinstellung für alle match-Direktiven, aber explizit ist besser als implizit (zweite Zeile des Zen of Python und generell auch eine gute Idee).

Die match mail-from Direktive gibt an, welche MAIL FROM-Adresse beim Verarbeiten von E-Mails übereinstimmen soll. Sie MÜSSEN die MAIL FROM-Adresse in Ihrer Anwendung definieren, wenn Sie Mails generieren. Sie finden Beispiele, wie Sie dies auf der Kommandozeile / BASH , in PHP , in Python3 und in Golang weiter unten tun können.

Die match for-any Direktive gibt an, dass die Verbindung an jeden Empfänger adressiert werden kann. Dies bedeutet einfach, dass alle möglichen Empfänger-E-Mail-Adressen übereinstimmen (SMTP: RCTP TO).

Die match action Direktive paart diese match-Direktive mit der “relay_monitoring”-Aktion, die wir oben beschrieben haben .

# MAIL FROM ist ein Linux-Benutzerkonto-Name
match from local mail-from "root" for any action "relay_monitoring"
match from local mail-from "www-data" for any action "relay_monitoring"
match from local mail-from "prometheus-alertmanager" for any action "relay_monitoring"

Sie können mehrere match-Direktiven angeben. Blunix bevorzugt eine pro Linux-Benutzer, nur für den Fall, dass einer von ihnen E-Mails generiert. Dies ist häufig bei Cronjobs der Fall, die eine Ausgabe auf stdout oder stderr generieren. Debian verwaltet die von Cronjobs generierte Ausgabe, die dem root-Benutzer gehören, indem es sie in einer E-Mail an den “root”-Benutzer sendet. Daher ist es hilfreich, alle Mails von bestimmten Benutzern über die Monitoring-Adresse weiterzuleiten zu lassen, um diese Ausgabe nicht zu verlieren, falls Cronjobs Probleme haben.

match from any reject

Oder Sie können alle E-Mails mit undefinierten Absenderadressen über ein bestimmtes SMTP-Konto senden:

match from any for any action "relay_monitoring"

Bei Blunix bevorzugen wir es, überhaupt keine E-Mails für Fehlermeldungen von Cronjobs und ähnlichem zu verwenden - wir leiten all diese Nachrichten an Matrix-Chaträume weiter, indem wir dieses Python3-Skript verwenden, das wir mit einer Aktion wie folgt verwenden: “action relay_monitoring relay host smtp://127.0.0.1:12325”. Dies ist im Blunix-Handbuch dokumentiert, würde aber den Rahmen dieses Blogposts sprengen. Wenn Sie Monitoring-E-Mails an Matrix oder einen anderen Chat mit OpenSMTPD weiterleiten möchten, wenden Sie sich bitte an Ihren freundlichen Blunix Linux-Berater für Unterstützung.

Als letzte match-Direktive können Sie einen Catchall definieren, der einfach alle Mails von undefinierten E-Mail-Adressen ablehnt. Wenn eine E-Mail mit einer unbekannten MAIL FROM-Adresse gesendet wird, wird sie abgelehnt:

echo "email-body" | mail --subject="mail-subject" --append="From: unknown@example.com" info@blunix.com
mail: cannot send message: Process exited with a non-zero status

Die Log-Nachricht result=“550 Invalid recipient: <info@blunix.com>”, die diese Aktion generieren wird, ist ein bisschen seltsam - der Empfänger (info@blunix.com) ist natürlich korrekt, der Absender (unknown@example.com) ist es nicht:

journalctl -f _COMM=smtpd
Mär 08 20:48:47 webserver smtpd[88171]: 2cd79d8bacbe2c12 smtp connected address=local host=webserver
Mär 08 20:48:47 webserver smtpd[88171]: 2cd79d8bacbe2c12 smtp failed-command command="RCPT TO:<info@blunix.com> " result="550 Invalid recipient: <info@blunix.com>"
Mär 08 20:48:47 webserver smtpd[88171]: 2cd79d8bacbe2c12 smtp disconnected reason=disconnect

Beachten Sie, dass dies “unautorisierte” Linux-Benutzer nicht daran hindert, E-Mails zu senden oder weiterzuleiten. Jeder Linux-Benutzer auf dem Server, auf dem dieses OpenSMTPD-Mailrelay läuft, mit Zugriff auf 127.0.0.1:25 oder Zugriff auf /var/run/smtpd.sock kann E-Mails senden, indem er einfach den MAIL FROM-Header auf eine Adresse angibt, für die wir eine match-Direktive definiert haben.

/etc/smtpd.conf als kopierbares Beispiel

Hier ist ein kopierbares Beispiel für die /etc/smtpd.conf wie oben beschrieben und erklärt. Stellen Sie sicher, dass Sie es an Ihre Anforderungen anpassen.

cat << "EOF" > /etc/smtpd.conf
table relay_secrets file:/etc/smtpd/tables/relay_secrets

listen on lo port 25 mask-src hostname example.com

listen on socket mask-src

action "relay_monitoring"     relay tls host smtp://monitoring@smtp.gmail.com:587     auth <relay_secrets>
action "relay_booking"        relay tls host smtp://booking@smtp.gmail.com:587        auth <relay_secrets>
action "relay_password_reset" relay tls host smtp://password_reset@smtp.gmail.com:587 auth <relay_secrets>

match from local mail-from "booking@example.com"        for any action "relay_booking"
match from local mail-from "password-reset@example.com" for any action "relay_password_reset"
match from local mail-from "www-data"                   for any action "relay_monitoring"
match from local mail-from "root"                       for any action "relay_monitoring"
match from local mail-from "prometheus-alertmanager"    for any action "relay_monitoring"
match from local mail-from "monitoring@example.com"     for any action "relay_monitoring"

match from any reject
# ODER alle anderen E-Mails über Monitoring weiterleiten (potenziell gefährlich)
#match from any for any action "relay_monitoring"
EOF

Die folgenden Befehle setzen sichere Berechtigungen für die Konfigurationsdatei:

chmod 640 /etc/smtpd.conf
chown root:opensmtpd /etc/smtpd.conf

Starten Sie schließlich den OpenSMTPD-Systemd-Dienst (neu) und aktivieren Sie ihn, um beim Booten zu starten:

systemctl restart opensmtpd.service

systemctl enable opensmtpd.service
Synchronizing state of opensmtpd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable opensmtpd

systemctl status opensmtpd.service
● opensmtpd.service - OpenSMTPD SMTP server
     Loaded: loaded (/lib/systemd/system/opensmtpd.service; enabled; preset: enabled)
     Active: active (running) since Fri 2024-03-08 21:13:29 UTC; 26min ago
       Docs: man:smtpd(8)
    Process: 89525 ExecStart=/usr/sbin/smtpd (code=exited, status=0/SUCCESS)
   Main PID: 89527 (smtpd)
      Tasks: 7 (limit: 2251)
     Memory: 12.9M
        CPU: 187ms
     CGroup: /system.slice/opensmtpd.service
             ├─89527 /usr/sbin/smtpd
             ├─89528 "smtpd: klondike"
             ├─89529 "smtpd: control"
             ├─89530 "smtpd: lookup"
             ├─89531 "smtpd: pony express"
             ├─89532 "smtpd: queue"
             └─89533 "smtpd: scheduler"

Die neue Mailrelay-Installation testen

Zeit zu testen, ob alles funktioniert.

Live-Ansicht der Mail-Logs mit journalctl

Öffnen Sie ein zweites Terminal, um die Logdateien live zu verfolgen, während sie erscheinen:

journalctl -f _COMM=smtpd

Eine Test-Mail mit BASH senden

Lassen Sie uns jetzt eine Test-Mail senden. Fühlen Sie sich frei, Spam an info@blunix.com zu senden ;)

echo "$(whoami)@$(hostname)" | mail --subject=testsubject --append="From: monitoring@example.com" info@blunix.com

Eine Test-Mail mit PHP senden

Um eine Test-Mail mit PHP zu senden, müssen wir PHP installieren:

apt install php

Das folgende einfache PHP-Skript generiert eine Testmail. Beachten Sie, dass wir die Absenderadresse angeben, was wichtig ist, damit OpenSMTPD das zu verwendende SMTP-Konto für die Weiterleitung “matchen” kann!

<?php
$to = 'info@blunix.com';
$subject = 'Test Email';
$message = 'Hello, this is a test email sent from a PHP script.';
$headers = 'From: monitoring@example.com' . "\r\n" .
    'X-Mailer: PHP/' . phpversion();

if(mail($to, $subject, $message, $headers)) {
    echo "Email sent successfully";
} else {
    echo "ERROR sending email!";
}
?>

Eine Test-Mail mit Python3 senden

Das folgende einfache Python3-Skript generiert eine Testmail. Beachten Sie, dass wir die Absenderadresse angeben, was wichtig ist, damit OpenSMTPD das zu verwendende SMTP-Konto für die Weiterleitung “matchen” kann!

#!/usr/bin/env python3

import smtplib
from email.mime.text import MIMEText
from email.header import Header
from email.utils import formataddr

mail_from = 'monitoring@example.com'
rcpt_to = 'info@blunix.com'
subject = 'Test Email'
message = 'Hello, this is a test email sent from a Python3 script.'
smtp_server = 'localhost'
smtp_port = 25

msg = MIMEText(message, 'plain', 'utf-8')
msg['Subject'] = Header(subject, 'utf-8')
msg['From'] = formataddr(('Bot', mail_from))
msg['To'] = rcpt_to

try:
    with smtplib.SMTP(smtp_server, smtp_port) as server:
        server.sendmail(mail_from, [rcpt_to], msg.as_string())
        print("Mail sent successfully!")
except Exception as e:
    print("Mail not sent!")
    print(e)

Eine Test-Mail mit Golang senden

Das folgende einfache Golang-Programm generiert eine Testmail. Beachten Sie, dass wir die Absenderadresse angeben, was wichtig ist, damit OpenSMTPD das zu verwendende SMTP-Konto für die Weiterleitung “matchen” kann!

Um Golang schnell auf Debian oder Ubuntu zu installieren, verwenden Sie die folgenden Befehle. Beziehen Sie sich auf die Golang-Website für die neueste Version.

golang_version="1.22.1"
wget https://go.dev/dl/go${golang_version}.linux-amd64.tar.gz
rm -rf /usr/local/go && tar -C /usr/local -xzf go${golang_version}.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin
grep "go/bin" ~/.bashrc || echo 'export PATH=$PATH:/usr/local/go/bin' >> ~/.bashrc
go version
go version go1.22.1 linux/amd64

Hier ist ein einfaches Go-Programm zum Senden einer Test-E-Mail. Denken Sie daran, immer die Absenderadresse anzugeben:

package main

import (
        "log"
        "net/smtp"
)

func main() {
        from := "monitoring@example.com"
        to := []string{
                "info@blunix.com",
        }
        smtpHost := "localhost"
        smtpPort := "25"

        message := []byte("From: monitoring@example.com\r\n" +
                "To: info@blunix.com\r\n" +
                "Subject: Test Email\r\n" +
                "\r\n" +
                "Hello, this is a test email sent from a Go script.\r\n")

        err := smtp.SendMail(smtpHost+":"+smtpPort, nil, from, to, message)
        if err != nil {
                log.Fatalf("Failed to send email: %v", err)
        }

        log.Println("Mail sent successfully")
}

Lassen Sie uns das Programm erstellen und ausführen:

go build my-golang-testmail-program.go
./my-golang-testmail-program
2024/03/07 05:54:55 Mail sent successfully

Häufige Administrationsbefehle und Debugging

Der Blunix Manual-Abschnitt über das OpenSMTPD-Mailrelay listet häufige Befehle zur Interaktion mit Mails in der Mailwarteschlange auf.

Automatisierte Installation von OpenSMTPD mit Ansible

Blunix verwendet Ansible zur Verwaltung seiner SLA-Hosting-Kunden. Wir bieten eine Open-Source-Ansible-Rolle für ein OpenSMTPD-Mailrelay . Das Git-Repository dieser Rolle wird auf GitHub gespiegelt .