RARE-DRAFT                                              Jeroen Houttuin
IESG Mail Applicability Design Team                    RARE Secretariat
<draft-rare-msg-c-bombs-01.txt>                              April 1994


              Bombs series: Behaviour of Mail Based Servers
                             Part 1: C-bombs
             Classification of Breeds of Mail Based Servers


Abstract

   This document defines a classification of Mail Based Servers (MBSs)
   according to their behaviour towards their users. The most important
   distinction is between mail responders (e.g. echo servers, file
   servers) and mail forwarders (e.g. mailing lists, auto-forwarders).
   The document aims at a common understanding of these MBS classes and
   other common MBS attributes, such as roles (administrators, owners),
   MBS lifetime and restricted MBS use.

Status of this Memo

   This document is a RARE Draft. RARE Drafts form a subseries of the
   Internet Drafts, which 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. For example, RARE Drafts are produced by the RARE
   Working Groups.

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

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

   Distribution of this memo is unlimited.

   The predecessor of this document (H-bombs) has been presented and
   discussed in several groups since late 1992: the RARE Working Group
   on Mail and Messaging (WG-MSG), The GO-MHS managers group, the IETF
   X400ops Working Group and the IFIP E-Mail Management Group. It was
   then taken over by the IESG solicited "Mail Applicability Statement"
   design team in June 1993. In order to make the subject more

   manageable, the design team decided to break down the document into
   one base document defining the different classes of MBSs (this
   document: C-bombs), which is to become in informational RFC / RTR.
   Standard track RFCs defining the behaviour of MBSs (e.g. other parts





RARE WG-MSG            Expires October 1994                     [Page 1]


INTERNET-DRAFT                C-bombs                         April 1994


   of H-bombs describe header behaviour) will be based upon the
   definitions of C-bombs.

   Depending on the nature of your comments, please send them to one of
   the following addresses:

         The main discussion group:       wg-msg@rare.nl
         The design team:                 mail-as@infoods.unu.edu
         The author:                      houttuin@rare.nl


Contents

   1. Introduction                                                   2
   2. Definitions                                                    3
      2.1. MBS                                                       3
      2.2. Implementation levels and protocols                       4
      2.3. Input- and output messages                                4
      2.4. Roles                                                     4
      2.5. Dedicated and non-dedicated MBSs                          5
      2.6. Message originator                                        5
      2.7. Exception messages                                        6
      2.8. Access permission                                         6
   3. Mail based server classification                               6
      3.1. Repliers                                                  6
           3.1.1. Echo servers                                       7
           3.1.2. Mailer demons                                      7
           3.1.3. Command servers                                    8
           3.1.4. Vacation servers                                   8
      3.2. Forwarders                                                9
           3.2.1. Distribution Lists                                 9
           3.2.2. Redirectors                                        9
           3.2.3. Auto-forwarders                                    9
   4. Implementations                                                9
   5. Security considerations                                       10
   6. Bibliography                                                  10
   7. Abbreviations                                                 12
   8. Author's Address                                              12


1. Introduction


   Electronic mail systems are increasingly being used as a basis for so
   called Mail Based Servers (MBSs), such as echo servers, distribution
   lists, file distribution servers, etc. MBSs are used for a number of
   purposes:

     - Enhancing the Message Handling Environment. Examples of such
       usage are distribution lists (DLs), for group communication, and
       e-mail servers, for file and information retrieval.



RARE WG-MSG            Expires October 1994                     [Page 2]


INTERNET-DRAFT                C-bombs                         April 1994


     - Monitoring the status of the MHS. Examples of this usage are
       echo servers and forced (non-)delivery messages (E.g. the so-
       called nosuchuser test).

   Since MBSs deal with automatically receiving, forwarding and replying
   to messages, which may themselves have been generated by automated
   processes, strong requirements are needed on the one hand to minimise
   human effort to manage such servers, and on the other hand to make
   the behaviour of mail based servers deterministic enough to build
   reliable tools upon them.

   A classic example of what can go wrong is when a mailing list
   contains an invalid address. The remote mailer generates a non-
   delivery message and sends it to the originator of the original
   message, which, under some circumstances, could be the list itself,
   which then distributes the non-delivery message to the list, and thus
   also to the erroneous address, etc. etc. Following strict
   recommendations on how mailing lists should deal with message header
   fields can avoid such looping-endangered situations.

   This document aims to facilitate such standardisation of MBS
   behaviour by defining a classification of MBSs and describing which
   attributes belong to each MBS class.


