メール振り分け3原則

昔々と言うほど昔ではない昔、メールはPOPで受信して、サブディレクトリに振り分けながらローカルマシンに保存していた。

Mail/
  +- inbox/
    +- foo/
    +- bar/
    +- baz/

みたいな感じで。この管理方法だと、振り分けられないメールがinboxに積もり積もって気持ち悪いので、振り分けるほど重要ではないメールでも適当に振り分けていた。

で、今までGmailのラベルは、このサブディレクトリへの振り分けと同じ感覚で付けていたのだが、Gmailへの出戻りを機に考え直してみた。

1. 受信トレイには
   • 読み返す予定のメール
   • 返信する予定のメール
   だけ残す
2. 受信トレイに残さないメールは即アーカイブ
3. 頻繁に検索する条件をフィルタ化して、検索結果にラベル付け

そう、割とどうでもいいメールの振り分けなんて考えず、捨てないまでも、目には付かないアーカイブに放り込んでしまえば良いのだ。そして、割と読み返しそうなメールにだけラベルを付ければ良いのだ。

…と言うわけで、まずは全ラベルを消去してみた。別にメールを消したわけではないので、必要に応じて検索すれば良い。よく検索する条件を入力するのが面倒になってきたら、ラベルを付けよう。

ついでに、どうでもいいことを思い出した。かつてGmailからiCloudのメールに乗り換えた最大の理由は、前の会社でGmailへのアクセスがブロックされるようになったからだった。今となっては本当にどうでもいい話。

OS XのMail.appでReply-Toヘッダを自動的に付ける

OS XのMail.appでReply-Toヘッダを付ける場合、

表示>返信先アドレス欄

で返信先アドレス欄を表示した上で、毎回手動で入力していたのだが、やはり面倒くさい。それでも、それらしい設定項目が見つからなかったので諦めていたのだが…。解決方法があった。

具体的にはこちらにあるように、

% defaults write com.apple.mail UserHeaders '{"Reply-To" = "foo@example.com"; }'

とすればOK。ここで指定したメールアドレスが返信先欄の初期値になるわけではなく、返信先を特に指定しなくても、ここで指定したメールアドレスへのReply-Toヘッダが付加されるようだ。

メールのアーカイブ

これまでGmailでは全メールを受信ボックスに置きっぱなしだったのだが、今更ながらアーカイブ機能を使い始めた。

基本的には読んだらアーカイブ。でも、後で返信しようと思ったら受信ボックスに残しておく。こんな程度の使い分けでいいのかな？
受信ボックスの未読フラグだけで管理としては十分だったから、今ひとつアーカイブ機能のありがたみが分からん。そのうち分かるのか？

Simple is better.

結論。iCloud Mailのサーバ上に振り分けた状態でメールを置くのは諦めた。
大量のメールの振り分けは、どうもうまく行かないばかりか、失敗した結果、せっかく重複メールを削除したのに、また複製ができてしまう(メールの移動という作業がアトミックではない(コピーしてから元メールを削除)から、途中で止まるとコピーだけが残るのだろう)。色々試行錯誤しているうちに、とうとうiCloudから容量オーバーの通知が来る始末。もう諦めて、単一のメールボックスで単純に運用することにした。

…とは言え、全く振り分けないのも不便なので、Mail.appのスマートメールボックスを使ってみようと思う。検索結果はそれなりにキャッシングしてくれる…、よね？ 馬鹿正直に検索するようなら、もう他のMUAに浮気する。

なんだか、Gmailの偉大さを再認識するのに2日かけたような気がする。

mboxから重複メールを削除

昨日見つけたツールは捌ける数が

max a few hundred at the time

とのことなので、4万通以上のメールが誤操作で更に4倍ほどに膨れ上がった今となっては、とても使えない。なので、エクスポートしたmbox形式のメールアーカイブから、重複メールを取り除くフィルタをRubyで書いた。

#!/usr/bin/ruby
require 'digest/md5'
class Msg
  def initialize
    @str = ''
    @id = nil
    @eoh = nil
  end
  def <<(line)
    @str << line
    unless @id or @eoh
      if line =~ /^$/
        @eoh = true
      elsif line =~ /^Message-ID:\s*(.+)$/i
        @id = $1
      end
    end
  end
  def id
    if @id
      @id
    else
      Digest::MD5.digest(@str)
    end
  end
  def to_s
    @str.dup
  end
end
ids = {}
msg = nil
while line = gets
  if line =~ /^From /
    if msg
      id = msg.id
      unless ids.include?(id)
        ids[id] = true
        print msg
      end
    end
    msg = Msg.new
  end
  msg << line if msg
end
print msg if msg and (not ids.include?(msg.id))

これをmbuniqという名前でパスの通ったところに置いて、実行属性を与えてから

% mbuniq <original mbox file(s)> > <new mbox file>

と実行すると、<original mbox file(s)>から重複メールを取り除いた<new mbox file>ができる。これを適当なMUAでインポートすればOK。

メールの同一性はMessage-IDでが同じかどうかで確認している。Message-IDが見つからない場合は、代わりにハッシュ(MD5)値を用いる。当然ながら、大事なメールはバックアップを取ってから使うべし。

