Systeme II – 9te Vorlesung Lehrstuhl für Kommunikationssysteme Institut für Informatik / Technische Fakultät Universität Freiburg 2009 Lehrstuhl für Kommunikationssysteme - Systeme II

Letzte Vorlesung World Wide Web und HTTP TCP-basierter Dienst, der Anfang der 90er Jahre definiert wurde Applikationsschicht – Server und Browser Interaktion mit dem Benutzer Spezielle Seitenbeschreibungs- sprache (X)-HTML, die in der Client- Applikation auf Benutzerseite gerendert wird Früher einfache Datei auf Server, heute vielfach dynamisch generiert Lehrstuhl für Kommunikationssysteme - Systeme II

Letzte Vorlesung HTTP-Datenaustausch Request / Response mit einfache, zeilenorientierten Sequenzen vonZeichen Reihe verschiedener Request-Kommandos Responses mit bestimmten Statuscodes Lehrstuhl für Kommunikationssysteme - Systeme II

Electronic Mail Email eine der ältesten Anwendungen des Internets überhaupt, erste Spezifikation Anfang der 80er Jahre Einer der populärsten Dienste überhaupt Im Laufe der Zeit immer wieder erweitert worden von 7bit Textnachrichten zu Multi-Megabyte Anhängen beliebigen Formats Etliche Probleme (SPAM) resultieren aus altem Design An Email sind mehrere Protokolle beteiligt Stark mit DNS verknüpft Eigenen DNS Resource Record – MX (Mail Exchange) Lehrstuhl für Kommunikationssysteme - Systeme II

Electronic Mail Anwender sieht typischerweise nur eine Anwendung, die jedoch mehrere Protokolle mit evtl. unterschiedlichen Servern spricht Simple Mail Transfer Protocol (SMTP) Post Office Protocol (POP) Internet Message Access Protocol (IMAP) Lehrstuhl für Kommunikationssysteme - Systeme II

Email – Komponenten Begriffe (unterschiedlich stark verwendet) MUA Mail User Agent – Nachrichten lesen / schreiben MTA Mail Transfer Agent – Sicherstellung von Weiterleitung MDA Mail Delivery Agent – in Mailbox schreiben (lokal); zum ’nachsten’ MTA weiterleiten MRA Mail Retrieval Agent – aus der Mailbox lesen Die Applikation wird typischerweise als Mailreader oder als Mail User Agents (MUA) bezeichnet Verfassen von E-Mails Versenden von E-Mail über einen Mailserver Abrufen eingehender E-Mails von einem Mailserver Verwalten der Mailbox auf einem Mailserver Lehrstuhl für Kommunikationssysteme - Systeme II

Email – Komponenten Mailreader (MUA) Verfassen von E-Mails Versenden von E-Mail über einen Mailserver Abrufen eingehender E-Mails von einem Mailserver Verwalten der Mailbox auf einem Mailserver Lehrstuhl für Kommunikationssysteme - Systeme II

Email – Komponenten Lehrstuhl für Kommunikationssysteme - Systeme II

Email – Komponenten Mailserver (MTA – Mail Transfer Agents) Legen eingehende E-Mails der Nutzer in deren Mailboxes ab Nehmen von Nutzern gesendete E-Mails entgegen und leiten sie an andere Mailserver weiter Sprechen dazu mindestens eines der genannten Protokolle SMTP, POP3, IMAP Inzwischen oft um weitere Komponenten erweitert (die wiederum auf separate Maschinen ausgelagert sein können) SPAM-Abwehr Virenschutz Lehrstuhl für Kommunikationssysteme - Systeme II

Email – Komponenten Hierzu: Ermittlung des korrekten Mailserver des Empfängers der E- Mails E-Mails müssen gespeichert werden, falls Mailserver des Empfängers nicht erreichbar ist Lehrstuhl für Kommunikationssysteme - Systeme II

Aufbau einer Email Generelle Spezifikation [Briefkopf] (Header) From: Bob Mailman <bob.mailman@post.de> To: Chef <ceo@post.de>, Mitarbeiter <vor.name@post.de> Cc: Mama <chef2@daheim.de> Subject: Die elektronische Post [Textkorper] (Body) Hallo, so funktioniert E-Mail Tschau! . Lehrstuhl für Kommunikationssysteme - Systeme II

