English
Francais
Deutsch
Espanol
Portugues
Italiano
Nederlands
Dansk
Svenska
Norsk
Suomi
Turkce
Ellinika
Russkij
Polski
Cestina
Ukrajinska
Magyar
Romana
Bulgarski
Hrvatski
Srpski
Slovencina
Slovenscina
Lietuviu
Latviesu
Eesti
日本語
한국어
العربية
Bahasa Indonesia
--syncinternaldatesの約束(そしてなぜ機能しないのか)
imapsyncコマンドを実行しました。ドキュメントを読んで慎重に--syncinternaldatesを含めました。移行が完了し、ログにはすべて転送済み、エラーゼロと表示されます。それからOutlookでメールボックスを開くと、すべてのメールが昨日の日付を表示しています。
これはimapsyncで最もよくあるフラストレーションの1つで、少なくとも2017年からシステム管理者を混乱させてきました。--syncinternaldatesフラグは移行中にIMAP INTERNALDATEを保持するはずです。そして技術的には試みます。しかし「試みる」はこの文において多くを含んでいます。
imapsyncはGilles Lamiralが作成したオープンソースのPerlツールで、その機能において本当に優れています。ほとんどの商用ツールがうらやむレベルの信頼性でIMAP間のメールボックス転送を処理します。しかし日付の保持は完全にはimapsyncの手中にはなく、そこで事態が複雑になります。
IMAP日付が実際にどのように機能するか
すべてのメールには3つの異なる「日付」が関与しており、ほとんどの人(一部のIT管理者を含む)がそれらを混同しています:
- Date:ヘッダー(RFC 2822) - 送信者のメールクライアントがメッセージ作成時に付けた日付。メッセージ本文内に存在し、メールサーバーが変更することはありません。
- Received:ヘッダー - メッセージを処理する各メールサーバーが自身のタイムスタンプ付きで追加します。送信者から受信者への連鎖を形成します。最新のReceived:ヘッダーが一部のメールクライアントが表示に使用するものです。
- INTERNALDATE - メールボックス内のメッセージのソート順を制御するIMAPサーバー側のタイムスタンプ。IMAP APPENDでメッセージが最初に保存されたときに設定されます。
imapsyncがメッセージを移行する際、ソースサーバーから(INTERNALDATEを含めて)読み取り、IMAP APPENDを使って宛先サーバーに書き込みます。--syncinternaldatesフラグはAPPEND中にソースのINTERNALDATEを宛先サーバーに渡すようimapsyncに指示します。
問題は次の点です:宛先サーバーにはその日付を尊重する義務がありません。
宛先サーバーがINTERNALDATEを無視する理由
IMAP仕様(RFC 3501)では、APPENDコマンドで日時が提供された場合、サーバーはそれを使用すべき(SHOULD)としています。RFCの言語で「SHOULD」は「良い理由がない限りそうしてください」を意味します。いくつかの主要なメールプラットフォームは良い理由があると判断しました。
Microsoft 365が最大の問題です。IMAP APPENDでメッセージが到着すると、Exchangeトランスポートパイプラインが現在の日付で新しいReceived:ヘッダーを付け、その配送タイムスタンプに基づいてINTERNALDATEを設定します。imapsyncがどの日付を要求したかは関係ありません。M365サーバーがそれを上書きします。
Google Workspace(Gmail)は異なる動作をしますが、それでも問題を引き起こす可能性があります。GmailのIMAP実装はほとんどの場合APPENDからのINTERNALDATEを尊重しますが、独自のReceived:ヘッダーを追加します。メールボックスを読むメールクライアントが表示にINTERNALDATEよりReceived:ヘッダーを優先する場合(Outlookはまさにそうします)、日付は依然として間違って表示されます。
日付を壊すimapsyncコマンドラインのよくある間違い
--syncinternaldatesの完全な忘れ
フラグはデフォルトで有効になっていません。基本的なimapsync --host1 ソース --host2 宛先 --user1 ユーザー --user2 ユーザーをフラグなしで実行すると、imapsyncは日付の保持を全く試みません。
--syncinternaldatesと--addheaderの併用
一部のガイドでは移行中にカスタムヘッダーを挿入するために--addheaderの使用を推奨しています。ヘッダーを追加するとメッセージを変更することになり、宛先サーバーが「新しい」メッセージとして扱うきっかけになる可能性があります。
--minageと--maxageを日付保持と混同
--minageと--maxageフラグは年齢に基づいて移行するメッセージをフィルタリングします。宛先での日付処理には影響しません。
タイムスタンプのずれを引き起こすSSLネゴシエーション
--ssl1と--ssl2でTLS経由で移行する場合、接続セットアップがレイテンシーを追加します。大規模な移行(50,000通以上)ではこのレイテンシーが蓄積されます。
imapsyncログの読み方:出力が実際に伝えていること
imapsyncは詳細なログを生成しますが、日付に関してはログ出力が誤解を招く可能性があります。
msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07
両方の日付が一致しています。これはimapsyncが正しいINTERNALDATEを宛先に送信したことを意味します。しかし、宛先サーバーがその日付を実際に保存したことは意味しません。imapsyncは要求したことを報告しており、サーバーが受け入れたことではありません。
大規模imapsync移行:日付問題が増殖する場所
imapsyncでの単一メールボックスの移行は日付が壊れると煩わしいものです。しかし数百のメールボックスでimapsyncを実行するMSPやIT部門は、まったく異なるスケールの問題に直面します。
典型的なエンタープライズ移行シナリオを考えてみてください。ZimbraサーバーからMicrosoft 365に200のメールボックスを移動しています。ユーザーのCSVをループするラッパースクリプトを書いて、各ユーザーに対してimapsyncを呼び出します。移行は週末に実行されます。月曜の朝、200のメールボックスに壊れた日付があり、約120万通のメールが移行タイムスタンプを表示しています。
自作の修正とその限界
フォーラムやメーリングリスト(SourceForgeのimapsync-develリストは2026年初頭時点でまだアクティブです)を検索すると、創造的なものから危険なものまでの提案が見つかります。
Perlのワンライナーで宛先サーバーのINTERNALDATEを直接修正することを提案する人もいます。すべてのメッセージをmbox形式にエクスポートし、日付を操作して再インポートすることを推奨する人もいます。imaplibを使ってメッセージのフェッチ、修正、再挿入を行うPythonスクリプトを書いた人もいます。
これらのアプローチはすべて同じ根本的な問題を共有しています。S/MIME署名付きメッセージを署名を壊さずにどう処理しますか。ネストされた境界を持つマルチパートMIME構造は。RFC 2047でエンコードされた非ASCIIヘッダーは。
Redate.ioがimapsyncの日付問題をどう修正するか
元のDate:ヘッダーはimapsync移行後も常に無傷です。imapsyncは生のメッセージを忠実に転送します。表示の問題を引き起こすのは宛先サーバーのメタデータ処理です。その元のヘッダーが修正を可能にします。
Redate.ioはメールボックス(Google Workspace、Microsoft 365、または任意のIMAPサーバー)に直接接続し、日付の異常があるメールをスキャンし、独自のヘッダーチェーン分析と日付再構築パイプラインを通じて的を絞ったメタデータ修正を適用します。
修正された各メールは個別に検証されます:メッセージの整合性、添付ファイルの保持、フォルダ配置、スレッド、ラベル。オリジナルは表示可能なRedate.io - Originalsバックアップフォルダに30日間保管されます。
- Outlookでimapsyncの日付を修正する
- Gmailでimapsyncの日付を修正する
- Microsoft 365でimapsyncの日付を修正する
- Google Workspaceでimapsyncの日付を修正する
Redate.ioは数か月前や数年前に行われた移行にも対応します。Date:ヘッダーには有効期限がなく、問題を修正する能力も同様です。
imapsyncで移行して日付が間違っていますか? 無料スキャンを実行して、影響を受けたメールの正確な数を確認してください。