Planung und Durchführung von Serverwechsel

[coltseavers]

Hallo zusammen,

ich möchte meinen derzeitigen Mailserver auf neue Hardware umziehen.
Ich stricke mir dafür gerade eine Abarbeitungsreihenfolge, die sicherlich noch fehlerhaft und auch noch nicht komplett ist.
Vielleicht könnt ihr mir dabei helfen sie fertigzustellen und zu korrigieren?

Zunächst aber erstmal ein paar Infos zu den Systemen etc:
Alter Server: Debian 6 stable, mit Postfix und Dovecot (IMAP), also MTA und MDA
Neuer Server: gleiches System, nur mit Debian 7 stable und besserer Hardware.

Das System soll möglichst ohne Ausfall umgestellt werden und der Hostname soll dabei übernommen werden (an dieser Stelle sehe ich noch Probleme, dazu später mehr).

Plan bisher:
1) Neues System mit identischer Konfiguration vorbereiten
2) erstes Überspielen der IMAP-Postfächer mit dem Tool imapsync
3) Umstellen des DNS-Eintrages von mail.blablubb.xy von altem Server auf neuen Server - Beginn des Parallelbetriebs
4) Fortwährender Abgleich per imapsync von altem nach neuen Server (1x pro Stunde oder so)
5) Nach 48 Stunden Abschalten der Maildienste am alten Server - Ende des Parallelbetriebs
6) Ausführen des letzten imapsync

Soweit ok? Oder was muss noch geändert werden? Was kann man noch besser machen?
Die Sache mit den 2 MX-Einträgen macht in diesem Szenario glaub ich keinen Sinn, weil der Hostname ja identisch ist, oder?

Kopfzerbrechen bereitet mir noch die Umstellung des PTR-Records.
Während des Parallelbetriebs haben ja beide Server den gleichen Hostnamen, aber unterschiedliche IPs.
Können dann während des Parallelbetriebs zwei unterschiedliche IPs auf den gleichen Hostnamen verweisen?
Falls nicht: wie macht mans richtig?

Ich sehe nämlich folgendes Problemszenario während des Parallelbetriebs:
Ein User liefert über seinen Client eine Mail schon am neuen Server ein, da sein Nameserver schon die neue IP liefert.
Der neue Mailserver liefert die Mail in die Welt hinaus. Der empfangende Mailserver prüft zum Schutz vor Spam per Reverse Lookup, ob der einliefernde Server für die Domain auch autorisiert ist. Da der empfangende Mailserver aber dann möglicherweise noch die alten Infos von seinem Nameserver bekommt, wird die Nachricht dann z.B. nicht angenommen.
Lässt sich das Problem umgehen? Wenn ja, wie?

Vielen Dank vorab!

[ddm3ve]

Das Problem sehe ich aber beim MDA (der ja auf dem gleichen Host liegt):
die Server müssen deshalb den gleichen Hostnamen haben, denn in den Clients ist ja als IMAP-und SMTP-Server nur z.B. host1.blablubb.xy hinterlegt. Ich will ja nicht bei allen Clients die Serverdaten ändern müssen.
Und wenn ich host1 im DNS einfach auf host2 weiterleiten würde und sich der neue Server dann mit host2 meldet, schlägt das SSL-Zertifikat natürlich Alarm, weil das ja nur grünes Licht gibt, wenn sich host1 meldet. Richtig?

http://www.rootforum.org/forum/viewtopi ... 33&t=54323

Der "physische" Hostnamen hat nichts mit den Domains Deiner Kunden zu tun und wird auch nicht an die Endkunden weiter gegeben.

Dein Kunde bekommt i.d.R. "logische" Namen, die Du mit dem DNS Umzug mit um ziehst.
Daran sind ja dann auch die SSL Zertifikate angebunden.

