Summary

  • RFC 1524 let several mail readers share local mailcap rules that mapped MIME Content-Types to view, compose, edit, print and test commands. The message supplied a type declaration; local search order and configuration supplied the action.
  • Under its UNIX semantics, an applicable rule became a Bourne-shell command with substituted media values or temporary filenames. A match, successful test or process exit was not proof that the body was authentic, safe, intentionally opened or usefully understood.

One label, many local capabilities

Internet mail was moving beyond plain text in 1993. MIME gave a body part a type, subtype, parameters and transport encoding. That solved a naming and carriage problem. It did not ensure that every recipient had the same viewer, editor, audio device or window system.

RFC 1524 introduced a deliberately local layer. A mail reader encountering an unfamiliar non-text body could consult an external mailcap file. A site could install one program, add one line and make that capability available to several independently written user agents. The shared artifact was not the viewer itself. It was a convention for describing which locally installed action should handle which declared media type.

That indirection preserved heterogeneity. The sender did not need to know the recipient's operating system or application inventory. The recipient did not need the sender's preferred program. Interchange stopped at a thin label; execution remained local.

The first applicable rule won

The effective configuration was a virtual concatenation of mailcap files. A candidate entry had to match the Content-Type, contain enough information for the action being requested and pass its optional test= command. The first entry satisfying those conditions was selected.

Order therefore changed behavior. Under the RFC's UNIX appendix, the default path began with a user's own file before site files, and the MAILCAPS environment variable could replace that path. A site administrator could publish a default; a user could override or augment it. Two accounts receiving identical bytes could legitimately choose different programs because their effective policy sources and precedence differed.

The mandatory fields named a media pattern and a view command. Optional fields separated composition, typed composition, editing and printing. Other flags said that a terminal was required, that output should be scrollable, or that a temporary filename needed a particular suffix. Recognition was not one binary property. A system might be able to display a format but not compose it, or print it only through another path.

The test= field sharpened the distinction. It could run an arbitrarily complex local program to check whether a window system, architecture or audio device was available. Zero exit status meant “this entry applies here.” It did not mean “these received bytes are safe.” Environment eligibility and content trust were different questions.

The configuration line became a shell command

On UNIX, RFC 1524 treated action fields as complete command lines intended for the Bourne shell—effectively preceded by /bin/sh -c. The rule could substitute %t for media type, %{name} for a Content-Type parameter, %n for a multipart count and %F for alternating types and filenames. %s stood for a file containing the body.

This was more than an application association. A parser selected a rule, interpreted quoting, expanded values and handed executable text to an operating-system command processor. Each transition had its own failure and authority boundary. A declared parameter could be syntactically present without being semantically sensible. A generated argument list could differ from the administrator's intended grouping. A command could start successfully and still mishandle the content.

Data transfer also changed with the template. Without %s, view and edit commands received the body on standard input. With %s, the user agent might create a temporary file and insert its name. RFC 1524 warned that the file could not be assumed to exist after the command exited; a helper continuing in the background had to save what it needed first.

nametemplate could give such a file a suffix required by a viewer. A .gif ending helped software that selected behavior by filename. It did not inspect the bytes, authenticate the sender or certify that opening them was harmless. A useful filename and a truthful object were separate claims.

Composition exposed another handoff

The same configuration could launch tools that created content. A compose program returned data to which the calling mail software applied the configured media type. A composetyped program instead emitted its own MIME Content-Type and related headers. The calling software still owned transport encoding unless that typed composer explicitly declared one.

So even locally generated mail crossed several records: the selected rule, the producing program, its output bytes, the type declaration, the transfer encoding and the final message. A successful editor session did not prove that the correct header or safe transport representation followed.

Extensibility did not confer trust

The RFC's security section was short but unambiguous: these mechanisms could make MIME security failures easier to enter, and implementers and administrators should be cautious about programs listed for automatic execution. It did not document a named exploit or claim that every mailcap deployment was unsafe. Its design evidence is narrower and more durable: a portable label can reach a powerful local action only through policy that somebody owns.

Later MIME specifications refined body formats, transfer encodings, media types and registration. Registration makes a token and its documentation shareable. It does not install a recipient handler, select a local rule or authorize execution.

The historical chain is therefore longer than “attachment opened.” Preserve the received bytes and declared type; effective mailcap files and their order; the requested action; selected entry and test result; fully expanded command; standard-input or temporary-file artifact; process identity and exit; displayed output; and the user's decision. Losing those distinctions turns metadata into an unexplained source of power.

Sources