Smarthost

Mails werden im Internet per SMTP versendet. Der absendende Server muss dazu die "nächte Station" finden. Dazu gibt es zwei Optionen:

  • MX-Record
    Über die Domäne der Zieladresse wird im DNS nach den "Mailservern" gesucht und die Mail direkt zugestellt.
  • Smarthost
    Oft kann oder soll ein System aber nicht direkt Mails senden sondern ein vorgelagertes Relay nutzen.

Diese Seite beleuchtet das Thema "Smarthost" etwas genauer, denn es gibt einige Gründe, warum der direkte Versand per MX-Record nicht funktioniert oder nicht gewünscht ist, z.B.

  • Spamschutz beim Empfänger mit dynamischen IP-Adressen
    Gerade wer seinen Mailserver über eine dynamische IP-Adresse betreibt, wird nur einen Bruchteil der Mails zustellen können. Viele Mailserver lehnen Verbindungen aus dynamischen Adressen per Default ab. "Privatanwender" sollten einfach den Smarthost ihres Postfachbetreibers nutzen. Die meisten solcher eingehenden Verbindungen sind Spambots, Viren oder Trojaner
  • "Schutzbedarf"
    Wenn ihr Mailserver direkt per MX-Record Mails versendet, dann baut er eine transparent TCP-Verbindung nach extern zu "unbekannten" Systemen auf. Es ist z.B. denkbar, dass ich einen "bösen" Server betreibe und eine Mail an ihre System sende, die aber unzustellbar ist. Wenn ihr System nicht gleich ablehnt, dann sendet es eine unzustellbarkeit an mich zurück. Gäbe es eine Schwachstelle, könnte ich diese eventuell ausnutzen.
  • Mehrwertfunktionen (Archiv, Virenscan, Spamschutz, Disclaimer, Kryptografie)
    Viele Firmen erweitern das Mailsystem mit Zusatzfunktionen, die aber nicht direkt auf dem Mailserver selbst implementiert werden können. Oft erfolgt dies dann durch ein Relay, welches zwischen Internet und Mailserver geschaltet wird und die Mehrwertfunktionen nachrüstet. Ich habe schon ganze "Ketten" von Relays gesehen um mehrere Funktionen nachzurüsten, z.B.
    • Malwareschutz
      Auch ausgehend sollten Sie nicht auf Virenschutz verzichten. Wer als " Versender von Viren" auftritt, wird sehr schnell auf Blacklists landen und der Einfluss auf das Geschäft ist nicht zu unterschätzen. Das Risiko von Schadensersatzansprüchen ist ebenso vorhanden.
    • Signieren und Verschlüsseln auf dem Gateway
      Gerade der Einsatz von Signierung (SMIME/PGP) und natürlich DE-Mail kann durch ein Gateway auf dem Weg zum Internet elegant umgesetzt werden
    • Disclaimer
      Auch die in Deutschland seit einiger Zeit erforderlichen Zwangsangaben unter Mails können auf Relays addiert werden.
    • Archiv
      Diverse Appliances und Softwarelösungen klemmen sich zwischen Mailserver und Internet, um wirklich jede von und nach extern übertragene Mail zu "sehen" und in ein Journalarchiv abzulegen.
    • Mailrouting/Rewriting
      Gerade und größeren, komplexen Umgebungen oder bei Migrationen wird gerne ein Smarthost als intelligenter Router und zum umschreiben von Mailadressen eingesetzt.

Konfiguration des Smarthost

Die Einrichtung eines Smarthosts betrifft aus Exchange Sicht immer nur "ausgehende" Mails, die die Exchange Organisation verlassen.

Es ist nicht möglich, einen Smarthost innerhalb der Organisation in das Routing zwischen den Exchange Servern einzubinden. In Exchange 2003/2000 war so eine "Fehlkonfiguration" über den virtuellen SMTP-Server sogar möglich aber hat das Routing unterbrochen. Die Exchange Server "authentifizieren" sich gegenseitig (TLS).

Insofern wird der Smarthost beim SMTP-Connector (2000/2003) oder Send-Connector (2007/2010) konfiguriert.

Auf den Seiten habe ich aber nicht nur beschrieben, wie ein Smarthost eingerichtet wird, sondern optional auch eine Authentifizierung.

Sicherung des Smarthost

Wer einen Smarthost betreibt, betreibt ein "Relay" und muss sich natürlich gegen Missbrauch absichern. Wir betrachten hier nur den "Versand" von intern nach extern und die Liste der internen Quellen ist überschaubar. Insofern bietet es sich natürlich an, auf dem Smarthost eine "Whitelist" anhand der Quell-IP-Adresse zu pflegen oder in der Firewall nur diese Verbindungen zuzulassen. Nur Systeme auf dieser Liste können überhaupt per SMTP den Smarthost erreichen. Diese Liste ist in der Regel klein.

