EMail – Grundlagen, Arbeitsweise, Header, SMTP, Security

1.)    SMTP

2.)    Postmaster und Mailer-Daemon

3.)    Arbeitsweise von E-Mail-Systemen (Listener, Spooler, MDA)

4.)    Die Wege einer Mail

5.)    Nachrichten in der Message Queue

6.)    Header nach RFC-822 (mit Beispiel und Beschreibung)

7.)    SMTP – Verbindungaufbau (ESMTP – Test)

8.)    Schutz im Internet (Angriffe auf den Mail-Server)

9.)    Umgang mit Binärdaten (Mailanhänge)

10.)   E-Mails sicher lesen von zu Hause

11.)   Glossar

1.) SMTP:

Im Internet existiert seit Jahren ein gültiger Standart – das Simple Mail Transport Protocol.

Diese Schnittstelle setzt voraus, dass alle E-Mail-Teilnehmer (Client / Server) ständig im Internet präsent sind. Durch Modem und ISDN bzw. durch Standleitungen stellt dies heutzutage kein Problem dar. Dies war früher nicht selbstverständlich, weshalb neben SMTP auch der Begriff UUCP beim Thema E-Mail eine Rolle spielt. Das Unix-to-Unix-Copy kann ebenfalls zum Transport von E-Mails eingesetzt werden und findet vor allem dort Anwendung, wo der Austausch von Nachrichten eher selten oder unregelmäßig (z.B. über Modemverbindungen) stattfindet.

2.) Postmaster und Mailer-Daemon:

Die erste Pflicht von angeschlossenen Rechnern, an das Internet, sollte die Bereitstellung einer administrativen E-Mail-Adresse – weltweit genormt- sein. Diese Mailbox heist immer „Postmaster“. Der für den Mailserver zuständige Techniker bzw. Administrator hat die Pflicht, die Mailbox dieses Accounts regelmäßig einzusehen. Wichtig hierbei ist, dass diese Aufgabe sehr ernst genommen wird. Sollte ein Server missbraucht werden (z.B. als Junk-Mail-Verteiler), kann es vorkommen, dass der Provider kurzerhand die Verbindung zum Server ins Internet von sich aus kappt.

Die zweite administrative Kennung eines Mailsystems ist der „Mailer-Daemon“, je nach Software. Sie wird nur für den Versand von automatischen Hinweisen des Mailservers verwendet, falls dieser Probleme oder Fehler feststellt. Ein Serverprozeß, der Mails bearbeitet, ist ein „Mailer-Daemon oder kurz Mailer“.

3.) Arbeitsweise von E-Mail-Systemen:

Wie bei fast allen elektronischen Diensten, handelt es sich auch bei E-Mail um eine Client-Server-Applikation mit fest definierten (standardisierten) Schnittstellen. Der Mail-Server besteht aus einem Listener (der Teil des Programms, der auf kommende Verbindungen wartet und neue Mails empfängt), einem Spooler (für das interne Handling der Mails) und einer Schnittstelle zu einem oder mehreren MDAs (Mail Delivery Agent), die die eigentliche Zustellung der Nachrichten vornehmen.

Normalerweise gibt es mindestens einen lokalen MDA, der die eingetroffenen Mails direkt in der Mailbox des betreffenden Benutzers speichert. Desweiteren leitet ein Remote-MDA Mails an entfernte Systeme weiter. MDAs können auch gewünschte Gateway-Funktionen bereitstellen, z.B. den Ausdruck einer Mail, die Weiterleitung an ein Fax-Gerät oder die Aufbereitung und Übermittlung der Nachrichten an E-Mail-Systeme anderer Standards (z.B. UUCP oder X.400).

Aber wie kommt nun die Mail zum Anwender?

Um Nachrichten zuzustellen kommt ein weiterer Server zum Einsatz, der mit dem eigentlichen Mailsystem nichts zu tun hat. Dieser Server wird POP- oder IMAP-Server genannt.

Das Verständnis dieser Besonderheit ist wichtig für den Umgang mit E-Mail-Systemen und der Planung einer Konfiguration!

E-Mail-Programme kommunizieren zum Versand von Mails mit dem SMTP-Listener eines Mail-Servers. Der Empfang von Mails - aus einem entfernten Postfach - kommt über den POP- oder IMAP-Server zustande (der Bestandteil einer Mail-Software sein kann, aber nicht muß).

4.) Die Wege einer Mail:

