Deaktivierung von SMTP-after-POP

Nach vielen Ankündigungen und Informations-E-Mails an unsere Kunden wurde die Anmeldung über SMTP-after-POP nun auf allen unseren Mailservern deaktiviert, sodass die Authentifizierung nur mehr über SMTP-Auth erfolgen kann.

Was bedeutet das?

Zur Anmeldung am Postausgangsserver (SMTP-Server) gibt es für den Versand von E-Mails zwei unterschiedliche Verfahren, „SMTP-Auth“ und „SMTP-after-POP“.

Bei der modernen und inzwischen von den meisten E-Mailprogrammen standardmäßig genutzten Anmeldung via „SMTP-Auth“ erfolgt am Postausgangsserver explizit eine Anmeldung mit Benutzername (bei uns die E-Mailadresse) und dem zugehörigen Kennwort.

„SMTP-after-POP“ ist als Authentifizierungsmethode inzwischen recht veraltet, es erfolgt dabei keine direkte Anmeldung am Postausgangsserver. Der Versand über SMTP-after-POP ist immer dann möglich, wenn zuvor eine Anmeldung am Posteingangsserver erfolgt ist. Das E-Mailsystem „merkt“ sich dann für einen bestimmten Zeitraum die IP-Adresse, über die die Anmeldung erfolgt ist und erlaubt den Versand über diese IP-Adresse, ohne dass eine weitere Authentifizierung am Postausgangsserver erfolgen muss.

Oder ganz kurz und einfach gesagt:

  • bei SMTP-Auth erfolgt die Anmeldung am SMTP-Server über die Authentifizierung mit Benutzername und Kennwort
  • bei SMTP-after-POP erfolgt die Anmeldung am SMTP-Server, nachdem man sich am POP-Server (Posteingangsserver) angemeldet hat.

Warum wurde SMTP-after-POP deaktiviert?

Da bei SMTP-after-POP keine eindeutige Authentifizierung am Postausgangsserver erfolgt, sondern der angemeldeten IP-Adresse der Versand über den Postausgansserver erlaubt wird, stellt diese Form der Anmeldung im täglichen Betrieb leider ein erhebliches Problem bei der Spambekämpfung dar.
Z.B. über öffentliche Netze ist es Dritten so möglich, ohne Authentifizierung über den Postausgangsserver zu senden und so Spammails zu verbreiten.

Da wir den Versand von Spammails über unsere Server ausdrücklich ablehnen und so gut wie möglich bekämpfen, haben wir beschlossen, die Anmeldungsmethode SMTP-after-POP in unserem System komplett zu deaktivieren und somit diese Möglichkeit der Spamverbreitung zu unterbinden.

Planungen und Vorbereitungen für die Deaktivierung von SMTP-after-POP

Die Deaktivierung einer zwar veralteten, jedoch immer noch recht weit verbreiteten Anmeldungsmethode haben wir selbstverständlich nicht ohne Vorankündigung durchgeführt.

In einem Express-Newsletter haben wir also zunächst alle Kunden (die die Zusendung unserer Newsletter wünschen) über die geplante Umstellung informiert.

Natürlich wissen wir aber, dass nicht jeder den Newsletter (aufmerksam) liest und die Kontoeinstellungen im E-Mailprogramm dann auch überprüft und gegebenenfalls berichtigt.

Wir halten es zwar für wichtig, zunächst eine allgemeine Information in dieser Form an unsere Kunden zu senden, jedoch in einem solchen Fall keinesfalls für ausreichend.

Daher haben wir geprüft, welche Postfächer via SMTP-after-POP über unser Mailsystem senden und wöchentlich eine personalisierte E-Mail an die Kunden, die die jeweiligen Postfächer verwalten, gesendet. Diese E-Mails enthielten die betroffenen E-Mailadressen, die wir als Sender ohne SMTP-Auth ausfindig machen konnten, sodass es unseren Kunden möglich war, die Einstellungen explizit für diese E-Mailadressen im E-Mailprogramm auf das SMTP-Auth-Verfahren anzupassen. Entsprechende Anleitungen dazu haben wir natürlich bereitgestellt.

Der Zeitraum betrug dabei 6 Wochen, sodass jeder Kunde, der Postfächer ohne SMTP-Auth nutzt, 6 E-Mails mit der Bitte um Änderung der Einstellungen erhalten hat.

Die Deaktivierung

Am 2.9.2013 haben die verantwortlichen Techniker nach und nach die Anmeldungsmethode via SMTP-after-POP auf unseren Postausgangsservern gesperrt.

Warum nicht alle auf einmal?

Wir haben uns gegen eine Deaktivierung von SMTP-after-POP für alle Postfächer gleichzeitig entschieden, damit das Anfragevolumen nicht plötzlich zu stark ansteigt. Durch die Deaktivierung in einzelnen Etappen konnten wir sämtliche Rückfragen unserer Kunden ohne ungewöhnlich lange Wartezeiten entgegennehmen und bearbeiten.

