. Ute Bormann, Rechnernetze

Transkript

1 Work in progress Ute Bormann, Rechnernetze

2 Vergleich mit klassischer Brief-Kommunikation 2

3 Vergleich mit klassischer Brief-Kommunikation 3

4 Zwei deutlich getrennte Verantwortungsbereiche In MHS (OSI-Mailing): Im Internet: 4

7 Message Handling Systems (MHS) CCITT X.400ff / ISO (Variante) Electronic Mailing Dienst im OSI-Umfeld Umfassende Konzepte daher im folgenden kurz betrachtet De facto keine praktische Bedeutung Setzt als Anwendungsschicht auf OSI-Protokollen auf: [ASN.1 + ROSE + weitere Zwischenschichten nicht weiter betrachten] Zwei Teilschic User Agent Layer (UAL): Kommunikation über den Nachrichtenkopf (Verwaltungsinformationen der Nachricht) Message Transfer Layer (MTL): Beförderung der Nachricht aufgrund der Umschlaginformationen 7

8 Message Handling Systems (MHS) CCITT X.400ff / ISO (Variante) Electronic Mailing Dienst im OSI-Umfeld Umfassende Konzepte daher im folgenden kurz betrachtet De facto keine praktische Bedeutung Setzt als Anwendungsschicht auf OSI-Protokollen auf: [ASN.1 + ROSE + weitere Zwischenschichten nicht weiter betrachten] Zwei Teilschichten User Agent Layer (UAL): Kommunikation über den Nachrichtenkopf (Verwaltungsinformationen der Nachricht) Message Transfer Layer (MTL): Beförderung der Nachricht aufgrund der Umschlaginformationen 8

9 Funktionalität des UAL Verschiedene anwendungsabhängige Ausprägungen unterscheidbar, insbes. Interpersonal Messaging Service (IPMS) Nachrichtenaustausch zwischen Menschen (eigentliches Mailing) Empfängerspezifikation Kopieempfänger (auch Blind Copy) Bestätigung des Empfangs erwünscht Antwortschreiben erwünscht Antwortschreiben Weitergeleitete Nachricht Verantwortlicher Ablaufdatum Thema Querverweise Wichtigkeit Sicherheitsvermerk Art der Inhaltsinformationen (z.b. (ASCII-)Text, Fax, ForwardedMessage, weitere Formate...) Unterdokumente ( Anlagen ) Davon abgegrenzt: Electronic Data Interchange (EDI) Handelsdatenaustausch zwischen Maschinen (Bestellungen, Rechnungen,...) 9

10 Funktionalität des MTL Verteilung der Nachrichten vom Sender zu dem/den Empfänger/n Ermittlung der Sender-/Empfängeradressen über X.500 (evtl. Auflösen von Verteilerlisten) Ggf. Anfordern/Senden von Auslieferungsbestätigung Ggf. Mitteilen des Sende-/Empfangszeitpunkts Ggf. verzögerte Versendung Ggf. Versendung an alternativen Empfänger Ggf. Speicherung im System Verschiedene Dringlichkeiten der Zustellung Versendung von Probenachrichten (Theoretisch auch:) Kodierungsumwandlung zwischen Informationstypen Verschlüsselung, Authentisierung In ASN.1 kodiert, Client-/Server-Modell auf ROSE-Basis 10

11 MHS-Architektur Zusammensetzung einer MTL-Nachricht 11

12 MHS-Architektur Zusammensetzung einer MTL-Nachricht 12

13 Electronic Mailing im Internet Setzt als Anwendung direkt auf TCP auf Zwei Teilschichten: 13

14 RFC 822 ( mittlerweile RFC 2822) Kommunikation über den Nachrichtenkopf Jedes Attribut in eigener Zeile Spezielles ASCII-Format für Verwaltungsinformationen Festgelegte Schlüsselwörter: From:... Subject:... To:... CC:... BCC:... Date:... In-Reply-To:.... Nachrichteninhalt wird einfach angehängt (mit Leerzeile dazwischen) 14

