Sprungmarken

Videoportal der FAU

Die letzten Meldungen

Novell Serverwartung MOLMED am Dienstag, 22 Mai von 8 Uhr bis ca. 11 Uhr

16. Mai 2012

Am Dienstag, 22 Mai findet von 8 Uhr bis voraussichtlich 11 Uhr eine dringende Serverwartung des Novell-Servers “MOLMED” statt. In der genannten Zeit ist der Zugriff auf die Volumes “USERTEMP” und “SYS” nicht möglich.
Weiterlesen...

Terminänderung – Vortrag “Einführung von fau.de-Maildomains und neuen Mail-/Groupware-Komponenten für die FAU” verschoben

15. Mai 2012

Aufgrund von Terminüberschneidungen mussten im Rahmen der Vorlesung “PRAXIS DER DATENKOMMUNIKATION” (Netzwerkausbildung) Termine getauscht werden.
Weiterlesen...

RRZE-Betrieb am „Berch“-Dienstag

15. Mai 2012

Am Dienstag, den 29.05.2012, wird das RRZE ab 12 Uhr geschlossen.
Weiterlesen...

Meldungen nach Thema

 

Hinweise zum Dokumentenaustausch per E-Mail

Mit der weltweiten Verbreitung des Internet wächst auch der Wunsch, per E-Mail nicht nur einfache Notizen sondern auch komplexe Dokumente, Bilder oder ähnliches auszutauschen. Leider enden viele dieser Versuche damit, dass beim Empfänger nur Datenschrott landet. Dieser Artikel soll etwas die Hintergründe erhellen und Tips geben, wie man zu einem optimalen Ergebnis kommt.

Wer sich für den theoretischen Hintergrund nicht interessiert, kann direkt bei Zusammenfassung weiterlesen und erfährt dort das Wichtigste in Kürze.

Historisches oder: For every problem there is one solution that is simple, neat and wrong (H.L. Menken)

Die ersten E-Mail-Systeme waren nur für die Übertragung von 7 Bit-Daten ausgelegt. Das reichte zum Austausch von einfachen Nachrichten voll und ganz aus, führte aber zu Problemen, als man auch Daten per E-Mail austauschen wollte, dassdiese 8 Bit benötigen. dassman nun in der ungünstigen Lage war einerseits 8-Bit-Daten übertragen zu wollen und andererseits viele Datenübertragungswege und auch vorhandene Mail-Systeme nur 7 Bit unterstützen, blieb nur der Weg, 8-Bit-Daten in 7 Bit zu kodieren, diese Daten zu übertragen und am anderen Ende wieder zu dekodieren. Das gebräuchlichste Verfahren hierzu ist uuencode, das auch heute noch in der UNIX-Welt weit verbreitet ist. Je nach Komfort des Mailprogramms muss die Konvertierung vor dem Übertragen von Hand erfolgen oder wird von diesem automatisch vorgenommen.

Ein weiteres Problem waren die Umlaute, für deren Übertragung auch 8 Bit benötigt werden. Wenn man nicht jeden Text mit Umlauten kodieren wollte, blieb nur der Ausweg, die Umschreibung des Umlautes (also ue usw.) zu verwenden.

  • Man erweitert alle Mailsysteme in der ganzen Welt, so dass sie 8-Bit verstehen, mit allen Problemen in der Übergangszeit.

  • Man findet einen sanften Migrationspfad hin zu 8-Bit-Systemen.

Die Realisierung des zweiten Ansatzes führte zu MIME (definiert im Internet-Standard Externer Link:  RFC 1341).

MIME oder: Lassen Sie sich doch bitte kein ü für ein =FC vormachen

Beim Entwurf von MIME ging man von mehreren Annahmen aus:

  • Es wird noch lange Datenübertragungswege und Mailsysteme geben, die nur 7 Bit unterstützen.

  • Einfacher Text sollte so übertragen werden, dass er auch auf nicht-MIME-fähigen Systemen vernünftig dargestellt werden kann.

  • Die Komplexität sollte in die Mail-Programme und nicht in das Übertragungssystem verlagert werden. D. h. man benötigt nur MIME-fähige Mail-Programme ( = MUA) keine MTAs.