Aufbau einer Email Zusatzinfos beim dem Senden Bevor die E-Mail abgeschickt wird, wird die E-Mail mit weiteren Angaben versehen: Envelope Sender- und Empfangeradressen ohne Beschreibungstext z.B.: <example@exersice.uk> Date Zeit der Erstellung des Dokuments (notwendig) Massage-ID (eine Art Briefmarke) MIME-Version und Content-Type falls Nachricht diesen Strukturen folgt Reply-To Adresse des Verfassers Lehrstuhl für Kommunikationssysteme - Systeme II

SMTP Simple Mail Transfer Protocol, Ursprünge sind ziemlich alt Aufgabe: Transfer von E-Mails zwischen Mailservern Transfer von E-Mails von Mailreader an Mailserver Spezifikation, verschiedene RFCs RFCs 821,2 (August 1982) und 1870 (November 1995) bilden Standard No. 10, abgelöst durch 2822 in 2001 Festlegung auf Text (Probleme ab 64KB), Internet war “noch relativ sicher”, da weitgehend beschränkter akademischer Nutzerkreis Daher keine Authentifikation notwendig Ziel: Protokoll so einfach wie moglich Lehrstuhl für Kommunikationssysteme - Systeme II

SMTP SMTP Spezifikation durch verschiedene RFCs Ab November 1995 zum STD 10 erklart mit RFC1869 (’SMTP Service Extensions’) und RFC1870 (’SMTP Service Extension for Message Size Declaration’) J. Klensin (Ed.) - Simple Mail Transfer Protocol. RFC 2821, April 2001 SMTP setzt zuverlässiges Transportprotokoll (TCP) voraus Kontroll- und Nutzinformationen werden über einen Kanal (Port 25) übertragen Mailserver tauschen gegenseitig E-Mails aus – jeder Mailserver ist Client und Server Lehrstuhl für Kommunikationssysteme - Systeme II

SMTP Problem: Daten werden generell unverschlüsselt übertragen Sämtliche E-Mails müssen in 7-Bit US-ASCII codiert werden können! Verbindungsauf- und -abbau (Handshake, Greeting), Datenübertragung Syntax der Kommandos ähnlich zu FTP Prinzip der Kommunikation – Interaktion zwischen Server und Client folgendermassen: Client sendet definierte Kommandos mit Parametern und Daten an den Server Der Server antworten per Server Responde Codes Ein (einwandfreier) Dialog erfolgt in (x) mehreren Schritten Lehrstuhl für Kommunikationssysteme - Systeme II

SMTP – Kommandos (Core) Befehle des Basis-Kommando-Sets HELO/EHLO Anmeldung/Identifikation des Clients MAIL Transaktion wird initiiert; Adresse des Senders RCPT Indentifiziert einen einzelnen Empfanger DATA Sendet Nachricht zum Server RSET Übertragung wird abgebrochen VRFY Prüft ob Ziel Mailbox (EXPN) Teilnehmer der Mailing Liste anzeigen (HELP) Hilfe zu Befehlen NOOP Kein Vorgang QUIT Schließen des Kommunikationskanals Lehrstuhl für Kommunikationssysteme - Systeme II

SMTP – Email verschicken telnet mailserver.domain.de 25 220 msrv.domain.de ESMTP Sendmail 8.12.9; Tue, 18 Oct 2008 15:07:29 +0100 (CET) HELO mua.sub.domain.de 250 msrv.domain.de Hello mua.sub.domain.de [13.175.12.7], pleased to meet you MAIL FROM: user@mua.sub.domain.de 250 2.1.0 user@mua.sub.domain.de... Sender ok RCPT TO: anderer@msrv.domain.de 250 2.1.5 anderer@msrv.domain.de... Recipient ok Mailkopf klar, nun Text, Daten ... Lehrstuhl für Kommunikationssysteme - Systeme II

SMTP – Email verschicken DATA 354 Enter mail, end with "." on a line by itself Subject: TEST Email testing to talk directly to SMTP server more text ... . 250 2.0.0 h9MI7Tmo005722 Message accepted for delivery QUIT 221 2.0.0 msrv.domain.de closing connection Mail beendet und verschickt (einfach mal selbst ausprobieren) Lehrstuhl für Kommunikationssysteme - Systeme II

