RFC 2369 / START HERE
Mailing list commands, before the details
Mailing list command headers use URLs (Uniform Resource Locators) to describe operations; this publication is not an acronym.
These email fields tell a mail reader where to get help, join or leave a list, post, contact an administrator or find archives.
The idea in one picture
List message
Command alternatives
User chooses an action
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Different list managers accept different commands. Shared header names and familiar URL syntax let readers offer consistent controls without guessing each manager’s private command language.
A familiar example
For example, List-Help can offer a website first and a mailto address second. A mail-only client can use the mail alternative, after the required chance to confirm an action. A forged header is still untrusted.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Give each list command its own fieldSix optional email fields describe list operations using URLs: Uniform Resource Locators that identify a resource or command.→
- Read bracketed alternatives without losing boundariesA field contains angle-bracketed URLs, optionally separated by commas and surrounding comments or white space.→
- Choose one supported alternative before falling backAlternatives are ordered left to right. Choose the first protocol the client supports or can access through another application.→
- Adapt command fields for a nested sublistA known sublist may need its own support commands while some parent fields remain appropriate.→
- Confirm safe actions and avoid invented substitutionsA list URL can cause an action. The user needs a chance to approve it, and a plausible header can still be forged.→
This introduction explains RFC 2369 (1998). Read the original RFC ↗