Mac OS 9版からMac OS X版へ移行するとき、結果的にメールの受信の手法は大きく変えないといけませんでした。UNIX系では、fetchmailによってPOPサーバに接続し、その結果をprocmailで受け付けてここで内容に応じた分岐を行って、さらにformailというコマンドでメールを整形してどこかに転送するというやり方が普及しています。当初、いろいろ考えて、9版で稼働していたプログラムを利用して、formailに相当する部分を自作し、受信や振り分けをfetchmailとprocmailによって行っていました。その結果、javaで作ったformail相当のコマンドの起動に時間がかかり、非常にパフォーマンスは悪かったという次第です。

　一方、その後の改良により、fetchmailでの受信は行いますが、procmailは、受信したメールをファイルに落とすという処理だけに使うようにして、その後に処理するプロセスでより多くのメールの処理をするようにしました。その結果、飛躍的に高速化しました。

　 結果的に、メールを1通受信すると、tempフォルダにその内容のファイルを作ります。一方、temp/hideフォルダには、バックアップのために受信結果をファイルに残しています。バックアップファイルは通常は、1日に1つのファイルにため込まれます。その後、tempフォルダにあるファイルを、1ファイルが1通のメールソースとして処理を行います。そこからの処理はJavaMailフレームワークを使った処理になります。

　fetchmail/procmailの処理でtempフォルダにファイルが作られ、それを処理します。通常は、OME_DownloadMailsがその処理を引き続いて行いますが、OME_MailProcessorを起動すると、tempフォルダのファイルの処理だけを呼び出すことができます。

　添付ファイルが存在する場合、ファイル名として設定された名前に拡張子が.mpartというフォルダを作り、そこに、各パートを個別のファイルとして保存します。

　ただし、現状ではすべての添付ファイルの処理ができるわけではありません。まず、うまくいくのは圧縮ファイルの添付で、これは多くの場合、問題なく処理ができるでしょう。また、テキストファイルについてもOKですが、拡張子がhtmlの場合にはコード変換してしまうので、htmlファイルを直接アタッチされたものはうまく解凍できない場合もあります。JPEGやGIFはOKです。また、Microsoft Officeのファイルも拡張子を付けておけば基本的にはほとんど問題なさそうです。なお、テキストファイルは、中身をそのままファイルに保存するという形式にしています。

　AppleDoubleやMacBinaryは現在はいったんファイルとして保存しておいて、その結果をStuffIt Expanderで処理させるようにしています。ただ、これは必ずしもうまくいく方法ではないようで、これらのファイルは中途半端に残ってしまいます。

　また、リソースの扱いですが、sitファイルでパックされて送ってくる以外は、リソースを元に戻すことはできません。これらの問題については、いずれは対処しますが、基本的には「ファイルは圧縮して送ってもらう」ということで対処してもらうしかありません。

　もし、ファイルが取り出せないメールが来たときには、temp/hideにあるメールのバックアップから該当部分を抜き出して文字コードを間違えないように保存しその結果をEntourage等で読み込んで、そちらで抜き出すということをしてください。

　対処はちょっと大変というのもあり、実際のところ「もしかしたら、リソースなんて使わなくなるかも」と思ったこともあって、優先順位的には低かったのですが…。

　 HTMLメールを採用するメールマガジンも増えてきている昨今ですが、HTMLメールにもいろいろな形式があります。Windowsの人が、別にHTMLである必要のないようなメールを送ってくる場合は、たいがいはテキスト化されたメインパートを参照すればOKでしょうから、HTMLを開く必要はないでしょう。わざわざ、署名をマルチパートで送ってくるような場合もありますが、結果的にHTML形式で参照したいのは、最近多くなってきたシングルパートのHTMLメールではないでしょうか。

　シングルパートのHTMLメールについては、.htmlファイルに保存をしますが、このファイルの保存に利用するエンコードは、HTMLメールのMETAタグに記載されたキャラクタセットを採用します。OMEでの保存ファイルのエンコード設定は無視します。該当するタグがない場合には、通常はシフトJISで保存します。

