Wenn die Mails nicht mehr fließen, ist guter Rat teuer. Wir zeigen Ihnen, wie Sie dem Fehler auf die Schliche kommen.

So lange der Mailverkehr funktioniert, macht sich naturgemäß kaum jemand Gedanken darüber, wie er eigentlich funktioniert. Kommt es zu Störungen, stehen deshalb die meisten Anwender dem Schlauch. Das liegt nicht zuletzt daran, dass oft Grundlagenkenntnisse darüber fehlen, was denn eigentlich genau geschieht, wenn Sie eine Mail versenden oder abholen. Das Wissen über die Funktionsweise ist jedoch eine Grundvoraussetzung, um auftretenden Problemen wirkungsvoll zu begegnen.

Vom Sender zum Empfänger

Beim Abschicken einer E-Mail kommt es zu einem komplexen Zusammenspiel verschiedener Dienste, die den reibungslosen Versand ermöglichen. Der Kasten “Kleine Briefschule” gibt einen Überblick der gebräuchlichsten Protokolle. Die meisten Mailserver arbeiten in einer Doppelrolle als MSA (Message Submission Agent) und MTA (Mail Transfer Agent): Der MSA nimmt ausschließlich Nachrichten von Maiclients, so genannten MUAs (Mail User Agents), entgegen und leitet sie an den MTA weiter. Dieser entscheidet anhand der Empfängeradresse, was mit der Mail geschieht. Besitzt der Empfänger ein Postfach auf dem Mailserver, leitet der Dienst die Mail an den MDA (Mail Delivery Agent) weiter, der die Nachricht dem jeweiligen Postfach zuordnet (Abbildung 1).

Abbildung 1: Die E-Mail durchläuft auch in den Mailservern selbst mehrere Stationen, bis sie den Empfänger erreicht.

Besitzt der Empfänger kein eigenes Mailkonto, gehört aber zur Domain, die der Mailserver verwaltet, landet die Nachricht im so genannten Catch-All-Sammelkonto, falls eines existiert. Ist das nicht der Fall, schickt der Mailserver die Nachricht mit dem Hinweis unknown recipient (unbekannter Empfänger) an den Versender zurück. Gehört die Nachricht einem Empfänger einer fremden Domain, leitet der MTA diese an den dafür zuständigen MTA weiter. Im Gegensatz zum MSA nimmt ein MTA ausschließlich Nachrichten von MTAs oder MSAs entgegen, nicht jedoch von Mailclients.

Damit der Empfänger im letzten Schritt der Übertragungskette die Mails vom Server abholen kann, kommen Protokolle wie POP3 oder IMAP zum Einsatz, die den Zugriff auf das Postfach ermöglichen. Die entsprechenden Dienste auf dem Server übernehmen unter Linux üblicherweise Cyrus für IMAP und Pop3 für den gleichnamigen Service.

Vorsicht Falle

Ein normaler Mailserver fungiert gleichzeitig als Posteingangsserver, um an ihn gerichtete Nachrichten anzunehmen und zu verwalten, sowie als Mail-Relay, um fremde Nachrichten an andere Mailserver weiterzuleiten.

Speziell der letzte Modus sorgte in der Vergangenheit für viel Verdruss, weil das SMTP-Protokoll von Hause aus keine Authentifizierungsmethoden mitbringt. Daher arbeiteten viele Mailserver als so genannte Open Mail Relays und ermöglichten es jedermann, Nachrichten zu verschicken. Diese Möglichkeit nutzten viele Spamversender, um ihre E-Mails ohne das Wissen des Mailserverbetreibers in großem Stil unters Volk zu bringen.

Freie Services wie DSLB [1] oder Spamcop [2] scannen deswegen regelmäßig das Internet nach offenen Mail-Relays und setzen diese auf ihre Blacklist. Diverse Spamfilter nutzen diese Listen, um Nachrichten von entsprechenden Absendern als Spam zu deklarieren. Sollten Mails auf scheinbar unerklärliche Weise nicht beim Absender ankommen, lohnt sich ein Check, ob eventuell der eigene Mailserver auf der schwarzen Liste steht.