Der Mailversand – oft nur ein Mausklick – löst eine Kettenreaktion aus. Nur wer versteht, was dabei vor sich geht, ist im Falle eines Fehlers gewappnet. Wenn also ein Anwender eine Mail abschickt, dann passiert folgendes:

Das Mailprogramm konvertiert die neuen Mitteilungen in das für Mails vorgeschriebene Format (RFC-822). Anschließend wird eine Verbindung zum Listener (des vom Benutzer voreingestellten Mail-Servers für ausgehende Nachrichten) hergestellt. Es erfolgt die Anmeldung beim Server, dann die Übertragung der Absender- und einer oder mehrere Empfängeradressen. Hat der SMTP-Server diese Daten positiv quittiert, wird der Rest der Mail übertragen, und die Arbeit ist für das Mailprogramm erledigt.

Der MTA leitet die empfangene Nachricht (Mail) dann an seinen Spooler weiter, der die Mitteilung nach der Prüfung der Empfängeradresse in der Mail-Warteschlange (Message Queue) speichert. Anhand der Empfängeradresse ist bekannt, ob die Nachricht für einen Anwender im internen Netz bestimmt ist oder ob an ein entferntes Mail-System weitergeleitet werden muß.

5.) Nachrichten in der Message Queue:

Im Falle einer lokalen Adresse holt sich der lokale MDA eine Kopie der Nachricht aus der Warteschlange und versucht, sie in der Mailbox des Empfängers zu speichern. War dieser Vorgang erfolgreich, wird die Nachricht in der Message Queue als erfolgreich an den lokalen Empfänger zugestellt markiert.

Ist die Nachricht an eine entfernte Adresse zu schicken, holt sich der zuständige Remote-MDA eine Kopie der Mail aus der Warteschlange und versucht den Verbindungsaufbau zum SMTP-Listener des entfernten Systems. Kann er die Mail dort erfolgreich ablegen, erfolgt eine Positivmeldung in die Warteschlange für die betreffende Adresse.

Stellt der MTA fest, dass für alle Empfängeradressen einer Mail positive Zustell-Rückmeldungen hinterlegt sind, dann betrachtet er sie als erfolgreich zugestellt und entfernt die Nachricht aus der Warteschlange.

Gibt es fehlerhafte Rückmeldungen (z.B. wegen eines ausgefallenen DNS-Servers), versucht der zuständige MDA die Zustellung in aller Regel noch mehrere male, bevor er aufgibt. Ist der aufgetretene Fehler nicht zu beheben (z.B. bei einer fehlerhaften Adressangabe), dann generiert das Mail-System automatisch eine Mitteilung an den Absender. Ist diese Fehlermeldung erfolgt, wird die Mail ebenfalls aus der Warteschlange entfernt. In diesem Fall spricht man von einem Bounce.

6.) Header nach RFC-822 (mit Beispiel und Beschreibung):

Der Header einer Mail gibt viel über den Verlauf der Mail, sowie dessen Absender preis. Allerdings sind die Angaben für Leihen sehr schwer zu dechiffrieren.

Die Header-Informationen von E-Mails werden grundsätzlich von unten nach oben gelesen und enthalten wissenswerte Fakten. Normalerweise dürfen zwischen den einzelnen Headern in einer Mail keine Leerzeilen vorkommen.

Hier ein Beispiel:

***************************************************