Als Beispiel:
Bei uns hat jeder Kunde einzelne oder mehrere Domains.
Für Dienste wie z.B. Email im allgemeinen gibt es eine "Subdomain". mail.domain.tld.
Sofern Web MTA und MDA auf der gleichen phyischen Maschine sind brächte es eine solche Trennung nicht und er würde in den Connection Parameter einfach nur seine domain.tld eintragen.

Mit dem DNS Update kommt es zu einem fliessenden Wechsel.
Die SSL Zertifikate müssen natürlich auf dem neuen System ebenfalls für die Domains / IPs existieren.

Danach ist die Umstellung mit zeitlichem Delay nur noch eine DNS Änderung.


Ganz simpel betrachtet, bedeutet hier der Umzug, lediglich ein Fullbackup auf dem Altsystem, fullrestore auf dem neu System.
Anapassen der IP, physischer Hostname.


Danach die schon geschilderten DNS Umstellungen und die neuen Maildaten etc. rüber schieben auf den neuen MTA / MDA.
Siehe auch Link oben.

[ddm3ve]

Die Sache mit den 2 MX-Einträgen macht in diesem Szenario glaub ich keinen Sinn, weil der Hostname ja identisch ist, oder?

Nein, das sind die beiden "physische" Hostnamen.
Du hast im Paralellbetrieb ja auch 2 phyische Server auch wenns nur eine vm ist.

der DNS und RDNS Eintrag des physischen FQDN host1.domain.tld muss zu einander passen damit der MTA auf beiden Systemen zuverlässig funktioniert.
Das hat jetzt erst mal nichts mit den dort gehosteten Domains zu tun.

[coltseavers]

Neja, bei mir ist das wie folgt:

Die kunden haben z.b. ne domain "domain1.xy".
Der Fqdn des Mailservers lautet aber "mail1.isp.xy"
Nur der Mailserver-Fqdn steht auch im SSL-Zertifikat, und in den Mailclients steht bei IMAP und SMTP entsprechend auch "mail1.isp.xy", und nicht etwa des Kunden Domain.

Somit verbindet sich der Mailclient immer nur mit "mail1.isp.xy", deshalb mussen sich im Parallelbetrieb auch beide server so zu erkennen geben.
Deshalb das Problem mit dem PTR, oder reden wir aneinander vorbei?

[ddm3ve]

mail1.isp.xy -> Wenn Das Deine Domain ist, müsstest Du genau diese später um ziehen per DNS Update.

Wenn das die IP deines Providers ist, dann wäre das genau die "physische" Adresse von der ich spreche.
Die Domains /DNS Name verbleibt natürlich dann beim Host.
Deine Kunden müssten dann Ihre Systeme um konfugieren.

Falls nein, solltest Du wohl so eine eigene Schicht des Hostnamen / Hostdomain einführen und kannst die genannte Domain um ziehen.

Zukünftig würde ich immer eine eigene und für nichts anders verwendete subdomain für einen host einrichten.
Meistens hat dies ja schon der Anbieter selbst erledigt.

[coltseavers]

Erstmal vielen Dank, dass du mir so unermüdlich hilfst!
So 100% ig habe ich aber leider noch nicht verstanden, was das nnun für mich bedeutet.

Was heißt das denn jetzt für meinen Umzugsablauf?
Umstellungen am Client sollen natürlich vermieden werden.

Kannst du meinen o.g. Ablaufplan kopieren und korrigieren?
Was ist denn nun mit dem PTR?

[ddm3ve]

Wenn ich dazu komme zeichne ich mal etwas dazu und erkläre was ich meine in einem Powerpoint oder ähnliches.

Zum PTR oder auch RDNS:

Du hast 2 Maschinen:

mail-alt.exaple.com 192.0.0.1
mail-neu.exaple.com 10.0.0.1

Entsprechend der PTR
-> 192.0.0.1 mail-alt.exaple.com
-> 10.0.0.1 mail-neu.exaple.com

