RARE-DRAFT                                            Jeroen Houttuin
IESG Mail Applicability Design Team                            TERENA
<draft-rare-msg-c-bombs-02.txt>                         December 1994
                                    
                                    
                                    
              BoMBS series: Behaviour of Mail Based Servers
                             Part 1: C-BoMBS
             Classification of Breeds of Mail Based Servers


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.
   
   Depending on the nature of your comments, please respond 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


Abstract
   
   This document defines a classification of Mail Based Servers (MBSs)
   based on 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 global understanding of these MBS classes and
   other common MBS attributes, such as roles (administrators, owners),
   MBS lifetime and restricted MBS use.








TERENA WG-MSG          Expires June 1995                        [Page 1]

INTERNET-DRAFT                C-bombs                      December 1994


Contents

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


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.
     
     - 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.
   



TERENA WG-MSG          Expires June 1995                        [Page 2]

INTERNET-DRAFT                C-bombs                      December 1994


   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 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. Mail Based Server
   
   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 this definition rules out a number of mail based
   applications:
     
     - A process that is in some way 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, such as work flow management
      types of applications. It is 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. Note
      however that it will often be desirable to perform human
      intervention as transparently as possible, so that the basic
      (header) behaviour of such systems still appear exactly the same
      as real MBSs, i.e. similar systems without human intervention.




TERENA WG-MSG          Expires June 1995                        [Page 3]

INTERNET-DRAFT                C-bombs                      December 1994


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
   
   Although this may intuitively be clear from chapter 2.1.:
   
   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
   
   Associated with an MBS can be many roles, which are often implemented
   as humans. The most important role in this document is that of the
   MBS administrator. Some roles may also be automated, and may in fact
   even be implemented as MBSs themselves. For instance, the address of
   an MBS administrator may be a distribution list (see 3.2.1) which
   forwards requests to a number of people who share the administrator
   role. Another example is automatic list (un)subscription implemented
   by means of a command server (see 3.1.3). In either case, the MBS
   implementing the MBS role will itself have roles associated with it
   as well, so in the end a human will still be responsible....
   
   For every dedicated MBS, there exists an MBS administrator who is
   responsible for managing the MBS. This person, or group of persons,
   is responsible for the correct behaviour of the MBS (as defined in
   the remainder of the BoMBS series). The administrator must also track
   down, act upon and be informed about possible malbehaviour of the



TERENA WG-MSG          Expires June 1995                        [Page 4]

INTERNET-DRAFT                C-bombs                      December 1994


   server, such as loops, unreachable addresses on mailing lists and
   rejected messages.
   
   Other possible roles related to the management of an MBS are:
    
    Owner             Has the responsibility for the existence and
                       nature of the MBS. Typically, in case of a
                       distribution list, the owner has authority over
                       the members of the list.
    Moderator         A role used for mailing lists. The moderator can
                       filter input messages to ensure the quality of
                       messages sent through a list. The moderator may
                       sometimes even edit the contents of input
                       messages in the filtering process.
    Other             Many other roles can be thought of.
   
   Note that in practice, these roles will often be played by one and
   the same person.


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 standalone
   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:
     



TERENA WG-MSG          Expires June 1995                        [Page 5]

INTERNET-DRAFT                C-bombs                      December 1994


     - 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:
     
     - 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 instead of a
   normal output message by the MBS. 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.









TERENA WG-MSG          Expires June 1995                        [Page 6]

INTERNET-DRAFT                C-bombs                      December 1994


3. MBS classification
   
   This chapter defines the different types of MBSs. Two main types are
   identified: repliers and forwarders. Per type of MBS, the usual
   implementation levels, associated roles and access permissions are
   also listed.


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
   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.
     
     Access permissions:   any.


3.1.1. Echo servers

   
   An echo server is a dedicated replier that will generate exactly one
   output message, which normally contains at least a copy of the input
   message.
     
     Implementation level: Although most existing echo servers operate
                            at UA level, this is not a necessity.
     
     Associated roles:     administrator, owner.
     
     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



TERENA WG-MSG          Expires June 1995                        [Page 7]

INTERNET-DRAFT                C-bombs                      December 1994


   Delivery Message (DM). In this case the mailer/gateway is acting as
   an MBS.
   
   Mailer demon behaviour 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).
     
     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 (normally
                            administrator = owner = '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.
     
     Access permissions:   any.







TERENA WG-MSG          Expires June 1995                        [Page 8]

INTERNET-DRAFT                C-bombs                      December 1994


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: UA level.
     
     Associated roles:     administrator, owner (normally
                            administrator = owner = 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.


3.2. Forwarders
   
   A forwarder is an MBS that will send its output messages to a list of
   (one or more) recipients. These recipients cannot be algorithmically
   determined from (the heading of) the input message, as is the case
   with repliers.
     
     Implementation level: any.
     
     Associated roles:     administrator, owner, 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.
     
     Implementation level: any.
     
     Associated roles:     administrator, owner, moderator.
     
     Access permissions:   any.



TERENA WG-MSG          Expires June 1995                        [Page 9]

INTERNET-DRAFT                C-bombs                      December 1994



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).
     
     Implementation level: MTA.
     
     Associated roles:     administrator, owner.
     
     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
   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.
     
     Implementation level: UA.
     
     Associated roles:     administrator, owner (normally
                            administrator = owner = mailbox-user).
     
     Access permissions:   mostly implicitly public.














TERENA WG-MSG          Expires June 1995                       [Page 10]

INTERNET-DRAFT                C-bombs                      December 1994


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. References
      
      [1]         Postel, J.B., "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.
      
      [3]         Braden, R., 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. and Postel, J., "Problems with the
                  Maintenance of Large Mailing Lists", RFC 1211, March
                  1991.
      
      [6]         Borenstein, N. and Freed, N., MIME (Multipurpose
                  Internet Mail Extensions), RFC 1341, June 1992
      
      [7]         Houttuin, J., "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.
      


TERENA WG-MSG          Expires June 1995                       [Page 11]

INTERNET-DRAFT                C-bombs                      December 1994


      [9]         Houttuin, J., "A-bombs: Answering Servers: Behaviour
                  of MBSs", work in progress, April 1994.
      
      [10]        Houttuin, J., "Classifications in e-mail routing",
                  RFC 17xx, RARE, September 1994.
      
      [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


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
   MIME            Multi-media Internet Mail Extensions
   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











TERENA WG-MSG          Expires June 1995                       [Page 12]

INTERNET-DRAFT                C-bombs                      December 1994


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/









































TERENA WG-MSG          Expires June 1995                       [Page 13]
