208 208.fi

Simple Mail Transport Protocol (SMTP)


Simple Mail Transfer Protocol (SMTP) ist ein Kommunikationsprotokoll, der auf Mailservern eingesetzt wird. Mit SMTP können Nachrichten geliefert werden, auch wenn keine direkte Verbindung zwischen dem Absender und dem Empfänger existiert.

E-Mail wird auf einer besonderen Weise im Domain-Namen-System behandelt: Während die meisten Dienste direkt mit irgendwelchen IPv4- oder IPv6-Adressen verbunden sind, wird Mail auf Servern geliefert, die in besonderen MX-Datensätzen aufgelistet werden.

Zur verbesserten Fehlertoleranz werden SMTP-Server üblicherweise die empfangenen Nachrichten bis zu eine Woche speichern, bis sie weiter geliefert werden können. Ein Server könnte vorübergehend unerreichbar sein, oder der verfügbare Speicherplatz für den Briefkasten des Empfängers könnte ausgelaufen haben. Normalerweise werden solche Probleme in wenigen Tagen gelöst.

Domain-Namen können mit mehreren MX-Einträgen assoziiert sein. Ist der primäre Server überlastet, können andere Server benutzt werden.

Dank ihrer verteilten, fehlertoleranten und warteschlangenbasierten Implementation ist E-Mail sehr robust.

Das Spam-Problem

Als die Kommerzialisierung von Internet in den 1990er Jahren Fahrt aufnahm, wurde eine fragwürdige Erfindung gemacht, dass E-Mail einem Sender ermöglicht, mit wenigen Kosten ein sehr großes Publikum zu erreichen. Wenn ausreichend viele Empfänger das Angebot annehmen oder Opfer des Betrugs werden, hat es sich für den Sender gelohnt.

So spät wie am Anfang der 2000er Jahren gab es SMTP-Server, die weit offen für die ganze Welt waren. Dadurch konnten Nachrichten an beliebige Empfänger verschickt werden. Die Nachrichten konnten behaupten, von beliebigen Absendern und Adressen zu stammen. So konnten Spammer den von anderen bezahlten Speicherplatz für Mail-Warteschlangen frei ausnutzen. Es war auch für Empfänger schwieriger, Spam von seriösen Nachrichten zu unterscheiden, weil der Müll durch sehr viele SMTP-Server verbreitet wurde.

Weit in die 1990er Jahre hinein könnte eine europäische technische Universität seine eigene Netzklasse B (x.y.0.0/16, 65,536 Adressen) verwalten, aufgeteilt in kleinere Adressbereiche für einzelne Fakultät oder Abteilungen. Eine statische Adresse wurde manuell in jedem Arbeitsplatzrechner oder Server konfiguriert. In diesen Rechnern könnte eine kommerzielle Version von Unix oder die neue Alternative GNU/Linux zum Einsatz kommen. Auf jedem Rechner würde auch ein eigener SMTP-Server laufen, der direkt mit dem Internet verbunden war. Es gab keine Brandmauer, NAT oder VPN. Die einzigen zenralisierten Komponenten waren die primären SMTP-Server und einige SMTP-Server der Abteilungen oder Fakultäten, die die empfangenen Nachrichtern aufbewahren würden, falls der persönliche Rechner eines Forschers zufällig unerreichbar war.

Mit POP3 und IMAP wurde es bequemer, auf Mail-Ordner auf einem Server zuzugreifen. Es war nicht mehr nötig, das lokale Postfach über eine Terminalverbindung zu einem VAX/VMS- oder Unix-Rechner zu lesen. Als mobile Rechner und drahtlose Netzwerke sich verbreiteten, wurde ein Übergang zu einer mehr zentralisierter Infrastruktur notwendig. Manuell konfigurierte statische IP-Adressen wurden durch dynamische Adressen ersetzt, die per BOOTP oder später DHCP ausgeliefert wurden. Benutzer wurden gezwungen, auf dedizierte Mail-Server zu wechseln. Interessanterweise wird DHCP keine SMTP-Einstellungen liefern; sie müssen manuell konfiguriert werden.

Bis in frühe 2000er Jahre wurde von Internetanbietern erwartet, dass E-Mail ein Bestandteil des Angebots ist. Heute kann man mehrmals pro Tag von einem Anbieter zum nächsten wechseln (denken Sie an Mobilgeräten und WiFi), und der E-Mail-Anbieter könnte ein ganz anderes Unternehmen sein.

Nur an eigene oder von eigenen Nutzern empfangen

In der heutigen Praxis akzeptiert ein SMTP-Server Nachrichten von anderen SMTP-Servern oder unauthentizierten Anwendern nur für Empfänger, für die der Server zuständig ist.

Endbenutzer sollen ihre Nachrichten über den SMTP-Server ihres Dienstleisters verschicken. Üblicherweise werden eine TLS-Verbindung, ein Benutzernamen und ein Kennwort benötigt.

