このプロジェクトの真のターニングポイントは、Harry Hochheiser がクライアント機のSMTPポートにメールを転送するための書きかけの コードを送ってきてくれたときだった。ぼくはほとんど即座に、 この機能を信頼できる形で実装できたら、ほかの配信モードは ほとんど時代遅れ同然になるなと気がついた。
何週間にもわたって、ぼくは fetchmailにいろいろ追加する形で いじってきていた。でもその間、インターフェースのデザインが 使えなくはないけれど、ちょっと野暮ったいなと感じだしていた ――エレガントじゃないし、貧弱なオプションがそこらじゅうに ぶらさがってるし。とってきたメールをメールボックスファイルや 標準出力にダンプするオプションがことさら気に入らなかった けれど、その理由が自分でもわからなかった。
SMTP転送について考えてみたときに気がついたのは、popclientはいろいろ やろうとしすぎてるということだった。これはメール配送エージェント （MTA）とローカル配信エージェント（MDA）の両方をこなす よう設計されていた。SMTP転送があれば、MDAの仕事からは足を洗って、 メールのローカル配信はほかのソフトにまかせればいい。ちょうど sendmailがやってるように。
メール配信エージェントのややこしい設定なんか、しなくたって いいじゃないか。メールボックスをロックして追加なんて、しなく ていいじゃないか。ポート25は、TCP/IPサポートのあるプラットホーム なら、まずまちがいなくそこにあるんだから。特にこうすれば、 とってきたメールは確実に、ふつうの送り手から送られてきた SMTPメールのように見えるはずなんだ。それがもともとぼくたちの 求めているものだろう。
ここにはいくつか教訓がある。まず、このSMTP転送のアイデアは、ぼくが Linusのやりかたを意識的に真似ようとした最大の見返りだった。 あるユーザがすばらしいアイデアを提供してくれた――ぼくは単に、 その意義を理解すればよかっただけ。
11。いいアイデアを思いつく次善の策は、ユーザからのいい アイデアを認識することである。時にはどっちが次善かわからなかったり する。
おもしろいことに、もし自分が他人に負うところがいかに大きいかに ついて、完全かつ謙虚なくらいに正直でいたら、世の中はその発明が 全部あなた自身のもので、単に自分の天才ぶりについて謙遜している だけだと見なしてくれる。これがLinusの場合にどんなにうまく いってるか、みんなもごらんの通り！
（1997年8月にこの論文をPerlの会議で発表したとき、最前列に Larry Wallがいた。ぼくがこの直前のくだりにさしかかると かれが野次をとばした。宗教的なリバイバルスタイルで、 「そうだそうだ、言ってやれ、兄弟！」と。全聴衆が笑った。 みんなこれが、Perl発明者にとってもうまくいったのを 知っていたからだ。）
そしてその同じ精神でプロジェクトを運営してほんの数週間もしない うちに、ユーザたちからだけでなく、それを伝え聞いたほかの人たち からも、同じような賞賛のメールが届くようになった。そういう メールはいくつかとってある。いつか、自分の人生なんて何の 価値もなかったんじゃないかと思うようになったら、またそれ を読みかえそうっと:-)。
でもここには、もっと本質的で政治的でない教訓があと2つある。 これはあらゆるデザインに一般化して言えることだ。
12。もっとも衝撃的で革新的な解決策が、自分の問題のとらえかたがそもそも間違っていたという認識からくるということはよくある。
ぼくはpopclientを、MTA/MDAの複合物として開発し、いろんな 気の利いたローカル配信モードをくっつけたものにしようとし 続けていた。これは解決すべき問題をまちがえていたんだ。 Fetchmailの設計は、純粋なMTAとして最初から考え直す 必要があった。通常のSMTPを話すインターネットメールパス の一部として。
開発で壁にぶちあたったとき――次のパッチ以降何をしたらいいか、 すごく悩んでしまうとき――というのは、自分が最終的な回答に たどりついたのかな、と考えるべきときではなく、むしろ自分が 正しい質問をしているのかな、と考え直してみるべきときである ことが多い。ひょっとして、問題をとらえなおしてみる必要が あるのかもしれない。
というわけで、問題をとらえなおした。明らかに、やるべき正しい ことというのは：
この3番目については、しばらくためらった。ながいことpopclientを 使ってきて、他の配信メカニズムに頼っている古参ユーザたちを 怒らせるんじゃないかと思ったからだ。理論的には、かれらは 即座に.forwardファイルか、sendmail以外でもそれに相当する 仕組みを使うことで、同じ結果を得ることができる。でも実際 問題としては、この移行はえらく手間がかかることになるかも しれない。
でも実際にやってみたら、利点のほうが大きく出てきた。ドライバの コードのいちばんいやらしい部分が消えた。設定もむちゃくちゃに 簡単になった――システムMDAやユーザのメールボックスを探し回ったり して悩むこともなくなったし、下敷きになってるOSがファイルの ロッキングをサポートしているか心配する必要もない。
さらに、メールをなくす唯一の方法も消え失せた。もしファイルへの 配信を指定してディスクがいっぱいになったら、メールは消えてしまう。 これはSMTP転送では絶対に起きない。SMTPのリスナーは、メッセージが 配信できるか、少なくとも後の配信用にスプールできる場合にしか OKを返してよこさないからだ。
さらに、速度も向上（もっともこれは一回走らせたくらいではわからない けれど）。もうひとつバカにできないメリットとして、manページが すごくシンプルになった。
あとで、ダイナミックSLIPがらみの珍しい状況を処理できるように するため、ユーザ指定のローカルMDA経由の配信は復活させなきゃ ならなかった。でも、これももっと簡単にこなす方法を見つけた。
教訓は？ 古びてきた機能は迷わず捨てること――有効性を 下げずに捨てられる場合には。アントワーヌ・サンテグジュペリ （かれは児童書の古典を書いていないときには、飛行家で航空機 設計家だった）曰く：
13。「完成」（デザイン上の）とは、付け加えるものが何も なくなったときではなく、むしろなにも取り去るものがなくなったとき。
コードがどんどんよくなって、しかも同時に単純になってきたら、それは もう絶対に自分が正しいのがわかる。そしてこの過程で、 fetchmailのデザインは、先祖のpopclientとは別の独自の アイデンティティを獲得してきた。
そろそろ名前を変える頃だった。新しいデザインは、以前のpopclientより ずっとsendmailの双子みたいな感じになってきていた。どっちもMTAだけれ ど、sendmailがプッシュして配信するのに対して、新しいpopclientは プルして配信する。だから引き継いで2ヶ月したところで、ぼくはこれを fetchmailと改名した。