Deine bisherige Sudbomain mail1. usw. würde ich wie insgesamt die Domains um ziehen. aber vorher erstmal 2 Subdomains auf bauen, beide Server entsprechend um bauen.

Diese beiden Subdomains dienen dann nur dem störungsfreien Betrieb des Mailserver und davon braucht niemand etwas wissen.
-> Also auch kein Kund etc.
Dafür nutzt Du andere Domains / IPs etc.

[coltseavers]

Ich verstehe schon, was Du meinst.

Wenn ich das so machen würde, wie Du vorschlägst, sehe ich für den Empfang von E-Mails von aussen auch kein Problem.
Dann würde ich im DNS eintragen:
mx-alt.blablub.xy auf alte IP
mx-neu.blablub.xy auf neue IP
und entsprechend die beiden PTR einrichten - und dann irgendwann mx-alt abschalten und aus dem DNS nehmen.
Alles verstanden und klar soweit.

Das Problem ist dann aber:
Bei den Kunden im E-Mail-Client ist ja dann weiterhin mx-alt.blablub.xy eingetragen (und so soll es bleiben, denn der Kunde soll ja nichts umstellen müssen), dann kann ich ja nicht einfach mx-alt.blablub.xy auf die neue IP umstellen.
Denn wenn dann der Kunde Mails abruft, kontaktiert er ja mx-alt.blablub.xy - und wenn sich dann durch die Umleitung auf die neue IP plötzlich der neue Server mit hostnamen mx-neu.blablub.xy identifiziert, dann schlägt ja das TLS-Zertifikat Alarm, weil es ja nur ne Verbindung zu mx-alt.blablub.xy zulässt.
Oder sehe ich das falsch?

Aber wenn ich am neuen Server auch ein neues TLS-Zertifikat einsetze... hmm, dann könnte es klappen, oder?
Denn das Zertifikat prüft ja nur die Kennung des Mailservers und nicht den hosteintrag im client, richtig?

[jan10001]

Ganz ehrlich, ich verstehe hier nicht warum ihr das so kompliziert macht.

1. Zertifikat auf beiden Server installieren
2. RDNS alter und neuer Server setzen auf: blablubb.xy (MX)
3. neuen Server in Betrieb nehmen
4. mail.blablubb.xy auf neuen Server zeigen lassen (Vorzugweise dies am späten Abend setzen.)
5. fortwährenden Datenabgleich machen
6. nach 24h Stunden blablubb.xy (MX) auf neunen Server zeigen lassen
7. nach weiteren 24h alten Server abschalten

1. Die Domain für den Mailversand ändert sich nicht und somit stimmt das Zertifikat.
2. Versendet der Kunde eine Mail über den alten oder neuen Server kommt sie immer an, da der RDNS Eintrag stimmt.
4. Damit stellst du sicher das deine Kunden ihre Mails vom neuen Server holen, das erleichtert den Datenabgleich.
6. und 7. 24h Stunden sollten ausreichen für ein DNS Update, bei Bedarf kannst du auch gern mehr machen

[coltseavers]

Servus Jan,

danke für Deine Hilfe.

So hatte ich das ja auch schon angedacht.
Aber bitte lies dazu nochmal die letzten beiden Absätze meines ersten Beitrages.

[jan10001]

Meinst du die?

Kopfzerbrechen bereitet mir noch die Umstellung des PTR-Records.
Während des Parallelbetriebs haben ja beide Server den gleichen Hostnamen, aber unterschiedliche IPs.
Können dann während des Parallelbetriebs zwei unterschiedliche IPs auf den gleichen Hostnamen verweisen?
Falls nicht: wie macht mans richtig?

Ja das geht.

