Mail Nachrichtenformate und MIME

Transkript

1 Mail Nachrichtenformate und MIME Mail Content (Achtung: nicht SMTP) beinhaltet neben dem eigentlichen Text d.h. dem Body zusätzliche Informationen: Zusätzliche Header Lines (separiert durch CRLF) Format wie aus HTTP bekannt (lesbarer Text mit Key Value Paar durch : getrennt) Definiert in RFC 822 Immer erforderliche Keywords sind To: und From: Optionale Keywords z.b. Subject: Body folgt nach einer Blank Line Beispiel: From: alice@crepes.fr To: bob@hamburger.edu Subject: Searching for the meaning of life. Text text text Grundlagen der Rechnernetze Applikationsschicht 22

2 Mail Nachrichtenformate und MIME Multipurpose Internet Mail Extensions (MIME) zum Versenden von Multimedia und non ASCII Text Verwendung weitere Header definiert in RFC 2045 und 2046 als MIME Extensions zu RFC 822 Zwei wesentliche MIME Header Content Type: erforderlich zur Darstellung auf dem User Agent Content Transfer Encoding: erforderlich für den Transport von Binary Data über 7 Bit ASCII (Beispiel base64) Beispiel From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg (base64 encoded data base64 encoded data ) Grundlagen der Rechnernetze Applikationsschicht 23

3 Mail Nachrichtenformate und MIME Empfangender SMTP Server fügt noch Recived: Header Line(s) hinzu Beispiel: Received: from crepes.fr by hamburger.edu; 12 Oct 98 15:27:39 GMT From: To: Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg (base64 encoded data base64 encoded data ) Durch Mail Forwarding kann auch ein ganzer Pfad von Received angehangen sein. Beislpielsweise: Mail Frowarding von hamburger.edu nach sushi.jp Received: from hamburger.edu by sushi.jp; 3 Jul 01 15:30:01 GMT Received: from crepes.fr by hamburger.edu; 3 Jul 01 15:17:39 GMT Grundlagen der Rechnernetze Applikationsschicht 24

4 Mail Access Protokolle Warum eigentlich die Trennung zwischen User Agent und Mail Server User Agent des Empfängers muss sonst immer an sein User Agent des Senders braucht im Falle nicht Erreichbarkeit die Übertragungsversuche (z.b. alle 30 Minuten) nicht selbst zu unternehmen Damit werden aber Mail Access Protokolle notwendig POP3 (Post Office Protocol Version 3) IMAP (Internet Mail Access Protocol) Web Basiert (HTTP) Aber auch SMTP wird auf User Agent verwendet: zum versenden von Mail auf den eigenen Mail Server SMTP, HTTP POP3, IMAP, HTTP Abbildung aus Kurose/Ross Computer Networking: A Top Down Approach, 2008 Grundlagen der Rechnernetze Applikationsschicht 25

5 Mail Access Protokolle: POP3 Einfaches Protokoll definiert in RFC 1939 TCP Verbindungsherstellung mit Mail Server auf Port 110 Anschließend drei Phasen: authorization, transaction, update Authorization: Authentifizierung des User mittels Username und Passwort user <username> pass <password> Transaction: Nachrichten empfangen, Nachrichten zur Löschung markieren, Löschungsmarkierungen aufheben, Mail Statistiken erfragen Update: nachdem Client quit gesendet hat; Mail Server löscht die mit delete markierten Nachrichten Im Prinzip zwei Varianten möglich: Variante: download and delete Variante: downlad and keep Grundlagen der Rechnernetze Applikationsschicht 26

6 Mail Access Protokolle: POP3 Beispiel einer Download and Delete Transaction (c: client, s: server) C: list S: S: S:. C: retr 1 S: (blah blah blah... S:... S:... blah blah blah) S:. C: dele 1 C: retr 2 S: (blah blah blah... S:... S:... blah blah blah) S:. C: dele 2 C: quit S: +OK POP3 server signing off Grundlagen der Rechnernetze Applikationsschicht 27

