Dies ist eine Gegenüberstellung von Headern aus verschiedenen Netzsystemen. Die Liste erhebt keinen Anspruch auf Vollständigkeit; bewusst weggelassen wurden Header, die nur in einem der Standards vorkommen.
Wenn zwei Header äquivalent sind, heißt das nicht automatisch, dass man sie auch konvertieren sollte. Manchmal ist es besser, gerade bei Informations-Headern, die in einem der Netze ein strenges Format haben, sie einfach 1:1 (mit entsprechender Kennzeichnung als Fremdnetz-Header) zu übernehmen, z.B. sollte RFCs Phone nicht in ZConnect PHONE, sondern in U-Phone konvertiert werden.
FTN: Es gibt drei Arten von "Headerinformationen": Der binäre Header im Nachrichtenpaket (dargestellt mit dem Namen aus FTS-0001 als kursiv), Kontrollabsätze (Kludges, beginnen mit einem Oktett mit dem Wert 1, unten dargestellt als ^a) sowie in Echomails Kontrollzeilen nach der Tearline.
RFC: Neben dem eigentlichen Header gibt es bei Mail noch den Envelope (Umschlag). Er enthält die Absenderadresse sowie die Empfänger (nur die, an die die Mail noch zugestellt werden soll). Bei ESMTP können außerdem noch weitere Parameter übertragen werden. Der Envelope steckt bei (E)SMTP in den Befehlen MAIL FROM und RCPT TO, bei UUCP in den Parametern zum Befehl rmail sowie in der/-n ersten Zeile(n) der Nachricht (beginnt mit "From "), wobei UUCP nicht alle möglichen Adressen transportieren kann (insbesondere Adressen mit Leerzeichen, die nach RFC 2821/2822 zulässig sind machen Probleme). Bei POP3/IMAP ist der Envelope verloren, manche Systeme sichern ihn in Headerzeilen wie Delivered-To und Return-Path.
Außer RFC (Mail) unterstützt kein Standard die Trennung von Envelope und eigentlichem Header. Da daher die Headerinformationen bei den anderen Standards zum Zustellen der Nachrichten verwendet werden, ist es am besten, diese Header mit dem Envelope bei RFC (Mail) gleichzusetzen.
Anm.: Das MausTausch-Format würde die Trennung zwar theoretisch auch unterstützen, aber weder MAUS noch QUARK haben das auch tatsächlich implementiert.
| RFC 2822/1036 | ZConnect 3.1 | Maus | FTN | Kommentar |
|---|---|---|---|---|
| Envelope: MAIL FROM Return-Path Envelope-From (kein Standard) |
ABS | V/R | fromUserName origNode origNet origZone ^aFMPT ^aINTL * Origin |
RFC: Es sollte nach Möglichkeit immer der echte Envelope ausgewertet werden! |
| Envelope: RCPT TO Delivered-To Envelope-To (kein Standard) X-Envelope-To (kein Standard) X-RCPT-TO (kein Standard) Apparently-To (kein Standard) Newsgroup |
EMP (mehrfach) KOP (mehrfach) |
A G K |
toUserName destNode destNet destZone ^aTOPT ^aINTL AREA |
RFC: Es sollte nach Möglichkeit immer der echte Envelope ausgewertet werden! |
| Distribution |
D |
|||
| From |
(ABS) |
(V/R) |
||
| Sender | S |
|||
| To |
(EMP/KOP) |
(A) |
Bei ZConnect sind KOP primäre Empfänger, deren Kopie der Nachricht einen anderen Weg genommen hat, keine sekundären Empfänger (CC-Empfänger). |
|
| CC |
(K) |
|||
| (BCC) | BCC kann durch getrennte Nachrichten simuliert werden. |
|||
| Reply-To Mail-Reply-To (kein Standard) |
ANTWORT-AN (mehrfach) |
(V/R) T |
^aREPLYTO ^aREPLYADDR |
|
| Mail-Followup-To (kein Standard) Mail-Copies-To (kein Standard) (Reply-To) Followup-To: |
DISKUSSION-IN (mehrfach) |
F (nur einfach!) |
||
| Envelope: ESMTP ORCPT Delivered-To |
VER |
|||
| (Recieved) Path |
ROT |
SEEN-BY |
||
| Recieved |
VIA |
^aPATH |
||
| Disclose-Recipients (MIXER) | STAT: NOKOP |
MIXER betrifft nur Gateways von/nach X.400. |
||
| X-Gateway |
Y |
Es lassen sich zwei Systeme unterscheiden: Bei RFC (Mail) bleiben die Header wie sie sind; es wärden zusätzliche Header (Resent-*) vorangestellt. Bei ZConnect werden dagegen die alten Adressierungsinformationen in anderen Headern transportiert, während die neuen Adressierungsinformationen in den normalen Headern transportiert werden.
| RFC 2822/1036 | ZConnect 3.1 | Maus |
FTN |
Kommentar |
|---|---|---|---|---|
| (Date) |
O-EDA |
|||
| (Recieved) | O-ROT |
|||
| (From) | OAB |
^aFWDFROM ^aFWDORIG |
||
| (To) | OEM |
^aFWDTO ^aFWDDEST ^aFWDAREA |
||
| (Message-ID) |
^aFWDMSGID |
|||
| (Envelope-Sender) | WAB |
|||
| Resent-From | (ABS) | |||
| Resent-Sender | - |
|||
| Resent-To | (EMP/KOP) |
Bei ZConnect sind KOP primäre Empfänger, deren Kopie der Nachricht einen anderen Weg genommen hat, keine sekundären Empfänger (CC-Empfänger). | ||
| Resent-CC | - |
|||
| Resent-BCC | BCC kann durch getrennte Nachrichten simuliert werden. | |||
| Resent-Date | (EDA) |
|||
| Resent-Message-ID | (MID) |
| RFC 2822/1036 | ZConnect 3.1 | Maus |
FTN |
Kommentar |
|---|---|---|---|---|
| Organisation (kein Standard) |
ORG |
O |
||
| POST |
||||
| Phone (kein Standard) Fax (kein Standard) Telefax (kein Standard) |
TELEFON | ZConnect hat ein strenges Format, das natürlich von einem nicht-standardiesierten RFC-Header nicht eingehalten wird. |
||
| User-Agent (kein Standard) Mailer (kein Standard) X-Mailer (kein Standard) X-Newsreader (kein Standard) |
MAILER |
RFC: User-Agent hat ein strenges Format, das von den anderen Headern nicht eingehalten wird. |
| RFC 2822/1036 | ZConnect 3.1 | Maus | FTN |
Kommentar | |
|---|---|---|---|---|---|
| Subject |
BET |
W |
subject |
||
| Comments | |||||
| Keywords | STICHWORT |
||||
| Summary (kein Standard) |
Zusammenfassung |
||||
| Message-ID |
MID |
I/# |
^aMSGID |
MausTausch: An einer MAUS werden sowohl boxspezfische IDs in #/- als auch globale IDs in I/R verwendet, an einer Quark nur globale IDs in #/-. FTN: FTN-IDs sind nach Gatebau 1:1 in Domain-IDs (RFC/ZConnect/MausTausch) konvertierbar. |
|
| # |
|||||
| References In-Reply-To |
BEZ |
R/- | ^aREPLYTO |
||
| - |
replyTo |
||||
| Supersedes (News/MIXER) Obsoletes (MIXER, veraltet) |
ERSETZT |
MIXER betrifft nur Gateways von/nach X.400. | |||
| Date |
EDA |
E |
DateTime ^aTZUTC |
||
| (Expires) Expire-Date (MIXER) |
LDA |
MIXER betrifft nur Gateways von/nach X.400. | |||
| SPERRFRIST |
| RFC 2822/1036 (Mail) | ZConnect 3.1 | Maus |
FTN |
Kommentar |
|---|---|---|---|---|
| Control |
CONTROL |
|||
| - |
STAT |
* |
AttributeWord |
Typ der Nachricht/Statusinformationen |
| (Content-Type: multipart/report) | B |
Bearbeitungsstatus |
||
| Importance Priority (MIXER) X-Priority (kein Standard) |
PRIO |
MIXER betrifft nur Gateways von/nach X.400. | ||
| Envelope: ESMTP NOTIFY Return-Receipt-To (kein Standard) Generate-Delivery-Report (MIXER) |
TRACE EB |
Empfangsbestätigung MIXER betrifft nur Gateways von/nach X.400. |
||
| Disposition-Notification-To |
Lesebestätigung |
|||
| - |
ERR |
| RFC 2822/1036 | ZConnect 3.1 | Maus |
FTN |
Kommentar |
|---|---|---|---|---|
| MIME-Version |
MIME U-MIME-Version |
ZConnect: MIME ist so gut wie nicht implementiert; es empfiehlt sich, sowohl die ZConnect als auch die RFC-Header zu schreiben/auszuwerten. |
||
| Content-Type | MIME-Type U-Content-Type |
|||
| Content-Type charset |
CHARSET |
^aCHRS ^aCHARSET |
||
| Content-Transfer-Encoding |
MIME-Encoding U-Content-Transfer-Encoding |
ZConnect: Wenn TYP: MIME nicht gesetzt ist, empfiehlt es sich, diesen Header zu ignorieren und eine 1:1-Kodierung anzunehmen. |
||
| Content-Disposition | - |
|||
| Content-Disposition modification-date | DDA |
|||
| Content-Disposition filename | FILE |
|||
| Content-Language Language (MIXER, veraltet) |
LANGUAGE |
MIXER betrifft nur Gateways von/nach X.400. | ||
| Content-Description |
ZUSAMMENFASSUNG |
|||
| Content-ID |
MIME-ID U-Content-ID |
|||
| (Content-Type) |
TYP |
ZConnect: TYP: MIME ist so gut wie nicht implementiert; es sollte keine Content-Transfer-Encoding verwendet werden und TYP: BINARY oder kein TYP-Header (= Text) verwendet werden, das gilt auch für mehrteilige Nachrichten. |
||
| - |
LEN |
|||
| - |
KOM |
| RFC 2822 (Mail) | ZConnect 3.1 | Maus |
FTN |
Kommentar |
|---|---|---|---|---|
| (Content-Type: multipart/encrypted) | CRYPT |
|||
| (Content-Type: multipart/encrypted) | CRYPT-CONTENT-CHARSET |
|||
| (Content-Type: multipart/encrypted) | CRYPT-CONTENT-KOM |
|||
| (Content-Type: multipart/encrypted) | CRYPT-CONTENT-TYP |
|||
| PGP |
||||
| PGP-ID |
||||
| PGP-KEY-AVAIL |
||||
| PGP-KEY-COMPROMISE |
||||
| PGP-KEY-OWN |
||||
| PGP-PUBLIC-KEY PUBLIC-KEY |
||||
| (Content-Type: multipart/signed) | PGP-SIG |
|||
| (Content-Type: multipart/signed) |
SIGNED |