Bloggerってファイルを添付できないのかいな？

Mail.appで過去メールのアップに失敗

同じ過ちを繰り返さないために、失敗の記録を残しておく。

やろうとしたことはこれだけ。

1. mbox形式の過去メールをMail.appにインポート
2. インポートした過去メールをiCloudのメールボックスへ振り分けながら移動

インポートはOK。Mail.appがローカルに作成した適当な名前の新規メールボックスに、問題なく取り込まれた。
失敗したのは振り分け。まずはインポート先の全ての過去メールに現在の振り分けルールを適用したのだが、さすがに40,000通以上を捌くのは骨が折れるようで、全く終わりそうな気配がない。そこで、ただ待っているのもつまらないからと、振り分けルールを編集し始めたのが失敗の元。「ルールを編集する→適用するか聞かれる→はい」を何度も繰り返していたら、振り分けによるiCloudへのコピーが何度も適用されて、かなりの数のメールが重複してしまったのだ。

重複メールを削除するというツールを見つけるには見つけたのだが、何せ物量が半端でない上にインターネット越しのIMAPなので、とんでもなく遅い。なので

1. iCloudの全メールを一旦ローカルに引き揚げ
2. ローカルで重複メールを削除
3. iCloudに再アップ

しようと、まずは全メールのダウンロード中。これまた時間がかかるけれど、今度は余計なことをせず、寝ながら待とう。

IMAP移行計画〜振り分けこうしよう編〜

まず結論。
当面はiCloudのメールをMacとpalm(を襲名したiPod touch)からIMAPで閲覧。振り分けはiCloudサーバ側ではなく、MacのMail.appで行なおう。

palmへのプッシュ通知と振り分けの手間を考えたら、現状ではこれが最適解かな。palmで読んだメールをMacで振り分け直すのが面倒だけど。iCloud側の機能が充実するのを待とう。

…機能的にはGmailは素晴らしいのだけれど、ある串を通れないのよね。

IMAP移行計画〜105円が惜しい編〜

@niftyのIMAP。有料会員なら使えて当然だと思っていたら、追加料金が必要なんかい。
過去メールをアップしたら、POPのみに戻そうかなぁ。

IMAP移行計画〜振り分けどうしよう？ 編〜

procmailみたいな振り分けソフトのIMAP版がないかなぁ。ないなぁ。RubyにIMAPのライブラリがあるようだから、書いてみるか？
…そんなことを考えたというだけの話で、実際に手を動かしたわけではない。

IMAP移行計画〜そもそも論編〜

メールをIMAPに移行したくなってきた。
実運用はGmailべったりながらも、フリーメールに100%依存するのはやっぱり怖い。なのでこれまで、@niftyからのPOP受信を併用していたのだけれど、@niftyの改善を知って面倒なPOPをやめたくなったのだ。

とりあえず、2003年から溜め込んできたメールのディスク消費量を見てみると、1.2GB。そのうち630MBがspam。容量的には全く問題無し。

…ところで、そもそもIMAPってどんなもんよ？ これまで真面目に使う気がなかったので、漠然とメールをリモート管理するのためのサーバー＆プロトコルくらいにしか認識してなかった。まあ、これからもコマンドレベルでどうこうすることは無いと思うけど、せっかくだから機能的な面くらいはさらっとなめておこう。

適当にググってみると、肝はサーバー側でメールボックスを管理できることのようだ。メールボックスというのは、言わばメールを置いておくサブディレクトリのようなもの。POPだとサーバー側のメールボックスは1つしか無くて、手元に受信してからローカルのサブディレクトリに振り分けていたのが、IMAPだとサーバー側に振り分けた状態で置いておける。

メールボックスは作ったり消したりリネームしたりできる。要するに、ローカルのディレクトリに対してよく行う基本的な操作はできる。
メールに対しては、読んだり削除したりできるのはもちろんのこと、あるメールボックスから別のメールボックスにコピーすることも出来る。加えて、メールボックスに新規のメールを追加するコマンドもある。過去のメールをサーバーに保存するには、これを使うのだろう。
メールの検索をサーバーにやってもらうコマンドもある。まあ確かに、検索の度にメールをダウンロードする仕様だったら、結局ローカルにキャッシュしてしまいそうだしね。

ところで、大事な機能が見当たらない。そう、メールの振り分け機能はIMAPの領分ではないようだ。好きなように整理整頓可能な書庫は提供するけど、どう整理するかを考える司書は適当に調達してくれ、ということか。

@niftyのメールが進化していた

iCloudへの転送設定をするために久々に@niftyのWebメールにログインしたときに、@niftyメールの基本仕様を読んで知ったこと。

メールボックス容量5GB/保存期間無期限で一生使い続けることのできる充実のメールサービス

保存期間無期限！ 昔は2週間だった。…と言うか、今日の今日まで2週間のつもりで、転送先のGmailをメインに使いながらも、@niftyからもPOPでこまめにローカルに保存してたヨ。
@niftyとGmailとiCloud。3つもコピーがあれば、もうローカルに取っておかなくてもいい気がしてきた。