Received: from mx0.gmx.net by mx02.web.de with smtp
(freemail 4.2.2.2 #11) id m15bk6K-0015ZQA; Tue, 28 Aug 2001 16:44 +0200
Received: (qmail 13153 invoked by uid 0); 28 Aug 2001 14:44:23 -0000
Date: Tue, 28 Aug 2001 16:44:23 +0200 (MEST)
From: datahelp@gmx.de
To: datahelp@web.de
MIME-Version: 1.0
Subject: Test: Mail-Header
X-Priority: 1 (Highest)
X-Authenticated-Sender: #<a href="/online/telefonieren/?si=93Z7.15BK7A.rGEtq.h&alt=0006644376">0006644376</a>@gmx.net
X-Authenticated-IP: [192.142.242.125]
Message-ID: <21102.999009863@<a target="_new" href="/jump.htm?url=www36.gmx.net">www36.gmx.net</a>>
X-Mailer: WWW-Mail 1.5 (Global Message Exchange)
X-Flags: 0001
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit


Dies ist eine Test-Mail!

***************************************************

Beschreibung:

Jede Received-Zeile steht für einen sogenannten Hop. Von unten nach oben gelesen lässt sich exakt nachvollziehen, wann die Mail welchen Host (Server) passiert hat, bis sie schließlich am Ziel angekommen ist.

Die Message-ID ist eine Kennzeichnung jeder Mail, die weltweit eindeutig sein sollte.

Die From:-Zeile bezeichnet den Absender einer Mitteilung. Aber hier kann eigentlich jeder beliebiger Absender stehen – Hauptsache RFC-konform.

Die To:-Zeile bezeichnet den Empfänger einer Mitteilung.

Return-Path: Das ist der physikalische Absender, der in der Regel dem Envelope-Absender entspricht.

Die übrigen Header dienen in erster Linie der Information für den Administrator.

Durch eine Leerzeile getrennt beginnt nach den Headern die eigentliche Mitteilung.

Zusammenfassung Mail-Header:

Bcc – Was ist hier besonderes ?:

Um eine ungewollte Ausbreitung von Mail-Adressen zu verhindern, wurde in RFC-822 das Bcc-Feld definiert. Die hier eingetragenen Adressen sind für die Empfänger der Mail nicht sichtbar, egal, ob diese in das To:, Cc: oder Bcc: - Feld eingetragen wurden. (Bsp.: man schreibt an sich To: eine Mail und trägt weitere Empfänger in das Bcc-Feld ein, somit ist ein gegenseitiges „ausspionieren“ fast unmöglich.)

7.) SMTP – Verbindungaufbau (ESMTP – Test):

Die nachfolgende Tabelle beschreibt den Datenfluß zwischen Sender und Empfänger. Die aufgeführten Textinformationen des antwortenden Servers sind nicht notwendig und dienen als Zusatzinformation für den Administrator. Der SMTP-Sender identifiziert nur die Zahlenwerte, die über den Status eines Kommandos oder eine Fehlermeldung Aufschluß geben.

8.) Schutz im Internet (Angriffe auf den Mail-Server):

Wer einen Mail-Server im Internet betreibt, ist vor Angriffen von anderen nicht sicher!

Desweiteren ist zunehmend problematisch die Massenaussendungen (meistens Werbemails) von Unternehmen - die sog. UCE (Unsolicited Commercial E-Mail). Wer sich gegen diese Überschwemmung seines Postfaches als einzelne Person zur Wehr setzen will, hat i.d.R. schlechte Karten. Die Antwortadressen der verschickten Massensendungen sind entweder falsch oder führen nur zu einem Automaten, der jede Reaktion eines gepeinigten Empfängers dahingehend honoriert, dass er die betreffende E-Mail-Adresse als besonders wertvoll kennzeichnet. Zwar existieren diverse Urteile gegen solche Unternehmen aber ein effektiver Erfolg bleibt meistens aus. Meist wandern die Unternehmen in Ländern ohne Bestimmungen von Massen-E-Mails ab und schon ist wieder das gleiche – UCE.

Möglichkeiten der UCE-Abwehr:

Leider sind die technischen Möglichkeiten zur UCE-Abwehr beschränkt. Zwar kann man Filterfunktionen installieren, dies bewirkt aber die Gefahr das auch harmlose Mails mit betroffen werden können. Als erste kleinere Hilfe ist ein Filter auf die Envelope-From-Adresse einzutragen. Hiermit werden alle Mails von der Absenderadresse geblockt, also nicht angenommen. Wollen Sie weitergehende Maßnahmen ergreifen, bleibt meistens nur das Ersetzen des Standard-SMTP-Listeners des Mailsystems durch eine aggressivere Variante, die mit speziellen Features im Kampf gegen unerwünschte Mailzusendungen ausgestattet ist. Hierzu zählen Programme wie zum Bsp. Teergrube oder Blackmail. An dieser Stelle sei aber erwähnt, dass bei Aktionen von diesen Programmen falsche Mailer betroffen werden könnten und somit es viel Ärger geben kann!

Mailbomben, Spam-Mails etc.:

Ist UCE einfach nur lästig und zeitraubend, gefährden Mailbomben den einwandfreien Betrieb eines Mailsystems. Ressourcen werden so stark belegt bis evtl. das Mailsystem zusammen brechen kann. Bei Mailbomben handelt es sich um den gezielten Angriff von außen auf eines oder mehrere Postfächer. Verschickt werden meist Unmengen von winziger Mitteilungen ohne Inhalt. Viele tausend Mitteilungen sind bei einer solchen Attacke keine Seltenheit, und es kostet das Opfer oft Stunden, seine Mailbox zu säubern.

Verfasser verfolgen:

