RARE-DRAFT Jeroen Houttuin IESG Mail Applicability Design Team RARE Secretariat 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]