7 Mail Access Protokolle: IMAP, Web basiert POP3 und mehrere Client Rechner (z.b. Desktop PC, Notebook)? Nur downlad and keep sinnvoll Mailbox aufräumen und in Foldern verwalten ist kompliziert, wenn alle Rechner konsistent gehalten werden sollen Bessere Lösung: IMAP (RFC 3501) Nachrichten verbleiben auf dem Server und werden dort verwaltet (herunter geladene Nachrichten liegen aber auch lokal vor) Jede Mail Nachricht ist einem Folder zugeordnet (z.b. Inbox) User kann Nachrichten auf dem Server löschen und in Folder verschieben Nachrichten können auf dem Server durchsucht werden Nachrichten können nur Teilweise herunter geladen werden (z.b. nur Header oder nur ein Teil einer Multipart MIME Message) Alternative Lösung: Web basiert (HTTP) Zugang über Browser (z.b. Google Mail oder SoGo an unserer Uni) Kommunikation mit der Mailbox über Browser (HTTP basiert) HTTP Kommunikation aber nur zwischen User Agent und Mail Server Kommunikation der Mail Server weiterhin über SMTP Grundlagen der Rechnernetze Applikationsschicht 28

8 Übersicht Web und HTTP File Transfer: FTP Electronic Mail Domain Name System (DNS) Grundlagen der Rechnernetze Applikationsschicht 29

9 DNS Übersicht Problem: IP braucht IP Adressen (z.b ) Menschen brauchen Host Namen ( koblenz.de) Aufgabe von DNS: Directory Service zur Übersetzung von Host Name in IP Adresse DNS ist eine verteilte Datenbank auf Basis einer Hierarchie von n (häufig UNIX Maschinen auf denen Berkeley Internet Name Domain (BIND) läuft) DNS ist ein Protokoll zur Abfrage von Übersetzungen auf den n DNS ist auf der Anwendungsschicht Läuft nur auf den End Systemen (Client, Server) nicht auf Routern Verwendet UDP (Port 53) Spezifikation: RFC 1034, RFC 1035 und Aktualisierungen in weiteren RFCs Grundlagen der Rechnernetze Applikationsschicht 30

10 DNS Übersicht Client Server Prinzip Beispiel: HTTP Anfrage an Web Server erfordert DNS Abfrage der IP 1. Client Seitig: DNS Anwendung 2. Browser extrahiert Host Name aus der URL und ruft damit DNS Anwendung auf (z.b. UNIX System: gethostbyname()) 3. DNS Client sendet Anfrage mit dem Hostnamen an 4. DNS Client empfängt irgendwann (typischerweise im Bereich Millisekunden bis Sekunden) eine DNS Antwort mit der IP Adresse zu 5. Browser kann TCP Verbindung auf Basis von IP Adresse und Port (z.b. Port 80 für HTTP Server) herstellen H N S Client: DNS Client und z.b. Web Browser Server: Grundlagen der Rechnernetze Einführung 31

11 DNS Übersicht DNS macht/kann aber noch mehr Host Aliasing Beispiel eines Canonical Host Namens: relay1.west coast.enterprise.com Beispiel eines Alias Host Namens: enterprise.com, DNS zur Abfrage des Canonical Host Names zu einem Alias Host Name Mail Server Aliasing Beispiel eines Canonical Host Name eines Mail Servers: relay1.westcoast.hotmail.com Beipiel einer Adresse: DNS übersetzt Alias Host Name hotmail.com ist den Canonical Host Name (Bemerkung: Mail Server und Web Server können identische (aliased) Host Namen haben) Load Distribution Replizierte Server (z.b. für stark frequentierte Seiten wie cnn.com) DNS liefert liste von IP Adressen; Client nimmt in der Regel die erste IP Rotiere IP Reihenfolge Grundlagen der Rechnernetze Applikationsschicht 32

