I am still receiving mails about the changeover from POP3 retrieval to direct receipt of mails via MX record in connection with various Exchange versions. I actually thought that retrieving mails from a provider via POP3 and delivering them to local Exchange servers was a thing of the past, but this seems to be more common than I thought. So here's a short article on the subject.
Procedure for switching from POP3 retrieval to receipt via MX
The procedure is quite simple and quick to carry out, but there are a few requirements to ensure that it runs smoothly:
- A fixed IP address should be available (IPs from dynamic address ranges are usually blocked by most recipients)
- The host of the domain (e.g. frankysweblab.de) must allow the MX record to be changed
- The provider of the Internet connection (e.g. Telekom) must allow the setting of a PTR record
- A certificate is required, Let's Encrypt offers these free of charge. SMTP without encryption is bad
- You must take care of appropriate protection yourself (AntiSPAM, AntiVirus)
To ensure that nothing goes wrong during the changeover and that mails are not lost, it must be checked before the changeover whether all e-mail addresses exist on the Exchange server. Years ago, I once saw a very unfortunate configuration in an environment. The hoster of the domain had only created one catch-all mailbox, and countless redirects were defined in the POP connector, something like this:
- info@domain.de send to benutzera@domain.de
- benutzera@domain.de deliver to benutzera@domain.de
- bestellung@domain.de send to benutzerb@domain.de
- irgendwas@domain.de send to benutzera@domain.de
- etc, etc, etc
- deliver everything unknown to benutzerb@domain.de
In such a case, all redirects can be resolved first; you could work with distribution groups or shared mailboxes, for example. It is particularly stupid if there is a redirect from all unknown addresses to one user, because this user can theoretically be reached under umpteen mail addresses. This is where message tracking helps to find used addresses.
To switch from POP retrieval to reception via MX, I therefore proceed as follows:
- Create HOST-A entry for the MX (e.g. mail.frankysweblab.de with reference to the fixed IP)
- Create PTR (reverse pointer) for the HOST-A entry (e.g. fixed IP with reference to mail.frankysweblab.de)
- Make Exchange Server or AntiSPAM Gateway accessible from the Internet under the fixed IP with port 25 TCP (SMTP) (e.g. via NAT)
- Test whether an SMTP connection is possible (MXToolbox SMTP Check)
- Check that the fixed IP is not on any blacklist (MXToolbox Blacklist Check)
- If the domain host allows it, the TTL of the MX record can be reduced before the changeover, for example to one hour. However, this is not absolutely necessary, patience works just as well.
- Change the MX record to the HOST-A record (e.g. mail.frankysweblab.de)
- Wait 24 hours and carry out tests from time to time (MXToolbox MX Test)
- Deactivate / uninstall POP Connector
- Delete POP mailboxes at the hoster
That's all there is to it. Normally a completely painless changeover.
Short example using Strato and Telekom
Here is a simple example of the procedure using the domain frankysweblab.de (my new test domain). The domain is hosted by Strato, the Internet provider with the fixed IP is Telekom.
The Strato mail servers are set as MX for frankysweblab.de at the Strato host, the mails are collected from the Strato POP servers via POP3 and POP Connector and delivered to the Exchange server:
A HOST-A entry is therefore created first, with some hosters this is also a subdomain with a HOST-A entry, this varies from hoster to hoster. At Strato, a subdomain must be created first, in this example mail.frankysweblab.de:
The HOST-A is then configured to the fixed IP for the subdomain:
After the Host-A has been created, it looks something like this:
The PTR entry is again created at the provider of the Internet connection (where the fixed IP comes from). In this case, this is Telekom:
The reverse resolution is now configured here, fixed IP to name. In the screenshot it says mail.frankysweb.de, so for this example it should be mail.frankysweblab.de, but I didn't want to change the PTR of my fixed IP now:
As soon as the remaining steps in the above list have been completed, the MX must be changed at the hoster (in this case Strato):
Now you have to wait 24 hours. As a rule, no more mails should land in the POP mailboxes after 24 hours.
Hallo Frank,
danke für den Artikel. Hätte mal eine Frage….vielleicht macht das nicht unbedingt Sinn für einen „produktiven“ Kunden, hierbei gehts jedoch lediglich um mich privat, da ich gerne mit Exchange arbeite und auch etwas rumspiele.
Bei mir ist es so, dass ich aktuell einen Hosting Anbieter habe, wo auch meine Mails ankommen. Dort hole ich die dann mit „POPcon“ als POP3 Connector ab und stelle die Mails zu in meine Exchange Konten. Da ich aber nur nen kleinen Server im Keller stehen habe kann es durchaus mal vorkommen, dass der in selteneren Fällen nicht erreichbar ist.
Wie würdest du vorgehen? Ich möchte den ungern komplett In- / Out über MX Einträge betreiben, da ich bedenken habe, dass Mails verloren gehen. Würde gerne den Empfang mit POP und Catch-All beibehalten, jedoch möchte/muss ich den Versand auf MX umstellen. Sende derzeit auch über einen Smarthost raus. Mein Problem ist jedoch:
Ich habe inzwischen 3 verschiedene Domains in meinem Exchange.
kontakt@domain1.com
info@domain2.de
privat@domain3.de
Mit den Smarthosts scheint das aber nicht möglich zu sein die pro Konto zu hinterlegen? Es kommen also alle E-Mails im richtigen Postfach bei mir an, aber es wird von allen 3 Konten derzeit mit nur einer E-Mail Adresse rausgeschickt.
Hast du da vielleicht nen praktikablen Lösungsansatz?
Danke und LG
Hallo,
ich habe ein Problem bei einem Kunden. Bestand:
– Deutschland-LAN bei der Telekom mit fixer IP
– Sophos-Firewall
– Exchange 2016
– POP-3-Postfächer bei Domainfactory
– POP-Con als Mailabholer
Konfiguration wie folgt:
Popcon holt bei den Postfächern per POP3 die Mails ab, überträgt diese an die IP der Sophos und leert dann die Postfächer. Die Sophos leitet die Mails dann an den Exchange weiter.
Beim Senden überträgt Exchange die Mails an die Sophos (Sophos ist als Smart-Host im Sendeconnector eingetragen). Die Sophos überträgt die Mails ins Internet (komischerweise habe ich keinen Smart-Host des Mailproviders in der Sophos eingetragen. Funktioniert trotzdem.).
Es ist eine Subdomain outlook.domain.de angelegt und zeigt mittels A-Record auf die feste IP. Die Sophos macht mit WAF und den gekauften Zertifikaten dann die Weiterleitung an OWA. Funktioniert auch. Intern verbinden sich alle Outlooks der Arbeitsplätze brav mit dem Exchange und es gibt nirgendwo Zertifikatsfehlermeldungen.
Nun aber:
Es werden einige Mails, die von den Mitarbeitern geschrieben werden, abgelehnt. Z.B. werden alle Mails, die mit @t-online enden, nicht zugestellt.
Ich sprach dann mit der Telekom und die sagten, daß ich einen Reverse-DNS setzen muß. Ich habe dann im Kundencenter einen Reverse-DNS auf outlook.domain.de gesetzt. Und in den Einstellungen der Sophos den eigenen Hostnamen auch auf outlook.domain.de gesetzt.
Ein Test mit mxtoolbox.com schlägt aber mit einer SMTP-Banner-Fehlermeldung fehl. Ich nehme an, daß auch weiterhin keine mails an einige Empfänger so nicht rausgehen werden.
Wo mag hier der Fehler liegen?
Gruß
Christoph
Mein Tipp:
Mit Postfix einen Exchange Frontend bauen, (oder gleich 2 :) )
Für die Umstellung auf MX erstmal alles zum alten Provider relayen.
MX Eintrag auf das Frontend umbiegen
24h – 48h warten so sollte der DNS Eintrag überall verteilt sein.
und dann am Tag X einfach auf dem Frontend das Relay Ziel ändern.
Funktioniert auch, wenn der Exchange eine dynamische Adresse benutzt. (Sendeconnector = Exchange Frontend)
Weiter Vorteile: Es gehen keine Mails verloren, wenn mal die eigene Internetverbindung ausfällt, da das Frontend die Mails behält und weiterhin versucht diese zuzustellen,
Weitere Interessante Vorteile:
Direktes „Aussortieren von SPAM / Viren“ möglich, noch _BEVOR_ die Mails auf dem Exchange landen.
Direktes Prüfen der Empfänger, d.h. alle Mails direkt Ablehnen (reject) für die es eh kein Postfach gibt.
Hallo,
hast du evtl. eine Anleitung wie ich Postifx als Frontend einrichte?
Für den Fall das Mails verloren gehen, hilft einen BackupMX falls der Primär Anschluss ausfällt.
Aber nur dann wen der Anschluss weg ist, davor macht das die Sophos, die nimmt die Mails noch an und wartet ne weile mit der Zustellung.
Ich habe zwar auf Offic365 migriert, aber ein Pop3-Tool à la Popbeamer war meines Erachtens immer nützlich. Erstens wird so beim Provider bereits SPAM gefiltert, zweitens gehen keine Mails verloren falls man nur einen Exchangeserver hat und diesen neustarten oder ein Disaster Recovery durchführen muss und drittens steht man bezüglich Security etwas besser da, da man nur Port 443 fürs OWA öffnen muss.
Also obwohl angestaubt, finde ich die POP-Anbindung von Exchangekonten gar nicht so schlecht.
Gruss Dave
Der Artikel ist gut. Vielen Dank!
Kleiner Tip: Wenn möglich, sollte man den alten MX-Record als Backup-MX während der Umstellung beibehalten und den Pop-Abruf vorübergehend aktiviert lassen. Sollte nach einiger Zeit wirklich nichts mehr zum alten Mailserver zugestellt werden, kann der Backup-MX weg.
Steht ganz unten in dem Artikel, warum MX auf dyn doof ist.
Ich habe nie von einem Cname gesprochen.
Soviel zum Thema dyndns: https://www.sult.eu/2017/05/05/mx-record-zeigt-auf-cname-keine-gute-idee/
@Sebastian:
Ha, gerade gestern das Problem gehabt. Musste den SPF-Check am Spamfilter abschalten weil es so viele Firmen gibt die entweder nicht wissen wie ihr SPF-Eintrag lauten soll, oder sich einfach nicht drum kümmern. Da werden Smarthosts genutzt und was nicht alles, grausam.
Selber setzen sollte man ihn aber, da hast du Recht.
Optional kann ausgehend und eingehend eine Endian Firewall Community Version schützen.
Diese kann als SMTP Proxy dienen sich um Viren und Spam kümmern.
Mit ein paar kleinen eingriffen lässt sich hier auch ein eigenes Zertifikat hinterlegen,
Let’s Encrypt vielleicht weniger, das wird ja alle xx Tage Automatisch aktualisiert und müsste ja direkt in die EFW eingebunden werden.
Frank, du hast meiner Meinung was wichtiges vergessen, was die meisten vergessen und oft zu Spam- oder sogar Virenangriffen sorgt.
Die Leute vergessen heute immer noch den SPF Record zu setzen, der einem selbst bei entsprechender FW aber auch andere Kunden schützt.
Stephan’s Methode funktioniert mit Strato auch einwandfrei. Die dynamische IP ist nur beim Senden ein Problem, dafür nimmt man dann eben den Provider-Mailserver als Senderelay. Für zu Hause oder Testumgebung ist das doch OK.
Man kann allerdings z. B. bei 1&1 einen mx record auf eine dyndns Adresse legen, ein catchall Postfach belassen und dieses im Exchange Send connector eintragen. Nicht schön funktioniert aber.