PDA

Bekijk Volledige Versie : domein verhuizen zonder email onderbreking



zwerfkat
24/10/11, 15:28
Hoe kan ik een domein verhuizen van host bedrijf1 naar host bedrijf2, zonder dat de desbetreffende klant dat merkt aan zijn email? Uit vorige berichten op dit forum maak ik op dat je het beste eerst de MX-records kan wijzigen. Maar stel dat mijn klant zijn pop3 box op vrijdag voor het laatst uitleest, en ik de MX-records zaterdagnacht wijzig, dan zal de mail van zaterdag overdag nog gewoon naar de POP3 box van bedrijf1 gaan. Als de klant dan op maandag opnieuw zijn mail ophaalt, gebeurt dit bij bedrijf2. En hij mist dus zijn email van zaterdag overdag. Nu kan de klant de mail box van bedrijf1 waarschijnlijk nog wel uitlezen via web mail, maar dat probeer ik dus te vermijden. Is er een methode zodat de klant er niets van merkt (wat betreft mail) dat zijn domein verhuisd is? Bij bedrijf1 heb ik een resellerspakket en bij bedrijf 2 heb ik een VPS met root rechten, en ik gebruik op beiden ook DirectAdmin.

Keizer
24/10/11, 15:52
Volgens mij is dit niet haalbaar zonder ingewikkelde set-ups. Ook met een minimale TTL zou het theoretisch mogelijk zijn om een e-mail op de oude server af te leveren terwijl de clients op de nieuwe server hun e-mail controleren. Daarbij moet je dat allemaal wel heel goed timen, want uiteraard moet je die e-mail van server1 naar server2 nog dupliceren.

Als ik jou was zou ik gewoon 's avonds laat de e-mail dupliceren en de DNS records omzetten (eventueel met minimale TTL), om die ochtend er na nog eens met een DirectAdmin e-mail only back-up de op server1 afgeleverde e-mail te verhuizen naar server2. Deze voegt dan alleen e-mails toe die er nog niet op stonden. Nadeel is dat verwijderde e-mails weer terugkomen, maar liever iets meer werk dan te weinig e-mail!

YolkNet
24/10/11, 19:37
Waarom zou je een klant niet informeren dat er 's avonds/nachts onderhoudswerkzaamheden worden uitgevoerd, waarbij het advies is om na 22.00 uur geen mail meer te lezen? Klant is geïnformeerd en jij bent hebt een excuus mocht er toch een mailtje wegvallen.

groenleer
24/10/11, 21:08
Je zou kunnen overwegen om de email wachtwoorden bij Bedrijf1 te resetten en met een speciaal programma de betreffende mailboxen uit te blijven lezen voor een periode van 2 weken. De binnengekomen berichten kun je dan via SMTP opnieuw aanbieden in je VPS. Kost je wat werk, maar is opzich wel te doen. Je kan hiervoor bij bedrijf1 catch-all accounts aanmaken zodat nieuwe adressen die, onverhoopt, op de oude locatie worden afgeleverd niet verloren gaan.

tjvb
25/10/11, 10:06
Een korte ttl, de mail servers op de oude server uit zetten. Migreren, op de nieuwe server de mail server aanzetten.
Als de versturende mail servers nog het oude ip hebben wachten ze en de volgende ronden hebben ze wel het nieuwe ip adres waar de mail wel geaccepteerd wordt.

mind
25/10/11, 10:40
Je kan op de nieuwe smtp server het beste een statische route aanmaken, voor het betreffende domein, naar de oude server. De mail wordt dan via de nieuwe server doorgestuurd naar de oude. Je kan nu de MX records van het domein vooruitlopend op de verhuizing al naar de nieuwe server laten verwijzen.

Als alle mail via de nieuwe server loopt, zet je het domein over en laat je de statische route in de smtp server vervallen.

Dreas
25/10/11, 18:30
De oplossing van mind lijkt me inderdaad het makkelijkst. Als je de mail routering zelf kan controleren zonder afhankelijk te zijn van externe DNS updates dan ben je flexibel in het moment van omzetten en wil je de routering omzetten zodra je ziet dat de POP3 box leeg is op de oude server. Je kan ook de routering tijdelijk via een externe partij laten lopen (bijv MX records naar een free trial van ons, 24 uur later controleer je de oude POP3 box en zodra je ziet dat die leeg is geef je bij ons de nieuwe route door. Daarna zet je de MX records om naar de nieuwe server en verwijder je onze free trial weer).

