Linux-Magazin Clean Linux (Vorschau)

Sysadmin
www.linux-magazin.de Mailheader 09/2013
64
Headerdaten der E-Mail sehen jetzt so
aus, als kämen sie von einem einzigen
Rechner namens »smtp.example.com«,
ganz gleich von welchem Clientrechner
im LAN ein Benutzer die E-Mails wirklich
abgeschickt hat. Die Headerdaten
werden, ausgenommen die unterschiedlichen
E-Mail-Adressen und Timestamps,
immer gleich aussehen.
Sensible Daten im Betreff
Apropos E-Mail-Adressen: Viele Sysadmins
lassen sich Statusmeldungen per
Mail zuschicken. Zum Beispiel könnte
die Absenderadresse »root@Meine_Domain.local«
lauten, was aber natürlich
wieder Rückschlüsse auf Interna zulässt.
Address Rewriting [4] beseitigt solche
Informationen.
Vorsicht ist ohnehin geboten: Viele Statusmeldungen
enthalten den FQDN des
betreffenden Rechners aber auch im
Betreff. Erwischt Header_checks einen
solchen Subject-Header, schmeißt es ihn
natürlich auch raus und die Mail erreicht
den Empfänger, also den Sysadmin, ohne
Betreffzeile – ein großer Nachteil gerade
bei Mails mit Logs, die sich Admins gerne
per Sieve in Ordner einsortieren lassen,
01 # Nochmal zur Sicherheit Domain entfernen
02 /^.*\.Meine_Domain\.local.*$/i IGNORE
03 # Amavis braucht auch keiner zu sehen
04 /^.*amavis.*$/i IGNORE
05 # Localhost‐Einträge löschen
06 /^Received: from localhost.*$/i IGNORE
07 # Der MUA sollte auch nicht erscheinen
08 /^User‐Agent.*$/i IGNORE
09 # KMail ist eindeutig zu geschwätzig
10 /^X‐KMail.*$/i IGNORE
11 # weitere Regeln für individuelle Mailclients
12 [...]
Listing 4: »/etc/postfix/header_
checks«
Listing 5: Mit Header_checks bereinigte Mail
01 Received: from smtp.example.com
02 (Name_meines_Routers.Mein_ISP.com [1.2.3.4])
03 by smtp.Mein_ISP.com (xxxxx xxxx) (RZmta
31.27 DYNA|AUTH)
04 with (DHE‐RSA‐AES256‐SHA encrypted) ESMTPA id
906d2cp5H92jgY
05 for ;
06 Mon, 17 Jun 2013 11:10:34 +0200 (CEST)
07 To: Adresse@Externe_Domain.com
08 Subject: test
09 From: "Dr. Harry Knitter"
10 Date: Mon, 17 Jun 2013 11:10:31 +0200
in denen schnell mal hundert Mails liegen.
Hier hilft folgende Regel als erster
Eintrag in der Datei »/etc/postfix/header_checks«
weiter:
/^Subject:(.*)@(.*)\.?Meine_Domain.localU
(.*)$/i REPLACE Subject:$(1)$(2).
Sie ersetzt den Namen der internen Domain
»Meine_Domain.local« einschließlich
der Subdomains, also der FQDNs
der sendenden Rechner, durch einen
Nullstring. Wie der Sysadmin Postfix
dazu überredet, ihm den Inhalt solcher
Statusmeldungen auch noch automatisch
verschlüsselt zu übertragen, beschreibt
der Artikel im Linux-Magazin [5].
Finetuning
Anpassungen für den individuellen Bedarf
sind im beschriebenen Szenario unvermeidlich.
Manche E-Mail-Programme
tragen sich nämlich nicht im Header
»User‐Agent«, sondern mit »X‐Mailer«
ein. Die beschriebenen Säuberungsaktionen
gestalten auch das Debuggen deutlich
schwieriger: Wer selbst Analysen
von Mailheadern vornehmen will, muss
damit rechnen, dass nicht unbedingt alle
Transportinformationen eingehender
Mails erkennbar sind: Die beschriebenen
Maßnahmen wendet Postfix nämlich
auch bei eingehenden Mails an.
Schon Fetchmail, das vielleicht die Daten
vom ISP abholt, liefert die Mails über
den lokalen MTA aus – und weg sind
die Header. Allerdings geschieht dies
nur ein Mal, wenn Postfix die Mail von
Fetchmail erhält. Die später folgenden
Zugriffe des MTA, zum Beispiel beim
Filtern durch Amavis bis zur Ablage in
IMAP, haben keinen Einfluss mehr auf
den Inhalt der dabei erzeugten Header,
wenn in der Konfigurationsdatei »mas-
11 MIME‐Version: 1.0
12 Content‐Type: Text/Plain;
13 charset="iso‐8859‐15"
14 Content‐Transfer‐Encoding: 7bit
15 Message‐Id:
16 X‐Seen: false
17 X‐ENVELOPE‐TO:
18 X‐Length: 3387
19 X‐UID: 21011
20 Status: R
21 X‐Status: N
ter.cf« als Option für die Rückgabe der
Mail durch den Contentfilter an den MTA
»‐o receive_override_options=no_header_body_checks«
eingetragen ist.
Außerdem machen manche Clients wundersame
Dinge: Admins, die mit Kmail
testen, werden sich fragen, warum die
mit Kmail empfangenen E-Mails dennoch
wieder die unerwünschten »X‐KMail«-
Header aufweisen. Direkt auf dem IMAP
sind diese Header in der E-Mail nicht vorhanden.
Sie entstehen, wenn Kmail die
Mails via IMAP abholt. E-Mail-Adressen,
die andere MUAs verwenden, sehen davon
also nichts. Verwendet der Sender
einen anderen MUA als Kmail, passiert
dies ebenfalls nicht.
Fazit
Das Ausplaudern unnötiger und sicherheitskritischer
Daten in den Mailheadern
ist mit recht einfachen Mitteln zu unterbinden.
Die beschriebenen Maßnahmen
sind – sieht man von den regulären Ausdrücken
ab – ohne Programmieraufwand
und ohne Beeinträchtigung der E-Mail-
Kommunikation möglich. Zwar bezieht
sich das Beispiel auf eine relativ simple
LAN-Topologie, die beschriebenen Mechanismen
eignen sich aber genauso für
größere Installationen. (mfe) n
Infos
[1] Postfix-Dokumentation: [ http:// www.​
postfix. org/ documentation. html]
[2] Postfix Header_checks: [http:// www.​
postfix. org/ header_checks. 5. html]
[3] Jeffrey E. F. Friedl, „Reguläre Ausdrücke“:
O’Reilly, Oktober 2007
[4] Postfix Address Rewriting:
[http:// www. postfix. org/ ADDRESS_
REWRITING_README. html]
[5] Harry Knitter, „Schlüsseldienst“: Linux-
Magazin 07/​13, S. 68;
[http:// www. linux‐magazin. de/ Ausgaben/​
2013/ 07/ Schluesseldienst]
Der Autor
Dr. Harry Knitter [http:// www. knitter‐edv‐be ratung.
de] berät und betreut kleine und mittlere
Unternehmen in den Bereichen Netzwerk und
IT-Sicherheit und setzt dabei auf Linux. Er ist
in Hof als EDV-Dozent an der Fachhochschule
für Öffentliche Verwaltung und Rechtspflege in
Bayern tätig.