Artikel mit ‘smtp’ getagged

Es sei denn, es ist die letzte Zeile

Samstag, 09. Juni 2012

Mit SMTP verhält es sich so: Ein Client sendet ein Kommando; der Server antwortet mit einem dreistelligen Statuscode, gefolgt von einem Leerzeichen und Text. Beispielsweise so:

HELO mainz.jonaspasche.com
250 crux.uberspace.de

Eine Antwort kann aber auch mehrzeilig ausfallen – in diesem Fall wird zwischen Statuscode und Text ein Minus statt eines Leerzeichens angegeben, um zu signalisieren, dass noch eine weitere Zeile kommt, und erst die letzte hat dann ein Leerzeichen. Beispielsweise so:

EHLO mainz.jonaspasche.com
250-crux.uberspace.de
250-PIPELINING
250-8BITMIME
250-AUTH LOGIN PLAIN
250 STARTTLS

Einige Mailserver nutzen dieses Feature, um gleich zur Begrüßung einen kleinen Roman loszuwerden:

220-mtain-me06.r1000.mx.aol.com ESMTP Internet Inbound
220-AOL and its affiliated companies do not
220-authorize the use of its proprietary computers and computer
220-networks to accept, transmit, or distribute unsolicited bulk
220-e-mail sent from the internet.
220-Effective immediately:
220-AOL may no longer accept connections from IP addresses
220 which no do not have reverse-DNS (PTR records) assigned.

So oder so: Nicht übermäßig kompliziert zu verstehen, das mit dem Minus und dem Leerzeichen.

Nun bekamen wir kürzlich eine Supportanfrage eines Ubernauten, der mehrere Uberspaces bei uns hat, dabei mindestens einen auf einem CentOS-5-Host und einen auf einem CentOS-6-Host. Unser netqmail-Setup unterscheidet sich hier ein wenig: Auf den CentOS-5-Hosts setzen wir einen TLS-Patch für netqmail ein; auf den CentOS-6-Hosts hingegen verwenden wir Spamdyke als SMTP-Frontend, das unter anderem TLS für ein in dieser Hinsicht ungepatchtes netqmail bereitstellt.

Der fragliche User berichtete nun, dass er mit seinem Android-Smartphone auf dem CentOS-5-Host problemlos SMTP AUTH mit TLS nutzen könne; auf dem CentOS-6-Host jedoch würde Android antworten, dass TLS erforderlich aber nicht von Server unterstützt sei. Dabei ging es um unseren Host crux, dessen EHLO-Rückgabe oben bereits zitiert wurde und der – ganz entgegen der Fehlermeldung – sehr wohl TLS-Support annonciert. Was zum..?!

Selbst ein Mitschneiden der Verbindung mittels tcpdump brachte nicht viel: Es war der Connect zu sehen, das EHLO, die Antwort des Servers, der klar STARTTLS annoncierte – und dann verabschiedete sich Android und jammerte, TLS würde nicht gehen.

Es brauchte einiges an Recherche, bis ich dann auf diesen fantastischen Bug-Report gestoßen bin: Email app doesn’t recognize STARTTLS as last line of EHLO response. Und Tatsache: Der entsprechende Code prüft auf TLS-Support, in dem er schaut, ob in der EHLO-Antwort die Zeichenkette „-STARTTLS“ enthalten ist. Ja, genau: Mit Minus. Im Klartext: Es erkennt den TLS-Support nur dann, wenn jener nicht in der letzten Zeile annonciert wird. Mir erschien das eigentlich schon fast zu blöde, um ernsthaft wahr zu sein, aber ich habe dann testweise Spamdyke gepatcht, damit der TLS-Support nun wie folgt annonciert wird:

EHLO mainz.jonaspasche.com
250-crux.uberspace.de
250-PIPELINING
250-8BITMIME
250-AUTH LOGIN PLAIN
250-STARTTLS
250 X-NOTHING

Tja, was soll ich sagen: Der Android-Mailclient funktioniert damit einwandfrei. Ist das zu fassen?

Nun ist der Bug-Report vom März 2009. Drei Tage später schreib jemand mit einer google.com-Adresse: „This issue is assigned to an engineer for further evaluation“ – supi. Dann passierte erstmal wochenlang nichts. Im Juli – immer noch 2009 – wurde ein Patch eingereicht, der im Prinzip die Zeile