IMAP vs. POP3

Das Protokoll IMAP bietet gegenüber POP3 diverse Vorteile, aber auch einige Nachteile. Während Sie via POP3 Ihre Mails stets komplett auf die lokale Maschine laden, verbleiben die Nachrichten bei IMAP auf dem Server. Dadurch haben Sie die Nachrichten von jedem Zugang aus parat. Das ermöglicht auch das Anlegen von Mehrbenutzer-Accounts, beispielsweise für Verteilermails. Einige IMAP-Server bieten dazu eine Rechteverwaltung für die zugriffsberechtigten Benutzer. Darüber hinaus bieten die meisten IMAP-Server eine Verschlüsselungsfunktion für den Datentransfer. Welche Sie davon nutzen, legen Sie in den Sicherheitseinstellungen Ihres Mailprogramms fest (Abbildung 2).

Abbildung 2: Ob und welche Verschlüsselung der IMAP-Server verwendet, entscheiden Sie über die Einstellungen des Mail-Clients.

Wählen Sie keine Verschlüsselung, gehen sowohl die Login-Daten als auch die abgerufenen Mails im Klartext über Netz. Hört ein Angreifer dieses mit einem Sniffer ab, bekommt er sämtliche Daten quasi auf einem silbernen Tablett präsentiert (Abbildung 3). Das gleiche gilt auch für POP3, allerdings bietet dieses Protokoll keinerlei optionale Verschlüsselungsfunktionen. Hier hilft nur der Einsatz von POP3S (siehe Kasten “Kleine Briefschule”).

Abbildung 3: Hört ein Angreifer mit einem Sniffer die Netzwerkleitung ab, bekommt er sowohl bei unverschlüsseltem IMAP als auch bei POP3 sämtliche Daten im Klartext angezeigt.

Weil der Mail-Client nur die Nachrichten, die Sie tatsächlich gelesen herunterlädt, benötigt ein IMAP-Zugriff auf das Postfach deutlich weniger Transfervolumen und ist damit prädestiniert für Anwender, die nur mit einem Schmalbandanschluss mit dem Internet verbunden sind.

Viele der Vorteile von IMAP stellen zugleich einen gewissen Nachteil dar. Dadurch, dass die Mails auf dem Server lagern, entsteht ein nicht unerhebliches Sicherheitsrisiko, da jeder, der Zugriff auf den Server hat, die Mails lesen kann. Weiterhin erfordert die Arbeit mit IMAP eine kontinuierliche Internetverbindung. Je nach Einstellung des Servers erlaubt IMAP eine Vielzahl serverseitiger Aktionen, beispielsweise das automatische Sortieren von E-Mails, was die Last auf dem Server gegenüber POP3 deutlich erhöht.

Fehler finden

Wenn es beim Empfang oder Versand von E-Mails zu Problemen kommt, hilft oft ein einfacher, aber dennoch wirkungsvoller Trick: Eine Verbindung zum Server über einem Telnet-Client gibt oft Aufschluss darüber, was nicht funktioniert. Die übermittelten Kommandos entsprechen exakt denen, die auch der Mailclient an den Server schickt – mit dem Unterschied, dass Sie die Antworten des Servers direkt sehen und damit wertvolle Informationen erhalten, um Fehlerquellen einzugrenzen oder zu identifizieren. Diese reichen von blockierten Ports über Probleme bei der Namensauflösung bis hin zu fehlerhafter Authentisierung.

