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]