IMAP-synkronisering og MX-skiftet

Modul 8: Flytning og styr på dit domæne · Læsetid: 12 minutter

Læringsmål: Efter denne lektion kan du kopiere mailbokse med en IMAP-synkronisering, gennemføre MX-skiftet og med DNS-opslag kontrollere at ny mail kommer ind det rigtige sted.

Nøglebegreber: IMAP-synkronisering (imapsync), kilde og mål, koble mapper sammen (Sent/Sendt), første og anden runde, undgå dubletter, Message-ID, kvote og store vedhæftninger, MX-ændring, TTL og caches, overgangsperiode, nå den gamle server midlertidigt via servernavn, omstille enheder, mail.<domæne> peger allerede på den nye server

Sådan virker en IMAP-synkronisering

En IMAP-synkronisering er et program der logger ind på to mailbokse samtidig: kilden (den gamle mailboks) og målet (den nye). Det læser listen over mapper i kilden, opretter de samme mapper i målet, og kopierer for hver mappe alle beskeder der mangler i målet. Det mest kendte program er imapsync, et open source-program som mange udbydere bruger bag deres migreringsværktøj.

Vigtigt at vide:

Der kopieres, ikke flyttes. I kilden ændres der ikke noget. Derfor kan du roligt kopiere, mens den gamle mailboks fortsat fungerer.
En anden runde springer det der allerede findes over. Programmet genkender beskeder der allerede ligger i målet, som regel på headeren Message-ID plus nogle andre headere. Derfor kan du synkronisere lige så ofte du vil uden at få dubletter.
Flag følger med: læst, besvaret, markeret. Derfor ser den nye mailboks ud på samme måde.
Målet skal være stort nok. Stopper synkroniseringen midtvejs, er den nye mailboks ofte fuld. Udvid kvoten og start igen: den fortsætter hvor den slap.

Koble mapper sammen: Sendt er ikke altid Sendt

Hver udbyder kalder de særlige mapper noget forskelligt. Hos den ene hedder mappen med afsendt mail Sent, hos den anden Sent Items, Sendt post eller INBOX.Sent. Gmail har ikke rigtige mapper, men labels, og viser dem via IMAP som mapper, fx [Gmail]/Sendt post og [Gmail]/Alle beskeder.

Uden sammenkobling får du i den nye mailboks en mappe Sent Items ved siden af din egen mappe Sendt, og dit mailprogram bruger kun en af de to (lektion 3.1). Gode migreringsværktøjer kobler de særlige mapper sammen automatisk; imapsync har indstillingen --automap til det, og med --regextrans2 kan du selv omdanne navne. Tjek efter den første runde om din afsendte mail ligger i den rigtige mappe.

To ting at være opmærksom på ved Gmail:

Alle beskeder ([Gmail]/All Mail) indeholder al mail, også alt det der ligger i andre labels. Kopierer du den mappe med, får du alt dobbelt. Spring den som regel over, medmindre du har mail der kun er arkiveret.
En besked med tre labels ligger via IMAP i tre mapper, og bliver altså kopieret tre gange. Det er meningen, men det tæller med i din lagerplads.

Mapper med kalenderaftaler eller kontaktpersoner (hos Microsoft 365 og Exchange ses de somme tider også via IMAP) kan ikke kopieres som mail. Et godt værktøj springer dem over og giver besked om det.

Den første runde

Start den første runde god tid før MX-skiftet, når de nye mailbokse står klar. Du skal bruge for hver mailboks:

IMAP-serveren for kilden (fx imap.mailprovider.example, eller servernavnet på din gamle hostingpakke);
adressen og adgangskoden (eller app-adgangskode, eller et Microsoft-login, lektion 8.1) for kilden;
adressen og adgangskoden for målet, samt servernavnet hos den nye udbyder.

En faldgrube: er din gamle IMAP-server sat op som mail.example.com, og har du allerede flyttet DNS'en? Så peger mail.example.com måske allerede på den nye server, og programmet kopierer så fra den nye til den nye mailboks. Brug derfor det faste servernavn fra din gamle udbyder som kilde (det står i din gamle velkomstmail eller kundepanel), ikke et navn under dit eget domæne.

Store mailbokse med mange vedhæftninger tager lang tid: regn med timer for mange gigabyte. Lad programmet bare køre; de fleste værktøjer fortsætter efter en afbrydelse, hvor de slap.

MX-skiftet

Er mailboksene kopieret, og står records for SPF, DKIM og DMARC klar (lektion 8.1, trin 3)? Så ændrer du MX-records til de værdier den nye udbyder oplyser. Derefter:

Kontrollér hos den autoritative navneserver om den nye MX står der. Det ser du med det samme, uden cache:

$ dig +short NS example.com
ns1.dns.example.
ns2.dns.example.
$ dig +norecurse MX example.com @ns1.dns.example.
;; ANSWER SECTION:
example.com.     300   IN   MX   10 mx1.newprovider.example.
example.com.     300   IN   MX   20 mx2.newprovider.example.

