Mail Nachrichtenformateund MIME - userpages.uni-koblenz.deunikorn/lehre/gdrn/ws16/08... ·...

Mail‐Nachrichtenformate und MIME

Grundlagen der Rechnernetze ‐ Applikationsschicht 22

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: [email protected]: [email protected]: Searching for the meaning of life.

Text text text



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)• BeispielFrom: [email protected]: [email protected]: Picture of yummy crepe.MIME-Version: 1.0Content-Transfer-Encoding: base64Content-Type: image/jpeg

(base64 encoded data ............................. base64 encoded data )



Empfangender SMTP‐Server fügt noch Recived: Header‐Line(s) hinzuBeispiel:Received: from crepes.fr by hamburger.edu; 12 Oct 98 15:27:39 GMTFrom: [email protected]: [email protected]: Picture of yummy crepe.MIME-Version: 1.0Content-Transfer-Encoding: base64Content-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.jpReceived: from hamburger.edu by sushi.jp; 3 Jul 01 15:30:01 GMTReceived: from crepes.fr by hamburger.edu; 3 Jul 01 15:17:39 GMT

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

Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008

SMTP,HTTP

POP3,IMAP,HTTP

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 deletemarkierten Nachrichten

Im Prinzip zwei Varianten möglich:• Variante: download‐and‐delete• Variante: downlad‐and‐keep

Mail‐Access‐Protokolle: POP3


Beispiel einer Download‐and‐Delete‐Transaction (c: client, s: server)C: listS: 1 498S: 2 912S: .C: retr 1S: (blah blah blah .........S: .........................S: ......... blah blah blah)S: .C: dele 1C: retr 2S: (blah blah blah .........S: .........................S: ......... blah blah blah)S: .C: dele 2C: quitS: +OK POP3 server signing off

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)• Email‐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

Übersicht• Web und HTTP• File Transfer: FTP• Electronic Mail• Domain Name System (DNS)

29Grundlagen der Rechnernetze ‐ Applikationsschicht

DNS Übersicht


Problem:• IP braucht IP‐Adressen (z.B. 121.7.106.83)• Menschen brauchen Host‐Namen (www.uni‐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 DNS‐Servern

(häufig UNIX‐Maschinen auf denen Berkeley Internet Name Domain (BIND) läuft)

• DNS ist ein Protokoll zur Abfrage von Übersetzungen auf den DNS‐Servern

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

DNS Übersicht

Grundlagen der Rechnernetze ‐ Einführung 31

HN S

• Client‐Server‐Prinzip• Beispiel: HTTP‐Anfrage an Web‐Server www.someschool.edu erfordert DNS

Abfrage der IP1. Client‐Seitig: DNS‐Anwendung2. Browser extrahiert Host‐Name www.someschool.edu aus der URL und ruft

damit DNS‐Anwendung auf (z.B. UNIX‐System: gethostbyname())3. DNS‐Client sendet Anfrage mit dem Hostnamen an DNS‐Server4. DNS‐Client empfängt irgendwann (typischerweise im Bereich Millisekunden

bis Sekunden) eine DNS‐Antwort mit der IP‐Adresse zu www.someschool.edu 5. Browser kann TCP‐Verbindung auf Basis von IP‐Adresse und Port (z.B. Port 80

für HTTP‐Server) herstellen

Client:DNS‐Client undz.B. Web‐Browser

Server:DNS‐Server

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, www.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.west‐

coast.hotmail.com• Beipiel einer Email‐Adresse: [email protected]• 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

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

DNS: verteilte, hierarchische Datenbank


Warum nicht ein zentraler DNS‐Server?• Single‐Point‐of‐Failure (SPOF) – ein Serverausfall legt das

gesamte Internet lahm• Verkehrsaufkommen – fast jeder Internet‐Host braucht DNS• Kommunikationsdistanz – Problem den einen DNS‐Server

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



RootDNS‐Server

comDNS‐Server

orgDNS‐Server

eduDNS‐Server

yahoo.comDNS‐Server

amazon.comDNS‐Server

pbs.orgDNS‐Server

poly.eduDNS‐Server

umass.eduDNS‐Server

Root DNS Server

Top‐Level‐Domain(TLD) DNS Server

AuthoritativeDNS Server

(*) Beispiel und Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008

Kleiner Ausschnitt aus der DNS Server‐Hierarchie(*)

Root‐DNS‐Server• Root‐Server werden von verschiedenen

Institutionen betrieben. Die Internet Corporation for Assigned Names andNumbers (ICANN) koordiniert den Betrieb

• 13 Root‐DNS‐Server (A bis M)• Allerdings steht jeder Buchstabe für einen

Cluster von replizierten Servern• (Bemerkung: Anycast, Alternative Roots)



RootDNS‐Server

comDNS‐Server

orgDNS‐Server

eduDNS‐Server



pbs.orgDNS‐Server



Root DNS Server





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 DNS‐Server erreichbar sein

• Kann über eigene DNS‐Server oder über einen Dienstleister realisiert sein



RootDNS‐Server

comDNS‐Server

orgDNS‐Server

eduDNS‐Server



pbs.orgDNS‐Server



Root DNS Server





Ein weiterer wichtiger DNS‐Server: Local DNS‐Server• 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

H N S

Beispiel DNS‐Anfrage



1. Anfrage „gaia.cs.umass.edu“ am localDNS‐Server 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‐Server dns.cs.umass.edu

6. Anfrage „gaia.cs.umass.edu“ an DNS‐Server dns.cs.umass.edu

7. Ergebnis: IP von gaia.cs.umass.edu8. Zurücksenden des Ergbnisses von

dns.poly.edu an cis.poly.eduDamit: 4 Anfragenachrichten und 4 Antwortnachrichten für eine einzige DNS‐Abfrage!?! Noch schlimmer:

Beispiel DNS‐Anfrage


Abbildung nach Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008

• TLD‐Server muss den auth. Server nicht unbedingt schon kennen; TLD‐Server kennt nur einen intermediate DNS‐Server

• Beispiel: intermediate‐Server dns.umass.edu und jedes Department hat einen eigenen DNS‐Server, z.B. dns.cs.umass.edu

Damit: 5 Anfragenachrichten und 5 Antwortnachrichten für eine einzige DNS‐Abfrage!?!Lösung? Caching!• DNS‐Server‐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)