zwerfkat
28/10/11, 13:21
Je kan op de nieuwe smtp server het beste een statische route aanmaken, voor het betreffende domein, naar de oude server. De mail wordt dan via de nieuwe server doorgestuurd naar de oude. Je kan nu de MX records van het domein vooruitlopend op de verhuizing al naar de nieuwe server laten verwijzen.

Als alle mail via de nieuwe server loopt, zet je het domein over en laat je de statische route in de smtp server vervallen.

Zie het voordeel nog niet zo van deze opzet. Dan blijft toch het probleem bestaan dat de klant eerst zijn pop3 box uitleest op de oude server, daarna wordt er nog nieuwe mail afgeleverd en na het opheffen van de statische route gaat de klant weer zijn POP3 uitlezen en mist dan die laatste nieuwe mail uit zijn oude POP box? Het betreft overigens meerdere POP3 boxen die door verschillende personen op verschillende tijdstippen worden gelezen.

Verder betreft het op de oude server virtuele domeinen met een gemeenschappelijk IP-adres, dus volgens mij lukt het nooit om zo'n route te maken terug naar de oude server, toch?

De methode van tjvb lijkt me het simpelst en het beste werken. Zal eens even wat gaan testen met een ttl van 300 seconde (5 minuten). Kun je trouwens simpelweg de MX-records verwijderen op het oude domein om de mail even in de wacht te zetten?

Dreas
28/10/11, 17:05
Kun je trouwens simpelweg de MX-records verwijderen op het oude domein om de mail even in de wacht te zetten?
Nee, dan gaan mailservers naar het A-record afleveren :) Als die ook niet bestaat dan zullen ze gebounced worden.

marsipulami
28/10/11, 17:20
Niet getest en schiet me zomaar te binnen.

Stel mail box is info@domein.nl

Op de oude server voor mailbox info@domein.nl een forwarder aanmaken naar info@domein.nl(zichzelf dus). de oude server doet ook een dnslookup richting de nieuwe server, evt statisch, alle mail wordt dan ook doorgestuurd naar de nieuwe server en komt ook op de oude. Zodra alle dns records over zijn dan komt de persoon gewoon in zijn nieuwe mailbox met zijn laatste mailtjes.

The-BosS
28/10/11, 17:32
Niet getest en schiet me zomaar te binnen.

Stel mail box is info@domein.nl

Op de oude server voor mailbox info@domein.nl een forwarder aanmaken naar info@domein.nl(zichzelf dus). de oude server doet ook een dnslookup richting de nieuwe server, evt statisch, alle mail wordt dan ook doorgestuurd naar de nieuwe server en komt ook op de oude. Zodra alle dns records over zijn dan komt de persoon gewoon in zijn nieuwe mailbox met zijn laatste mailtjes.

Dat werkt dus niet omdat elke server zijn eigen (lokale dns) nslookup gebruikt en de mail dus lokaal blijft en je nog een loop kan veroorzaken ook je smtp.

even simpel uitgelegd maar hier komt het op neer:


10 echo you got mail from $email
20 if $email = $email goto 10

Dreas
28/10/11, 18:04
Je kan wel een tijdelijke domein alias/mail subdomein toevoegen op de nieuwe server .. en daar naar forwarden.

marsipulami
28/10/11, 18:49
Dat werkt dus niet omdat elke server zijn eigen (lokale dns) nslookup gebruikt en de mail dus lokaal blijft en je nog een loop kan veroorzaken ook je smtp.

even simpel uitgelegd maar hier komt het op neer:


10 echo you got mail from $email
20 if $email = $email goto 10


je hebt gelijk zie ik, maar als je root rechten had, kon je in de dns het domein hard wijzigen . maar lees net dat hij daar alleen resellerrechten heeft.

Flaxe_eu
24/11/11, 13:13
Wij doen het wel eens op deze manier (bv als de klant zijn spul naar een hosting pakket bij ons wilt verhuizen en de tegen partij lastig doet.).

Server 1 = waar je nu bent bent
Server 2 = waar je heen gaat.


Je zorgt dat server 2 al helemaal is ingericht voor het domein.

Op server 2 laat ik een Imap script lopen (perl script wat ik ook heb gevonden) die de imap van server 1 in de gaten houdt (op ip basis) en alles wat daar anders is naar server 2 kopieert. en de klant kan tijdens de verhuizing gewoon netjes mail.domein.ext of wat dan ook blijven gebruiken voor de pop of imap.
script laten we nog 48 uur lopen als de verhuizing voltooid is.

we hebben het al verschillende keren op deze manier gedaan en eigenlijk nog nooit een probleem ondervonden.

Het script is imapsync.pl en heb dat dus ooit gevonden ergens op het web.