Ich sehe nämlich folgendes Problemszenario während des Parallelbetriebs:
Ein User liefert über seinen Client eine Mail schon am neuen Server ein, da sein Nameserver schon die neue IP liefert.
Der neue Mailserver liefert die Mail in die Welt hinaus. Der empfangende Mailserver prüft zum Schutz vor Spam per Reverse Lookup, ob der einliefernde Server für die Domain auch autorisiert ist. Da der empfangende Mailserver aber dann möglicherweise noch die alten Infos von seinem Nameserver bekommt, wird die Nachricht dann z.B. nicht angenommen.
Lässt sich das Problem umgehen? Wenn ja, wie?

Erfahrungsgemäß machen die meisten Mailserver nur einen einfachen Check. Sie prüfen nur den Namen im Helo Teil mit dem Ergebnis des Reverse Lookups. Meldet sich dein Server also mit "HELO blablubb.xy" dann macht der andere Server einen Reverse Lookup und erhält dann blablubb.xy was ja passt.

Zudem solltest du deine Kunden informieren das ein Server Umzug statt findet und das der Mailverkehr etwas gestört werden könnte. Auch solltest du den Umzug am Wochenende machen, dann sollte alles am Montag wie gewohnt laufen.

[ddm3ve]

Meinst du die?

Kopfzerbrechen bereitet mir noch die Umstellung des PTR-Records.
Während des Parallelbetriebs haben ja beide Server den gleichen Hostnamen, aber unterschiedliche IPs.
Können dann während des Parallelbetriebs zwei unterschiedliche IPs auf den gleichen Hostnamen verweisen?
Falls nicht: wie macht mans richtig?

Ja das geht.

Theoretisch schon.
Praktisch wenn der alte Host noch Emails versendet und der A Eintrag mail.domain.tld auf die neue IP verweist.
Werden Email eventuell abgelehnt. Daher sollte DNS und RDN Eintrag passen.
Wäre meines Wissens auch RFC Konform.
Im Idealfall hat jeder Server einen eindeutigen DNS und RDNS Eintrag der auch zueinander passt. Damit vermeidet man das Problem grundsätzlich.
Umständlich ist das nicht, wenn man schon von vornherein seine Infrastruktur sauber auf baut.

[jan10001]

Theoretisch schon.
Praktisch wenn der alte Host noch Emails versendet und der A Eintrag mail.domain.tld auf die neue IP verweist.
Werden Email eventuell abgelehnt. Daher sollte DNS und RDN Eintrag passen.
Wäre meines Wissens auch RFC Konform.

Die Frage wäre dann, ist der MX Eintrag mail.domain.tld?
Wenn er mail.domain.tld als MX Eintrag verwendet, dann gibt es Probleme. Ist sein MX Eintrag ein anderer dann wird es gehn.

Bei mir benutzen die Kunden zwar mail.domain.tld für den Mailversand aber der Mailserver hat eine andere Domain. (MX)

[ddm3ve]

Lies den Post nochmals komplett durch dann verstehst Du warum ich Ihm den Weg empfohlen habe.
Ja scheint so zu sein.

[jan10001]

@ddm3ve
Du hast Recht, sieht ganz danach aus, anders kommt er bei so einer Config nicht weiter.

[coltseavers]

ok - neuer server kriegt neuen hostnamen. entscheidung gefallen.
also muss neues zertifikat her, ok.

Schlachtplan also nun:
1)
Neuen Server identisch einrichten, aber neuer hostname mit neuem zertifikat

2)
RDNS und A-Record für neue IP / neuen hostnamen setzen. Anschliessend 24 Stunden warten.
(Hat aber noch keinen Einfluss auf Mailverkehr)

3)
Beginn Parallelbetrieb:
Alter MX-Eintrag wird durch neuen ersetzt: Mails gehen nun an beiden Servern ein, nach 24 hrs ist Umstellung fertig und Mails kommen nur noch bei neuem Server rein. Es geht nicht 1 eingehende Mail verloren, weil beide Server annehmen und auch deren A-Records weiterhin stimmen.
Die Kunden verbinden sich weiter mit altem Server. Deshalb wird vorübergehend ein Relay der neuen Mails zum alten Server eingerichtet, damit die Kunden weiterhin die neuen Mails abrufen können.

