Exchange IMAP: чому дати листів спотворюються

Імпорт Exchange IMAP і дати ваших листів

Exchange Online надає кожному повідомленню в поштовій скриньці дату, і саме за цією датою Outlook відображає та сортує листи. Для листа, що надходить з інтернету, це момент доставки. Для листа, скопійованого під час міграції, це та дата, яку інструмент міграції надав копії: оригінальну, якщо міграція передає її, або день імпорту, якщо ні.

Саме звідси виникають неправильні дати при імпорті Exchange IMAP. Exchange Online не перезаписує дату, яку йому передають. Але коли інструмент імпорту не передає оригінальну дату кожного листа, копія семирічного повідомлення отримує дату імпорту, ніби його щойно доставили.

Результат? Ви імпортуєте 4000 листів зі старого IMAP-сервера в Exchange Online, і листи показують дату імпорту замість власної. Листи з 2018, 2020, 2023 років датовані сьогоднішнім днем. Ваші користувачі відкривають Outlook у понедільок вранці і бачать стіну повідомлень з однаковою датою.

Як працює майстер міграції Exchange Admin Center

Exchange Admin Center (EAC) містить вбудований майстер міграції для IMAP-імпортів. Це графічний інтерфейс, до якого найчастіше звертаються адміністратори Exchange: ви переходите в Recipients, потім Migration, створюєте нову партію, обираєте "Migrate to Exchange Online", вказуєте IMAP як джерело, завантажуєте CSV-файл з відповідностями поштових скриньок і запускаєте партію.

За лаштунками майстер міграції EAC створює New-MigrationBatch з типом кінцевої точки IMAP. Exchange підключається до вашого джерельного IMAP-сервера, читає кожне повідомлення і записує його в цільову поштову скриньку Exchange Online. На папері все просто.

Але от з чим стикаються адміністратори. Microsoft не документує, як міграція встановлює дату кожної копії, і адміністратори повідомляють, що листи виходять з датою синхронізації замість дати отримання. Outlook, OWA та будь-який інший клієнт, підключений до цієї скриньки, потім використовують саме цю дату для відображення і сортування.

Оригінальний заголовок Date: з 2019 року? Він досі там, похований серед заголовків повідомлення. Але Exchange не використовує його для порядку сортування у вашій папці Вхідні.

Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequest і та сама проблема

Адміністратори, які надають перевагу командному рядку, часто звертаються до New-MailboxImportRequest для імпорту PST-файлів або до New-MigrationBatch з IMAP-кінцевими точками для міграцій між серверами. Очікується, що PowerShell дає більше контролю. І це так, для деяких речей. Але не для дат.

New-MailboxImportRequest імпортує PST-файли в поштові скриньки Exchange Online. PST-файл містить оригінальні позначки часу для кожного повідомлення. Але у команди PowerShell немає параметра, який контролює, яку дату отримує кожен імпортований лист. Прапорця -PreserveDates не існує (і, вірте, адміністратори його шукали).

New-MigrationBatch -SourceEndpoint з кінцевою точкою IMAP працює подібно до майстра EAC, тільки без графічного інтерфейсу. Те саме IMAP-підключення, той самий результат для дат. Команда пропонує параметри для фільтрування за діапазоном дат (-StartAfter, -CompleteAfter) та виключення папок, але жодного, що контролює те, як Exchange обробляє позначку часу вхідного повідомлення.

Точніше, це переважно впливає на дату відображення і порядок сортування. Вміст листа, включно з оригінальним заголовком Date, надходить непошкодженим. Неправильна лише дата, яку отримала копія, і саме вона стоїть за всім, що бачить користувач.

Прямий IMAP-імпорт проти сторонніх інструментів

Чи має значення, чи використовуєте ви рідний IMAP-імпорт Exchange, чи сторонній інструмент, як BitTitan MigrationWiz або CloudM? Коротка відповідь: проблема з датами виникає в обох випадках, але з дещо різних причин.

При рідному IMAP-імпорті Exchange (майстер EAC або PowerShell) сам Exchange підключається до джерельного IMAP-сервера і забирає повідомлення. Те, як він встановлює дату кожної копії, залежить від Microsoft і не документується.

Зі сторонніми інструментами інструмент міграції діє як посередник. Він читає з джерела, можливо перетворює повідомлення, і записує в Exchange Online. Коли інструмент пише через IMAP, Exchange Online зберігає ту дату, яку передає інструмент: якщо інструмент надсилає оригінальну дату кожного листа, копія її зберігає; якщо ні, копія отримує дату міграції. Деякі інструменти також додають власний заголовок Received: під час передачі.

Практична різниця? Заголовки, що залишаються, відрізняються від інструменту до інструменту, тому виправлення не може спиратися на один фіксований шаблон. Основна проблема однакова: показана дата не є оригінальною датою листа.

Чому правила транспорту Exchange Online погіршують ситуацію

