Visual RFC.
ALL RFCs / RFC 2369
Read the RFC ↗
RFC 2369 / MAILING LIST COMMANDS

Confirm safe actions and avoid invented substitutions

05

A list URL can cause an action. The user needs a chance to approve it, and a plausible header can still be forged.

DIAGRAMRead RFC section 5 ↗
RFC 2369 · § 5EXAMPLE
4 / 4
Confirm safe actions and avoid invented substitutionsFour independent action-boundary scenes. A mailto command prepares a fictional message and stays pending user approval. A user-confirmed safe example may be sent, without authenticating its claimed origin. A separate file URL is blocked by this client because confirmation does not make unsafe local behavior safe. A command requiring user-specific substitution has no defined variable expansion in RFC2369, so List-Help supplies instructions instead. No URL is opened, mail sent or private data substituted; this is not the separate RFC8058 one-click procedure.A header is not permission to actCommand needs a user-specific valueinvent variable expansionuse instructions insteadList-Help: <mailto:help@example.org>
04
Use help instead of fabricating variables.

A manager’s command needs a user-specific substitution. RFC2369 does not define that feature. The reader uses List-Help for instructions rather than inventing a replacement value or transmitting private data.

Source for this drawing: RFC 2369 · Read RFC section 5 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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

RFC 5322 Email message format RFC 2919 Mailing list identity RFC 6068 mailto links

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

Related RFCs and changes

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

KEY POINT

Reading a command is not permission to execute it.

  • RFC2369 requires a chance for the user to confirm any action before execution. If a dialog or other feedback interface is used, Appendix B.2.4 says it MUST offer review (and possibly modification) of the message before sending. Preparing the message is a suggested approach, not the only interface.
  • URL security considerations apply. Clients should not support list URLs that compromise the system, including dangerous file URLs; list processors should not allow user-originated list-command fields to pass through to their lists. Known nesting follows the separate section4 rules.
  • Client-side variable substitution is not supported. For managers needing extra user details, systems SHOULD still provide List-Help for instructions or a suitable structured interface. A client must not invent a substitution language.
DETAILS

The artwork is a fictional mail-reader walkthrough; no mail is sent and no URL is opened. The exact UI layout is not standardized; Appendix B.2.4 still requires the review option for a feedback interface. Appendix B.1 suggests identifying the command and destination, prompting for a sender address when it cannot be determined, and using the subscribed address for unsubscribe when known. RFC8058 separately defines authenticated one-click unsubscribe with user consent; it does not turn every generic List-Unsubscribe URL into an authorized automatic action. Its relation is contextual, not a formal update in RFC Editor metadata.

Read the RFC section ↗

All chapters in RFC 2369

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 ↗