Bugs und Verbesserungsvorschläge für GMX

Ich habe einen Account bei Global Mail Exchange. Mit diesem hatte ich schon mehrfach technische Probleme, die in meiner Sicht von Unzulänglichkeiten der Server-Implementierung herrühren, und die ich im Folgenden beschreiben werde. Überwiegend wurden diese Probleme bis heute nicht gelöst.

Fehlerhaftes > in Zeilen die mit from beginnen

Mails, die über GMX empfangen werden, bekommen in allen Zeilen, die mit dem Wort from beginnen, unabhängig von Groß-Klein-Schreibung, ein > vorangestellt. Das irritiert beim Lesen, und zerstört digitale Signaturen. Es gibt zwar Speicherformate, die zumindest für Zeilen beginnend mit From  in genau dieser Schreibweise ein solches Escaping erforderlich machen, aber das betrifft nur die Speicherung und sollte bei der Weitervermittlung wieder rückgängig gemacht werden.

Das Problem ist als ID[|#1695324880#5134788#5bc0175#|] bei GMX aufgenommen worden. Ich habe später eine Mail mit der mir neuen ID[|#1695324880#5272077#5b6016f#|] bekommen, die ein nicht näher beschriebenes Problem als keine Technische Lösung möglich bezeichnet hat. Aus dem Zeitlichen Zusammenhang muss ich annehmen, dass diese Mail zu dem hier beschriebenen Problem gehört, auch wenn ich eine entsprechende Rückfrage nie beantwortet bekommen habe.

SMTP: ESMTPA-Kennzeichnung zur besseren Unterscheidung von Spam

Spamerkennungssysteme wie SpamAssassin untersuchen, von wo eine Mail geschickt wurde, und behandeln in der Standardeinstellung Mails von privaten Internetverbindungen mit dynamischen IP-Adressen leichter als Spam als Mails von bekannten Mailservern. Mails, die von angemeldeten GMX-Kunden kommen, sollten in diesem Sinne als vom GMX-Server stammend behandelt werden. Das Problem dabei ist, dass der GMX-Server die Tatsache, dass er den Kunden Authentifiziert hat, zwar in einem Header namens X-Authenticated vermerkt, dieser aber leicht zu fälschen ist und von SpamAssassin gar nicht behandelt wird.

SpanAssassin hingegen schaut genauer auf den Received-Header. Wenn dort with ESMTPA (Extended Simple Mail Transfer Protocol Authenticated) steht, dann wird dieser Server als verantwortlicher Absender gehandhabt, und dynamische IP-Adressen auf dem Weg zu diesem Server spielen keine Rolle mehr. Unglücklicher Weise kennzeichnet GMX seine Mails nur als with SMTP.

Man sollte meinen, dass das Hinzufügen von zwei Buchstaben zu einem String nicht so schwer ist, und dass die Server auch wissen, ob der Benutzer sich authentifiziert hat oder nicht. Als ID[|#1695324880#4311007#5850161#|] wurde das Problem an die Technik weitergeleitet, und dort dann als ID[|#1695324880#4468943#5df0177#|] abgelehnt, da der SpamAssassin, bei dem die Mail dann aufgrund dieses Problems aussortiert wird, nicht ihr eigener ist.

SMTP: Mailadresse bei Fehlermeldung 5.1.2 nennen

Wenn man eine Mail an eine längere Liste von Empfängern schickt, und einer von diesen einen falschen Domainnamen enthält, bekommt man von GMX die Meldung 550 5.1.2 Cannot resolve your domain. Welche der vielen Adressen damit gemeint ist, muss einem entweder das eigene Mailprogramm verraten, oder man muss von Hand das Überprüfen oder Ausprobieren anfangen. Bei einer vergleichbaren Meldung für ungültige Empfänger mit GMX-Adresse schickt der Server in der entsprechenden Fehlermeldung den Namen der ungültigen Adresse mit, so dass man sofort weiß, wo das Problem liegt.

Das Problem wurde bei GMX als ID[|#1695324880#6391657#5d70176#|] aufgenommen. Ich habe zwei Mails dazu bekommen, die beide in meinen Augen überhaupt nichts mit meiner Anfrage zu tun hatten. Statt dessen habe ich das Problem in meinem Mailprogramm, Mozilla Thunderbird, gelöst.

POP3: Verbindungsabbruch bei gescheiterter Authentifizierung (behoben)

Bei Eingabe eines falschen Passworts mit dem AUTH-Befehl und einem erneuten Versuch mit dem älteren USER-Befehl hat der Server direkt nach Erhalt des USER-Befehls die Verbindung abzubrechen, statt nach einem Passwort zu fragen und dann eine Meldung auszugeben, wenn dies wieder nicht stimmt. Dieses Problem hat zusammen mit einem Bug in Thunderbird dazu geführt, dass bei falschem Passwort keine Fehlermeldung angezeigt wurde.

Dieses Problem wurde von GMX behoben, und sogar einen Dank für die gute Fehlerbeschreibung habe ich bekommen.