Das Alerting Center in der Securepoint UTM ist eine feine Sache um über etwaige Probleme unterrichtet zu werden. Wir nutzen dieses Feature sehr gerne, sind allerdings bei einem Kunden auf ein Problem gestoßen.

Im Regelfall sollte es so sein, das die UTM an den Unternehmens-eigenen Mailserver (sofern vorhanden) zustellt. So weit, so gut. Bei Kunden gibt es folgende Konstellation in Sachen Mail-Flow:

Securepoint UTM -> MDaemon - > Weiterleitung zu uns

Das Ganze scheint irgendwie (mal wieder) mit Ionos by 1&1 zusammen zu hängen, denn die gleiche Kombi funktioniert mit All-inkl.com ohne Überraschungen. Um es etwas ausführlicher auszudrücken:

Die Securepoint UTM hat als SMTP-Relay oder via SMTP-Route den MDaemon Email Server (oder andere Mailserver) des Kunden konfiguriert. Das macht nicht nur wegen der Alerting Center-Nachrichten Sinn, sondern auch wegen des Spamfilters, wenn Nachrichten aus der Quarantäne zugestellt werden sollen.

Im MDaemon bzw. Mailserver wiederum gibt es einen administrativen Benutzer, der unter anderem Postmaster, etc. ist. Bei diesem ist eine Weiterleitung zu uns eingerichtet. So erhalten wir alle System-relevanten Nachrichten, nicht nur die des Alerting Centers bzw. der UTM.

Kommt jetzt allerdings eine Nachricht vom Alerting Center der UTM schlägt die Weiterleitung fehl. Die Nachricht landet in der Defekt-Warteschlange mit der Erläuterung

undeliverable forwarded message

Um mehr Informationen zu dieser Meldung zu erfahren ist es hilfreich ins “C:\MDaemon\Logs\MDaemon-<Datum>-SMTP-(abg.).log” zu schauen. Zum entsprechenden Zeitpunkt findet man z.B. folgende Einträge:

...
Wed 2020-07-15 02:01:59.775: 01: Sending <c:\mdaemon\queues\remote\pd50000017829.msg> to [212.227.15.183]
Wed 2020-07-15 02:01:59.834: 01: Transfer Complete
Wed 2020-07-15 02:01:59.903: 02: <-- 554-Transaction failed
Wed 2020-07-15 02:01:59.903: 02: <-- 554-Reject due to policy restrictions.
Wed 2020-07-15 02:01:59.903: 02: <-- 554 For explanation visit https://www.ionos.com/help/index.php?id=2425&ip=<Eigene IP-Adresse>&c=hd
Wed 2020-07-15 02:01:59.903: 03: --> QUIT
Wed 2020-07-15 02:01:59.905: 01: Dies ist eine weiter- oder umgeleitete Nachricht; sie wird in die Defekt-Warteschlange verschoben.
Wed 2020-07-15 02:01:59.938: 02: <-- 221 kundenserver.de Service closing transmission channel
Wed 2020-07-15 02:01:59.938: 04: SMTP session terminated (Bytes in/out: 5010/43588)

Ruft man die vorgeschlagene URL von Ionos by 1&1 auf bekommt man zum Fehlercode 554 gleich mehrere mögliche Ursachen. Für die protokollierte Meldung wäre diese hier die passendste Begründung:

554 Reject due to policy restrictions
Problem:

The email was rejected as it violates IONOS policy. The sending server is mostly sending spam messages.

Solution:

Contact us IONOS to have the facts of the case examined.

Kurzum der Spam-Filter des Providers verhindert den Versand. Wahrscheinlich deswegen, da es sich um eine weitergeleitete Nachricht handelt, die als Absender im Header

From: Alerting-Center [firewall.domain.local] <spalertd@firewall.domain.local>

stehen hat. (Leider ist dies in der UTM nicht so ohne weiteres änderbar. <- Siehe Update vom 21.01.2022) Lösen lässt sich in Verbindung mit dem MDaemon Email Server das Problem dadurch, das man die Header-Zeile umschreiben lässt:

• Auf “Einstellungen – Server-Einstellungen – Kopfzeilen-Umsetzung” klicken.
• Im Feld “Bestehender Kopfzeilentext” die ursprüngliche Angabe der UTM eintragen, z.B. “From: Alerting-Center [firewall.domain.local] <spalertd@firewall.domain.local>”
• Im Feld “Neuer Kopfzeilentext” den neuen Absender eintragen, z.B. “From: Administrator <administrator@domain.tld>
  Ergänzung vom 05.11.2024: Bei den beiden vorigen Zeilen reicht mitunter aus, lediglich die E-Mail-Adresse ändern zu lassen. Die komplette “From”-Zeile muss nicht geändert werden.
