IMAPメールボックスの危機 (2)

Imapのサーバーのユーザーディレクトリーに保存されているファイルの名前はMIMEではなく、UTF-7だそうです。

で、それを変換するperlスクリプトを作りました。作ったと言っても当該のCPANモジュールを呼び出すだけですが。

ただし、これには罠があって、CPANモジュールのIMAP-UTF-7の説明には間違いがあります。

use Encode qw/encode decode/;

ではなくて、

use Encode::IMAPUTF7;

としないといけません。ずいぶん昔から指摘されているのに、直っていません^^;

スクリプト付けときます。GNU GPL 3.0 or laterっちゅうことで。

#!/usr/bin/perl
# imapdecode.pl
# by I Hieda (JE1SGH), 22 Apr 2016
# GNU GPL 3.0 or later

use Encode::IMAPUTF7;

$filename = @ARGV[0];

$outname=Encode::decode('IMAP-UTF-7',$filename);
binmode(STDOUT,":utf8");

print $filename," : ";
print $outname,"\n";

使い方としては、

 for i in `ls`; do imapdecode.pl $i; done

などとします。

IMAPメールボックスの危機

注意(主に自分宛, 2024/10/30): 当記事執筆当時,IMAPサーバーはUW-IMAPでしたが,その後dovecotに変更したので,当記事の内容は現在は全く意味をなしません.

自分のメールの管理は、昔からIMAPサーバーを立ち上げてやっています。これは個人営業のクラウドのようなもので、サーバーにアクセスできる限り、自宅LANからも外部からも、パソコン、iPhone、iPadなどで保存したメールすべてを同様にアクセスできます。どこからでも同じように閲覧・保存・操作ができるということで、年々メールが溜まっていくわけです。

とは言えメールに関してはパソコンのトラブル、サーバーのトラブルなどで完全消失したことが過去には何度もあり、現在残っている最古のメールは2002年11月です。

人によっては数百通のメールがありますが、文字コードの破損などで、メールボックスの構造が壊れているというか、ほつれつつあるところがあります。

クライアントの種類、接続の状況によって、正常だったり、異常だったりします。と言うことで完全に壊れている、というより「ほつれている」状態です。たぶん、文字コードのハンドリングが完璧でないクライアントでいじったりしたのが、ほつれをひどくしている原因だと思います。

あんまりいじるとさらにひどくなりそうなので、そっとしておくことにしますが、うっかり削除したり、どうしようもないほど回復不能になったフォルダーの回復法をメモっときます。

  1. Thunderbirdを使う。Local Foldersの場所をAccount settingで確認しておく。
  2. バックアップがあることを確認した上で、当該のフォルダーを削除して、Thunderbirdはいったん終了。
  3. 壊れたメールボックス(フォルダー)の場所(path)を特定して、バックアップツール(Time MachineやRetrospect)からそれに対応するファイルを探し出す。
  4. 復活させたいフォルダーのファイル、”フォルダー名”と”フォルダー名.msf”を安全なところに復活させる。
  5. その二つのフォルダーを1でみつけたフォルダーにコピーする。
  6. Thunderbirdを起動して、Local Foldersにある復活させたフォルダーの中身を確認して、IMAPサーバーにコピーする。

不可視フォルダーや、pathなどについては、省略^^; たぶん、解る人にはヒントになると思います(たぶん^^; おそらく^^;; )。

気をつけなければいけないのは、Thunderbirdでフォルダーの中身をぶっ壊した場合、Thunderbirdで同じフォルダーを復活させてもその後の処理はかなり危険と言うことです。

Thunderbirdは、どうも、この件に関してはかなり劣悪です。Apple Mailはまだましですが、バックアップから復活させたメールボックスファイルをインポートする方法が解らないので、今回は使い(使え)ませんでした。

また、GMailにIMAPでいったん上げて、GMailのWeb UIでいじるのは良い具合です。ただし、また、自営のIMAPサーバーに戻す時にトラブったりしますが。

メールクライアントからは、同じフォルダー内にあるというイメージ。IMAPサーバー的には、一つのメールボックスファイルとなっている。

Too Big To Fail

大きければ良いってもんじゃないって事を実感しました.

今回のOpenSSLの史上最悪のセキュリティーホール対策の話です.まあ,私が運営しているサイトなんか,意図的なクラックの対象にはならないと思いますが,そのうちネットをクロールしながら,総当たり的にクラックするツールなりウィルスが発明されて,どんなサイトも攻撃対象になり得ますので,対策を取っておきました.

対策の第一は,OpenSSLのupdateです.ふだんからソースからbuildしてますので,たいした手間ではありませんでした.

そして,サーバーの秘密鍵の更新です.サーバーの秘密鍵が盗まれても何の形跡も残らない,というこで,完全を期すならば,OpenSSLのupdateのあとにこの鍵の更新をすることが推奨されています.

証明書は,私の利用しているところは有効期限が半年なので,5か月内外で更新していますが,秘密鍵そのものは滅多に作り直すものでは無くて,タイムスタンプを見たら,どのサイトのものも2006年作成でした.で,自分のメモにしたがってやってみました.

メモには,キーのサイズを4096にするとあるのですが,前にキーを作ったのは,8年も前ですから,この際8192にしてみました.

私が管理しているサイトでは,httpd(HTTPS)の他,imapd(IMAPS)とsendmail(STARTTLS)がこの秘密鍵とそれぞれの証明書を使用しています.それら3つのサービスの秘密鍵と証明書を更新してデーモンを再起動しました.

httpdに関しては何ら問題がありませんでしたが,IMAP(IMAPS)とSMTP(STARTTLS)で接続できないとか認証エラーがクライアントから出ます.

昨夜から今朝までさんざん悩んで,sendmailをソースから再ビルドしたり,SASLのパスワードを設定し直したりしてみましたが,ちっとも症状は変わりません.ふと思いついて,

sendmail error 8192

で検索したらありました.キーサイズは4096までじゃないとsendmailのSTARTTLSは正常に動作しないようです.この他,IMAPS対応のメールクライアントやデーモン,プラグインでもNGなものがあるようです.

Heartbleed
ただし,HTTPSは正常に機能していましたが,DAVは動かなくなっていました.