Eine Analyse zum Auffinden des Verfassers ist nicht einfach. Viele Informationen erfordern einen guten Adminstrator und natürlich auch einen guten Provider der entsprechende Anfragen beantwortet. Wie schon bei den Werbemails können Sie auch Angriffe nicht mit einem einzigen Trick abwehren. Zu schnell entwickeln sich die Programme und die verschiedenen Angriffsmöglichkeiten. Im Zweifelsfall bleibt nur die Installation eines aggressiven SMTP-Listeners, der spezielle Abwehrmechanismen bereitstellt. Aber wieder mit äußerster Vorsicht betreiben!

9.) Umgang mit Binärdaten (Mailanhänge):

Zum Verschicken von Grafik- und Programmdateien benötigt man sog. Umwandlungs-Algorithmen. Grund: Da der Mailstandard im Internet nur 7-Bit-Zeichen zulässt, stellt sich natürlich die Frage wie beispielsweise Grafik- und Programmdateien verschickt werden. Diese enthalten binäre 8-Bit-Informationen und wären eigentlich nicht transportierbar. Hier greift die sog. Konvertierung. Durch spezielle Algorithmen lassen sich 8-Bit in 7-Bit-Daten umwandeln. Die zu übertragende Bruttodatenmenge steigt dadurch zwar an, aber dennoch hat sich diese Vorgehensweise im Laufe der Jahre im Internet durchgesetzt.

UUCode und Base64:

Im wesentlichen gibt es für diese Konvertierung zwei Standards: UUCode und Base64. Der erste ist der ältere Standard und erfordert zumeist eine manuelle Umwandlung der Daten. Der zweite kam zusammen mit der Einführung des Mime-Standards (Multi purpose Internet Mail Extension) und wird von allen modernen E-Mail-Programmen automatisch unterstützt. Der Benutzer merkt kaum noch was von der Ver- und Entschlüsselung der Anhänge. Meistens treten Fehler bei Anhängen die nicht Mime-konform versendet werden auf. Hier sind häufig die Clients – nicht der Mail-Server – schuld.

10.) E-Mails sicher lesen von zu Hause:

Die normalen Protokolle POP3 und IMAP (zum Abholen der Mails) schicken das Passwort im Klartext zum Server. Somit kann jeder mit etwas krimineller Energie das Postfach „stürmen“.

1. Lösung: S/POP3 oder IMAPS

Es gibt eine sichere, verschlüsselte Variante: POP3S (ssl) bzw. IMAPS. Bedingung der Client sollte Verschlüsselung unterstützen.

2. Lösung: POP3 und SMPT mit SSH tunneln

Man baut zum Server eine SSH-Verbindung auf und holt danach seine E-Mails ab (Login/Passwort werden verschlüsselt über die Leitung übertragen).

Kommentar:

IMAP (Internet Mail Access Protocoll) beinhaltet eine Verschlüsselung, diese ist aber nur optional einstellbar. Da aber viele E-Mail-Programme IMAP noch nicht voll unterstützen sollte man hier einen alternativen Weg zur Übertragung suchen.

Funktionsweise (Technischer Hintergrund):

Auf dem Mail-Server läuft ein spezielles Programm (z.B. sendmail), welches nichts weiter tut, als auf eingehende Mails zu warten und um diese dann zuzustellen oder weiterzuleiten. Das e-Mail-Programm auf dem Client-Rechner baut nun zum Server eine TCP-Verbindung zum Port 25 des Mailers auf. Nun werden die Mails vom Client zum Server unverschlüsselt übertragen.

Der Client nimmt für ausgehende Verbindungen irgendeinen „nächsten freien“ Port zum Server.

Wie funktioniert das ganze bei ssh?

Der SSH-Client macht eine Verbindung zum SSH-Server auf. Dazu müssen sich beide Rechner dem anderen gegenüber durch ihren sog. HOST-KEY authentifizieren. Danach folgt der schematische Ablauf von Bild oben. Nun kann der User Login und Passwort verschlüsselt übertragen. Gute E-Mail-Programme sowie gute Provider machen dies mit ihren Kunden sowieso automatisch, d.h., der Nutzer braucht sich um die ssh-Verbindung weiter keine Kopfzerbrechen bereiten.

(Eine ausführliche Beschreibung zu ssh-Verbindungen wird nachgereicht – aber in diesem Thema etwas vernachlässigt - da es hier um das eigentliche Mail-System geht.)

11.) Glossar:

Copyright ©      www.datahelp.de

Modifizierung oder Weitergabe an Dritte nur mit Einverständnis des Autors gestattet !