Artikel mit ‘android’ 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.


Impressum