In diesem Artikel versuche ich zu erklären, warum man manche spezielle Backup MX Konfiguration besser meiden sollte. Die Konfiguration eines Backup MX beim Provider oder Hoster ist veraltet und sollte nicht mehr genutzt werden.
Backup MX beim Provider
Schon häufiger habe ich die Konfiguration mit einem Backup MX Eintrag für den Provider vorgefunden. Die MX-Einträge für eine Domain sehen dann beispielsweise wie folgt aus:
frankysweb.de MX preference = 10, mail exchanger = MeinServer.MeineDomain.tld
frankysweb.de MX preference = 50, mail exchanger = BackupMX.MeinProvider.tld
Es gibt einen MX Eintrag bevorzugten MX Eintrag (preference = 10), welcher auf den eigenen Exchange Server oder das eigene AntiSpam Gateway zeigt. Ein weiterer MX Eintrag für die Domain zeigt auf ein Relay beim Provider (preference = 50). Der Gedanke dahinter ist folgender: Fällt der eigene Internetanschluss oder irgendwas an der eigenen E-Mail Infrastruktur aus, werden Mails nicht mehr an den bevorzugten MX zugestellt, sondern an den BackUp MX beim Provider. Der Provider speichert die Mails in seiner Queue zwischen und stellt diese zu, wenn die Funktion der eigenen E-Mail Infrastruktur wiederhergestellt ist.
Leider hat diese Konfiguration aber einen Haken: In der Regel sind die Backup MX Einträge deutlich schlechter gegen Spam und dergleichen geschützt, wie der bevorzugte MX Eintrag. Meistens gibt es da keine gut trainierten Spam-Filter, ausgeklügelte Blacklisten oder andere modernen E-Mail Sicherheitsfeatures. Es ist in der Regel ein ganz rudimentäres Relay, welches so gut wie jede Mail annimmt und in die Queue packt und an die eigenen Server zustellt wenn diese verfügbar sind. Manche Provider setzen dies sogar derart schlecht um, dass gar nicht geprüft wird, ob der bevorzugte MX verfügbar oder ausgefallen ist und nehmen daher einfach alles an, was den Backup MX erreicht.
Diese Konfiguration ist bei Spammern besonders beliebt, denn anstatt den Spam an den bevorzugten MX zu schicken, wird einfach der MX mit der höchsten Preference benutzt. Dieser nimmt ja den ganzen Spam an und leitet es weiter.
Auch macht man es sich hier selbst nicht einfacher, denn der eigene Spam-Filter kann einige Prüfungen auf Spam nicht mehr durchführen, wenn die Mails über den vermeintlich vertrauenswürdigen Backup MX zugestellt werden. Blacklist-, SPF- und RDNS-Checks sind die bekanntesten Prüfungen die nicht mehr funktionieren, wenn die Mail die eigene AntiSpam Lösung über den Backup MX erhält.
Hinzu kommt noch ein weiteres Problem: Mails an nicht existierende Empfänger, der Backup MX weiß in der Regel nicht, welche E-Mail Adressen existieren und welche nicht. Der Backup MX nimmt daher erst einmal alle Mails an und leitet diese weiter. Erst die eigene Antispam Lösung oder der eigene Mailserver führt die Empfänger Prüfung durch und beantwortet Mails an nicht existierende Empfänger mit einem NDR. Dies nennt sich dann BackScatter Spam, Spammer erzeugen Spam mit NDR Nachrichten, indem der der Absender gefälscht wird und im NDR als Empfänger gilt. Dieser Spam wird dann auch noch vom eigenen Mailserver versendet, da dieser ja den NDR erzeugt, im schlimmsten Fall hängt dieser auch noch den Spam als Original Message an den NDR an.
Meine Meinung zu den Backup MX beim Provider ist folgende: Nicht nutzen. Einfach weglassen. Ich würde behaupten es reicht in 99% der Fälle genau ein MX Eintrag pro Domain aus. Um bei dem Beispiel von oben zu bleiben, würde also dieser MX ausreichen:
frankysweb.de MX preference = 10, mail exchanger = MeinServer.MeineDomain.tld
Wie man sieht, verweist der MX auf einen Host-A Record, wer beispielsweise redundante Systeme betreibt legt also einfach zwei mal den Host-A im DNS mit unterschiedlichen IPs an. So hat man ein via DNS Round Robin auch gleich ein einfaches Loadbalancing. Betreibt man nur eine kleine Umgebung ohne Redundanz, reicht auch ein Host-A mit der IP. Fällt dieser aus. kommen eh keine Mails mehr rein und anstatt des Backup MX beim Provider speichern nun die Mailserver der Absender die Mails in den Queues. Exchange hält beispielsweise eine Mail welche nicht zugestellt werden kann, 2 Tage lang in der Queue. Das sollte doch reichen um die eigene Infrastruktur wieder ans Laufen zu bekommen.
Backup MX beim Provider und POP3 Postfächer
Aus meiner Sicht ist die folgende Konfiguration noch eine Steigerung der schlechten „Backup MX beim Provider“-Konfiguration. Im Prinzip ist die Ausgangslage die Gleiche wie oben schon geschildert, aber mit einer zusätzlichen Verschärfung. Der Backup MX beim Provider, stellt die Mails nicht an den bevorzugten MX zu, sondern speichert die Mails in eigenen Postfächern. Diese Postfächer werden dann mit POP3-Connector wie etwa POPcon oder Ähnlichem abgeholt und an den eigenen Mailserver zugestellt. So umgeht man also jegliche AntiSpam Maßnahmen des Unternehmens. Das Worst-Case Szenario ist schnell erklärt: Eine Malware Mail wird direkt an den Backup MX geschickt, landet via POP3 Connector direkt im Postfach des Anwenders, Anwender klickt auf bösen Anhang und die Ransomware breitet sich aus. Dies ist übrigens keine Fiktion, sondern leider genauso bei einigen Admins/Unternehmen passiert.
Noch ein weiterer Grund diese Konfiguration zu meiden ist, dass die POP3 Mailboxen beim Provider auch erstellt und verwaltet werden müssen. Die Mailboxen beim Provider müssen also synchron mit den Exchange Mailboxen verwaltet werden, damit man nicht ebenfalls Backscatter Probleme einhandelt oder valide Mails abgewiesen werden, weil vergessen wurde eine entsprechende POP3 Mailbox beim Provider zu erzeugen oder zu löschen. In meinen Augen ist dies doppelter Aufwand für einen sehr eingeschränkten Nutzen.
MX beim Provider und POP3 Postfächer
Ich dachte eigentlich, dass diese Konfiguration schon lange ausgestorben ist. Ich glaube diese Konfiguration hatte seine Hochzeit zu den „Windows Small Business Server Zeiten“. DAMALS wurde oft ein SBS Server als Eierlegendewollmilchsau in kleinen Unternehmen installiert. Da zu dieser Zeit kleine Unternehmen keine feste IP hatten und DSL Zwangstrennungen noch zum Standard gehörten, machte diese Konfiguration DAMALS noch einen gewissen Sinn. Diese Zeiten sind lange vorbei. Meiner Meinung nach handelt man sich hier nur Probleme ein, wie die beiden oberen Konfigurationen schon verdeutlichen sollten. In diesem Fall verlässt man sich komplett auf die AntiSpam Features des Providers und halst sich den Aufwand der Pflege der POP3 Postfächer auf. Die meisten Provider beschränken ihre AntiSpam Funktionalität auf das Nötigste, meistens sind dort nur ein paar Blacklisten konfiguriert. Ich habe in diesem Fall auch schon die wildesten Konfigurationen gesehen, diverse Umleitungen von einer Provider POP3 Mailbox zu einer anderen POP3 Mailbox und es war kaum noch festzustellen welche E-Mail Adresse denn nun wo an kommt. In diesem Fall kann ich nahezu dafür garantieren, dass halbwegs gut gemachte Phishing Mails oder Ransomware zugestellt wird. In dieser Konfiguration muss man als Admin nicht nur zwei Umgebungen verwalten (Provider und lokaler Exchange) und sich zusätzlich auch noch auf die AntiSpam Lösung des Providers verlassen. Es gibt hier auch Provider, welche scheinbar ein ganz einfaches Prinzip verfolgen: Lieber eine Mail zustellen, als sich auf eine False-Positive Diskussion mit dem Kunden einlassen. Ganz bitter wird es, wenn es dann auch CatchAll Postfächer gibt, welche einfach jede Mail annehmen. Hier befindet sich dann 99,99% Spam und oft gibt es dann auch noch eine arme Seele im Unternehmen, die aus 10000 Spam-, Phishing- und Malwaremails die eine Mail mit falsch geschriebenen Empfänger erkennen soll.
Wie man es besser macht
Die genannten schlechten Konfigurationen zu vermeiden ist eigentlich überhaupt nicht schwer. Wer aktuell noch eine der genannten Konfigurationen einsetzt, könnte beispielsweise recht einfach zu einem Cloud Spamfilter migrieren. Wer mal nach Cloud Spam Filter googled findet unzählige Anbieter und Lösungen. Bei einem Cloud Spam Filter zeigt der MX Eintrag auf den Anbieter des Spam Filters, der Anbieter sorgt dann für hoch verfügbare Systeme, sowie je nach Anbieter für moderne AntiSpam Features. Der eigene Server nimmt dann nur noch Mails via SMTP von den IP-Adressen des Anbieters an. In diesem Fall zeigt also kein MX Record mehr auf eigene Server. Ein Cloud basiertes AntiSpam System hat den Vorteil, dass man selbst keine eigenen Server mehr für das Filtern der Mails betreiben muss. Um die Hochverfügbarkeit muss man sich in der Regel auch nur wenig Gedanken machen, da dies der Anbieter übernimmt. Vom Prinzip her entspricht ein Cloud basierter Spam Filter dem Szenario „MX beim Provider“, es gibt allerdings wichtige Unterschiede: Ein Anbieter für Cloud basiertes AntiSpam betreibt E-Mail Security als Geschäftsmodell und nicht als „kleinen Service“ der wie bei einem Hoster oder Provider neben her läuft. Jedem der aktuell eine der drei genannten schlechten Lösungen betreibt, kann sich ja einfach mal bei folgenden Lösungen umschauen:
Wenn keine Cloud Lösung zum Einsatz kommen soll, kann natürlich der MX Eintrag auf die eigenen Server zeigen. Hier sollte dann aber nur genau ein MX Eintrag pro Domain existieren. Unterschiedliche MX Einträge mit unterschiedlicher Gewichtung sind nicht nötig. Wenn hochverfügbare Server für den Mailempfang betrieben werden, dann reicht es aus, den Host-A Eintrag auf den der MX verweist mit mehreren IPs anzulegen. Hier mal ein Beispiel für meine Domain und Office 365:
Wie in dem Screenshot zu sehen ist, gibt es nur einen MX Eintrag welcher auf den Host „frankysweb-de.mail.protection.outlook.com“ zeigt. Der Host-A Eintrag für „frankysweb-de.mail.protection.outlook.com“ zeigt dann auf die beiden IPs 104.47.7.138 und 104.47.11.138. In kleinen Umgebungen könnten dies zwei redundante AntiSpam Appliances sein. In größeren Umgebungen könnten sich hier auch Loadbalancer zum Einsatz kommen, welche die Last auf viele AntiSpam Appliances verteilen und somit auch die Verfügbarkeit erhöhen.