要約

  • Eric Allmanの1994年の論文によると、Sendmailの主要な開発は1987年2月以降に止まり、ベンダーや外部の協力者が複数の派生版を作ったのち、1991年7月に再開した。
  • 再開の理由は一つではない。Berkeleyのメール環境の変更、版ごとの分岐、そして多くの実装に反映されていないとAllmanが考えたSMTP拡張が重なっていた。
  • Sendmail 8.6.6は一部の拡張に対応しつつ、別の機能には明確な制約を残した。公開版はその境界を調べられる形にしたが、普及や完全な標準準拠を証明するものではない。

長い中断が版の問題に変わった

Sendmailは、企業製品やオープンソース経済の象徴として語られる前から、Berkeley Unixの一部だった。Internet Hall of Fameの略歴によれば、Eric AllmanはINGRESに携わりながらカリフォルニア大学バークレー校でdelivermailとSendmailを開発し、両者はBSDとともに配布された。この背景は公開コードの意味を示す。システムを組み立てる人々は、メールルーターを調べ、自分たちの環境に合わせてコンパイルできた。

Allmanの1994年の論文「Changes in Sendmail Version 8」は、その後の停滞を具体的に記す。Sendmailの主要な開発は1987年2月以降、事実上止まり、積極的な作業が戻ったのは1991年7月だった。その間、ほかの人々が最低限の支援を続け、ベンダーや外部の協力者が独自の版を作った。Allmanは再開の理由を複数挙げている。Berkeleyではサブドメイン構造と4.4BSDに合わせたメール変更が必要だった。Bryan CostalesのSendmail本をレビューしたこと、分岐した版をまとめたいという意向、SMTP標準の変化も理由に含まれていた。

これは単一のきっかけで説明できる決断ではない。新しいBSDに合わせ、枝分かれしたコードを整理し、プロトコルの変更にも応じる必要があった。論文によれば、IDA-Sendmailは設定ファイルから相当量のパッチ群へと発展し、自分でソースをコンパイルする利用者に広く使われていた。一方、IDAのチームも大半のベンダーも、新しいSMTPの明確化や拡張を取り込んでいないとAllmanは述べる。これは1994年時点の本人による回顧であり、すべてのベンダーや設置環境を独立に調査した結果ではない。

この違いは大きい。標準が公開されても、実際に動くソフトウェアには古い前提が残り得る。実装が非公開だったり、枝分かれしていたり、入手しにくかったりすれば、運用者が標準文書から検証可能な代替版へ移る道は限られる。公開版は変更点と限界を見える形にし、隔たりを狭める助けになる。しかし、ベンダーに更新版の出荷を強制したり、管理者に導入を促したり、相手側のメールサーバーに受け入れさせたりはできない。

Version 8は機能の境界を明示した

AllmanはSendmail 8.6.6を例に、標準対応が二択ではないことを示す。この版はRFC 1425の基本的なESMTP、RFC 1427のメッセージサイズ拡張、そしてRFC 1426のBODYパラメーターの限定的な対応を備えていたと論文は説明する。同時に、8BITMIMEを広告せず、8ビットに対応しない相手へ送る際の変換も正しく扱えなかったと記している。

これは「Sendmail 8は新しいSMTP標準に対応した」という一括した説明より正確だ。機能を版と結び付けているからである。RFC 1425はEHLOで能力を交換するESMTPを定め、RFC 1427はSIZE、RFC 1426は後に8BITMIMEと結び付くBODY拡張を扱う。相手が何を広告するか、送信側が何を選ぶか、受信側がどう処理するかによって、意図した転送ができるかは変わる。論文は各地の導入時期や、これらの経路が本番でどれほど発生したかを示してはいない。

Sendmail Version 8の別の変更記録は、RFC 1123に対して「条件付きで準拠」と説明し、満たした要件と残る留保を列挙する。そのページが挙げる拡張RFCの番号は、1994年の論文に登場するものより後の版だ。両方を一つの機能一覧に混ぜてはならない。二つの記録を合わせると、準拠という表現にはソフトウェアの版、規範文書、例外の明示が必要だと分かる。

Allmanの貢献は、単にメジャーバージョンを公開したことではない。どの拡張があり、どれが部分対応で、変換のどこに問題が残るかを読める形にした。Version 8という番号にも実務的な理由がある。4.4BSD配布物のファイルがすでに8.1と番号付けされていたため、版を8から始めた。すべてのプロトコル問題を解決したという意味ではない。

公開コードは運用者に検証対象を与えた

Heng LuのNote 65は、編集上の視点として役立つ。公開された標準と稼働コードは別の問いに答える、という見方だ。このノートはAllmanの動機やSendmail史の証拠ではない。ここでの区別は実務的だ。標準はシステムが何をできるべきかを示し、ソース配布は一つの実装を調べる手段となり、テストや本番のSMTP交換は特定の二つのシステムが何をしたかを示す。

公開コードは作業も分配する。保守者は共通の変更を公開でき、ベンダーはパッチを取り込み、運用者はローカルの動作を公開ソースと比較できる。その一方で、設定差、非公開パッチ、古いパッケージは公開後も分岐を残し得る。公開は点検と修正の選択肢を生むが、保守コストをなくすわけではない。

結論は限定して述べるべきだ。Allmanの回顧では、Sendmailの停滞により、変化するSMTP文書と多くの利用者が入手できる実装との間に隔たりが生じた。Version 8は比較できる公開基準を提供し、新しい拡張の一部を取り込んだが、8.6.6の記録には明確な限界も残る。標準の発行もコード公開も、あらゆる環境での導入を証明しない。運用者が正確な版を特定し、動作を試験し、不足が見つかったときに保守される移行経路を選べるかが問われる。

出典