Untersuchung von verschlüsselter - Kommunikation nach Spam und Viren MASTERARBEIT. zur Erlangung des akademischen Grades.

Transkript

1 UNIVERSITÄT JOHANNES KEPLER LINZ JKU Technisch-Naturwissenschaftliche Fakultät Untersuchung von verschlüsselter - Kommunikation nach Spam und Viren MASTERARBEIT zur Erlangung des akademischen Grades Diplom-Ingenieur im Masterstudium Netzwerke und Sicherheit Eingereicht von: Michael Grundmann Bakk.techn., Angefertigt am: Institut für Informationsverarbeitung und Mikroprozessortechnik Beurteilung: O.Univ.-Prof. Dr. Jörg R. Mühlbacher Assoz.Prof. Mag. iur. Dipl.-Ing. Dr. Michael Sonntag Mitwirkung: Dipl.-Ing. Dr. Rudolf Hörmanseder Linz, September 2012

2 Kurzfassung Ohne eine Überprüfung von -Nachrichten nach unerwünschten (Spam) oder gefährlichen Inhalten (Viren, Phishing) ist das Betreiben oder Benutzen eines Mail-Dienstes nicht mehr vorstellbar. Da immer mehr und sensiblere Daten übertragen werden, wird auch die Verschlüsselung des Mail-Transports immer wichtiger. Diese Verschlüsselung ist sicherheitstechnisch eine sinnvolle Entwicklung, die aber der benötigten Überprüfung der Mails entgegenstehen kann, wenn die Mail-Analyse beim»betreten«oder»verlassen«des eigenen Netzwerkes erfolgen soll. Diese Arbeit zeigt eine Möglichkeit, eine solche Inhaltsanalyse auch bei Verwendung von Verschlüsselung vorzunehmen. Dabei wird trotz TLS-Verschlüsselung, die zwischen den Mailservern zur Absicherung des SMTP-Transportweges aufgebaut wird, die Inhaltsanalyse mit Hilfe einer vertrauenswürdigen Zertifizierungsstelle ermöglicht. Hierbei werden bestehende SMTP-Proxy-Lösungen auf solche Funktionalität hin untersucht und als Konsequenz der Untersuchung wird eine Eigenentwicklung vorgestellt. Dazu werden die Eigenheiten von SMTP vorgestellt, soweit diese bei der Implementierung eines Proxy und der Verwendung von TLS relevant sind. Bei der Realisierung wurde darauf Wert gelegt, dass der Proxy die Sicherheit erhöht, aber dabei in keinem Fall ein nicht vorhandenes Sicherheitsniveau vortäuscht. Auch soll die Funktionalität und das Verhalten, besonders in Fehlerfällen, genau der Kommunikation ohne Proxy entsprechen. Diese Schwerpunkte ergeben sich aus der Anforderung des Projekts zur Integration des SMTPS-Proxy in die Firewall der Firma Underground_

3 Abstract Operating or using an electronic mail service is hardly imaginable anymore without checking the electronic mail messages for unwanted (spam) or dangerous (virus, phising) content. Due to the need to transmit more and sensitive data, encryption of the mail transport is becoming increasingly widespread. While this is a reasonable development, it might contradict the necessary checking of the mail messages, if this should happen when they enter or leave the own network. This thesis shows a way to enable such a checking, even when using TLS encryption. A trusted Certificate Authority (CA) allows for an analysis of the content despite the encryption used by mail servers to secure the SMTP transport. It includes an investigation into existing SMTP proxy solutions and whether they are able to support this functionality which leads to a self-developed solution. Features of the SMTP protocol which are relevant to the implementation of a proxy and the usage of TLS encryption will be presented. The implementation takes care that the proxy increases the security but in no case pretends a non-existing security level. The functionality and behavior, especially in error-cases, should match that of a communication without the proxy. These key aspects arise from the requirements of the project to integrate the SMTPS proxy into the firewall of the company Underground_8.

4 Danksagung An dieser Stelle möchte ich meinen Dank dem Institut für Informationsverarbeitung und Mikroprozessortechnik aussprechen. Im Besonderen danke ich dem Institutsvorstand O.Univ.- Prof. Dr. Jörg R. Mühlbacher und Assoz.Prof. Mag. iur. Dipl.-Ing. Dr. Michael Sonntag für die Betreuung dieser Diplomarbeit. Ebenfalls möchte ich mich bei Dipl.-Ing. Dr. Rudolf Hörmanseder für die fachliche Unterstützung der Masterarbeit bedanken. Ohne die Unterstützung durch meine Kolleginnen und Kollegen bei der Firma Underground_8 wäre diese Arbeit nicht möglich gewesen. Im Speziellen gilt hier mein Dank Dipl.-Ing. Roman Aspetsberger, der mir sowohl technisch als auch inhaltlich eine große Hilfe war. iii

