ZMail on the MIT CADR and LM-3

Maintained LM-3 source and contemporary manual

The source analysis pins the LM-3 System repository at check-in 4df393c, tag system-303. This is maintained preservation work, so it is not silently treated as a pristine 1980s release checkout.

The active DEFSYSTEM ZMAIL declaration selects 18 unique Lisp source paths. They total 666,208 bytes. A manifest made from each repository-relative pathname, byte size, and SHA-256 in expanded declaration order has SHA-256 03fba3258c2baa74d618a6e6d0e3eb2407ca115b04f2d9fd64db7937bf147115. The principal files are:

The active local-filesystem integration is file/zmail.lisp. Although selected by the system declaration, zmail/lmfile.lisp is entirely commented out. The separate zmail/lm.lisp is not selected at all, and its pathname defaults are therefore not part of the strict System 303 profile.

The tree also contains the first-edition ZMail Manual, labeled ZMail 50 on System 94 and dated April 1983. Its 163,179-byte source has SHA-256 ac360407be2d99ffd3b80cbac0e823072366105b98808a94250b7182780017ba. It is contemporary product documentation, but its version label differs from the maintained System 303 source and the tested band. Claims below are therefore cross-checked against code, not copied from the manual as though all three artifacts were identical.

System 46 boundary

The museum's pinned public System 46 snapshot is 8e978d7. Its ZWEI files contain a mail-composition mode, but the snapshot has no ZMail system or ZMAIL-FRAME implementation. ZWEI Mail mode and ZMail are therefore separate catalog entries: one edits outgoing mail text; the other manages mail stores and the complete reading/sending workflow.

The System 46 composer is itself behaviorally substantial. It is a sparse ZWEI major mode: Control-Altmode and End send, Control-] exits while retaining the draft for later resumption, and Tab retains the parent tab-stop operation. A fresh entry clears and initializes the draft, while an argument retains its contents. Sending requires the literal body separator and at least one nonempty To recipient; Cc alone is insufficient. Recipient splitting is comma-based without quoted-comma syntax, surrounding spaces and tabs are removed, and one surrounding parenthesis pair is stripped. The writer opens its request stream before the empty-recipient check, so strict emulation must permit a rejected draft to leave partial request output. The command prose names Control-G as quit, but the executable table binds Control-]; the table is authoritative for this source profile.

Status vocabulary and parser ownership

The executable System 303 old-mail-buffer state machine uses NIL for stable state and :LOADING, :SAVING, :SAVING-REQUIRED, and :AWAITING-NEW-MAIL while work is pending. New-mail/inbox work additionally uses :NEW-MAIL, :LOADING-NEW-MAIL, and :AWAITING-SAVE. A nearby source comment instead spells two states :SAVE-REQUIRED and :AWAIT-NEW-MAIL; those comment-only spellings are not executable status values.

Header-parse ownership is claimed with an atomic %STORE-CONDITIONAL transition on the message's parse-state cell; it is not protected by the separate recursive disk-buffer lock. A source-visible failure edge remains important: a waiter sleeps for the owner to publish T, but an owner that unwinds restores NIL, so that waiter can remain asleep. This is a strict compatibility fault case, not a recommendation for a modern implementation; D08 defines a separately labeled safe extension which wakes the waiter with failure.

Registered System 303 mail-file formats

The selected source registers six formats:

This corrects two tempting inferences. The manual says VMS and Multics are unimplemented, while the maintained source implements VMS but not Multics. And the inactive lm.lisp file must not be used to invent a seventh strict-profile adapter or LM-host default. The active local-file integration chooses Babyl for ordinary local files.

The Text result is another compatibility trap. Rejecting or clearly labeling an attempt to reopen an export matches the supported non-reparsable UI boundary. If a strict source profile exposes the low-level load anyway, executable control flow publishes one message for each consecutive nonblank line, but an initial or intervening blank/space-tab-only line reaches buffer-pointer construction with a null start and faults before publication. The adjacent comment instead predicts zero messages. The maintained source and its untested band behavior must remain separate until the forced-load runtime oracle records the exact condition and cleanup.

Reading, navigation, and display

• move to next or previous messages, with variants for unseen, undeleted, first, and last messages;
• jump or go to a message selected by a filter, move between saved points, and set a message-position mark;
• switch among summary-only, message-only, combined, and experimental filtered configurations;
• scroll the message and summary panes separately, recenter, refresh, and move to the start or end of a message;
• show the parsed or original header, type messages to a typeout window, and edit the current message through ZWEI;
• list, select, rename, and kill ZMail buffers.

Filing and lifecycle