MIME-Mails werden in der Regel als 7-Bit-Daten übertragen (es gibt zwar auch die Möglichkeit, Daten direkt als 8 Bit zu wählen, wegen der Probleme an einem möglichen Übergang ist dies aber nicht empfehlenswert) und alle 8-Bit-Daten (Anhänge und Umlaute) müssen vom sendenden Mail-Programm in 7 Bit kodiert und von dem auf Empfängerseite wieder in 8 Bit umgewandelt werden.

MIME-Mails sind folgendermaßen aufgebaut:

Neben den üblichen Headern (From:, To:, Date:, Subject:) gibt es zusätzliche folgende Header:

  • MIME-Version: legt die verwendete Version (z. Zt. immer 1.0) fest
  • Content-Transfer-Encoding: bezeichnet die Art der Kodierung
  • Content-Type: Legt den Typ einer Mail, also zum Beispiel einfacher Text fest.

Das folgende Beispiel zeigt den Header-Aufbau einer MIME-Mail:

From: Paul Mustermann <<paul.mustermann@rrze.fau.de>
To: "Helga Musterfrau" <<helga.musterfrau@rrze.fau.de>
Subject: Beispiel-Mail
Date: Thu, 20 Feb 1997 13:47:12 +0100
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=iso-8859-1

Möchte man 8-Bit-Zeichen übertragen, (beispielsweise ein ü) werden sie vom MUA durch ein = gefolgt vom ASCII-Kode dargestellt. Diese Art der Kodierung nennt man auch quoted-printable. Könnte man in den Text einer MIME-kodierten Mail sehen (bei Pegasus-Mail geht das, indem Sie sich alle Header anzeigen lassen), würde das folgendermaßen aussehen (aus dem ü wurde ein =FC):

Hallo!

Beispiel f=FCr Text mit Umlaut

Das Mail-Programm des Empfängers sollte diese Zeichen wieder in den richtigen Text verwandeln, ohne dass der Leser etwas davon merkt. Sehen Sie hingegen in einer Mail irgendwelche =XX-Zeichen, können Sie davon ausgehen, dass Ihr Mailprogramm kein MIME unterstützt. Die folgende Graphik, zeigt den Weg einer Mail von einem Absender mit MIME-fähigem Mail-Programm bis hin zum Empfänger mit bzw. ohne MIME-fähigem Mailprogramm.

Übertragung von binären Anhängen mit MIME

MIME ermöglicht die Versendung von binären Anhängen und Mails, die aus mehreren Teilen bestehen. Letzteres erlaubt Ihnen zum Beipiel in einer Mail ein Dokument mit Beschreibung zu versenden. Sie als Anwender geben wie gewohnt nur den Empfänger und das Subject ein, schreiben den Begleittext (Dies ist ein Beispiel einer E-Mail mit Anhang) und wählen dann - je nach verwendetem Mailprogramm geht das unterschiedlich elegant - die zu versendende Datei über ein Menü aus und schicken die Mail los. Der Empfänger wiederum muss nur auf den Anhang klicken und die entsprechende Anwendung (z.B. ein Textverarbeitungsprogramm) wird gestartet, um den Anhang geeignet darzustellen.

Realisiert wird dies von den beteiligten Mailprogrammen durch Verwendung des Content-Types: MULTIPART/MIXED und die Festlegung einer speziellen Zeichenfolge, die als Grenze (BOUNDARY) zwischen diesen Teilen dient (und natürlich in der Mail sonst nicht vorkommen darf). Innerhalb der einzelnen Teile der Mail kann man wieder angeben, ob es sich um einen Text oder eine Binär-Datei handelt. Binäre Daten werden nach einem speziellen Verfahren (Base64) für die Übertragung umgewandelt.

Das nächste Beispiel zeigt eine solche Mail, wie sie bei der Übertragung aussieht, aber vom Benutzer in dieser Form nicht gesehen wird. Sie besteht aus einem kurzen Text und einem binären Anhang:

Date: Fri, 21 Feb 1997 17:00:17 +0100 (MET)
From: Clemens Brogi <unrz13@rrze.fau.de>
To: brogi@rrze.fau.de
Subject: test
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-2139974673-931073429-856540817=:"
---2139974673-931073429-856540817=:
Content-Type: TEXT/PLAIN; charset=US-ASCII
Dies ist ein Beispiel einer Email mit Anhang.
---2139974673-931073429-856540817=:
Content-Type: IMAGE/JPEG; name="clemens.jpg"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SUN.3.91.970221170017.489i@tick>
Content-Description:
/9j/4AAQSkZJRgABAQAAAQABAAD//gBGQ1JFQVRPUjogWFYgVmVyc2lvbiAz