5 Inhaltsverzeichnis 1 Einleitung Ausgangslage Gliederung der Arbeit Das Simple Mail Transfer Protocol Aufbau des Simple Mail Transfer Protocol Ablauf einer SMTP-Session Ende einer SMTP-Session Behandlung des end of mail-indikators SMTP-Kommandos SMTP Return Codes Bespiele für den Ablauf von SMTP-Sitzungen Verlässlichkeit Mail-Routing Timeouts SMTP-Proxy Proxy-Unterstützung für (E-)SMTP-Funktionalität SMTP-Proxy vs. Relay Regelung des Zugriffs Verantwortlichkeit für Mail-Nachrichten Verwaltung einer Warteschlange STARTTLS-Erweiterung Vorhandene SMTP-Proxy-Lösungen ProxSMTP/ClamSMTP Anti-Spam-SMTP-Proxy-Server (ASSP) Hermes BarricadeMX qpsmtpd Evaluation TLS-Proxy-Engine von Underground_ Aufbau des TLS-Proxy Multithreading Anbindung der Content-Filter Verbindungsablauf iv

6 Inhaltsverzeichnis v Zertifikate Erweiterbarkeit für weitere Protokolle Der TPROXY-Patch Erweiterung des TLS-Proxy RFC-konforme Fehlermeldungen Gemeinsam genutzte Zertifizierungsstelle Relay Erzwingen von TLS Hinterlegen von Zertifikaten Entwurf Aufgabenstellung Einsatzszenarien Interne Clients verwenden beliebige externe Mailserver Interne Mailserver empfangen Mails von externen Servern TLS-Sessions trotz fehlender TLS-Unterstützung am Server Zentraler SMTP-Relay-Server Design Struktur Zertifizierungsstelle Anbindung der Content-Filter TLS-Funktionalität Relay Black-/Whitelists Fehlerbehandlung Behandlung von Timeouts Implementierung Entwicklungsumgebung Verwendete Bibliotheken Einbindung der SMTP-Funktionalität Verbindungsablauf im TLS-Proxy Verwaltung von Sockets und TLS-Session Threads Proxy-Objekte Connection Tracking Ausgelagerte Zertifizierungsstelle Kernfunktionalität der Zertifizierungsstelle Initialisierung Signalbehandlung Threadverwaltung in der Zertifizierungsstelle Blocking vs. Non-Blocking I/O Multiplexing-I/O mit select OpenSSL und Non-Blocking-Sockets Verwendung im TLS-Proxy Protokollhandler für SMTP Struktur des SMTP-Handlers

7 Inhaltsverzeichnis vi SMTP-Data und SMTP-Dialog Multiplex-I/O Limits Behandlung von Verbindungsabbrüchen Behandlung von STARTTLS Relay Weiterleitung ohne Untersuchung Behandlung sonstiger Kommandos Hinterlegung von Zertifikaten Verwaltung der hinterlegten Zertifikate Aufbau einer Zertifikatsdatei Verwendung Konfigurationsoptionen Allgemeine Optionen SSL/TLS-Optionen SMTP Optionen Optionen für die Zertifizierungsstelle Tests Testwerkzeuge swaks OpenSSL s_client Testumgebung Non-TLS-Tests Grundlegender Test des Mail-Versands Filtern von SMTP-Kommandos und Antworten TLS-Tests Grundlegender TLS-Test STARTTLS mit On-The-Fly-Zertifikat Server kündigt keine STARTTLS-Unterstützung an Server präsentiert ungültiges oder abgelaufenes Zertifikat CA ist nicht erreichbar STARTTLS mit hinterlegtem Zertifikat Relay zu mailrelay.test.underground8.com Pass-Through Konfigurationsparameter Erwartete Funktionalität IP in Whitelist Hostname in Whitelist Client-Zertifikate Forced-TLS-Tests Konfigurationsparameter Serverseitiges Erzwingen von TLS Clientseitiges Erzwingen von TLS Handbuch zur Systemintegration 98

8 Inhaltsverzeichnis vii 9.1 Installation Softwareabhängigkeiten Installation auf einem Linux-System Statisches Linken der OpenSSL-Bibliotheken Grundkonfiguration Konfiguration der Szenarien Anpassen der Grundkonfiguration Interne Clients verwenden beliebige externe Mailserver Interne Mailserver empfangen Mails von externen Servern Interne Clients verbinden sich zum internen Server über den Proxy Zentraler SMTP-Relay-Server Zusammenfassung und Ausblick Zusammenfassung Ausblick Glossar 112 Tabellenverzeichnis 115 Abbildungsverzeichnis 116 Quellcodeverzeichnis 118 Literaturverzeichnis 122 Internetquellen 126 Erklärung Lebenslauf