if (result.contains("-STARTTLS")) {

durch diese Zeile ersetzt:

if (result.contains("-STARTTLS") || result.contains(" STARTTLS")) {

Es dauerte bis zum April 2010, bis der Patch in den produktiven Code übernommen wurde – was nichts daran ändert, dass sich die Kommentare im Bugreport auch weiterhin wie folgt lesen:

  • „Any resoulution on this issue yet?“ (August 2010)
  • „What should non-expert users stuck on Android 2.1 do to get around this? Any suggestions?“ (März 2011)
  • „I would’ve hoped Google would’ve fixed their email app by now.“ (Juni 2011)
  • „I guess google have fixed it, in a later release, but my phone will never be upgraded to 2.2 by the manufacturer or network.“ (Juni 2011)
  • „I can’t believe this is still not working *!#$!*“ (September 2011)
  • „Still not working in Android 4.0 Emulator.“ (November 2011)

Zwei Dinge stechen hier besonders hervor: Zum einen ein deutlicher Hinweis darauf, was für eine Schande es ist, dass kaum ein Hersteller von Android-Smartphones ernsthaft eine vernünftige Update-Politik betreibt und somit nur ein Bruchteil der Android-User in den Genuss von Bugfixes kommt.

Zum anderen ein Hinweis darauf, dass sich dieser Bug offenbar auch in aktuellen Versionen immer noch zeigt – und das nicht nur direkt beim Google-Projekt, sondern auch beim CyanogenMod-Projekt, das mit TLS does not work if STARTTLS is last line in server response einen inhaltlich identischen Bug-Report aufweist, allerdings aus dem November 2011, wo der Bug doch eigentlich schon längst gefixt hätte sein müssen. Der Bug-Reporter schickt auch gleich den – einzeiligen – Patch mit, der nötig ist, um diesen trivialen Bug zu fixen. Statt eines Dankeschöns wird er angeranzt, man habe Patches über Gerrit (ein von Google entwickeltes Review-System) einzureichen, woraufhin der Bug-Reporter trocken reagiert: „don’t have a development system… so then forget it.“ – vielen Dank auch, super gelaufen.

Wie’s aussieht, wird uns dieses Problem also noch eine Weile erhalten bleiben. Wir werden uns dann mal daran machen, unsere Spamdyke-Installationen zu patchen:

--- spamdyke-4.3.1/spamdyke/spamdyke.c	2012-01-19 16:58:29.000000000 +0100
+++ spamdyke-4.3.1-patched/spamdyke/spamdyke.c	2012-06-03 21:23:50.985562352 +0200
@@ -2436,8 +2436,11 @@
 
                     /* Add a "250 STARTTLS" line. */
                     output_writeln(current_settings, LOG_ACTION_FILTER_FROM, STDOUT_FD, SMTP_EHLO_SUCCESS, STRLEN(SMTP_EHLO_SUCCESS));
-                    output_writeln(current_settings, LOG_ACTION_FILTER_FROM, STDOUT_FD, SMTP_STR_DONE, STRLEN(SMTP_STR_DONE));
+                    output_writeln(current_settings, LOG_ACTION_FILTER_FROM, STDOUT_FD, SMTP_STR_CONTINUATION, STRLEN(SMTP_STR_CONTINUATION));
                     output_writeln(current_settings, LOG_ACTION_FILTER_FROM, STDOUT_FD, SMTP_EHLO_TLS_INSERT, STRLEN(SMTP_EHLO_TLS_INSERT));
+                    output_writeln(current_settings, LOG_ACTION_FILTER_FROM, STDOUT_FD, SMTP_EHLO_SUCCESS, STRLEN(SMTP_EHLO_SUCCESS));
+                    output_writeln(current_settings, LOG_ACTION_FILTER_FROM, STDOUT_FD, SMTP_STR_DONE, STRLEN(SMTP_STR_DONE));
+                    output_writeln(current_settings, LOG_ACTION_FILTER_FROM, STDOUT_FD, SMTP_EHLO_NOTHING_INSERT, STRLEN(SMTP_EHLO_NOTHING_INSERT));
                     }
                   else if ((filter_return & FILTER_MASK_TLS) == FILTER_FLAG_TLS_REMOVE)
                     filter_return ^= FILTER_FLAG_TLS_REMOVE;

Ernsthaft bei Spamdyke für künftige Releases einreichen können wir den Patch wohl kaum – das wäre ja schon irgendwie etwas arg lächerlich, um solche dämlichen Android-Bugs in Fremdsoftware herumworkarounden zu müssen. Natürlich ist das ein Bug, der in Android selbst gefixt werden muss. Aber so ist das eben nun mal, wenn man sich ein Gerät zulegt, dessen Plattform so geschlossen ist, wie es nur irgend geht – wenn ich dann letztlich bei der Update-Politik dann doch wieder von der Güte meines Smartphone-Herstellers völlig abhängig bin, spielt eigentlich keine Rolle mehr, dass da ein Linux drunter läuft; mit freier Software hat das nichts mehr zu tun.

Facebook und die Bounces

Dienstag, 07. Juni 2011

Ich weiß nicht, seit wievielen Jahren genau es als „bad practice“ gilt, Bounces zu versenden. Bounces gehen nun mal an die Adresse, die als Envelope Sender in der SMTP-Session angegeben wird – und das muss eben durchaus nicht die Adresse desjenigen sein, der die Mail tatsächlich verschickt hat. Insbesondere bei Spam ist das regelmäßig nicht der Fall, was letzten Endes heißt: Mailserver, die Mails nicht direkt in der SMTP-Session ablehnen, sondern jene erst akzeptieren und dann später bouncen, lösen damit als Antwort auf eine Welle von Spam eine Welle von Bounces aus, die dann denjenigen trifft, den der Spammer zufällig als Absender gewählt hat. Ich selbst habe im Lauf der Jahre immer mal wieder erlebt, wie plötzlich innerhalb weniger Stunden zehntausende von Bounces auf meiner Mailadresse eintrafen, die jemand als Absender von Spam verwendet hatte.

Das Ärgerliche dabei ist, dass sich sowas nur schwer filtern lässt, denn die Bounces sind ja so gesehen durchaus „legitime“ im Sinne von „gut gemeinten“ Mails; sie haben keinen strikten Aufbau, und im blödesten Fall zitieren sie auch die Originalmail nicht, so dass der Spamfilter wirklich keine Chance hat, wenn ich ihn nicht darauf trainieren will, allgemein Bounces als Spam anzusehen.

Folgerichtig haben einige RBL-Betreiber damit begonnen, nicht nur Hosts, die Spam versenden, auf ihre Listen zu setzen, sondern auch Hosts, die Bounces versenden. Dazu gehören nicht nur ganz exotische RBLs, sondern auch Größen wie z.B. SpamCop, die durchaus eine gewisse Reputation haben und das Problem in ihrer FAQ gut erläutern.

Mittlerweile sind so ziemlich alle Mailserver auf einem Entwicklungsstand, dass sie Mails, die sie dann ohnehin nicht zustellen, auch gar nicht erst annehmen. Selbst das von uns gerne eingesetzte netqmail, dem gerne – und zu Recht – vorgeworfen wird, „delayed bounces“ zu senden, setzen wir nicht ohne eine Empfängerprüfung ein, in der Regel den validrcptto.cdb-Patch.

Der Einzige, der mir legitimer- und auch erwünschterweise Bounces senden können sollte, dürfte in einer idealen Welt ausschließlich der Mailserver sein, den ich zum Relaying verwendet habe – denn der muss ja nun meine zu verschickenden Mails erstmal annehmen; er ist ja nicht der Empfänger, sondern der Postbote, der dann erstmal schauen muss, wo er eine Mail hintragen muss, und von daher regelmäßig erst später wissen kann, ob ein Empfänger existiert oder nicht.

An wem aber ist diese an sich doch recht positive Entwicklung, Mails, die man nicht haben will, direkt in der SMTP-Session abzulehnen, weitestgehend spurlos vorübergegangen? Am Über-600-Millionen-User-Netzwerk Facebook, deren Macher es als gute Idee ansehen, dass ihre User nun auch per E-Mail mit Nicht-Facebook-Mitgliedern kommunizieren können (und ich als Nicht-Facebook-Mitglied hatte das immer als Feature angesehen, dass das nicht geht – also, als Feature für mich meine ich).

Facebook-User haben offenbar die Möglichkeit, dies als Option ein- oder auszuschalten. Leider dringt das nicht bis zum Facebook-MX durch, der Mails an User, die das gar nicht wollen, problemlos annimmt:

$ dnsmx facebook.com
10 smtpin.mx.facebook.com
$ telnet smtpin.mx.facebook.com 25
Trying 66.220.155.11...
Connected to smtpin.mx.facebook.com.
Escape character is '^]'.
220 smtpin.mx.facebook.com ESMTP
HELO mainz.jonaspasche.com
250 smtpin.mx.facebook.com says HELO to 82.207.131.175:46878
MAIL FROM:<jpasche@jonaspasche.com>
250 MAIL FROM accepted
RCPT TO:<SOME_USER@facebook.com>
250 RCPT TO accepted
DATA
354 continue.  finished with "\r\n.\r\n"
Subject: Test

Test
.
250 OK 82/1F-27359-C29DDED4
QUIT
221 smtpin.mx.facebook.com closing connection
Connection closed by foreign host.

Sekunden später trudelt die Bouncemail ein (hier der Übersicht wegen etwas gekürzt; eigentlich ist es ein multipart/report):

From: Facebook <mailer-daemon@mx.facebook.com>
To: jpasche@jonaspasche.com
Subject: Sorry, your message could not be delivered
Date: Tue, 07 Jun 2011 00:55:25 -0700

This message was created automatically by Facebook.

Based on the email preferences of the person you're trying to email, this message
could not be delivered.

Reporting-MTA: dns; 10.138.205.200
Arrival-Date: Tue, 07 Jun 2011 00:55:22 -0700

Status: 5.1.1
Last-Attempt-Date: Tue, 07 Jun 2011 00:55:55 -0700
Final-Recipient: rfc822; SOME-USER@facebook.com
Action: failed
Diagnostic-Code: smtp; 550 5.1.1 RCP-P2
http://postmaster.facebook.com/response_codes?ip=82.207.131.175#rcp Refused due to
recipient preferences

„Refused due to recipient preferences“ – und das wusste man zum Zeitpunkt des RCPT TO noch nicht? Also bitte, das muss doch im Jahr 2011 besser gehen. Vor allem dann, wenn man Mail für so eine große Userbasis macht.

Wissen Sie eigentlich, dass Sie einen Mailserver betreiben?

Dienstag, 24. Mai 2011

Wer Zugangsdaten zum Abruf von Mails hat, kann damit üblicherweise auch Mails versenden. Das ist bei uns genauso wie bei praktisch allen anderen Providern auch.

Nun wissen wir natürlich nicht, was für ein Client das ist, der sich da via SMTP AUTH an einem unserer Mailserver anmeldet. In diesem Fall ist es kein Desktop-Mailclient, sondern ein Postfix-Mailserver, den der Kunde lokal bei sich betreibt. Sein Desktop-Mailclient verschickt also Mails über Postfix, und Postfix macht dann SMTP AUTH bei uns. Kein Problem, geht.

Schlecht wird es, wenn es um Spam geht. In diesem Fall ist beim Kunden nämlich offenbar ein User-Passwort geknackt worden und dann fleißig Spam über seinen Postfix-Server geschickt worden – der dies dann wiederum brav via SMTP AUTH über uns weitergeleitet hat. Gut, dass in solchen Fällen dann schnell unser Monitoring anspringt, das in diesem Fall feststellte, dass dieser User ungewöhnlich viele Mails verschickt, die dann als zumindest temporär nicht zustellbar in der Mailqueue verblieben. Minuten später war der betreffende Account zum Relaying gesperrt – ein nettes Feature von vpopmail, weil der Abruf von Mails weiterhin problemlos möglich bleibt, nur eben kein Relaying mehr. Die betreffenden Mails haben wir aus der Mailqueue in die Quarantäne verschoben, damit der reguläre Mailbetrieb erstmal weitergehen konnte.

Wir haben für diesen Fall mittlerweile ein vorgefertigtes Schreiben, das wir mit ein paar Log-Auszügen schmücken und das den Kunden sinngemäß zu folgenden drei Punkten auffordert:

  1. Teilen Sie uns mit, was genau die Ursache für den Spamversand war
  2. Teilen Sie uns mit, was genau Sie unternommen haben, um vergleichbare Vorfälle in Zukunft zu verhindern
  3. Bestätigen Sie uns bitte ausdrücklich, dass Sie ihre lokale Mailqueue geleert haben

Ziel ist, sicherzustellen, dass der Kunde wirklich verstanden hat, was das Problem war. Insbesondere Leute, die sich mit Mailserver-Administration auskennen, werden die Hände über dem Kopf zusammenschlagen, wenn sie wüssten, wie häufig wir auf Frage 2 die Antwort „Ich habe einen Spamfilter auf meinem PC installiert“ lesen müssen, was nun eben gerade überhaupt nichts damit zu tun hat, dass man ein Open-Relay-Problem hat. Es liegt uns zwar allgemein fern, Kunden „erziehen“ zu wollen. In diesem Bereich tun wir es trotzdem – freundlich, hilfreich, aber auch konsequent. Spamming ist ein AGB-Verstoß, egal ob der Kunde Urheber des Spamversands ist (sowas resultiert dann auch gleich in einer fristlosen Kündigung) oder Spam „nur“ durchgeleitet hat, oftmals durch Unwissenheit. In diesem Bereich geben wir dann auch durchaus eine zweite Chance, wenn klar ist, dass der Kunde den Vorfall zum Anlass genommen hat, sein System entsprechend abzusichern.

Ursprünglich enthielt das Schreiben nur die ersten beiden Punkte. Den dritten haben wir ergänzt, nachdem es wiederholt vorkam, dass Kunden zwar tatsächlich das ursprüngliche Problem begriffen und auch nachprüfbar behoben hatte – aber noch ein paar tausend bereits entgegengenommene Mails in seiner Mailqueue hatte, die sein Mailserver nach Wiederfreischaltung dann erst nochmal zu verschicken versucht hat.

Es hat also auch durchaus seinen Grund, dass wir die drei simplen Fragen durchnummerieren. Es scheint wirklich schwierig zu sein: Selbst wenn man eindringlich darauf hinweist, dass gegen die AGB verstoßen wurde; dass man andere User mit Spam belästigt hat (und man selbst will ja auch nicht von Spam belästigt werden) – all diese Formulierungen führen regelmäßig trotzdem nicht dazu, dass sich ein Kunde die Zeit nimmt, unsere wirklich nicht übermäßig lange Mail vollständig zu lesen und zu beantworten. Das Durchnummerieren der Fragen hat schon mal dazu geführt, dass ein etwas größerer Anteil von Kunden darauf kommt, dass wir auf drei Fragen vermutlich auch drei Antworten erwarten, aber für etwa ein Viertel alle derart Angeschriebenen liegt das offenbar immer noch nicht auf der Hand – mit der Folge, dass wir Nachfragen müssen, was für den Kunden, der relaytechnisch nun gerade „auf dem Trockenen“ sitzt, auch nicht wirklich so super ist.

Insbesondere nicht für den Kunden von heute. Es entwickelte sich ein längerer Mailaustausch, den ich in anonymisierter und in Umfang und Formulierungen etwas reduzierter Form gerne wiedergeben möchte – ein kleiner Einblick, womit wir uns auch herumschlagen müssen.

Ich: (sende dem Kunden die Hinweismail in puncto Sperrung)

Kunde: „Ich habe den Account meiner Tochter gelöscht und hoffe, dass die Spammails nicht mehr von meinem Account ausgehen. Bitte um Entsperrung, damit wir wieder am normalen Leben teilnehmen können.“

Ich: „Bestätigen Sie mir doch bitte noch, dass Sie auch die Mailqueue Ihres Mailservers gelöscht haben“ (mit nachvollziehbarer Erklärung, warum wir auf dieser Bestätigung bestehen)

Kunde: „Ich bin bei Ihnen, weil ich keine Zeit habe, mich permanent um mein System zu kümmern. Dass jemand Daten hackt, soll vorkommen. Ich habe den Account gelöscht. Was tot ist, kann keine Daten mehr versenden.“

Ich: (… detaillierte Erläuterung, wieso das Löschen eines Accounts etwas ganz anderes ist als das Löschen der Mailqueue … bildlicher Vergleich, dass wenn man den Typen, der die Briefe in den Briefkasten wirft, vom Briefkasten wegschubst, damit ja immer noch die bereits eingeworfenen Briefe bleiben …) – „Ich bitte daher erneut darum, uns ausdrücklich zu bestätigen, dass Sie die Mailqueue Ihres lokalen Mailservers geleert haben.“

Kunde: „Ich habe alles gelöscht. Ich habe alle Postausgangsordner kontrolliert und dort hängt nichts mehr zum Versenden.“

Ich hatte schon so ein ungutes Gefühl. Wäre es um einen Exchange-Server gegangen, hätte ich ja angenommen, das „Postausgang“ eine krude Übersetzung für „Queue“ wäre, aber bei Postfix … aber ich wollte mal nicht so pingelig sein und habe sicherheitshalber die Verarbeitung der Queue des betreffenden Relayhosts bei uns kurz mal gestoppt und erst dann das Relaying wieder freigeschaltet.

Sekunden später prasselten hunderte von Spammails auf uns ein. Gut, dass ich die Mailqueue vorher gestoppt hatte. Also – Account direkt wieder sperren; die frisch eingelieferten Spammails direkt auch wieder in die Quarantäne verschieben, Verarbeitung wieder starten.

So langsam frage ich mich, ob der Kunde überhaupt weiß, dass er einen Mailserver betreibt – und wenn ja, wie das sein kann, dass er selbst aus der überdeutlichen Formulierung „die Mailqueue Ihres lokalen Postfix-Mailservers“ immer wieder lediglich auf den Postausgangsordner seines MUAs kommt. Ich habe nun erstmal ganz konstruktiv vorgeschlagen, dass er doch einfach unsere Infrastruktur für die Ablage seiner Mailboxen nutzen könnte, was ihn ja nicht mal etwas extra kostet und gerade, wenn er im Grunde sowieso keine Zeit für die Administration hat, vermutlich auch die beste Lösung für ihn wäre, um nicht unbeabsichtigt das restliche Internet mit Spam zu belästigen. Erfahrungsgemäß fühlen sich leider oftmals gerade die Kunden, die schon mehr oder weniger objektiv durch ihr Handeln belegt haben, wie wenig sie sich auskennen, ganz besonders auf den Schlips getreten, statt einfach mal zu sagen: Alles klar, ich habe einen Fehler gemacht; was raten Sie mir? Warten wir mal ab, was da kommt.

Warum man mit Hotmail keinen Ärger haben möchte

Freitag, 04. März 2011

Der heutige Freitag bot eine lustige Überraschung: Plötzlich konnten von keinem unserer Hosts aus mehr Mails an Adressen unter der Domain hotmail.com zugestellt werden. Gestern ging’s noch. Heute nicht mehr.

Ich empfehle jedem Kunden, der für eingehenden Mailverkehr gerne eine Blacklist einsetzen möchte, ausschließlich welche zu verwenden, die auch nachvollziehbar machen, warum jemand gelistet wird: Sprich, wo man eine Message-ID, eine Beispiel-Mail oder auch nur wenigstens einen Timestamp erfahren kann, nach dem man im Logfile suchen kann. Bei Hotmail gibt es so etwas nicht. Also, so überhaupt nicht. Man kann nichts nachschlagen; man bekommt nur einen Link auf eine Seite, die die Statuscodes erklärt und die einem „hilfreich“ mitteilt:

Die E-Mail wurde von Windows Live Hotmail wegen Verletzung der Richtlinien zurückgewiesen. Ursache für die Zurückweisung können Spam-verdächtige Inhalte oder die Zuverlässigkeit der IP-Adresse/Domäne sein. Wenn Sie kein E-Mail-/Netzwerkadministrator sind, wenden Sie sich an Ihren E-Mail-/Netzwerk-Dienstanbieter, um Unterstützung zu erhalten.

Darin war Microsoft ja immer schon groß: Jeden, der irgendwelche Probleme hat, an den Administrator zu verweisen – aber jenem dann nicht einen Deut Hilfestellung zu geben, was für Probleme man mit einem hat, denn als Administratoren der Mailserver sehen wir in unseren Logs keinen Deut mehr als das, was auch die Enduser in ihren Bouncemails sehen. Pickel bekomme ich auch immer dann, wenn ich als Grundlage für ein Blacklisting Phrasen wie „…könnte…“ oder ganz besonders „…oder…“ lese. Ja Himmel nochmal, die Sperrung ist doch nicht vom Himmel gefallen; die wird doch einen konkreten Grund haben – wieso nennt ihr dann nicht einfach den konkreten Grund, statt mit verschiedenen theoretischen Möglichkeiten absolut überhaupt nicht hilfreich zu sein?

Ich möchte kurz einwerfen, dass wir selbstverständlich eine strikte Anti-Spam-Politik fahren. Wir filtern selbst Spam aus, so gut es geht; wir betreiben natürlich keine offenen Relays; wir stopfen Sicherheitslücken in Webapplikationen, die einen Spamversand ermöglichen; wir verpflichten unsere Kunden, Mailings nur mit confirmed Opt-In zu betreiben; und sollte wirklich mal ein Kunde als Spammer auffallen, wird ihm auch tatsächlich gekündigt. Nicht ohne Grund findet man praktisch nie auch nur einen unserer Server auf irgendwelchen Blacklists, außer vielleicht mal temporär zwischen Feststellen und Behebens eines Problems. Insofern ist es schon verwunderlich, wenn Hotmail plötzlich Mails von Hosts abweist, die in den Augen der gesamten restlichen Welt absolut „sauber“ sind – immerhin gibt es genug Massen-RBL-Checker, bei denen wir problemlos verifizieren können, dass Hosts, von denen Hotmail nichts annehmen will, definitiv auf keiner Blacklist stehen.

Kommen wir also zum „was tun“, und da redirected Hotmail einen auf dieses hübsche Formular, das man bei Zustellungsproblemen bitte ausfüllen möge:

https://support.msn.com/eform.aspx?productKey=edfsmsbl&ct=eformts&st=1&wfxredirect=1

Da geht’s dann los:

  • Primärer Kontaktname für das Unternehmen
  • Primäre E-Mail-Adresse für das Unternehmen
  • Aus welcher Domäne heraus senden Sie?
  • Wie würden Sie Ihre Firma oder sich selbst beschreiben?

Gut, soweit noch nachvollziehbar und auch kein Problem – vor allem, da man sich beim letzten Punkt durchaus als „Internetdienstanbieter (ISP)“ oder „E-Mail-Dienstanbieter (ESP)“ klassifizieren kann. Das hat nur keinen Einfluss auf den Rest des Formulars, der wie folgt aussieht:

  • Wie lauten die IP-Adressen Ihrer ausgehenden E-Mail-Server (aus der Perspektive des empfangenden Mailservers)?
  • Handelt es sich bei Ihrem Server um einen dedizierten oder einen freigegebenen Server?
  • Geben Sie bitte zur schnellen Lösung des Problems möglichst viele Details an, einschließlich des Datums und der Uhrzeit, zu denen das Problem auftrat, einer Beschreibung des Vorgangs, den Sie ausführen wollten, der genauen Schritte, durch die das Problem verursacht wurde, sowie detaillierter Informationen über möglicherweise zurückgegebene Fehlermeldungen.
  • Kopieren Sie alle Fehlermeldungen, und fügen Sie sie ein:
  • Welchen Internetdienstanbieter verwenden Sie?
  • Welches Betriebssystem verwenden Sie?
  • Nennen Sie Ihre E-Mail-Übertragungssoftware.
  • Nennen Sie Ihre E-Mail-Listen-Verwaltungssoftware.
  • Wie werden zurückgesendete Nachrichten (Unzustellbarkeitshinweise) von Ihrem System bearbeitet?
  • Wie häufig senden Sie E-Mail?
  • Welchen Umfang weisen diese E-Mail-Sendungen auf?
  • Nennen Sie einige der Konten innerhalb der Systeme von Microsoft, an die Sie zu senden versucht haben.
  • Werden in Ihren SMTP-Protokollen fehlerhafte Transaktionen angezeigt, wenn Sie versuchen, E-Mails an Adressen bei MSN, Windows Live Hotmail oder andere MSN-Dienste zu senden? Wenn ja, fügen Sie diese Einträge hier ein.
  • Können Sie von Ihren E-Mail-Servern eine Verbindung via Telnet mit Port 25 von „mx1.hotmail.com“ herstellen?
  • Können Sie die Route zu 216.32.183.201 von Ihren E-Mail-Servern rückverfolgen?
  • Geben Sie Beispiele einiger von Ihnen gesendeten Nachrichten einschließlich der Kopfzeilen an (aus der Perspektive der Empfänger). Kopieren Sie den Text und fügen Sie ihn hier ein.
  • Auf welche Art werden Empfänger Ihren E-Mail-Listen hinzugefügt?
  • Geben Sie die URL Ihrer Website an.
  • Geben Sie die URL Ihrer Datenschutzrichtlinie an.
  • Geben Sie die URL an, unter der sich Benutzer für den Empfang Ihrer E-Mails entscheiden können.
  • Geben Sie die URL an, unter der sich Benutzer dauerhaft von Ihrer E-Mail-Liste streichen lassen können.
  • Sind Sie derzeit Kunde von Return Path?
  • Nehmen Sie am Sender Score Certified-Programm teil?
  • Veröffentlichen Sie SPF (Sender Policy Framework)-/Sender-ID-Datensätze für Ihr IP?
  • Verwenden Sie gesonderte IPs für Transaktionskommunikation im Gegensatz zu Werbe-/Abonnement-Marketingkommunikation?
  • Nehmen Sie am Junk-Mail-Meldeprogramm (Junk Mail Reporting Partner Program, JMRPP) teil?
  • Setzen Sie Smart Network Data Services ein?

Alle diese Fragen sind verpflichtend zu beantworten – dabei sind drei Viertel davon für uns als ISP überhaupt nicht sinnvoll beantwortbar: Welches Betriebssystem verwenden Sie? – Ja soll ich da alle Betriebssysteme aller Server aufführen?! Nennen Sie Ihre E-Mail-Übertragungssoftware – Äh, „verschiedene“?! Wie häufig senden Sie E-Mail? – Nun ja, hm, „sehr häufig, denn wir hosten ein paar tausend Domains“?! Geben Sie die URL an, unter der sich Benutzer für den Empfang Ihrer E-Mails entscheiden können – Nun, sagten wir bereits, dass wir ISP sind? Nicht wir verschicken diese Mails!

Besonders großartig finde ich persönlich die Aufforderung, einige Mails mit Headern und Inhalt in das Formular zu kopieren. Ist Microsoft sich im Klaren darüber, dass wir als ISP nach geltendem Datenschutzrecht überhaupt nicht berechtigt sind, die Kommunikation unserer Kunden einzusehen?

Der Witz schlechthin ist schließlich: Es ist auch nicht möglich, postmaster@hotmail.com oder abuse@hotmail.com zu erreichen – die SMTP-Verbindung wird nämlich bereits nach dem MAIL FROM: abgewiesen, nicht erst nach dem RCPT TO:. Ich bin mir nicht sicher, ob das noch als RFC-konform angesehen werden kann, denn eigentlich handelt es sich hierbei um Adressen, die verpflichtend bestehen und verpflichtend von administrativem Personal gelesen werden sollten.

Tja, was nun? Wir haben nun zunächst Hotmail über einen extern stehenden Relayserver mit der Bitte um Unterstützung angeschrieben. Aber im Grunde sind wir wütend: Besonders, weil Hotmail nun gerade einer der Mailprovider ist, die sich jahrelang einen feuchten Dreck um Spam-Prävention gekümmert haben und nun heute – ähnlich wie zum Beispiel auch AOL – weitestgehend nach Gutsherrenart und nicht nachvollziehbaren Kriterien Hosts blockieren und es selbst versierten und verantwortungsbewussten Postmastern extrem schwer machen, für Abhilfe zu sorgen.

Ganz ehrlich? Ginge es hier nur um mich persönlich und nicht um noch einen Haufen Kunden, würde ich angesichts dieses Verhaltens schlicht sagen: Wenn Hotmail keine Mails mehr von mir will, dann ist das eben so. Das sagt letzten Endes mehr über Hotmail als über mich.

So werde ich aber nun mal gleich wieder meinen Kollegen in seinem Bestreben nach Klärung und ggf. temporären Workarounds unterstützen … und hoffen, dass dieses Trauerspiel ein schnelles Ende findet.

Update

Wir routen alle Mails an Hotmail jetzt erstmal über einen unserer Server, der in einem externen Rechenzentrum in einem ganz anderen IP-Netz steht. Als Workaround tut das erstmal, bis Hotmail sich zu einer Stellungnahme bequemt.

Update 2

Ui, fantastisch: Wenn man sich bei Microsoft ein bisschen umschaut, kann man unter Umständen tatsächlich den in einer riesigen Textwüste versteckten Link „To learn more about the Sender and ISP Services, go here“ finden (kleiner Tipp an Microsoft: Vielleicht mal die Einführung zu Links bei SELFHTML nachlesen, die anschaulich erklärt, warum man Links nicht mit Wörtern wie „hier“ beschriften sollte). Die Zielseite des Links verweist dann schließlich auf die Smart Network Data Services von Microsoft, wo man die Reputation „seiner“ IP-Adressen einsehen kann – nachdem man sich als für die betreffenden Netzbereiche zuständig registriert hat.

Das funktioniert so, dass man dort einen Netzbereich eingibt und SNDS dann schaut, ob die Reverse Lookups der IPs aus diesem Netzbereich alle in der gleichen Domain liegen, dann sind postmaster@ und abuse@ unter dieser Domain autorisiert; zusätzlich wird das Whois abgegrast. SNDS erklärt auch den Algorithmus:

The WHOIS approach queries global, regional, and national IP registrars, such as ARIN and APNIC, using the first IP in the range to find the most specific allocation record covering it. It then looks to make sure the range being requested isn’t larger than the record covers. If so, it authorizes any email addresses contained in the record.

Das ist natürlich prima, denn in unseren Netzbereichen stehe ich natürlich mitsamt E-Mail-Adresse drin. Also flugs den Vorgang gestartet – daraufhin findest SNDS sage und schreibe zwanzig E-Mail-Adressen, die sich als für diesen Netzbereich zuständig erklären können, darunter einige Adressen von Plus.line, unserem Uplink-Provider (was ja völlig okay ist) sowie eine ganze Reihe weiterer E-Mail-Adressen von Domains, die definitiv nicht uns gehören, die nicht auf IPs in unserem Netzbereich verweisen und die sowieso schon mal überhaupt nicht in den Whois-Einträgen unserer Netzbereiche stehen. Nur eine E-Mail-Adresse fehlt in der Liste: Meine. Also, nur damit hier keine Missverständnisse entstehen:

$ whois 82.98.87.192
[Querying whois.ripe.net]
[...]
inetnum:        82.98.87.192 - 82.98.87.255
netname:        JONASPASCHE-FFM-003
descr:          Jonas Pasche
descr:          Albert-Schweitzer-Strasse 2d, Mainz
country:        DE
admin-c:        JP55128-RIPE
tech-c:         PLN
status:         ASSIGNED PA
mnt-by:         PLUSLINE-MNT
source:         RIPE # Filtered
[...]
person:       Jonas Pasche
address:      Albert Schweizer Str. 2d
address:      55128 Mainz
phone:        +49 6131 90667 27
fax-no:       +49 6131 90667 28
e-mail:       mail@jonaspasche.de
nic-hdl:      JP55128-RIPE
mnt-by:       HGC-MNT
source:       RIPE # Filtered
[...]

Tja, soviel zur Auskunft, der Algorithmus „authorizes any email addresses contained in the record“ – schön wär’s. Netterweise bietet Microsoft die Möglichkeit, Probleme mit dem Algorithmus zu melden, aber nicht, ohne gleich anzumerken, dass er natürlich intensiv getestet wurde und dass das SNDS-Team auch so oder so keine manuellen Autorisierungen vornehmen kann:

Although this algorithm has undergone extensive testing, please report any issues, remembering of course to follow the feedback guidelines. Be aware that the SNDS team cannot manually adjust authorizations and will be unable to process any such requests.

Tja. Also hab ich dann mal ein Problem mit dem Algorithmus gemeldet. Und warte dann mal darauf, dass der Algorithmus in Ordnung gebracht wird, denn manuell wird ja nicht autorisiert. Damit ich dann, wenn ich mich möglicherweise irgendwann tatsächlich als für diesen Netzbereich zuständig autorisieren kann, zumindest einmal einsehen kann, was Hotmail möglicherweise gegen uns hat. Aber klar, mit einer Möglichkeit der Aufhebung der Sperrung ist das auch wiederum nicht verbunden, selbst wenn sich hierbei ein Problem zeigen sollte, das tatsächlich bei uns besteht und tatsächlich von uns behoben werden könnte. Insofern – warum mache ich mir die Mühe eigentlich …

Die Registrierung der Zuständigkeit für einzelne IP-Adressen aus unserem Netz ist übrigens kein Problem, sofern das Reverse Lookup irgendwie auf uns verweist, denn die postmaster– und abuse-Adressen betreuen wir bei unseren eigenen Domains ja durchaus selbst. Also habe ich mal zumindest einzelne IP-Adressen hinzugefügt. Ist es nicht beruhigend, dass SNDS freimütig zu allen manuell hinterlegten E-Mail-Adressen nur dieses hier zu sagen hat:

All of the specified IPs have normal status.

Nur ändert das leider nichts daran, dass weiterhin SMTP-Verbindungen auch von den IP-Adressen, von denen SNDS behauptet, sie hätten einen normalen Status, abgewiesen werden:

550 SC-001 Unfortunately, messages from $IP weren’t sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.

Ein wenig fühlt es sich an, als wäre ich in der Twilight Zone. Hoffentlich hat das bald ein Ende. Wir bleiben dran.

Update 3

Ein Facepalm jagt den nächsten. Über unseren Umleitungs-Workaround haben wir es tatsächlich geschafft, eine Mail an abuse@hotmail.com abzusetzen. Prompt trudelt ein Autoresponder ein, der sich mit den Worten

We wanted to thank you and let you know that your report has been received.

freundlich bedankt und darauf hinweist:

Please don’t reply to this message, because it is from an unmonitored email address.

Die fragliche Mail kommt … auch von abuse@hotmail.com. Unmonitored, was?

Update 4

07.03.2011, 12:30 Uhr

Okay, bei postmaster@hotmail.com sieht’s noch schlimmer aus. Hier kommt dann postwendend ein Autoresponder mit der freundlichen Nachricht:

postmaster@hotmail.com is an unmonitored account. If you need assistance, please consult our help pages or visit http://postmaster.live.com.

Hierzu kann ich nur RFC 2821 zitieren:

   Any system that includes an SMTP server supporting mail relaying or
   delivery MUST support the reserved mailbox "postmaster" as a case-
   insensitive local name. [...]
   SMTP systems are expected to make every reasonable effort to accept
   mail directed to Postmaster from any other system on the Internet.
   In extreme cases --such as to contain a denial of service attack or
   other breach of security-- an SMTP server may block mail directed to
   Postmaster.  However, such arrangements SHOULD be narrowly tailored
   so as to avoid blocking messages which are not part of such attacks.

Interessant ist in diesem Zusammenhang auch die Listing-Policy für postmaster.rfc-ignorant.org, die es ausdrücklich als Grund für ein Blacklisting ansieht, wenn Mails an den Postmaster mit einem Autoresponder beantwortet werden, der zum Ausdruck bringt, dass die Mail nicht von einem Menschen gelesen wird:

Further, if a postmaster address contains a „redirecting auto-acknowledgement“, such that it is obvious that the message will not be received by a human (as specified in the RFCs), that shall also be considered a listable offense.

Ah, sehr schön: Sie nehmen das auch ernst und führen hotmail.com tatsächlich auf ihrer Blacklist.

Unnötig zu sagen, dass es bisher weder auf unsere Anfrage an abuse@hotmail.com von Freitag Nachmittag eine Antwort gab, noch auf unsere Anfrage, wieso der SNDS-Algorithmus zwar völlig Fremden erlaubt, Details zum Mailverkehr unserer Netze einzusehen, aber nicht uns, obwohl wir als admin-c eingetragen sind. Und ebenso unnötig zu sagen, dass für die IP-Adressen, die wir manuell autorisiert haben, auch weiterhin „All of the specified IPs have normal status“ angegeben wird. Die fragliche Seite trägt zwar den Hinweis „This data is updated once a day, not real-time so it may not reflect the current state of the system“, aber nachdem das Blacklisting nun schon stolze drei Tage andauert, kann man auch das nicht mehr als Ausrede gelten lassen.

Also, nur um das nochmal festzuhalten: Wir kriegen alle unsere Netze komplett gesperrt, ohne je auch nur eine Abuse-Message erhalten zu haben; wir können SNDS aufgrund eines Fehlers im Algorithmus nicht für unsere Netze nutzen; für einzelne IP-Adressen gibt SNDS faktisch falsche Auskünfte und disqualifiziert sich damit im Grunde; Hotmail erwartet, dass wir zum Debugging Datenschutzverletzungen mit Kundenmails begehen; es gibt keine RFC-konforme Postmaster-Adresse; Mails an abuse@hotmail.com werden nicht beantwortet; Mails an msn-snds@microsoft.com werden nicht beantwortet.

Well done, Microsoft.

Update 5

09.03.2011, 11:38 Uhr

Es ist ja nicht so, dass wir nicht zumindest versucht hätten, das absurd lange Beschwerdeformular nach bestem Wissen und Gewissen auszufüllen und alle Fragen höflichst zu beantworten; im schlechtesten Fall zumindest mit „Wir sind selbst ISP; Frage trifft nicht zu“. Nach dem Absenden haben wir eine Ticketnummer erhalten sowie den Hinweis:

Um sicherzustellen, dass Sie die Antwort von Microsoft erhalten, fügen Sie Ihrer „Sicherungsliste“ für E-Mails die Domäne „microsoft.com“ hinzu. Geht in Ihrem „Posteingang“ innerhalb von 24 Stunden keine Antwort ein, überprüfen Sie die Ordner „Massensendungen“ oder „Junk-E-Mail“.

Zunächst einmal: Ich habe zwar schon etliche Mailserver administriert, sendmail, qmail, postfix, exim … und habe aber dennoch keine Vorstellung, was Hotmail mit einer „Sicherungsliste“ meinen könnte. Offenbar eine Art Whitelist. Aber davon abgesehen:

Hände rauf, wer überrascht ist – die 24 Stunden sind mittlerweile lange um, und natürlich gab es keinerlei Reaktion von Hotmail. Das wirft dann nebenbei auch die Frage auf: Was bitte soll ich mit der Ticketnummer? Es gibt ja keine einzige andere Kontaktmöglichkeit – keine Postmaster-Adresse, keine allgemeine Support-Adresse, auch keine telefonische Hotline; man kann sich auf den Kopf stellen: Alles wird letztlich auf irgendwelche Formulare umgeleitet.

Ist das nicht der Witz schlechthin – mit einem der größten E-Mail-Provider weltweit … kann man nicht per E-Mail kommunizieren.

Sollte tatsächlich irgendwann mal doch noch eine Antwort auf unsere Beschwerde kommen, gehe ich jede Wette ein, dass der Absender vermutlich donotreply@hotmail.com heißen wird und sich in der Mail ein Hinweis finden wird, dass man nicht antworten kann, sondern bitte das Formular unter der folgenden URL ausfüllen möge … (Anekdote am Rande: Bei Ryanair ist das noch viel schlimmer. Dort gibt’s für Beschwerden nicht mal ein Online-Formular. Man muss sich per Fax beschweren, an eine Faxnummer in Irland. Und dabei … eine E-Mail-Adresse angeben. Die Antwort von Ryanair folgt dann per E-Mail – von einer Adresse aus, an die man nicht antworten kann, und mit dem Hinweis, dass, wenn man noch etwas antworten möchte, die E-Mail bitte ausdrucken und zusammen mit seiner Antwort wieder nach Irland faxen möge.)

Wir haben nun erstmal das Beschwerdeformular ein weiteres Mal ausgefüllt, ebenso gewissenhaft, diesmal auf Englisch (das Formular ist auf Deutsch, deshalb hatten wir es beim ersten Versuch auch auf Deutsch ausgefüllt). Und haben dabei auch mal die Ticketnummer erwähnt, die wir bereits erhalten haben. Die Hoffnung stirbt ja bekanntlich zuletzt.

Update 6

10.03.2011, 14:40 Uhr

Holy crap! Wir sind noch zurückhaltend mit Luftsprüngen, aber nachdem wir es jetzt von einigen Hosts aus getestet haben, macht es ganz den Eindruck, als sei die Sperrung aufgehoben. Zurückhaltend sind wir vor allem deshalb, weil wir auch weiterhin (auch über 24 Stunden nach dem zweiten Ausfüllen des Formulars) keinerlei Rückmeldung erhalten haben, also auch nicht unter der von uns extra dafür angelegten Hotmail-Adresse. Wir wissen also nicht nur nicht, warum wir eigentlich gesperrt worden sind; wir wissen auch nicht, warum es jetzt wieder geht – ob da jemand tatsächlich unsere Anfrage gelesen und bearbeitet hat oder ob das alles nur ein bedauerliches Missverständnis war, oder ob schlicht die Sperrung automatisiert nach einer definierten Zeit zurückgenommen wurde und jederzeit wieder erfolgen kann.

Was auch weiterhin nicht funktioniert, ist eine Authentifizierung für unsere IP-Netze bei SNDS (und wer nicht das ganze Blog liest, sondern nur dieses eine Posting hier, möchte vielleicht einen kurzen Blick auf SNDS werfen). Da werden wir gegenüber Hotmail noch dranbleiben müssen.

Für heute können wir uns jetzt aber erstmal einen Moment zurücklehnen und uns den Schweiß von der Stirn wischen … waren ja nur sechs Tage, die Hotmail begründungslos den Mailverkehr aller unserer Kunden abgeklemmt hat.

In der Plesk-Hölle: qmail-smtpd, SSL … und spamdyke

Dienstag, 27. Juli 2010

Wenn man etwas weiter hinter die Kulissen schaut, findet man manchmal ganz erstaunliche Dinge. Heute soll es mal um verschlüsseltes SMTP mit dem qmail-Paket von Plesk gehen. Für Verschlüsselung gibt es, um das ganz kurz zu erläutern, zwei Verfahren: TLS und SSL. TLS bedeutet: Man verbindet sich mit dem unverschlüsselten Port (normalerweise 25), der Server annonciert, dass er STARTTLS beherrscht, der Client sendet jenes STARTTLS, und die Verbindung ist verschlüsselt. Alternativ benutzt man SSL: Hier stellt der Server einen separaten Port bereit (normalerweise 465), auf dem dann direkt eine verschlüsselte Verbindung entgegengenommen wird.

Der aufmerksame Leser wird bereits eins ahnen: SSL über einen separaten Port kann man in der Art eines Wrappers um beliebige Dienste „drumherumstricken“, z.B. mit stunnel oder ucspi-ssl, ohne dass man den Dienst selbst anpassen muss. Dass ein Dienst hingegen ein Schlüsselwort wie STARTTLS versteht und daraufhin die Verschlüsselung einschaltet – da dürfte auf der Hand liegen, dass das nur mit einem Patch geht. Für qmail gibt es dafür seit langem einen etablierten Patch von Frederik Vermeulen, der (unter anderem) qmail-smtpd beibringt, auf STARTTLS zu reagieren. Im Vorbeigehen unterstützt er auch noch die traditionelle Variante mit dem separaten Port – ganz ohne Wrapper: Es reicht aus, die Umgebungsvariable SMTPS zu setzen, bevor qmail-smtpd aufgerufen wird, und das war’s.

Nun schauen wir uns mal an, wie das bei Plesk aussieht. Ich habe die Konfigurationsdateien jeweils auf das Wesentliche gekürzt, also bitte nicht wundern. Erstmal für den Standard-SMTP-Port 25:

# cat /etc/xinetd.d/smtp_psa
service smtp
{
  [...]
  server      = /var/qmail/bin/tcp-env
  server_args = /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd [...]
}

… und schließlich für den Standard-SMTPS-Port 465:

# cat /etc/xinetd.d/smtps_psa
service smtps
{
  [...]
  server      = /var/qmail/bin/tcp-env
  server_args = /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd [...]
}

Der xinetd erkennt an der service-Bezeichnung den numerischen Port, in dem er ihn über /etc/services auflöst. So weit, so gut.

Nun stellt sich aber doch eine Frage: Woher weiß qmail-smtpd im zweiten Fall denn, dass es bitte SSL sprechen möge und nicht Plaintext? Plesk arbeitet hier genauso mit dem etablierten TLS-Patch, der eigentlich verlangt, dass die Umgebungsvariable SMTPS gesetzt sein muss. Die wird hier aber doch gar nicht gesetzt..?!

Des Rätsels Lösung ist, dass Plesk hier ganz gewaltig trickst. Nicht etwa, dass es ein Leichtes gewesen wäre, in der /etc/xinet.d/smtpd_psa kurzerhand env = SMTPS=1 einzutragen: Nein, das wäre doch viel zu nachvollziehbar gewesen.

Stattdessen patcht Plesk. Und patcht. Und patcht. Details dazu finden sich in der Plesk-Knowledgebase. Wir schnappen uns das erste der Patche-Archive und schauen mal rein. Darin findet sich ein Haufen Patches mit so klangvollen Namen wie patch-pb, patch-pe oder auch patch-ps. Oder, und darum geht’s: patch-pu-tls. Darin steckt so eine Art Variante des etablierten qmail-TLS-Patches, „natürlich“ bereinigt um jegliche Kommentare oder Dokumentation. Und ganz am Ende, da findet sich plötzlich ein Teil, den es im Original nicht gibt, nämlich diesen hier:

--- ./tcp-env.c.orig    Thu Feb 20 11:33:43 2003
+++ ./tcp-env.c Thu Feb 20 11:37:05 2003
@@ -70,6 +70,9 @@
    temp[fmt_ulong(temp,localport)] = 0;
    if (!env_put2("TCPLOCALPORT",temp)) die();
 
+   if (localport == 465)
+      if (!env_put2("SMTPS","true")) die();
+
    byte_copy(&iplocal,4,&salocal.sin_addr);
    temp[ip_fmt(temp,&iplocal)] = 0;
    if (!env_put2("TCPLOCALIP",temp)) die();

Dass qmail-smtpd unter Plesk also auf „magische“ Weise plötzlich SSL spricht, liegt daran, dass das vorgeschaltete tcp-env die Variable SMTPS kurzerhand setzt, sobald es feststellt: Oh, ich laufe unter Port 465! Unnötig zu sagen, dass Plesk die man page von tcp-env nicht angerührt hat – die verrät von diesem Verhalten nichts. Da muss man sich dann auch nicht wundern, wenn in Foren Fragen wie diese auftauchen – und unbeantwortet bleiben (Hand aufs Herz, die Frage ist von 2007, und in dem Forum müsste ich mich auch erstmal registrieren, um antworten zu können):

When i copy smtps_psa to another port / service, SSL does not work. Is SSL hard-coded somewhere in Plesk’s qmail ? For instance : i would like to run smtps on port 665

Aber nun gut, lassen wir das für einen Moment so stehen und wenden uns dem Thema zu, das mich erst auf diese ganze Thematik gebracht hat, und das für mich vor allem deshalb so ein „Aufreger“ ist, weil es dazu Howtos über Howtos gibt und praktisch alle in puncto SSL falsch sind – wahrscheinlich schreiben alle voneinander ab. Hier findet sich in zig Howtos der Hinweis, dass Spamdyke auf Plesk-Systemen in /etc/xinetd.d/smtp_psa und /etc/xinetd.d/smtps_psa eingetragen werden muss. Das ist so auch nicht ganz falsch – allerdings geben fast alle Howtos an, dass man dort das Gleiche eintragen soll; viele liefern sogar konkrete Konfigurationsbeispiele, die aber vor Veröffentlichung definitiv nie getestet worden sein können. Dann hätte nämlich auffallen müssen, dass sie in der Realität überhaupt nicht funktionieren – nicht mit SSL.

Und so finden wir falsche Howtos im offiziellen Plesk-Forum, im inoffiziellen Plesk-Forum, im Serversupport-Forum, nochmal dort, im Howto des RootForums, in der Anleitung von huschi.net, bei Blue Orix oder bei Haggybear, um nur eine kleine Auswahl an Quellen zu nennen. Hier und da (aber Ausnahmen bestätigen ja bekanntlich die Regel) findet sich auch jemand, der es richtig macht, zum Beispiel The BOFH. Andere kriegen es auch hin, so wie Alexander Koch, wenngleich auf ganz andere Weise (nämlich, in dem gar nicht von der SMTPS-Funktionalität Gebrauch gemacht wird, sondern in dem stunnel als Wrapper eingesetzt wird – was aber fraglos auch eine legitime Lösung ist, nur eben eine aufwendige).

Im Endeffekt laufen alle Howtos darauf hinaus, dass man spamdyke vor den Aufruf von qmail-smtpd setzen soll. Aus

server_args = [...] /var/qmail/bin/qmail-smtpd [...]

soll also werden:

server_args = [...] /usr/local/bin/spamdyke -f /etc/spamdyke.conf \
              /var/qmail/bin/qmail-smtpd [...]

Und genau da liegt der Knackpunkt. Die TCP-Verbindung kommt jetzt ja nun nicht mehr bei qmail-smtpd an, sondern bei spamdyke. Und so schön und gut es auch ist, dass qmail-smtpd eine Umgebungsvariable namens SMTPS interpretiert, und so tricky und gruselig es ist auch ist, dass Plesks tcp-env diese Umgebungsvariable heimlich setzt: spamdyke hat deswegen noch lange keine Ahnung davon – und spricht deshalb auch auf Port 465 schlicht und einfach Plaintext. Warum um alles in der Welt sollte es auch etwas anderes tun?

Praktischerweise kann man spamdyke sagen, dass es SSL sprechen soll. Nämlich, in dem man tls-level=smtps setzt anstelle des Defaults tls-level=smtp. Nur tut das keins der oben genannten Howtos! Es kann also überhaupt nicht funktionieren.

Die Abhilfe ist dann letztlich trivial. Entweder man legt sich eine zweite Konfigurationsdatei für spamdyke an, zum Beispiel eine spamdyke-smtps.conf, die eine Kopie des Originals ist, aber tls-level=smtps beinhaltet. In der xinetd-Konfiguration sieht das dann so aus:

# cat /etc/xinetd.d/smtps_psa
service smtps
{
  [...]
  server      = /var/qmail/bin/tcp-env
  server_args = /var/qmail/bin/relaylock \
                /usr/local/bin/spamdyke -f /etc/spamdyke-smtps.conf \
                /var/qmail/bin/qmail-smtpd [...]
}

Oder man hat verständlicherweise keine Lust, eine zweite Konfigurationsdatei zu pflegen, und setzt die Angabe direkt als Parameter mit in den Programmaufruf ein:

# cat /etc/xinetd.d/smtps_psa
service smtps
{
  [...]
  server      = /var/qmail/bin/tcp-env
  server_args = /var/qmail/bin/relaylock \
                /usr/local/bin/spamdyke -f /etc/spamdyke.conf --tls-level=smtps \
                /var/qmail/bin/qmail-smtpd [...]
}

So, und damit wir jetzt zum Schluss alle nochmal herzhaft lachen können:

Alle, wir alle inklusive mir, hätten eigentlich nur die ganz offizielle INSTALL.txt von spamdyke lesen müssen. Dort lesen wir schnöde vier Zeilen:

   Plesk users can also use spamdyke for their SMTPS connections by adding it to
   the /etc/xinetd.d/smtps_psa file.  spamdyke's configuration in that file will
   need to include the options "tls-level" (set to "smtps") and
   "tls-certificate-file".

Das wär’s auch schon gewesen. Aber andererseits: Ansonsten wäre ich nie darauf gekommen, wie Plesk das mit dem SSL eigentlich macht. Insofern hat sich’s doch gelohnt …


Impressum