MDaemon: Konto-Weiterleitung über Smarthost schlägt fehl

MDaemon: Konto-Weiterleitung über Smarthost schlägt fehl mit „554 Unauthorized sender address" (1&1/IONOS, GMX, web.de)

1. Symptom

Ein MDaemon-Benutzerkonto hat die Weiterleitung von Nachrichten aktiviert (Benutzerkonten-Editor → Weiterleitung). Der Versand erfolgt über einen Smarthost eines Providers, der zur United-Internet-Gruppe gehört bzw. auf der Nemesis-Plattform basiert (1&1/IONOS smtp.1und1.de, GMX mail.gmx.net, web.de smtp.web.de).

Verhalten:

  • Direkt vom Konto versendete Nachrichten werden problemlos zugestellt.
  • Weitergeleitete Nachrichten von externen Absendern werden vom Smarthost abgelehnt und landen in der Defekt-Warteschlange (Bad Queue).
Typischer Log-Auszug (SMTP-Ausgang):
  1. <-- 235 Authentication succeeded
  2. --> MAIL From:<konto@kundendomain.de> SIZE=12199
  3. <-- 250 Requested mail action okay, completed
  4. --> RCPT To:<empfaenger@extern.de>
  5. <-- 250 OK
  6. --> DATA
  7. <-- 354 Start mail input; end with <CRLF>.<CRLF>
  8. Transfer Complete
  9. <-- 554-Transaction failed
  10. <-- 554-Unauthorized sender address.
  11. Dies ist eine weiter- oder umgeleitete Nachricht; sie wird in die Defekt-Warteschlange verschoben.
Wichtige Merkmale zur Abgrenzung:
  1. 235 Authentication succeeded
Die SMTP-Anmeldung ist nicht das Problem. Zugangsdaten sind korrekt.
  1. 554 erst nach DATA
Der Provider prüft den Nachrichteninhalt, nicht den Envelope.
  1. 550 Sender address is not allowed bereits bei MAIL FROM
Anderes Problem: Der Envelope-Absender ist für das Smarthost-Konto nicht zugelassen (siehe Abschnitt 7).

2. Ursache

Die Nemesis-Plattform (1&1/IONOS, GMX, web.de) validiert beim authentifizierten Versand nicht nur den SMTP-Envelope (MAIL FROM), sondern auch den From:-Header innerhalb der Nachricht gegen das authentifizierte Postfach und dessen zugelassene Absenderadressen.