　そのHTMLファイルを、Internet Explorer等のWebブラウザで参照してください。基本的にはきちんと見えるはずです。

　以前には多くあった画像ファイルなどを含めたマルチパートのものも、基本的にはきちんとフォルダにファイルを展開するはずですが、最近はこの手のマルチパートメールといえばウィルスくらいになっているみたいなので（笑）、あまりきちんとチェックはしていません。

　なお、拡張子の.htmlは未読、.htmは既読を意味します。

　メール受信後の処理ですが、クラス定義により任意に設定できるという形式にしますした。

　いままでは、主に2つのクラスで処理をしていたことから、かなり処理が複雑に込み入っていました。こんな流れです。

　 　MailProcessor：受信したメールのファイルを認識して処理を行う
　　　↓
　PartExpander：メールファイル1つ1つの処理を行う

　この流れを次のように変更します。

　 　MailProcessor：受信したメールのファイルを認識して処理を行う
　　　↓
　MessageMaker：定義に従ったメールファイル1つ1つの処理を行う
　　　↓
　PartProcessorの拡張クラス：メール処理を行うクラス（複数を指定できる）

　ここで、MessageMakerは定義に従って、複数のPartProcessorの拡張クラスにメール処理を依頼できるようになっています。PartProcessorの拡張クラスの書き方などについては、改めてドキュメントを作成しますが、利用する側としてのポイントを先にまとめておきたいと思います。

　まず、PartProcessorの拡張クラス（OME.messagemakerパッケージ）として、次のものが用意されています。

　こうしたメール処理の諸機能をクラスに分離することによって、見通しよく拡張や改造をしやすくしようというのが趣旨です。まだ、もう少し分離統合はできると思いますが、現状でとりあえず公開しようと思いますので、場合によってはソースをご覧ください。

　たとえば、汎用的な処理プロセスを実行するクラスをここでインプリメントしていますが、場合によっては特定の処理を行うクラスを自分で作るということになるかと思います。また、メールの保存方法を独自に既定したクラスを作ることもできます。たとえば、必ずHTMLになるとか、保存結果はXMLだとか、あるいはStandardSaveをちょっと改造すると、無条件にUTF-8で保存なんてことも不可能ではありません（なお、UTF-8保存は別の手法もあります）。

処理に使用するクラスの指定と既定値

　それで、実際にメールに対して適用するクラスを定義するには、Behavior_Info.txtファイルに、次のような記述を行います。以前と同一にするには、次のような記述となります。

