Mailserver an DSL-Anschlüssen oder anderen Leitungen mit fester IP-Adresse und das Wechselspiel der IP-Auflösungen (A, MX, PTR)

Seit 1986 gibt es klare Regeln wie Elektropost im Internet versendet zu werden hat, diese Regeln wurden 2001 überarbeitet, und sollten inzwischen in jedem Mailserver implementiert sein. 

Aber selbst wenn der Mailserver richtig eingestellt ist, Hostname und „helo“ übereinstimmen und aufgelöst werden können, werden Mails oft nicht angenommen oder als SPAM markiert und landen ungelesen in digitalen Nirwana. Die Ursache könnte eine fehlerhafte Rückwärtsauflösung sein, die sich einfach korrekt einstellen lässt.


Werbung



Es gibt 3 Sachen die zueinander passen müssen.

  1. Das eine ist das „helo„, das ist der Name mit dem ein Mailserver sich bei dem Empfänger meldet. (z.b. „mail.crnet.de“), dieser name muss ein gültiger Hostname sein (also „fritzes.mailserver“ oder „default.domain.tld“ geht schonmal nicht).
    (RFC 2821, Section 3.6)
  2. Dieser im helo genannte Hostname muss auch auf den Host passen von dem gesendet wird (vorwärts Auflösung im DNS). Also „mail.crnet.de“ darf sich nur der Mailer nennen, der von der IP 212.91.251.66 sendet.
    (RFC 2821, Section 3.6)
  3. Die sendende IP muss rückwärts aufgelöst auch auf genau diesen Hosteintrag passen. ( also z.B. IP 212.91.251.66 rückwärts aufgelöst ergibt „mail.crnet.de“)
    (RFC1912 – Section 2.1)

Und genau der 3. Punkt ist meist bei den Betreibern von privaten Mailservern an DSL-Anschlüssen (u.ä.) der Punkt der vernachlässigt wird. Dabei sagen die Anbieter dieser Leitungen selber, das das unabdingbar ist, und bieten dementsprechende Möglichkeiten an, um diesen Eintrag korrekt zu setzen. Ich hab Kunden mit eigenen Mailservern bei QSC, bei der T-Com, bei Colt, bei Manitu – und ausnahmslos alle bieten an, das es einen korrekten PTR gibt.

Zum Beispiel bei der Telekom (die Ihre festen IPs nur Businesskunden zuteilt) sieht das im DSL Business Kundencenter so aus:

Kundencenter - Anschlussdaten - Reverse Mapping

Kundencenter – Anschlussdaten – Reverse Mapping

 

Der Menü-Punkt

Der Menü-Punkt

 

Die klare Ansage

Die klare Ansage

Und genau da steht es auch:

Reverse Mapping ist z.B. für den erfolgreichen Betrieb eines eigenen Mailservers erforderlich.

Erforderlich“ steht da, nicht „es wäre hübsch“ oder „besser wenns so wär„, sondern klipp und klar:
Es ist erforderlich.“


Werbung


Was passiert wenn dieser Eintrag nicht stimmt?

Da gibt es drei Möglichkeiten:

  1. Der Empfangende Mailserver hat keine Prüfung auf Gültigkeit und keinen Spamschutz.
    Dann nimmt der die Mail an – genauso wie die anderen über 90% der Mails mit Nachrichten die die Benutzer nicht haben wollen, und der Empfänger muss aus dem Wust von Müll die Mail erst heraussuchen. Bei so einem Mailserverbetreiber möchte ich nicht Kunde sein.
  2. Der Empfangende Mailserver hat keine Prüfung auf Gültigkeit aber Spamschutz.
    Das ist das gefährlichste, denn die Mail landet im SPAM-Postfach, weil dem Spamfilter das Missachten der Regeln auffällt. (Z.B. Web.de, Googlemail etc.) – wer da ein Konto hat, der weiss das eh niemand in die Spamfolder schaut, die Nachricht hat also die allergrößten Chancen übersehen zu werden und im Digitalnirwana versenkt zu werden, ohne das es jemand merkt.
  3. Der Empfangende Mailser hat eine Gültigkeitsprüfung und verweigert die Annahme der Mail.
    Unserer Meinung nach die fairste Behandlung des Problems, denn es bekommt genau der die Information, das etwas nicht stimmt, der dafür Verantwortlich ist, bzw. den dafür Verantwortlichen erreichen kann: der Absender.
    Der kann dann seinen Mail-Admin in den Hintern treten, damit der seinen Job mal so macht, wie es sich gehört.

 

In den Fehlermeldungen steht dann auch drin, das der Absender sich an SEINEN Administrator wenden soll, und eine Diagnoseinformation, die einer kompetenten Fachkraft etwas sagt. Da steht nicht, das man sich an den Administrator des Empfängers wenden soll, und dem vorwerfen muss, daß der seinen Mailserver so betreibt, wie die Spielregeln es vorsehen.

Gültige Einträge in den entsprechenden Mailservern sollten natürlich rundum eingetragen sein, also sollte der sendende Host möglichst auch der MX für die Domain sein, Bounces annhemen, ggfs einen SPF-Record haben auf den der Sender passt etc.

Wer das nicht in den Griff bekommt, sollte keinen Mailserver betreiben, oder ausgehende Mails über ein Relay bei dem diese Sachen stimmen und passen versenden. Bei MS-Exchange z.B. heisst diese Funktion „Smart-Host“.


Werbung


Beispiel Fehlermeldung, die beim Absender durch Exchange zurückkommt:

Ihre Nachricht wurde aufrund von Sicherheitsrichtlinien nicht zugestellt. MS-Exchange versucht nicht, diese Nachricht für Sie erneut zuzustellen. Wenden Sie sich mit dem folgenden Diagnosetext an Ihren Systemadministrator. Die folgende Organisation hat Ihre Nachricht zurückgewiesen: mail.crnet.de
[ … ]
Diagnnoseinformation für Administratoren: mail.crnet.de #550 5.7.1 <hostname xyz.t-ipconnect.de [ip]>: client host rejected (Fehlermeldung)