12 DNS Übersicht Philosophisches Normalerwiese interagiert der User direkt mit den Application Layer Protokollen (Web, Mail, FTP etc.) DNS ist für viele andere Dienste ein Core Internet Service auf der Anwendungsebene Typisches Beispiel der Internet Philosophie: vieles der Komplexität des Internets ist am Rand des Internets Grundlagen der Rechnernetze Applikationsschicht 33

13 DNS: verteilte, hierarchische Datenbank Warum nicht ein zentraler? Single Point of Failure (SPOF) ein Serverausfall legt das gesamte Internet lahm Verkehrsaufkommen fast jeder Internet Host braucht DNS Kommunikationsdistanz Problem den einen sinnvoll auf dem Globus zu plazieren Verwaltung fast jeder Server Host muss über DNS auffindbar sein Also: wie immer, ein Skalierbarkeitsproblem. Es kommt nur eine verteilte Lösung in Frage. Außerdem nicht ein einziger Provider: hierarchische Organisation Grundlagen der Rechnernetze Applikationsschicht 34

14 DNS: verteilte, hierarchische Datenbank Root Root DNS Server com org edu Top Level Domain (TLD) DNS Server yahoo.com amazon.com pbs.org poly.edu umass.edu Authoritative DNS Server Kleiner Ausschnitt aus der DNS Server Hierarchie (*) Root Root Server werden von verschiedenen Institutionen betrieben. Die Internet Corporation for Assigned Names and Numbers (ICANN) koordiniert den Betrieb 13 Root (A bis M) Allerdings steht jeder Buchstabe für einen Cluster von replizierten Servern (Bemerkung: Anycast, Alternative Roots) (*) Beispiel und Abbildung aus Kurose/Ross Computer Networking: A Top Down Approach, 2008 Grundlagen der Rechnernetze Applikationsschicht 35

15 DNS: verteilte, hierarchische Datenbank Root Root DNS Server com org edu Top Level Domain (TLD) DNS Server yahoo.com amazon.com pbs.org poly.edu umass.edu Authoritative DNS Server Kleiner Ausschnitt aus der DNS Server Hierarchie (*) Top Level Domain Server Beispiel: com, org, net, edu, gov Beispiel für Länder Top Level Domains: de, uk, fr, ca, jp Verwaltet durch Unternehmen Authoritative DNS Server Öffentlich erreichbare Server eines Unternehmens / einer Einrichtung müssen über solche erreichbar sein Kann über eigene oder über einen Dienstleister realisiert sein (*) Beispiel und Abbildung aus Kurose/Ross Computer Networking: A Top Down Approach, 2008 Grundlagen der Rechnernetze Applikationsschicht 36

16 DNS: verteilte, hierarchische Datenbank Root Root DNS Server com org edu Top Level Domain (TLD) DNS Server yahoo.com amazon.com pbs.org poly.edu umass.edu Authoritative DNS Server Kleiner Ausschnitt aus der DNS Server Hierarchie (*) H N S Ein weiterer wichtiger : Local Durch ISP (z.b. Uni/Campus, Unternehmen, lokaler ISP) realisiert Bekannt gemacht in der Regel über DHCP (siehe z.b. Netzstatus des Betriebssystems) In der Regel nahe am Host Agiert als Proxy zwischen Host und DNS Infrastruktur (*) Beispiel und Abbildung aus Kurose/Ross Computer Networking: A Top Down Approach, 2008 Grundlagen der Rechnernetze Applikationsschicht 37

