Mal wieder ein Problem zum Thema Email und Postfix. Neulich erst SMTPUTF8, jetzt wieder etwas was sich der Admin vor Ort nach Erklärungen und Lösungen sucht.

Fortune hat einmal zu mir folgendes gesagt:

Das Spiel beginnt

Bevorzugt kommen solche Fragen ja immer am spätem Nachmittag rein. Mal wieder das Thema Email. Mal wieder auf den ersten Blick dubios: Angeblich kann ein Emailserver keine Mails an eine bestimmte Empfangsdomain senden. Als Grund wird der fehlende Reverse DNS-Eintrag angegeben. Dieser ist aber gesetzt. So auf die schnelle passt hier irgendwas nicht zusammen, der detailliertere Blick ins Protokoll muss her. Hier findet sich folgendes – stark gekürzt und anonymisiert. Du weißt schon, Datenschutz und so 😉

May  7 14:12:37 methusalix postfix/smtp[587]: 0D2B11E0027: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.57, delays=0.02/0.01/0.33/0.21, dsn=2.0.0, status=sent (250 OK id=1hNyxZ-00061t-DZ)
May  7 14:12:37 methusalix postfix/smtp[587]: 9600B1E0028: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.35, delays=0.01/0/0.22/0.12, dsn=2.0.0, status=sent (250 OK id=1hNyxZ-00068z-RW)
May  7 14:13:23 methusalix postfix/smtp[587]: EAE621E0028: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.4, delays=0.01/0/0.21/0.18, dsn=2.0.0, status=sent (250 OK id=1hNyyJ-0007Tp-6X)
May  7 14:55:19 methusalix postfix/smtp[6340]: A672D1E0027: to=<emfp@aeng.er>, relay=mail.gatew.ay[1.1.1.1]:25, delay=0.65, delays=0.01/0/0.5/0.14, dsn=2.0.0, status=sent (250 OK id=1hNzct-0006QR-6i)
May  7 15:13:07 methusalix postfix/smtp[8811]: 6C1A31E0027: to=<emfp@aeng.er>, relay=mail.gatew.ay[1:1:1:1::1:1]:25, delay=0.39, delays=0.03/0.01/0.32/0.03, dsn=5.0.0, status=bounced (host mail.gatew.ay[1:1:1:1::1:1] said: 550-Inconsistent/Missing DNS PTR record (RFC 1912 2.1) 550 (methusalix.doma.in) [1:1:1:1::1]:44636 (in reply to RCPT TO command))

smtp_address_preference = any ist wie es sich gehört richtig gesetzt. Das macht so einfach mit am meisten Sinn und wird in der Dokumentation letztendlich genauso empfohlen. inet_protocols brauche ich gar nicht zu kontrollieren, muss auf any stehen. Sonst hätte es gar nicht die beiden unterschiedlichen Zustellvarianten geben dürfen. Um jetzt zu verstehen was da passiert sollte man die Doku kennen oder sich an das im Block links angeführte Zitat von Wietse erinnern.

Somit ist die Lösung für dieses Rätsel fix gefunden: Für diese eine Empfangsdomain sollte der Emailausgang ausschließlich auf IPv4 festgelegt werden. Nur kennt Postfix keine inet_protocol_map in der man dies festlegen könnte. Es ist also mal wieder die Frage nach etwas Kreativität um eine passende Lösung mit Postfix Mitteln entsprechend abzubilden.

Und der Weg zum Ziel ist unterm Strich mal wieder ganz einfach: Man definiert in der master.cf einen weiteren smtp Dienst welcher als Option das oben bereits erwähnte inet_protocols = ipv4 hat. Im zweiten Schritt noch fix einen passenden Eintrag für die Zieldomain in der transport Tabelle gesetzt welche genau diesen Dienst verwendet und voilà: Ziel erreicht.

Die Umsetzung

Die folgenden Beispiele zeigen an reinen Textdateien unter /etc/postfix die passende Konfiguration für die Empfängerdomain gehirn-mag.net. Wer dort bereits eine transport-Tabelle hat kann diese selbstverständlich nutzen. Wer ein Datenbank- oder LDAP-Backend hat kann diese Lösung sinngemäß übertragen. Hier aber, der Einfachheit wegen, das Beispiel an den „blanken“ Textdateien. Und Du solltest logischerweise die Empfängerdomain richtig anpassen 🙂

Die erste Datei die geändert wird ist /etc/postfix/master.cf. Hier wird ein weiterer Dienst eingetragen. Eine Zeile analog zur ersten gibt es bereits. Wichtig ist, dass zu Beginn am Anfang und am Ende smtp steht und kein smtpd. Diese kopiert ihr, ändert den Namen (Zeile 2, Spalte 1) und fügt darunter den Inhalt der Zeile 3 ein.

Als nächstes ist /etc/postfix/main.cf dran. Hier ist zu prüfen ob es eine transport_maps Zeile gibt. Falls nicht fügt Ihr diese einfach ein.

Und zu guter Letzt ist die transport Tabelle /etc/postfix/transport selbst. Hier ist der Eintrag für die Zieldomain zu setzen, dass diese unseren neuen IPv4 smtp Dienst verwendet.

smtp      unix  -       -       y       -       -       smtp
smtp-ipv4 unix  -       -       y       -       -       smtp
    -o inet_protocols=ipv4

transport_maps = hash:/etc/postfix/transport

gehirn-mag.net           smtp-ipv4:

Nun müsst Ihr noch via postmap /etc/postfix/transport diese für postfix übersetzen und mit postfix reload den Mailserver neu starten. Postfix versendet nun für Eure Zieldomain alle Mails dorthin via IPv4 anstatt frei zu wählen was er jetzt verwenden könnte.

Und fertig!

Was eine Lösung. Ist das wirklich elegant gemacht auf diese Art und Weise? Ja, das ist Sie. Auf ihre ganz spezielle Art. Einen eigenen Dienst in der master.cf anzulegen macht man eigentlich öfters. Am häufigsten wohl als Ziel für irgendwelche Postfachsysteme wie IMAP/POP3 oder Groupware-Systeme. Wenn man diese externe Domain mit der sinngemäßen gleichen Logik betrachtet ist das schon sehr ähnlich: Ein Postfachspeicher welcher Emails via SMTP annimmt und obwohl er eine IPv6 Adresse hat kann der Dienst aber nur IPv4. Ich betreue Postfix Umgebungen bei denen aufgrund von der Vielzahl und der Größe der dahinter liegenden Groupware Lösungen die transport-Tabelle länger ist bei vielen anderen Installationen die virtual-Tabelle. Da erlebt man noch ganz andere Dinge…

In größeren Emailumgebungen ist man gefühlt nie am Ende mit der Konfiguration angekommen. Man mag sich in dem zu Beginn angesprochenen Tunnel fühlen. Sobald die Ursache aber sauber erfasst wurde ist die Lösung des Problems rasch erledigt und das Ende des Tunnels naht. Bis zum nächsten Anruf 😉

Aber morgen kontaktiere ich erstmals den Emailadmin auf der anderen Seite und frage nach den Gründen für diese Fehlermeldung – Feierabend für heute.

Quellen

• GNU Bild: Wikimedia – kann aber genauso gut auf gnu.org direkt gezogen werden
• Wietse Bild: Wikimedia – public domain