SMTP-Header

Eine Mail besteht für den Benutzer aus dem Body, optional in verschiedenen Formaten (Text/HTML/RTF) und optionalen Anlagen. für die meisten Benutzer unbemerkt enthält eine Mail aber noch einen Header, welcher die für den Anwender wichtigen Informationen wie Betreff, das Sendedatum und die Namen der Absender und Empfänger enthält. All diese Daten kann aber der Absender vorgeben und natürlich auch fälschen. Sobald eine Mail aber auf dem Weg über verschiedene Mailsysteme zum Ziel ist, wird der Header um weitere Daten erweitert. Wenn dies nicht unterdrückt ist, dann addiert jeder Mailserver zumindest sich als "Zwischenstation". Hier mal ein Header einer Werbemail von 1und1 an mein Postfach (einige Werte habe ich verfälscht).

Received: from mail.netatwork.de (192.168.100.12) by anonymrelay.netatwork.de
 (192.168.100.8) with Microsoft SMTP Server id 14.0.702.0; Mon, 6 Sep 2010
 15:24:04 +0200
X-NoSpamProxy-Tests: Realtime Blocklist filter: 0;Spam URI Realtime Blocklist filter: 0;
	CommTouch AntiSpam Services: 0;Word filter: 0;Validate and/or decrypt mail: 
	PassCommTouch Zero Hour Virus Outbreak Protection: PassFilebased virus scanner: Pass
X-NoSpamProxy-Rating:
X-NetatworkMailGateway-TrustedMail: no
X-NetatworkMailGateway-Scl: 0,00
X-NetatworkMailGateway-Sender: bounce9+baAAACUEIQ@inx1and1.de
X-NetatworkMailGateway-Rule: All other inbound mails
X-NetatworkMailGateway-Gateway: 212.227.126.171:62200
X-NoSpamProxy Encryption-EncryptionAlgorithm: None
X-NoSpamProxy Encryption-SignatureStatus: None
Received: from mbulk.1and1.com (mbulk.1and1.com [212.227.126.222])	by
 mx.kundenserver.de (node=mxeu5) with ESMTP (Nemesis)	id
 0Lx7xF-M1-01756f für frankx@cariusx.dex; Mon, 06 Sep 2010 15:24:03 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=1und1.de; s=global1;
	t=128779443; i=ps-automailer@1und1.de; bh=y1vkrMaYzsm7Yi4Ec
	s+KMAyvJ3qp/r1Poqps=; h=Date:From:Reply-To:To:Message-ID:Subject:
	 MIME-Version:Content-Type; b=iKVqlRociSyAuvUkevNGIvs09gg/y2EwpMZj4
	=
Received: from inxserv01 (inxserv01.inx1and1.de [217.72.200.214])	by
 mbulk.1and1.com (node=mbulk1) with ESMTP (Nemesis)	id
 0M-00YlTt; Mon, 06 Sep 2010 15:24:03 +0200
Date: Mon, 6 Sep 2010 15:34:22 +0200
From: 1&1 ProfiSeller Team <ps-automailer@1und1.de>
Reply-To: 1&1 ProfiSeller Team <ps-automailer@1und1.de>
To: <frankx@cariusx.dex>
Message-ID: <INX.11a25360d2b5.481.2dd2.2232.10c5cd87d.bounce9@inx1and1.de>
Subject: =?ISO-8859-15?Q?1&1_DSL_Sommer-Special_verl=E4ngert!?=
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_116045166_574783756.1283780062408"
X-Mailer: Inxmail EE 3.8.2.10
X-Provags-ID: V01nO9SA==
Return-Path: bounce9+baaaacsaueiq@inx1and1.de
X-MS-Exchange-Organization-AuthSource: NAWEX001.netatwork.de
X-MS-Exchange-Organization-AuthAs: Anonym
X-MS-Exchange-Organization-AuthMechanism: 0c

Irgendwo in der Mitte sehen sie die Absender und Empfängeradresse, den Betreff und das Datum und dann sehr viele "Received"-Zeile, die den Weg der Mail über die unterschiedlichen Stationen anzeigen. Diesen Header können Sie als Empfänger in Outlook in den Eigenschaften der Mail einfach anzeigen lassen oder auf dem Server über die Funktion Pipelinetracing sogar die Verarbeitung analysieren.

Steuerung durch Header

Die Header bieten sich natürlich ideal dazu an, Verwaltungs- und Verarbeitungsinformationen zu speichern. An dem Beispiel erkennen Sie z.B.: dass diese Mail durch den Net at Work NoSpamProxy auf Spam geprüft wurde und eine eventuelle Verschlüsselung durch "NoSpamProxy Encryption" verarbeitet werden würde. An den Zeilen unten erkennen Sie, dass die Mail von Exchange anonym angenommen wurde.

