Internet Draft: Message Submission and Relay                 R. Gellens
Document: draft-gellens-submit-04.txt                          Qualcomm
Expires: 26 September 1997                                H. Alvestrand
                                                                UNINETT
                                                         26 March, 1997



                     Message Submission and Relay



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

        To learn the current status of any Internet Draft, please check the
        "1id-abstracts.txt" listing contained in the Internet Drafts shadow
        directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
        munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
        ftp.isi.edu (US West Coast).

        A revised version of this draft document will be submitted to the
        RFC editor as a Proposed Standard for the Internet Community.
        Discussion and suggestions for improvement are requested.  Please
        send comments to the IETF Submit mailing list,
        <ietf-submit@imc.org>.  To subscribe, send a message containing
        SUBSCRIBE to <ietf-submit-request@imc.orgt>.

        This document will expire before December 1997.  Distribution of
        this draft is unlimited.

        The file name of this version is draft-gellens-submit-04.txt


1.  Introduction

        SMTP was defined as a message *relay* protocol, that is, a means for
        message transfer agents (MTAs) to route finished (complete)
        messages.  SMTP forbids MTAs from altering the message text, except
        to add 'Received' header fields.


Gellens, Alvestrand           Expires September 1997           [Page 1]


Internet Draft          Message Submission and Relay          March 1997



        However, SMTP is now also widely used as a message *submission*
        protocol, that is, a means for message user agents (MUAs) to
        introduce new messages into the MTA routing network.  Regardless of
        whether this is good or bad, it is far too late to change.

        Messages being submitted are in some cases finished (complete)
        messages, and in other cases are unfinished (incomplete) in some
        aspect or other. Unfinished messages need to be completed to ensure
        they conform to [RFC-822], [RFC-1123], and later requirements.  For
        example, the message may lack proper Date or Message-ID headers, and
        domains might not be fully qualified.  In some cases, the MUA may be
        unable to generate finished (complete) messages (for example, it
        might not know its time zone).  Even when submitted messages are
        finished (complete), local site policy may dictate that the message
        text be modified in some ways. Such completions or modifications
        violate the letter and spirit of SMTP when used as a relay protocol.

        This memo proposes a low cost, deterministic means for messages to
        be identified as submissions or relays, and specifies what actions
        are to be taken by a submission server.

        Separation of messages into submissions and relays can have many
        benefits for Internet mail in the short and long term.  These
        benefits include allowing sites to more easily implement security
        policies and guard against unauthorized mail relaying (and spam
        injection), making it easier to detect configuration problems with a
        site's mail clients, providing a migration path to get relays out of
        the dangerous business of modifying mail, and providing a basis for
        adding additional functionality in the future.


2.  SUBMIT Servers

        To distinguish relay SMTP from submission, port XXXX is reserved as
        the MAIL SUBMIT port.  Messages received on this port are assumed to
        be submissions, even though the protocol used is otherwise SMTP.
        The process which acts as a submission server will be referred to as
        a Message Submission Agent (MSA) to distinguish it from an MTA,
        which acts as a relay agent.


3.  SMTP Extension for Message Relay or Submission

        In addition to providing for a submission server separate from SMTP,
        this memo proposes an SMTP extension [ESMTP] to assert that a
        message is not a submission, or when it is, to provide a means for
        MUAs to request non-default handling of their submissions.

        The name of this extension is "Mode".

        The EHLO keyword is MODE.



Gellens, Alvestrand           Expires September 1997           [Page 2]


Internet Draft          Message Submission and Relay          March 1997


        One new optional parameter is defined for the MAIL FROM verb: MODE.
        It has a required value, which must be either SUBMIT or RELAY.  When
        SUBMIT appears, it may be followed by a list of modifiers enclosed
        in parentheses.

        If MODE=RELAY is used with the MAIL FROM command, the message is to
        be treated as a relay.  If RELAY appears in MAIL FROM for a message
        received on the SUBMIT port, the message MUST NOT be treated as a
        submission; the MSA may either treat it as a relay or reject the
        MAIL FROM command with 504.  (While 504 is not listed in RFC 821 as
        a valid failure response to MAIL FROM, it seems to make the most
        sense, although cases can be made for 521 and 554).

        If MODE was not used, and the message was received on the standard
        SMTP port (port 25), the MTA may either treat the message as a
        relay, or use the guidelines in section 8 to determine if the
        message is a submission or a relay.

        If MODE=SUBMIT is used on the SMTP port, the MTA may either accept
        the MAIL FROM and treat the message as a submission, or reject the
        MAIL FROM with response code 504.

        No modifiers are defined at this time for the SUBMIT value of the
        MODE parameter. However, such modifiers may be defined in the
        future.  Names beginning with 'x' or 'X' are reserved for
        non-standard use.  All other names are reserved for standardized
        modifiers.  IANA will maintain the list of standard names.