　MessageMakerClasses={"StandardSave",VirusCheckNAV","CommentChainByAliases",UnreadAliases","
SucceedProcess"}

　もちろん、ダブルクォートの間に、クラス名を正確に記載しないといけません。間違えても、そのクラスの動作を飛ばすだけで、処理はストップはしません。また、依存関係のあるクラスも発生します。たとえば、UnreadAliasesはStandardSaveがないと意味がない…などです。

　なお、順序も依存しますが、いまのところは、それによる動作の違いは少ないと思います。今後、「最後に指定しないと行けないクラス」とか出てくる可能性があります。

　もし、Behavior_Info.txtファイルにMessageMakerClasses=...の記述がない場合には、以下の指定があるものと同等であるとみなすことにします。ここら辺は、異存があるかもしれませんので、ご意見ください。

　MessageMakerClasses={"StandardSave","UnreadAliases","MailSourceBackup","SucceedProcess"}

メールのバックアップファイルの作成クラス（2005/3/28 - 5/8改訂）

　従来までは、メールをfetchmailでダウンロードするとき、procmailがメールソースをtempフォルダに作成し、同時にprocmailでのカーボンコピー機能を使ってtemp/hideにメールのソースのバックアップを作成していました。既存の機能を使って確実にバックアップを作るということで採用した機能ですが、このためのメールのダウンロードが遅くなるという結果になっていました。そこで、MailSourceBackupというクラスを作り、バックアップ作業を受信処理のクラスで行うようにしました。動作はこれまでと同じように、temp/hideにファイルを作るようにしています。

　従来と同様な動作を行うために、このMailSourceBackupクラスはデフォルトで使うようにしました。そして、デフォルトでは、procmailによるバックアップ作成は行われなくなっています。デフォルトでは、以下の設定をBehavior_Info.txtファイルに記述したのと同じようになっています。

　MessageMakerClasses={"StandardSave","UnreadAliases","MailSourceBackup","SucceedProcess"}

　Behavior_Info.txtファイルのキーワード“DontMoveFile”と“MoveFileByProcmail”を念のため、使えるようにしています。“DontMoveFile”はprocmailによるバックアップを作成しないという指定で、デフォルトと変わりありません。言い換えれば何も変化ないということです。一方、procmailによるバックアップファイルの作成をしたい場合には、“MoveFileByProcmail”を指定してください。これによってprocmailでのバックアップ作成が行われますが、MessageMakerClasses={}の指定がそのままだとバックアップが２重に同じファイルに作成されることになります。

Moving_Info.txtのの条件ごとに処理クラスを切り替える

　Moving_Info.txtのオプション、つまり、3つ目の項目にMessageMakerClasses=..の記述があれば、その条件に合ったメールは、Behavior_Info.txtで決めた処理クラスのセットとは違ったクラスのセットで処理を行えます。{}や""内のカンマをセパレータとして認識しないようにしないといけないのですが、そこはまだ実装していません。

　たとえば、ome-junk@mac-ome.jpが宛先に設定されているメールは、OME-Junkフォルダに移動し、かつ、未読を示すエイリアスは作成しないという場合には、OME設定フォルダにあるMoving_Info.txtファイルには、

　[To:]
ome-junk@mac-ome.jp,OME-Junk,,MessageMakerClasses={"StandardSave"}

　と書きます。つまり、この条件に合ったメールは、StandardSaveクラスの処理しかしないということです。

　また、ome-junk@mac-ome.jpが宛先に設定されているメールは、OME-Junkフォルダに移動し、かつ、未読を示すエイリアスは作成しないけども、指定したInputDataBase.appというスクリプを実行したいという場合には、OME設定フォルダにあるMoving_Info.txtファイルには、

　[To:]
ome-junk@mac-ome.jp,OME-Junk,MessageMakerClasses={"StandardSave","SucceedProcess"},/Users/msyk/Documents/InputDataBase.app

　と書きます。つまり、この条件に合ったメールは、StandardSaveクラスの処理しかしないということですが、処理後に、InputDataBase.appを起動し、OpenDocumentsイベントが発生して、アプリケーションは保存したファイルの情報が得られます。

廃止されたBehavior_Info.txtのオプション

　処理内容をMessageMakerClassesで記述することになったので、以下のオプションキーワードは廃止されます。Behavior_Info.txtファイルにあっても動作上は問題ありませんが、それによって、機能のオンオフは指定できません。

　 ＜Behavior_Info.txt＞
VirusScanning
SuppressCommentChaining

＜Moving_Info.txtのオプション＞
NoUnreadAlias

　 以前、インターネットの通信容量が少ない時代、1つのメールを複数のメールで分割して送信するということが行われてきました。そうした機能が要請されることから、現在でもメールアプリケーションにそうした機能が残っています。しかしながら、ブロードバンドが一般化した現在、こうした分割メールをやりとりする理由は非常に薄いことから、OMEでは分割メールの送信あるいは受信の機能を組み込む予定はありません。しかしながら、そうしたメールを受信してしまうこともありますので、その場合はOMEで受信したメールあるいはそのもとのソースを利用して、以下のサイトを参考にするなどしてデコードをしてください。