ZConnect Header FAQ

In dieser FAQ wird erklärt, wie ZConnect-Benutzer aus einem Header die Daten herauslesen können, die notwendig sind, um sich auf eine UCE (unsolicited commercial email) bzw. eine UBE (unsolicited bulk email) hin an der richtigen Stelle beschweren zu können. Außerdem geht sie allgemein auf den Aufbau eines Mailheaders bei ZConnect ein.

Hinweise für rfc-gewohnte Menschen erscheinen in dieser Schreibweise.

Inhalt

1. ZConnect für rfc'ler

Wer seine Mails direkt im rfc-Format bekommt, hat es bei der Header-Analyse relativ einfach, und wenn er nicht durchblickt, kann er die Experten in de.admin.net-abuse.mail (bzw. in ZConnect-Schreibweise /DE/ADMIN/NET-ABUSE/MAIL) befragen. Wer jedoch seine Mails über eine ZConnect-Mailbox bezieht, die mehr oder weniger direkt an ein rfc-ZC-Gate angebunden ist, hat unter Umständen mit einer Reihe von Problemen zu kämpfen, weil die Header anders heißen oder eventuell sogar einige fehlen.

Zunächst ein paar Begriffe, die zwischen der rfc- und der ZConnect-Welt differieren (und über die es deswegen regelmäßig Streit gibt):

ZConnect	rfc
PM (persönliche Mail)	Mail
AM (allgemeine Mail)	News, Artikel, Posting
Brett	Newsgroup
Pointprogramm	Mail- und Newsreader

Für eMail relevante Header mit gleicher Bedeutung (Erläuterung in 2.):

ZConnect	rfc
ABS:	MAIL FROM:
ANTWORT-AN:	Reply-To:
BET:	Subject:
BEZ:	References: oder In-Reply-To:
DISKUSSION-IN:	Followup-To:
EMP:	RCPT TO: und/oder To: (bei News auch Newsgroups:)
KOP:	CC:
MID:	Message-Id:
EDA:	Date:
MAILER:	Mailer:
OAB:	From: (mit anderem MAIL FROM:)
OEM:	To: (mit anderem RCPT TO:)
WAB:	Sender:
X-… (X-Header)	X-…
U-… (UUCP-Header)	(Header, die nicht in ZConnect „übersetzt“ werden können)

Der SMTP-Envelope, also MAIL FROM: und RCPT TO:, ist ein Konstrukt, das ZConnect nicht kennt, da eine Mail anders transportiert wird. Nicht das Empfängersystem, sondern das Absendersystem ist dafür verantwortlich, dass eine Nachricht richtig geroutet wird. Da die Nachrichten zwischen den Systemen in gepackten Puffern übertragen werden, die jeweils mehrere öffentliche und private Nachrichten enthalten können, ist die Identifikation einer einzelnen Mail während der Übertragung nicht möglich. Bei der Konvertierung von Mails werden diese Angaben aber sehr wohl berücksichtigt.

2. Wie ist ein ZConnect-Header aufgebaut?

Bevor wir an die Header-Analyse gehen, müssen wir erst einmal die wichtigsten ZConnect-Header kennen. Wer schon Bescheid weiß, kann ja gleich zu Kapitel 3 blättern :-)

a) Pflichtheader

Ein ZConnect-Header hat zunächst sieben Pflichteinträge, ohne die eine Nachricht zwischen ZConnect-Systemen gar nicht transportiert und von Gateways nicht angenommen werden soll. Die Reihenfolge aller Header ist mit wenigen Ausnahmen vollkommen egal.

 ABS: absender@hier.bin.ich (Vorname Nachname)

Der Absender in rfc-Schreibweise; der Realname ist ein Kann, kein Muss. Allerdings gibt es Mailboxprogramme, die bei eingeschalteter „strenger Headerprüfung“ es den eigenen Benutzern nicht erlauben, ohne Realname zu schreiben.

Dieser Header darf nur einmal in jeder Mail vorkommen.

 EMP: empfaenger@da.bist.du

Der Empfänger in rfc-Schreibweise. Hier sollte kein Realname stehen, da das manche Mailboxprogramme übelnehmen. Dieser Header kann mehrfach vorkommen, und er kann öffentliche wie private Empfänger enthalten.

Auch ein Newsgroups:-Header wird in einen EMP gewandelt, bei mehreren Newsgroups-Angaben wird ein EMP pro NG erzeugt.

 MID: zufaelligezeichenkombination@system.do.main

Auch hier gilt rfc-Schreibweise, Leer- und Sonderzeichen sind nicht erlaubt. Dieser Header darf natürlich nur einmal vorkommen. Die MID ist sozusagen der Personalausweis einer jeden öffentlichen oder privaten Nachricht.

Im Gegensatz zu rfc822 schreibt ZConnect auch für Mail eine eindeutige Message-Id vor. Ein Gateway muss daher für Mails aus rfc, die keine Message-Id mitbringen, selbst eine erzeugen.

 BET: Das ist ein Test

