In diesem Beitrag dokumentiere ich eine Lösung für die Meldung: „554 5.7.1 REJECT policy violation – too many different Display Names – code #242 (in reply to end of DATA command)“
Umgebung
Ich betreibe einen Virtual Private Server (VPS) im Internet, sowie einige Raspberry Pis und weitere Geräte, die man heute wohl am ehesten dem Internet der Dinge zuordnen würde.
Diese Systeme sollen mir Systemmeldungen per E-Mail senden. Dafür habe ich mir ein günstiges E-Mail-Postfach bei Mailbox.org gebucht und auf den betroffenen Systemen Postfix installiert und zum Versand über einen Smarthost konfiguriert. Die Konfiguration erfolgte über die Ansible-Rolle relaymail von Yannik. Diese dient jedoch nur als Werkzeug. Die Konfiguration kann selbstverständlich auch manuell durchgeführt werden.
Problembeschreibung
Bei einer Systemüberprüfung fielen mir einige Fehlermeldungen der folgenden Art ins Auge (einige Werte durch <Platzhalter> ersetzt):
„<Hostname und IP-Adresse> said: 554 5.7.1 id=<ID> – Rejected by next-hop MTA on relaying, from MTA(smtp:[<IP-Adresse>]:10025): 554 5.7.1 REJECT policy violation – too many different Display Names – code #242 (in reply to end of DATA command)“
Während meine Raspberry Pis mit Raspbian GNU/Linux 10 (buster) und Postfix 3.4.14-0+deb10u1 sich wie erwartet verhalten und lediglich meine E-Mail-Adresse in das Header-Feld „From“ eintragen, fügt mein VPS mit Debian GNU/Linux 10 (buster) und Postfix 3.4.14-0+deb10u1 den Namen des jeweiligen Benutzers bzw. Dienstes mit ein, welcher die E-Mail versenden möchte. Diese Informationen nimmt der VPS aus dem Kommentarfeld der /etc/passwd. Während die Kommentarfelder auf meinen Raspberry Pis leer sind, sind diese auf dem VPS entsprechend gefüllt.
Im E-Mail-Header stellt sich das dann wie folgt dar.
Header-Auszug bei E-Mail von Raspberry Pi
Date: Mon, 10 May 2021 04:56:32 +0200 (CEST)
From: no-reply@example.comHeader-Auszüge bei E-Mails vom VPS
From: no-reply@example.com (Cron Daemon)
To: rootDate: Mon, 10 May 2021 04:44:12 +0200 (CEST)
From: Jörg Kastning <no-reply@example.com>Date: Mon, 10 May 2021 04:44:36 +0200 (CEST)
From: root <no-reply@example.com>Lösung
Um das Problem aufzulösen, lasse ich nun Postfix das Header-Feld „From“ umschreiben und explizit auf den Wert no-reply@example.com setzen. In der /etc/postfix/main.cf müssen dazu folgende Zeilen vorhanden sein:
sender_canonical_classes = envelope_sender, header_sender
sender_canonical_maps = regexp:/etc/postfix/sender_canonical_maps
smtp_header_checks = regexp:/etc/postfix/header_checkInhalt der /etc/postfix/sender_canonical_maps:
/.+/ no-reply@example.comDies sorgt dafür, dass Postfix das Feld „Envelope-From“ explizit auf no-reply@example.com setzt.
Inhalt der /etc/postfix/header_check:
/From:.*/ REPLACE From: no-reply@example.comHiermit wird der Wert des Header-Felds „From“ explizit auf no-reply@example.com gesetzt. Die Lösung habe ich hier gefunden. Damit läuft der Versand meiner Systembenachrichtigungen wieder.
Spannend, ich habe das genau anders gelöst.
Vor etwa einem halben Jahr bin ich mit allen (bis auf eine) Domains zu mailbox.org umgezogen und braucht damit den Mailserver „eigentlich“ nicht mehr.
Für die letzte Domain habe ich immer noch Mail selber konfiguriert und nutze den Mailserver, um Benachrichtigungen zu versenden. Das klappt bestens.
Na so anders ist das gar nicht. Meine Domain und meine privaten E-Mails liegen bereits seit Jahren bei Mailbox.org und ich betreibe für Mail keinen eigenen MTA und MDA mehr.
Da ich bei Mailbox.org jedoch nur einen Benutzernamen und Passwort habe, möchte ich diese nicht auf all meinen „Servern“ und IoT-Geräten hinterlegen. Dies würde nur das Risiko unnötig erhöhen, dass sie doch mal bekannt werden. Gerade auf Systemen, wo auch noch andere Personen Root-Rechte haben. Deshalb habe ich mir einen extra Account dafür gegönnt.
Bis vor Kurzem funktionierte das auch tadellos, bis Mailbox.org diese Policy nachgerüstet hat.