7Network Working Group G. Neufeld
8Request for Comments: 2369 Nisto
9Category: Standards Track J. Baer
14 The Use of URLs as Meta-Syntax for Core Mail List Commands
15 and their Transport through Message Header Fields
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
27 Copyright (C) The Internet Society (1998). All Rights Reserved.
31 The mailing list command specification header fields are a set of
32 structured fields to be added to email messages sent by email
33 distribution lists. Each field typically contains a URL (usually
34 mailto [RFC2368]) locating the relevant information or performing the
35 command directly. The three core header fields described in this
36 document are List-Help, List-Subscribe, and List-Unsubscribe.
38 There are three other header fields described here which, although
39 not as widely applicable, will have utility for a sufficient number
40 of mailing lists to justify their formalization here. These are
41 List-Post, List-Owner and List-Archive.
43 By including these header fields, list servers can make it possible
44 for mail clients to provide automated tools for users to perform list
45 functions. This could take the form of a menu item, push button, or
46 other user interface element. The intent is to simplify the user
47 experience, providing a common interface to the often cryptic and
48 varied mailing list manager commands.
50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
52 document are to be interpreted as described in RFC 2119.
58Neufeld & Baer Standards Track [Page 1]
60RFC 2369 URLs as Meta-Syntax July 1998
65 This is a proposal for additional header fields to be added to email
66 messages sent by email distribution lists. The content of each new
67 field is typically a URL - usually mailto [RFC2368] - which locates
68 the relevant information or performs the command directly. MTAs
69 generating the header fields SHOULD usually include a mailto based
70 command, in addition to any other protocols used, in order to support
71 users who do not have access to non-mail-based protocols.
73 Implementing these fields will be optional. Significant functionality
74 and convenience can be gained by including them, however. Many list
75 managers, especially as the proposal first gains acceptance, MAY
76 choose to implement only one or two of the fields. The List-Help
77 field is the most useful individual field since it provides an access
78 point to detailed user support information, and accommodates almost
79 all existing list managers command sets. The List-Subscribe and
80 List-Unsubscribe fields are also very useful, but cannot describe
81 some list manager syntaxes at this time (those which require variable
82 substitution). See appendix A.5 for an explanation.
84 The description of command syntax provided by the fields can be used
85 by mail client applications to provide simplified and consistent user
86 access to email distribution list functions. This could take the form
87 of menu items, push buttons, or other user interface elements. The
88 intent is to simplify the user experience, providing a common
89 interface to the often cryptic and varied mailing list manager
92 Consideration has been given to avoiding the creation of too many
93 fields, while at the same time avoiding the overloading of individual
94 fields and keeping the syntax clear and simple.
96 The use of these fields does not remove the requirement to support
97 the -Request command address for mailing lists [RFC2142].
101 The list header fields are subject to the encoding and character
102 restrictions for mail headers as described in [RFC822]. Additionally,
103 the URL content is further restricted to the set of URL safe
104 characters [RFC1738].
106 The contents of the list header fields mostly consist of angle-
107 bracket ('<', '>') enclosed URLs, with internal whitespace being
108 ignored. MTAs MUST NOT insert whitespace within the brackets, but
109 client applications should treat any whitespace, that might be
110 inserted by poorly behaved MTAs, as characters to ignore.
114Neufeld & Baer Standards Track [Page 2]
116RFC 2369 URLs as Meta-Syntax July 1998
119 A list of multiple, alternate, URLs MAY be specified by a comma-
120 separated list of angle-bracket enclosed URLs. The URLs have order of
121 preference from left to right. The client application should use the
122 left most protocol that it supports, or knows how to access by a
123 separate application. By this mechanism, protocols like http may be
124 specified while still providing the basic mailto support for those
125 clients who do not have access to non-mail protocols. The client
126 should only use one of the available URLs for a command, using
127 another only if the first one used failed.
129 The use of URLs allows for the use of the syntax with existing URL
130 supporting applications. As the standard for URLs is extended, the
131 list header fields will gain the benefit of those extensions.
132 Additionally, the use of URLs provides access to multiple transport
133 protocols (such as ftp and http) although it is expected that the
134 "mailto" protocol [RFC2368] will be the focus of most use of the list
135 header fields. Use of non-mailto protocols should be considered in
136 light of those users who do not have access to the specified
137 mechanism (those who only have email - with no web access).
139 Command syntaxes requiring variable fields to be set by the client
140 (such as including the user's email address within a command) are not
141 supported by this implementation. However, systems using such
142 syntaxes SHOULD still take advantage of the List-Help field to
143 provide the user with detailed instructions as needed or - perhaps
144 more usefully - provide access to some form of structured command
145 interface such as an HTML-based form.
147 The additional complications of supporting variable fields within the
148 command syntax was determined to be too difficult to support by this
149 protocol and would compromise the likelihood of implementation by
152 To allow for future extension, client applications MUST follow the
153 following guidelines for handling the contents of the header fields
154 described in this document:
156 1) Except where noted for specific fields, if the content of the
157 field (following any leading whitespace, including comments)
158 begins with any character other than the opening angle bracket
159 '<', the field SHOULD be ignored.
161 2) Any characters following an angle bracket enclosed URL SHOULD be
162 ignored, unless a comma is the first non-whitespace/comment
163 character after the closing angle bracket.
170Neufeld & Baer Standards Track [Page 3]
172RFC 2369 URLs as Meta-Syntax July 1998
175 3) If a sub-item (comma-separated item) within the field is not an
176 angle-bracket enclosed URL, the remainder of the field (the
177 current, and all subsequent, sub-items) SHOULD be ignored.
1793. The List Header Fields
181 This document presents header fields which will provide the
182 command syntax description for the 'core' and key secondary
183 functions of most email distribution lists. The fields implemented
184 on a given list SHOULD be included on all messages distributed by
185 the list (including command responses to individual users), and on
186 other messages where the message clearly applies to one distinct
187 list. There MUST be no more than one of each field present in any
190 These fields MUST only be generated by mailing lists, not end
195 The List-Help field is the most important of the header fields
196 described in this document. It would be acceptable for a list
197 manager to include only this field, since by definition it SHOULD
198 direct the user to complete instructions for all other commands.
199 Typically, the URL specified would request the help file, perhaps
200 incorporating an HTML form for list commands, for the list, and
201 alternatively provide access to an instructive website.
205 List-Help: <mailto:list@host.com?subject=help> (List Instructions)
206 List-Help: <mailto:list-manager@host.com?body=info>
207 List-Help: <mailto:list-info@host.com> (Info about the list)
208 List-Help: <http://www.host.com/list/>, <mailto:list-info@host.com>
209 List-Help: <ftp://ftp.host.com/list.txt> (FTP),
210 <mailto:list@host.com?subject=help>
214 The List-Unsubscribe field describes the command (preferably using
215 mail) to directly unsubscribe the user (removing them from the list).
219 List-Unsubscribe: <mailto:list@host.com?subject=unsubscribe>
220 List-Unsubscribe: (Use this command to get off the list)
221 <mailto:list-manager@host.com?body=unsubscribe%20list>
222 List-Unsubscribe: <mailto:list-off@host.com>
226Neufeld & Baer Standards Track [Page 4]
228RFC 2369 URLs as Meta-Syntax July 1998
231 List-Unsubscribe: <http://www.host.com/list.cgi?cmd=unsub&lst=list>,
232 <mailto:list-request@host.com?subject=unsubscribe>
236 The List-Subscribe field describes the command (preferably using
237 mail) to directly subscribe the user (request addition to the list).
241 List-Subscribe: <mailto:list@host.com?subject=subscribe>
242 List-Subscribe: <mailto:list-request@host.com?subject=subscribe>
243 List-Subscribe: (Use this command to join the list)
244 <mailto:list-manager@host.com?body=subscribe%20list>
245 List-Subscribe: <mailto:list-on@host.com>
246 List-Subscribe: <http://www.host.com/list.cgi?cmd=sub&lst=list>,
247 <mailto:list-manager@host.com?body=subscribe%20list>
251 The List-Post field describes the method for posting to the list.
252 This is typically the address of the list, but MAY be a moderator, or
253 potentially some other form of submission. For the special case of a
254 list that does not allow posting (e.g., an announcements list), the
255 List-Post field may contain the special value "NO".
259 List-Post: <mailto:list@host.com>
260 List-Post: <mailto:moderator@host.com> (Postings are Moderated)
261 List-Post: <mailto:moderator@host.com?subject=list%20posting>
262 List-Post: NO (posting not allowed on this list)
266 The List-Owner field identifies the path to contact a human
267 administrator for the list. The URL MAY contain the address of a
268 administrator for the list, the mail system administrator, or any
269 other person who can handle user contact for the list. There is no
270 need to specify List-Owner if it is the same person as the mail
271 system administrator (postmaster).
275 List-Owner: <mailto:listmom@host.com> (Contact Person for Help)
276 List-Owner: <mailto:grant@foo.bar> (Grant Neufeld)
277 List-Owner: <mailto:josh@foo.bar?Subject=list>
282Neufeld & Baer Standards Track [Page 5]
284RFC 2369 URLs as Meta-Syntax July 1998
289 The List-Archive field describes how to access archives for the list.
293 List-Archive: <mailto:archive@host.com?subject=index%20list>
294 List-Archive: <ftp://ftp.host.com/pub/list/archive/>
295 List-Archive: <http://www.host.com/list/archive/> (Web Archive)
2974. Supporting Nested Lists
299 A list that is a sublist for another list in a nested mailing list
300 hierarchy will need to modify some of the List- header fields, while
301 leaving others as the parent list set them.
303 Sublists SHOULD remove the parent list's List-Help, List-Subscribe,
304 List-Unsubscribe and List-Owner fields, and SHOULD insert their own
305 versions of those fields.
307 If the sublist provides its own archive, it SHOULD replace the List-
308 Archive with its own. Otherwise, it MUST leave the List-Archive field
311 Dependant on how postings to the list are handled, the sublist MAY
312 replace the List-Post field. The appropriateness of whether to
313 replace List-Post is left to the determination of the individual list
314 managers. If the intention is that postings should be distributed to
315 all members of the primary list, List-Post should not be changed by a
316 sublist in such a way that postings will be distributed only to
317 members of the sublist.
3195. Security Considerations
321 There are very few new security concerns generated with this
322 proposal. Message headers are an existing standard, designed to
323 easily accommodate new types. There may be concern with multiple
324 fields being inserted or headers being forged, but these are problems
325 inherent in Internet email, not specific to the protocol described in
326 this document. Further, the implications are relatively harmless.
328 Mail list processors should not allow any user-originated list header
329 fields to pass through to their lists, lest they confuse the user and
330 have the potential to create security problems.
332 On the client side, there may be some concern with posts or commands
333 being sent in error. It is required that the user have a chance to
334 confirm any action before it is executed. In the case of mailto, it
338Neufeld & Baer Standards Track [Page 6]
340RFC 2369 URLs as Meta-Syntax July 1998
343 may be appropriate to create the correctly formatted message without
344 sending it, allowing the user to see exactly what is happening and
345 giving the user the opportunity to approve or discard the message
348 All security considerations for the use of URLs [RFC1738] apply
349 equally to this protocol. Mail client applications should not support
350 list header field URLs which could compromise the security of the
351 user's system. This includes the "file://" URL type which could
352 potentially be used to trigger the execution of a local application
353 on some user systems.
357 The numerous participants of the List-Header [5], ListMom-Talk [6],
358 List-Managers and MIDA-Mail mailing lists contributed much to the
359 formation and structure of this document.
361 Keith Moore <moore@cs.utk.edu> and Christopher Allen
362 <ChristopherA@consensus.com> provided guidance on the standards
394Neufeld & Baer Standards Track [Page 7]
396RFC 2369 URLs as Meta-Syntax July 1998
399A. Background Discussion
401 This proposal arose from discussions started on the ListMom-Talk
402 Discussion List [6]. When the discussion reached a sufficient level,
403 a separate list was formed for discussing this proposal, the List
404 Headers Mail List [5] for deeper discussion. We have included
405 summaries of key issues raised, in order to show some of the
406 alternatives examined and reasons for our decisions.
408A.1. Multiple header fields vs. a single header field
410 Use of a single header field for transporting command meta-syntax was
411 rejected for a number of reasons.
413 Such a field would require the creation of a new meta-syntax in order
414 to describe the list commands (as opposed to the use of the widely
415 deployed URL syntax which was chosen for this implementation). Every
416 additional layer of complexity and newness reduces the likelihood of
417 actual implementation because it will require additional work to
418 support. Also, by using the existing URL syntax, we can profit from
419 the end users' knowledge of that syntax and ability to use it even if
420 their client applications do not support the list header fields.
422 Restricting the transport of meta-syntax to the use of a single
423 header field also introduces complications with header field size
424 limitations. Most individual commands can easily be described in a
425 single line, but describing a multitude of commands can take up many
426 lines in the field and runs a greater risk of being modified by an
427 existing server on route.
429 The client implementation is also easier with multiple fields, since
430 each command can be supported and implemented individually,
431 completely independent of the others. Thus, some list managers or
432 mail clients can choose to implement a subset of the fields based on
433 the specific needs of their individual lists.
435 Finally, the format described in this document is simple and well
436 recognized, which reduces the chances of errors in implementation and
439A.2. URLs vs. parameter lists
441 URLs are already an established syntax which is flexible, well-
442 defined, and in wide spread use. As its definition matures and
443 expands, the abilities of the list fields will grow as well, without
444 requiring modification of this proposal. URLs are well prepared to
445 handle future protocols and developments, and can easily describe the
446 different existing access protocols such as mailto, http and ftp.
450Neufeld & Baer Standards Track [Page 8]
452RFC 2369 URLs as Meta-Syntax July 1998
455 Many clients already have functionality for recognizing, parsing, and
456 evaluating URLs, either internally or by passing the request to a
457 helper application. This makes implementation easier and more
458 realistic. As an example, this existing support for URL parsing
459 allowed us to add prototype list header functionality to existing
460 mail clients (Eudora and Emailer for the Macintosh) without modifying
463A.3. Why not just create a standard command language?
465 A standard command language, supported by all email list services,
466 would go a long way to reducing the problems of list access that
467 currently plague existing services. It would reduce the amount of
468 learning required by end users and allow for a number of common
469 support tools to be developed.
471 However, such standardization does pose problems in the areas of
472 multi-lingual support and the custom needs of individual mailing
473 lists. The development of such a standard is also expected to be met
474 with a slow adoption rate by software developers and list service
477 These points do not preclude the development of such a standard (in
478 fact, it would suggest that we should start sooner rather than
479 later), but we do need a solution that can be widely supported by the
480 current list services.
482 We can support most existing list manager command syntaxes without a
483 standard command language. By using URLs, we allow alternate access
484 methods a standard command language probably wouldn't enable, such as
487 Finally, client support for a standard command language is not at all
488 clear or necessarily simple to implement. The variety and large
489 number of commands existing today would require complicated user
490 interfaces which could be confusing and difficult to implement. By
491 restricting this proposal to the core functions, the client
493 implementation is much simpler, which significantly increases the
494 likelihood of implementation (as evidenced by the support already
495 announced by a number of client and server application authors).
497A.4. Internationalization
499 Multilingual support is up to the URL standard. If URLs support it,
500 then the List- header fields support it. This is another advantage of
501 using URLs as the building blocks for the list header fields.
506Neufeld & Baer Standards Track [Page 9]
508RFC 2369 URLs as Meta-Syntax July 1998
511A.5. Variable Substitution
513 Variables would allow the List- header fields to accommodate nearly
514 every existing list manager. However, it would immeasurably increase
515 the complexity of the entire proposal, and possibly involve
516 redefining the URL standard, or force us to use something more
517 complicated (and hence more difficult to implement) than URLs to
518 describe the command syntax.
520 Parameters would either have to be mandatory (i.e. the user agent
521 doesn't submit the message if it doesn't know what text to
522 substitute) or you need a way to say "if you know this parameter, add
523 its text here; otherwise, do this" where "this" is either: (a)
524 substitute a constant string, or (b) fail.
526 The reason you would want a facility like this is because some list
527 server applications insist on having certain parameters like users'
528 names, which the user agent might or might not know. e.g. listserv
529 insists on having a first name and a last name if you supply either
532 Which could lead to something like the UNIX shell syntax, where
533 ${foo-bar} means substitute the value of parameter "foo" if "foo" is
534 defined, else substitute the string "bar". Perhaps $foo would mean
535 "substitute the value of parameter foo if it is defined, else
536 substitute the empty string"
538 This all seems far too complicated for the gains involved, especially
539 since the use of variables can often be avoided.
541 The use of variables in the command syntaxes of list services appears
542 to be lessening and does not, in any case, apply to all commands.
543 While the unsubscribe and subscribe command header fields may not be
544 usable by those systems which require the use of variables, the help
545 field will still provide end users with a consistent point of access
546 through which they can get support for their use of the list.
548A.6. Why not use a specialized MIME part instead of header fields?
550 MIME parts were considered, but because most mail clients currently
551 either don't support MIME or are not equipped to handle such
552 specialized parts - such an implementation would result in problems
553 for end users. It is also not as easy for many list servers to
554 implement MIME as it is to implement new header fields.
556 However, we are looking at the design of a MIME part to more fully
557 describe list command syntax, as well as trying to find ways to get
558 it supported by the applicable software.
562Neufeld & Baer Standards Track [Page 10]
564RFC 2369 URLs as Meta-Syntax July 1998
567A.7. Why include a Subscribe command?
569 Subscribe and Unsubscribe are the key commands needed by almost every
570 list. Other commands, such as digest mode, are not as widely
573 Additionally, users who have unsubscribed (before going on vacation,
574 or for whatever other reason) may want to resubscribe to a list. Or,
575 a message may be forwarded/bounced from a subscriber to a non-
576 subscriber. Or, the user may change addresses and want to subscribe
577 from their new address. Having the List-Subscribe field available
578 could certainly help in all these cases.
580A.8. The Dangers of Header Bloat
582 At what point are there just too many header fields? It really
583 varies on a list by list basis. On some lists, the majority of users
584 will never be aware of a field unless the client software provides
585 some alternative user interface to it (akin to the Reply-To field).
586 On others, the users will often see the header fields of messages and
587 would be able to recognize the function of the URLs contained within.
589 The flexibility afforded by the protocol described in this document
590 (in that the header fields may be individually implemented as deemed
591 appropriate) provides list administrators with sufficient 'room to
592 maneuver' to meet their individual needs.
618Neufeld & Baer Standards Track [Page 11]
620RFC 2369 URLs as Meta-Syntax July 1998
623B. Client Implementation
627 For 'mailto' URL based commands, mail client applications may choose
628 to provide specialized feedback (such as presenting a dialog or
629 alert), instead of the actual command email message, asking for
630 command confirmation from the user. The feedback should identify the
631 message destination and command within a more descriptive
632 explanation. For example:
634 "Do you want to send the unsubscription command 'unsubscribe
635 somelist' to 'somelist-request@some.host.com'? Sending the command
636 will result in your removal from the associated list."
638 If the user has multiple email addresses supported by the mail
639 client, the client application should prompt the user for which
640 address to use when subscribing or performing some other action where
641 the address to use cannot be specifically determined. When
642 unsubscribing or such, the address that is subscribed should be used,
643 unless that is not known by the application and cannot be determined
644 from the message headers.
646B.2. Implementation Options
648 The following implementation possibilities are suggested here to give
649 some idea as to why these new header fields will be useful, and how
650 they could be supported.
652 In most cases, it may be helpful to disable the interface for the
653 commands when not applicable to the currently selected message.
655B.2.1. Key combinations and command lines
657 On text based systems which utilize command lines or key
658 combinations, each field could be implemented as a separate command.
659 Thus one combination would subscribe the user, another would
660 unsubscribe, a third request help, etc. The commands would only be
661 available on messages containing the list header fields.
665 On graphical systems which have menus, these commands could take the
666 form of a menu or sub-menu of items. For example, a "Lists" menu
667 might appear when viewing messages containing the header fields, with
668 items named "Subscribe", "Unsubscribe", "Get Help", "Post Message to
674Neufeld & Baer Standards Track [Page 12]
676RFC 2369 URLs as Meta-Syntax July 1998
679 List", "Contact List Owner" and "Access List Archive". This menu
680 could be disabled when not applicable to the current message or
683B.2.3. Push Buttons and Pallettes
685 On graphical window systems, buttons could be placed in the window of
686 the message, a toolbar, or in a floating pallette of their own. Each
687 button could correspond to a command, with names "Subscribe",
688 "Unsubscribe", "Get Help", "Post to List", "List Owner" and
689 "Archive". These buttons or pallettes could be disabled when not
690 applicable to the current message or disappear entirely.
692B.2.4 Feedback to the User
694 If using a dialog interface (or other feedback element) the client
695 application MUST include an option for the user to review (and
696 possibly modify) the message before it is sent. The application may
697 also find it useful to provide a link to more detailed context-
698 sensitive assistance about mail list access in general.
702 [RFC822] Crocker, D., "Standard for the Format of ARPA
703 Internet Text Messages", STD 11, RFC 822, August 1982.
705 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill,
706 "Uniform Resource Locators (URL)" RFC 1738, December 1994.
708 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and
709 Functions", RFC 2142, May 1997.
711 [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL
712 scheme", RFC 2368, July 1998.
714 [5] "List-Header" Mail list. list-header@list.nisto.com
715 <URL:http://www.nisto.com/listspec/mail/>
716 <URL:http://www.nisto.com/listspec/>
718 [6] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com
719 <URL:http://cgi.skyweyr.com/ListMom.Home>
730Neufeld & Baer Standards Track [Page 13]
732RFC 2369 URLs as Meta-Syntax July 1998
740 Pittsburgh, PA 15213-3799
743 EMail: josh@skyweyr.com
751 Web: http://www.nisto.com/
786Neufeld & Baer Standards Track [Page 14]
788RFC 2369 URLs as Meta-Syntax July 1998
791Full Copyright Statement
793 Copyright (C) The Internet Society (1998). All Rights Reserved.
795 This document and translations of it may be copied and furnished to
796 others, and derivative works that comment on or otherwise explain it
797 or assist in its implementation may be prepared, copied, published
798 and distributed, in whole or in part, without restriction of any
799 kind, provided that the above copyright notice and this paragraph are
800 included on all such copies and derivative works. However, this
801 document itself may not be modified in any way, such as by removing
802 the copyright notice or references to the Internet Society or other
803 Internet organizations, except as needed for the purpose of
804 developing Internet standards in which case the procedures for
805 copyrights defined in the Internet Standards process must be
806 followed, or as required to translate it into languages other than
809 The limited permissions granted above are perpetual and will not be
810 revoked by the Internet Society or its successors or assigns.
812 This document and the information contained herein is provided on an
813 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
814 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
815 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
816 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
817 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
842Neufeld & Baer Standards Track [Page 15]