• mark messages deleted or undeleted, remove them from a temporary result buffer, expunge disk-backed buffers, and choose the direction of movement after deletion;
• save changed mail files, move a message to another file, concatenate it to an existing message, append or move relative to a referenced message, and save a message into the ZWEI kill ring;
• get new mail, optionally jump after retrieval, handle append-versus-prepend policy, and keep the primary inbox distinct from other mail-file buffers;
• assign expiration dates and optionally delete expired messages per file;
• detect duplicate messages and turn a digest into individual messages, with options for deleting or clipping the original digest;
• print one message or a whole selected set through the hardcopy abstraction.

Searching, classification, and bulk operations

• find a string from the current position and perform an occurrence search over a selected message population;
• attach or remove keywords and build reusable filters from typed message attributes;
• define universes, which name the population to which a filter and command apply;
• sort messages and survey a filtered set in a summary;
• map Delete, Undelete, Type, Find String, Keywords, Unkeywords, Move, Forward, Redistribute, Reply, or Concatenate across the selected population;
• select, delete, or move messages connected by reference headers, including an entire reference conversation.

The universe/filter distinction is historically notable. It separates “which messages may be considered” from “which predicate selects among them,” then applies a command to the result. That is closer to a small interactive query system than a folder-only mail reader.

Composition and delivery

• compose ordinary mail, replies, forwards, redistributions, local messages, and bug reports;
• choose reply-recipient policies such as sender only, original recipients, or sender plus recipients, with independent display policies for the original message;
• add To, Cc, FTo, FCC, From, Subject, In-Reply-To, and additional text fields;
• generate or suppress Message-ID and In-Reply-To fields, require a subject, and format addresses with short, long, personal-name, or original-text policies;
• yank the current message, prune selected headers, inherit or transform subjects, and use mail/reply/bug/forwarding templates;
• save, restore, write, and preserve drafts as messages; switch between one-, two-, and three-window reply arrangements; recursively start another mail operation;
• send through a file-job/COMSAT path, a Chaos mail server, direct Chaos delivery, Ethernet mail, or SMTP when the relevant site support is available.

The transport menu is capability metadata in this audit. It does not prove that an SMTP server, Chaos mail server, or Ethernet interface was configured in the tested load band.

The maintained source also fixes the send order, including its partial results. Headers are validated, a subject may be requested, and a message identifier is generated first. Requested FTo, FCC, and BFCC copies are then filed locally, with overlap precedence FTo over FCC over BFCC, before the network/file transport is called. Only transport success marks the draft sent and marks source messages Answered or Forwarded. A transport failure can therefore leave committed local copies and an unsent draft; retry can duplicate those copies. Visible and blind Chaos recipients use separate sessions, and direct Chaos submission proceeds per host, so earlier recipients or hosts may succeed before a later failure. The selected tree advertises Ethernet and SMTP-related choices but contains no active Ethernet sender and delegates SMTP outside the selected closure. They are unavailable without their providers, not aliases for another transport. An FTo-only draft can count as a successful local filing because file submission is a no-op when both To and Cc are empty.

Profiles and self-description

ZMail's profile editor exposes user options without requiring Lisp code. The source turns option definitions into editable values with types such as boolean, menu choice, number, pathname, pathname list, address list, string list, and Lisp form. Options cover layout, summary proportions, deletion direction, reply behavior, headers, file copies, templates, mail checking, saving, filtering, and mouse-button semantics.

The selected defs.lisp contains exactly 69 active textual user-option forms. The semantic companion records every name, type, default, applicability restriction, persistence class, update hook, and the source-visible filter/universe/Profile defects. That finite denominator excludes separately declared site, hardcopy, backup, and patch options.

The command system is also self-describing. ?, Help, Meta-X, X, Meta-?, and the named Apropos command reach different combinations of key help, full help, extended-command completion, and command-name searching. Menu buttons carry dynamic mouse documentation, and mode-line elements for keywords and scroll state are selectable. The implementation registers 86 distinct top-level ZMail command functions in the active source set; not all have a direct key.

Persistence and inbox failure boundaries

System 303 does not wrap mail retrieval, merge, expunge, and save in one transaction. Strict compatibility preserves these source-visible orderings:

1. An inbox source may be renamed before messages are read; a later parse or insert failure leaves that renamed source as recovery evidence.
2. Pending inbox files are deleted only after the destination mailbox save. A delete error is printed, but the pending list is then cleared, so that process does not automatically retry the deletion.
3. Merge splices interval/node structures before updating message arrays; a failure can expose a partially merged in-memory structure.
4. Save All expunges every selected buffer before saving any buffer. A later save failure follows already completed in-memory expunges.
5. Expunge applies expiration deletion before its confirmation; declining the later prompt need not undo those newly applied delete marks.
6. A foreground/background save-finish edge can abort-close a :SAVING buffer and leave status NIL instead of :SAVING-REQUIRED.

A reconstruction may offer transactional behavior as an explicit safety extension, but that behavior is not the strict System 303 profile.