SMTP – Response Codes Mail Server Response Codes Code Bedeutung 1xx Befehl akzeptiert, jedoch gestoppt ⇒ anhalten / fortfahren? 2xx Befehl erfolgreich ausgefuhrt ⇒ nachster Befehl 3xx Befehl akzeptiert, jedoch gestoppt ⇒ Zusatzangaben 4xx Temporarer Fehler 5xx Standiger Fehler x0x Syntax x1x Information x2x Verbindung x3x Nicht spezifiziert x4x Nicht spezifiziert x5x Mail System xxY Genauere Beschreibung der Kategorie (aus 2 digit) Lehrstuhl für Kommunikationssysteme - Systeme II

SMTP – Response Codes Mail Server Response Code Beispiele (teilweise im Kommunikationsablauf gesehen) Code Bedeutung 220 < domain > Service ready 221 < domain > closing connection 250 Ok 354 Enter mail, end with ’.’ 421 < domain > Service not available 452 Insufficient system storage 500 Command unrecognized 501 Error in parameters or arguments 554 Transaction failed Lehrstuhl für Kommunikationssysteme - Systeme II

SMTP – Erweiterung Multipurpose Internet Mail Extensions zur: Übertragung binärer Daten in E-Mails Anhängen von Dateien an E-Mails (Attachments) Spezifikation durch: N. Freed, N. Borenstein. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. RFC 2045, 47 in 1996 N. Freed, N. Borenstein. Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. RFC 2046 November 1996 Lehrstuhl für Kommunikationssysteme - Systeme II

SMTP – Erweiterung MIME Eigenschaften Erweitert SMTP um zusätzliche Header (MIME Header) Header Content-Type: gibt Typ der binären Daten an (MIME- Type) Header Content-Encoding: gibt Codierung der binären Daten an Eine E-Mail darf mehrere Attachments enthalten Jedoch ohne Angabe von MIME-Headern wird weiterhin Text mit 7-Bit US-ASCII erwartet Lehrstuhl für Kommunikationssysteme - Systeme II

SMTP – MIME Header Syntax MIME-Header Header Content-Type: Aufbau: Content-Type: type/subtype; parameters Anhand subtype wird häufig externe Applikation (Viewer) gestartet Angabe von Parametern ist optional Beispiele für type/subtype Lehrstuhl für Kommunikationssysteme - Systeme II

SMTP – MIME Header Syntax MIME-Header Header Content-Transfer-Encoding: Aufbau: Content-Transfer-Encoding: mechanism Mailreader kann bei unbekanntem mechanism Inhalt der E-Mail nicht darstellen Typische eingesetzte Verfahren: base64, 7bit, 8bit, binary, quoted-printable Lehrstuhl für Kommunikationssysteme - Systeme II

SMTP – MIME Header Anmerkungen Subject: Multipart Test MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=“---------- 060003040705070005060705” ------------060003040705070005060705 Test Teil 1 – nur Text. Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data Test Teil 3 – wieder nur Text Anmerkungen Boundary darf nicht im Body der E-Mail vorkommen Deshalb in der Regel eine lange Folge zufälliger Zeichen Anhand der boundary Rückschlüsse auf den MUA möglich Lehrstuhl für Kommunikationssysteme - Systeme II

Mailbox Zugriff Bisher Spezialisierte Protokolle für den Zugriff Transfer von E-Mails zwischen Mailservern Transfer von E-Mails zwischen Mailreader und Mailserver (nur diese Richtung!) Wie kommt Mailreader (User) an seine empfangenen Mails ran? Spezialisierte Protokolle für den Zugriff POP(3) – Post Office Protocol IMAP(4) – Internet Message Access Protocol Lehrstuhl für Kommunikationssysteme - Systeme II

Post Office Protocol (v3) Problem – eigener Rechner nicht die ganze Zeit online zum Mailempfang, Mail gespeichert in Mailbox auf Mailserver POP3 (Post Office Protocol) ist einfaches Mail-Zugriffs- Protokoll Beschrieben in RFC 1939 Dynamische Kommunikation eines Clients mit einer Mailablage Im Normalfall Mails nur herunter geladen und dann vom Server gelöscht TCP am Port 110 POP3 Befehle bestehen aus Nicht-Case-Sensitiven ASCII Zeichen Schlüsselwörter und Argumente durch ein Leerzeichen getrennt Lehrstuhl für Kommunikationssysteme - Systeme II