2. Definitions


   This chapter defines some attributes that are common to all MBSs.


2.1. MBS

   An MBS is a process that automatically generates one or more messages
   (the output messages) as a result of receiving a message (the input
   message).

   The number of output messages and its contents depend on the kind of
   server and on the contents of the input message.

   Note that our definition rules out a number of mail based
   applications:

     - A process that is in someway triggered by an input message, but
       does not necessarily generate an output message. Think of
       process control applications.

     - Applications that need more than one input message to trigger
       the generation of an output message. For such work flow
       management types of applications, it is already nearly
       impossible to define globally applicable rules for how the
       recipient of the output message(s) should be determined. It is


RARE WG-MSG            Expires October 1994                     [Page 3]


INTERNET-DRAFT                C-bombs                         April 1994


       however possible to treat an MBS as a special subclass of such
       systems, namely where the number of input messages is exactly
       one. Hopefully this document can be used as a starting point for
       later studies on the behaviour of more complex systems.

     - Applications that do not completely automatically generate
       output messages. This rules out mail based applications that
       need (human) intervention, such as moderated distribution lists.


2.2. Implementation levels and protocols

   An MBS can be modelled and implemented in one of the following ways:

   In Internet terminology: As a process built directly on top of SMTP.
   This is called an 821 MBS. If, in addition, the MBS is RFC 822 based,
   it is called an 822 MBS.

   In X.400 terminology: within the MTS, in which case it can be
   considered an enhancement of the X.400 message dispatcher (see [11]).
   This is called a P1 MBS. Or, as an MTS service user, in which case it
   can be considered an automated User Agent (UA). Per default, this is
   called a P3 MBS. If, in addition, the MBS is P2 based, it is called a
   P2 MBS.

   Regardless whether an MBS is X.400 or RFC based, we will use the
   following terms for implementation levels:

     UA level:      RFC 822, MIME, P2, P22, P7.
     MTS level:     RFC 821, P3.
     MTA level:     RFC 821, P1.


2.3. Input- and output messages

   An input message is a message that triggers the generation of one or
   more output messages by an MBS.

   An output message is a message that is being generated by an MBS as a
   result of receiving an input message.


2.4. Roles

   For every dedicated MBS, there exists an MBS administrator who is
   responsible for managing the MBS. This person, or group of persons,
   must track down, act upon and be informed about possible malbehaviour
   of the server, such as loops, unreachable addresses on mailing lists
   and rejected messages.





RARE WG-MSG            Expires October 1994                     [Page 4]


INTERNET-DRAFT                C-bombs                         April 1994


   Other possible roles related to the management of an MBS are:

     Owner          Has the responsibility for the existence of the
       MBS.
     Operator       Operates the hard- and software.
     Moderator      Moderates a mailing list.
     Other          Many other roles can be thought of.

   Note that in practice, most of these roles will be played by one and
   the same person. The most important role in this document is that of
   the MBS administrator.


2.5. Dedicated and non-dedicated MBSs

   A dedicated MBS is an MBS that is meant to be used as an MBS only.
   Examples of non-dedicated MBSs are temporarily auto-forwarding user
   agents (UAs), and UAs that automatically send back vacation notes
   (vacation servers). Although software developers are encouraged to
   implement such features as if it concerned a dedicated MBS, there are
   some differences between the two types. For instance, it is not
   realistic to assume a separate MBS administrator for every stand-
   alone UA. Also, non-dedicated MBSs often have a limited life time.