9 Kapitel 1 Einleitung 1.1 Ausgangslage Die automatisierte Untersuchung von -Kommunikation nach Spam und Viren ist zu einer Notwendigkeit geworden. Dies wird auch im McAfee Threats Report aus dem zweiten Quartal 2011 deutlich [56, Seite 15]. Darin wird zum Beispiel das Spam-Aufkommen mit 1 5 Billionen Nachrichten pro Tag beziffert. Das ist vor allem relevant, da der Aufwand, der zum manuellen Aussortieren von Spam betrieben werden muss, die Produktivität negativ beeinflusst. Auch wird immer mehr zur Verbreitung von Viren genutzt. Die Anforderungen an die Vertraulichkeit und Integrität der -Übertragung stehen jedoch im Widerspruch zu dieser Automatisierung, insbesondere da diese meist durch Verschlüsselung abgedeckt werden. Verschlüsselte Verbindungen können aber normalerweise nicht am Übertragungsweg (z. B. an einer Firewall oder einem Proxy) untersucht werden und müssen deshalb meist ohne Untersuchung durchgelassen oder zur Gänze blockiert werden. Roman Aspetsberger stellt in seiner Masterarbeit Trusted Person in the Middle: TLS- Proxy [Asp09] einen Lösungsansatz vor, der von der Firma Underground_8 als TLS-Proxy- Lösung zur Untersuchung von HTTPS-Verbindungen in die U8-Firewall integriert wird. Ziel dieser Arbeit ist es, diese Lösung weiterzuentwickeln und um die Unterstützung für das Simple Mail Transfer Protocol (SMTP) zu erweitern. 1.2 Gliederung der Arbeit Der erste Teil dieser Arbeit umfasst die theoretischen Grundlagen für einen SMTPS-Proxy (Kapitel 2). Dazu gehören eine Betrachtung des Mail-Protokolls SMTP im Kontext mit SMTP-Proxys. Auch ist ein Vergleich von SMTP-Proxy und SMTP-Relay enthalten. Eine Untersuchung der STARTTLS-Erweiterung 1 für SMTP und die Evaluierung vorhandener SMTP-Proxy-Lösungen im Hinblick auf die Möglichkeit der Verwendung von Transport Layer 1 Ermöglicht das Aushandeln von TLS-Verschlüsselung auf Klartextverbindungen (STARTTLS) 1

10 1. Einleitung 2 Security (TLS) schließt das Kapitel 3 ab. In Kapitel 4 wird die Struktur der bereits vorhandenen TLSProxy-Engine der Firma Underground_8 beschrieben. Insbesondere wird auf die Erweiterbarkeit für weitere Protokolle neben dem Hypertext Transfer Protocol (HTTP) eingegangen. Weiters werden die gewünschten Erweiterungen für den TLS-Proxy vorgestellt. Gefordert waren die Unterstützung des SMTP- Protokolls, das Auslagern der Zertifizierungsstelle für eine gemeinsame Nutzung durch alle TLS-Proxys, die Möglichkeit, Nachrichten über ein Mail-Relay anstatt direkt an den Zielserver zuzustellen, sowie das Erzwingen von TLS-Sessions auf Client- oder Server-Seite. In Kapitel 5 wird die Aufgabenstellung detailliert beschrieben, die Struktur der SMTP- Unterstützung im Proxy erläutert, und es werden wichtige Designentscheidungen begründet. Auch wird untersucht, wie die Content-Filter (Viren-, Spamfilter) an den Proxy angebunden werden sollen und wie eine zentrale Zertifizierungsstelle realisiert werden kann. Kapitel 6 stellt die Implementierung des SMTPS-Proxy 2 genauer vor. Die verwendeten Entwicklungswerkzeuge sowie die Zielplattform werden präsentiert und wichtige Codeausschnitte erläutert. Kapitel 8 enthält den speziell für den Proxy entwickelten Testplan, der das erwartete Verhalten des SMTPS-Proxy unter Berücksichtigung der Konfigurationsmöglichkeiten beschreibt. Die zum Testen verwendeten Werkzeuge sowie die Testergebnisse werden ebenfalls präsentiert. Kapitel 9 enthält ein Handbuch zur Installation, Konfiguration und Benutzung des SMTPS- Proxy und zur Integration in konkrete Einsatzszenarien. 2 Die verschlüsselte Variante des Simple Mail Transfer Protocols (SMTPS)