Als Betreiber eines Firmenmailservers sollten alle internen Absender natürlich immer den zentralen Mailserver nutzen, welcher in dem Zuge auch die lokale Zustellung als auch die Authentifizierung der Clients übernimmt.

Sollte es wirklich nicht möglich sein, die Clients anhand ihrer IP-Adresse zu filtern, dann können Sie eine Authentifizierung konfigurieren. Das kann auch zusätzlich zur IP-Filterung der Quelle erfolgen. So wird z.B. verhindert, dass jemand anderes die IP-Adresse missbräuchlich verwendet, indem es den eigentlichen Besitzer abgeschaltet hat.

Ich hatte schon mal eine SpamMail einer IP-Adresse, die eigentlich einem HP-Drucker gehört hat. Schenkt man dem userAgent glauben, war es aber ein Unix-System. Da könnte also ein "böser Anwender" das Kabel vom Drucker abgezogen  und stattdessen seinen Notebook angehängt haben.

Das Problem sehe ich aber als gering ab, wenn konsequent Clients und Server durch Subnetze und VLANs getrennt werden. Wenn dann eine IP-Adresse gekapert werden kann, dann ist der Angreifer schon viel zu nah am Server dran.

Bedenken Sie auch immer, dass bei einer Authentifizierung die Anmeldedaten auf dem ausgehenden Server hinterlegt sein müssen, dieses Kennwort vermutlich nie geändert wird und SMTP sehr einfach "abgehört" werden kann, wenn Sie die SMTP-Verbindung nicht verschlüsseln oder alternative Anmeldeverfahren statt "Klartext" nutzen

Ausgehender Smarthost im Internet

Verlassen wir nun das eigene Netzwerk und schauen und Smarthosts im Internet an. Eigentlich bräuchte man die nicht, wenn das System an der Grenze per MX-Record einfach seine Mails zustellen könnte. Auf der anderen Seite will man aber vielleicht doch eine Smarthost nutzen, um z.B. den Datenverkehr zu optimieren oder Zusatzleistungen eines Cloud-Anbieters zu nutzen.

Aber auch Provider möchten ihre Netzwerkstruktur gegen Missbrauch schützen und blockieren gerne mal Ports, die von "Endanwendern" eigentlich gar nicht benötigt werden. Viele Provider verbieten auch den Betrieb bestimmter Dienste und auch wenn dies vielleicht noch nicht durchgesetzt wird, kann dies zukünftig immer noch kommen. Schlimmstenfalls kündigt der Provider seinerseits den Vertrag, weil Sie einen günstigen Privatkundenvertrag doch als Firma nutzen. Dann geht nämlich die Kalkulation nicht mehr auf. Eine Familie oder ein Privatanwender nutzt eine Leitung deutlich weniger als eine Firma, hinter der sich mehrere Anwender befinden.

Wenn Sie aber einen Exchange Server z.B. hintern einem Anschluss mit dynamischer IP-Adresse betreiben oder andere Dinge verhindern, dass Sie selbst per DNS die Mails versenden, dann kommt ein Smarthost im Internet als nächste Station ins Spiel. Ein Smarthost kann an der Stelle aber auch hilfreich sein, wenn die Leitungen nicht "schnell" sind oder sie eine Mail an mehrere Empfänger verschiedener Domains versenden. Dann wird die Mail nur einmal mit allen Empfänger in der "RCPT TO Liste" an den Smarthost gesendet, der dann die weitere Verteilung übernimmt. Das ist besonders bei Newslettern nicht zu unterschätzen, wenn diese nicht personalisiert werden müssen.

Es bieten sich mehrere verschiedene Optionen an:

  • Der Smarthost des Zugangsproviders.
    Die erste Option ist ein Smarthost des Providers, der ihnen die physikalische Anbindung an das Internet bereit stellt. Er "kennt" sie bereits durch einen Vertrag und kann auch ihre aktuell zugewiesene IP-Adresse z.B. durch die Anmeldung des Routers nachverfolgen. Der vom Provider betriebene Smarthost kann Zugriffe von ihrem System schon allein anhand der IP-Adresse aus dem Bereich des Providers zulassen. Eine weitere Authentifizierung kann entfallen.
    Technisch könnte der Provider sogar auf seinen Routern jede ausgehende Verbindung „zwangsweise“ über sein Relay leiten (Zwangsproxy), so dass sie nicht einmal etwas konfigurieren müssten.