От що застає навіть досвідчених адміністраторів Exchange неготовими. В Exchange Online є правила транспорту (тепер у центрі адміністрування вони називаються "правилами потоку пошти"), які можуть спрацьовувати на імпортованих повідомленнях. Якщо у вашій організації є правила, що додають заголовки, дописки або змінюють повідомлення за певних умов, ці правила можуть обробляти й імпортовані листи.

Це означає, що лист з 2020 року може отримати додану дописку в кінці, або X-заголовок, поставлений правилом дотримання вимог, якого не існувало, коли надсилався оригінальний лист. Неправильна дата - найпомітніший симптом, але правила транспорту можуть створювати й інші несподівані зміни.

Чи можна вимкнути правила транспорту під час імпорту? Так, тимчасово. Але більшість адміністраторів не думають про це, бо взагалі не очікують, що транспортний конвеєр обробляє мігровані повідомлення. Коли вони розуміють, що сталося, партія імпорту вже завершена і шкода вже завдана.

Що означають неправильні дати для середовищ Exchange

Середовища Exchange, як правило, є бізнес-середовищами. Юридичні фірми, фінансові установи, медичні організації, державні установи. Це не особисті облікові записи Gmail, де неправильна дата - легка прикрість. Це поштові скриньки, де позначки часу листів мають юридичне і нормативне значення.

Судове утримання в Exchange зберігає листи на основі діапазонів дат. Якщо кожен імпортований лист показує дату імпорту замість оригінальної дати, утримання захоплює неправильний набір повідомлень. Пошук eDiscovery за запитом "усі повідомлення між січнем і березнем 2022 року" не повертає нічого, бо ці листи тепер показують квітень 2026 року.

Політики зберігання мають ту саму проблему. Організація з політикою зберігання на 3 роки може випадково видалити листи, які виглядають так, ніби вони з 2026 року (а отже "нові"), тоді як насправді вони з 2019 року і мають зберігатися. Або навпаки: листи, які мали бути видалені за політикою зберігання, залишаються, бо їхня видима дата виглядає нещодавньою.

Один випадок з кінця 2025 року: MSP мігрував близько 200 поштових скриньок з хостингового провайдера Exchange в Microsoft 365 за допомогою майстра міграції EAC. Через три тижні співробітник клієнта, відповідальний за дотримання вимог, помітив, що квартальні звіти про архівацію листів показують всі архівовані повідомлення з однаковою датою. Увесь архів листів за останні 5 років виглядав так, ніби надійшов за один вівторок у листопаді.

Виправлення дат імпорту Exchange IMAP

Оригінальний заголовок Date: переживає імпорт неушкодженим. Імпорт не змінює оригінальні заголовки RFC 2822 всередині листа. Ця оригінальна дата є опорною точкою для виправлення.

Redate.io підключається до поштової скриньки Exchange Online (кожна людина входить під власним обліковим записом Microsoft), сканує повідомлення з аномаліями дат, спричиненими IMAP-імпортом, і застосовує власний рушій виправлення, який виконує перевірку відповідності RFC, збереження структури повідомлення та цілеспрямовану реконструкцію метаданих. Redate не потрібно знати, який інструмент виконував імпорт: він знаходить листи, чия відображена дата не збігається з оригінальною.

Кожне виправлене повідомлення перевіряється окремо: цілісність вмісту, контрольні суми вкладень, розміщення в папках і зв'язки в розмовах. Оригінали залишаються у видимій папці резервної копії у вашій власній поштовій скриньці, доки ви самі їх не видалите. Якщо щось виглядає не так, повернення до попереднього стану займає один клік.

Чому не виправити це скриптом PowerShell? Бо зрозуміти проблему із заголовком Received - легка частина. Виправити 8000 листів у 50 поштових скриньках без пошкодження підписаних S/MIME повідомлень, без поламки вкладених структур MIME, без спотворення заголовків RFC 2047 з не-ASCII символами і без втрати призначення папок - складна частина. Як перевірити, що кожне окреме виправлене повідомлення у робочому середовищі неушкоджене, що жодне вкладення не втрачено, що жоден ланцюжок розмови не розірваний? Скрипт, що працює на тестовій скриньці з 30 повідомленнями, захлинеться на реальних граничних випадках. Той контракт з вкладенням на 42 МБ і трьома вбудованими зображеннями всередині структури multipart/mixed, обгорнутої в multipart/alternative? Успіхів.

Посібники за платформами

Виправлення дат застосовується на рівні поштової скриньки Exchange Online, але користувачі отримують доступ до своєї пошти через різні клієнти. Кожен з них відображає дати по-своєму:

• Виправлення дат імпорту Exchange IMAP в Outlook
• Виправлення дат імпорту Exchange IMAP в OWA (Outlook на вебі)

Шукаєте ширший контекст щодо проблем з датами Microsoft 365 у різних інструментах міграції? Дивіться повний посібник з виправлення дат листів після міграції Microsoft 365.

IMAP-імпорт Exchange залишив ваші поштові скриньки з неправильними датами? Почніть із безкоштовного сканування, щоб побачити, скільки листів це торкнулося і скільки коштуватиме виправлення, без потреби в кредитній картці.