Bei der MDaemon-Konto-Weiterleitung wird der Envelope korrekt auf das weiterleitende Konto umgeschrieben (Feld „Inhalt für SMTP-Befehl MAIL"), der ursprüngliche From:-Header der Nachricht bleibt jedoch erhalten – das ist bei klassischem Forwarding beabsichtigt. Der Provider erkennt den Mismatch zwischen authentifiziertem Konto und From-Header und lehnt mit 554 Unauthorized sender address ab.

Dies ist kein MDaemon-Fehler, sondern eine bewusste Anti-Spoofing-Richtlinie des Providers. Sie lässt sich serverseitig beim Kunden nicht umgehen. Der From-Header muss vor der Übergabe an den Smarthost auf eine zugelassene Adresse umgeschrieben werden.

Ein zusätzlicher Sender:-Header (RFC 5322 „im Auftrag von") wird von der Nemesis-Plattform ignoriert und löst das Problem nicht (in der ELOVADE-Testumgebung verifiziert, Juli 2026).

3. Lösungsübersicht

Die Lösung besteht aus drei Bausteinen, die alle erforderlich sind:

  1. Serveroption aktivieren: „Weitergeleitete Nachrichten durchlaufen Inhalts- und Spamfilter" – standardmäßig deaktiviert. Ohne diese Option verarbeitet der Inhaltsfilter Weiterleitungskopien grundsätzlich nicht (Log: „Forwarded message detected; further processing skipped").
  2. Zwei Inhaltsfilter-Regeln (vom Hersteller MDaemon Technologies bereitgestellt):
    • Regel 1 setzt den ursprünglichen Absender dynamisch als Reply-To → Antworten des Empfängers erreichen den ursprünglichen Absender.
    • Regel 2 schreibt den From:-Header auf die Adresse des weiterleitenden Kontos um und erhält die ursprüngliche Absenderadresse sichtbar im Anzeigenamen.
  3. Neustart des MDaemon-Dienstes – die Option aus Schritt 1 wird erst nach einem Dienstneustart wirksam.

Ergebnis beim Empfänger (Beispiel):

  1. Von:        "ACTUAL: (original.absender@extern.de)" <konto@kundendomain.de>
  2. Antwort an: original.absender@extern.de
Die Zustellung funktioniert, die ursprüngliche Absenderadresse bleibt sichtbar, und „Antworten" adressiert automatisch den ursprünglichen Absender. Die Lösung arbeitet dynamisch für beliebige Absender; es ist keine Pflege pro Absenderadresse erforderlich.

4. Einrichtung Schritt für Schritt

Schritt 0 – Ausgangszustand prüfen

Vor der Einrichtung sicherstellen, dass keine Altlasten die Verarbeitung stören:

  • Keine konkurrierenden Einträge unter Einstellungen → Server-Einstellungen → Kopfzeilen-Umsetzung (diese greift bereits beim Erzeugen der Weiterleitungskopie und damit vor dem Inhaltsfilter – sie kann das Ergebnis der Regeln verfälschen).
  • Keine älteren Test-Regeln im Inhaltsfilter, die auf dieselben Nachrichten wirken.
  • Keine zusätzlichen Benutzer-Filter (IMAP-Filter) am Konto, die dieselben Nachrichten parallel weiterleiten oder umleiten (Gefahr doppelter Zustellung).
  • Die Konto-Weiterleitung selbst muss korrekt konfiguriert sein: Zieladresse gesetzt, AUTH-Daten des Smarthost-Postfachs hinterlegt (oder globale Smarthost-AUTH aktiv) und „Inhalt für SMTP-Befehl MAIL" = Adresse des beim Smarthost authentifizierten Postfachs. Ohne korrektes Envelope-Rewriting scheitert der Versand bereits bei MAIL FROM mit 550 (siehe Abschnitt 7).


Schritt 1 – Option aktivieren

Einstellungen → Voreinstellungen → Verschiedenes → „Weitergeleitete Nachrichten durchlaufen Inhalts- und Spamfilter" aktivieren.

Hintergrund: Der Inhaltsfilter markiert verarbeitete Nachrichten über den Dateinamen (Präfix wechselt von md auf pd), damit jede Nachricht nur einmal gefiltert wird. Weiterleitungskopien werden ohne diese Option direkt als bereits verarbeitet erzeugt und vom Inhaltsfilter übersprungen. Im Inhaltsfilter-Protokoll erscheint dann pro Weiterleitungskopie die Zeile:

  1. * Forwarded message detected; further processing skipped

Solange diese Zeile erscheint, ist die Option nicht wirksam (nicht gesetzt oder Neustart fehlt).

Nebenwirkung beachten: Die Option gilt global – weitergeleitete Nachrichten durchlaufen dann auch den Spamfilter. In der Regel unkritisch, sollte aber bekannt sein.


Schritt 2 – Inhaltsfilter-Regeln anlegen

Die Regeln können über die GUI (Sicherheit → Inhaltsfilter → Neue Regel) oder direkt in der Regeldatei C:\MDaemon\App\CFRules.dat angelegt werden. Für die Einrichtung beim Kunden hat sich der Weg über die Datei bewährt (weniger Klickfehler, exakte Übernahme der Syntax).

Vorgehen über CFRules.dat:

  1. Sicherungskopie von C:\MDaemon\App\CFRules.dat erstellen.
  2. Datei in einem Texteditor öffnen (empfohlen: Notepad++).
  3. Am Dateiende die Nummer der letzten vorhandenen Regel ermitteln (z. B. [Rule033]). Die neuen Regeln erhalten die nächsten freien Nummern (im Beispiel [Rule034] und [Rule035]).
    • Regelnummern müssen eindeutig sein – niemals eine vorhandene Nummer doppelt vergeben.
    • Reihenfolge zwingend beachten: Die Reply-To-Regel muss vor der From-Regel stehen, da sie den noch unveränderten ursprünglichen From-Header übernimmt. Steht sie dahinter, übernimmt sie die bereits umgeschriebene Adresse und der Reply-To-Mechanismus ist wirkungslos.
  4. Regelblöcke exakt anhängen (siehe Varianten unten), Nummern anpassen, speichern.
  5. MDaemon-Dienst neu starten (Schritt 3).

Die Blöcke müssen zeichengenau übernommen werden – insbesondere die Anführungszeichen in der Action-Zeile (dort kommen verschachtelte Anführungszeichen vor, die korrekt sind und nicht „bereinigt" werden dürfen). Beim Kopieren aus E-Mail-Programmen auf typografische Anführungszeichen achten; im Zweifel Blöcke als .txt-Anhang übermitteln.

Variante A – Hersteller-Original (dynamisch, empfohlen)

Quelle: MDaemon Technologies, Distributor-Support (Jared Charles), Juli 2026.

  1. [Rule034]
  2. RuleName=Forwarding - Part 1: Reply-To
  3. Enable=Yes
  4. ThisRuleCondition=All
  5. ProcessQueue=REMOTE
  6. Condition01=Reply-To|does not exist|AND|
  7. Condition02=X-MDRedirect|exists|AND|
  8. Action01=add header|"Reply-To","$HEADER:From$"

  10. [Rule035]
  11. RuleName=Forwarding - Part 2: From
  12. Enable=Yes
  13. ThisRuleCondition=All
  14. ProcessQueue=REMOTE
  15. Condition01=X-MDRedirect|exists|AND|
  16. Action01=header search and replace|"From",".*<([^>]+)>.*",""ACTUAL: ($1)" <$HEADER:X-MDRedirect_From$>","0,1"

Funktionsweise:

  • MDaemon setzt bei Konto-Weiterleitungen intern die Header X-MDRedirect: 1 und X-MDRedirect_From: <adresse-des-weiterleitenden-kontos>. Beide Regeln nutzen X-MDRedirect als Erkennungsmerkmal, wirken also ausschließlich auf Weiterleitungskopien (Queue: REMOTE).
  • Regel 1 (Reply-To): Feuert nur, wenn noch kein Reply-To existiert (vorhandene Reply-To-Header der Originalnachricht werden respektiert). Das Makro $HEADER:From$ übernimmt den ursprünglichen From-Header dynamisch – funktioniert für beliebige Absender.
  • Regel 2 (From): Der reguläre Ausdruck .*<([^>]+)>.* extrahiert die Adresse aus dem From-Header. Das Replacement baut den neuen From-Header: ursprüngliche Adresse im Anzeigenamen als ACTUAL: (…), als tatsächliche Absenderadresse das Makro $HEADER:X-MDRedirect_From$ = Adresse des weiterleitenden Kontos.

Variante B – Feste Absenderadresse (Fallback / Sonderfälle)

  1. [Rule035]
  2. RuleName=Forwarding - Part 2: From
  3. Enable=Yes
  4. ThisRuleCondition=All
  5. ProcessQueue=REMOTE
  6. Condition01=X-MDRedirect|exists|AND|
  7. Action01=header search and replace|"From",".*<([^>]+)>.*",""ACTUAL: ($1)" <POSTFACH@SMARTHOST-PROVIDER.TLD>","0,1"
POSTFACH@SMARTHOST-PROVIDER.TLD durch die Adresse ersetzen, mit der sich der Server beim Smarthost authentifiziert. Regel 1 (Reply-To) bleibt identisch zu Variante A.

Unterschiede der Varianten und Auswahlkriterien

Variante A (Makro)Variante B (feste Adresse)
Eingesetzte From-Adresse$HEADER:X-MDRedirect_From$ = Adresse des weiterleitenden Kontos (dynamisch pro Konto)Fest eingetragene Adresse
Funktioniert für mehrere weiterleitende Konten gleichzeitigJaNein (eine feste Adresse für alle)
VoraussetzungDie Adresse des weiterleitenden Kontos muss beim Smarthost als Absender zugelassen sein (Standardfall: Weiterleitungskonto = beim Provider gehostetes/authentifiziertes Postfach)Keine – es wird direkt die zugelassene Smarthost-Adresse eingetragen
Typischer EinsatzKundenumgebungen (Regelfall): Konto-Adresse ist identisch mit dem beim Provider authentifizierten PostfachTestumgebungen oder Konstellationen, in denen die lokale Konto-Adresse dem Smarthost-Provider unbekannt ist (z. B. lokale Domäne ≠ Provider-Postfach); außerdem als Fallback, falls Variante A wider Erwarten weiterhin 554 liefert

Hintergrund aus der Fallhistorie: In der ELOVADE-Testumgebung (lokale Domäne mdaemon-schulung.de, Smarthost GMX) ist die Konto-Adresse für das GMX-Postfach kein zugelassener Absender – dort war Variante B für den Zustellnachweis erforderlich. Beim Kunden (Konto = IONOS-Postfach) greift Variante A unverändert.

Es darf immer nur eine der beiden „Part 2"-Varianten aktiv sein.

Schritt 3 – MDaemon-Dienst neu starten

Neustart über die Windows-Diensteverwaltung (services.msc → Dienst „MDaemon" → Neu starten).

Der Neustart ist zwingend erforderlich: Er lädt sowohl die direkt in CFRules.dat eingetragenen Regeln als auch die Option aus Schritt 1. In den Verifikationstests wurde die Option ohne Neustart nicht wirksam (Skip-Zeile erschien weiterhin im Inhaltsfilter-Log).

Kontrolle nach dem Neustart: Unter Sicherheit → Inhaltsfilter müssen beide Regeln in der Liste erscheinen und aktiviert sein.

Schritt 4 – Funktionstest

  1. Von einer externen Absenderadresse eine Testnachricht an das weiterleitende Konto senden.
  2. Inhaltsfilter-Protokoll prüfen – erwartetes Bild für die Weiterleitungskopie (Remote-Queue):
  1. * Message matched rule: "Forwarding - Part 1: Reply-To"
  2. *    Action: Header added to message
  3. * Message matched rule: "Forwarding - Part 2: From"
  4. *    Action: Searched for and replaced text in message header (if found)
  • SMTP-Ausgangsprotokoll prüfen: Session muss nach DATA mit 250 Requested mail action okay enden.
  • Beim Empfänger prüfen: Absenderdarstellung "ACTUAL: (original@extern.de)" <konto@kundendomain.de>, Antwort-an = ursprünglicher Absender. Auf „Antworten" klicken und verifizieren, dass die Antwort beim ursprünglichen Absender ankommt.

    • 5. Einschränkungen und Hinweise

    • Die ursprüngliche Absenderadresse steht nach dem Rewrite nicht mehr im adressierbaren Teil des From-Headers, sondern im Anzeigenamen und im Reply-To. Für die meisten Anwendungsfälle (Lesbarkeit + funktionierendes Antworten) ist das ausreichend; SPF/DKIM/DMARC-Auswertungen des Empfängers beziehen sich auf die Smarthost-Identität.
    • Die Option aus Schritt 1 wirkt global auf alle Weiterleitungen des Servers (inkl. Spamfilter-Durchlauf).
    • Die Regeln wirken auf Nachrichten mit X-MDRedirect-Header, d. h. auf Konto-Weiterleitungen (Benutzerkonten-Editor → Weiterleitung). Andere Weiterleitungswege (z. B. IMAP-Filter mit Weiterleiten-Aktion) wurden nicht abschließend für alle Konstellationen verifiziert – im Zweifel testen.
    • Alternative für rein externe Nachrichten: Liegt das weiterleitende Postfach bei IONOS/1&1 und sollen nur von extern eingehende Nachrichten weitergereicht werden, ist eine Umleitung im IONOS-Webmail ein sauberer Weg, bei dem der ursprüngliche From-Header vollständig erhalten bleibt (die Weiterleitung läuft dann providerintern und durchläuft die Smarthost-Prüfung nicht). Diese erfasst jedoch keine Nachrichten, die nur innerhalb des MDaemon-Servers entstehen. Beide Wege können parallel betrieben werden.
    • Das Umschreiben des From-Headers per Kopfzeilen-Umsetzung (Server-Einstellungen) löst zwar ebenfalls das Zustellproblem, ist aber statisch (ein Eintrag pro Absenderadresse), verliert die ursprüngliche Absenderadresse bis auf den Anzeigenamen und kollidiert mit den hier beschriebenen Regeln. Nicht mit dieser Lösung kombinieren.

    6. Diagnose-Referenz

    BeobachtungBedeutung / Maßnahme
    554 Unauthorized sender address nach DATA, AUTH mit 235 erfolgreichKernproblem dieses Artikels: From-Header-Mismatch. Lösung gemäß Abschnitt 4.
    550 Sender address is not allowed bei MAIL FROMEnvelope-Absender ist für das Smarthost-Konto nicht zugelassen. „Inhalt für SMTP-Befehl MAIL" in der Weiterleitung prüfen (muss die beim Provider authentifizierte Adresse sein).
    Inhaltsfilter-Log: Forwarded message detected; further processing skippedOption aus Schritt 1 nicht wirksam → Option prüfen + Dienstneustart.
    Weiterleitungskopie erscheint gar nicht im Inhaltsfilter-Log (nur pd*.msg im SMTP-Log)Wie vorstehend – ohne die Option laufen Weiterleitungskopien vollständig am Inhaltsfilter vorbei.
    Regeln matchen laut CF-Log, trotzdem 554From-Header nach Rewrite prüfen (.msg in der Bad Queue öffnen): Ist die eingesetzte Adresse beim Smarthost zugelassen? Ggf. Variante B. Außerdem prüfen, ob eine Kopfzeilen-Umsetzung oder eine weitere Regel das Ergebnis nachträglich verändert.
    Reply-To enthält die falsche (bereits umgeschriebene) AdresseRegel-Reihenfolge falsch (From-Regel vor Reply-To-Regel) oder eine Kopfzeilen-Umsetzung schreibt den From bereits vor dem Inhaltsfilter um. Reihenfolge korrigieren, Kopfzeilen-Umsetzung entfernen.
    Doppelte Zustellung beim EmpfängerZusätzlicher Benutzer-Filter (IMAP-Filter) leitet parallel weiter → deaktivieren.
    Regeln erscheinen nach CFRules.dat-Bearbeitung nicht in der GUINummernkollision in der Datei (doppelte [RuleNNN]-Sektion) oder Neustart fehlt.

    Bei Ticket-Eingang zu diesem Themenkomplex immer dazu legen:

    SMTP-Ausgangsprotokoll (fehlgeschlagene Session) und Inhaltsfilter-Protokoll (Verarbeitungseintrag zur betroffenen Nachricht). Diese beiden Protokolle genügen, um die Ursache eindeutig einzuordnen.