Achtung:
Einige ersetzen aber beim Versand einer Mail über das Relay die Absenderadresse durch die Mailadresse des Anschlussinhabers.
Es kann sich dann leider keine Firma dahinter verstecken. Einige Anbieter (Telekom) schalten diese Verhalten aber gegen Gebühr auch wieder ab.

  • Der Smarthost des „Domain Betreibers“
    Oft sind der Leitungsprovider und der Betreiber der Domäne und Webseite unterschiedliche Firmen. Es ist daher möglich, dass Sie einen Smarthost dieses Providers für den Versand verwenden. Allerdings wird dieser Provider natürlich auf einer Authentifizierung bestehen, da die IP-Adresse ihres Servers für ihn nicht zuzuordnen ist.
    Und auch hier muss geprüft werden, ob „any From-Adresse“ erlaubt ist oder auch wieder nur die Mailadresse des angemeldeten users ersetzt wird. Dies ist oft der Fall, wenn der Provider selbst die Postfächer betreibt und Sie die Mail per POP3 Sammler mit individuellen Postfächern abholen.
  • Anderer „bezahlter Smarthost
    Sie können natürlich auch einen ganz anderen Smarthost nutzen, der weder vom Zugangsprovider noch vom Domainprovider betrieben wird. Klassische Beispiele sind hierbei "Hosted Spamschutz" wie Postini, Retarus und andere, die ihre eingehenden Mails erst nach einer Filterung zu ihnen zustellen. Sie sollten dann auch ihre Mails über diese Systeme senden, damit diese Dienste ihre Mails "lernen" können.
    Auch Office 365 ist so eine Plattform, bei der Sie z.B. eine "Hybrid"-Konfiguration oder Office 365 als "Hosted Spamfilter" nutzen können.

Eingehende Relay (<> Smarthost)

Aber auch in der Gegenrichtung kann ein Smarthost gute Dienste tun. Allerdings ist hierfür die Bezeichnung "Smarthost" irreführend, weil niemand dieses System als "next Hop" einträgt, sondern die Absender natürlich per MX-Record diese Relay finden.

Mit einer festen IP-Adressen verweist der MX-Record z.B. auf ihren Mailserver. Nur sehr kleine Firmen werden ihren Mailserver mit einem Bein in das Internet stellen. In der Regel wird zwischen dem "unbekannten Absender" und dem Mailserver ein Relay als Schutz und Filter eingeführt. Es gelten hier in etwas die gleichen Beweggründe wie Malwareschutz, Archiv, Verschlüsselung etc. Dabei ist es unerheblich, ob das MX-Ziel nun bei ihnen in der DMZ oder bei einem Provider steht. Gerade beim Einsatz von Lösungen bei einem "Cloud-Anbieter" wird der MX-Record eben dorthin verweisen.

Interessant kann so ein Relay aber auch sein, wenn Sie sich hinter einer dynamischen Adresse verbergen. Wer hier einen MX-Record auf einen Rechnernamen verweisen lässt, der dann per dynamischen DNS im Internet auflösbar ist, wird immer zwei Risiken eingehen, die beim IP-Adresschange auftreten. Aufgrund von Cache-Funktionen in DNS-Servern wird eine Änderung nicht sofort aktiv. Selbst wenn der "Time to Live" (TTL) sehr kurz gesetzt wird, so gibt es immer wieder DNS-Server, die einen aus ihrer Sicht zu kleinen TTL durch einen vorgegeben Wert ersetzen. Immer dann treten die beiden Probleme für die Übergangszeit aus

  • Mail komme noch nicht an
    Es dauert einige Minuten bis Stunden, bis ihre "neue" Adresse auch verteilt ist. In der Zeit kommen keine Mails bei ihnen an.
  • Mails an ihre Domain landen bei einem anderen Server
    Wurde die von ihnen vorher verwendete IP-Adresse mittlerweile einem anderen Kunden ihres Providers zugewiesen, dann können Absender irrtümlich dort hin die Mails senden. Wenn der andere Kunde keinen Mailserver betreibt, dann werden die Mails nur verzögert. Schlimmer ist, wenn der andere Kunde auch auf Port 25 "lauscht". Er kann ihre Mails annehmen, beim Einsatz einer Wildcard-Funktion sogar sehen oder mit einer unzustellbarkeitsquittung beantworten oder ablehnen.

Leider können Sie daran nichts ändern außer zu warten oder eine andere Art der Anbindung zu wählen.

Weitere Links