Spam nervt und es ist nur zu verständlich, wenn ein Mailserver-Administrator versucht sicherzustellen, dass seine Kunden möglichst wenig Spam erhalten und vor allem, dass seine Server nicht zu Spamschleudern werden. Doch was GMX und, da die selbe Infrastruktur genutzt wird, vermutlich auch web.de betreiben, grenzt schon ans Absurde.
Einer unserer Kunden arbeitet zur Zeit in Marokko und nutzt einen GMX-Account für seine E-Mails. Sein dortiger Provider weist zumindest nicht bei jeder DSL-Einwahl eine neue IP-Adresse zu, ob ggf. mit konstanten IP-Adressen gearbeitet wird, kann nicht festgestellt werden. Vor zwei Tagen rief der Kunde bei uns an, er könne zwar nachwievor Mails über GMX empfangen, aber beim Versenden aus seinem Outlook käme eine Fehlermeldung, er sei blacklisted und fragte uns, was dort passiert sei.
Nun ist das Blacklisting von IP-Adressen, die als Spamschleudern arbeiten eine legitime Methode der Spamvermeidung – aber dieses Verfahren wird normalerweise nur bei unauthentifizierter Maileinlieferung, also „Mailserver zu Mailserver“ angewandt und nicht bei der Anbindung von Clients, also SMTP-Auth. Um Clients verlässlich von Mailservern unterscheiden zu können, wurde ja ein zweiter SMTP-Port (587/TCP) definiert, der von Servern, die den Port 25 nutzen, nicht genutzt wird. Doch was macht GMX: Dort wird sowohl auf Port 25 als auch auf Port 587 zuerst die IP-Adresse geprüft und erst danach, wenn die IP-Adresse zugelassen wird, ein SMTP-Auth ermöglicht. Das führt dazu, dass ein Benutzer keinerlei Möglichkeit mehr hat, über sein Mailprogramm E-Mails über seinen GMX-Account zu versenden. Man kann hierzu nur sagen: Schlecht umgesetzt.
Bei unserem Kunden kann vermutet werden, dass vermutlich nicht seine einzelne IP-Adresse gesperrt worden ist, sondern vermutlich ein ganzer IP-Bereich, ggf. der gesamte Provider, da sein Rechner als Spamquelle ausgeschlossen werden konnte.
Wie konnten wir dem Kunden nun helfen: Um dem Kunden zu helfen, mussten wir die ausgehenden Mails über einen unserer Rechner routen, so dass sich dann unser Rechner mit den SMTP-Accountdaten des Kunden bei GMX für den SMTP-Mailversand anmeldet. Der Kunde meldet sich also bei einem unserer Mailserver an und liefert seine Mails bei uns ab. Unser Mailserver liefert diese Mails dann aber nicht direkt an den Empfänger aus, sondern meldet sich beim GMX-Mailserver mit den Kundendaten an und nutzt dann den GMX-Mailserver für diese Kundenmails als SMTP-Relay.
Doch warum so kompliziert, warum liefern wir die Mails nicht direkt an die Empfänger aus? Der Grund ist relativ einfach: Ebenfalls zur Spamvermeidung prüfen viele Empfänger-Mailserver, ob der Absendermailserver E-Mails vom behaupteten Absender annehmen würden. Da unser Mailserver jedoch für GMX nicht zuständig ist, würde er einen solchen Versuch ablehnen. Der Empfängermailserver würde also die Mails als Spam ablehnen.
In dem Zusammenhang konnten wir auch feststellen, dass GMX auch bei SMTP-Auth nicht jede Mail annimmt. GMX verlangt, dass der FROM-Header dem SMTP-Auth-Anmeldenamen entspricht.
Wir haben bei GMX nachgefragt, warum die IP-Adresse des Kunden auf der GMX-Blacklist steht und was der Kunde machen soll, eine Antwort steht noch aus.
Traurig: GMX hat sich bis heute weder bei unserem Kunden noch bei uns auf die Nachfrage gemeldet. Was machen Anwender, die auf ihre E-Mails bei GMX angewiesen sind? Nach diesen Erfahrungen können wir zumindest Zeit von GMX nur abraten. Falls sich GMX doch noch melden sollte, werden wir dies selbstverständich ebenfalls hier veröffentlichen.