11 Kapitel 2 Das Simple Mail Transfer Protocol 2.1 Aufbau des Simple Mail Transfer Protocol Dieses Kapitel beschreibt das Simple Mail Transfer Protocol (siehe RFC 821 [Pos82], bzw. RFC 5321 [Kle08]), seine Kommandos und Konzepte, soweit sie für einen SMTP- bzw. SMTPS-Proxy relevant sind oder das Verständnis unterstützen. SMTP ist für den Transport von elektronischen Mail-Nachrichten, sogenannten Mail Objects, zuständig. Der Sender benutzt SMTP, um seine Nachricht an einen SMTP-Server zu übergeben. Dieser Server kann entweder direkt der Host des Empfängers, ein passender SMTP-Server oder sogar der Host des Senders sein. Um eine Mail-Nachricht zustellen zu können, gibt der SMTP-Client (im Normalfall der Sender der Nachricht) dem SMTP-Server folgende Informationen: Die Herkunft der Nachricht (Reverse-Path) und das/die Ziel(e) der Nachricht sowie die Nachricht selbst. Der SMTP-Server kann sowohl Sender als auch Empfänger ablehnen oder akzeptieren. Der Server kann einen Empfänger auch dann akzeptieren, wenn er die Nachricht weiterleiten muss. Diese Übernahme einer Nachricht und die Weiterleitung wird SMTP-Relay genannt. Auf diese Weise kann eine Mail-Nachricht während ihrer Weiterleitung mehrere SMTP-Server passieren. Die zu transportierenden Mail Objects setzen sich aus den Komponenten Envelope und Content zusammen. Der Envelope besteht aus einer Reihe von SMTP-Kommandos, die zumindest die Quelle und das Ziel bzw. die Ziele spezifizieren. Der Content besteht wiederum aus zwei Teilen: dem Header und dem Body. Der genaue Aufbau ist in RFC 822 [Cro82] bzw. RFC 5322 [Res08] festgelegt. SMTP ist ein textbasiertes Protokoll, in dem Client und Server Kommandos und Statusinformationen jeweils als eine Zeile darstellen. Diese Kommandos bestehen aus einem Kommandowort mit vier Zeichen und optional aus Kommandoparametern welche mit einem Leerzeichen (SP für space) vom Kommandowort getrennt werden. Die maximale Länge einer 3

