Visual RFC.
ALL RFCs / RFC 6068
Read the RFC ↗
RFC 6068 / MAILTO LINKS AND MESSAGE TEMPLATES

Filter unsafe fields and recognize public URI exposure

05

A URI cannot choose the sender’s identity, routing or MIME machinery. Clients assess dangerous fields, and addresses in a public link remain public even when labelled bcc.

DIAGRAMRead RFC section 4 ↗
RFC 6068 · § 4EXAMPLE
3 / 3
Filter unsafe fields and recognize public URI exposureThree independent safety examples. A URI arrives at mail software with from and Content Transfer Encoding requests; those originator and MIME fields MUST be ignored, and normal fields are created as necessary. In a separate hypothetical MUA policy, a Subject containing decoded CRLF is considered dangerous; the proposed draft stops following SHOULD NOT, while MAY subset processing remains permitted. Finally an observer reads a public URI containing bcc hidden at example com; public bcc addresses can be harvested even though ordinary outgoing recipient handling differs. No real messages or accounts are used.A URI template is untrusted inputPublic page URIPage observerread public URImailto:alice@example.com?bcc=hidden@example.comVisible address: hidden@example.combcc in a public URI is not secretPercent encoding is not encryption
03
Read bcc as public URI data.

An observer of a public link can read hidden@example.com from its bcc query. It is not hidden from the page reader or harvester just because normal message recipient handling treats bcc differently.

Source for this drawing: RFC 6068 · Read RFC section 4 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 3986 URI syntax RFC 5322 Email message format RFC 3629 UTF-8

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
bcc
Blind carbon copy: an addressing option for message composition, not a secrecy property of an address embedded in a public URI.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Treat the template as untrusted input, not authority or confidentiality.

  • URI originator fields such as From/Date, routing and trace fields, and MIME fields such as MIME-Version or Content-* MUST be ignored. The client MUST create new fields when necessary, as for a new message.
  • If fields are considered dangerous, the client SHOULD NOT create the message; it MAY instead use only a subset. Unknown or inconsistent fields are especially suspect, not automatically safe. Clients MUST support compliant creation using subject and body; creators cannot expect arbitrary fields to be supported.
  • Public mailto URIs expose all contained addresses, including bcc, to harvesting. bcc is not encryption or secrecy for the URI; outgoing messages may be logged or read along the route if not protected. mailto itself provides no variable substitution for the user’s address.
DETAILS

Three independent safety examples. A URI-supplied From/Content-Transfer-Encoding is ignored after input arrives. A hypothetical MUA treats a decoded Subject line break as dangerous and follows SHOULD NOT; subset processing is a permitted alternative, not a universal rejection requirement. The bcc exposure example is reserved fictional data only.

Read the RFC section ↗

All chapters in RFC 6068

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