15 SMTP: Simple Mail Transfer Protocol (RFC 2821) Beförderung der Nachricht aufgrund der Umschlaginformationen: Empfängerspezifikation (RCPT) An wen soll Nichtzustellbarkeitsvermerk gesendet werden? (MAIL) ASCII-Protokoll mit 4-buchstabigen Kommandos und 3-ziffrigen Antwortcodes (+ Kommentar) spezielles Client-/Server-Modell Aufbau der Adressinformationen: (z.b. Nachrichteninhalt endet mit Zeile, auf der nur ein Punkt steht Max. Zeilenlänge: 1023 Zeichen in klassischem SMTP erstmal nur ASCII-Nachrichten unterstützt keine Datentransparenz Abhilfe: MIME (Multipurpose Internet Mail Extension) 15

16 SMTP: Simple Mail Transfer Protocol (RFC 2821) Beförderung der Nachricht aufgrund der Umschlaginformationen: Empfängerspezifikation (RCPT) An wen soll Nichtzustellbarkeitsvermerk gesendet werden? (MAIL) ASCII-Protokoll mit 4-buchstabigen Kommandos und 3-ziffrigen Antwortcodes (+ Kommentar) spezielles Client-/Server-Modell Aufbau der Adressinformationen: (z.b. Nachrichteninhalt endet mit Zeile, auf der nur ein Punkt steht Max. Zeilenlänge: 1023 Zeichen in klassischem SMTP erstmal nur ASCII-Nachrichten unterstützt keine Datentransparenz Abhilfe: MIME (Multipurpose Internet Mail Extension) 16

17 Beispiel für klassischen SMTP-Dialog Ist nur einfaches Beispiel, muss nicht genauso umgesetzt sein (... TCP-Aufbau: Angabe von SMTP-Server-Port 25...) 220 opal.cs.tu-berlin.de SMTP Service at 29 May 87 09:15: HELO tub.cs.tu-berlin.de 250 opal.cs.tu-berlin.de - Hello tub.cs.tu-berlin.de MAIL FROM:<ute@tub.cs.tu-berlin.de> 250 MAIL accepted RCPT TO:<cabo@cs.tu-berlin.de> 250 Recipient accepted DATA 354 Start mail input; end with <CRLF>.<CRLF> Date: Sat, 29 May From: ute@tub.cs.tu-berlin.de To: cabo@cs.tu-berlin.de Subject: meeting Let's get together today at 3 pm OK QUIT 221 opal.cs.tu-berlin.de Service closing transmission channel 17

18 MIME (Multipurpose Internet Mail Extensions) Klassische Internet-Mail: SMTP + RFC 822 Basierte zunächst auf ASCII-Texten Multi-Media -Erweiterung MIME Aufgaben: Transport von Nicht-ASCII-Informationen Identifikation von Formaten Nachrichtenstrukturierung (z.b. für alternative Darstellung, für Anlagen, ) Grundlage: Setzt auf SMTP auf Aber: Klassisches SMTP kann nur 7-Bit-ASCII transportieren Zeilen max Zeichen Nachrichtenende: Zeile mit einzelnem Punkt keine Binär-Dateien versenden 18

19 MIME (Multipurpose Internet Mail Extensions) Klassische Internet-Mail: SMTP + RFC 822 Basierte zunächst auf ASCII-Texten Multi-Media -Erweiterung MIME Aufgaben: Transport von Nicht-ASCII-Informationen Identifikation von Formaten Nachrichtenstrukturierung (z.b. für alternative Darstellung, für Anlagen, ) Grundlage: Setzt auf SMTP auf Aber: Klassisches SMTP kann nur 7-Bit-ASCII transportieren Zeilen max Zeichen Nachrichtenende: Zeile mit einzelnem Punkt keine Binär-Dateien versenden 19

20 Transport von Nicht-ASCII-Informationen Neue Header-Zeile: Content-Transfer-Encoding 7-Bit: Information passt in klassisches SMTP 8-Bit: Erweitertes SMTP vorausgesetzt, evtl. Konvertierung durch MTA Quoted-Printable: Im großen und ganzen 7-Bit, = als Escape-Zeichen für 8-Bit-Zeichen gemäß ISO (Latin1) in Hex-Kodierung sowie abweichende Zeilenenden Beispiel: Gr=FC=DFe Grüße Latin1-Kodierung von ü ist = F16C16 =FC in Quoted-Printable Base-64: 3 Bytes werden mit 4 Zeichen repräsentiert (3x8 = 4x6) Nur 2 6 =64 ASCII-Zeichen verwenden mehrdeutige Zeichen vermeiden (z.b. Punkt) Nicht-ASCII-Informationen in Headerzeilen (z.b. From/To/Subject) spezielle Kodierung vorgesehen From: =?ISO ?Q?J=F6rg Ott?= 20

21 ISO (Latin 1) 21

22 Transport von Nicht-ASCII-Informationen Neue Header-Zeile: Content-Transfer-Encoding 7-Bit: Information passt in klassisches SMTP 8-Bit: Erweitertes SMTP vorausgesetzt, evtl. Konvertierung durch MTA Quoted-Printable: Im großen und ganzen 7-Bit, = als Escape-Zeichen für 8-Bit-Zeichen gemäß ISO (Latin1) in Hex-Kodierung sowie abweichende Zeilenenden Beispiel: Gr=FC=DFe Grüße Latin1-Kodierung von ü ist = F 16 C 16 =FC in Quoted-Printable Base-64: 3 Bytes werden mit 4 Zeichen repräsentiert (3x8 = 4x6) Nur 2 6 =64 ASCII-Zeichen verwenden mehrdeutige Zeichen vermeiden (z.b. Punkt) Nicht-ASCII-Informationen in Headerzeilen (z.b. From/To/Subject) spezielle Kodierung vorgesehen From: =?ISO ?Q?J=F6rg Ott?= 22

25 Neue Header-Zeile: Content-Length Zur einfacheren Abgrenzung von Nachrichten in Mail-Foldern Identifikation von Formaten Neue Header-Zeile: Content-Type text/plain; charset=us-ascii text/plain; charset=iso text/richtext application/postscript... image/jpeg... audio/mpeg... video/mpeg... message/rfc822 (eingebettete RFC822-Nachricht) 25

26 Neue Header-Zeile: Content-Length Zur einfacheren Abgrenzung von Nachrichten in Mail-Foldern Identifikation von Formaten Neue Header-Zeile: Content-Type text/plain; charset=us-ascii text/plain; charset=iso text/richtext application/postscript... image/jpeg... audio/mpeg... video/mpeg... message/rfc822 (eingebettete RFC822-Nachricht) 26

27 Strukturierung von Nachrichten Content-Type: multipart/mixed (Mehrere Bestandteile unterschiedlicher Typen) multipart/parallel (Audio + Video synchronisiert) multipart/alternative (Alternative Darstellung derselben Informationen, z.b. Grafik und Ersatztext) Abgrenzung zwischen Bestandteilen: Content-Type: multipart/mixed; boundary=fasel --fasel Content-Type: text/plain; charset=us-ascii... --fasel Content-Type: application/postscript... --fasel-- 27

28 Strukturierung von Nachrichten Content-Type: multipart/mixed (Mehrere Bestandteile unterschiedlicher Typen) multipart/parallel (Audio + Video synchronisiert) multipart/alternative (Alternative Darstellung derselben Informationen, z.b. Grafik und Ersatztext) Abgrenzung zwischen Bestandteilen: Content-Type: multipart/mixed; boundary=fasel --fasel Content-Type: text/plain; charset=us-ascii... --fasel Content-Type: application/postscript... --fasel-- 28

29 SMTP Extensions SMTP in Originalversion auf die Dauer zu simple! EHLO: Erweiterungsmechanismus IANA registriert Keywords/Parameter für Erweiterungen Am Anfang einer Mail-Session Fähigkeiten der Empfänger erfragen EHLO-Kommando statt HELO Alter Empfänger reagiert mit Fehlermeldung Rückfallen auf Original-SMTP möglich Beispieldialog:... EHLO tub.cs.tu-berlin.de 250-opal.cs.tu-berlin.de BITMIME 250-DSN (ggf. Auflistung weiterer Erweiterungen)

30 DSN: Delivery Status Notification Im Original-SMTP: Non-Delivery Notification als Mail ( free-form ) zurück an bei FROM angegebenen Nutzer inflexibel, nicht formalisiert DSN: Sender spezifiziert gewünschte Form von Bestätigung (als zusätzliche Parameter des Mail-Dialogs) In RCPT: NOTIFY: SUCCESS (positive Bestätigung) FAILURE (negative Bestätigung) NEVER (keine Bestätigung) DELAY ORCPT: (noch keine Zustellung möglich, wird weiter probiert) (enthält Angabe des Originalempfängers Info für Empfänger bei z.b. Weiterleitung) In MAIL: RET: (Welcher Teil der Mail kommt in DSN zurück) FULL (der ganze Inhalt, nur bei FAILURE) HDRS (nur der Header) ENVID: (Mail-ID zum Zuordnen der Bestätigung) DSN Message als MIME Message (Multipart/Report) repräsentiert 30

31 Beispiel: EHLO tub.cs.tu-berlin.de 250-opal.cs.tu-berlin.de DSN MAIL RET=HDRS ENVID=QQ ok RCPT NOTIFY=SUCCESS,FAILURE 250 recipient accepted... Weitere SMTP-Erweiterungen: Pipelining: asynchrone RPCs mehrere Kommandos direkt hintereinander senden ohne Bestätigung des vorigen abzuwarten allerdings weiterhin sequentiell (kein zusätzlicher Bezeichner nötig)... 31

32 Beispiel: EHLO tub.cs.tu-berlin.de 250-opal.cs.tu-berlin.de DSN MAIL RET=HDRS ENVID=QQ ok RCPT NOTIFY=SUCCESS,FAILURE 250 recipient accepted... Weitere SMTP-Erweiterungen: Pipelining: asynchrone RPCs mehrere Kommandos direkt hintereinander senden ohne Bestätigung des vorigen abzuwarten allerdings weiterhin sequentiell (kein zusätzlicher Bezeichner nötig)... 32

33 Internet-Mailing-Architektur (grob) Allerdings: a) SMTP-Server muss nicht auf Empfängersystem sein Empfangene Mails werden auf Serversystem gespeichert verschiedene Formen des Fernzugriffs Dateisystemzugriff (lokal, NFS; GNUS: bei Start neue Mail in UA laden) POP3 IMAP4 Web-Schnittstelle (intern oft IMAP4, auch für Versenden von Mails nutzbar) 33

36 Exkurs: Fernzugriff bei MHS (OSI-Mailing) Allgemeines Konzept des Fernzugriffs UAs verfügen nicht unbedingt über einen eigenen Nachrichtenspeicher Temporärer Speicher (Message Store, MS) zwischen UA und MTA Benutzerbezogen Versenden: MS reicht weiter Empfangen: MS speichert zwischen Fernzugriff auf MS über Protokoll P7 Summarize: Zusammenfassungen der Nachrichten List: Auflisten nach bestimmten Kriterien Fetch: Informationsabruf Delete: Eintrag löschen Alert: Benachrichtigung über neue Nachrichten Register-MS: MS konfigurieren 36

37 Post Office Protocol (POP3) ASCII-Protokoll Anzeigen einer Übersicht von empfangenen Nachrichten Nachrichten auf Empfängersystem übertragen ( offline lesen) und im Server löschen (Normalfall) Problematisch, wenn man Mails von mehreren Rechnern aus liest Keine Synchronisation mit Server über Lesevorgang 37

38 Internet Mail Access Protocol (IMAP4) RFC 3501 Deutlich flexiblere Schnittstelle (offline/online lesen) Mails primär auf Server verwaltet auch von mehreren Rechnern aus zugreifbar (auch User-Gruppen möglich) Grundsätzlicher Aufbau (vereinfacht): Setzt auf TCP auf Verbindungsaufbau + Authentisierung a) Name + Passwort (heute oft in TLS eingebettet) b) Kryptografie-basiert (verschiedene Varianten) Synchronisation zwischen Server-Daten und lokalen Kopien (welche Mails seither gelesen, markiert,...) Verbindung bleibt erstmal bestehen kontinuierliche Synchronisation möglich Mehrere Mailboxen (für Sortierung) ASCII-Protokoll, Client-/Server-Modell 38

