Summary

  • RFC 2017 added a URL access type to MIME message/external-body: the mail carried a retrieval description, while the referenced object remained outside it.
  • Folding and percent-encoding made a URL safe to transport, but could not establish reachability, stable identity, authenticity or permission to retrieve.
  • The specification kept type agreement, explicit user consent and Content-MD5 integrity evidence as separate controls; the official record does not establish broad deployment.

A normal attachment lets transport and content travel together. MIME's external-body model deliberately broke that convenience apart. The enclosing message described how to obtain a body that was not present. RFC 1521 had already named access routes such as FTP, anonymous FTP, TFTP, a local file and a mail server. RFC 2017 added another registered route: URL.

The addition looks small. The access type is URL; a URL parameter is mandatory; an inner entity header says what media type the eventual object should have. Yet those few fields expose several independent facts that an interface can too easily compress into one word such as “attachment”.

First comes location. RFC 2017 permits only URLs that actually retrieve an object. It expressly rules out mailto: that scheme designates a mailbox and an action, not data directly accessible as the external body. The distinction is semantic, not cosmetic. A string may have URL syntax without offering the operation the message claims.

Second comes transport. Long parameter values had to survive mail header rules. RFC 2017 therefore represented the locator as a quoted sequence of URL-word tokens, no more than 40 characters each, separated by linear whitespace. A receiver reconstructed the locator by removing the quotes and that whitespace. Before splitting, raw spaces, controls, quotation marks, backslashes and high-bit octets had to be encoded under RFC 1738's historical URL rules.

This solved a representation problem. It did not prove that the target existed, that the same bytes would be returned tomorrow, that credentials allowed access, or that the action was safe. A parser could perfectly reconstruct a locator and still possess no object.

A declaration made before retrieval

The inner header created another boundary. It declared the media type expected after retrieval. RFC 2017 required the version actually used by the application to agree with that declaration, noting that the application might already have made irrevocable choices. Selecting a decoder, allocating a viewer or dispatching to a handler can happen before all evidence about the fetched bytes is available.

The blank “phantom body” reinforces the architecture. In this URL form it is unused and should be empty: the message is not pretending to contain a miniature copy. That differs from the mail-server access type, where the phantom area carries a command. The absence is part of the contract.

RFC 2046, published the following month and replacing RFC 1521, preserved the external-body model. It required a Content-ID for external bodies so caches and later receipts could correlate material. It also made the risk unusually plain: resolving an external body causes the recipient to perform an operation specified by the sender. Software should explain what it proposes to do and obtain explicit permission.

Consent, then, is not supplied by syntactic validity. Nor is authenticity. RFC 2017 allows Content-MD5 to test whether retrieved bytes match an expected digest and the object the sender intended. It immediately says the field is not a digital signature. RFC 1864 makes the same limited claim: integrity checking is not author authentication.

These distinctions matter because the enclosing message and the retrieved object may have different evidence chains. Signing or validating the message does not automatically cover bytes obtained later through another protocol. The access mechanism itself may be redirected or subverted. A locator identifies a retrieval route; it is not a permanent content identity.

RFC 2017 was published as a Proposed Standard, and its current records retain that status. The errata query showed no matching errata at this review. RFC 1738, whose encoding rules the document assumed, is now obsolete; RFC 3986 supplies later generic URI syntax. Neither status fact establishes implementation prevalence, operational success or modern product lineage.

The historical lesson is narrower and more useful. Mail could transport an address without transporting the addressed object. Every system built on that separation needs independent answers to six questions: Was the locator preserved? Is the scheme eligible? Did the user authorize the action? What bytes arrived? Do they agree with the declared type? What evidence binds them to the sender's intention? One green indicator cannot honestly answer all six.

Sources