MIME hat natürlich noch viel mehr Möglichkeiten, die zu besprechen den Rahmen dieses Artikels sprengen würde. Der interessierte Leser findet sie in den einschlägigen RFCs (z.B. Externer Link:  RFC 1143).

X400

X400-Mail-Systeme sind von vornherein auf 8-Bit-Daten ausgelegt. Wenn man Daten von einem SMTP-Mail-System auf ein X400-System übertragen will, kommt es bei der Umwandlung vielfach zu Problemen, wenn die verwendeten Systeme beispielsweise den Standard nicht richtig oder unterschiedlich interpretieren.

Exoten: Oder: Wenn ihnen jemand eine BinHex-kodierte Datei schickt, will er sie nicht verapplen.

Andere Mail-Systeme verwenden vielfach eigene Kodierungsverfahren, die den Nachteil haben, dass Sie nicht zu anderen Mail-Programmen kompatibel sind. Apple-Rechner verwenden z.B. BinHex-Kodierung. Wenn man so eine Datei erhält, braucht man entweder ein Mailprogramm, das die Dekodierung beherrscht, oder ein externes Programm.

Zusammenfassung: Oder: Praxis ist, wenns klappt und keiner weiß warum.

Aus der Informationstheorie wissen wir, dass zur Kommunikation immer Sender, Empfänger und das Übertragungsmedium gehören. Letzteres kann beim Mail-Transport nahezu beliebig komplex sein. Deshalb empfiehlt es sich, davon auszugehen, dass es dumm ist und selber einige Randbedingungen einzuhalten, damit die Mail unbeschadet beim Empfänger ankommt.

Was soll man nun zusammenfassend raten?

  • Am glücklichsten werden Sie, wenn sie schon beim Versenden an den Empfänger denken. Also schicken Sie einem UNIX-Benutzer eine Datei MIME- oder uuencoded, aber nicht als BinHex-Datei.

  • Verwenden Sie zur Übertragung einen 7-Bit-Zeichensatz (Stichwort: dummes Medium). Bei vielen Mail-Programmen kann man das einstellen.

  • Verwenden Sie in Nachrichtentexten bitte keine Umlaute. Ich weiß, Sie verfügen über ein Mail-Programm, das dies mühelos beherrscht, aber denken Sie an den armen Benutzer am anderen Ende, der die Mail erst erhält, nachdem sie von 2 Gateways bearbeitet wurde und ihm von jemand anderes als forward weitergeschickt wurde. Was wäre ihnen lieber: ein ue oder ein =FC oder irgendein anderer Grümpftel?

  • Wenn Sie eine Datei übertragen wollen, schicken sie diese:

    • Wenn sie nichts über das System am anderen Ende wissen: MIME-kodiert.

    • Wenn am anderen Ende ein UNIX-System ist, MIME oder mit uuencode kodiert.

    • Wenn am anderen Ende ein MAC ist, BinHex-kodiert.

Welches Mailprogramm sollte man verwenden?

Verwenden sie immer ein MIME-fähiges Mailprogramm, wie zum Beispiel Mozilla-Mail (alle Systeme), Netscape-Mail (Windows, MAC und UNIX), Pegasus-Mail (Windows und DOS) oder pine (UNIX). Eine Übersicht der Konfigurationen für die jeweiligen Mailprogramme entnehmen Sie der Starthilfe ins Internet.

Wo finde ich weitere Tools?

Eine Sammlung geeigneter Programme zum Kodieren/Dekodieren findet man zum Beispiel auf der Internet-CD im Verzeichnis: software/dos/tools/arc

Letzte Änderung: 13. Maerz 2012, Historie

zum Seitenanfang

Startseite | Kontakt | Impressum

RRZE - Regionales RechenZentrum Erlangen, Martensstraße 1, D-91058 Erlangen | Tel.: +49 9131 8527031 | Fax: +49 9131 302941

Inhaltenavigation

FAU - Friedrich-Alexander-Universität
UnivIS - Informationssystem der Friedrich-Alexander-Universität Erlangen Nürnberg

Zielgruppennavigation

  1. Studierende
  2. Beschäftigte
  3. Einrichtungen
  4. IT-Beauftragte
  5. Presse & Öffentlichkeit