Kolme päivämäärää jokaisen sähköpostin sisällä
Jokainen IMAP-palvelimelle tallennettu sähköposti kantaa vähintään kolmea erillistä päivämääräarvoa. Näiden päivien toiminnan ja sähköpostiohjelmien näyttölogiikan ymmärtäminen on avain migraation päivämääräongelmien ymmärtämiseen. Tämä artikkeli on tekninen syvennys IMAP-päivämääräjärjestelmään, suunnattu IT-ylläpitäjille ja kaikille jotka haluavat ymmärtää migraation jälkeisten päivämääräongelmien juurisyyn.
1. RFC 2822 "Date"-otsake
"Date"-otsake on määritelty RFC 2822:ssa (Internet-viestiformaatti). Sen asettaa lähettäjän sähköpostiohjelma viestin kirjoitus- ja lähetyshetkellä. Tämä otsake on osa itse viestisisiltöä, se kulkee viestin mukana eikä sitä koskaan muokata sähköpostipalvelimien toimesta reitillä. Tyypillinen Date-otsake näyttää tältä:
Date: Mon, 15 Jan 2024 09:32:17 +0100
Date-otsake edustaa viestin "lähetyspäivää". Se on luotettavin päivämäärä koska se asetetaan kerran eikä sitä koskaan muuteta.
2. IMAP INTERNALDATE
INTERNALDATE on määritelty RFC 3501:ssa (IMAP4rev1-protokolla). Se on palvelinpuolen metadta-arvo joka edustaa päivää ja kellonaikaa jolloin viesti toimitettiin palvelimelle. Toisin kuin Date-otsake, INTERNALDATE ei ole osa itse sähköpostiviestin. Se tallennetaan erikseen IMAP-palvelimen metatietona.
Ja tässä kohtaa asia menee mielenkiintoiseksi. Kun viesti lisätään IMAP APPEND -komennolla (mitä migraatiotyökalut käyttävät), APPEND-komento antaa asiakkaan määrittää INTERNALDATE:n erikseen. Hyvin suunnitellut migraatiotyökalut käyttävät tätä toimintoa lähdepalvelimen alkuperäisen INTERNALDATE:n säilyttämiseksi. Mutta vaikka INTERNALDATE olisi oikein asetettu, "Received"-otsakeongelma (kuvattu alla) voi silti korvata näytetän päivämäärän monissa asiakkaissa.
3. "Received"-otsakeketju
Joka kerta kun sähköposti kulkee sähköpostipalvelimen läpi, palvelin lisää "Received"-otsakkeen viestin alkuun. Tämä luo "Received"-otsakekentien ketjun joka tallentaa sähköpostin matkan lähettäjältä vastaanottajalle.
Esimerkki siirron jälkeisestä otsakeketjusta:
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Miten sähköpostiohjelmat valitsevat näytettävän päivämäärän
Outlook (työpöytä, verkko, mobiili)
Microsoft Outlook käyttää INTERNALDATE:n ja uusimman "Received"-otsakkeen yhdistelmää "Vastaanotettu"-päivän määrittämiseen. Käytännössä Outlook suosii uusimman "Received"-otsakkeen aikaleimaa "Vastaanotettu"-sarakkeessa. Koska Outlook lajittelee oletuksena "Vastaanotettu"-sarakkeen mukaan, käyttäjät näkevät ensimmäisenä "Received"-otsakkeen aikaleiman.
Apple Mail
Apple Mail macOS:llä ja iOS:llä käyttää ensisijaisesti IMAP INTERNALDATE:a päivämäärän näyttämiseen. Lisätietoja artikkelissa Apple Mail: väärä päivä migraation jälkeen.
Thunderbird
Mozilla Thunderbird tarjoaa eniten joustavuutta. Se voi näyttää sekä "Päivämäärä" (Date-otsakkeesta) että "Vastaanotettu" (Received-otsakkeista). Katso Thunderbird: väärä päivä migraation jälkeen.
Gmailin verkkokäyttöliittymä
Gmailin verkkoliittymä käyttää Date-otsaketta päivämääränäyttöönsä. Gmailin verkkoversio näyttää siis usein oikeita päiviä migraation jälkeenkin. Mutta IMAP INTERNALDATE palvelimella on silti väärä, mikä vaikuttaa jokaiseen IMAP-asiakasohjelmaan joka yhdistää tähän Gmail-tiliin.
Miksi IMAP APPEND rikkoo päivämäärät
Mitä tapahtuu migraation aikana
Kun migraatiotyökalu siirtää sähköpostin Palvelimelta A Palvelimelle B, työkalu yhdistää Palvelimeen A IMAP:n kautta ja lataa raakaviestin, sitten yhdistää Palvelimeen B ja käyttää APPEND-komentoa lisäykseen. Lisäyksen aikana Palvelin B käsittelee saapuvan viestin ja lisää uuden "Received"-otsakkeen nykyisellä aikaleimalla: migraatiopäivällä.
Tulos: kontaminoitunut otsakeketju
Migraatiotyökalun "Received"-otsake on nyt ylin merkintä. Mikä tahansa sähköpostiohjelma joka käyttää uusinta "Received"-otsaketta näyttöpäivän määrittämiseen (erityisesti Outlook) näyttää migraatiopäivän alkuperäisen sijaan.
Hyväkään INTERNALDATE-käsittely ei estä tätä
Jotkut migraatiotyökalut asettavat INTERNALDATE:n oikein APPEND:n aikana. Mutta "Received"-otsakkeen lisää kohdepalvelin, ei migraatiotyökalu. Migraatiotyökalulla ei ole kontrollia tähän käyttäytymiseen.
Mitä asialle voidaan konkreettisesti tehdä?
Mitkä migraatiotyökalut lisäävät "Received"-otsakkeita
Kaikki IMAP-migraatiotyökalut aiheuttavat tämän ongelman koska "Received"-otsakkeen lisää kohdepalvelin, ei työkalu itse.
BitTitan MigrationWiz lisää "Received"-otsakkeen joka sisältää "mx.migrationwiz.com". CloudM Migrate lisää otsakkeita "cloudm.io"-viittauksilla. imapsync käynnistää kohdepalvelimen yleisen "Received"-otsakkeen. GSMMO lisää otsakkeita "gmailapi.google.com"-viittauksilla.
Korjaus: oikeiden päivämäärien palauttaminen
Hyvä uutinen on että oikea päivämäärätieto on edelleen olemassa jokaisessa sähköpostissa. Alkuperäinen Date-otsake on ehi. Alkuperäiset "Received"-otsakkeet ovat ehjiä. Ongelma on että kontaminoiva otsake istuu niiden yläpuolella.
Redate.io:n oma korjausmoottori analysoi jokaisen vaikuttuneen sähköpostin täydellisen otsakeketjun, vertaten tunnisteita satoihin tunnettuihin migraatiotyökaluprofiileihin tunnistaakseen tarkalleen mitkä otsakkeet tarvitsevat korjausta. Monivaiheinen analyysiprosessi käsittelee rajatapaukset: S/MIME-allekirjoitukset, PGP-salaus, multipart/alternative-rakenteet, Content-Transfer-Encoding-ongelmat, ei-ASCII-otsakkeet (RFC 2047) ja vialliset MIME-rajat.
Korjauksen jälkeen jokainen sähköposti käy läpi eheystarkistuksen. Alkuperäiset säilytetään näkyvässä varmuuskopiokansiossa 30 päivää.
Voisi kirjoittaa skriptin tähän itse? Teknisesti kyllä. Mutta ero "toimii 95 %:lla sähköposteista" ja "toimii 100 %:lla korruptoimatta yhtäkään" edustaa kuukausien kehitystyötä. Ja kun puhe on jonkun täydestä postilaatikosta, 5 % epäonnistumisprosentti tarkoittaa satoja hiljaisesti vahingoittuneita viestejä ilman keinoa todentaa mikä meni vikaan.
Haluatko tietää kuinka monessa postilaatikkosi sähköpostissa on väärät päivämäärät? Käynnistä ilmainen analyysi Redate.io:lla välittömän laskennan saamiseksi, ilman maksua.