17 Beispiel DNS Anfrage Abbildung aus Kurose/Ross Computer Networking: A Top Down Approach, Anfrage gaia.cs.umass.edu am local dns.poly.edu 2. Anfrage gaia.cs.umass.edu am Root DNS 3. Ergebnis: Liste von TLD Server, die für edu zuständig sind 4. Anfrage gaia.cs.umass.edu an einen der TLD Server 5. Ergebnis: IP des zuständigen auth. dns.cs.umass.edu 6. Anfrage gaia.cs.umass.edu an DNS Server dns.cs.umass.edu 7. Ergebnis: IP von gaia.cs.umass.edu 8. Zurücksenden des Ergbnisses von dns.poly.edu an cis.poly.edu Damit: 4 Anfragenachrichten und 4 Antwortnachrichten für eine einzige DNS Abfrage!?! Noch schlimmer: Grundlagen der Rechnernetze Applikationsschicht 38

18 Beispiel DNS Anfrage dns.cs.umass.edu Abbildung nach Kurose/Ross Computer Networking: A Top Down Approach, 2008 dns.umass.edu TLD Server muss den auth. Server nicht unbedingt schon kennen; TLD Server kennt nur einen intermediate Beispiel: intermediate Server dns.umass.edu und jedes Department hat einen eigenen, z.b. dns.cs.umass.edu Damit: 5 Anfragenachrichten und 5 Antwortnachrichten für eine einzige DNS Abfrage!?! Lösung? Caching! Antworten werden in Cache gespeichert Signifikante Reduktion von Nachrichten und Latenz Zuordnung von Domain Name auf IP ist nicht permanent; Einträge verweilen in Cache bis zu einem Timeout (z.b. zwei Tage) Grundlagen der Rechnernetze Applikationsschicht 39

19 DNS Anfrage: rekursiv versus iterativ Iterative Query Rekursive Query In der Regel: Anfrage an Local rekursiv Der Rest Iterativ (Am häufigsten jedoch Cache Hit) Abbildungen aus Kurose/Ross Computer Networking: A Top Down Approach, 2008 Grundlagen der Rechnernetze Applikationsschicht 40

20 DNS Records speichern Ressource Records (RRs) DNS Reply Nachrichten beinhalten ein oder mehrere auf die Anfrage passende RRs. RRs bestehen aus 4 Tupel (Name, Value, Type, TTL) TTL ist die Lebensdauer des RR (wird danach aus Cache entfernt) (Name, Value) hängt von Type ab Type = A: Name ist Host Name und Value ist IP Adresse Beispiel: (relay1.bar.foo.com, , A) Type = NS: Name ist Domain und Name ist der Name eines auth., der die IP Adressen der Hosts bestimmen kann Beispiel: (foo.com, dns.foo.com, NS) Type = CNAME: Name ist der canonical Host Name für den Alias Host Name Beispiel: (foo.com, relay1.bar.foo.com, CNAME) Type = MX: Name ist der canonical Name eines Mail Servers zu einem Alias Host Name Beispiel: (foo.com, mail.bar.foo.com, MX) Erlaubt ein und denselben Alias für Mail Server und z.b. Web Server Beispiel: foo.com für joe@foo.com und ww.foo.com Unterscheidung durch Anfrage entweder MX oder CNAME Grundlagen der Rechnernetze Applikationsschicht 41

21 DNS Nachrichten Abbildung aus Kurose/Ross Computer Networking: A Top Down Approach, 2008 DNS Query und Reply Nachrichten haben dasselbe Format 12 Byte Header Identification: Client kann damit Reply seinem Request zuordnen (z.b. mehrere gleichzeitige ausstehende Requests) Flags: 1 Bit Query/Reply Flag: Unterscheidung von Query und Reply Nachricht 1 Bit Authoritative Flag: 1, wenn Server authoritative für den angefragten Namen 1 Bit Recursion: in Query: Recursion Desired in Reply: Recursion Available Number Fields: Anzahl Vorkommen der folgenden vier möglichen Datentypen Grundlagen der Rechnernetze Applikationsschicht 42