39 Vereinfachtes Beispiel:... Verbindungsaufbau + Authentisierung + Anfangssynchronisation... A142 SELECT INBOX * 172 EXISTS * OK [UNSEEN 12] (12 ist erste unseen) * FLAGS (\Answered \Flagged \Deleted \Seen) A142 OK SELECT completed A143 FETCH 12 (FLAGS ENVELOPE BODY) * 12 FETCH... A143 OK FETCH completed... Lesen... A144 STORE 12 + FLAGS (\seen) * 12 FETCH (FLAGS (\seen)) A144 OK STORE completed 39

40 Wesentliche Kommandos (nicht vollständig) CREATE/DELETE/RENAME Mailbox EXAMINE/STATUS Mailbox SELECT/CLOSE Mailbox SUBSCRIBE/UNSUBSCRIBE Mailbox APPEND Mailbox ggf. Flags Message SEARCH... (Mailbox (de)aktivieren) (Eigenschaften von Mailbox herausfinden) (ausgewählte Mailbox nach Suchkriterien durchsuchen) A145 SEARCH UNSEEN SINCE 1-JUN * SEARCH A145 OK SEARCH completed FETCH... (angegebene Informationen der angegebenen Mails holen) A146 FETCH 22:24 (FLAGS ENVELOPE BODY) * 22 FETCH... * 23 FETCH... * 24 FETCH... A146 OK FETCH completed 40