4)
24 Stunden nach Ausführung Punkt 3)
Relay von neuem nach altem Server abschalten -> ab jetzt bleiben neue Mails auf neuem Server.
Postfächer werden nun in der Nacht per imapsync von alt nach neu verschoben.

5)
Direkt danach: Umstellen des A-Records vom alten hostnamen auf neue IP (da im Mail-Client ja der alte hostname steht und stehen bleibt) -> Kunden fangen an Mails über neuen Server abzurufen und zu versenden.
Nach 24 Stunden: Ende Parallelbetrieb, alter Server geht offline.


Anmerkungen:
1.
Eigentlich kopiert man erstmal die Postfächer auf den neuen Server, stellt dann die Kunden darauf um und relayt die eingehenden Mails von alt nach neu, bevor dann auch der mx-Eintrag umgestellt wird.
Der versteckte Knackpunkt ist bei mir aber, dass MX-Eintrag im DNS und Eintrag von smtp und imap beim Kunden identisch sind, nennen wir ihn mail-alt.blablub.xy
Da ich beim Kunden nichts ändern möchte kann ich den Kunden nur auf den neuen Server kriegen, indem ich den A-Record von mail-alt.blablub.xy auf die IP vom neuen Server umleite. Daraus entsteht aber folgendes Problem:
Wenn ich einfach den A-Record von mail-alt.blablub.xy von alten auf neuen Server umstelle, hat der einliefernde Mailserver Alarm:
Er ermittelt per DNS-Anfrage den FQDN (mail-alt.blablub.xy) des Mailservers und erfragt die IP, kriegt durch die Umstellung aber die IP des neuen Servers. Er kontaktiert den neuen Server und der meldet sich dann aber mit mail-neu.blablub.xy statt mit mail-alt.blablub.xy, wie es im DNS steht.

Also muss ich in meinem Fall andersrum vorgehen und den MX-Eintrag zuerst ändern.
Die Kunden werden dadurch zwar nicht durchgehend mit neuen Mails versorgt, aber immerhin geht nicht 1 Mail verloren oder wird abgelehnt und es kommt auch sonst nicht zu irgendwelchen Fehlern bei Spamschleuder-Prüfung per RDNS-Abfrage oder ähnliches. Afaik ist alles jederzeit RFC-konform, alles andere wäre nicht akzeptabel.

Eure Kommentare zu der Lösung bitte! :-)

[jan10001]

Du verstehst es nicht, du mußt und solltest nicht den MX Eintrag verwenden.
Bisher hast du deinen Kunden gesagt versendet euere Mail über mail.domain.tld und hast mail.domain.tld auch als MX Eintrag gesetzt, das solltest du ändern. Deine Kunden brauchen nicht umbedingt die Domain zu benutzen die als MX Eintrag hinterlegt ist.

Verwendest du als MX Eintrag "mx.domain.tld" dann können deine Kunden trotzdem ihre Mails über "mail.domain.tld" versenden. Der Eintrag "mail.domain.tld" dient in den Mailprogrammen doch nur dafür um die IP des Servers aufzulösen über den versendet wird bew. von dem Emails abgeholt werden.

Der MX Eintrag wird erst benötigt wenn der Server diese eingelieferten Emails versendet:

z.B.
test1.de (MX Eintrag im DNS für diese Domain: mx.mailserver.de)
test4.com (MX Eintrag im DNS für diese Domain: mx.mailserver.de)

Abgehende Mails:
Hier prüft der empfangende Mailserver anhand des MX Eintrages ob dein Mailserver für die Absender test1.de eigentlich zuständig ist.

Ankommende Mails:
Eine Email soll an test@test4.com gesendet werden, hier wird der MX Eintrag benötigt um festzustellen, welcher Mailserver für diese Domain zuständig ist und nimmt dann Kontakt auf zu diesen Mailserver, also mx.mailserver.de.