Post Office Protocol (v3) POP3 Server-Antwort besteht aus Statusmeldung ( „+OK“ oder „-ERR“) und Schlüsselwort Meldung kann bis zu 512 Zeichen lang sein Kommunikation findet in drei Phasen statt Autorisierungsphase Client meldet sich an Transaktionsphase Client fordert vom Server Aktionen Udate-Phase Aktionen werden entgültig vollzogen Lehrstuhl für Kommunikationssysteme - Systeme II

Post Office Protocol (v3) POP Befehle: Authorisierungsphase USER name - Mailbox-Besitzer PASS string – Passwort des Mailbox-Besitzers QUIT – Abbruch der Aktion APOP name digest (optional) - Problem der unverschlüsselten Verbindung Vermeidung Klartextpasswort (via PASS) – Server sendet zu Beginn der Session einen Timestamp, das zweite Argument beinhaltet eine MD5 Verschlüsselung des Timestamps (shared secret) Lehrstuhl für Kommunikationssysteme - Systeme II

Post Office Protocol (v3) POP Befehle: Transaktionsphase STAT – Gibt Anzahl der Nachrichten und deren Größe als Oktalzahl an LIST [msg] – Wird kein Argument gegeben werden alle Nachrichten aufgelistet, sonst die Nachricht mit der angegebenen Nummer in Byte RETR msg – Nachricht Nr. [msg] wird herunter geladen DELE msg – Nachricht Nr. [msg] wird zum löschen markiert NOOP – Mache nichts (ähnlich wie auch bei SMTP) Lehrstuhl für Kommunikationssysteme - Systeme II

Post Office Protocol (v3) Transaktionsphase: RSET – Alle als gelöscht markierten Nachrichten werde wieder in den Ausgangszustand gesetzt TOP msg n [m] – (optionaler Befehl) schicke Header der Mail(s) n (-m) UIDL [msg] (optional) – Ordnet jeder Nachricht eine eindeutige ID zu Update Phase QUIT – Führe vorher markierte Aktionen aus (löschen) Recht einfaches Protokoll, so können Nachrichten nur einmal herunter geladen werden – Alternative IMAP Lehrstuhl für Kommunikationssysteme - Systeme II

Internet Message Access Protocol Beschrieben z.B. in RFC 3501 (IMAP4) Kein Download der Mails vom Server auf lokalen Rechner notwendig, aber möglich Zugriff auf Server-Verzeichnisse wie auf lokale Verzeichnisse Manipulation von Mailverzeichnissen auf dem Server (Erstellen, Umbenennen, Löschen; Setzen/Löschen von Flags; Suchen von Mails) Offline-Betrieb und Resynchronisation mit dem Server Vorteile Zugriff auf zentrale Mailbox von verschiedenen Arbeitsplätzen aus (gleiche Sicht unabhängig vom Standort) Inzwischen von allen gängigen Mail-Clients unterstützt Lehrstuhl für Kommunikationssysteme - Systeme II

Ende der siebten Vorlesung Ende der neunten Vorlesung Ende der siebten Vorlesung Damit Abschluss der Applikationsschicht Implizit schon benutzt: TCP, UDP, Portnummern – Protokolle und Eigenschaften der Transportschicht Die Schicht zwischen IP und den Anwendungen Lehrstuhl für Kommunikationssysteme - Systeme II

Ende der siebten Vorlesung Ende der neunten Vorlesung Ende der siebten Vorlesung Pfingstpause, weiter geht es am Montag, den 8.6. mit der praktischen Übung und am Mittwoch, den 10.6. mit der nächsten Vorlesung Alle relevanten Informationen auf der Webseite zur Vorlesung: http://www.ks.uni- freiburg.de/php_veranstaltungsdetail.php?id=28 Vorbereitung: Lesen des Kapitels 3 im Kurose&Ross und zu Transportschicht in der angegebenen Literatur! Lehrstuhl für Kommunikationssysteme - Systeme II