41 STORE... (angegebene Informationen für angegebene Mails speichern) A147 STORE 52 +FLAGS (\Deleted) * 52 FETCH (FLAGS (\Deleted \Seen)) A147 OK STORE completed Argument: FLAGS vs. +FLAGS vs. -FLAGS FLAGS vs. FLAGS.SILENT EXPUNGE (alle als deleted markierten Mails löschen automatisch bei CLOSE) A148 EXPUNGE * 2 EXPUNGE * 2 EXPUNGE * 4 EXPUNGE * 5 EXPUNGE A148 OK EXPUNGE completed (Mails \deleted) (Nummernraum: Message Number ist relativ (vs. eindeutige UID)) 41

42 Fehlermeldungen in IMAP Statt OK-Rückmeldung 2 Fehlervarianten: NO: Anfrage im Grundsatz sinnvoll, aber nicht durchführbar BAD: grundsätzlich unsinnige Anfrage Bei Antworten werden automatisch neue Server-Informationen geliefert A149 STORE 22 +FLAGS (\seen) * 22 FETCH (FLAGS (\seen)) * 173 EXISTS A149 OK STORE completed Ursprüngliches Problem: Anzeige setzt aktive Anfrage voraus 42

43 Ursprünglich: Regelmäßige Anfrage nach neuer Mail nötig, keine automatische Anzeige Mittlerweile auch Push-Mail (IDLE-Kommando): A150 IDLE * 174 EXISTS * 15 EXPUNGE + idling... * 174 EXISTS DONE A150 OK IDLE terminated A151 FETCH 174 FULL * 174 FETCH... A151 OK FETCH completed 43