2.6. Message originator

   A number of definitions and behaviour rules for MBSs require a clear
   understanding of the term 'message originator'. In particular, the
   originator of the input message must be well defined. Depending on
   implementation level and protocols, a message originator is defined
   as follows:

     - For Internet Mail: The UA-level originator of an input message
       is defined as the RFC 822 Sender: , and in the absence of that
       header, the RFC 822 From:

     - For X.400: The UA-level originator of an input message is
       defined as the P2.originator, or if this attribute is not
       present, the P2.authorizingUsers

   Exception messages are always sent to the MTS-level originator, which
   is defined as:

     - For Internet Mail: The MTS-level originator of the input message
       is defined as the MAIL FROM: address. For RFC 822 based MBSs
       that, for some reason, cannot access the MAIL FROM: address, the
       MTS-level originator of an input message is defined as the RFC
       822 Return-Path: . If this header is not available either, the
       MTS-level originator of an input message is defined as the RFC
       822 Sender: , and in the absence of that header, the RFC 822
       From:


RARE WG-MSG            Expires October 1994                     [Page 5]


INTERNET-DRAFT                C-bombs                         April 1994



     - For X.400: The MTS-level originator of an input message is
       defined as the P1 or P3 originator. For P2 based MBSs that
       cannot access P3 attributes, the MTS-level originator of an
       input message is defined as the P2.originator, or if this
       attribute is not present, the P2.authorizingUsers.

   These definitions are based on [1], [2], [11] and [12].

   In the remainder of this document, the term 'originator' is used to
   refer to either a UA- or an MTS-level originator.


2.7. Exception messages

   An exception message is a message that is generated by the MBS
   instead of a normal output message. It is addressed to the MBS
   administrator only and contains in readable format (ASCII, MIME,
   IA5Text, ASN.1) both a description of the reason why the exception
   message was generated as well as a complete as possible copy of the
   original input message. Exceptions messages are normally generated
   when some header conditions are violated. The precise rules for this
   can be found in the follow up documents in this series (e.g. [9]).


2.8. Access permission

   Associated with an MBS is a number of originator addresses that are
   allowed to use the MBS (i.e. to have the MBS send output messages).
   Implementation of MBS access permission is considered a local matter.
   The main implementation options are:

     - Implicit: Only those addresses explicitly listed are not allowed
       to send messages to the MBS.

     - Explicit: Only those addresses explicitly listed are allowed to
       send messages to the MBS.


3. Mail based server classification


   This chapter defines the different types of MBSs. Two main types are
   identified: repliers and forwarders.


3.1. Repliers

   Intuitively speaking, a replier is an MBS that will send an output
   message to the originator of the input message. There are also
   exceptions to this rule, such as replying to a Reply-To: field. More
   formally speaking, a replier is characterised by the fact that the


RARE WG-MSG            Expires October 1994                     [Page 6]


INTERNET-DRAFT                C-bombs                         April 1994


   recipient of the output message is uniquely defined in (the heading
   of) the input message. The different types of repliers can be
   classified by the number and content of the output message.

   Implementation level: Most existing repliers operate at UA level.

   Associated roles: administrator, owner, operator.

   Access permissions: any.


3.1.1. Echo servers

   An echo server is a dedicated replier that will generate exactly one
   output message, containing at least the input message.

   Implementation level: Although most existing echo servers operate at
   UA level, this is not a necessity.

   Associated roles: administrator, owner, operator.

   Access permissions: mostly implicitly public, but any other options
   possible.


3.1.2. Mailer demons

   This document does not consider X.400 delivery reports and
   notifications, which are assumed to be well defined in X.400 already.
   The MTA can be thought of as an MBS, whose administrator is the
   administrator of the MTA.

   RFC 822 mailers and RFC 1327 gateways however can generate a message
   explaining the (NON-)Delivery of an input message, a so-called
   Delivery Message (DM). In this case the mailer/gateway is acting as
   an MBS.

   Mailer demon behaviour of is well defined in other documents, such as
   RFC 821 and RFC 1123. The MBS administrator is the administrator of
   the mailer/gateway.

   A gateway should ideally behave as a normal mailer demon or MTA when
   a message is not deliverable. In practice however, the following may
   occur. The gateway accepts from the Internet mail side a message in
   which it recognises an RFC 822 encoded X.400 address. The gateway
   performs the gatewaying and then discovers that the X.400 message is
   not deliverable. The gateway has two options in this case. Either it
   creates an X.400 non-delivery report and gateways it back to the
   Internet mail world, or it immediately generates an RFC non-delivery
   message (the inverse scenario is also possible).