Betreff der Nachricht; der Header kann zwar leer, muss aber an sich vorhanden sein (wobei einige ZConnect-Programme mit leeren Betreffs auch so ihre Probleme haben). Er darf nur einmal vorkommen.

 EDA: 19981221101400W+1

Erstellungsdatum im Format jjjjmmtthhmmss und direkt daran S für Sommerzeit bzw. W für Winterzeit. Die angegebene Zeit muss immer GMT sein! Direkt dahinter kommt die Differenz der Lokalzeit zur GMT in Stunden.

Dieser Header darf nur einmal vorkommen.

 ROT: system3.do.main!system2.do.main!system1.do.main

Der Routpfad gibt nur den Laufweg der Mail wieder, nicht aber Datum und Uhrzeit oder benutztes Programm (im Gegensatz zu den Received-Zeilen, die von rfc-Systemen erzeugt werden). Eine Ergänzung sind hier jedoch die optionalen VIA:-Header (s.u.).

Jedes System trägt sich in den Routpfad vor dem vorhergehenden ein, sodass das letzte System, durch das eine Nachricht gelaufen ist, immer ganz vorne steht. Wenn eine Nachricht vom Point abgeschickt wird, muss der Header gesetzt, darf aber nicht ausgefüllt sein, und natürlich kommt er nur einmal vor.

ROT: ist identisch aufgebaut wie Path: bei News, nur dass dieser Header in ZConnect auch für Mail verwendet wird.

 LEN: 1248

Die Länge des Nachrichtenbodys in Bytes. Im Gegensatz zu rfc-Nachrichten wird bei ZConnect das Nachrichtenende nicht durch einen Punkt am Zeilenanfang erkannt, sondern bereits im Header muss die korrekte Länge der Nachricht angegeben sein. Auch dieser Header darf in jeder Mail nur einmal gesetzt und muss bereits vom Point (oder vom Mailboxprogramm) ausgefüllt worden sein.

b) relevante optionale Header

 WAB: user@system.do.main (Vorname Nachname)

Diese Nachricht wurde von demjenigen geschrieben, der unter ABS: genannt ist, und von demjenigen, der unter WAB: genannt wird, weitergeleitet. WAB: darf nur einmal vorkommen. (Crosspoint: Nachricht-Weiterleiten-Original; siehe auch OEM:).

Diese Konstruktion ist grob vergleichbar mit einer Kombination von Sender: und From:, nur dass es zu Sender: in ZConnect kein echtes Äquivalent gibt.

 OAB: user@system.do.main (Vorname Nachname)

Das ist eine andere Konstruktion: Derjenige, der unter OAB: genannt ist, hat die Nachricht verfasst, und derjenige, der unter ABS: genannt ist, hat sie weitergeleitet. (Crosspoint: Nachricht-Weiterleiten-Kopie).

Diese Konstruktion entspricht grob einem MAIL FROM: mit dem Weiterleiter und einem From: des Original-Absenders. Ich bin mir nicht sicher, vermute aber, dass diese Konstruktion in rfc nicht vorgesehen ist.

 KOP: user@system.do.main

An diesen Benutzer ist diese Nachricht ebenfalls gegangen. Ein EMP wird in ein KOP gewandelt (oder soll gewandelt werden), wenn die Nachricht für den Kopienempfänger abgesplittet wurde und einen anderen Routweg genommen hat. Wie EMP: kann auch KOP: sowohl Mail- als auch Brettempfänger beinhalten.

Die Kombinationsmöglichkeit Newsgroups: und To: sowie ein Cc: auf beides ist in rfc nicht vorgesehen. Kombinierte Crosspostings/-mailings werden daher vor der Konvertierung nach rfc im oder vorm Gate gesplittet und völlig getrennt weiter verarbeitet.

OEM: user@system.do.main

Der Originalempfänger einer Nachricht; dieser Header entsteht, wenn eine Nachricht nicht im Original, sondern als Kopie weitergeleitet wird. (XP: Nachricht-Weiterleiten-Kopie).

VIA: 19981221101900@system.do.main

VIA gibt an, wann eine PM durch ein ZConnect-System gelaufen ist. Dadurch lassen sich immerhin die Quellen von Verzögerungen feststellen. Diese Zeile wird m.W. zumindest optional von jedem ZConnect-Boxprogramm (nicht jedoch von Points) erzeugt; ein System schreibt seinen VIA:-Header immer unter den letzten (kann also mehrfach vorkommen), hier ist die Reihenfolge also nicht egal.

 MAILER: CrossPoint V3.11 R12345

Dieses Programm hat die Mail erstellt und ist damit für die grundsätzlichen Header verantwortlich. Im allgemeinen ist auch das selbe Programm dafür zuständig, die Nachricht in der Mailbox einzuliefern. Dieser Header darf nur einmal angegeben werden.

 GATE: ZC/rfc-Gate system.do.main Programmname Version

