さて、個人的には「とっととしてくれ」と思っていた「ドコモメール」の提供開始。SPモード（というよりはSPモードメールの端末側ソフト）のダメ仕様が多少マシになるのではと期待していたのだが、当初予定ではとっくに始まっている筈が、延びに延びて10月という話に。

　＃つかこの調子だと年内すら怪しい気がする。

　ということで、いい加減SPモードの呪縛から逃れようと、多少なりとも話が通じそうな人間にはgmailへのアドレス変更通知を送っているのだ、が。
　問題は過去メール。何だかんだでバックアップもされないまま端末に溜まっております。これはマズい。
　ということで、この「SPモードのメールをgmailに移行する」という作業をしたのだが、Thunderbirdの思わぬ罠に引っかかってトンでもない目に遭ったので、取り敢えずメモ。

　◇

　まず、大まかな作業の流れ。

　1.SPモードからメールをeml形式でSDカードへExportする。
　2.SDカード上のファイルを何らかの方法でPCにCopyする。
　3.ThunderbirdでGmailに接続し、IMAP経由でImportする。

　Thunderbirdがいつの間にかeml形式を読み込めるようになったので非常にシンプルな行程で出来るようになってます。
　・・・が、そこに罠があったのであり。

　結論から言うと、Thunderbirdのeml読込にはimapフォルダと組み合わされた場合に発動する、結構イヤな感じのバグが残っている。但し操作方法を一工夫すればバグ回避が可能。
　その一工夫とは、以下の通り。

　「まずemlファイルをローカルフォルダにImportし、次にローカルフォルダの中身をIMAPフォルダにCopyする」

　これで日時表示の問題等もなくemlファイル群をGmailにImport出来ましたとさ。

　♯ちなみに当方がこの「一工夫」を見つけるまで約3時間、但し2時間以上「emlファイルのヘッダを弄ったらどうにかならんのか」と試していたのであり。そちらの結論は「ヘッダ弄りではどうにもならん」ということで。

　◇

　以下、詳細。

　「Thunderbirdのeml読込にはIMAPフォルダと組み合わされた場合に発動する」症状は2つで、

　・IMAPのローカルキャッシュが壊れる
　・Thunderbird内部に保持されるメールの受信日時がImport作業をした日時になる

　これどちらも結構イヤな感じ。

　前者はmboxファイルが壊れるにも関わらずThunderbird側には検出されないため、メールの本文表示が壊れるだけでなく、運が悪いとIMAPサーバ＝Gmailと同期すらしなくなってしまう。
　対処はmboxを手動で削除して、再度全DLして作り直すしかない。

　後者は「このままIMAPサーバにメールをImportするとメール一覧画面で表示される日時が狂う」という最悪の状況が発生する。
　もともとThunderbirdの開発にはgoogleが絡んでいるので「ThunderbirdでIMAPを使えばGmailへImportしても日時が狂わない」というのはThunderbirdの初期のウリの一つだったのだが、このウリが完全に吹っ飛んでしまっている。

　ところがこの2つの症状、発生するのは「外部からemlを直接IMAPフォルダに読み込ませた場合」という極めて限定的な状況のみ。
　試しにローカルフォルダにemlをImportしてみると問題はないし、既にデータの存在するIMAPフォルダの内容を別のIMAPフォルダ下にコピーしてもこれまた全く問題無い。
　なので、取り敢えずローカルフォルダにImportしてから作業をすれば全て解決。

　にしても、OSSとしては開発者数に恵まれているThunderbirdでこんな分かり易い症状の出るバグが残っているとは。
　IMAPフォルダへのeml直接投入なんて操作は普通やらん、てことなのかね？

　恐らく一番スマートでない方法を取ってしまったというメモ。

　一言でまとめ：常時稼働している環境にPOP-SSL proxyを仕込む。

　・・・さすがにあんまりなのでもう少しだけ補足。
　一番メジャーなPOP-SSL proxyはstunnelではないかと。Windows版もありまっせ。

　◇

　ここからは普通に文章。