[coltseavers]

Ja doch, ich versteh schon, deshalb ist ja mein Plan es zu ändern!
Aktuell ist es noch identisch, und nach der Umstellung steht dann im mx-eintrag mail-neu.blablub.xy und beim kunden im client steht aber weiterhin mail-alt.blablub.xy

Abgehende Mails:
Hier prüft der empfangende Mailserver anhand des MX Eintrages ob dein Mailserver für die Absender test1.de eigentlich zuständig ist.

Das ist nur theoretisch richtig und spielt in der Praxis keine Rolle.
Beispiel: Sende-Relay.

Der MX-Eintrag spielt also nur für den Empfang ne Rolle.

[jan10001]

Das ist nur theoretisch richtig und spielt in der Praxis keine Rolle.
Beispiel: Sende-Relay.

Dann schau dir mal einen Mailheader an. ;) Nebenbei prüfen auch diverse SPAM Filter Systeme ob der MX Eintrag passt.

[coltseavers]

Dann schau dir mal einen Mailheader an. ;)

Bei einer E-Mail, die über ein Sende-Relay geschickt wird steht dann "from: mx-eintrag by mail-relay"
Ausliefernder Server ist dann aber das Mail-Relay, und das steht nicht als MX im DNS der Absende-Domain.

Macht ja auch keinen Sinn: müsste ein reines Sende-Relay auch im MX stehen, müsste es ja auch E-Mails für die Domain annehmen - dann wärs aber kein reines Sende-Relay mehr.

Nebenbei prüfen auch diverse SPAM Filter Systeme ob der MX Eintrag passt.

Joa, naja: in erster Linie prüfen sie per Reverse Lookup, ob HELO des einliefernden Servers zur IP passt.
DAS ist das Hauptkriterium, und das muss immer stimmen.
Als Nebenkriterium prüfen einige auch noch den MX-Eintrag, richtig. Da dieser aber bei einem Sende-Mailrelay oder auch bei einer Mail aus einem Webseitenformular gar nicht stimmen kann, fällt dies kaum ins Gewicht. Als einziges KO-Kriterium gilt dies auf keinen Fall.
(siehe: das Postfix-Buch von Peer Heinlein, Seite 229/230)

[ddm3ve]

Joa, naja: in erster Linie prüfen sie per Reverse Lookup, ob HELO des einliefernden Servers zur IP passt.
DAS ist das Hauptkriterium, und das muss immer stimmen.
Als Nebenkriterium prüfen einige auch noch den MX-Eintrag, richtig. Da dieser aber bei einem Sende-Mailrelay oder auch bei einer Mail aus einem Webseitenformular gar nicht stimmen kann, fällt dies kaum ins Gewicht. Als einziges KO-Kriterium gilt dies auf keinen Fall.
(siehe: das Postfix-Buch von Peer Heinlein, Seite 229/230)

Wenn Du den Postfix wie Peer konfiguriert hat stimmt das. Aber wenn man Hinz und Kuntz einen Riegel vorschieben will im SPAM Versandt, dann prüfe ich und policyd_weight auch, den DNS/RDNS sowie MX Eintrag.

Das macht weitere Spamfilter wie Spamassassin ziemlich unnötig.
Die allermeisten Provider, haben Ihre Infrastruktur so gebaut, dass sie über einen validen Mail"cluster" senden.
Sprich die Webscripte die sendmail oder derartiges nutzen, schicken die Emails über eine saubere Mailinfrastruktur.
Das in den seltensten Fällen der "Webserver" selbst sondern immer über einen konfigurierten Mailserver.
Ist bei dir übrigens auch so, lediglich dass der MTA lokal installiert ist.


Soll also heissen, dass sehr wohl geprüft wird, ob der zu versendende Host auch für die Domain zuständig und verantwortlich ist.
Sonst könnte ja einfach mal jeder als Du und würde einfach so durch kommen.

