Mail Requirements Group Jeroen Houttuin INTERNET-DRAFT Allan Cargille September 1992 Requirements for mail based servers Abstract This document defines minimal requirements and recommendations that must be implemented in all mail based servers in the Internet e-mail community and all e-mail networks connected to it, such as the GO-MHS community. 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. 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. INTERNET-DRAFT September 1992 Contents 1. Introduction 1 2. Terminology 3 3. Mail based server types 4 3.1. Replier 5 3.1.1. Echo server 5 3.1.2. (NON)-Delivery Message 5 3.1.3. Command server 5 3.1.4. Auto-replier 5 3.2. Forwarder 6 3.2.1. Distribution List 6 3.2.2. Auto-forwarder 6 4. Requirements 6 4.1. General 7 4.2. Repliers 7 4.2.1. Echo-servers 8 4.2.2. (NON)-Delivery Messages 9 4.2.3. Command servers 9 4.3. Forwarders 10 4.3.1. Distribution Lists 10 4.3.2. Auto-forwarders 10 5. Recommendations 10 5.1. General 10 5.2. Repliers 11 5.2.1. Echo-servers 11 5.2.2. Command servers 11 5.3. Forwarders 12 5.3.1. Distribution Lists 12 5.3.2. Auto-forwarders 12 6. Mapping to X.400(88) and RFC 822 12 7. Acknowledgements 13 8. References 13 9. Authors' Addresses 14 1. Introduction Electronic mail systems are increasingly being used by automated processes, such as echo servers, distribution lists, etc. Although such applications differ widely in nature, they have many properties and problem areas in common and can be grouped under the term 'mail based servers'. Mail based servers are used for a number of purposes: - Enhancing the Message Handling Environment. Examples of such usage are distribution lists (DLs) and mail based file servers. Houttuin, Cargille Expires: April 1993 [page 1] INTERNET-DRAFT September 1992 - Monitoring the status of the MHS. Examples of this usage are echo servers and forced (non-)delivery messages (the so-called nosuchuser test). Since mail based servers deal with automatically receiving, forwarding and replying to messages, which may themselves have been generated by automatic 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 DL contains an invalid address. The remote mailer generates a non-delivery message and sends it to the originator of the original message, which, under circumstances, could be the DL itself, which then again distributes the non-delivery message to the non-existing recipient, etc. Following strict requirements on how a DL should handle message header fields will avoid such looping-endangered situations. A more complicated example of the usefulness of strong requirements for mail based servers is the following: suppose a distributed tool will check the connectivity of mailers by sending a message to an echo-server. The connectivity tool could request the echo to be sent to another component of the tool instead of to itself. If for some reason the address of that other component cannot be routed to, an automatically generated non-delivery message could be sent back to the echo server, which results in a message loop. Throughout this document, X.400(84) terminology is preferred to X.400(88) and RFC 822 for the following reasons - X.400 has more pre-defined message attributes than RFC 822 - X.400(88) has already defined a specific mechanism for DLs. This implies that a separate recommendation for a mail based server approach to DLs is only useful in the context of X.400(84) or RFC 822. - Requirements for mail based servers are needed now. Since most available products are X.400(84) implementations, this document will sort more effect if it uses X.400(84) terminology. Once expressed in X.400(84) terminology, most requirements can be mapped to RFC 822 and X.400(88) mail systems using Houttuin, Cargille Expires: April 1993 [page 2] INTERNET-DRAFT September 1992 RFC 1327 and X.400(84) to X.400(88) upgrading, respectively. For the reader's convenience, chapter 6 lists the used X.400(84) terminology together with their RFC 822 and X.400(88) equivalents. For those requirements that cannot be mapped implicitly, chapter 6 will also explicitly state how such requirements must be implemented for the other mail standards. The requirements defined in this document will as much as possible be aligned with comparable rules that either have already been defined in other standards (X.400(88) DLs) or have already been used for a long time (X.400(84) Status Reports; distribution lists in the Internet). 2. Terminology Mail based server (MBS) A mail based server is a process in an MHS that automatically generates (a) message(s) as a result of receiving a message. An MBS can be implemented/modelled in the following ways: - within the MTS, in which case it can be considered an enhancement of the X.400 message dispatcher. This is called a P1 MBS. - 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. Upon receiving a message, an MBS will generate at least one message, whose contents and list of recipients depend on - the kind of server - the contents and header of the received message. (Non-)Dedicated MBS A dedicated MBS is an MBS that is meant to be used as an MBS only. Examples of non-dedicated MBSs are auto- forwarding UAs, and UAs that automatically send back vacation notes (auto-repliers). Houttuin, Cargille Expires: April 1993 [page 3] INTERNET-DRAFT September 1992 MBS administrator For every dedicated MBS, there exists an MBS administrator who is responsible for managing the MBS. MBS Submit Permission Associated with an MBS is a list of addresses that are allowed to use the MBS (I.e. have the MBS send output messages). Implementation of MBS Submit 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. Messages An input message is a message that triggers the generation of (a) message(s) by an MBS. Depending on the implementation of the MBS, this is defined either as a P1.MPDU or as the parameters of an MTS.DELIVER.Indication. An output message is a message that is being generated by an MBS as a result of a received input message. Depending on the implementation of the MBS, this is defined either as a P1.MPDU or as the parameters of an MTS.SUBMIT.Request. Originator For P2 messages, the originator of an input message is defined as the P2.originator, or if this attribute is not present, the P2.authorizingUsers. For non-P2 messages, the originator of an input message is defined as the P1.originator. 3. Mail based server types This chapter defines the different types of MBSs. Two main types are identified: repliers and forwarders. Houttuin, Cargille Expires: April 1993 [page 4] INTERNET-DRAFT September 1992 3.1. Replier 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 P2.replyToUsers 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 content of the output message. 3.1.1. Echo server An echo server is a dedicated replier that will submit the contents of the input message. 3.1.2. (NON)-Delivery Message This document does not consider the behaviour of P1.Service.MPDUs and P2.SR-UAPDUs, which is assumed to be well defined in X.400(84) already. RFC 822 mailers and RFC 1327 gateways however can generate a message (P2.IM- UAPDU) explaining the (NON-)Delivery of an input message. In this case the mailer/gateway can be considered an MBS. The MBS administrator is the administrator of the mailer/gateway. 3.1.3. Command server The contents of an output message submitted by a command server depends on commands that were included in the input message. Concrete examples are file servers, archie servers, DL-registration servers and address conversion servers. 3.1.4. Auto-replier Some UAs have an auto-reply feature that will temporarily and/or conditionally turn the UA into an MBS. Thus an auto- replier is a non-dedicated replier. The content of the output message is often a note such as 'I am on holidays.' Houttuin, Cargille Expires: April 1993 [page 5] INTERNET-DRAFT September 1992 3.2. Forwarder 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. 3.2.1. Distribution List Upon receiving an input message, a DL will generate output messages to a list of DL members, which is managed by the MBS administrator. In X.400(84), no DLs are defined. Many vendor-specific implementations exist, some of which are nothing more than local multi-recipient aliases, others use local directories for DL expansion. This document defines the requirements for X.400(84) DLs as well as a recommendation for how to implement them. Their behaviour will as much as possible be aligned with that of X.400(88) DLs. 3.2.2. Auto-forwarder 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. 4. Requirements MBSs shall follow the requirements defined in X.411 and X.420 as a minimum. This document describes additional requirements in terms of P1, P3, and P2. Depending on the implementation of the MBS, it can discard requirements that are not applicable. I.e.: as far as appropriate, any P2 MBS shall not only follow the P2 requirements, but also all P3 requirements, and any P3 MBS shall also follow all P1 requirements. Houttuin, Cargille Expires: April 1993 [page 6] INTERNET-DRAFT September 1992 4.1. General - The following attributes shall have the same value in the output message as in the input message: P2.Sensitivity - I case of an MBS Submit Permission violation, a P1.DeliveryReportMPDU shall be sent to the P1.originator of the input message. The P1.DeliveryReportMPDU shall have the following values: ReasonCode: unableToTransfer(1) DiagnosticCode: uaUnavailable(4) SupplementaryInformation: "Submit Permission Violation" - The address of the MBS administrator shall be the same as that of the MBS, except for the Personal Name. - The following types of input messages are invalid as input messages: P1.ServiceMPDU P2.SR-UAPDU Instead of generating an output message, the MBS shall send a warning message to the MBS administrator. 4.2. Repliers - The following attributes shall have the same value in the output message as in the input message: P3.Priority P2.Importance - The following attributes shall not be used in the output message: P2.replyRequest Houttuin, Cargille Expires: April 1993 [page 7] INTERNET-DRAFT September 1992 P2.replyBy P2.expiryDate. - If a P2.replyToUsers field is used in the output message, it shall not contain the address of the MBS. - Repliers shall not send output messages to addresses which are likely to be MBSs, such as addresses with the following values in the Surname attribute: echo autoanswer listserv netserv These values must be matched in any combination of upper case and lower case. Instead, a replier shall forward the input message to the MBS administrator. The list of dangerous Surnames is subject to change; an up-to-date version of this list is available in [dontreply] - Every PerRececipientFlag in the output message shall have the following bits set: Report Request: 00 User Report Request: 00 i.e. the Non-delivery Notification service shall be prevented. 4.2.1. Echo-servers - The following attributes shall have the same value in the output message as in the input message: P1.ContentType - If a P2.replyToUsers field is present in the input message, the output message shall be sent to this address. Otherwise the output message shall be sent to the originator of the input message. If the P2.replyToUsers field contains more than one address, Houttuin, Cargille Expires: April 1993 [page 8] INTERNET-DRAFT September 1992 at least the first address shall be replied to. Replying to the others is not recommended. - If an output message is not sent to the P2.originator of the input message, its P2.authorizingUsers field shall contain the addresses of the P2.originator and the P2.authorizingUsers of the input message. - The P2.originator of the output message shall contain the address of the MBS administrator. - Echo servers shall not send an output message if the input message contains a P2.In-Reply-To or P2.crossReferences field. Instead, the input message is forwarded to the MBS administrator. 4.2.2. (NON)-Delivery Messages - The P1.recipient and the P2.recipient of a (non-)DM should equal the P1.originator of the input message. - A message addressed to S=nosuchuser should always result in an NRN or a non-DM being generated. - The P2.Originator of the output message shall contain the address of the MBS administrator. 4.2.3. Command servers - If a P2.replyToUsers field is present in the input message, the output message shall be sent to this address. Otherwise the output message shall be sent to the originator of the input message. If the P2.replyToUsers field contains more than one address, at least the first address shall be replied to. Replying to the others is not recommended. - If an output message is not sent to the P2.originator of the input message, its P2.authorizingUsers field shall contain the addresses of the P2.originator and the P2.authorizingUsers of the input message. - The P2.Originator of the output message shall contain the address of the MBS administrator. - Command servers shall not send an output message if the input message contains an P2.inReplyTo or P2.crossReferences field. Instead, the input message Houttuin, Cargille Expires: April 1993 [page 9] INTERNET-DRAFT September 1992 is forwarded to the MBS administrator. 4.3. Forwarders - The following attributes shall have the same value in the output message as in the input message: P3.ContentType 4.3.1. Distribution Lists - The P1.contents of an output message shall be the same as that of the input message. - The P1.originator of the output message shall contain the address of the DL administrator. - All P1.ExtensionIdentifiers in an output message shall be distinct. 4.3.2. Auto-forwarders - The output message(s) shall have the P2.autoForwarded flag set to true. 5. Recommendations Please note that all recommendations for names of MBSs and MBS administrators should apply to internationally used MBSs. Local MBSs can use similar mechanisms in their local language. 5.1. Generals - For all MBSs, at least an MBS administrator with Surname=postmaster should exist. - MBS Submit Permission implementation should be 'implicit'. Houttuin, Cargille Expires: April 1993 [page 10] INTERNET-DRAFT September 1992 5.2. Repliers - The P2.In-Reply-To attribute of an output message should contain the IPMessageID of the input message. - A replier should not reply to an auto-forwarded input message. - Dedicated repliers should at least log the P2.Originator of the input message and the P2.recipient of the output message so that the MBS administrator can track down malicious behaviour. - The P2.inReplyTo and P2.crossReferences attributes are optional in an output message. If used, they should contain the IPMessageID of the input message. 5.2.1. Echo-servers - The Surname attribute of the echo server should have the value "echo". - The Surname attribute of the echo server administrator should have the value "echo-reply". - The complete input message should be included in the output message in a readable format, e.g. in an IA5Text bodypart. - The P2.subject of the output message should contain the string 'Re: ', concatenated with the subject of the input message. - An echo server may put additional information in separate bodyparts. 5.2.2. Command servers Although it is beyond the scope of this document to define requirements for the command syntax used by command servers, it is in general recommended that: - Commands should only be put in the body of the input message, e.g. a command server should ignore the P2.subject field. - It is recommended that the recipient of the output Houttuin, Cargille Expires: April 1993 [page 11] INTERNET-DRAFT September 1992 message can be uniquely identified from the heading of the input message. I.e. Alternate recipients should not be negotiated in the body of the input message. 5.3. Forwarders 5.3.1. Distribution Lists - DLs should preferably be implemented as P1 MBSs. This has some important advantages over P3/P2 based implementations: - Using P3 would result in loosing P1.TraceInformation - Better alignment with X.400(88), which also defines DLs within the MTS - An MTS DL distributes P1.UMPDUContent transparently, and will thus implicitly implement one of the requirements for DLs. - The Surname attribute of the DL administrator should be that of the DL, concatenated with "-request". 5.3.2. Auto-forwarders - The input message should be encoded as a P2.ForwardedIPMessage bodypart in the output message. 6. Mapping to X.400(88) and RFC 822 For the exact mapping between X.400 and RFC 822, see RFC 1327. The following table gives some examples: X.400(84) X.400(88) RFC 822 ---------------------------------------------------------- P2.expiryDate IPMS.Heading.expiry-time Expiry-Date: P2.inReplyTo IPMS.Heading.replied-to-IPM In-Reply-To: P2.replyBy IPMS.Heading.reply-time Reply-By: P2.replyToUsers IPMS.Heading.reply-recipients Reply-To: etc. Houttuin, Cargille Expires: April 1993 [page 12] INTERNET-DRAFT September 1992 88 based DLs shall, in case of conflicts between the requirements stated in this document and those in X.400(88), follow the requirements in X.400(88). 7. Acknowledgements Within the context of the connectivity testing tool 'concord', initial work on the requirements for echo servers and distribution lists was done within COSINE MHS and XNREN (see [Concordreqs]). Thanks for comments and corrections: Urs Eppenberger (SWITCH), Juan Pizzorno (DFN). 8. References CCITT/ISO88a. CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1," Message Handling: System and Service Overview , December 8.1. CCITT/ISO88b. CCITT/ISO, "CCITT Recommendations X.420/ ISO IS 10021-7," Message Handling Systems: Interpersonal Messaging System, December 1988. CCITT/ISO88c. CCITT/ISO, "CCITT Recommendations X.411/ ISO IS 10021-4," Message Handling Systems: Message Transfer System: Abstract Service Definition and Procedures, December 1988. CCITT/ISO88d. CCITT/ISO, "Specification of Abstract Syntax Notation One (ASN.1)," CCITT Recommendation X.208 / ISO IS 8824, December 8.2. Concordreqs. COSINE MHS server Mail: cosine-mhs-server@nic.switch.ch FTP: nic.switch.ch, Username: cosine File: procedures/echo-server-reqs Crocker82. Crocker, D., "Standard of the Format of ARPA Internet Text Messages," RFC 822, UDEL, August 1982. Houttuin, Cargille Expires: April 1993 [page 13] INTERNET-DRAFT September 1992 Dontreply. COSINE MHS server Mail: cosine-mhs-server@nic.switch.ch FTP: nic.switch.ch, Username: cosine File: procedures/dontreply Hardcastle-Kille92a. Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822," RFC 1327, UCL, May 1992. Hardcastle-Kille92b. Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading," RFC 8.3. UCL, May 1992. Kille-86. Kille, S., "Mapping between X.400 and RFC 822," RFC 987, June 1986. Westine/Postel91. Westine, A. & Postel, J., "Problems with the Maintenance of Large Mailing Lists," RFC 1211, March 1991. 9. Authors' Addresses Jeroen Houttuin Allan Cargille TOP LEVEL EC University of Wisconsin - Madison Esserweg 14 1210 West Dayton Street NL-9722 SN Groningen Madison, WI 53706 Europe USA Tel. +31 50 255445 Tel. +1 608 262 5084 houttuin@amiga.physik.unizh.ch cargille@cs.wisc.edu Houttuin, Cargille Expires: April 1993 [page 14]