RDの予約をGmailから拾うために。
恐らく一番スマートでない方法を取ってしまったというメモ。
一言でまとめ：常時稼働している環境に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接続が全然来ない・・・と首傾げまくったり（ぉ。
◇
・・・結局、なんだかんだで手元に常時稼働サーバが必要というのが、全くスマートでないのだが。
一応これで「普段使いとは別のメールアドレスを予約用に使う」という当初の目的は達しました、とさ。
Tags: Google Apps
結局Google Apps側にメール統合ですか。
さて、以前「メール環境どうしよう」とウダウダと書いていたネタですが。
結局ローカルでの統合は諦め、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でローカルキャッシュと同期しておいたし、まあこれで大丈夫だと思う、うん。
Tags: Google Apps
Google Sites Liberation を試してみる。
さて、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を全消去は基本、ということで。
Tags: Google Apps
続・Google Sites のちょっとしたワナ（訂正有）。
本日は、昨日のGoogle Sitesネタの続編。
Google Apps for DomainsのGoogle Sitesの、何だかビミョーな仕様について。
要約すると「消滅済のCategory名やSite名がdashboardに残りっぱなしになる」というネタですが。
結論から言うと、
ある程度時間が経つといつの間にか消える
らしい。
ある程度、の時間単位はウン週間。数時間や数日という単位ではない。
ついでに、消える迄の時間は一定ではなく、タイミングも不明。
その上、順不同。昔削除した分から必ず先に消える、ということでもないらしい。
・・・う～ん。
明示的に作業しなくてもそのうち消えてくれるからいいだろ、というのが多分Google側の発想なんだろうなぁ。
な～んか釈然としないが、まあ確かに表示されっぱなしでも実害があるか、と言われると特別そんなのも無いし。
にしても、この辺りの件について、英語版Helpを含めて一切情報が無いってのは。
皆さん、気にしてないのかな？
Tags: Google Apps
Google Sites のちょっとしたワナ。
Google Apps for DomainsのGoogle Sites、何だかビミョーな仕様というかバグというか。
サイトが無くなったカテゴリが、現状削除出来ない模様。
具体的には、↓のURLで出てくるDashborad上の表示ね。
https://sites.google.com/a/[ドメイン名]/sites/system/app/pages/meta/dashboard/categories
参照はコレ。
deleting wrong popular categories
＞http://www.google.com/support/forum/p/sites/thread?tid=6a26d4c49292149f&hl=en
現時点では、カテゴリを削除する方法は無いらしい。
つまり、からっぽカテゴリがずっと残りっぱなし、ということらしい。
ちなみに現状手元では、カテゴリが削除出来ないどころか、削除済のサイトが未だにカテゴリの横に「(1)」とか存在することになっているのですが。
・・・割とカッコ悪いよ、コレ。
この他にも、現状Dashboardには12コ以上のカテゴリが表示されない、特定状況で表示自体がバグる、等の問題が報告されている模様。
・・・ん～、まだまだ未完成、ってことですかね。
Tags: Google Apps