Kontrollér hos en offentlig resolver hvad resten af internettet ser. Får du der stadig den gamle værdi, så har den resolver den stadig i sin cache indtil TTL'en udløber:

$ dig MX example.com @9.9.9.9
example.com.     212   IN   MX   10 mx.oldprovider.example.

Tallet (212) er den resterende tid i sekunder. Efter den tid spørger resolveren igen.

Send en testmail fra en adresse uden for dit domæne (fx en gratis maildienst, eller fra din telefon via mobildata) og se om den kommer frem i den nye mailboks. I headerne (lektion 1.5) kan du i de øverste Received-linjer se hvilken server den kom ind via.

Overgangsperioden

I overgangsperioden kommer der nogle gange stadig mail ind på den gamle server: fra afsendere hvis resolver stadig kender den gamle MX, og fra servere der havde en besked i deres kø til den gamle server. Det er ikke et problem, så længe den gamle mailboks stadig findes. To måder at undgå at miste noget på:

Anden synkroniseringsrunde en dag efter skiftet (eller senere, afhængigt af den gamle TTL). Den tager kun de nye beskeder med. Ved en domæneflytning med skift af navneserver er det klogt at køre endnu en runde efter to eller tre dage.
Eller begge mailbokse midlertidigt i dit mailprogram, hvor den gamle sættes op med det faste servernavn fra den gamle udbyder. Sådan ser du straks om der er noget der er blevet tilbage.

Mail du sender i denne periode, går via den udgående server der er sat op på din enhed. Sørg for at SPF i denne periode indeholder begge udbydere, ellers kan din mail score dårligere hos modtageren, fordi den går via den "forkerte" server.

Omstilling af enheder

Sæt på hver enhed den nye mailboks op som en ny konto med IMAP og oplysningerne fra den nye udbyder (modul 2). Fjern derefter den gamle konto. Hvorfor ikke bare ændre den eksisterende konto? Fordi programmet så somme tider prøver at synkronisere den gamle lokale kopi med den nye mailboks, hvilket kan give dubletter eller forsvundne mapper.

Glem ikke:

Fjern gamle konti hurtigt. En telefon i en skuffe der hele tiden prøver at logge ind med en gammel adgangskode, kan hos den gamle eller den nye udbyder forårsage en midlertidig IP-blokering (lektion 3.4). Så virker der pludselig ikke noget på det netværk.
Alt der sender mail via SMTP: hjemmeside, webshop, scanner, kassesystem (lektion 8.1).
Signaturer, regler og autosvar sættes op igen.

Opsig først bagefter

Opsig først de gamle mailbokse, når alt har fungeret godt i et par uger, og den sidste synkroniseringsrunde er kørt. Ryd derefter op i DNS'en: fjern den gamle udbyder fra SPF, fjern den gamle DKIM-selector, sæt TTL tilbage til en normal værdi.

I praksis: sådan ser det ud hos en udbyder

Hos WebOké kan du kopiere med e-mailflytteværktøjet i Mit WebOké (vælger selv servernavnet hos kendte udbydere, logger også ind hos Microsoft og fortsætter efter en afbrydelse) eller med IMAPSync-migreringer i DirectAdmin (udfyld kilde-host, bruger og adgangskode, vælg målmailboks). En anden runde springer i begge tilfælde det der allerede er kopieret over. Andre udbydere har tilsvarende migreringshjælp; begreberne kilde, mål og anden runde er de samme overalt.

Opsummering

En IMAP-synkronisering kopierer for hver mappe det der mangler i målet; en anden runde skaber ikke dubletter.
Koble særlige mapper sammen (Sendt, Papirkurv), og vær hos Gmail opmærksom på labels og Alle beskeder.
Brug det faste servernavn fra den gamle udbyder som kilde, ikke mail.<dit domæne>.
Efter MX-skiftet: kontrollér først autoritativt, derefter offentligt (TTL), derefter en testmail udefra.
Anden runde efter den gamle TTL, sæt enheder op som ny konto, fjern gamle konti, opsig først efter flere uger.

Quiz

Opgave

Opgave Z8.2: MX og TTL kontrollere omkring skiftet. Indtast dit eget domæne (eller brug wikipedia.org, hvis du ikke har et eget domæne). Udfyld: MX-hosten med den laveste prioritet ifølge den autoritative navneserver, TTL'en for MX-recorden hos den navneserver, og hvem din mail kommer ind hos (fri tekst). Programmet slår NS op, derefter MX hos en autoritativ navneserver uden cache, og MX hos en offentlig resolver. Det stiller svarene ved siden af hinanden og giver besked, hvis den offentlige resolver stadig giver et andet svar (så er skiftet endnu ikke synligt overalt).

Videre læsning

Trinnene i disse artikler gælder for panelerne hos WebOké; hos andre udbydere fungerer det på lignende måde.

Cookies hos WebOké

Cookieindstillinger

Nødvendige

Marketing