Choose one supported alternative before falling back
03Alternatives are ordered left to right. Choose the first protocol the client supports or can access through another application.
Separate failed-attempt branch: the selected mailto command is known to have failed. Only now does the example consider the later supported mailto fallback, with the applicable confirmation and security checks still needed.
Source for this drawing: RFC 2369 · Read RFC section 2 ↗
New to this? Start hereA quick picture + helpful background
The envelope and the letter do different jobs.
Mail transport moves a message between servers. The message format describes its contents. Authentication adds checks; it does not make every message safe.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Preference order is not permission to execute every listed URL.
- Multiple alternative URLs MAY be supplied. The client should use the leftmost supported or accessible protocol and should use only one URL for a command.
- The client should use another alternative only if its first attempted URL failed. Success does not trigger the next command. User confirmation and URL security still apply.
- Generators SHOULD usually include a mailto command beside other protocols for mail-only users. The RFC does not require every client to support the first-listed protocol or every list to supply all alternatives.
The worked example assumes a mail-only client and three valid alternatives. “Supports” includes access via a separate application. Which failures justify another attempt and how to avoid ambiguous side effects require application policy; this diagram does not silently submit real requests. Lowercase should from §2 is retained.
Read the RFC section ↗