4.  Actions when MODE=RELAY Is Used

        If the MAIL FROM command has the MODE=RELAY parameter, the MTA is
        being informed that this message is being relayed, and therefore the
        letter and spirit of SMTP MUST be followed.  The MTA MUST NOT alter
        the text, except to add a 'Received' header field.


5.  Actions when the Message Is a Submission


5.1.  General Rules


5.1.1.  Even though various modifications to header fields are
        authorized in this memo, a paramount rule is that elements of
        structured header fields may only be modified when specific problems
        are recognized which have clear solutions.  This is especially true
        with address elements.  For example, indiscriminately appending
        '@foo.com' to an address or element which lacks an '@' results in
        more broken addresses.  If an address lacks an '@', it must be
        verified to be a valid local part in the domain before the domain
        can be added.



Gellens, Alvestrand           Expires September 1997           [Page 3]


Internet Draft          Message Submission and Relay          March 1997



5.1.2.  It is better to reject than to risk damage.  When a problem with
        a message is detected, and there is no specificly configured rule for
        the problem, it is better to reject the message than to attempt to
        fix it.  This is especially true of problems which are correctable
        by the MUA (for example, an invalid 'From' field).  In these
        situations, the MSA may either accept the message and subsequently
        issue a bounce, or use response code 554 to reject a MAIL FROM, RCPT
        TO, or DATA command which contains something improper.


5.2.  Things which MAY Be Done by the MSA if the Message Is a Submission


5.2.1.  Refuse the MAIL FROM command if the address in MAIL FROM is not
        believed to have submission rights, or is invalid. Failure code 554
        should be used for this purpose.


5.2.2.  Refuse the DATA command or send a failure result
        after end-of-data if the submitted message is syntactically invalid,
        or seems inconsistent with permissions given to the user (if known).
        Result code 554 should be used.  The MSA MAY instead accept the
        message and subsequently issue a bounce.


5.2.3.  Add or replace a 'Sender' field, if the identity of the sender
        is known and this is not given in the 'From' field.  The MSA MUST
        ensure that any address it places in a 'Sender' field is in fact a
        valid mail address.


5.2.4.  Add a 'Date' field to the submitted message, if it lacks it, or
        correct the 'Date' field if it does not conform to [RFC-822] syntax
        (as modified by [RFC-1123]).  If the MSA adds or changes the 'Date'
        field, it MUST add a comment to the field indicating this.  This is
        because an altered or MSA-created 'Date' field is likely to be
        misleading to the recipient.


5.2.5.  Add a 'Message-ID' field to the submitted message, if it lacks
        it.


5.2.6.  Transfer encode the message according to MIME conventions, if
        needed and not harmful to the MIME type.


5.2.7.  Resolve aliases (CNAME records) for domain names, in the
        envelope as well as in address fields of the header, subject to local
        policy.  For example, if www.ab.com and ftp.ab.com are both aliases
        for mail.ab.com, rewriting them could lose useful information.



Gellens, Alvestrand           Expires September 1997           [Page 4]


Internet Draft          Message Submission and Relay          March 1997



5.2.8.  Rewrite local parts and/or domains, in the envelope as well as
        in address fields of the header, according to local policy.  For
        example, a site may prefer to rewrite 'JRU' as 'J.Random.User' in
        order to hide logon names, and/or to rewrite 'squeeky.sales.xyz.com'
        as 'zyx.com' to hide machine names and make it easier to move users.
        However, only addresses which match specific local MSA configuration
        settings may be altered.  The MSA MUST NOT apply data-independent
        rewriting rules, such as always deleting the first element of a
        domain name.