44 Internet-Mailing-Architektur (grob) Allerdings: b) SMTP-Client muss keine End-zu-End-Verbindung zu Empfänger-Server haben Sendesystem muss nicht verfügbar sein, bis Mail im Mail-Server der Empfänger-Domain ausgeliefert wurde SMTP-Submission-Server erhält Auftrag zur Weiterleitung (Authentisierung des Clients nötig, um Spam-Versand zu erschweren andere Portnummer) 44

45 Internet-Mailing-Architektur (grob) Allerdings: b) SMTP-Client muss keine End-zu-End-Verbindung zu Empfänger-Server haben Sendesystem muss nicht verfügbar sein, bis Mail im Mail-Server der Empfänger-Domain ausgeliefert wurde SMTP-Submission-Server erhält Auftrag zur Weiterleitung (Authentisierung des Clients nötig, um Spam-Versand zu erschweren andere Portnummer) 45

46 Sonderfall: Versenden von Mails an mehrere Empfänger Exkurs: Mehrere Empfänger in MHS: Hierarchische Verteilung über MTA-Zwischensysteme Optimierung der Verteilung durch Erzeugen von Kopien unterwegs Statt: In MHS: Dann keine End-zu-End-Verbindungen zwischen Sender- und Empfänger-MTA (aber nicht Netz-bedingt, sondern auf Anwendungsebene) 46

