[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                    Bryan Costales
Request for Comments: DRAFT                               InfoBeat, Inc.
<draft-costales-subscribe-01.txt>                             April 1997


                  E-Mail Headers to Facilitate Mailing
                 List Subscriptions and Unsubscriptions


Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   The number of ways to subscribe-to (and to unsubscribe-from) e-mail
   mailing lists is as varied as the number of programmers designing
   mailing list software. For some lists, for example, users
   (un)subscribe by sending a request to <listname>-request@host.domain.
   For others lists the address is majordomo@host.domain with the
   request to (un)subscribe embedded in the message body. Yet others set
   up special hosts to satisfy this need, such as <listname>@list-
   off.domain.  In this Internet Draft we offer two new e-mail headers
   intended to make mailing list subscription and unsubscription easier
   and more uniform: List-Subscribe and List-Unsubscribe.

Discussion

   Naive users, over time, rely more and more on the ``smart'' features
   of Mail User Agent programs to solve complex needs. Filtering in
   bound e-mail is on such feature. Automating subscription to and
   unsubscription from mailing lists could be another. Consider, for
   example, a typical (but abbreviated) mailing list message.




Costales                                                        [Page 1]


INTERNET-DRAFT                                                April 1997


           To: you@your.domain
           From: list@example.domain (Mailing List Site)
           Subject: Your mass mailing for today
           Comment: to unsubscribe send a message to list-cancel@example.domain
           X-List-Unsubscribe: list-cancel@example.domain

           ... 50 or so lines of message contents

           * To unsubscribe from this Mailing List, send an e-mail message to
             list-cancel@example.domain.

   Here, three problems with this message prevent easy automation of the
   unsubscription process:

   (1) The Comment header describes how to unsubscribe from the mailing
   list.  Unfortunately, it is in free-form text, inappropriate for
   automatic parsing. Also, because the Comment header is a general
   purpose header, there is no guarantee that any addresses found in it
   are those used for unsubscription purposes.

   (2) The X-List-Unsubscribe header, because it begins with an X-, is a
   non-standardized header. Although some software may recognize it as
   specifying an address for unsubscription, other software will not.
   The leading X- prevents any requirement that all software recognize
   its special meaning.

   (3) The trailing text in the message body also describes how to
   unsubscribe. This is perhaps the most common and least easily
   automated form for providing unsubscription information.

The List-Subscribe and List-Unsubscribe headers

   One method to specify mailing-list subscription and unsubscription
   information in an e-mail message is to include an appropriate, and
   corresponding List-Subscribe and List-Unsubscribe header. The List-
   Subscribe specifies the address (or URL, see below) to which e-mail
   must be sent to subscribe to a mailing list. The List-Unsubscribe
   header specifies the address (or URL) to which e-mail must be sent to
   unsubscribe  from a mailing list.

   The field-body (the text to the right of the colon following the
   header name) for these headers shall be either a bare address
   specification or a mailto URL.

A Bare Address

   When the address specification in the field-body may be that of an
   RFC822 recipient including address commentary. For example:



Costales                                                        [Page 2]


INTERNET-DRAFT                                                April 1997


           List-Unsubscribe: Stop Getting This <listname+off@host.domain>
           List-Subscribe: listname+on@host.domain (Join The List)

   The recipient address specification in the field-body is in every way
   identical to that for the ``To'' header, except that it may only list
   a single recipient.

The Mailto URL

   When the address part of the address specification in the field-body
   is surrounded by a '<' and '>' pair, and when the first non-
   whitespace characters following the '<' are ``mailto:'', the address
   specification shall be interpreted as a mailto URL. For example:

           List-Unsubscribe: <mailto: listname+off@host.domain>
           List-Subscribe: <mailto: listname+on@host.domain>

   Currently, only an e-mail address may appear in a mailto URL.  Future
   enhancements may include the ability to include other header and body
   information. When legal, such use of extensions are recommended. For
   example:

           List-Unsubscribe:
                <mailto: majordomo@host.domain?body=unsubscribe>

Security Considerations

   If mail user agents are careless when using the List-Subscribe and
   List-Unsubscribe headers, risk develops that a user may inadvertently
   ``spam'' or otherwise misuse a mailing list.

   These headers should only provide a template for addresses that can
   be used by user agent software.  A user agent should never send a
   message based on these headers without first showing the user the
   full message that will be sent (including all headers), fully
   decoded, and asking the user for approval to send the message.  The
   user agent should also make it clear that the user is about to
   subscribe-to or to unsubscribe-from a mailing list.













Costales                                                        [Page 3]


INTERNET-DRAFT                                                April 1997


Author's  Address:

   Bryan Costales
   InfoBeat, Inc.
   Denver, Colorado 80202 USA
   Tel: 303-295-0335
   bcx@infobeat.com












































Costales                                                        [Page 4]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/