5.3.  Things which MUST Be Done by the MSA if the Message Is a
        Submission


5.3.1.  Ensure all domains (in the envelope as well as the text) are
        fully-qualified.  Single-level domains (for example, 'sales') MAY be
        expanded based on local configuration (for example, to
        'sales.foo.com'). Multi-level domains which are not fully-qualified
        (for example, 'sales.foo') MUST be rejected, not expanded.  Response
        code 554 should be used to reject a MAIL FROM, RCPT TO, or DATA
        command which contains improper domains.  The MSA MAY instead accept
        the command and subsequently issue a bounce.


5.3.2.  Reject messages with detectably illegal syntax in a sender or
        recipient address.  This applies after any address transformations
        have been done. Response code 554 should be used to reject a MAIL
        FROM, RCPT TO, or DATA command which contains improper domains.  The
        MSA MAY instead accept the message and subsequently issue a bounce.


5.3.3.  Use the MODE=RELAY parameter to the MAIL FROM command when
        relaying the message, if the server MTA understands ESMTP and
        supports the MODE extension.


5.4.  Things which MUST NOT Be Done by the MSA if the Message Is a
        Submission


5.4.1.   Alter already valid headers or text in ways not authorized by
        this memo.  However, the MSA MAY reject or bounce messages which
        violate site policy in some way.  (For example, messages which
        appear to contain proprietary information)


5.5.  Things which SHOULD Be Done by the MSA if the Message Is a
        Submission


5.5.1.  Log message errors, especially apparent misconfigurations of


Gellens, Alvestrand           Expires September 1997           [Page 5]


Internet Draft          Message Submission and Relay          March 1997


        client software.  It can be very helpful to notify the local
        postmaster when problems are detected with local mail clients.  This
        is another advantage of distinguishing submission from relay: local
        postmasters are likely to be interested in local configuration
        problems, but not in client problems at other sites.


5.5.2.  If the MSA treats a message as a submission (see also section 8)
        and as a result modifies the contents of any structured header fields
        or makes other significant changes, it SHOULD document all such
        alterations by adding one or more 'Change-History' header fields.

        'Change-History' is a structured header field which allows an MSA to
        list the changes it made, and to provide trace and contact
        information should problems with its changes be detected.  All
        parameter names and parameter values are case-insensitive, unless
        otherwise noted.


5.5.3.  Parameters of 'Change-History'

        The following parameters are defined for the 'Change-History' header
        field. Additional parameters may be defined in the future, and will
        be registered with IANA.  Names beginning with 'X' or 'x' are
        reserved for non-standard parameters. Other names are reserved for
        standard parameters.


5.5.3.1.  The 'Contact-Domain' parameter

        'Contact-Domain' is a required parameter.  It specifies a FQDN, the
        postmaster of which is the contact point for problems detected by
        the recipient of the message.


5.5.3.2.  The 'MSA' parameter

        While 'MSA' is an optional parameter, either it or
        'MSA-Identity-Token' is required.  'MSA' lists the FQDN of the MSA.


5.5.3.3.  The 'MSA-Identity-Token' parameter

        While 'MSA-Identity-Token' is an optional parameter, either it or
        'MSA' is required.  'MSA-Identity-Token' is any string which is
        sufficient for the postmaster at the contact domain to identify the
        software which modified the message.  This parameter value must be
        treated as case sensitive; that is, its case must be preserved.
        This allows the generating to site to use values which are either
        case sensitive or insensitive.


5.5.3.4.  The 'Date' parameter


Gellens, Alvestrand           Expires September 1997           [Page 6]


Internet Draft          Message Submission and Relay          March 1997



        'Date' is required and contains the time and date at which the change
        was made, using syntax as in [RFC-822] and [RFC-1123].