Die Sperrung von SMTP-after-POP erfolgte alphabetisch, wobei wir für eine gleichmäßige Aufteilung zuvor ausgewertet haben, wie viel Prozent der Postfächer mit welchem Anfangsbuchstaben beginnen.

Wie hat sich die Umstellung intern ausgewirkt?

Nach 2 Tagen, also am 3.9.2013, wurde die Umstellung dann – ohne Probleme! 🙂 – für sämtliche Postfächer erfolgreich abgeschlossen.

Ein erhöhtes Anfragevolumen haben wir natürlich trotz aller Informationsmails erwartet, umso schöner, dass der Kundenservice in dieser Zeit voll besetzt war und sich Kollegen sogar (selbstverständlich freiwillig!) bereit erklärt haben, geplante Urlaube zu verschieben um während und nach der Umstellung anwesend zu sein.

Schon während unsere Techniker die Deaktivierung vorgenommen haben, stieg die Menge an Anfragen natürlich an, auch jetzt noch erhalten wir einige Rückfragen zur Änderung der Einstellungen im E-Mailprogramm, die wir aber – wie wir denken – in sehr zufriedenstellenden Antwortzeiten bearbeiten und lösen können.

Abschließend…

Wir freuen uns sehr, dass so viele Kunden auf unsere E-Mails reagiert haben, sodass die Authentifizierung an den Postausgangsservern größtenteils bereits vor der Umstellung über SMTP-Auth erfolgte.

So haben wir eine Möglichkeit, den Versand von Spamnachrichten über unser System zu verhindern und somit wieder einen Teil zur Spambekämpfung beitragen können!

End of article

Anna Philipp

Über den Autor

Anna Philipp

Anna arbeitet seit 2006 bei DomainFactory. Als Social Media und Content Manager vertritt sie DF in den sozialen Netzwerken (Facebook, Twitter, Googleplus und natürlich im DF-Blog). In ihrer Freizeit findet man Anna - sofern sie mal nicht online ist - höchstwahrscheinlich zwischen Rührschüsseln und Schneebesen am Backofen.

19 Kommentare

Bitte füllen Sie das Captcha aus : *

Reload Image