12 2. Das Simple Mail Transfer Protocol 4 HELO MAIL FROM: RCPT TO: DATA From: To: Date: Subject: Mail Text Envelope Content Header Body QUIT Abbildung 2.1: Aufbau von Mail-Objects, die mit SMTP transportiert werden Kommandozeile (inklusive Kommandowort und abschließendem CRLF) beträgt 512 octets. Kommandos und Parameter sind, mit Ausnahme des Mailbox local-part 1, nicht case-sensitive. Die Antworten bestehen aus einem dreistelligen numerischen Code für die maschinelle Verarbeitung und einem Text, der die Antwort genauer beschreibt. Der Client wertet die Antwort alleine auf Basis des numerischen Codes aus. Der Text kann als Status- bzw. Fehlermeldung an die Benutzer weitergereicht werden. SMTP-Kommandos und Antworten werden zeilenweise gesendet und mit einem Carriage- Return (CR) + Line-Feed (LF) abgeschlossen. Durch das Alter von SMTP ist anzumerken, dass die Zeichen des 7-Bit-US-ASCII-Zeichensatzes [Cer69] verwendet werden. Das bedeutet, dass auch bei einem 8-Bit-Übertragungskanal die 7 Bit in Least Significant Bit = niederwertigstes Bit (LSB) bis Most Significant Bit = höchstwertiges Bit (MSB) -1 übertragen werden und das MSB auf 0 gesetzt werden muss Ablauf einer SMTP-Session Zu Beginn einer SMTP-Session, also nach dem Aufbau der TCP-Verbindung 2, in der die SMTP-Session abgewickelt wird, sendet der Server eine Willkommensnachricht. Dieser Reply auf den TCP-Verbindungsaufbau mit Code 220 kann Informationen zur Software und zum Versionsstand bekanntgeben 3. Der Server kann an dieser Stelle die SMTP-Verbindung ablehnen, indem er anstatt eines 220-Codes den Wert 554 sendet. Beenden darf er die SMTP-Verbindung aber erst auf Kommando des Clients (siehe Abschnitt 2.1.2). Auch der Client stellt sich vor, indem er das Kommando HELO oder EHLO (falls er das 1 Eine Mailbox wird in der Form local-part@domain angegeben. 2 Transmission Control Protocol (TCP) 3 Diese Informationen können aber auch für mögliche Angreifer von Vorteil sein und sind deshalb mit Vorsicht zu verwenden.

13 2. Das Simple Mail Transfer Protocol 5 Extended Simple Mail-Transfer-Protocol (ESMTP) unterstützt) sendet. Als Parameter übergibt er seine Identifikation (typischerweise die Domäne). Wenn der Server ein EHLO empfängt, kann er in der Antwort mit Code 250 dem Client mitteilen, welche SMTP-Erweiterungen er unterstützt. An dieser Stelle sind beide Teilnehmer der Session bereit, eine Mail-Transaktion zu beginnen. Diese besteht aus folgenden Schritten: Als Start der Transaktion sendet der Client ein MAIL-Kommando und identifiziert damit den Absender. Der Server kann den Absender nun mit dem Antwort-Code 250 bestätigen oder mit Code 4xx bzw. 5xx ablehnen. Eine genaue Auflistung der Antwort-Codes findet sich in Abschnitt bzw Wurde der Absender bestätigt, kann der Client mit einem oder mehreren RCPT-Kommandos Empfänger angeben. Der Server hat auch hier die Möglichkeit, einzelne Empfänger zu bestätigen oder abzulehnen. Mit dem Kommando DATA leitet der Client nun die Übertragung des Mail-Content ein. Nachdem der Server das Data-Kommando mit Code 354 bestätigt hat, überträgt der Client den Content, welcher durch den end of mail-indikator abgeschlossen wird. Dieser Indikator wird durch eine Zeile bestehend nur aus einem Punkt dargestellt (siehe auch Abschnitt 2.1.3). Sobald der Server den Content mit dem Code 250 bestätigt hat, ist er für die weitere Zustellung der Nachricht verantwortlich. Nach der Transaktion kann der Client entweder mit einem neuerlichen Mail-Kommando eine neue Transaktion beginnen oder mit dem Kommando QUIT die Session beenden Ende einer SMTP-Session Normalerweise endet eine SMTP-Session, wenn der Client das QUIT-Kommando sendet und der Server darauf mit einem Code 221 antwortet. Der Server schließt daraufhin die TCP- Verbindung. Der Server darf von sich aus die Verbindung nur in folgenden Ausnahmefällen beenden: Wenn der Server feststellt, dass er den SMTP-Service beenden muss, muss er noch versuchen, dem Client vor Verbindungsabschluss eine Code-421-Antwort zu senden. Der Server darf die Verbindung auch beenden, falls beim Warten auf ein Client- Kommando oder auf Daten vom Client ein Timeout (siehe Abschnitt 2.1.9) aufgetreten ist. In RFC5321 [Kle08] wird explizit erwähnt, dass ein SMTP-Server die Verbindungen nicht abbrechen darf, selbst wenn er ein unbekanntes Kommando vom Client empfängt. Die korrekte Reaktion auf ein unbekanntes Kommando ist eine 500-Antwort, wonach auf weitere Anweisungen des Clients gewartet werden muss.