[coltseavers]

Konfigurierst Du also Deine Mailserver so, dass Dir prinzipiell erstmal keiner über ein Sende-Relay was zusenden kann??
Ich hoffe das ist nicht Dein ernst!

eBay z.B. versendet auch über einen ganzen Pool von Mailservern. Im DNS stehen aber nur 3 Server.
Blockst Du Mails von ebay also auch? *gg*

Ich habe diverse Kunden seit 6 Jahren über meinen Server als Sende-Relay laufen.
Meine Kunden können absolut problemlos in die Welt hinaussenden, obwohl mein Server nicht in des Kunden MX-Einträgen auftaucht...
Wäre das, was Du beschrieben hast, gängige Praxis, dürfte das wohl nicht klappen, oder zumindest häufiger mal zu Problemen führen.
Mir ist aber bisher nicht 1 Fall bekannt, wo meines Kunden Mails wegen dieser Konfig nicht durchkamen.

Wie gesagt: man kann den MX-Eintrag ja gerne prüfen, aber führt er nicht zum absendenden Mailserver, sagt das auch nicht wirklich viel aus.
Da sind ein ungültiger HELO oder ein falscher RDNS schon deutlich aussagekräftiger.

[ddm3ve]

Ja ich konfiguriere das in der tat so.
Wenn Du den Email Header von Ebay genauer analysierst stimmt der Absender und der zugehörige MX Eintrag etc. wieder.

Ich habe beim Empfang auch keine Probleme.
Denn eine Analyse der abgelehnten Emails und eine spätere Gegednprüfung zu blacklisten zeigt uns auf, dass wir schon frühzeitig die faulen Eier eliminiert haben.

In über 10 Jahren gab es nur 2 Fälle, in denen
1. die Hausbank eines unserer Kunden die DNS Einträge eigenständig verdaddelt hatte,
2. Ein One Man Hoster seinen Mailserver nicht RFC konform konfiguriert hat.

Dabei orientiere ich mich an einen meiner Kunden mit über 20 MIO Emailkunden.

[coltseavers]

Ja ich konfiguriere das in der tat so.
Wenn Du den Email Header von Ebay genauer analysierst stimmt der Absender und der zugehörige MX Eintrag etc. wieder.

Ich verstehe nicht, was du meinst.
Ich hab grad mal ne Mail von ebay rausgesucht:
Absender ebay@ebay.de
kommt vom Server: mxslcpool24.ebay.com, IP: 66.135.215.90

zu ebay.de finde ich folgende 3 MX-Einträge:
lore.ebay.com 216.113.175.103
data.ebay.com 216.113.172.68
gort.ebay.com 216.113.167.215

Wie kannst Du bzw Dein Server mit diesen 3 MX-Einträgen erkennen, dass mxslcpool24.ebay.com, IP: 66.135.215.90 autorisiert ist Mails von ebay@ebay.de zu senden?

[ddm3ve]

Code: Select all

DomainKey-Signature: a=rsa-sha1; s=dksm28; d=ebay.de; c=nofws; q=dns;
	h=message-id:from:reply-to:to:subject:mime-version:
	content-type:x-ebay-mailtracker:x-ebay-mailversiontracker;
	b=KyEvtQmtMNQztyVY232OpIlsv4zHKPPnhsHRX00vmr2z/jiJ7nuzIvapgdrVsG++n
	avSsT9IoIs7L13adP/psQ==

Es gibt nicht nur einen weg sich zu legitimieren.
http://de.wikipedia.org/wiki/DomainKeys

Für Dich ist das aber erstmal vollständig irrelevant.
Gib dem 1. und 2. Host einen eindeutigen DNS Eintrag und passe den RDNS (PTR) dazu an.
Dann kannst Du Deine Domains unproblematisch und ohne nennenswerte Service Downtime um ziehen.

Alle weiteren Methoden sind für Deine Umgebung und Anwendungsfall irrelevant.