Kommunikation und Infrastruktur

Stockhausen, Lars

Kommunikation und Infrastruktur

Informatik - Internet, neue Technologien

Zusammenfassung

Inhaltsangabe:Gang der Untersuchung:
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 Groupware-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 Themen 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 einen Ausblick, welche Themen weiterführend interessant sein könnten.

Inhaltsverzeichnis:Inhaltsverzeichnis:
Über den Autor2
Kurzfassung3
Inhaltsverzeichnis4
Abbildungsverzeichnis7
Tabellenverzeichnis7
Vorwort8
Leserkreis9
Aufbau und Konventionen der Arbeit10
1.Einführung11
1.1Entstehung von Email11
1.2Internetgremien12
1.3Protokolle13
1.3.1TCP/IP13
1.3.2DNS14
1.3.3SMTP15
1.3.4ESMTP19
1.3.5MIME19
1.3.6POP321
1.3.7IMAP423
1.4Kodierung und Zeichensatz23
2.Infrastruktur27
2.1Einführung27
2.2Schema einer Internetanbindung27
2.2.1IP-Adressen28
2.2.2Bereitstellung von Diensten im Internet30
2.2.3Gemeinsame Nutzung von Internetdiensten31
2.3Testnetz32
2.3.1Szenario 1: Lokale Zustellung an virtuelle Domain33
2.3.2Szenario 2: Lokale Zustellung von Client zu Client35
2.3.3Szenario 3: Entfernte Zustellung37
2.3.4Szenario 4: Entfernte Zustellung an internen Groupware-Server39
2.3.5Szenario 5: Entfernte Zustellung über Backup-Server42
3.Filtertechniken45
3.1Unerwünschte Emails45
3.1.1Spam45
3.1.2Viren, Würmer und Trojaner46
3.1.3Falschmeldungen und Kettenbriefe46
3.1.4Phishing47
3.1.5Verbotene Emails im Unternehmenseinsatz47
3.2Erkennung unerwünschter Emails47
3.2.1Statische (regelbasierte) Erkennung48
3.2.2Dynamische (lernende) […]

Leseprobe

Inhaltsverzeichnis

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.

http://www.diplom.de, Hamburg 2007

Printed in Germany

Über den Autor

Ü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

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

Inhaltsverzeichnis

Über den Autor ... 2

Kurzfassung... 3

Inhaltsverzeichnis ... 4

Abbildungsverzeichnis... 7

Tabellenverzeichnis ... 7

Vorwort... 8

Leserkreis ... 9

Aufbau und Konventionen der Arbeit ... 10

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

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

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

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

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

Schlusswort ... 70

Anhang A: Technisches ... 71

A.1 Statuswerte einer SMTP-Verbindung ... 71

Inhaltsverzeichnis

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

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

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

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

, 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.

[Tomlinson 1]

[Knuth 2006]

Leserkreis

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

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.

Normaler Text wird mit der Serifenschrift Times New Roman geschrieben. Seri-

fenschriften besitzen eine gute Zeilenführung und gelten daher als lesefreund-

lich.

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 `).

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.

[Riekert 2002]

[Vgl. Riekert 2002, Seite 23]

[DIN 1505]

1 Einführung

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.

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.

[Conrady 2004, Seite 1820]; [Hein 2004, Seite 14, 15]; [Tomlinson 2, 3]

[Sendmail 1 1999]

1 Einführung

1.2 Internetgremien

Mit Gründung des ARPANET 1969 wurden von Dr. Stephen D. Crocker die Request

for Comments (RFC) ins Leben gerufen

und für die kommenden 28 Jahre durch

Dr. Jonathan B. Postel verwaltet.

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.

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."

Welche Gremien an der Bildung von Internetstandards beteiligt sind, wird in der RFC

2026 beschrieben.

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).

Siehe auch Kapitel 4.2.5, Standards.

[RFC 1160 1990, Seite 3, 4]

[RFC 2555 1999, Seite 2]

[RFC 1160 1990, Seite 1, 2]

[ISOC 1]

[RFC 2026 1996]; [RFC 3979 2005]

[RFC 3356 2002]; [RFC 3563 2003]

1 Einführung

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.

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."

,,Das IP hat die Aufgabe, die Netzknoten bei der Datenübertragung zu

adressieren, [...], sowie die Übermittlung von Datenpaketen zwischen ge-

trennten Netzwerken sicherzustellen."

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

[Hein 2004, Seite 1416]

[Hunt 2003, Seite 2]

[Hein 2004, Seite 56]

1 Einführung

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.

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

(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.

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"

[Fritsch 2005, Seite 3438]

[RFC 2606 1999, Seite 1, 2]

[Albitz 2002, Seite xi-4]

1 Einführung

(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.

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:

[Albitz 2002, Seite 103105]

1 Einführung

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

92354

Must

erstad

Erika

Abse

nder

Home

stree

t 2

8756

9 Ost

erdor

Message-ID

Subject

Body

From

Date

Header

Envelope

IP-Ad

resse

Enve

lope-

From

Enve

lope-

Abbildung 1: Simple Mail Transfer Protocol

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

[Siehe auch Hildebrandt 2005, Seite 88]

1 Einführung

(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).

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

[Spenneberg 2006, Kapitel 4, Bedrohungen bei der Vernetzung von Systemen]

1 Einführung

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

, 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.

[Hein 2004, Seite 297]

1 Einführung

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.

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

ist:

8BITMIME

Die 8BITMIME

-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

= 128) darstellbar. Mit 8 Bit sind

dementsprechend 256 Zeichen (2

= 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

(aktualisiert durch RFC 2822

) beschrieben. Inhaltlich waren nur

die in 1.3.4 erwähnten 128 Zeichen der US-ASCII-Tabelle

möglich.

[Siehe auch Hildebrandt 2005, Seite 9]

[Hildebrandt 2005, Seite 12, 13]

[RFC 1652 1994]

[RFC 822 1982]

[RFC 2822 2001]

1 Einführung

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

-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_=

[RFC 20 1969, Seite 2]

[RFC 20452049 1996]

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2006
ISBN (eBook): 9783956361180
ISBN (Paperback): 9783836600552
Dateigröße: 850 KB
Sprache: Deutsch
Institution / Hochschule: FOM Hochschule für Oekonomie & Management gemeinnützige GmbH, Neuss früher Fachhochschule – unbekannt
Erscheinungsdatum: 2006 (Dezember)
Note: 1,3
Schlagworte: e-mail spam

Autor

Lars Stockhausen (Autor:in)

Kommunikation und Infrastruktur

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Lars Stockhausen (Autor:in)