Spam nervt und es ist nur zu verst\u00e4ndlich, wenn ein Mailserver-Administrator versucht sicherzustellen, dass seine Kunden m\u00f6glichst 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.<\/p>\n
Einer unserer Kunden arbeitet zur Zeit in Marokko und nutzt einen GMX-Account f\u00fcr 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\u00f6nne zwar nachwievor Mails \u00fcber GMX empfangen, aber beim Versenden aus seinem Outlook k\u00e4me eine Fehlermeldung, er sei blacklisted und fragte uns, was dort passiert sei.<\/p>\n
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\u00e4sslich von Mailservern unterscheiden zu k\u00f6nnen, 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\u00fcft und erst danach, wenn die IP-Adresse zugelassen wird, ein SMTP-Auth erm\u00f6glicht. Das f\u00fchrt dazu, dass ein Benutzer keinerlei M\u00f6glichkeit mehr hat, \u00fcber sein Mailprogramm E-Mails \u00fcber seinen GMX-Account zu versenden. Man kann hierzu nur sagen: Schlecht umgesetzt.<\/p>\n
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.<\/p>\n
Wie konnten wir dem Kunden nun helfen: Um dem Kunden zu helfen, mussten wir die ausgehenden Mails \u00fcber einen unserer Rechner routen, so dass sich dann unser Rechner mit den SMTP-Accountdaten des Kunden bei GMX f\u00fcr 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\u00e4nger aus, sondern meldet sich beim GMX-Mailserver mit den Kundendaten an und nutzt dann den GMX-Mailserver f\u00fcr diese Kundenmails als SMTP-Relay.<\/p>\n
Doch warum so kompliziert, warum liefern wir die Mails nicht direkt an die Empf\u00e4nger aus? Der Grund ist relativ einfach: Ebenfalls zur Spamvermeidung pr\u00fcfen viele Empf\u00e4nger-Mailserver, ob der Absendermailserver E-Mails vom behaupteten Absender annehmen w\u00fcrden. Da unser Mailserver jedoch f\u00fcr GMX nicht zust\u00e4ndig ist, w\u00fcrde er einen solchen Versuch ablehnen. Der Empf\u00e4ngermailserver w\u00fcrde also die Mails als Spam ablehnen.<\/p>\n
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.<\/p>\n
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.
\n