14 2. Das Simple Mail Transfer Protocol 6 Wenn ein Client einen TCP-Verbindungsabbruch erkennt, ohne eine entsprechende Benachrichtigung (421) des Servers empfangen zu haben, soll er trotzdem die aktive Transaktion als abgebrochen betrachten Behandlung des end of mail-indikators innerhalb des Mail-Textes Die Sequenz <CRLF>.<CRLF> dient als Kennzeichnung des Endes der Mail-Daten und darf deshalb nicht innerhalb des (vom Benutzer eingegebenen) Mail-Textes vorkommen. Die Kenntnis solcher verbotener Sequenzen kann aber von AnwenderInnen nicht vorausgesetzt werden. Der SMTP-Client hat jedoch die Möglichkeit, das Ende des Mail-Textes auf andere Weise zu erkennen. Wenn er nun am Anfang einer Zeile einen Punkt erkennt, dupliziert er ihn 4. Dadurch kann die Sequenz nicht mehr im Text auftreten. Der Server hat dabei die Aufgabe, jede Zeile darauf zu überprüfen, ob sie mit 2 Punkten beginnt. Ist dies der Fall, streicht er einen davon. Beginnt die Zeile nur mit einem Punkt wird die Sequenz als End Of Mail (EOM) Indikator betrachtet SMTP-Kommandos Dieses Kapitel beschreibt jene Kommandos, die ein SMTP-Server laut RFC5321 [Kle08] mindestens unterstützen muss. Diese Kommandos können vom Client nur dann verwendet werden, wenn nicht gerade Mail-Content übertragen wird. Die Syntax der beschriebenen SMTP-Kommandos und Return-Codes basiert auf der in [CO08] spezifizierten Augmented Backus Naur Form (ABNF), die wiederum auf der Backus Naur Form (BNF) aufbaut. Die ABNF wird in verschiedenen RFCs verwendet, um Syntax oder Kommunikationsprotokolle zu beschreiben. Die in diesem Kapitel gezeigte Syntax wurde aus [Kle08] entnommen HELO HELO wird von SMTP-Clients benützt, um sich beim SMTP-Server zu identifizieren. Als Parameter wird der Fully Qualified Domain Name = der vollständige Name einer Domain (FQDN) übergeben. Falls der Client keinen oder keinen sinnvollen 5 Domainnamen angeben kann, soll er zumindest seine Internet Protocol (IP)-Adresse übergeben. Der Client erwartet darauf eine einzeilige Antwort, im positiven Fall mit Code 250. Nach Empfang dieser Antwort sind beide Teilnehmer in einem Initialzustand und bereit, eine Transaktion zu beginnen. Syntax: helo = HELO SP Domain CRLF 4 Das ist eine Form des Character Stuffing oder Zeichenstopfens, wie es z. B. in [Tan98, Seite 203 ff.] beschrieben wird. 5 z. B. wenn der Domainname dynamisch zugewiesen wurde und kein Reverse-Eintrag existiert.

15 2. Das Simple Mail Transfer Protocol 7 1 HELO mail.example.com Listing 2.1: SMTP-Client identifiziert sich mit dem HELO-Kommando EHLO Das Kommando EHLO (Extended-Hello) erfüllt die gleiche Aufgabe wie HELO, signalisiert dem Server aber zusätzlich, dass der Client grundsätzlich ESMTP-Funktionalität unterstützt. Der Server kann diese in einem Multiline-Reply mit Code 250 ankündigen. Laut RFC5321[Kle08] muss er alle unterstützten Kommandos mit Hilfe von Schlüsselwörtern ankündigen, die nicht in der Liste der minimal vorausgesetzten Schlüsselwörter (Abschnitt 2.1.4) enthalten sind. Syntax: ehlo = EHLO SP ( Domain / address-literal ) CRLF 1 EHLO mail.example.com Listing 2.2: SMTP-Client identifiziert sich mit dem EHLO-Kommando MAIL Um eine Mail-Transaktion zu beginnen, sendet der Client ein MAIL-Kommando und gibt die Adresse der Mailbox des Absenders (Reverse-Path) als Parameter an. Diese Information kann der Server benutzen, um Fehlerberichte zuzustellen oder um zu entscheiden, ob der Absender berechtigt ist, Nachrichten zu senden. Zusätzlich existieren aber auch Benachrichtigungstypen, die einen leeren (<>) Reverse-Path verlangen. Dies sind Nachrichten, die sich auf eine vorhergehende Nachricht beziehen, wie Message Delivery Notification (MDN)[HV04] oder Delivery Status Notification (DSN)[Moo03]. Dadurch wird verhindert, dass wegen Unzustellbarkeit solcher Benachrichtigungen weitere Benachrichtigungen erzeugt werden. Syntax: mail = MAIL FROM: Reverse-path [SP Mail-parameters] CRLF 1 MAIL FROM:<jack@example.org> Listing 2.3: Spezifikation des Absenders mit dem MAIL-Kommando RCPT Das RCPT-Kommando (Recipient) kann vom Client mehrmals abgesetzt werden und spezifiziert jedes Mal einen individuellen Empfänger. Jeder dieser Empfänger wird vom Server entweder bestätigt (Code 250) oder abgelehnt (Code 4xx bzw. 5xx). Wie der Reverse-Path beim MAIL- Kommando spezifiziert auch der Forward-Path eine Mailbox, im Fall des RCPT-Kommandos die Mailbox des Empfängers.