47 Mehrere Empfänger in SMTP a) Angabe von mehreren RCPT-Zeilen möglich a1) Zwischen Client und Submission-Server: Submission-Server erfragt MX-Records der adressierten Empfänger-Domains Zu jedem Server Aufbau TCP-Verbindung (Port 25) und Versendung aller zugehörigen Mails a2) Zwischen Submission-Server und Delivery-Server Alle Mails müssen an denselben Delivery-Server adressiert sein b) Verwendung von Verteilerlisten (bzw. Mail-Alias) Mail wird an zuständigen Delivery-Server gesendet Der ermittelt die/den Empfänger und leitet weiter 47

50 Funktionalität des UAL To: CC/BCC: In-Reply-To: Resent-To: From: Expires: Subject: References: Priority: RFC 822 Content-Type (MIME):...Multi-Part (MIME): Empfängerspezifikation Kopieempfänger (auch Blind Copy) Bestätigung des Empfangs erwünscht Antwortschreiben erwünscht Antwortschreiben Weitergeleitete Nachricht Verantwortlicher Ablaufdatum Thema Querverweise MHS Wichtigkeit Sicherheitsvermerk Art der Inhaltsinformationen (diverse Formate) Unterdokumente ( Anlagen ) + weitere Header-Zeilen 50

51 Funktionalität des MTL SMTP SMTP (kein expliziter Verteilbaum) DNS (MX-Records) DSN DSN(Date: /Received:) POP/IMAP (SMTP-Dialog) MHS Verteilung der Nachrichten vom Sender zu dem/den Empfänger/n Ermittlung der Sender-/Empfängeradressen über X.500 (evtl. Auflösen von Verteilerlisten) Ggf. Anfordern/Senden von Auslieferungsbestätigung Ggf. Mitteilen des Sende-/Empfangszeitpunkts Ggf. verzögerte Versendung Ggf. Versendung an alternativen Empfänger Ggf. Speicherung im System Verschiedene Dringlichkeiten der Zustellung Versendung von Probenachrichten (Theoretisch auch:) Kodierungsumwandlung zwischen Informationstypen UAL ASCII/Latin-1 Client/Server (SMTP) Verschlüsselung, Authentisierung In ASN.1 kodiert, Client-/Server-Modell auf ROSE-Basis 51