Kategorie: Tipps

Beinahe täglich erhalten wir von Kunden E-Mails mit sinngemäß folgendem Inhalt:

• Meine Mail von gestern ist noch immer nicht beim Empfänger ankommen, was ist da los?
• Warum steht der Variomedia-Mailserver bei Provider XY auf der Blacklist?
• Ich habe die Zugangsdaten für meine neue Domain nicht bekommen, warum dauert das so lange?

In all diesen Fällen sind schlecht konfigurierte Spamfilter anderer Provider als Ursache anzusehen.

Wenn wir in unseren Logdateien nachsehen, wo eine nicht zugestellte E-Mail geblieben ist (Fall 1 oben), stellen wir fast immer fest, dass die E-Mail durchaus korrekt zugestellt wurde. Eine Nachfrage beim Empfänger ergibt dann, dass die Mail im Spam-Ordner beim Empfänger aufgetaucht ist.

Andere Provider nutzen Blacklists (Fall 2), die von externen Dienstleistern betrieben werden. Wir haben in der Vergangenheit immer wieder erlebt, dass unsere Mailserver aufgrund einer einzigen über uns verschickten Spam-Mail blockiert werden – bei täglich rund 100.000 (legalen) E-Mails, die über unsere Mailserver verschickt werden. Der Betreiber der Blacklist verlangt dann von uns einen Betrag um 100,- Euro, damit er uns wieder von der Blacklist entfernt – bis zur nächsten Sperrung. “Moderne Wegelagerei” ist vielleicht der treffendste Begriff für dieses Verhalten.

Auch der dritte oben beschriebene Fall tritt immer wieder auf. Natürlich tippt kein Mitarbeiter bei uns eine E-Mail mit Zugangsdaten per Hand – diese E-Mail wird automatisch verschickt. Es gibt Spamfilter, die automatisch versandte E-Mails grundsätzlich in den Spamordner einsortieren und sich unsere Kunden dann wundern, warum sie auch nach einer Woche noch keine Zugangsdaten für ihren Vertrag bekommen haben.

Unser eigener Spamfilter (eXpurgate von Eleven) nutzt Signaturen, um Spam zu identifizieren – dies gelingt mit einer wirklich guten Erfolgsquote von über 99%. Dabei werden nur 0,00001% aller erwünschten E-Mails fälschlicherweise als Spam erkannt.  Der Absender erhält in diesem Fall eine eindeutige Meldung, die E-Mail verschwindet also nicht einfach im Nirvana.

Spam ist zweifellos eine Plage, die es zu bekämpfen gilt. In unserem Arbeitsalltag fällt allerdings zunehmend auf, dass schlechte Spamfilter die noch viel größere Belastung sind. Die Zustellung von E-Mails ist zur Glückssache geworden.

… macht viel Kummer und Sorgen. Wir selbst setzen Exchange nicht ein, viele Kunden nutzen die Microsoft Groupware jedoch. In den letzten Stunden muss es ein Exchange-Update gegeben haben, das zu folgendem Phänomen führt:

Unsere Reseller nutzen üblicherweise eine Providerdomain, mit der es nach außen so scheint, als betreibe der Reseller alle Server selbst, also z.B. ns1.[providerdomain], pop3.[providerdomain] und so weiter. Zum Versenden von E-Mails per SMTP verwenden diese Reseller dann entsprechend smtp.[providerdomain], wobei auch dies nur ein Alias für smtp.variomedia.de ist.

Nutzt ein Reseller ein solches Postfach zum Versenden von E-Mails mit Exchange (oder einem anderen Groupwareserver), trägt er die Benutzerdaten des Postfachs und den entsprechenden SMTP-Server in der Konfiguration zum Senden ein. Nach den Exchange-Updates (uns ist das gleiche Verhalten auch vom Tobit-Server bekannt) nutzt der Server zum Versenden aber nicht mehr den eingetragenen SMTP-Server, sondern fragt dessen MX-Eintrag ab. Der MX-Eintrag für smtp.[providerdomain] ist üblicherweise mail.[providerdomain]. Dies ist jedoch ein völlig anderer Server, den man nicht als SMTP-Relay, also für den Versand von E-Mails nutzen kann.

Die Verwendung des falschen Servers führt zu der wenig hilfreichenden Fehlermeldung “AUTH Fehler”. Es gibt unseres Wissens keine Möglichkeit, die Verwendung des MX-Eintrags in Exchange zu unterbinden, daher hilft nur die Methode, einfach keinen MX-Eintrag mehr für smtp.[providerdomain] mehr auszuliefern. Dies führt dazu, dass man keine E-Mails mehr an Adressen im Format …@smtp.[providerdomain] empfangen kann; für die meisten Kunden dürfte dies jedoch verschmerzbar sein. Ein Reseller, der von dem Problem betroffen ist, sollte daher den DNS-Eintrag

*.[providerdomain] IN MX mail.[providerdomain]

löschen. Alternativ lässt sich auch smtp.variomedia.de als SMTP-Server nutzen; wir haben für unsere eigene Domain den Eintrag bereits gelöscht. Diese Anleitung befindet sich auch in unserer FAQ.

Update: Bei dem heute aufgetretenen Problem scheint ein Tobit-Update für den Großteil der Fehlermeldungen verantwortlich zu sein.

Wichtig: Da es sich hierbei um DNS-Änderungen handelt, kann es bis zu 48 Stunden dauern, bis die Änderungen beim DNS-Server Ihres Providers ankommen und wirklich Ihr Problem lösen! Tragen Sie vorerst bitte direkt die IP-Adresse (81.28.224.28) als Relay-Server ein.