　個人的な気分の問題かも知れないが、そもそもこのテの「ネット対応」「メール対応」を謳っている家電に、自分の普段使いのメールアドレスを設定するのはどうにも気が引ける。
　一応この「気分の問題」にも根拠はあって、

　１・パスワードを設定をするのがイヤ

　一番の問題がコレ。
　手元のRDの他、「ネット対応」「メール対応」を謳っている家電で、over SSL等の暗号化に対応しているというブツはお目にかかったことがない。
　ということは、一度パスワードを設定したが最後、コレをナマで数十分毎に垂れ流すという世にも恐ろしい状況に。何ですかこの盗聴大歓迎設定。

　更に、内部にパスワードを保持するということは。
　故障した時・廃棄の時・中古売却の時、不注意もしくは諸事情により消去し忘れると、第三者にパスワード含めてアカウント情報がだだ漏れに。
　それが普段使いのメールアドレスだったらこれ、ホントに致命的でっせ。

　２・アドレス設定とかがイヤ

　上に書いたアカウント情報だだ漏れの危険性も高いが、何より日常的にもっと大きなコトが。
　家電の場合、メールサーバへの接続設定がはっきり言って面倒なことが多いんですわ。そんな面倒なコト何度もやってられますかい。

　３・機械用メールと人間用メールがが混ざるのがイヤ

　人間用は人間のルールで整理したい一方で、機械用メールは大抵そんなことお構いなしで、ヘタに触るとそれが原因で動かなくなったりする。
　何で人間が機械に合わせなあかんのよ。

　・・・とまあ、この3段ぐらいで。

　以上の問題を解決するには「機械用のメールアドレスを作ればいい」という結論に達します、はい。

　とはいえ追加でカネを払うのも何だかな～という方、フリーメールを探してみましょ。
　一昔前と違って、タダでも今ではPOPが使えるモノも結構ありまっせ。

　具体的にはGmailとGmail OEM系（livedoor mail等）、Windows Live Mail等。
　まあどれかのアカウントを使ったとして、話を進めますね。

　問題はこの後。
　GmailやWindows Live MailではPOP over SSLが必須。まあパスワード垂れ流し防止ということで正しい対応だと思うが、こうなるとRDからは繋がらない。
　さてどうする。

　ここで登場するのが、手元で常時稼働しているサーバ。
　このサーバ上でPOP-SSL proxy、要するに、生POPをSSLで中継してくれるプログラムを動かして、RD→手元サーバ→メールサーバという経路を確立する、と。

　当方の場合、手元にほぼ常時稼働中のWindows機があるので、コレにstunnelを放り込んで設定しましたよ、と。
　設定さえミスらなければ後は放っておけるので、特に難しいこともない。

　＃このWindows機のFirewallに穴を開けるのを当初忘れていて、RDからのPOP接続が全然来ない・・・と首傾げまくったり（ぉ。

　◇

　・・・結局、なんだかんだで手元に常時稼働サーバが必要というのが、全くスマートでないのだが。
　一応これで「普段使いとは別のメールアドレスを予約用に使う」という当初の目的は達しました、とさ。

　さて、以前「メール環境どうしよう」とウダウダと書いていたネタですが。
　結局ローカルでの統合は諦め、Gmail側に旧メールをまとめてインポートすることにしましたよ。
　ローカルでのIMAPやPOPはあくまでバックアップという感覚で、オンラインをメインに使おうといういうことですな。

　＃にしても、不便極まりなかった「Webメール」の時代を知っている人間にとっちゃ、Gmailなんてまぁ（以下略。

　ということで、以下作業記録。
　理屈は簡単だが、実際の作業は割と手間がかかるんだ、コレが。

　ちなみに以下の方法はWeMailに限らず、MH形式orそれに近い形式でメールを保持している全てのMUAで使えるテです、はい。

　◇その1、正しいMH形式に整形する。

　まず、WeMailのメール保存形式。
　.wemという拡張子が付いていますが、これ要するにMH形式というヤツです。1メール1ファイル形式。
　何故か未だにあちこちで使われてるmbox形式と比べて、圧倒的に分かり易く汎用性も高いフォーマット。