16 2. Das Simple Mail Transfer Protocol 8 Syntax: rcpt = RCPT TO: ( <Postmaster@ Domain > / <Postmaster> / Forward-path ) [SP Rcpt-parameters] CRLF 1 RCPT TO:<joe@example.net> Listing 2.4: Spezifikation der Absender mit dem RCPT-Kommando DATA Die positive Antwort auf das Kommando DATA des Clients hat den Code 354 und signalisiert diesem, dass er mit dem Senden des Mail-Content beginnen kann. Alle darauf folgenden Zeilen werden vom Server solange als Teil dieses Content interpretiert, bis er den End-Of-Mail- Indikator (<CRLF>.<CRLF>) empfangen hat. Das erste CRLF im Indikator ist eigentlich das Zeilenende der vorherigen Contentzeile und weiters das letzte Zeichen, das der SMTP-Server weiterleitet (Relay) oder zustellt. Nach Erhalt des Indikators muss der Server den Reverse-Path, alle (akzeptierten) Forward-Paths und den Content verarbeiten und entscheiden, ob er die Mail-Nachricht annimmt (Code 250). Mit dem Senden des Return-Codes 250 übernimmt der Server die volle Verantwortung für die Nachricht. Tritt in der weiteren Verarbeitung ein Fehler auf, so muss der Server dies an den Absender (Reverse-Path) der Nachricht melden. Syntax: data = DATA CRLF 1 DATA Listing 2.5: Einleitung der Mail-Daten-Übertragung mit dem DATA-Kommando RSET Der SMTP-Client kann an jeder Stelle der Transaktion (jedoch nicht während der Übertragung des Mail-Content) ein RSET-Kommando (Reset) senden, um sie abzubrechen. Der Server muss darauf mit einem 250 Reply antworten und genauso wie der Client die gespeicherten Daten zur aktuellen Transaktion verwerfen. Falls gerade keine Transaktion im Gange ist, hat das Kommando keinen Effekt, muss aber trotzdem vom Server bestätigt werden. Das RSET Kommando ist aber kein Signal an den Server, die SMTP-Verbindung zu beenden (siehe Abschnitt 2.1.2). Syntax: rset = RSET CRLF 1 RSET Listing 2.6: Abbruch der Transaktion mit dem RSET-Kommando

17 2. Das Simple Mail Transfer Protocol NOOP Das NOOP-Kommando hat keinen Effekt auf die Transaktion, außer dass der Server es mit einer 250 Antwort bestätigen muss. Der Client kann es im SMTP-Dialog jederzeit mit oder ohne Parameter senden. Falls ein Parameter gesendet wird, muss ihn der Server ignorieren. Syntax: noop = NOOP [ SP String ] CRLF 1 NOOP Listing 2.7: Absenden eines Kommandos, das sich nicht auf die Transaktion auswirkt: NOOP QUIT Als Reaktion auf das Kommando QUIT antwortet der SMTP Server mit 221 OK und beendet dann die TCP-Verbindung. Weiters wird auch jede gerade aktive Transaktion abgebrochen. Der Server darf ansonsten die Verbindung nicht von sich aus unterbrechen (Ausnahmen siehe Abschnitt 2.1.2). Genauso soll der Client die Verbindung nicht abbrechen, bevor er QUIT gesendet und die Antwort empfangen hat. Falls die TCP-Verbindung trotzdem abbricht, müssen beide Teilnehmer die Transaktion so behandeln, als ob sie abgebrochen wäre. Syntax: quit = QUIT CRLF 1 QUIT Listing 2.8: Beenden der SMTP-Sitzung mit dem QUIT-Kommando VRFY Mit dem VRFY-Kommando (Verify) kann der Client beim Server nachfragen, ob der übergebene Parameter einen User oder eine Mailbox spezifiziert. In der Antwort kann der Server einerseits die Existenz der Mailbox oder des Users bestätigen und andererseits zusätzliche Informationen zum angefragten User zurückgeben. Aus Sicherheitsgründen 6 können SMTP-Server die VRFY- Funktionalität abschalten und 252 Cannot VRFY User zurückgeben, anstatt die Verifikation durchzuführen. Auf keinen Fall dürfen sie aber eine 250-Antwort zurückgeben, wenn der Parameter nicht verifiziert wurde. Syntax: vrfy = VRFY SP String CRLF 1 VRFY john Listing 2.9: Überprüfung mit dem VRFY-Kommando, ob ein User oder eine Mailbox auf dem Server existieren 6 z. B. um Spammern das Sammeln von Adressen nicht zu erleichtern.

