Get Adobe Flash player

Standard

MTA – Standards müssen her

Wer sich viel mit Email-Technik beschäftigt, der muss sich zwangsweis auch mit MTA’s befassen. Je nachdem, ob man einen Server selbst aufsetzt oder einen fertigen in Gebrauch nimmt, muss man sich selbst für einen Mail-Transfer-Agent entscheiden oder sich mit dem vorgesetzten auseinandersetzen.

Lange Zeit war Sendmail die Nummer 1 der Mailabwickler. Dies lag auch daran, dass seine Wurzeln bis in die 80er Jahre zurückreichen und es lange schlicht keine Alternative gab. Es gab ja auch keinen Grund dazu, denn Sendmail war zuverlässig und erfüllte alle Anforderungen.  In den 90er Jahren kamen dann aber doch Konkurrenten auf den Markt, die viele Kritikpunkte in Sendmail sahen, allen voran Aspekte der Sicherheit. Immerhin gab es zu Entstehungszeiten von Sendmail noch keine Spam-Problematik

Eine dieser Entstehungen ist Qmail. Qmail ist streng modular aufgebaut und wird auch nicht standardmäßig im Root-Verzeichnis des Servers installiert (wie etwa Sendmail).  Die Verankerung im Root-Verzeichnis legt einem Angreifer alle Wege offen, sobald er die Hürde des MTA genommen hat. Der modulare Aufbau sorgt zusätzlich dafür, dass der Assistent stabiler läuft und ein ausfallender Abschnitt, also ein Modul, nicht gleich für den Absturz des Mailservers sorgt.

Aber ich will hier eigentlich gar keinen MTA-Vergleich oder sonst eine Bewertung abliefern. Auch ist die Liste der aktiven MTA’s weit länger als die zwei bisher genannten. Dazu ist aber Wikipedia da.Wie der Titel schon sagt, möchte ich mich für eine Standardisierung aussprechen. Jeder Mail-Server gibt für jeden Task eine Antwort ab. Diese finden sich etwa in den zugehörigen Logfiles. Sie werden aber auch etwa bei Bounce-Mails an den Versender einer Email abgeschickt. Hierfür nutzt jeder MTA bestimmte Codes, Ausdrücke oder ganze Sätze. Liest man diese Responses durch, wirkt es oft schon sympathisch menschlich, was der Server da so von sich gibt. Leider nur ist es so, dass unterschiedliche Systeme für die gleichen Szenarien auch unterschiedliches Feedback geben.

Für den Fall, dass der eigene Server beobachtet werden soll, ist das ja nicht weiter schlimm: man lernt, mit seinem Mailer zu kommunizieren. Was aber machen diejenigen unter uns, die etwa groß im Email-Marketing-Geschäft stecken? Werden zahlreich Newsletter verschickt, so ist ein anständiges Bounce-Management eine bereichernde Geschichte und für jeden PHP-Entwickler auch leicht automatisierbar, wäre da nicht diese Unterschiedlichkeit! Das ankommende Feedback sollte für einen Mailprofi in Softbounce und Hardbounce kategorisiert werden können. Denn abhängig davon müsste auf unterschiedliche Weise mit dem potentiellen Empfänger bzw. seiner Email-Adresse umgegangen werden.

Leider kommt man dabei nicht drum herum, Versuche und Ausnahmen zu programmieren, in der Hoffnun, jeden Fall abfangen zu können. Perfekt wird das aber kaum werden können.

Dabei ist es sogar so, dass es einen RFC-Standard dafür gibt, er sollte halt nur auch konsequent genutzt werden: RFC 1893.  Von Qmail wird dieser Standard beispielsweise eingesetzt. Das schöne daran ist auch: ein bestimmtes Ereignis wird nicht nur in einem festgelegten Wortlaut beschrieben, es erhält auch einen festgelegten numerischen Code.

Eine einheitliche Orientierung würde viel Ärger, Arbeit und Ungewissheit ersparen.