dns.umass.edu

dns.cs.umass.edu

DNS‐Anfrage: rekursiv versus iterativ


Abbildungen aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008

IterativeQuery

RekursiveQuery

In der Regel:• Anfrage an Local DNS‐Server rekursiv• Der Rest Iterativ• (Am häufigsten jedoch Cache‐Hit)

DNS‐Records


DNS‐Server 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, 145.37.93.126, A)• Type = NS: Name ist Domain und Name ist der Name eines auth. DNS‐Server, der die

IP‐Adressen der Hosts bestimmen kannBeispiel: (foo.com, dns.foo.com, NS)

• Type = CNAME: Name ist der canonical Host‐Name für den Alias‐Host‐NameBeispiel: (foo.com, relay1.bar.foo.com, CNAME)

• Type = MX: Name ist der canonical Name eines Mail‐Servers zu einem Alias‐Host‐NameBeispiel: (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 [email protected] und ww.foo.com• Unterscheidung durch Anfrage entweder MX oder CNAME

DNS‐Nachrichten


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


DNS‐Nachrichten


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“


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 www.internic.net gefunden werden

Ggf. wird auch IP eines primären und sekundären Authoritativen DNS‐Server angegeben• Zum Beispiel: dns1.networkutopia.com und dns2.networkutopia.com mit

212.212.212.1 und 212.212.212.2• 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, 212.212.212.1, A)

Dann noch ein Web‐Server und Mail‐Server‐Eintrag in den eigenen authoritativen DNS‐Server• Type A Eintrag für Web‐Server www.networkutopia.com 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.

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 authoritativeDNS‐Server mit gefälschten Source‐Adressen

DNS ist aber sehr robust• DNS‐Server Konfiguration• Caching

Zusammenfassung und Literatur


Zusammenfassung• Anwendung versus Anwendungsprotokoll (z.B. Email‐Client und Server versus SMTP, POP3, IMAP, HTTP)

• Anwendungen und deren Anwendungsprotokolle haben unterschiedliche Anforderungen an das Transport‐Protokoll:

Grundlagen der Rechnernetze ‐ Applikationsschicht 47Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008

Besonderheit DNS: Dienst auf Anwendungsebene, welcher von fast allen anderen Anwendungen genutzt wird

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 48Abbildung aus Kurose/Ross „Computer Networking: A Top‐Down Approach“, 2008

Literatur• James F. Kurose, Keith W. Ross, „Computer Networking: A Top‐Down Approach“, 4th Edition, 2008– 2.1.4 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


Mail Nachrichtenformateund MIME - userpages.uni-koblenz.deunikorn/lehre/gdrn/ws16/08... ·...

Documents

Transcript of Mail Nachrichtenformateund MIME - userpages.uni-koblenz.deunikorn/lehre/gdrn/ws16/08... ·...