Summary

  • Eric Allman’s 1994 account says major Sendmail work stopped after February 1987 and resumed in July 1991, after vendor and volunteer variants had accumulated.
  • He identified several reasons for returning, including Berkeley’s mail changes, divergent versions and SMTP extensions that he said were not reaching most implementations.
  • Sendmail 8.6.6 supported some extensions while falling short on others; a public release made the boundary inspectable but did not prove adoption or full standards compliance.

A long pause became a version problem

Sendmail had become part of the Berkeley Unix environment before it became a company product or a symbol in arguments about open-source economics. The Internet Hall of Fame’s biography says Eric Allman developed delivermail and Sendmail at the University of California, Berkeley while working on INGRES, and that both were distributed with BSD. That history explains why a public code base mattered: system builders could examine and compile the mail router as part of their operating environment.

Allman’s 1994 paper, “Changes in Sendmail Version 8,” gives a more specific account of what happened next. Major work on Sendmail effectively stopped after February 1987. Active work resumed in July 1991. Other people provided minimal support during the interval, while vendors and outside contributors produced their own variants. Allman names several motives for returning: Berkeley needed mail changes for its subdomain structure and 4.4BSD; he had reviewed Bryan Costales’s Sendmail book; divergent versions needed unifying; and SMTP standards had changed.

That is a cluster of reasons, not a single conversion story. The code had to serve a new BSD release, reconcile differences between branches and respond to protocol changes. Allman’s paper says that IDA-Sendmail had grown from configuration files into a substantial patch set, and that it was widely used by people who compiled their own source. He also says that IDA and most vendors were not incorporating the newer SMTP clarifications and extensions. That is his 1994 retrospective, not an independently measured survey of every vendor or installation.

The distinction matters. A standard can be published while the software that operators actually run continues to reflect older assumptions. If the implementation is private, fragmented or difficult to obtain, an operator may have no practical path from a standards document to a tested replacement. A public version can narrow that gap by making changes and limitations visible. It cannot make a vendor ship them, an administrator install them or a remote mail system accept them.

Version 8 exposed the boundary

The 1994 paper uses Sendmail 8.6.6 to show that support was not an all-or-nothing property. It describes basic Extended SMTP under RFC 1425, the message-size extension from RFC 1427 and limited support for the BODY parameter under RFC 1426. It also says that this version did not advertise 8BITMIME and did not correctly convert a message for a peer that was not 8-bit capable.

Those details are narrower than saying “Sendmail 8 supported the new SMTP standards.” They identify a release and a set of capabilities. RFC 1425 defines ESMTP’s EHLO-based capability exchange; RFC 1427 defines SIZE; RFC 1426 defines the BODY extension later associated with 8BITMIME. A peer’s advertised capabilities, the sender’s choice and the receiver’s behavior all affect whether a message can be transferred as intended. The paper does not establish how quickly installations upgraded or how frequently these paths occurred in production.

A separate Sendmail Version 8 changes page describes the software as “conditionally compliant” with RFC 1123, listing requirements that had been met alongside remaining qualifications. That page cites later extension numbers than the 1994 paper’s discussion, so the two records should not be blended into one feature checklist. Together they show why a compliance label needs a version, a specification and a list of exceptions attached to it.

Allman’s contribution was therefore not just a new major version number. The paper made the implementation boundary legible: which extension was present, which was limited and where conversion still failed. The version number itself had a mundane explanation. Sendmail’s release series jumped to 8 because files in the 4.4BSD distribution were already numbered 8.1; it did not signal that every protocol issue had been solved.

Public source gave operators a testable object

Heng Lu’s Note 65 offers a useful editorial lens: a published specification and running code answer different questions. The note is not evidence about Allman’s motives or Sendmail’s history. Applied here, the distinction is practical. A standard says what systems should be able to do; a source release lets people inspect one implementation; a test and a production exchange show what a particular pair of systems did.

Public code also redistributes work. Maintainers can make a common change visible, vendors can carry patches, and operators can compare local behavior with the published source. At the same time, configuration differences, private patches and old packages can preserve divergence after a release. Publication creates an option to inspect and repair; it does not erase the cost of maintenance.

The record supports a bounded conclusion. In Allman’s account, Sendmail’s pause left a gap between evolving SMTP documents and the implementations available to many users. Version 8 provided a public point of comparison and incorporated some of the newer extensions, but the 8.6.6 example retained explicit limits. Neither a standard nor a public release proves universal deployment. The meaningful question is whether operators can identify the exact version, test its behavior and choose a supported path when the implementation falls short.

Sources