18 2. Das Simple Mail Transfer Protocol SMTP Return Codes SMTP-Antworten bestehen aus einem dreistelligen Code gefolgt von einem beschreibenden Text. Der Code entspricht dem maschinenlesbaren Teil, während der Text für Menschen bestimmt ist. Im Code sind genug Informationen enthalten, damit der Client den Text nicht verarbeiten muss. Er kann ihn entweder verwerfen, mitprotokollieren oder an den User weiterleiten (z. B. in Fehlerfällen). Syntax: textstring = 1*(%d09 / %d32-126) ; Horizontal Tabulator (HT), SP, Printable US-ASCII Reply-line = *( Reply-code - [ textstring ] CRLF ) Reply-code = Reply-code [ SP textstring ] CRLF %x32-35 %x30-35 %x30-39 Zwar basiert die Syntax der Return-Codes bei SMTP auf jenen von FTP, jedoch wird die Klasse 1yz nicht verwendet Multiline Replies Vor allem bei Antworten auf das Kommando EHLO kann es vorkommen, dass der Text mehr als eine Zeile umfasst. In diesem Fall muss jede Zeile mit dem Reply-Code beginnen, der Text jeder Zeile außer der letzten wird nun mit einem - -Zeichen statt einem SP vom Reply-Code getrennt. Das Trennzeichen der letzten Zeile ist wiederum ein Leerzeichen. Die Antwort auf das Kommando EHLO hat damit folgende Syntax: Syntax: ehlo-ok-rsp = ( 250 SP Domain [ SP ehlo-greet ] CRLF ) / ( 250- Domain [ SP ehlo-greet ] CRLF *( 250- ehlo-line CRLF ) 250 SP ehlo-line CRLF ) mail.example.net STARTTLS SIZE 0 Listing 2.10: Mögliche Antwort auf das EHLO-Kommando Klasse 2yz Return Codes mit der Ziffer 2 an erster Stelle stehen für eine positive Rückmeldung. Weiters wird dadurch angezeigt, dass die Operation abgeschlossen wurde und ein neues Kommando gesendet werden kann mail.example.net Service ready Listing 2.11: Begrüßung des Servers nach dem TCP-Verbindungsaufbau

19 2. Das Simple Mail Transfer Protocol Klasse 3yz Das Kommando wurde zwar erfolgreich angenommen, zu dessen Abschluss fehlen dem Server aber noch weitere Informationen. Diese muss der Client im nächsten Kommando nachreichen Start mail input; end with <CRLF>.<CRLF> Listing 2.12: Antwort auf das DATA-Kommando Klasse 4yz Codes dieser Klasse zeigen an, dass das Kommando weder akzeptiert noch die davon angeforderte Aktion durchgeführt wurde. Allerdings ist dieser Fehlerzustand temporär und ein erneutes Senden dieses Kommandos könnte erfolgreich sein. Ein Client soll deshalb die Kommandosequenz zu einem späteren Zeitpunkt nochmals probieren Temporary problem, insufficient system storage Listing 2.13: Antwort des Servers, wenn nicht genug Speicherplatz zur Verfügung steht Klasse 5yz Im Gegensatz zur Klasse 4yz sind Fehler hier permanent (z. B. ein Server unterstützt ein Kommando nicht). Dementsprechend darf ein Client die gleiche Sequenz auch nicht erneut probieren Command not implemented Listing 2.14: Antwort des Servers, wenn ihm ein Kommando zwar bekannt ist, aber nicht unterstützt wird. Die zweite Stelle der Codes unterteilt die Antworten weiter in folgende Kategorien: Kategorie x0z Zu dieser Kategorie gehören sowohl Fehler in der Syntax als auch syntaktisch korrekte Kommandos, die nicht unterstützt werden Syntax error: line too long Listing 2.15: Antwort des Servers, wenn ein zu langes Kommando empfangen wurde Kategorie x1z Diese Kategorie enthält Antworten auf Anfragen nach Informationen, Status oder Hilfe Visit for help Listing 2.16: Antwort des Servers auf das HELP-Kommando

20 2. Das Simple Mail Transfer Protocol Kategorie x2z Die Antworten aus dieser Kategorie betreffen den Übertragungskanal mail.example.net Service closing transmission channel Listing 2.17: Antwort des Servers auf das QUIT-Kommando Kategorie x5z Diese Kategorie betrifft das Mail-System selbst Cannot VRFY, send some mail and i try my best Listing 2.18: Antwort des Servers auf das VRFY-Kommando Die Kategorien x3z und x4z sind unspezifiziert. Die dritte Stelle der Codes erlaubt eine weitere, feinere Unterteilung Bespiele für den Ablauf von SMTP-Sitzungen mail.example.net Service ready 2 EHLO mail.example.com mail.example.net STARTTLS SIZE 0 6 HELP Visit for help 8 VRFY john Cannot VRFY, send some mail and i try my best 10 MAIL FROM:<jack@example.org> OK 12 RCPT TO:<john@example.net> No such user here 14 RCPT TO:<joe@example.net> OK 16 DATA Start mail input; end with <CRLF>.<CRLF> 18 Date: :21: Subject: Hello 20 From: Jack <jack@example.org> 21 To: Joe <joe@example.net> Hello Joe 24 Whats up? OK 27 QUIT