RARE WG-MSG            Expires October 1994                     [Page 7]


INTERNET-DRAFT                C-bombs                         April 1994


   Implementation level: Internet mailer demons conceptually operate at
   MTA or MTS level, although, as usual with Internet mailers, they may
   interpret and under circumstances even _add_ UA level information.
   This especially holds for mail protocol gateways.

   Associated roles: administrator, owner, operator (normally
   administrator = owner = operator = 'postmaster').

   Access permissions: implicitly public.


3.1.3. Command servers

   The contents of an output message generated by a command server
   depend on commands that were included in the input message. Concrete
   examples are file servers, e-mail archie servers, DL-registration
   servers and address conversion servers.

   Note that an echo server can in some ways be regarded as a special
   type of command server, namely one that echoes the input message.

   Implementation level: All known command servers operate at UA level,
   but this is not a necessity.

   Associated roles: administrator, owner, operator.

   Access permissions: any.


3.1.4. Vacation servers

   Some UAs have an auto-reply feature that will temporarily and/or
   conditionally turn the UA into an MBS. Thus a vacation server is a
   non-dedicated replier. The content of the output message is often a
   note such as 'I am on holidays.'  A vacation server has a certain
   lifetime, which is defined as the time span between switching the
   vacation server on and back off again.

   Implementation level: Mostly at UA level.

   Associated roles: administrator, owner, operator (normally
   administrator = owner = mailbox-user. On stand-alone UAs often also
   operator = mailbox-user).

   Access permissions: Implicitly public. During the lifetime a user has
   access to the vacation server only once, i.e. a no-access list is
   automatically built from the originators of the input-messages.







RARE WG-MSG            Expires October 1994                     [Page 8]


INTERNET-DRAFT                C-bombs                         April 1994


3.2. Forwarders

   A forwarder is an MBS that will send its output messages to a list of
   recipients. These recipients are independent of (the heading of) the
   input message.

   Implementation level: any.

   Associated roles: administrator, owner, operator, moderator.

   Access permissions: any.


3.2.1. Distribution Lists

   Upon receiving an input message, a DL will generate output messages
   to a list of DL members, which is managed by the DL administrator.

   At the moment many vendor-specific implementations of DLs exist. Some
   of these are nothing more than local multi-recipient aliases, others
   use local directories for DL expansion. This document defines the
   requirements for DLs as well as implementation options.

   Implementation level: any.

   Associated roles: administrator, owner, operator, moderator.

   Access permissions: any.


3.2.2. Redirectors

   Some MTAs have a redirection feature that will temporarily and/or
   conditionally turn the MTA into an MBS. Thus a redirector can be
   considered a non-dedicated forwarder. Upon receiving an input
   message, an auto-forwarder will submit an output message to a locally
   defined (list of) address(es).

   Like a vacation server, a redirector often has a certain lifetime.

   Implementation level: MTA.

   Associated roles: administrator, owner, operator.

   Access permissions: mostly implicitly public.


3.2.3. Auto-forwarders

   Some UAs have an auto-forward feature that will temporarily and/or
   conditionally turn the UA into an MBS. Thus an auto-forwarder can be
   considered a non-dedicated forwarder. Upon receiving an input


RARE WG-MSG            Expires October 1994                     [Page 9]


INTERNET-DRAFT                C-bombs                         April 1994


   message, an auto-forwarder will submit an output message to a locally
   defined (list of) address(es), which is managed by the owner of the
   UA.

   Although an auto-forwarder often has a certain lifetime, like a
   vacation server, this has no implications for the requirements for
   auto-forwarders.

   The main difference with a redirector is that an auto-forwarder
   conceptually operates at UA level. In almost all cases redirection is
   to be preferred over auto-forwarding.

   Implementation level: UA.

   Associated roles: administrator, owner, operator (normally
   administrator = owner = mailbox-user. On stand-alone UAs often also
   operator = mailbox-user).

   Access permissions: mostly implicitly public.