　このため、拡張子の.wemを全て引っぺがして数字だけのファイルにすれば、Sylpheedをはじめ、大抵のMAUでざくっと取り込めます、はい。
　まあ、一部ヘッダの文字コード絡みで問題が発生することも時々あるけど。

　但し問題なのが、フォルダ構成。
　大抵の人は階層管理していると思うのだが、インポート用にはこれをフラットにしないといけない。これ当然、ファイル名が衝突しますわな。
　仕方ないので検索等を駆使して一カ所にまとめ、その後はお好きな連番改名ツールを使って通し番号に変更しますよ。タイムスタンプを見てくれるヤツだとちょっと嬉しい。

　＃お気に入りの心当たりが無ければFlexible Renamerなんていかが。

　◇その2、mbox形式に変換する。

　次に、これらのメールをmboxに変換。面倒なのでIMAP用に日常使っているSylpheedにお任せ。

　何故こんなことをするのかというと、SylpheedのIMAPで直接Gmailにアップロードすると、タイムスタンプがアップロードしたタイミングに書き換わってしまって、とても悲しいことになるんですな。
　ところがThunderbirdのIMAP経由ではこの問題が発生しないため、わざわざThunderbirdが読み込める形式に変更してやる。と。

　◇その3、mboxの中身をアップロードする。

　出来上がったものをThunderbirdに読み込ませましょ。
　インポートしてもいいが、簡単なのはユーザープロファイルの所にあるメールボックスの場所にmboxファイルを置いてからThunderbirdを起動する方法。
　こうすると、勝手にmboxを読み込んでメール一覧に表示されます、はい。

　後はIMAPのお約束。ローカルでメールの束をどかっと移動すると、するするするっとGmail側にアップロードされて、はい出来上がり。

　ちなみに文字コードがS-JISなメールはThunderbirdにImportすると激しく文字化けすることが多いが、ほぼ確実にアップロード自体に問題は起こらないし、GMail上からもきちっと正しく読めるので、特に気にする必要はありません、えぇ。

　但し、ThunderbirdのIMAPは正直Sylpheedと比べて圧倒的に遅い。
　Sylpheedの軽快さに慣れてる人はウズウズしながら待つハメになりますな。

　・・・以上。
　結局5000通、100MBばかりアップロードしましたとさ。

　取り敢えずアップロード直後にSylpheedでローカルキャッシュと同期しておいたし、まあこれで大丈夫だと思う、うん。

　さて、googleネタが続きますが。
　本日のターゲットは、Google SitesのImport／Export Tool。

　＞http://code.google.com/p/google-sites-liberation/

　これ何かというと、Google Sitesのバックアップ（Export）とリストア（Import）が出来るというシロモノ。
　Google SitesのAPIを使うサンプルプログラムという位置づけでもあり。
　jarなので、Java Runtimeが導入されている環境で試してみてね、と。
　現状、1.01になっております。

　まず、ダウンロード（Export）は、小規模サイトであれば特別問題は無いですな。
　1,0の頃に問題があったらしい、日本語文字コードの問題も解消されている模様。
　そもそもgoogle sitesで使っているcssが無いとレイアウトがガタガタになるという問題はあるものの、一応全てのサイト内容、添付ファイル等はダウンロード可能。

　但し、ある程度の大きさのあるサイトではまともにDL出来ないという話が英語圏ではあちこちに出てきているので、現状ではホントに全部DL出来ているかの確認が必須の模様。

　一方で、アップロード（Import）は・・・ダメですな。どう頑張っても全くImport出来ない。

　こちらでは、ディレクトリ構造は再現されるが、ファイルは一つもアップロードされないという状態。

　・・・ん～、まだまだですか。
　取り敢えず、全くアップロードが出来ないというのはさすがにどうかと。

＃全く関係無いが・・・
　ブラウザのキャッシュやCookieが壊れたり不整合起こしたりすると、Google Sitesって結構意外な、というか割ととんでもない挙動することがあるのね。
　何か挙動がヘンだな～と思ったら、取り敢えずCookieとCacheを全消去は基本、ということで。