22 DNS Nachrichten Abbildung aus Kurose/Ross Computer Networking: A Top Down Approach, 2008 Questions: Einträge der Form (Name, Type) (z.b. Type A oder Type MX) Answers: Antwort in Form von RRs (Name, Value, Type, TTL) Reply kann mehrere RRs enthalten z.b. Host mit mehreren IP Adressen für Load Balancing Authority: Reply Einträge über zuständige Authoritative Server Additional Information: Beispiel Reply auf MX Query: Ergebnis = canonical Name des Mail Servers und zusätzlich Type A Record für dessen IP Adresse Grundlagen der Rechnernetze Applikationsschicht 43

23 Eintragen von RR in die DNS Datenbank Beispiel: Neue Firma Network Utopia mit Domain Namen networkutopia.com Networkutopia.com muss über einen Registrar angemeldet werden Registrar bietet solche kostenpflichtige Dienstleistung an Registrare können auf gefunden werden Ggf. wird auch IP eines primären und sekundären Authoritativen angegeben Zum Beispiel: dns1.networkutopia.com und dns2.networkutopia.com mit und Registrar veranlasst Eintragung von Type NS und Type A Eintrag in TLD com, d.h. für primary authoritative Server networkutopia.com: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, , A) Dann noch ein Web Server und Mail Server Eintrag in den eigenen authoritativen DNS Server Type A Eintrag für Web Server und Type MX Eintrag für Mail Server mail.networkutopia.com In der Regel alles noch einfacher: Provider stellt für Kunden die Server zur Verfügung. Kunde registriert über Provider (der ist dann auch der Registrar) einfach eine Domain. Grundlagen der Rechnernetze Applikationsschicht 44

24 Robustheit von DNS DNS ist eine kritische Komponente der Internet Infrastruktur Diskussion möglicher Angriffe DDoS Attacke gegen DNS Root Server Auf Basis von ICMP Ping oder Fluten mit DNS Anfragen bzgl. Top Level Domains (z.b. alle Server für die Top Level Domain com) Man in the Middle Attack Abfangen von Client Queries oder Eintragen von falschen Cache Einträgen Nutzen der DNS Infrastruktur, für DDoS Attacke auf authoritative mit gefälschten Source Adressen DNS ist aber sehr robust Konfiguration Caching Grundlagen der Rechnernetze Applikationsschicht 45

25 Zusammenfassung und Literatur Grundlagen der Rechnernetze Applikationsschicht 46

26 Zusammenfassung Anwendung versus Anwendungsprotokoll (z.b. Client und Server versus SMTP, POP3, IMAP, HTTP) Anwendungen und deren Anwendungsprotokolle haben unterschiedliche Anforderungen an das Transport Protokoll: Besonderheit DNS: Dienst auf Anwendungsebene, welcher von fast allen anderen Anwendungen genutzt wird Abbildung aus Kurose/Ross Computer Grundlagen der Rechnernetze Applikationsschicht 47 Networking: A Top Down Approach, 2008

27 Zusammenfassung Damit ergibt sich in der Regel Auswahl zwischen TCP oder UDP Was ist mit Sicherheit? Erweiterung von TCP für Sicherheit auf Anwendungsebene mittels SSL (Secure Sockets Layer) bzw. TLS (Transport Layer Security) Was ist mit Bandbreiten und Latenz Garantien? Anwendungen mit solchen Anforderungen laufen in der Regel ; können mit nichtvorhandenen Garantien im gewissen Rahmen umgehen. Grundlagen der Rechnernetze Applikationsschicht 48 Abbildung aus Kurose/Ross Computer Networking: A Top Down Approach, 2008

28 Literatur James F. Kurose, Keith W. Ross, Computer Networking: A Top Down Approach, 4th Edition, Transport Services Provided by the Internet 2.2 The Web and HTTP 2.3 File Transfer: FTP 2.4 Electronic Mail in the Internet 2.5 DNS The Internet s Directory Service 2.9 Summary Grundlagen der Rechnernetze Applikationsschicht 49