5.5.3.5.  The 'Field' parameter

        The 'Field' parameter is required and identifies which header field
        was changed. If the body was changed (for example, upgraded to MIME
        and content-transfer-encoded, 'body' should be specified.  If a
        multi-valued field (such as an address field) was changed, the
        specific element MAY be indicated by appending a dot and an integer.
        For example, the first address in 'To' would be 'To.1'.


5.5.3.6.  The 'Action' parameter

        The 'Action' parameter is required and specifies the type of change:
        'Added', 'Expanded', 'Quoted', 'Unquoted', 'Changed', or 'Removed'.


5.5.3.7.  The 'Cause' parameter

        The 'Cause' parameter optionally identifies the justification for the
        change: 'Bad-Syntax', 'Incorrect', 'Missing', 'Nickname', or
        'Policy'.


5.5.3.8.  The 'Original' parameter

        'Original' is an optional parameter which contains the value of the
        field before any changes were made.


5.5.4.  ABNF for 'Change-History'

        This defines the syntax for the 'Change-History' header field using
        terminals as specified in RFC 2045 [MIME-IMB]:

        change-history ::= "Change-History:" parameter *(";" parameter)

        parameter ::= action / contact-domain / cause / date / field / msa /
                      msa-identity-token / original

        action ::= "Action" "=" ("Added" / "Changed" / "Expanded" / "Quoted"
                   / "Removed" / "Unquoted")

        contact-domain ::= "Contact-Domain" "=" <FQDN>

        cause ::= "Cause" "=" ("Bad-Syntax" / "Incorrect" / "Missing" /
                  "Nickname" / "Policy")

        date ::= "Date" "=" <quoted-string containing date-time as specified


Gellens, Alvestrand           Expires September 1997           [Page 7]


Internet Draft          Message Submission and Relay          March 1997


                 in RFC 822 and RFC 1123>

        field ::= "Field" "=" ("body" / <header fields as specified in RFC
                   822 or RFC 2076 [HEADERS]>)

        msa ::= "MSA" "=" <FQDN>

        msa-identity-token ::= "MSA-Identity-Token" "=" value

        original ::= "Original" "=" value


5.5.11.  Examples of 'Change-History'

        Change-History: Date="Fri, 20 March 1997 19:32 +0800";
        MSA=helpful.qualcomm.com; Contact-Domain=Qualcomm.Com; Field=To.1;
        Action=Expanded; Cause=Nickname; Original=Foo

        Change-History: Date="Fri, 20 March 1997 19:32 +0800";
        MSA=helpful.qualcomm.com; Contact-Domain=Qualcomm.Com; Field=From;
        Action=Changed; Cause=Policy


6.  Interaction with Other SMTP Extensions

        The SMTP [AUTH] extension, if supported and used, may allow the MSA
        to determine the identity of the submitting user.

        Extended Status Codes [SMTP-CODES], if supported and used according
        to [CODES-EXTENSION], permits the MSA to notify the client of
        specific configuration or other problems.  In particular, when
        result code 554 is used to reject a MAIL FROM, RCPT TO, or DATA
        command, or if 504 is used to reject a MAIL FROM commad, the codes
        defined in [SMTP-CODES] will be helpful.


7.  Message Rejection

        The MTA MAY choose to implement message rejection rules which rely
        in part on whether the message is a submission or a relay.  For
        example, some sites might configure their MTA and MSA to reject all
        RCPT TOs for messages being relayed which do not reference local
        users, and/or to reject all message submissions which do not come
        from local users (based on IP address and/or authenticated
        identity).

        The MSA may be unable to comply with the requirements for relaying a
        submitted message.  For example, the domain names in the message
        headers and/or envelope might be unqualified and either unknown or
        ambiguous, preventing the MSA from qualifying them.  If the MSA is
        able to produce a valid message, it may either reject the message
        immediately, or accept it and issue a bounce.  If the MSA is not
        able to determine a return path to the submitting user (from a valid


Gellens, Alvestrand           Expires September 1997           [Page 8]


Internet Draft          Message Submission and Relay          March 1997


        MAIL FROM, or based on authenticated identify), it MUST immediately
        reject the message.  A message can be immediately rejected by
        returning 554 to the MAIL FROM command or after receiving the final
        period.


8.  Possible Other Cases for Treating Messages as Submissions

        For backwards compatibility with older mailers and MTAs, the MTA MAY
        consider the message a submission, and treat it as above, under some
        combinations of the following circumstances:


8.1.  The message lacks any 'Received' fields.

8.2.  The message comes from a host known to the MTA as being a "pure
        client", such as a PC.

8.3.  The message lacks a 'Date' field.

8.4.  The MTA knows that all of its messages are submissions.  For
        example, an MTA and all clients might be configured so that all
        submissions go through that MTA, and only submissions go through
        that MTA.


9.  Security Considerations

        Separation of submission and relay of messages can allow a site to
        implement more secure policies.  This can aid in tracking spam, and
        can allow a site to ensure that it is not used as a spam injection
        point by outsiders.  For example, a site could configure its MSA to
        require authentication before accepting a message, and could
        configure its MTA to reject all RCPT TOs for non-local users.  This
        can be an important element in a site's total email security policy.

        The 'Change-History' header field allows for problem tracking and
        reporting, through use of the 'Contact-Domain' parameter with either
        the 'MSA' or the 'MSA-Identity-Token' parameter.  Sites wanting to
        prevent disclosing details of their local network (such as the
        identities of local servers) should use 'MSA-Identity-Token', while
        sites without these concerns can use the simpler 'MSA' paremeter.



10.  Acknowledgements

        This updated draft has been revised in part based on comments and
        discussions which took place on and off the IETF-Submit mailing
        list.


11.  References


Gellens, Alvestrand           Expires September 1997           [Page 9]


Internet Draft          Message Submission and Relay          March 1997



        [AUTH] J.  Myers, "Internet Draft:  SMTP Authentication", Carnegie
        Mellon, draft-myers-smtp-auth-05.txt, February, 1997, work in
        progress,
        <ftp://ds.internic.net/internet-drafts/draft-myers-smtp-auth-05.txt>

        [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
        Crocker, "SMTP Service Extensions", RFC 1869, STD 10, United Nations
        University, Innosoft International, Inc., Dover Beach Consulting,
        Inc., Network Management Associates, Inc., The Branch Office,
        November 1995, <ftp://ds.internic.net/rfc/rfc1869.txt>

        [RFC-822] D. Crocker, "Standard for the format of ARPA Internet text
        messages", RFC 822, STD 11, University of Delaware, 08/13/1982,
        <ftp://ds.internic.net/rfc/rfc822.txt>

        [RFC-1123] R. Braden, Editor, "Requirements for Internet Hosts --
        Application and Support", RFC 1123, USC/Information Sciences
        Institute, October 1989, <ftp://ds.internic.net/rfc/rfc1123.txt>

        [SMTP] J. Postel, "Simple Mail Transfer Protocol", RFC 821, STD 10,
        Information Sciences Institute, 08/01/1982,
        <ftp://ds.internic.net/rfc/rfc821.txt>

        [CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning
        Enhanced Error Codes", RFC 2034, Innosoft, October 1996,
        <ftp://ds.internic.net/rfc/rfc2034.txt>

        [SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
        1893, Octel Network Services, January 1996,
        <ftp://ds.internic.net/rfc/rfc1893.txt>

        [MIME-IMB] Freed, Borenstein, "Mulitpurpose Internet Mail Extensions
        (MIME) Part One: Format of Internet Message Bodies", RFC 2045,
        Innosoft, First Virtual, November 1996,
        <ftp://ds.internic.net/rfc/rfc2045.txt>

        [HEADERS] Palme, J., "Common Internet Message Headers", RFC 2076,
        Stockholm University/KTH, February 1997,
        <ftp://ds.internic.net/rfc/rfc2076.txt>



12.  Authors' Addresses

        Randall Gellens                    +1.619.651.5115
        Qualcomm, Inc.                     +1.619.658.1560 (fax)
        6455 Lusk Blvd.                    Randy@Qualcomm.Com
        San Diego, CA  92121
        U.S.A.


        Harald Tveit Alvestrand            +47 73 59 70 94


Gellens, Alvestrand           Expires September 1997           [Page 10]


Internet Draft          Message Submission and Relay          March 1997


        UNINETT                            Harald.T.Alvestrand@uninett.no
        P.O.Box 6883 Elgeseter
        N-7002 TRONDHEIM
        NORWAY


















































Gellens, Alvestrand           Expires September 1997           [Page 11]