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.
Iich verstehe nicht, warum gerade die Google,-Leute die doch sonst so viel von OSS halten, eine solche Haltung an den Tag legen. Als OpenSource-Projekt sollte man immer froh sein, wenn andere Leute Patches einsenden, auch wenn man selbst die Entwicklung hinter verschlossenen Türen voranbringt.
Naja, ich nutze den Mail-Client von Google nicht und kann nur hoffen, dass K-9-Mail eine Eigenimplementierung des SMTP-Stacks mitbringt. Das ist ja wohl absolut lächerlich.
@Janek
Wenn ich die richtige Source-Datei von k9mail gefunden habe, scheint das der Fall zu sein. Es wird lediglich auf „STARTTLS“ (ohne Leerzeichen oder Bindestrich) geprüft.
Siehe http://code.google.com/p/k9mail/source/browse/k9mail/trunk/src/com/fsck/k9/mail/transport/SmtpTransport.java (Zeile 242)
Wenn man sich das zugehoerige Git Repository ansieht, sieht man das es 2010 gefixt worden ist aber ein Merge den Fix anscheinend wieder zunicht gemacht hat. Im Feb 2012 wurde es wieder gefixt und es ist im Master Branch dabei (voraussichtlich Android 4.0.5).
Ah, das ist wirklich interessant. Hand aufs Herz, ich bin an sich wirklich versiert damit, mir irgendwo Code von Open-Source-Projekten anzuschauen, durch Branches zu browsen, aber wie man von source.android.com irgendwo hin kommt, wo man dann vielleicht auch mal einfach durch den Code browsen kann, ohne sich erst das
repo
-Tool besorgen zu müssen und dann den gesamten Sourcetree klonen zu müssen, hat sich mir zumindest nicht intuitiv erschlossen. Gute Erklärung jedenfalls, wieso es nicht mal mit meinem frisch auf Android 4.0.4 geflashten „Smart“phone funktioniert.Die Email-App hat noch andere Bugs, so enthält die Kommandozeile beim Senden Leerzeichen an unpassender Stelle („MAIL FROM: „), obwohl der aktuelle RfC explizit sagt das nach dem Doppelpunkt keins zu kommen hat. Und wer keine Patches ohne Gerrit haben will…
Nach welchen Kriterien Google Bugs fix-t erscheint mir auch sehr undurchsichtig. Da ziehen sich teilweise sehr triviale Fehler seit den Anfängen Androids durch den Code und hunderte Entwickler machen darauf aufmerksam und bieten Patches an. Aus irgendwelchen (vielleicht leicht elitären?) Gründen wird das extrem stiefmütterlich behandelt.
Böse Zungen könnten natürlich behaupten, solange der Mailclient mit Google Mail harmoniert, kann der Bug ja nicht so kritisch sein … 😉
@Code browsen: Imo gibt es keine offiziele Moeglichkeit den Code zu browsen man findet aber einige Mirrors die das anbieten: https://github.com/android/
Hi Jonas,
danke für den Blog, immerwieder super Beiträge, leider in zu geringer Frequenz. Passiert zu wenig 😉 Was ist denn eine von dir genutzte „“smart“phone“ alternative?
Grüsse,
Marcus
@Marcus: Ich habe da keine Alternative. Mein Telefon hat noch Tasten, die man drücken kann. Mit Ziffern drauf. Ich hab nur mal am Wochenende ein bisschen mit einem gebrauchten Smartphone rumgespielt, das ich mit Android 4.0 versorgt hab, aber wirklich überzeugt hat mich das nicht. Ich hab irgendwie einfach keine Verwendung für ein Smartphone.
Zur Blog-Frequenz: Ich blogge lieber selten, und dann Dinge, die mich auch selbst interessieren würden, in einem Stil, den ich selbst gerne lesen würde, als in höherer Frequenz durchschnittlichere Posts rauszuhauen. So ein Blogpost wie dieser hier schreibt sich ja auch nicht in einer Viertelstunde, ganz abgesehen von dem Aufwand, der dem Blogpost vorausgegangen ist. Das geht einfach nicht jeden Tag; dafür ist Bloggen zu wenig mein Hauptberuf. 😉
Moin Jonas,
auch hier nochmal einen herzlichen Dank für deinen Einsatz! Manchmal liegen Fehler halt doch in blöden Kleinigkeiten!
Viele Grüße
Johannes
@ Jonas Pasche: Und was hältst du als Linux-Erfahrener Sysadmin von Android so als ganzes? Also sowohl als OS als für Smartphone wie auch Tablet?
Was meinst du so zur „Sicherheit“ von Android?
Interessiert mich mal deine Meinung dazu, weil immerhin halte ich schon große Stücke von und zu Uberspace! 😉
Danke für die Blumen. Speziell zu Android kann ich aber zugegebenermaßen so gut wie gar nichts Kompetentes sagen – meine Erfahrungen damit belaufen sich auf „Device rooten“, „mal ein Image flashen“ und ein bisschen mit der Oberfläche rumzuspielen; festzustellen, dass es mich nicht die Bohne reizt, mich eingehender damit zu beschäftigen, und es dann nach wenigen Tagen wieder gelangweilt wegzulegen. Aus der Perspektive eines Sysadmins kann ich dazu absolut gar nichts dazu sagen, was über nachgeplappertes Halbwissen hinausginge, und da ist es dann aufrichtiger, lieber zu schweigen.
Ehre wem Ehre gebührt. 🙂
Na wenigstens hast du schon das „Rooten des Device“ gemacht, wovon ich bisweilen noch die Finger lasse aus Sorge mir mein Galaxy Note damit kaputt zu machen.
Ich hätte es sicher nicht gemacht – gerade als Anfänger in dem Bereich – wenn’s nicht um ein älteres (nicht von mir) gebrauchtes Gerät gegangen wäre, dass hier eh nur rumgelegen hat. 😉
Ach, aber Outlook haben wir doch auch schon mit „AUTH=PLAIN LOGIN“ statt „AUTH PLAIN LOGIN“ glücklich machen müssen. SMTP is hard, let’s go shopping…
Ich hab mir im Dez ein Galaxy III geleistet. Ich wurde und werde immer wieder nach Mobilversionen und Apps für unsers Software gefragt, und war da einfach komplett blank.
Also Sprung ins kalte Wasser. Kleiner ging nicht (wg. Tippen mit den Wurstfingern) größer (Galaxy Note)
Vorausschicken sollte ich, dass eine Handy bei mir ca 5 Jahre hält und dass es für mich ein Telefon ist. So Empfangsschwächen wie beim iPhone4 würde ich nicht dulden.
Mein vorheriges Telefon war ein Samsung E1080 (Mit Tasten! Und Ziffern!), an dem mich nur 2 Sachen stören:
– ich vergesse immer wo das Netzteil ist, wenn ich es nach 2 Wochen mal wieder aufladen muss.
– es mit Adressdaten zu füllen, is a royal PITA.
Wenn man ein Galaxy und dazu alle Produkte aus der Googlewelt nutzt dann funktioniert das einigermaßen. Der Rest ist über weite Strecken einfach nur BÄH, mit Fremdschämsosse.
– die Dockingstation funktioniert unter Windows, unter Linux nicht
– mit DHCP kannst einen Heiden“spass“ haben,
– schon zum Hostnamen setzen müsste man es rooten.
– imap und smtp, wie hier beschrieben, ein Heidenspaß
– ein Großteil meines Datentransfers sind Updates für Sachen, die ich nicht brauche, nicht will und nicht herunterwerfen kann
– weil sich die ganzen Apps immer gegenseitig am Schlafen hindern, ist das Ding nach 18 h Nichtbenutzung leer, wenn ich alles einschalte, ohne BT, WLAN, GPS, etc (also funktional gleichwertig zum E1080) hält es 2.5 Tage.
Fortschritt?
Ich sehe wohl, was man mit solcher Technik alles nützliches machen kann, aber auch dass das alles zu instabil ist um sich davon abhängig zu machen. Zumal die Behörden sich in Zukunft diese Dinger einfach greifen und in Forensikautomaten einspannen, genauso wie es schon reihenweise Gentest-Rasterfahndungen gibt, einziges Kriterium: Mann in einem gewissen Einzugsgebiet um Tatorte.
Das ist schade, denn so wird ein Smartphone zum single point of failure und zum Risiko.
P.S.: ich hatte die zweifelhafte Ehre letzte Woche den Notruf zu betätigen. Draussen war es kalt, und der Adrenalinschub tat ein weiteres: mit solchermaßen taktil eingeschränkten Fingern ist das Ding fast nicht zu bedienen. Mit dem E1080 geht das b-l-i-n-d!
P.P.S: Bei mir wird es auf Android-Pad und bar-type Mobiltelephon hinauslaufen. KISS principle und „do one thing and do it well“ und so.
Was ich mich frage:
Ist denn eigentlich
„if (result.contains(„-STARTTLS“) || result.contains(“ STARTTLS“)) {“
die korrekte Methode?
Was macht man wenn die Antwort des Servers das folgende ist:
EHLO x@y.com
250-blabla
250-this server does not support STARTTLS
250 X-NOTHING
Eigentlich würde ich ja erwarten, dass man die Antwort-Strings irgendwie vernünftig zerlegt und überprüft. Oder ist das Wort „STARTTLS“ so reserviert, dass es immer und ausschließlich in diesem Kontext verwendet werden kann?
Ich hab auch eine Zweigerätestrategie: ein klassisches Natel zum Telephonieren und, wenns hoch kommt, mal eine SMS schreiben… sowie zur Zeit drei(!) Geräte, die sich eine Daten-SIM (100 MB flat schnell, danach flat langsam) teilen: ein USB-UMTS-Surfstick (der out-of-the-box mit MirBSD tut), ein PocketPC (Windows Mobile 6.x, IMHO das aktuell beste „Smartphone“-OS), mit Stift! und benutzbarer Tastatur! zum Geocachen, und ein geliehenes HTC Vision für Ingress (furchtbare Erfahrung, Android käme mir privat auch nicht in die Tasche, und es hat keinen Stift, und Multitouch ist noch schlimmer als vorher vermutet)