Lars Stockhausen
Kommunikation und Infrastruktur
ISBN: 978-3-8366-0055-2
Druck Diplomica® GmbH, Hamburg, 2007
Zugl. Fachhochschule für Ökonomie und Management (FOM), Neuss, Deutschland,
Bachelorarbeit, 2006
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica GmbH
http://www.diplom.de, Hamburg 2007
Printed in Germany
Über den Autor
2
Über den Autor
Lars Stockhausen ist zurzeit als Groupware-Berater tätig. Seit fünf Jahren unterstützt
Herr Stockhausen eine große Versicherung bei der Administration und Planung infra-
struktureller Lösungen im Umfeld der IBM Groupware Lotus Domino.
Kurzfassung
3
Kurzfassung
Gegenstand der hier vorgestellten Arbeit ist die Darstellung der Anforderungen an die
Infrastruktur, die für den Dienst Email erforderlich sind. Weiter beinhaltet die Arbeit die
Konzepte, Strukturen und Probleme, die im Umfeld von Email existieren.
Schlagwörter: Email, DNS, SMTP, RFC, IANA, MIME, Spam, PKI, PGP, S/MIME.
Inhaltsverzeichnis
4
Inhaltsverzeichnis
Über den Autor ... 2
Kurzfassung... 3
Inhaltsverzeichnis ... 4
Abbildungsverzeichnis... 7
Tabellenverzeichnis ... 7
Vorwort... 8
Leserkreis ... 9
Aufbau und Konventionen der Arbeit ... 10
1
Einführung ... 11
1.1 Entstehung
von
Email... 11
1.2 Internetgremien... 12
1.3 Protokolle ... 13
1.3.1 TCP/IP ... 13
1.3.2 DNS ... 14
1.3.3 SMTP... 15
1.3.4 ESMTP ... 19
1.3.5 MIME ... 19
1.3.6 POP3... 21
1.3.7 IMAP4 ... 23
1.4
Kodierung und Zeichensatz... 23
2
Infrastruktur... 27
2.1 Einführung... 27
2.2
Schema einer Internetanbindung ... 27
2.2.1 IP-Adressen ... 28
2.2.2 Bereitstellung von Diensten im Internet... 30
2.2.3 Gemeinsame Nutzung von Internetdiensten... 31
2.3 Testnetz... 32
2.3.1 Szenario 1: Lokale Zustellung an virtuelle Domain... 33
2.3.2 Szenario 2: Lokale Zustellung von Client zu Client ... 35
2.3.3 Szenario 3: Entfernte Zustellung ... 37
2.3.4 Szenario 4: Entfernte Zustellung an internen Groupware-Server ... 39
2.3.5 Szenario 5: Entfernte Zustellung über Backup-Server... 42
Inhaltsverzeichnis
5
3
Filtertechniken... 45
3.1 Unerwünschte
Emails... 45
3.1.1 Spam ... 45
3.1.2 Viren, Würmer und Trojaner... 46
3.1.3 Falschmeldungen und Kettenbriefe... 46
3.1.4 Phishing ... 47
3.1.5 Verbotene Emails im Unternehmenseinsatz... 47
3.2
Erkennung unerwünschter Emails... 47
3.2.1 Statische
(regelbasierte)
Erkennung ... 48
3.2.2 Dynamische
(lernende)
Erkennung ... 49
3.2.3 Verteilte
Erkennung... 50
3.2.4 Weitere Methoden zur Erkennung... 50
3.3
Umgang mit unerwünschten Emails... 51
3.4 Testbarkeit ... 53
4
Email-Verschlüsselung... 55
4.1 Verschlüsselungsverfahren... 55
4.1.1 Symmetrische
Verschlüsselung... 55
4.1.2 Asymmetrische
Verschlüsselung... 56
4.1.3 Hybride
Verschlüsselung... 56
4.2 Public-Key-Infrastruktur ... 56
4.2.1 Ziele... 57
4.2.2 Voraussetzungen... 57
4.2.3 Vertrauensmodelle... 58
4.2.4 Komponenten ... 60
4.2.5 Standards ... 61
4.3 Verschlüsselte
Kommunikation... 65
4.3.1 Transportverschlüsselung ... 65
4.3.2 Inhaltsverschlüsselung... 66
4.3.3 Alternativen zum sicheren Datenaustausch... 67
5
Weiterführende Themen... 68
5.1 Allgemein ... 68
5.2 Client-Infrastruktur... 68
5.3 Groupware ... 69
5.4
Große Infrastrukturen und Open Source ... 69
5.5 Teergrube... 69
6
Schlusswort ... 70
Anhang A: Technisches ... 71
A.1 Statuswerte einer SMTP-Verbindung ... 71
Inhaltsverzeichnis
6
A.2 ESMTP-Erweiterungen... 71
A.3 ASCII ... 73
A.4 Base64... 77
Abkürzungen und Glossar ... 80
Literaturverzeichnis ... 87
Ehrenwörtliche Erklärung... 92
Stichwortverzeichnis... 93
Abbildungsverzeichnis
7
Abbildungsverzeichnis
Abbildung 1: Simple Mail Transfer Protocol ... 16
Abbildung 2: Schema einer Internetanbindung ... 28
Abbildung 3: Network Address Translation... 30
Abbildung 4: Testnetz... 32
Abbildung 5: Postfix-Architektur ... 36
Abbildung 6: Postfix als Email-Client... 38
Abbildung 7: Web of Trust... 59
Abbildung 8: Hirarchical Trust... 59
Abbildung 9: X.500-Verzeichnisbaum ... 62
Abbildung 10: Zertifikatsexport ... 64
Abbildung 11: Transportverschlüsselung ... 65
Abbildung 12: Inhaltsverschlüsselung... 66
Tabellenverzeichnis
Tabelle 1: Auszug aus der ASCII-Tabelle... 24
Tabelle 2: Auszug aus dem Base64-Alphabet ... 25
Tabelle 3: Aufbau eines X.509-Zertifikats ... 63
Tabelle 4: Statuswerte einer SMTP-Verbindung... 71
Tabelle 5: Auszug an Steuerzeichen der ASCII-Tabelle ... 73
Tabelle 6: Darstellbare Zeichen der ASCII-Tabelle ... 73
Tabelle 7: Base64-Tabelle ... 77
Vorwort
8
Vorwort
Der Autor kommt im Rahmen seiner Tätigkeit oft mit Email in Berührung. Email ist
heute einer der am meisten genutzten Internetdienste. Es regelt oftmals einen Großteil
interner und externer Kommunikation. Viele Firmen sind bereits auf die Verfügbarkeit
und Performance von Email angewiesen, sei es, um flexibel auf Kundenfragen zu ant-
worten, es als Instrument zum Direktmarketing zu verwenden oder zur einfachen Kom-
munikation zwischen Geschäftspartnern. Die Anforderungen an das Thema und deren
Infrastruktur steigen ständig, nicht zuletzt durch die Belastungen unerwünschter Emails.
Die meisten Menschen sehen Email mittlerweile als Selbstverständlichkeit an. Das
Wort, das sich aus den beiden englischen Wörtern ,,Electronic" und ,,Mail" zusammen-
setzt, ist in den allgemeinen Sprachgebrauch übergegangen. Der Autor verwendet die
Schreibweise ,,Email" aus nachfolgendem Grund:
Als Erfinder der Email gilt Ray Tomlinson (siehe Kapitel 1.1), der auf seiner Home-
page
1
die Meinung vertritt, man sollte endlich Abstand von der Schreibweise ,,E-Mail"
nehmen. Auch Donald Knuth, ein ebenfalls bekannter Mann der informationstechni-
schen Zeitgeschichte, vertritt diese Meinung und publiziert auf seiner Webseite
2
, es sei
archaisch, diese alte Schreibweise mit dem Bindestrich zur Symbolisierung der Her-
kunft des Wortes zu verwenden. Er führt an, dass es ebenso unüblich sei ,,Soft-Ware" an
Stelle von ,,Software" zu schreiben.
1
[Tomlinson 1]
2
[Knuth 2006]
Leserkreis
9
Leserkreis
Diese Arbeit richtet sich an Angestellte der elektronischen Datenverarbeitung, die einen
Einstieg in die Email-Kommunikation suchen und ein Interesse an der gesamtheitlichen
Infrastruktur haben.
Des Weiteren ist diese Arbeit an Email-Administratoren und Email-Verantwortliche
gerichtet. Email-Verantwortliche können Berater, Manager und gleichermaßen Group-
ware-Administratoren sein, die zwar die Verantwortung für Email tragen, aber nicht die
gesamte Email-Strecke über Firewalls und Relais bis zum eventuellen Groupware-
Server betreuen. Dieses Thema ist darüber hinaus interessant für DNS-, Firewall- und
Betriebssystem-Administratoren.
Email-Verantwortliche erhalten in Kapitel 1 einen Überblick über die relevanten The-
men und in Kapitel 2.1 und 2.2 einen Einblick in die Möglichkeiten der Anbindung. In
Kapitel 3 erfahren sie, welche Probleme im Umfeld von Email existieren und welche
Lösungsansätze bekannt sind. Kapitel 4 weist auf die Möglichkeiten zur gesicherten
Kommunikation hin.
Administratoren können ihr Wissen vertiefen, ab Kapitel 2 direkt in die Konfiguration
einsteigen und die dargestellten Szenarien nachvollziehen. In Kapitel 5 erhalten sie ei-
nen Ausblick, welche Themen weiterführend interessant sein könnten.
Aufbau und Konventionen der Arbeit
10
Aufbau und Konventionen der Arbeit
Diese Arbeit basiert auf der Vorlage von Prof. Dr. Wolf-Fritz Riekert der Fachhoch-
schule Stuttgart (Hochschule der Medien) und wurde für das Textverarbeitungspro-
gramm Microsoft Word erstellt.
3
·
Normaler Text wird mit der Serifenschrift Times New Roman geschrieben. Seri-
fenschriften besitzen eine gute Zeilenführung und gelten daher als lesefreund-
lich.
4
·
Einige Eigennamen und Schlagworte werden großgeschrieben (z. B. SMTP)
·
Dateinamen und Pfade werden kursiv gesetzt (z. B. /etc/services)
·
Kommandozeilenbefehle werden fett gesetzt (z. B. telnet localhost smtp).
Das $-Zeichen symbolisiert die Ausführung des Kommandos mit einem nicht
privilegierten User. Das #-Zeichen zeigt an, dass die Aktion Administrations-
rechte benötigt.
·
Computerprogramme und Inhalte von Dateien werden mit fester Zeichenbreite
durch die Schriftart Courier New dargestellt (z. B.
print $1;
).
Überlange Zeilen werden durch ein Leerzeichen am Anfang der nächsten Zeile
kenntlich gemacht.
·
Zitate werden nach DIN 1505 Teil 3 durch ,, eingeleitet und durch " abgeschlos-
sen. Darüber hinaus werden direkte Zitate kursiv gesetzt und eingerückt. Auslas-
sungen werden durch [...] gekennzeichnet. Kommen im Zitat ,, oder " vor, wer-
den sie durch einfache Kommentarzeichen ersetzt (, und `).
5
Indirekte Zitate
werden durch das Voranstellen von ,,Vgl." (Vergleiche) gekennzeichnet.
·
Die Literatur wird nach DIN 1505 Teil 2 angegeben, wobei Quellenangaben Re-
ferenzen auf Einträge im Literaturverzeichnis sind.
3
[Riekert 2002]
4
[Vgl. Riekert 2002, Seite 23]
5
[DIN 1505]
1 Einführung
11
1 Einführung
Dieses Kapitel gibt einen Überblick über
·
die Entstehung der Email sowie der mit dem ARPANET entstandenen Gremien und
Normen sowie über
·
emailrelevante Konventionen zu Struktur, Aufbau und Kodierung.
1.1 Entstehung von Email
Die Ursprünge von Email im Sinne der Nachrichtenübermittlung über Rechnergrenzen
hinweg gehen zurück bis in das Jahr 1971 (bereits zuvor gab es Umsetzungen, um
Nachrichten für andere Benutzer auf dem lokalen Rechner zu hinterlegen).
Das amerikanische Verteidigungsministerium startete 1969 ein Projekt mit dem Ziel der
Vernetzung von Rechneranlagen. Mit Entstehung des ARPANET wuchs die Begehr-
lichkeit, Nachrichten über Rechnergrenzen hinweg zu übertragen. Ray Tomlinson ent-
wickelte Ende 1971 ein Emailprogramm, das dies erstmals ermöglichte. Auf Tomlinson
geht auch das at-Zeichen (@) zurück, das den Namensteil (localpart) und den Hostteil
(domainpart) trennt. Ray Tomlinson suchte nach eigenem Bekunden ein Zeichen, das
im ASCII-Zeichensatz enthalten war und kaum noch Verwendung fand. In den ASCII-
Zeichensatz wurde das at-Zeichen Anfang der Sechzigerjahre als angelsächsischer Er-
satz des kaufmännischen ,,à", das im deutschen und französischen Raum Verwendung
findet, aufgenommen.
6
Genau zehn Jahre nach der Entstehung des ARPANET wurde 1979 der erste Mail
Transfer Agent (MTA) Delivermail von Eric Allman publiziert. Mit der Umstrukturie-
rung des ARPANET (siehe auch Abschnitt 1.3, Protokolle) und der Verwendung von
TCP/IP und dem SMTP-Protokoll wurde Delivermail als Sendmail im Jahre 1983 im
Berkley Unix (BSD) 4.1c neu veröffentlicht. Trotz der Konkurrenz durch andere MTAs
konnte sich Sendmail bis heute behaupten und ist immer noch stark verbreitet.
7
6
[Conrady 2004, Seite 1820]; [Hein 2004, Seite 14, 15]; [Tomlinson 2, 3]
7
[Sendmail 1 1999]
1 Einführung
12
1.2 Internetgremien
Mit Gründung des ARPANET 1969 wurden von Dr. Stephen D. Crocker die Request
for Comments (RFC) ins Leben gerufen
8
und für die kommenden 28 Jahre durch
Dr. Jonathan B. Postel verwaltet.
9
In den RFC werden Dokumente veröffentlicht, bei denen organisatorische oder konzep-
tionelle Ideen vorgestellt werden. Einige dieser Dokumente sind nur informell, andere
dagegen werden als Standards übernommen. Aus den RFC beziehungsweise der Not-
wendigkeit zur Regulierung sind einige weitere Gremien hervorgegangen.
Ende der Siebzigerjahre halfen immer mehr Menschen bei der Entwicklung der Proto-
kolle und machten einen Ausschuss zur Lenkung der technischen Entwicklungen unab-
dingbar. Dr. Vinton Cerf gründete demzufolge 1979 das Internet Configuration Control
Board (ICCB), das der Vorgänger des 1983 gegründeten Internet Activities Board (IAB)
war, das wiederum heute unter dem Namen ,,Internet Architecture Board" bekannt ist.
10
Ein weiteres wichtiges Gremium bildet die Internet Assigned Numbers Authority (IA-
NA). Die IANA regelt die Vergabe von Domainnamen, IP-Adressen und Portnummern.
Heute ist ein Großteil dieser Gremien unter dem Dach der Internet Society (ISOC) zu-
sammengefasst.
,,Die überwiegende Anzahl der Standards im Internet werden von der In-
ternet Engineering Task Force (IETF) erarbeitet und als technische Do-
kumente, den sogenannten Request for Comments (RFC) veröffentlicht.
Die IETF ist eine organisierte Aktivität der ISOC, die als Dachorganisa-
tion die rechtliche Verantwortung für sie trägt."
11
Welche Gremien an der Bildung von Internetstandards beteiligt sind, wird in der RFC
2026 beschrieben.
12
Es gibt einige weitere Standadisierungsorganisationen, mit denen die ISOC/IETF in
Kooperation steht. Dies sind beispielsweise die International Organization for Standar-
dization (ISO) und der International Telecommunications Union-Telecommunication
Standardization Sector (ITU-T).
13
Siehe auch Kapitel 4.2.5, Standards.
8
[RFC 1160 1990, Seite 3, 4]
9
[RFC 2555 1999, Seite 2]
10
[RFC 1160 1990, Seite 1, 2]
11
[ISOC 1]
12
[RFC 2026 1996]; [RFC 3979 2005]
13
[RFC 3356 2002]; [RFC 3563 2003]
1 Einführung
13
1.3 Protokolle
Das im August 1982 von Dr. Jonathan B. Postel in der RFC 821 beschriebene Simple
Mail Transfer Protocol (SMTP) wurde als Standard für Email implementiert, bis es im
April 2001 erweitert und teilweise korrigiert wurde (RFC 2821). Das ,,einfache Mail-
Übertragungsprotokoll" (SMTP) beschreibt die technischen Erfordernisse zum Versand
von Email. Als Basis dient die gemeinsame Transportschicht, die eine Ende-zu-Ende-
Verbindung herstellt.
Heute sind TCP und UDP die gängigen Transportschichten, wobei für SMTP TCP ver-
wendet wird. Zu Zeiten der Entstehung von Email war das gängige Transportprotokoll
NCP, das jedoch 1983 durch den TCP/IP-Protokollsatz ersetzt wurde. Ebenso wichtig
wie die gesicherte Ende-zu-Ende-Verbindung via TCP (RFC 793) ist die Punkt-zu-
Punkt-Verbindung via IP (RFC 791). Diese Protokolle sind derart eng verbunden, dass
sie in der Regel immer zusammen erwähnt werden und auch als TCP/IP-
Protokollfamilie bekannt sind. TCP/IP gilt als Namensgeber für etwa 500 Protokolle, zu
denen auch SMTP gehört.
14
Ein weiteres wichtiges Protokoll im Umfeld von Email ist
das Domain Name System Protokoll (DNS).
1.3.1 TCP/IP
TCP/IP bildet die Grundlage für die Vernetzung von Rechnern. Diese beiden Protokolle
ermöglichen eine Kommunikation und sind nicht nur auf Computer beschränkt. Aktuell
werden immer mehr Menschen über die IP-Telefonie vernetzt.
,,TCP/IP ist die führende Kommunikationssoftware für lokale Netzwerke
und unternehmensweite Intranets und bildet die Grundlage des weltwei-
ten Internet."
15
,,Das IP hat die Aufgabe, die Netzknoten bei der Datenübertragung zu
adressieren, [...], sowie die Übermittlung von Datenpaketen zwischen ge-
trennten Netzwerken sicherzustellen."
16
TCP leistet die gesicherte Verbindung zweier Endpunkte. Das Sichern der Verbindung
basiert auf einem Drei-Wege-Handshake-Verfahren. Details können der RFC 793, Seite
27 und 28, entnommen werden. TCP stellt auch sicher, dass die Pakete in derselben
Reihenfolge, in der sie verschickt werden, beim Empfänger ankommen. Dies erreicht
TCP durch eine Sequenznummer im Header. TCP sowie das verbindungslose UDP
verwenden Ports für die Verbindung zweier Endpunkte. TCP lässt sich jeden Empfang
14
[Hein 2004, Seite 1416]
15
[Hunt 2003, Seite 2]
16
[Hein 2004, Seite 56]
1 Einführung
14
durch den Empfänger quittieren, UDP indessen versichert sich nicht, ob die Pakete auch
empfangen wurden.
Bei den verwendeten Ports sind die < 1023 privilegierte Ports, da sie in der Regel als
Root-Prozesse laufen. Die Portnummern werden von der Internet Assigned Numbers
Authority (IANA) vergeben. SMTP hat zum Beispiel den Port 25 TCP erhalten.
17
Die
Zuordnungen stehen in folgenden Dateien:
Windows C:\Windows\system32\drivers\etc\services (kann variieren)
Linux /etc/services
Die Zeile mit SMTP sieht etwa so aus:
smtp
25/tcp
mail
#Simple
Mail
Transfer
Protocol
1.3.2 DNS
Das Domain Name System (DNS) funktioniert im Wesentlichen wie ein Telefonbuch.
Hier werden Namen in Nummern übersetzt. Im Internet, das auf TCP/IP basiert, werden
32 Bit lange Nummern (IP Version 4) zur Adressierung verwendet. Wird zum Beispiel
www.example.com in den Browser eingegeben, verwendet dieser in Wirklichkeit die
Adresse 192.0.34.166 (4 Oktette à 8 Bit = 32 Bit). Der Browser findet diese Information
auf Grund des im Betriebssystem definierten DNS-Eintrags.
Anmerkung: Die Domains example.com, example.org und example.net wurden durch
die IANA für die Verwendung in Dokumentationen reserviert
18
(die Anwahl mit einem
Internetbrowser führt zu einem Fehler, da sich hinter diesen Domains keine Webseiten
befinden).
Bereits im damaligen ARPANET wurden mehr und mehr Rechner untereinander ver-
bunden. Der Austausch der Host-Dateien, in denen die Namen und Adressen der Rech-
ner vermerkt waren, wurde zunehmend aufwändiger und man suchte nach einer Alterna-
tive. Die Lösung war eine verteilte Datenbank mit delegierbaren Zuständigkeiten. Das
Domain Name System (DNS) war geboren. Ende 1983 wurden die ersten RFC (882 und
883) zu DNS veröffentlicht. Die aktuellen Spezifikationen können in RFC 1034 sowie
in RFC 1035 nachgelesen werden.
19
Im Umfeld von Email kommt dem DNS eine ganz besondere Bedeutung zu: Es ermög-
licht, anders als die Host-Datei, die Implementierung einer Ausfallsicherheit. Im DNS
können beliebig viele Ziele für Email definiert werden. Die Priorität der verschiedenen
Ziele wird dabei über einen Zahlenwert im so genannten ,,Mail Exchange Eintrag"
17
[Fritsch 2005, Seite 3438]
18
[RFC 2606 1999, Seite 1, 2]
19
[Albitz 2002, Seite xi-4]
1 Einführung
15
(MX) definiert. DNS ermöglicht demnach das Adressieren eines Namens, hinter dem
sich mehrere verschiedene Hosts verbergen können.
Als Beispiel soll eine Email an Robert@t-online.de geschickt werden. Ohne DNS be-
stünde nur die Möglichkeit, einen bestimmten Host, von dem die IP-Adresse bekannt
ist, zu adressieren. Das könnte Robert@[194.25.134.8] oder Robert@[mailin00.sul.t-
online.de] sein. Der Nachteil dabei liegt auf der Hand: Fällt der Server aus, kann die
Email nicht zugestellt werden. Mit DNS ist T-Online in der Lage, bei Bedarf eine neue
IP-Adresse zu publizieren und weitere Server zu der Kette der möglichen Ziele hinzuzu-
fügen. Im DNS sind nachstehende MX-Einträge für t-online.de definiert (Abfrage vom
21.02.2006):
Domain
Record
Typ Priorität Zielhost
t-online.de. IN MX 10 mailin01.sul.t-online.de.
t-online.de. IN MX 10 mailin02.sul.t-online.de.
t-online.de. IN MX 10 mailin03.sul.t-online.de.
t-online.de. IN MX 10 mailin04.sul.t-online.de.
t-online.de. IN MX 10 mailin05.sul.t-online.de.
t-online.de. IN MX 10 mailin06.sul.t-online.de.
t-online.de. IN MX 10 mailin07.sul.t-online.de.
t-online.de. IN MX 10 mailin00.sul.t-online.de.
T-Online hat acht Email-Server definiert, die für die Domain t-online.de Emails entge-
gennehmen. Jeder dieser acht Server muss wissen, wo Robert seinen Postkorb hat, und
die Email an ihn zustellen. Alle acht Server haben die gleiche Priorität, was neuere
Email-Server dazu veranlasst, sie auch zufällig anzusprechen, wodurch sich bereits eine
gewisse Lastverteilung ergibt.
20
1.3.3 SMTP
Das Simple Mail Transfer Protocol (SMTP) ist der Standard zum Austausch von Email.
Die folgende Abbildung 1 verdeutlicht, wie SMTP im Vergleich zu postalisch zugestell-
ten Briefen oder Postkarten funktioniert und wie die einzelnen Abschnitte technisch
benannt sind:
20
[Albitz 2002, Seite 103105]
1 Einführung
16
Body
Erika Absender
Homestreet 2
87569 Osterdorf
Hans Mustermann
Musterstr. 24
92354 Musterstadt
Betreff: Terminbestätigung
Sehr geehrter Herr Mustermann,
wie bereits telefonisch besprochen, bestätige ich den Termin
am 27.02.2006 um 10:00 Uhr. Bitte bereiten Sie die
entsprechenden Unterlagen vor.
Vielen Dank.
Mit freundlichen Grüßen
(Erika Absender)
Osterdorf, 20.02.2006
Ihr-Zeichen: XYZ4711
Hans
Muste
rmann
Muste
rstr. 2
4
92354
Must
erstad
t
Erika
Abse
nder
Home
stree
t 2
8756
9 Ost
erdor
f
Message-ID
Subject
Body
From
To
Date
Header
Envelope
IP-Ad
resse
Enve
lope-
From
Enve
lope-
To
Abbildung 1: Simple Mail Transfer Protocol
21
Die Zustellung von Email basiert in erster Linie auf den Daten, die sich auf dem Brief-
umschlag (engl. envelope) befinden. Der Server merkt sich beim Verbindungsaufbau
mindestens die folgenden drei Informationen: Woher die Email (IP-Adresse) kommt,
wer sie geschickt hat (Absender = Envelope-From) und an wen sie gesendet werden soll
21
[Siehe auch Hildebrandt 2005, Seite 88]
1 Einführung
17
(Empfänger = Envelope-To). All diese Informationen sind Inhalte des Briefumschlags,
den der Anwender eines Email-Client in der Regel nicht zu sehen bekommt.
Zur Anzeige im Email-Client, auch ,,Mail User Agent" (MUA) genannt, sind die Daten
des Briefpapiers vorgesehen. Die Informationen des Briefpapiers können in den Brief-
kopf (engl. header) und den eigentlichen Brief (engl. body) unterteilt werden. Die Zu-
stellung erfolgt an den Empfänger, der auf dem Briefumschlag angegeben ist. Diese
Information wird bei bei SMTP als ,,Envelope-To" bezeichnet.
Ist der Envelope-To nicht erreichbar, geht die Email an den Absender (Envelope-From)
zurück. Hierbei handelt es sich um einen Rückläufer (Bounce). Ist auch der Absender
nicht erreichbar, löscht der Email-Server die Email nach einer definierten Zeitspanne.
Solche Emails kommen vermehrt bei Spam (siehe Kapitel 3.1, Unerwünschte Emails)
vor und werden als ,,double Bounces" bezeichnet.
Um bei der Analogie zur Post (Post meint nicht explizit die ,,Deutsche Post", sondern
schließt auch andere Zusteller mit ein) zu bleiben, ist im Unterschied zur Post der Brief,
der sich in einem Umschlag (engl. envelope) befindet, ebenso ungeschützt und für jeden
wie eine Postkarte lesbar. Dies setzt natürlich voraus, dass der Angreifer durch geeigne-
te Methoden den Datenverkehr abhören kann (siehe auch Kapitel 4, Email-
Verschlüsselung).
22
Da es sich bei SMTP um ein textorientiertes Protokoll handelt, kann der Ablauf einer
SMTP-Verbindung mit der Anwendung
Telnet
getestet werden. Im Folgenden wer-
den die Befehle des Clients und die Antworten des Servers dokumentiert:
$ telnet halsrv01 smtp
220 HALSRV01 ESMTP Service ready at Sun, 5 Feb 2006 17:17:15 +0100
helo halwks01.hal.de
250 halsrv01.hal.de Hello halwks01.hal.de ([192.168.100.24]),
pleased to meet you
mail from: <stockhal@web.de>
250 stockhal... Sender OK
rcpt to: <stockhal@freenet.de>
250 stockhal... Recipient OK
data
354 Enter message, end with "." on a line by itself
22
[Spenneberg 2006, Kapitel 4, Bedrohungen bei der Vernetzung von Systemen]
1 Einführung
18
From: Lars Stockhausen <stockhal@web.de>
To: Lars Stockhausen <stockhal@freenet.de>
Subject: Test-Email
Date: 05.02.2006 17:14:00
Message-ID: 4711@hal.de
Bodytext
.
250 Message accepted for delivery
quit
221 halsrv01.hal.de SMTP Service closing transmission channel
Connection closed by foreign host.
Bei wird mit der Anwendung
Telnet
eine Verbindung zwischen Client und Server
aufgebaut. Der Client löst zunächst via DNS den Namen ,,halsrv01" auf und verbindet
sich zu der ermittelten IP-Adresse. Der Port 25 wird aus der Datei services anhand der
Eingabe von smtp ermittelt. Der Server meldet durch die Rückgabe des Wertes 220,
dass der Service bereit steht und Emails empfangen kann. Die Angabe des Serverna-
mens, des Protokolls, des Datums, der Uhrzeit und der Zeitzone sind optional.
Es folgt in das erste SMTP-Kommando. Jedes Kommando beginnt mit einem vier-
stelligen Codewort
23
, daher lautet der Befehl helo und nicht ,,hello". Mit diesem Befehl
meldet sich der Client beim Server und gibt ihm seinen Hostnamen, in der Regel den
voll qualifizierten (engl. Fully Qualified Domain Name, FQDN), bestehend aus local-
part und domainpart, bekannt. Der Server bestätigt die Aktion mit der Rückgabenum-
mer 250.
In und werden Absender (Envelope-From ) und Empfänger (Envelope-To ) an
den Server übermittelt, woraufhin dieser die Aktion abermals mit 250 bestätigt.
bilden den Envelope.
Das data-Kommando aus leitet Briefkopf (Header) und Brief (Body) ein. Der Server
meldet den Status 354, in dem mitgeteilt wird, wie der Datenblock zu beenden ist (siehe
Punkt ).
Ab folgt der Header mit seinen Informationen aus Abbildung 1.
trennt Header und Body durch eine Leerzeile.
Ab beginnt der Body.
23
[Hein 2004, Seite 297]
1 Einführung
19
In folgt das Ende durch einen Punkt in einer separaten Zeile. Viele Server geben an,
den Datenblock durch Eingabe von <CRLF>.<CRLF> zu beenden. Carriage Return
(CR) und Line Feed (LF) werden implizit ausgeführt, sobald die Datenfreigabetaste
(Enter/Return) betätigt wird, und meint exakt, was der SMTP-Server in diesem Beispiel
zurückmeldet:
354 Enter message, end with "." on a line by itself
Mit quit in endet die Kommunikation, woraufhin der Server mit einem abschließen-
den 221 antwortet.
24
Eine Liste der wichtigsten Rückgabewerte finden Sie im Anhang A.1 Statuswerte einer
SMTP-Verbindung.
1.3.4 ESMTP
ESMTP ist eine Erweiterung des SMTP-Protokolls. An der Antwort des Servers auf die
Kommunikationsverbindung aus Kapitel 1.3.3 ist zu erkennen, dass der Server die
ESMTP-Erweiterung beherrscht.
220 HALSRV01 ESMTP Service ready at Sun, 5 Feb 2006 17:17:15 +0100
Anmerkung: Die Begrüßungszeile ist konfigurierbar und kann des Hinweises ESMTP
ermangeln.
Ein Beispiel einer Erweiterung
25
ist:
·
8BITMIME
Die 8BITMIME
26
-Funktion verdoppelt die mögliche Anzahl von Zeichen, die in
einer Email verwendet werden können. Ursprünglich standen 7 Bit zur Verfü-
gung. Mit diesen 7 Bit sind 128 Zeichen (2
7
= 128) darstellbar. Mit 8 Bit sind
dementsprechend 256 Zeichen (2
8
= 256) darstellbar.
Im Anhang A.2 ESMTP-Erweiterungen, befindet sich eine Liste einiger weiterer
ESMTP-Funktionen.
1.3.5 MIME
Ursprünglich war Email nur für Textnachrichten konzipiert. Das Format einer Email
wurde in RFC 822
27
(aktualisiert durch RFC 2822
28
) beschrieben. Inhaltlich waren nur
die in 1.3.4 erwähnten 128 Zeichen der US-ASCII-Tabelle
29
möglich.
24
[Siehe auch Hildebrandt 2005, Seite 9]
25
[Hildebrandt 2005, Seite 12, 13]
26
[RFC 1652 1994]
27
[RFC 822 1982]
28
[RFC 2822 2001]
1 Einführung
20
Um via Email Anhänge verschicken zu können, musste eine Kodierung erfunden wer-
den, die Dateien in erlaubte ASCII-Zeichen umwandelt. Die erste Kodierung, die dies
ermöglichte, war UUENCODE. Die dementsprechend kodierten Anhänge wurden im
Body der Email untergebracht und mussten von Hand herauskopiert und wieder deko-
diert werden. Die meisten heutigen Email-Clients beherrschen zwar diese Kodierung,
aber sie wird nur noch selten genutzt.
Heute sind Emails nach dem MIME
30
-Standard üblich. Mit der Multipurpose Internet
Mail Extensions (MIME) wurde ein zum Format aus RFC 822 kompatibler Standard
entwickelt, der es ermöglicht, Emails in mehrere Abschnitte zu unterteilen. Darüber
hinaus ist es nicht nur möglich, Anhänge zu verschicken, sondern auch, Informationen
über den Typ des Anhangs zu vermitteln. MIME ist die Basis heutiger multimedialer
Emails mit bunten Hintergründen, Sounds und Emoticons (engl. icon = Piktogramm,
zum Beispiel Smilies, um nonverbale Emotionen zu kommunizieren).
Ebenfalls definiert sind die Kodierungsmethoden, um Anhänge und/oder Sonderzeichen
und Umlaute zu kodieren (siehe auch Kapitel 1.4, Kodierung und Zeichensatz).
Die in MIME gängigen Kodierungsmethoden sind Base64, vorrangig für binäre Anhän-
ge (zum Beispiel *.exe), und Quoted-Printable für Texte mit Sonderzeichen und/oder
Umlauten. Die Funktionsweise der Kodierungsmethoden wird in Kapitel 1.4, Kodierung
und Zeichensatz, erläutert.
Im Folgenden wird der Seitenquelltext einer typischen MIME-Email dargestellt. Den
Seitenquelltext (engl. page source) können viele gängige Email-Clients anzeigen (am
Beispiel von Microsoft Outlook Express: In der Email, Menü Da-
tei/Eigenschaften/Details Quelltext). Eine weitere Möglichkeit, den Seitenquelltext zu
erhalten, ist eine Einrichtung der technischen Universität (TU) Berlin. Die TU Berlin
betreibt einen Echo-Server, der alle Emails an die Adresse echo@tu-berlin.de mit dem
gesamten Seitenquelltext an den Absender zurückschickt (zum Zeitpunkt der Erstellung
dieser Arbeit liegen keine Pläne seitens der Technischen Universität Berlin vor, diesen
Dienst zu deaktivieren).
From: stockhal@web.de
To: echo@tu-berlin.de
Subject: Euro
MIME-Version:
1.0
Content-Type: multipart/alternative;
boundary="=_alternative 003D1B1EC1257127_="
Dies ist eine mehrteilige Nachricht im MIME-Format.
--=_alternative
003D1B1EC1257127_=
29
[RFC 20 1969, Seite 2]
30
[RFC 20452049 1996]
Ende der Leseprobe aus 96 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2006, Kommunikation und Infrastruktur, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/225127
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare