Nachrichtenformate
RFC822
Nachrichten bestehen hier aus einem primitiven Umschlag ( in RFC821
beschrieben) , einigen Headerfeldern, einer Leerzeile und dem
Nachrichtentext. Jedes Headerfeld besteht aus einer Zeile mit ASCII-Text,
in der der Feldname , ein Doppelpunkt und meist ein Wert stehen.
Dieser Standard unterscheidet also nicht klar zwischen Umschlag und
Nachricht.
Die wichtigsten Headerfelder sind:
| Header |
Bedeutung |
| To: |
DNS-Adresse des primären Empfängers |
| Cc: |
DNS-Adressen der sekundären Empfänger |
| Bcc: |
DNS-Adressen der Empfänger von blinden Kopien, die
nicht im CC-Feld aufgeführt werden. |
| From: |
DNS-Adresse des Verfassers |
| Sender: |
DNS-Adresse des Absenders |
| Received: |
Zeile die jeder MTA auf der Route einträgt |
| Return-Path: |
wird vom letzten MTA in der Reihe eingefügt und soll
angeben auf welchem Weg die Mail zurückkehren soll. Meistens steht
hier nur die Adresse des Absenders. |
Zusätzlich könne noch die folgenden Felder nach RFC822
enthalten sein:
| Header |
Bedeutung |
| Date: |
Datum Uhrzeit der Absendung |
| Reply-To: |
Adresse an die die Antwort gesendet werden soll |
| Message-ID |
Eindeutige Nummer der Nachricht |
| In-Reply-To: |
Kennung der Nachricht , der diese Antwort gilt |
| References: |
Andere relevante Nachrichtenkennungen |
| Keywords: |
Vom Benutzer ausgewählte Schlüsselworte |
| Subject: |
Betreff der Zeile. |
RFC822 definiert explizit, dass Benutzer neue Header hinzufügen
können, vorausgesetzt diese beginnen mit der Zeichnkette "X-".
Nach den Headerfeldern folgt eine Leerzeile und dann der eigentliche
Nachrichtentext.
MIME
Früher, als Mail im Internet ihren Anfang nahm, bestanden Mails aus
Textnachrichten in Englisch, und dafür war das vorgestellte Protokoll
völlig ausreichend. Die Benutzer allerdings wollte mehr.
Sie wollten:
- Nachrichten in Sprachen mit Akzenten wie Französisch und Deutsch
- Nachrichten in nichtlateinischen Sprache wie Hebräisch oder
Russisch
- Nachrichten in Sprachen ohne Alphabet wie Chinesisch oder Japanisch
- Nachrichten die Bilder, Audio und Video enthielten
Um dieses Problem zu lösen wurde in RFC1341 eine Lösung vorgeschlagen
und in RFC1521 überarbeitet. Die Lösung heißt Multipurpose Internet
Mail Extensions oder kurz MIME.
MIME sollte weiterhin das Format von RFC822 benutzen, aber erweiterte
Kodierregeln für ASCII-fremde Nachrichten einführen.
Dafür definiert MIME fünf neue Nachrichtenheader.
| Header |
Beschreibung |
| MIME-Version: |
Dieser Header informiert den MUA das es sich um eine
MIME-Nachricht handelt und gibt an, welche Version benutzt wird. Bei
Nachrichten ohne MIME-Header wird davon ausgegangen, das es sich um
ASCII-Text handelt. |
| Content-Description: |
Dieser Header weist auf den Inhalt der Nachricht hin. Er ist
erforderlich, damit der Benutzer beurteilen kann, ob es sich lohnt
die Mail zu öffnen. Steht hier z.B. "Foto von Willis
Dackel", dann kann sie getrost ignoriert werden. |
| Content-Id: |
Analog zu Message-Id |
| Content-Transfer-Encoding: |
Dies bezeichnet wie die Nachreicht zur Übertragung aufbereitet
wurde. Dafür stehen einige Schemata plus ein Escape für neue
Schemata zur Verfügung.
- ASCII-Text: Dieses Schema benutzt 7-Bit-ASCII-Zeichen
und kann direkt vom Mailtransferprotokoll übertragen werden,
sofern keine Zeile mehr al 1000 Zeichen hat.
- 8-bit-ASCII: Benutzt 255 Zeichen. Dieses Schema
verletzt das ursprüngliche eMail-Protokoll, wird aber besonders
unter MS-Windows benutzt, das einige Erweiterungen definiert.
Durch Angabe der Kodierung wird das zwar nicht besser, aber der
MUA erhält einen Hinweis wie die Nachricht darzustellen ist.
- base64: Bei diesem Schema werden Gruppen von je 24 Bit
in vier 6 Bit-Einheiten zerlegt, von denen jede als zulässiges
ASCII-Zeichen übertragen wird. Die Kodierung lautet A = 0, B =
1,... gefolgt von den 26 Kleinbuchstaben, den 10 Ziffern sowie +
und / für 63 und 64. Die Folgen == und = werden benutzt um zu
bezeichnen, dass die letzte Gruppe nur 8 bzw. 16 Bit enthält.
Zeilenvorschub und Zeilenrücklauf werden ignoriert.
- Quoted printable: wird bei Nachrichten die fast
gänzlich aus ASCII-Zeichen bestehen angwandt. Es handelt sich
eigentlich um 7-Bit-ASCII, bei dem alle Zeichen größer 127 als
Gleichheitszeichen gefolgt vom hexadezimalen Wert des Zeichens
kodiert werden.
|
| Content-Type: |
spezifiziert den Nachrichteninhalt nach RFC1521. |
Nach RFC1521 sind für den Inhalt folgende Typen vorgesehen:
| Typ |
Subtyp |
Beschreibung |
| Text |
Plain |
gewöhnliche Nachrichten, ohne Formatierung, die so angezeigt
werden können wie Sie eingegangen sind. |
| Richtext |
Text mit einfachen Formatierungen wie Fett, Kursiv, etc |
| Image |
Gif |
Gif-Bilder |
| JPEG |
JPG-Bilder |
| Audio |
Basic |
Ton |
| Video |
Mpeg |
Video |
| Application |
Octet-stream |
Format verlangt externe Verarbeitung |
| Postscript |
ein Postscript-Dokumnt |
| Message |
RFC822 |
Message enthält eine weitere Nachricht im RFC822-Format |
| Partial |
Teil einer Nachricht. |
| External-body |
Referenz auf externe Quellen wie URL im WWW |
| Multipart |
Mixed Alternative |
mehrteilige Nachricht. Bei mixed unabhängig Teile, bei
alternative gleiche Nachricht in mehreren Formaten. |
| Parallel |
mehrteilige Nachricht, alle Teile sind gleichzeitig abzuspielen
(Bild und Ton) |
| Digest |
Sammlung von mehreren Nachrichten. |
|