In der Vergangenheit kam es vor, dass Spam-Nachrichten über gekaperte Geräte in Heimnetzwerken verschickt wurden. Heutzutage sollte das zum Beispiel dank Traficoms Verordnung 67 über Informationssicherheit im Telekommunikationsbetrieb verhindert werden. Durch diese Verordnung werden Internetanbieter verpflichtet, direkte unverschlüsselte SMTP-Verbindungen für Verbraucher auf das eigene Netzwerk des Anbieters zu beschränken.

Daher wird man praktisch gezwungen, E-Mail ausschließlich über den SMTP-Server des Anbieters zu verschicken. Dies ermöglicht einen effizienten Schutz gegen Spam. Die empfangenden Server setzen oft DNS-basierte Blockierungslisten von Servern, die verdächtigt werden, Spam zu liefern.

Unterscheiden Sie sich von Spammern: SPF, DMARC, DKIM

Einige der effizientesten Wege zur Spam-Bekämpfung sind DMARC und DKIM, die zum größten Teil den alten SPF aufgelöst haben. Alle diese Lösungen basieren sich auf TXT-Datensätze im DNS.

Warum sehen viele Webmail-Nutzer meine Nachrichten nicht?

Viele E-Mail-Anbieter setzen künstliche Verzögerungen ein oder klassifizieren Nachrichten als Spam, wenn diese Richtlinien nicht eingehalten werden.

Der erste Sendeversuch kan vorübergehend abgelehnt werden, und der Sender wird erwartet, später erneut zu versuchen. Ein späterer Versuch aus derselben Adresse oder mit den gleichen Metadaten kann durchgelassen werden. Der Sinn dahinter ist, dass nicht alle Spammer eine Warteschlange implementieren und so ein Teil des Mülls abgewehrt wird.

Die durchgelassenen Nachrichten können weiterhin als Spam eingestuft werden, zum Beispiel wenn der Absender nicht im Addressbuch des Empfängers eingetragen ist.

Weil das Internet ein verteiltes und dezentral verwaltetes System ist, finden Umstellungen allmählich statt, und der Übergang kann lange dauern. Genau wie die Umstellung von HTTP auf HTTPS, wird eine vollständige Umstellung auf DMARC und DKIM schließlich durchgeführt.

Zum Beispiel gibt es einen TXT-Eintrag für 208.fi gemäß SPF, der den zuständigen Absender-Mail-Server identifiziert. Der Eintrag erlaubt einem Empfänger-Server, einfach die Echtheit einer Nachricht, die angeblich aus 208.fi kommt, zu prüfen.

Nehmen wir an, dass eine Nachricht aus 208.fi im guten Glauben an einen Empfänger verschickt wird, der einen Weiterleitungsdienst A einsetzt, der sämtliche Nachrichten an eine E-Mail-Adresse B weiterleitet. In diesem Fall kann A prüfen, dass die Nachricht aus dem zuständigen Mail-Server von 208.fi verschickt wird. Jedoch wird aus der Sicht des zuständigen Servers für B die Adresse 208.fi unerlaubt von A benutzt!

Diesen Designfehler von SPF hat DKIM gelöst: Der ursprüngliche Absender wird den Inhalt der Nachricht mit seinem privaten Schlüssel signieren. Der entsprechende öffentliche Schlüssel wird per DNS bereitgestellt. Zum Beispiel enthält der TXT-Datensatz mail._domainkey.208.fi den öffentlichen Schlüssel des Servers mail.208.fi. Der empfangende Server kann prüfen, ob die Nachricht ein Feld DKIM-Signature enthält, das dem Inhalt und der öffentlichen Schlüssel entspricht.

Was passiert, wenn eine Nachricht im guten Glauben aus 208.fi an einen Adressat verschickt wird, und dieser einen Weiterleitungsdienst X eingerichtet hat, der die Nachricht an eine Million weitere Adressen weiterschickt? Könnte mail.208.fi auf irgendwelche DNS-Blockierlisten gelangen? (Der Weiterleitungsdienst X hoffentlich schon.)

Die SPF-Datensätze wurden durch DMARC-Datensätze ergänzt oder ersetzt. Diese Datensätze vermitteln einen Wunsch, wie die als Spam eingestuften Nachrichten behandelt werden sollten. Es ist üblich, nach Benachrichtigungen zu bitten. Der E-Mail-Administrator wird aufklären und beim Bedarf beantworten und versprechen, die Situation zu regeln. Dadurch sollte eine Blockierung vermieden werden.

Die Korrekturmaßnahme hängt von der jeweiligen Situation ab. Wenn es um einen vereinzelten Benutzer handelt, könnte der Kunde kontaktiert werden. In einem Extremfall ist es möglich, das Senden weiterer Nachrichten vorübergehend zu blockieren.


Siehe auch