ナレッジベース
以前のメールボックスを持ち込む
いま持っているメールを持ち込める。現在の保管先から書き出したアーカイブでも、アカウントそのものでも、元どおりにスレッド化され、あるべき場所に整理される。
未提供
取り込み機能はまだ一切存在しない。唯一すでに解決している部分はスレッド化である。元のヘッダーを保持したまま取り込まれたメールは、後から届くメールと並んで自動的にスレッド化されるからである。
詳細
- 未提供である。ここには mbox も .eml ファイルもプロバイダーのアーカイブも IMAP アカウントも読むものがなく、取り込みを開始する画面も存在しない。読み取りを担うパーサーはすでに依存関係に含まれており、届くすべてのメッセージに対して動いている。存在しないのは、アーカイブをメッセージに分割してパーサーに渡す部分である。
- スレッド化については新たな作業がまったく不要である。会話はメッセージの References ヘッダーの先頭の値を基準にまとめられ、なければ In-Reply-To、それもなければメッセージ自身の id にフォールバックする。これは他のあらゆるメールシステムが使っている規則なので、この3つのヘッダーを保持した取り込みは、id の対応表も2回目の処理もなしにスレッドを正確に再現する。取り込まれたメールはその後に届くメールと同じ関数を通るため、両者は一緒にスレッド化される。
- 配信経路は再利用できるが、その処理の大半は無効にしなければならない。届いたメッセージは、フィッシングの採点、AI 作成の判定、要約、検索用の埋め込み生成、ファイルのインデックス化を受け、開いているすべてのタブに通知される。8万通の古いメールをこれに通せば、8万回のモデル呼び出しと8万件の通知になる。そのため取り込み機能は、配信経路に5つ目のスイッチを足すのではなく、意図的に静かな受信の前例としてすでに存在する使い捨て受信トレイの経路の隣に置くのがふさわしい。
- 古いメールを受信トレイに入れてはならない。ここでのフォルダーはラベルにすぎないので、8年分のアーカイブを整理することは、INBOX と UNREAD の代わりに ARCHIVE を書くだけのことである。現在それを行うスイッチは、副作用として配信レポートの突き合わせも抑止してしまうため、取り込みはそれを借りるのではなく専用のものを必要とする。日付はメッセージから取られるので、2019年のスレッドは移行した日ではなく2019年として並ぶ。
- 同じ取り込みを2回実行してもメールボックスが二重になってはならない。メッセージはここで生成した id ではなく、メッセージ id と送信者の組で既に重複排除されているため、失敗後の再実行は構造上安全である。これこそが、再開可能な取り込みを可能にしている点である。足りないのはその周辺の記録である。ジョブの記録、カーソル、進捗を確認できる件数、そして取り込めなかったものの一覧である。
- 経路は2つあり、規模は同じではない。すでに手元にあるファイルは、パーサーとキューがあれば足り、それ以外は不要である。どのプロバイダーも要求すればファイルを提供してくれる。稼働中のアカウントをその API 経由で読むには、OAuth クライアント、同意画面、審査、そしてメールボックス全体を読めるだけの広いスコープが必要であり、そのスコープはこの製品が意図的に手放したものである。履歴を持ってここに来るための道はファイルであり、アカウント経由は、どこまでのアクセスを求めるかという別の判断になる。