別稿でも述べたように、戸田は確たる意図に基づいて「unix系OS上の原始的なメール環境」を使い続けています。 しかし、世の中は、各ユーザがメールを読みたいときに各クライアントがメールサーバにPOPでアクセスしてメールを受信するという世界が事実標準となってきています。 この状況に対応するためには、unix系OSのキャラクタインタフェースからの使用を前提としたPOPクライアントが必要です。
2002年度に職場のシステムがネットワーク関連を中心に更新されることになり、メールサーバも置き換わることになりました。 そこで、この機会に何か適当な既製品は無いかなと思って探してみたところ、「popmail 1.2」というのが見つかりました。 作者に関する情報が若干錯綜（作者名に関する情報が「嶋田 通夫」と「嶋田 有吾」の２つある）しているのですが、とにかくソースファイル内に「Mitch Shimada」とクレジットしている作者が1995年3月16日02:47:15 GMTにNetNewsのfj.sourcesに投稿（<3p93nj$434@usgj.novell.co.jp>）したものです。 作者は、その後「インタープレス」というWindowsに特化したソフトウェアをオンラインで提供するプロジェクトを進めているようです。 そして、そのプロジェクトのページで、作者が過去に開発したpopmailなど2件のunix用ソフトウェアも提供されていました（2004年7月に見てみたら、無くなっていました）が、プロジェクトとしてはサポート対象外になっているようです。 popmailのドキュメント（1999年9月2日に追加されたPDFファイル）にも「現在、ソースコードに対するアップデートは一切行っていませんので、ご自由に改変していただき結構です」と明記されています。
さて、私としては、このpopmailの利用を考えたのですが、このソフトは、POPサーバへ定期的にメールを取りに行って手元に未読状態でメールを持っておくデーモンとして記述されています。 そして、デーモンとしての動作を安定させるために、POPサーバから取得したデータは「/bin/mail」に渡す、つまり、unix系OSの古典的なメールシステムの流れに載せて処理するという方法をとっています。
私としては、とにかく「余計なことをせずに」POPアクセスして「余計なことをせずに」テキストファイル（できればmbox形式）に落とす「なるべく軽くて信頼性の高い」ソフトが欲しかったわけです。 そして、自分が能動的にメールアクセスしようとしているとき以外にクライアントが勝手にPOPサーバからデータを取ってしまうのも嫌でした。 このことは、Fetchmailなどの有名どころのツールを採用しなかった理由でもあります。
そこで、デーモンとして動作するのではなく、ユーザが能動的に「メールを読む」行動を起こした時にPOPサーバへアクセスして直ちに終了するという、一過性の通常のアプリケーションに書き替えることにしました。 それに連動して、サーバ名やアカウント名などを記述する設定ファイルは全廃し、コマンドラインオプションとコンソール応答で全ての動作を決定するようにしました。 ログファイルも廃止して、コンソール出力のみとしました。 この段階は、専ら「コードを削除する」作業になります。 どこをどう削除して、残り部分をどう並べれば良いかを決めるために、デーモンの記述に関する若干の学習が必要だっただけです。
そして、データを「/bin/mail」に渡すのもやめにして、直接ユーザファイルに落とすことにしました。 二度手間を発生させないという目的もあるのですが、標準のメールシステムに対する種々の不満な点をこの機会に改良してしまおうという意図もあったのです。
「/bin/mail」で処理されたメールを処理するラインモードのメールソフトとしては「mailx」が標準的ですが、未読メールをスプールに戻す際に、勝手にコード変換したうえ各メッセージ末に空行を入れてしまうのです。 しかもコード変換に際して日本語EUCを自動判定（当初版開発当時にメインで使っていたNEWS-OSはシフトJISベース）するのですが、「utf-8・Big5・中国語EUC・韓国語EUC」などを日本語EUCと誤認してメチャクチャにしてしまうことが多いのです。 そして、MIME日本語文字列には対応していません。 このような問題点を、標準システムを通さずに自分でプログラムすることで解決しようと思ったわけです。
socketライブラリがサポートされていれば基本的には使えるハズです。 初期のバージョンではsocketライブラリを用いて実際に通信を行う手順をストリーム入出力（通常のfgets/fputsなど）を介して行っていましたが、この方式ではMS-DOS環境やWindowsのコマンドプロンプト環境に対応できないので、2004年7月15日にsocketライブラリの送受信関数（send/recv）を直接呼ぶ形に書き改めました（これにより、バージョン番号をVer.2系列とした）。
動作確認環境
unix系環境NEWS-OS Rel.6（添付のmakefile.sonyでコンパイル）MS-DOS環境 （Quick C Ver.2 ＋ CenterNET PC/TCP Development Kit Ver.4.0 for Dos）
RedHat Linux 9 Publisher's Edition（単純にccコマンドを実行すれば良い）
Turbo Linux FUJI Basic Version 11（単純にccコマンドを実行すれば良い）
MS-DOS Ver.5 for PC-9801 SeriesWindowsコンパイル環境（Visual Studio 6.0（＝Visual C++ 6.0）／wsock32.libをリンクするよう指定）
Windows 98 Second EditionWindows実行環境
Windows XP 2002 Home Edition
上記コンパイル環境のほか、
Windows XP 2002 Professional Edition
基本的にコマンドラインで動作の全てが決まります。 環境変数は、現バージョンでは「HOME」を参照するだけです。
コマンド名 [-v] ホスト名 [アカウント名]という書式になります。 サーバ名やアカウント名は一般には固定的情報ですが、シェルのエイリアス機能などを利用して自動的にコマンドラインに与えることを想定しています。 「-v」はデバッグ用のオプションなので、通常は指定しないでください。 指定すると、POPサーバとの会話を、メール内容を除いて全て画面表示します。 アカウント名を省略するとコンソール入力を要求します。
環境変数「HOME」に作業ファイル「wbox」と目的ファイル「mbox」を作ります。 「mbox」は、unix系OSの通常のメールシステムにmailxなどでアクセスした際に既読メールが落ちる「mbox」と基本的に同じものと考えてください。 「wbox」には、POPサーバから受け取ったデータが、コード変換を一切行わずに入ります。通常は見る必要はありません。 なお、これらのファイルが既存の場合は、コンソール入力で処理を指定するよう求めてきます。
作業ファイル「wbox」を作るのは、異常データなどの到来に際して動作をなるべく安定させるためです。 即ち、 POPサーバからのメッセージをひたすら「wbox」に保存し、それが完了してから順次「mbox」に変換していきます。 この変換の過程で、メールのSubjectなどを画面に表示していきます。 なお、メールが100通を越えると異常な表示になりますが、 変換には影響は無いハズです。
ちなみに、2006年5月12日に、100通（容易に変更可）を超えるメールがサーバにある場合には、最初の100通しか受信しないのを標準動作とし、バージョン番号をVer.4系列としました。 （この仕様とした直接の動機はSpamメールが増えたことです。）
「mbox」への変換が終了すると、サーバからメッセージを削除するかどうか、 コンソール入力で指定するよう求めてきます。 特に異常が無いようであれば、削除してしまって良いでしょう。
提供ソースをそのままコンパイルするとISO-2022-JPをシフトJISに変換します。 2004年11月30日にEUC-JPへの変換にも対応し、バージョン番号をVer.3系列としました。 冒頭で「EUC-JP」というプリプロセッサ変数の定義をコメントアウトしているのを外してコンパイルすればEUC-JP用になります。
MIME文字列のデコードは「mimehead()」、ISO-2022-JPからシフトJISやEUC-JPへの変換は「kanjicnv()」という関数で行っています。 この部分を書き替えれば、任意の変換が可能なハズです。 但し、現バージョンでは、変換結果の文字列の長さ（バイト数）がシフトJISモードでは変換前よりも、EUC-JPモードでは変換前の２倍よりも絶対に長くならないという性質を利用した書き方になっているので、この条件を満たさない変換をサポートする際には、呼び出し仕様を変えることも考えた方が良いかもしれません。
なお、この関数は独立性を高く書いてあるので、これだけ取り出して利用することも可能でしょう。 詳しくはアーカイブ中の「popkanji.txt」に記載されていますが、
2008年12月6日に、日本語以外のISO-2022文字列が正しく処理されない致命的なバグを修正しました。 2015年9月8日に、特定の条件でSubject:等の2バイト文字を正しくデコードしないバグを修正しました。 2018年7月20日に、対話入力したログインアカウントが短い場合に発現するバグを修正しました。 詳しくはアーカイブ内のドキュメントを参照してください。