古いメールの回復

条件がいろいろ違う

発掘した場所,元の時代などによっていろいろメールファイルの形態(ヘッダーに含まれる情報や型式,文字コード等)が違いますので,なかなか一筋縄ではいきません.

一応,昔の発掘したメールファイルの回復方法を書いときます.最終的には手作業で,メールヘッダー部分を修正する必要があることが多いです.

取り出して一通ずつ切り分ける

まず,何とかして取り出して,一通ずつに切り分けます.どこからもってくるかによって全部つながっていたり,個別に分かれていたりしますね

メールが数百とかある場合は,Perlスクリプトなどで処理するのが現実的ですね.

文字コードをUTF-8に整える

文字コード変換が必要な場合,扱うOSでネイティブな文字コードに変換してしまうのが楽です.わたしの場合は,MacとLinux + KDEが主なので,迷わずUTF-8です.

nkfを使うか,Kateなどの高機能エディターでUTF-8にします.数が多い場合は,bashでnkfを連続で回すのが良いでしょうね.

ヘッダーを整える

文字コードを変換した場合,ヘッダーの当該部分を,

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

にします.数が多ければsedを使うのがよいでしょう.

なお,比較的新しいメールについては,ヘッダー内のタイトル(Subject)はMIME化されていて,また,本文の文字コードと,ヘッダーの上記部分の整合性もいいので,文字コード変更(とそれに伴うヘッダー修正)は行わない方が良いです.

ヘッダーの修正

文字コード以外のヘッダーの修正が必要なことが多いです.

一番引っかかる(IMAPクライアントのヘッダー解析でエラーになってしまう)のが,

>From だれそれ

というヘッダーです.これは,ざっくり削除しました.

sed -i '/^>From /d' *

(Mac OS X付属のsedは,GNU sedではないようで,上記の方法はNGです.)

ただし,手持ちの古いファイルの一部は,このヘッダーのみに日時が含まれている(「だれそれ」の後に付いている)ので,これをDate:行に書き換える必要がありました.

できたファイルをThunderbirdで読み込む

できたファイルの拡張子は,”eml”にします.

IMAPのサーバーでも良いし,ローカルでも良いので空のフォルダーを,Thunderbirdで作ります.そこへ(Thunderbirdへ),整えたemlファイルをdrag & dropします.

確認して必要ならば修正

読み込んだメールの日時やタイトル,本文を確認して,うまくいってなければ個別に文字コードやヘッダーを修正して再度読み込ませます.

Thunderbirdが依然としてエラーを出すヘッダーのあるemlについては,emlをuploadした直後に,downloadに失敗します(uploadはノーチェックのようです)ので,小分けにして読み込ませるのが良いようです.

制限

このようにして,Thunderbirdでは,エラーなく復活できたメールを正常に相手,日時,タイトルなどをリスト表示できて,本文の表示もできます.

いっぽうで,このようにThunderbirdからIMAPサーバーにuploadしたメールについて,Mac OS Xの”Mail”や,iPhoneなどのiOSの「メール」でアクセスすると,リストには日時が正常に表示されず,Thunderbirdでemlをuploadした日時が表示されるものがあります.また,リストには「本文がありません」と表示されるものもあります.

この,Mac OS Xと,iOSのMailでのリスト表示の不具合はなんとも不可思議で,同じように処理したつもりでも,リストに日時が正常に表示されるものと,uploadの日時になってしまうものがあります.両者のヘッダーを穴の開くほど眺めましたが,違いが分かりませんでした.

内容表示は正常なのでよしとします.時間順が重要な場合は,Thunderbirdで読むことにします.

効能^^;

この方法でかなり多くのメールを復活させました.2000年前後が主ですが,1994年頃のものもあります.

この人とは,この頃こういう交流をしていたのだ,などと懐古しています^^;

亡くなった先輩とのメールなど読み返すと,いろいろ思うところがあります.仲の良い先輩で,ある意味友だち付き合いしていました.あんまり失礼な書きぶりがなくてほっとしています.

Eudoraのメールファイル,UW-IMAPサーバーのユーザーディレクトリー内のファイルは,一続きでした.

IMAPの保存メールいじりまとめ

IMAPクライアントで,サーバーのメールフォルダー・ファイルのメンテをその後もだらだらやっています.

いくつか解ってきたことがあります.

メールクライアントごとの状況

Thunderbird

不思議ですが,家庭内LAN経由でつないでいるMac, Windows PC, 仮想マシンのWindows, 仮想マシンのLinuxのいずれについても,破損が懸念されているメールボックスを読み込む間エラー表示が出続け,本来275通のはずなのですが,400を越えても読み込みを続けます.恐ろしいので,400〜500見当で,Thunderbirdを終了させています.

唯一,IMAPサーバーを動かしているLinuxマシンのコンソール(X.org + KDE 4.x)からは,問題なくつながり,正しいと思われる通数のメールを読み込み,表示します.

ただし,文字コードへのトーレランス(注)は,あまりないようで,古いメールのタイトルがいくつか化けています.

注: toleranceの最初の母音は[ou]と発音される長母音ですから,カタカナ表記的にはトーレランスとすべきです(例 totalはトタルでなくて,トータル,rotateは,ロテトじゃなくて,ローテートでしょう).そこで,マスコミがどう書こうが,当サイトでは”トー レランス”と標記します.

ここまで書いた後で解ったことは,サーバー以外で一台だけ,当該のメールボックスをThunderbirdで正常に読み込めるMacがありました.因果関係がますます解らなくなりました.

Apple Mail

エラーなくつながり,文字コードへのトーレランスも高いのですが,本文があるのに勝手に「このメールには本文がありません」という表示があったり,実際に本文が表示されなかったりします.

また,なぜか大きいメールボックスについては全通は表示されません.その規則性,何年前で切っているのか,何通で切っているのかも解りません.

ということで,メールボックスの操作は危険と判断しています.

iOS Mail(メール)

エラーなくつながり,文字コードへのトーレランスも高く,すべてのメールが表示され,本文がないこともありません.ネット越しにつながるクライアントで一番まともです.

ただし,階層構造になっているメールボックスをたたむことができず,全部展開されますから,いじるのは大変です.

結論

IMAPサーバーの動いているマシンのコンソールからThunderbirdを動かして,メールボックスをメンテナンスして,iOSのMail(メール)で,確認をするのがよさそう.

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メールボックスの危機

自分のメールの管理は、昔から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サーバー的には、一つのメールボックスファイルとなっている。

Slackwareのbuildスクリプトのバグ発見

UW IMAPは,make時にIP=6を与えないといけないのです.

普通は,configure時のオプション設定で,そうした設定をして足りるんですが,たまにこういうオレ流なパッケージがあります.

Slackware-currentのalpine.Slackbuildですが,

# Build and install:
# Since we build non-compliant to RFC3501 we have to answer 'y' half-way:
echo y | make EXTRACFLAGS="-fPIC" SSLTYPE=unix || exit 1

# Build and install:
# Since we build non-compliant to RFC3501 we have to answer 'y' half-way:
echo y | make EXTRACFLAGS="-fPIC" SSLTYPE=unix IP=6 || exit 1

にしないと,IPv6サポートになりません.

そう,これだけのこと^^; オレの週末を返せぇ!

Slackware付属のIMAPデーモン(サーバー)が,IPv6で使えない問題の解決策の話です.