Wenn eine Mail durch mehrere Exchange Server geht, dann können Sie hier deutlich mehr Informationen sehen. Wenn Sie z.B. ein Journal aktiviert haben, dann erstellt der erste HubTransport eine Kopie der Mail und sendet diese an das Journalpostfach. Über einen Headereintrag bekommt dann alle anderen nachfolgenden Stationen die Information, dass zu diese Mail bereits ein Journal erstell wurde und keine weiteren Kopien mehr erforderlich sind. Das funktioniert natürlich nur, solange die Mail innerhalb der gesicherten Exchange Organisation bleiben. Ein Grund, warum zwischen Exchange Servern kein anderes Mailsystem als Relay stehen sollte und Routing Group Connectoren immer nur zwischen Exchange Servern direkt aufgebaut werden können.

Als Administrator können sie selbst auch auf Header verschiedene Aktionen anstoßen oder Header setzen. Die Transportregel erlauben entsprechende Veränderungen :


Exchange hinterleg in den Headern aber auch Informationen über die Spambewertung (SCL), so dass der erste HubTransport die Mail über den Intelligent Message Filter klassifizieren kann und der Store-Prozess die Mail ab einen bestimmten SCL in den "Junk-E-Mail"-Ordner verschieben kann.

Sicherung der Header - Header Firewall

Ohne besondere Schutzfunktionen wären aber die Steuerungen über den Header sehr leicht zu durchbrechen. Stelle Sie sich vor ein Spammer würde gleich den Exchange Header für "SCL=0" setzen. Darauf darf sich ein Hub-Transport nicht verlassen. Entsprechend gibt es Code in der Rolle, welcher Header addiert aber auch untersucht und sogar entfernen kann. Schließlich ist die Information im Header in keinster Weise gegen Veränderungen auf dem unsicheren Transportweg im Internet geschützt. Insofern sind die Informationen als nicht "vertrauenswürdig" anzusehen, wenn eine Mail von einem unbekannten System kommt. Innerhalb der Exchange Organisation ist es allerdings nicht so einfach zu fälschen, da Exchange jede Verbindung "authentifiziert" und per TLS verschlüsselt.

Zwei PowerShell-Befehle sind der Einstieg in die Funktion der Header Filter.

Der erste Befehl gibt die maximale Größe des Headers aus, welche der Exchange Server annimmt:

[PS] C:\>Get-ReceiveConnector | fl name,*header*

Name          : Default W2K8R2E2010
MaxHeaderSize : 64 KB (65,536 bytes)

Name          : Client W2K8R2E2010
MaxHeaderSize : 64 KB (65,536 bytes)

In dem Beispiel habe ich einen Windows 2008 R2 Server mit Exchange 2010 SP1 als Basis genommen. Der Header darf insgesamt also nicht größer als 64k werden. Das sollte aber in allen Fällen ausreichen. Sendet ein System wirklich einen noch größeren Header, dann ist das weit weg von "Normal", den selbst DKIM und viele Routinginfos, sollten ein Header selten über 2-3k anwachsen lassen.

Interessanter wird es, wenn Sie sich mal die Berechtigungen auf so einen Receive Connector anzeigen lassen.

[PS] C:>Get-ReceiveConnector | Get-ADPermission | ft -AutoSize User,deny,inher*,accessrights

Wer mit der Anzeige nicht zurecht kommt, kann auch mit ADSIEDIT sich einfach die Berechtigungen des Receive Connectors anzeigen lassen. Er ist aber bei Exchange 2010 etwas tiefer in der Struktur versteckt, da die Konfiguration "pro Server" erfolgt

Es gibt durchaus ACLs für "Accept Forest Headers" und "Accept Organization Headers". Selbst EXCH50 und XSHADOW sind eigene per Berechtigung steuerbare Einträge. Die Gruppe der "Exchange Server" haben hier sehr weitreichende Rechte, aber anscheinend ist selbst ein Exchange 2000/2003-Server nicht ausreichend vertrauenswürdig. Von diesen Systemen akzeptiert Exchange keine Forest/Organzation-Header.

Zu welcher Klasse ein Header zählt, ist direkt aus dem Namen erkennbar. Ein "X-MS-Exchange-Organization-"-Prefix kennzeichnet einen Organisationsheader. Sollte also so ein Header zu unrecht enthalten sein, wird ihn der Receive Connector einfach entfernen.

Das kann durchaus auch unschön Effekte haben. Wie schon bei AdminSDHolder kann es kontraproduktiv sein, wenn Sie im Rahmen einer Fehlersuche z.B.: die Exchange Computerkonten in die falschen Gruppen aufnehmen. Wer einen Exchange 2007/2010 Server in die Gruppe "ExchangeLegacyServers" aufnimmt, kann schwere Störungen hervorrufen. Da z.B. der erste HubTransport bei entsprechender Konfiguration eine Kopie einer Mail dem Journal zuführt, vermerkt dieser dies auch im Organization-Header. Wird der Header von einem anderen HubTransport nun entfernt, dann wird erneut ein Journal-Eintrag erstellt. Und selbst für die Journalmail wieder eine neue Journalmail erstellt. Und das ist nur eines der Probleme, wenn die Berechtigungsgruppen von Exchange falsch genutzt werden.

Weitere Links