Summary

  • RFC 2368 extended mailto: from an address into a template containing recipients, selected headers and a short plain-text body, but activating the URL did not require immediate network interaction.
  • The client could reject unsafe fields, had to disclose the decoded message, and left the user free to edit, send or cancel; a visible link, populated draft or click was therefore not a receipt for consent, submission, delivery or recipient action.

A link is usually remembered as a route. Click it and the browser asks a server for something. In July 1998, RFC 2368 standardized a stranger kind of link. A mailto: URL could contain an address, a subject, copies to other recipients and a short body. Yet following it did not have to contact any remote host. The useful result could be nothing more than a local composition window.

That pause was not incidental user-interface behavior. It was the protocol's operating boundary. RFC 2368 said the client created a message whose supplied fields were defaults. The user could edit it, send it unchanged or choose not to send. URL syntax did not mandate how resolution worked. The link could write the beginning of a message; it could not speak for the person whose mail program opened it.

From destination to candidate message

RFC 1738 had defined the simple form: mailto: followed by an address. RFC 2368 expanded the grammar to permit a comma-separated mailbox list followed by query-style header fields. The first field began after ?; later fields were separated by &. A special body field supplied the first text/plain body part.

This was a practical bridge between the Web and older mail automation. A document could offer a pre-addressed request for an information service, a subscription command for a list processor, a subject line needed by an archive robot or a reply carrying an In-Reply-To reference. The author no longer had to explain, “open your mail client, copy this address, type this exact command.” The link could stage the instruction.

But staging introduced several owners of truth. The document author owned the literal URL. A parser owned the conversion of escaped octets into address, header and body values. A mail client owned its safety policy and composition interface. The user owned approval. A submission server later owned acceptance. Other systems owned transport, mailbox delivery, reading and any requested action. RFC 2368 connected those stages without merging their receipts.

Encoding was part of the control surface

The compact syntax carried two grammars at once: URL syntax and Internet-message syntax. Characters meaningful to the URL layer could also be legitimate address or content characters. RFC 2368 therefore required percent-encoding for reserved data. A literal percent sign in an old-style address became %25; a question mark used as address data became %3F; spaces became %20; message-body line breaks became %0D%0A.

HTML added another layer. Because ampersand already marked an entity reference in HTML, a mailto: URL embedded in a page had to write the header separator as &. The page source, parsed link, decoded message and wire message were related representations, not interchangeable strings. A mistaken decode order could change a destination or split one field into two.

RFC 2368 also exposed the internationalization limits of its period. Raw eight-bit characters were forbidden. MIME encoded words could appear in header values, but not in the body value. The URL could not substitute run-time variables, so it could not safely insert the activating user's address or create a signature that depended on local data. What looked like a miniature form was deliberately less powerful than a general program.

The resolver was allowed to say no

Permitting arbitrary header names in the grammar did not obligate a client to honor them. RFC 2368 told a user agent to avoid creating a message when supplied fields were dangerous, or to construct a message from only a safe subset. It identified Subject, Keywords and Body as both safe and useful, while warning creators not to expect support beyond Subject and Body.

Identity and routing fields received stronger suspicion. A link was not entitled to choose From, hide a destination in Bcc, or dictate MIME and route machinery merely because those strings fit into the general header shape. The RFC's security section recommended interpreting fewer fields, not more. Extensibility at the syntax layer was bounded by local policy at the execution layer.

That distinction matters when reconstructing early Web automation. A complex mailto: URL was not an executable command with uniform effects. Two clients could parse the same bytes and produce different drafts because they accepted different fields. A third could refuse. Even after composition, the user could rewrite every line or close the window.

Disclosure came before authority

The specification's strongest language addressed consent. A mail client should not send a URL-derived message before showing the user the complete decoded result, including all supplied headers, explaining that email was about to be sent and asking for approval. Opaque encoding could otherwise conceal a recipient, copy address or command.

The risk was not abstract. RFC 2368 listed messages that might identify the user to an unwanted third party, incur a financial charge, violate law or trigger damaging action attributed to the sender. A convenient link could cross a social and legal boundary if composition silently became transmission.

The resulting evidence ladder is exact. Presence of a link proves only that a publisher exposed a template. A click may prove activation in one interface, if it was logged at all. A populated composer proves a client accepted some decoded fields. A visible review proves disclosure only if the interface and state are captured. A send action is a separate event. Server acceptance, remote delivery, reading and service execution require still other records. None can be safely backfilled from the preceding layer.

What RFC 6068 changed—and preserved

RFC 6068 replaced RFC 2368 in 2010. It modernized the scheme around URI syntax, clarified duplicate fields and escaping, and allowed non-ASCII character data to be encoded through UTF-8 before percent-encoding. It revised the treatment of Bcc and documented internationalized-domain handling. These were substantial corrections to how templates could be represented.

They did not remove the central boundary. The later RFC still described a mailto: URI as a template for a message that client software might send. Better character transport did not turn the template into consent. A correctly decoded international subject did not prove that a user approved it, that a server accepted it or that a recipient acted on it.

RFC 2368 therefore belongs in Internet history not merely as the document behind clickable email addresses. It recorded a constitutional choice for client-side automation: an outside document could propose content, but the local client could filter it and the human could stop it. The link reduced transcription work without acquiring the user's authority.

Sources