• Auf “Hinzufügen”, “Übernehmen” und “OK” klicken.

Ab sofort wird in allen Nachrichten, in denen die betreffende Header-Zeile gefunden wird, diese ersetzt.

Was bei anderen Konstellationen womöglich auch hilft (in diesem Fall allerdings nicht) sind die erweiterten Einstellungen zur Weiterleitung:

• Das betreffende Benutzerkonto bearbeiten.
• Zu “Weiterleitung” wechseln.
• Im Abschnitt “Erweiterte Einstellungen zur Weiterleitung” im Feld “Nachrichten an folgende Domäne weiterleiten:” entweder die Zieldomäne eintragen oder wenn es gezielt an einen Server gehen soll, diesen in eckigen Klammern eintragen.
• Im Feld “Adresse für SMTP-Umschlag” die für den Versand zu verwendete E-Mail-Adresse eintragen. An dieser Stelle kann also die etwas ungünstige Altering-Center-Adresse ersetzt werden.
• Ggf. noch den Port eintragen.

Zum Abschluss noch ein Tipp für bereits in der Defekt-Warteschlange hinterlegten Nachrichten:

• Die betreffende Nachricht bearbeiten.
• Die “FROM”-Zeile ändern und speichern.
• Mit der rechten Maustaste auf die “Defekt-Warteschlange” klicken und “Jetzt verarbeiten” auswählen.

Die Nachricht wird zeitnah verarbeitet und im Idealfall, wenn alles passt, auch gleich versendet.

Quelle:

Securepoint – Support-Forum – Smarthost Test ?

MDaemon – Help – Header Translation

Update 01.06.2021

Wird kein eigener Mailserver betrieben und die Alerting Center-Nachrichten sollen direkt an einen Mail-Provider zugestellt und ggf. weitergeleitet werden, droht weiteres Ungemach. Ich hatte diese Situation nun und konnte es dank des oben verlinkten Threads wie folgt lösen:

• Beim Mail-Provider ein Postfach mit dem Namen “spalertd@<domain.tld>” anlegen.
• In diesem Postfach die Weiterleitung zum eigentlichen Ziel (Support, Monitoring, Admin, zu wem auch immer) einstellen.

Alle weiteren Schritte werden auf der UTM ausgeführt:

• Unter “Netzwerk – Servereinstellungen” bei “Globaler E-Mail-Adresse” das zuvor stellte Postfach, gemeint ist dessen E-Mail-Adresse, eingeben.
• Unter “Anwendungen – Mailrelay” auf der Registerkarte “Smarthost” diesen aktivieren und die Daten des Mail-Providers samt des zuvor erstellten Postfachs eintragen.
• Im Web-Interface der UTM die Tasten-Kombi “Strg+Alt+A” drücken.
• Auf “Extras – Templates” klicken.
• Nach “spalert” suchen.
• Die Datei “/etc/spalert/spalert.conf” bearbeiten.
• Die Zeile “GLOBAL:HOSTNAME={{ print @GLOB_HOSTNAME}}” zu “GLOBAL:HOSTNAME=<E-Mail-Domain>” ändern.
• Die Änderung speichern.
• Unter “Anwendungen – Anwendungsstatus” den Dienst “Alerting Center (spalertd)” neu starten.

Diese Änderung setzt die Absender-Domain der E-Mail-Nachrichten. Ab Werk lautet die Adresse “spalertd@<firewallname>”, also z.B. “spalertd@firewall.testlab.local”. Versucht man mit solchen Adressen zu verschicken, bekommt man vom Mail-Provider Meldungen wie diese (und weitere):

(host <mail.server.tld>[<IP>] said: 553 5.7.1 <spalertd@firewall.testlab.local>: Sender address rejected: not owned by user <Mailbox> (in reply to RCPT TO command))

Update 21.01.2022

Mittlerweile ist in der Securepoint UTM eine einfache Möglichkeit hinzugekommen, den Absender-Namen zu ändern:

Im Web-Interface unter “Alerting Center” auf der Registerkarte “Allgemein” kann im Feld “Absender” die Vorgabe “spalertd” geändert werden. Alles nach dem @-Zeichen entspricht dem FQDN der Firewall, der wiederum unter “Netzwerk – Server-Einstellungen” auf der Registerkarte “Servereinstellungen” bei “Firewallname” geändert werden kann.

Update 12.09.2022

Seit Version 12.2.3.1 lässt sich die Absender-E-Mail-Adresse vollständig manuell konfigurieren, die feste Vorgabe mit “@<Firewallname>” entfällt.

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.