Die von Ihnen hier erhobenen Daten werden von der domainfactory GmbH zur Veröffentlichung Ihres Beitrags in diesem Blog verarbeitet. Weitere Informationen entnehmen Sie bitte folgendem Link: www.df.eu/datenschutz


  • Axel
    Axel - 6. September 2013 um 13:06 Uhr

    Ein großes Lob an Eure Informationspolitk.
    Ich wünschte mir, dass jeder Dienstleister so mit seinen Kunde umgeht. Leider bleibt das in den meisten Fällen ein Wunschtraum.

    DF ist da ein – für mich – großes und gutes Vorbild.

    Danke!

  • Torsten
    Torsten - 6. September 2013 um 13:24 Uhr

    Well done!

    Da kann ich mir nur anschließen. Vorbildliches kundenorientiertes Vorgehen bei der Umsetzung und großartig kommuniziert. Vor allem die personalisierte Ansprache nach Identifizierung der betroffenen Benutzer ist ein Hammer-Service, den wohl kaum ein Außenstehender richtig würdigen kann.

    Einen lieben Gruß an alle Techniker und Supporter! Ich kann mich nur noch einmal wiederholen: Well done! 🙂

  • Heinz
    Heinz - 6. September 2013 um 13:50 Uhr

    Einfach Perfekt!
    Großes Lob auch von unserer Seite an DF!
    War vor ein paar Jahren die beste Entscheidung zu DF zu wechseln.

  • Andreas G.
    Andreas G. - 6. September 2013 um 15:13 Uhr

    Ein furchtbares Relikt das zum Glück jetzt abgeschafft wurde.

    Der nächsten Schritte müsste sein LOGIN und PLAIN rauszuwerfen dafür SCRAM-SHA-1 einzuführen. Dann könnten Benutzername und Passwort nicht mehr mitgelesen werden selbst wenn keine Verschlüsselung vorhanden ist.

    Dazu würde ich noch TLS verpflichtend einführen um nochmal eine Schippe draufzulegen.

  • Jan
    Jan - 6. September 2013 um 18:14 Uhr

    Sehr hilfreich war auch die Info, welche EMail-Accounts SMTP-after-POP noch tatsächlich Anfang August genutzt haben. Bei uns hat die Umstellung problemlos geklappt.

  • LeereDose
    LeereDose - 6. September 2013 um 22:24 Uhr

    Gibt es denn zufälligerweise Infos, wieviele eurer Kunden (Pi-mal-Daumen prozentual) überhaupt noch SMTP-after-POP genutzt hatten?

  • Martin
    Martin - 6. September 2013 um 22:35 Uhr

    Jetzt noch Port 25 sperren!

  • Peter
    Peter - 7. September 2013 um 00:29 Uhr

    Jetzt bitte die freien Ressourcen auf das Hashen der Kundenkennworte in Euren Datenbanken verwenden! Das empfinden wir als drängend!

  • Bachsau
    Bachsau - 7. September 2013 um 13:42 Uhr

    Also mir wär das peinlich, mich wegen solcher Basics an den Support zu wenden. Das ist ja nun nichts, was man nicht überall nachlesen könnte, am einfachsten direkt in der Hilfe des Mailprogramms.

  • Bachsau
    Bachsau - 7. September 2013 um 13:45 Uhr

    @Andreas G.:
    SCRAM-SHA-1 ist bestimmt kein Fortschritt, sondern gehört verboten. Es erfordert nämlich, dass die Zugangsdaten auf dem Server im Klartext gespeichert werden, und das will niemand!

  • Andreas G.
    Andreas G. - 7. September 2013 um 21:50 Uhr

    @Bachsau:

    Eben das ist bei SCRAM-SHA1 nicht der Fall.
    Die Passwörter werden lt. RFC5802 als gesalzene Hashes in der Datenbank gespeichert. Trotzdem geht nichts unverschlüsselt über die Leitung.

    Das ist der große Vorteil gegenüber CRAM-MD5 bei dem die Passwörter tatsächlich im Klartext in der Datenbank stehen müssen.

    Leider ist SCRAM-SHA1 zu neu als das es weit verbreitet wäre.

  • Nils Dornblut
    Nils Dornblut - 8. September 2013 um 23:38 Uhr

    @Martin: Der Port 25 wird von vielen Kunden verwendet und stellt so eigentlich keine direkte Gefahr dar. Man kann nicht jeden zu SSL zwingen, auch wenn wir die Nutzung empfehlen. Hier würde es einen großen Aufschrei geben, wenn wir das machen würden.

    @LeereDose: Es waren unter einem Prozent der Postfächer, die das noch genutzt haben.

  • Michael
    Michael - 9. September 2013 um 08:44 Uhr

    @Nils Dornblut: Sehe ich das richtig, dass meine möglichen Versuche die Mailverbindung zum DF-Server aufzubauen vergessen kann, wenn nicht der andere ebenfalls ne verschlüsselte Verbindung zu seinem Server hat?

    Ich hatte schon mal überlegt, mir ein Zertifikat zuzulegen aber wenn da nur die halbe Strecke verschlüsselt ist, lesen die Amis trotzdem und ich kann den Versuch doch vergessen. Dann lieber GNU / PGP, aber auch da muss der andere wieder mitspielen.

    Und da ich kein Terrorist bin, ist es mir eigentlich auch nicht die Mühe wert, alle Leute zu bequatschen, sich GNU zuzulegen. Auch wenn’s kostenlos ist aber nur wegen der Mühe.

  • Nils Dornblut
    Nils Dornblut - 10. September 2013 um 19:47 Uhr

    @Michael: Nein, er muss nur das Feature entsprechend unterstützen und verschlüsselte Verbindungen (TLS) akzeptieren. Ende-zu-Ende Verschlüsselung über PGP oder S/MIME empfehlen wir als beste Lösung zusätzlich. Hier muss der Angeschriebene das aber auch unterstützen, wie schon von Ihnen geschrieben wurde.

  • Bachsau
    Bachsau - 11. September 2013 um 15:29 Uhr

    @Michael: Das wichtigste ist doch, dass die Login-Daten und Mails auf dem Weg zum Server nicht von jedem Hans Doof mitgelesen werden können. Besonders wichtig in öffentlichen WLANs! Da leistet SSL gute Dienste. So kann ich auch im Ausland und bei McDonald’s meine Mails mit sicherem Gefühl lesen. Ende zu Ende Verschlüsselung ist eine andere Baustelle.

  • Jan U. Day
    Jan U. Day - 29. September 2013 um 03:16 Uhr

    wie kann ich es machen, daß meine Kunden als POP3- und SMTP-Server nicht die Domain pop3/smtp.kundendomain.de haben, sondern die Adresse meines Mailservers. Also pop3/smtp.**************.de? Ich finde diese Funktion ist interessant, da ich dann nur guten Kunden einen „eigenen Mailserver“ anbieten kann.

  • Nils Dornblut
    Nils Dornblut - 29. September 2013 um 10:16 Uhr

    @Jan U. Day: Da Sie keinen direkt eigenen Mailserver haben, ist das so nicht möglich. Die Mailserver werden dediziert betrieben und Sie können dem Mailserver nicht die eigene Domain verpassen. Für Thunderbird gibt es die Möglichkeit der Hinterlegung von eigenen Konfigurationseinstellungen: https://www.df.eu/forum/threads/63754-Thunderbird-Konten-Assistent-und-d%29f-Mailserver?p=413309&viewfull=1#post413309