横断歩道での一時停止は善意ではなく義務 (Powered by WordPress)
AMD A6マシン(GW4)に， Slackware64 14.2をインストールし，日本語フォントを追加して，ユーザーのデータをコピーしました．
ユーザーのデータをコピーしましたが，これから作業をしているうちに，ずれてくるので，rsyncで同期させるbashスクリプトも作りました．
そして，現在の私にとっての三種の神器であるFirefox, ThunderbirdとFileZillaの64bit版，さらに，LibreOfficeもインストールして，普通のWSとしては十分使えるようになりました.この記事も，当該マシンから書いてます．
たいていのソフトは，64bit版が手に入るので，multilib化はしないことにしました．multilib化しない方がメンテ性もいいでしょう．
次は，いよいよmariaDBのデータ移転ですね．これも，bashスクリプトでrsyncを動かして，バイナリー転送でうまくいくのか，動作確認しておきます．うまくいくようであれば，最終的な段階で，rsyncして，up to dateにします．
それより先にwebサーバー関係かなぁ．
発掘した場所，元の時代などによっていろいろメールファイルの形態（ヘッダーに含まれる情報や型式，文字コード等）が違いますので，なかなか一筋縄ではいきません．
一応，昔の発掘したメールファイルの回復方法を書いときます．最終的には手作業で，メールヘッダー部分を修正する必要があることが多いです．
まず，何とかして取り出して，一通ずつに切り分けます．どこからもってくるかによって全部つながっていたり，個別に分かれていたりしますね
メールが数百とかある場合は，Perlスクリプトなどで処理するのが現実的ですね．
文字コード変換が必要な場合，扱う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:行に書き換える必要がありました．
できたファイルの拡張子は，”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年頃のものもあります．
この人とは，この頃こういう交流をしていたのだ，などと懐古しています^^;
亡くなった先輩とのメールなど読み返すと，いろいろ思うところがあります．仲の良い先輩で，ある意味友だち付き合いしていました．あんまり失礼な書きぶりがなくてほっとしています．
IMAPクライアントで，サーバーのメールフォルダー・ファイルのメンテをその後もだらだらやっています．
いくつか解ってきたことがあります．
不思議ですが，家庭内LAN経由でつないでいるMac, Windows PC, 仮想マシンのWindows, 仮想マシンのLinuxのいずれについても，破損が懸念されているメールボックスを読み込む間エラー表示が出続け，本来275通のはずなのですが，400を越えても読み込みを続けます．恐ろしいので，400〜500見当で，Thunderbirdを終了させています．
唯一，IMAPサーバーを動かしているLinuxマシンのコンソール(X.org + KDE 4.x)からは，問題なくつながり，正しいと思われる通数のメールを読み込み，表示します．
ただし，文字コードへのトーレランス(注)は，あまりないようで，古いメールのタイトルがいくつか化けています．
注: toleranceの最初の母音は[ou]と発音される長母音ですから，カタカナ表記的にはトーレランスとすべきです（例 totalはトタルでなくて，トータル，rotateは，ロテトじゃなくて，ローテートでしょう）．そこで，マスコミがどう書こうが，当サイトでは”トー レランス”と標記します．
ここまで書いた後で解ったことは，サーバー以外で一台だけ，当該のメールボックスをThunderbirdで正常に読み込めるMacがありました．因果関係がますます解らなくなりました．
エラーなくつながり，文字コードへのトーレランスも高いのですが，本文があるのに勝手に「このメールには本文がありません」という表示があったり，実際に本文が表示されなかったりします．
また，なぜか大きいメールボックスについては全通は表示されません．その規則性，何年前で切っているのか，何通で切っているのかも解りません．
ということで，メールボックスの操作は危険と判断しています．
エラーなくつながり，文字コードへのトーレランスも高く，すべてのメールが表示され，本文がないこともありません．ネット越しにつながるクライアントで一番まともです．
ただし，階層構造になっているメールボックスをたたむことができず，全部展開されますから，いじるのは大変です．
IMAPサーバーの動いているマシンのコンソールからThunderbirdを動かして，メールボックスをメンテナンスして，iOSのMail（メール）で，確認をするのがよさそう．
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
などとします。