Diese Zeile nennt die Art des Gateways (ZConnect nach rfc, ZConnect nach Fido, Fido nach rfc und jeweils umgekehrt), das konvertierende System und das benutzte Programm. Wenn sich ein weiteres Gate einträgt, benutzt es die gleiche Zeile und schreibt seinen Eintrag hinter den vorherigen, es wird also keine neue GATE:-Zeile erzeugt; somit darf dieser Header nur einmal vorhanden sein.

Bei auftretenden Fehlern im Header muss nicht unbedingt der Benutzer des Pointprogramms schuld sein. Achtet also drauf, ob ein Fehler auch erst im Gate entstanden sein kann.

 TYP: BIN

Der Inhalt des Nachrichtenbodys ist eine 8bit-Binärnachricht. Das ist eine Besonderheit von ZConnect, die die rfc-Welt so nicht kennt. Binärnachrichten dieser Art werden von den Gateways bei der Konvertierung nach rfc nach 7bit codiert (base64 oder uuencode). Natürlich darf dieser Header nur einmal vorhanden sein.

 BEZ: <bezugs-id@do.main>

Die Bezugs-ID zeigt an, auf welche Nachricht, ausgewiesen durch deren Message-ID, sich diese Mail bezieht; dieser Bezug kann aus einem Brett oder einer PM stammen. Bezugs-IDs müssen sich an eine feste Reihenfolge halten: Die neueste kommt zuerst. Für jede BEZ: wird also ein neuer Headereintrag erzeugt.

Im Gegensatz zu rfc gilt es in ZConnect nicht unbedingt als notwendig, immer den kompletten Bezug in jeder Mail bzw. jedem Follow-Up mitzuschleppen, denn wenn der Empfänger eine funktionierende Bezugsverkettung hat, kann er den Thread problemlos zurück verfolgen. Trotzdem machen es die meisten Pointprogramme, aber eben nicht alle.

c) Header aus rfc, die nicht konvertiert werden können

Diese Header werden mit einem vorangehenden "U-" gekennzeichnet und ohne Veränderungen direkt übernommen, können aber von einem ZConnect-System nicht ausgewertet werden. Leider gibt es Gateway-Programme, die (aus Faulheit des Autors?) diese Header nicht in U-Header wandeln, sondern einfach wegwerfen. Bei einer Rückkonvertierung kann das, hm, „lustige“ Effekte haben.

Die wichtigsten:

 U-Received: from system.do.main [123.123.123.123] via SMTP
              by mail.server.do.main, id smtpda07046; Sun Dec 20 04:17:47 1998

Die originalen Received-Zeilen aus dem rfc-Header sind die wichtigsten bei der Header-Analyse. Sie geben Auskunft darüber, über welche Systeme die Mail wann gelaufen ist, und zwar meist unter Angabe der IP-Adresse, der eindeutigen Identifikationsnummer eines Computers im Internet.

 U-To: user@system.do.main

Der To:-Header der Originalmail ist dann wichtig, wenn sie mehrere Empfänger enthielt. Nach EMP wird nämlich nur der Empfänger aus dem SMTP-Envelope (RCPT TO:) gewandelt.

 U-Date:

Das Original-Datum. Manchmal haben Gate-Programme das Problem, dass sie nicht alle Datumsformate – die sind in rfc nicht so fest wie in ZConnect – parsen können. In diesem Fall wird der Header EDA: aus dem aktuellen Systemdatum erzeugt, das Originaldatum aber im U-Date angegeben. Keine perfekte Lösung, aber eine, mit der man leben kann.

3. Wie finde ich die Beschwerdeadresse für eine UCE heraus?

Wer das Glück hat, hinter einem Gate zu sitzen, das die Received:-Zeilen in U-Received: wandelt, hat es jetzt relativ einfach, denn in diesen Zeilen sind im allgemeinen alle notwendigen Daten enthalten. Mit diesen Zeilen ist eine Nachfrage in de.admin.net-abuse.mail (oder in ZConnect-Schreibweise /DE/ADMIN/NET-ABUSE/MAIL) problemlos möglich, deshalb gehe ich darauf auch nicht näher ein.

Sieht eine UCE nach der Konvertierung aber so aus:

ABS: spammer@agis.net
EMP: user@system.do.main
BET: Mail Your Message To Millions
MID: 123456789@relay.spam-friendly.net
EDA: 19981220100000W+5
ROT: system.do.main!mailer.do.main!agis.net
GATE: rfc/ZC-Gate mailer.do.main Mistprogramm V0.1b
LEN: 5000

… dann sollte man in Erwägung ziehen, postmaster@mailer.do.main bzw. sysop@mailer.do.main mal daraufhin zu befragen, ob die Gatesoftware nicht „redseliger“ konfiguriert oder eine andere benutzt werden könnte.

Falls ein Internet-Zugang vorhanden ist, besteht die Möglichkeit, mit whois mal die letzte Domain im ROT sowie das System, das die Message-ID gesetzt hat, zu überprüfen. Falls sich dabei sinnvolle Adressen ergeben, könnte sich eine Beschwerde dorthin durchaus lohnen.