メールデータの移行。

仕事 PC

　職場のグループウェアとして長年利用しているdesknet's。
　俺がシステム管理をしていた当時よりもサーバを増強しバージョンアップも進んでいるが、メールの操作性は今一つのままだ。メールが主機能ではないのだから専用のメールアプリケーションと比較しても仕方ないが。
　さて自分のアカウントにはメールメッセージと添付ファイル用に2GBのストレージが割り当てられているが、９割近くまで使用した状態で長期間メンテナンスができていなかった。
　これまでの担当業務によっては10年程前のメッセージまで残してあって、いつか削除しなくてはならなかったが後で必要になった時（そんなことあるか？と言われる向きもあると思うが、たまにあるんだこれが…）に困る。それでバックアップは取得したいと思っていたが、時間がかかるのが分かっていたし面倒だったので放置していたのだ。
　で、そろそろ限界だったのでようやく着手。
　
　バックアップ方法はメールメッセージの取り出しとする。
　メッセージを可能なら１件１ファイルに…できれば単にeml形式で取得できればありがたい。これをそのまま保存するか、もしくはWindows上で動作する何らかのメールアプリケーションにインポートする。俺はThunderbirdを使用しているので、こちらにインポート用のメッセージフォルダを使用してここへ全件インポートしてしまう。
　取り出しだけならdesknet'sの正規の操作方法ではWEBメールのダウンロード機能により可能だが、これは一回の操作につき100件までのメッセージを１つの圧縮ファイルに格納してローカルディスクに保存するもので、メッセージ件数が２万件を超えている俺の状態では現実的ではなかったので使わない。
　ではどうやるか。
　desknet'sサーバではサービス公開にIISを使用しているので、言わずと知れたinetpubディレクトリ内には自分自身のユーザ用ファイルが入っているのでこれを直接拝借すればよい。
　ターゲットはデフォルト値による構築なら\\desknet'sサーバ\構築先ストレージ\inetpub\Scripts\dneo\wmldata\1\user\自分のユーザID\maildat\以下のフォルダ内にある拡張子なしのファイル群。これらは単純なemlファイルであり、Windows上ではいずれも拡張子を.emlへ変更すれば各種のメールアプリケーションでメッセージファイルとして使える。
　ところで自分のユーザIDとは何か？。desknet'sユーザは管理者に割り当てられたユーザ名でログインしているが、desknet'sの内部ではユーザ名文字列とは別のユーザIDが使用される。正規の方法で確認することはできないので（分かっている管理者に尋ねれば答えてくれる可能性もあるが）、次の方法で調べておく。
　自分のユーザ名でdesknet'sにログインし、ポータル画面を表示する。
　ブラウザ上でページのソースを表示して、その中に含まれる文字列「name="loginuid"」を検索する。
　当該行の先頭にある「value="XXXX"」のXXXXが自分のユーザID値。
　ターゲットとなるファイル群は拡張子なし。おおむね1,000件程度ごとにフォルダに分割されている。
　それらがあるのを確認したら、フォルダごとで構わないので全て自分用PCのローカルディスク上にコピーする。
　サーバに関する作業はここまで。
　サーバ上で直接ファイルの書き換えを行うわけにはいかないので、後は全て自分のPC上で実施する。
　複数のフォルダに分かれているこれらファイルを適当な一つのフォルダに移す。
　任意のファイルリネームユーティリティ（今回はWinFDのファイル名変更機能を使用した）にて、取得した全ファイルの拡張子を.emlへ変更する。
　これで、自分自身のWEBメール上にある全てのメールメッセージがemlファイルとして取得できたことになる。
　この方法だと残念ながらフォルダ別の分類は失われるが、やる気があるなら分類情報を格納しているSQLiteデータベース（mailindex.db）を見てどうにかすることもできるだろう。
　
　俺はこの後Thunderbirdのインポート用に作成したサブフォルダへemlファイルをドラッグ＆ドロップでインポートした。
　なおThunderbirdではインポート処理等でスクリプトを実行しているが、スクリプトの実行中にタイムアウト判定を行っており、デフォルトでは20秒で「警告：スクリプトの実行に時間がかかっています」を表示して処理を中断してしまう。これは俺のPCでは300件程度のインポートしかできない時間だった。
　これはタイムアウト値を延長することで回避できる。ThunderBirdではツール→オプション→詳細→設定エディタで行う。dom.max_script_run_timeとdom.max_chrome_script_run_timeをそれぞれ900に変更したところ警告表示前に処理が完了できるようになった。
　ただし900秒だと何らかの理由でスクリプトが本当に無限ループに入っても900秒間は無応答になるので、後で既定値もしくは常識的な値に訂正する必要があるだろう。