4. Implementations


     A by no means complete list of implementations follows:

     AUSSIE         (echo server)
     Concord        (echo server, DLs)
     EAN            (DLs, auto-forwarding, auto-answer, echo)
     Echoput        (echo server)
     LISTSERV       (DLs, command server, file server)
     mailbase       (DLs, command server, file server)
     majordomo      (DLs, command server, file server)
     PP             (DLs, auto-answer, echo server)
     Squirrel       (command server)


5. Security considerations


   Security issues are not discussed in this memo.


6. Bibliography


      [1]         Jonathan B. Postel, "Simple Mail Transfer Protocol",
                  RFC 821, University of Southern California, August
                  1982

      [2]         Crocker, D., "Standard of the Format of ARPA Internet
                  Text Messages", RFC 822, UDEL, August 1982.


RARE WG-MSG            Expires October 1994                    [Page 10]


INTERNET-DRAFT                C-bombs                         April 1994



      [3]         R. Braden, Editor, "Requirements for Internet Hosts -
                  - Application and Support", RFC 1123, USC/Information
                  Sciences Institute, October 1989.

      [4]         Kille, S., "Mapping between X.400(1988) / ISO 10021
                  and RFC 822", RFC 1327, UCL, May 1992.

      [5]         Westine, A. & Postel, J., "Problems with the
                  Maintenance of Large Mailing Lists", RFC 1211, March
                  1991.

      [6]         N. Borenstein, N. Freed, MIME (Multipurpose Internet
                  Mail Extensions), RFC 1341, June 1992

      [7]         J. Houttuin, "Concord functional specification",
                  COSINE MHS server, Mail: cosine-mhs-
                  server@nic.switch.ch, FTP: nic.switch.ch, Username:
                  cosine , File: tools/operational/concord/xxxxxxxx

      [8]         Houttuin, J., "H-bombs: Header Behaviour of Mail
                  Based Servers", work in progress, November 1993.

      [9]         Houttuin, J., "A-bombs: Answering Servers: Behaviour
                  of MBSs", work in progress, April 1994.

      [10]        Houttuin, J., "Classifications in e-mail routing",
                  Computer Networks for Research in Europe, CNETDP 25
                  (Suppl. 2), 0169-7552, S72-S81, Elsevier, December
                  1993.

      [11]        CCITT Recommendations X.400 - X.430. Data
                  Communication Networks: Message Handling Systems.
                  CCITT Red Book, Vol. VIII - Fasc. VIII.7, Malaga-
                  Torremolinos 1984

      [12]        CCITT Recommendations X.400 - X.420. Data
                  Communication Networks: Message Handling Systems.
                  CCITT Blue Book, Vol. VIII - Fasc. VIII.7, Melbourne
                  1988














RARE WG-MSG            Expires October 1994                    [Page 11]


INTERNET-DRAFT                C-bombs                         April 1994


7. Abbreviations

      ASCII    American Standard Code for Information Exchange
      CCITT    Comite Consultatif International de Telegraphique et
               Telephonique
      COSINE   Co-operation for OSI networking in Europe
      DL       Distribution List
      DM       Delivery Message
      EAN      X.400 software (not an abbreviation)
      IPM      Inter-Personal Message
      IPN      Inter-Personal Notification
      ISO      International Organisation for Standardisation
      MHS      Message Handling System
      MBS      Mail based server
      MTA      Message Transfer Agent
      MTS      Message Transfer System
      NJE      Network Job Entry
      NRN      Non-Receipt Notification
      PP       MHS software (not an abbreviation)
      RARE     Reseaux Associes pour la Recherche Europeenne
      RFC      Request for Comments
      RN       Receipt Notification
      RTR      RARE Technical Report
      SMTP     simple mail transfer protocol
      UA       User Agent


8. Author's Address


   Jeroen Houttuin

   RARE Secretariat
   Singel 466-468
   NL-1017 AW  Amsterdam
   Europe

   Tel +31 20 6391131
   Fax +31 20 6393289

   RFC 822     houttuin@rare.nl
   X.400 /S=houttuin/O=rare/PRMD=surf/ADMD=400net/C=nl/












RARE WG-MSG            Expires October 1994                    [Page 12]