IMAP INTERNALDATE: miksi päivämäärät hajoavat

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 viestisisältöä, 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. Se kuitenkin perustuu lähettäjän laitteen kelloon, joka voi olla väärin asetettu. Harvinaisissa tapauksissa Date-otsake voi puuttua kokonaan, erityisesti automaattisissa järjestelmäilmoituksissa tai vioittuneissa viesteissä.

2. IMAP INTERNALDATE

INTERNALDATE on määritelty RFC 3501:ssa (IMAP4rev1-protokolla). Se on palvelinpuolen metatietoarvo, joka edustaa päivää ja kellonaikaa, jolloin viesti toimitettiin palvelimelle. Toisin kuin Date-otsake, INTERNALDATE ei ole osa itse sähköpostiviestiä. Se tallennetaan erikseen IMAP-palvelimen metatietona.

Kun sähköposti toimitetaan normaalisti (eikä migroida), IMAP-palvelin asettaa INTERNALDATE:n nykyiseen aikaan toimitushetkellä. Tämä vastaa läheisesti Date-otsaketta, tyypillisesti muutaman sekunnin tai minuutin sisällä. Sähköpostiohjelmat käyttävät usein INTERNALDATE:a "vastaanottopäivänä", koska se kertoo, milloin palvelin todella vastaanotti viestin.

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 asiakasohjelman 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äytettävän päivämäärän monissa sähköpostiohjelmissa.

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"-otsakkeiden ketjun, joka tallentaa sähköpostin matkan lähettäjältä vastaanottajalle. Uusin (ylimmäinen) "Received"-otsake näyttää viimeisen viestiä käsitelleen palvelimen, ja vanhin (alimmainen) näyttää ensimmäisen.

Normaalissa sähköpostissa voi olla 3-6 "Received"-otsaketta, jotka dokumentoivat matkan lähettäjän lähtevältä palvelimelta mahdollisten välityspalvelimien kautta vastaanottajan saapuvalle palvelimelle. Jokaisessa "Received"-otsakkeessa on aikaleima. Yksinkertaistettu esimerkki:

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
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100

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. "Lähetetty"-sarake käyttää Date-otsaketta. 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. Jos INTERNALDATE säilyi oikein migraation aikana, Apple Mail voi näyttää oikean päivän, mutta vain jos INTERNALDATE asetettiin nimenomaisesti APPEND-toiminnon aikana. Jos migraatiotyökalu ei asettanut INTERNALDATE:a, palvelin käyttää oletuksena lisäysaikaa, eli migraatiopäivää. 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). Oletuksena Thunderbird näyttää Date-otsakkeen arvon, mikä tarkoittaa, että päivämäärät voivat näyttää oikealta Thunderbirdissä, vaikka ne olisivat väärin Outlookissa. Thunderbirdin "Vastaanotettu"-sarake näyttää siitä huolimatta migraatiopäivän. Katso Thunderbird: väärä päivä migraation jälkeen lisätietoja varten.

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. Ero Gmailin verkkoversion ja Outlookin tai Apple Mailin välillä on yleinen sekaannuksen lähde, ja se kuluttaa turhaan paljon ylläpitäjän aikaa vianetsintään.

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ä. Palvelin käsittelee jokaisen APPEND-komennon uutena viestin toimituksena.

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. Alkuperäinen Date-otsake ja alkuperäiset Received-otsakkeet ovat edelleen tallella niiden alapuolella, mutta ne eivät enää ole siinä asemassa, jota sähköpostiohjelmat priorisoivat.

Hyväkään INTERNALDATE-käsittely ei estä tätä

Jotkut migraatiotyökalut asettavat INTERNALDATE:n oikein APPEND:n aikana. Esimerkiksi imapsync säilyttää nimenomaisesti lähdepalvelimen INTERNALDATE:n. Mutta "Received"-otsakkeen lisää kohdepalvelin, ei migraatiotyökalu. Migraatiotyökalulla ei ole kontrollia tähän käyttäytymiseen. Vaikka INTERNALDATE säilyisi täysin oikein, ylin "Received"-otsake sisältää edelleen migraatiopäivän, ja esimerkiksi Outlook näyttää siitä huolimatta väärän päivän.

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. Lisätyn otsakkeen sisältö vaihtelee työkalun ja palvelimen mukaan.

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 ehjä. 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 ja tunnistaa päivämäärien poikkeamien perusteella tarkalleen, mitkä otsakkeet tarvitsevat korjausta, riippumatta käytetystä migraatiotyökalusta. Monivaiheinen analyysiprosessi käsittelee rajatapaukset: S/MIME-allekirjoitukset, PGP-salaus, multipart/alternative-rakenteet, Content-Transfer-Encoding-ongelmat, ei-ASCII-otsakkeet (RFC 2047), ylisuuret liitteet ja vialliset MIME-rajat.

Korjauksen jälkeen jokainen sähköposti käy läpi eheystarkistuksen, jossa varmistetaan, että viestin rakenne, sisältö ja liitteet säilyvät täysin muuttumattomina. Alkuperäiset säilytetään näkyvässä varmuuskopiokansiossa, kunnes asiakas poistaa ne.

Voiko tällaista yrittää itse skriptillä? 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 saadaksesi välittömän laskennan vaikutuksen alaisista sähköposteista, ilman maksua.