Das POP-Protokoll verfügt über etwa ein Dutzend verschiedene Nutzerkommandos. Um sich im Postfach anzumelden, tippen Sie auf der Konsole telnet Mailserver 110. Ist der Server erreichbar, bestätigt er den Kontakt mit einem +OK Server ready. Als nächstes geben Sie jeweils hinter USER und PASS Ihre Logindaten ein, die der Server mit +OK Mailbox locked and ready bestätigt, sofern diese korrekt sind; andernfalls erscheint ein P-ERR [AUTH] Invalid login. Während LIST alle in der Mailbox aufbewahrten Mails auflistet, zeigt der Befehl RETR Mail-Nummer die komplette ausgewählte Nachricht an. Möchten Sie nur die Headerdateien sehen, tippen Sie TOP Mail-NummerAnzahl der Zeilen, beispielsweise TOP 3 2. Um die aktuelle Größe der Mailbox zu ermitteln, tippen Sie RSET. Der Befehl QUIT beendet die Session.

Ebenso aufschlussreich gestaltet sich das Prüfen des eigenen Mailservers via Telnet, da Fehler in der Konfiguration sofort auffallen. So sollte ein Mailserver beispielsweise in der Absenderadresse ausschließlich Domainnamen akzeptieren, die er selbst verwaltet. An einen SMTP-Server melden Sie sich mit telnet Mailserver 25 an.

Als erstes erwartet der Server – abhängig vom Typ (SMTP oder ESMTP) – ein HELO oder ein EHLO, gefolgt vom Hostnamen des Absenders. Der Mail-Client sendet an dieser Stelle im Normalfall den eigenen Hostnamen. Speziell die Mailserver einiger Internet-Provider wie Chello akzeptieren den Versand nur, wenn Sie über diesen mit dem Internet verbunden sind. Sofern der Server Nachrichten von diesem Host akzeptiert, antwortet darauf mit einer Liste der von ihm unterstützten Funktionen. Andernfalls verweigert der Server die Annahme von Mails. Eine Aufschlüsselung der verschiedenen Antwort-Codes finden Sie unter [3].

Eine einfache Methode, zu prüfen, ob der Mailserver den Empfänger akzeptiert, bietet das Kommando VRFY <Empfangsadresse>, beispielsweise VRFY tleichtenstern@linux-user.de. Um eine Mail über die Telnet-Session zu verschicken (Abbildung 4), geben Sie folgendes ein:

• MAIL from:Mailadresse – legt die Absenderadresse fest.
• RCPT to:Mailadresse – Legt die Empfängeradresse fest. Bei der Eingabe mehrerer “Recipients” versendet der Server die Nachricht an alle angegebenen.
• DATA – Zeigt an, dass nun der Datenteil mit der eigentlichen Nachricht beginnt.
• Subject: Nachricht – Die Betreffzeile der Mail.
• Beliebiger Text – Die eigentliche Nachricht.
• “.” – Ein abschließender Punkt in einer eigenen Zeile signalisiert dem Server das Ende des Datenteils. Er versendet daraufhin die Nachricht.

Abbildung 4: Das Versenden von E-Mails über den Telnet-Client gibt Aufschluss über die Konfiguration des Servers und hilft so, Fehler zu finden.

Während der Befehl RSET die Eingaben zurücksetzt, beendet QUIT die Verbindung. Speziell das Testen verschiedener Kombinationen von Absender- und Empfängeradressen geben einen relativ exakten Aufschluss über die Konfiguration des Servers. So sollte ein nicht authentifizierter Benutzer niemals Nachrichten an Empfänger fremder Domains schreiben dürfen, da der Server sonst im Open-Relay-Modus arbeitet. Einige Mailserver, beispielsweise der von Google Mail, arbeiten ausschließlich im verschlüsselten TLS-Modus. Eine Übertragung im Klartext – und damit auch via Telnet – scheitert entsprechend. Eine Liste aller verfügbaren SMTP-Kommandos finden Sie unter [4].

Gerade Linux-Anwender versenden oft ihre Mails direkt vom eigenen Mailserver direkt zum Empfänger. Das führt nicht selten zu Problemen, weil auch die Adressbereiche dynamischer Einwahlverbindungen in vielen Blacklists geführt werden und die Gegenstelle den Empfang ablehnt. Hier hilft es, die Mails zunächst vom eigenen Mailserver zu einem anderen, öffentlichen weiterleiten zu lassen, der sie dann dem Empfänger zustellt.