[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 01 02 03 04 05 06 07 08 09 11 12 rfc2476       Standards Track
Internet Draft: Message Submission                           R. Gellens
Document: draft-gellens-submit-12.txt                          QUALCOMM
Expires: 4 March 1999                                        J. Klensin
                                                                    MCI
                                                       4 September 1998



                           Message Submission


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), ftp.ietf.org (US East Coast), or
    ftp.isi.edu (US West Coast).


Comments:

    Public comments should be sent to the IETF Submit mailing list,
    <ietf-submit@imc.org>.  To subscribe, send a message containing
    SUBSCRIBE to <ietf-submit-request@imc.org>.  This list will remain
    active after publication.  Private comments may be sent to the
    authors.


Copyright Notice

    Copyright (C) The Internet Society 1998.  All Rights Reserved.












Gellens & Klensin              Expires March 1999              [Page
1]Internet Draft             Message Submission             September
1998

                           Table of Contents

     1.  Abstract . . . . . . . . . . . . . . . . . . . . . . . . . .  2
     2.  Document Information  . . . . . . . . . . . . . . . . . . .   3
       2.1.  Definitions of Terms Used in this Memo . . . . . . . . .  3
       2.2.  Conventions Used in this Document . . . . . . . . . . .   4
     3.  Message Submission . . . . . . . . . . . . . . . . . . . . .  4
       3.1.  Submission Identification . . . . . . . . . . . . . . .   4
       3.2.  Message Rejection and Bouncing . . . . . . . . . . . . .  4
       3.3.  Authorized Submission . . . . . . . . . . . . . . . . .   5
       3.4.  Enhanced Status Codes  . . . . . . . . . . . . . . . . .  6
     4.  Mandatory Actions . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  General Submission Rejection Code  . . . . . . . . . . .  6
       4.2.  Ensure All Domains are Fully-Qualified  . . . . . . . .   6
     5.  Recommended Actions  . . . . . . . . . . . . . . . . . . . .  7
       5.1.  Enforce Address Syntax  . . . . . . . . . . . . . . . .   7
       5.2.  Log Errors . . . . . . . . . . . . . . . . . . . . . . .  7
     6.  Optional Actions  . . . . . . . . . . . . . . . . . . . . .   7
       6.1.  Enforce Submission Rights  . . . . . . . . . . . . . . .  7
       6.2.  Require Authentication  . . . . . . . . . . . . . . . .   8
       6.3.  Enforce Permissions  . . . . . . . . . . . . . . . . . .  8
       6.4.  Check Message Data  . . . . . . . . . . . . . . . . . .   8
     7.  Interaction with SMTP Extensions . . . . . . . . . . . . . .  8
     8.  Message Modifications . . . . . . . . . . . . . . . . . . .   9
       8.1.  Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . 10
       8.2.  Add 'Date'  . . . . . . . . . . . . . . . . . . . . . .  10
       8.3.  Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 10
       8.4.  Transfer Encode . . . . . . . . . . . . . . . . . . . .  10
       8.5.  Sign the Message . . . . . . . . . . . . . . . . . . . . 10
       8.6.  Encrypt the Message . . . . . . . . . . . . . . . . . .  10
       8.7.  Resolve Aliases  . . . . . . . . . . . . . . . . . . . . 10
       8.8.  Header Rewriting  . . . . . . . . . . . . . . . . . . .  11
     9.  Security Considerations  . . . . . . . . . . . . . . . . . . 11
    10.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  11
    11.  References . . . . . . . . . . . . . . . . . . . . . . . . . 12
    12.  Full Copyright Statement  . . . . . . . . . . . . . . . . .  13
    13.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14


1.  Abstract

    SMTP was defined as a message *transfer* protocol, that is, a means
    to route (if needed) and deliver finished (complete) messages.
    Message Transfer Agents (MTAs) are not supposed to alter the message
    text, except to add 'Received', 'Return-Path', and other header
    fields as required by [SMTP-MTA].

    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.  The process
    which accepts message submissions from MUAs is termed a Message
    Submission Agent (MSA).


Gellens & Klensin              Expires March 1999              [Page
2]Internet Draft             Message Submission             September
1998

    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 [MESSAGE-FORMAT], and later requirements.  For
    example, the message may lack a proper 'Date' header field, and
    domains might not be fully qualified.  In some cases, the MUA may be
    unable to generate finished messages (for example, it might not know
    its time zone).  Even when submitted messages are complete, local
    site policy may dictate that the message text be examined or
    modified in some way.  Such completions or modifications have been
    shown to cause harm when performed by downstream MTAs -- that is,
    MTAs after the first-hop submission MTA -- and are in general
    considered to be outside the province of standardized MTA
    functionality.

    Separating messages into submissions and transfers allows developers
    and network administrators to more easily:

    *   Implement security policies and guard against unauthorized mail
        relaying or injection of unsolicited bulk mail

    *   Implement authenticated submission, including off-site
        submission by authorized users such as travelers

    *   Separate the relevant software code differences, thereby making
        each code base more straightforward and allowing for
        different programs for relay and submission

    *   Detect configuration problems with a site's mail clients

    *   Provide a basis for adding enhanced submission services in the
        future

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


2.  Document Information

2.1.  Definitions of Terms Used in this Memo

    Fully-Qualified

    Containing or consisting of a domain which can be globally resolved
    using the global Domain Name Service; that is, not a local alias or
    partial specification.

    Message Submission Agent (MSA)

    A process which conforms to this specification, which acts as a
    submission server to accept messages from MUAs, and either delivers


Gellens & Klensin              Expires March 1999              [Page
3]Internet Draft             Message Submission             September
1998

    them or acts as an SMTP client to relay them to an MTA.

    Message Transfer Agent (MTA)

    A process which conforms to [SMTP-MTA], which acts as an SMTP server
    to accept messages from an MSA or another MTA, and either delivers
    them or acts as an SMTP client to relay them to another MTA.

    Message User Agent (MUA)

    A process which acts (usually on behalf of a user) to compose and
    submit new messages, and process delivered messages.  In the
    split-MUA model, POP or IMAP is used to access delivered messages.


2.2.  Conventions Used in this Document

    In examples, "C:" is used to indicate lines sent by the client, and
    "S:" indicates those sent by the server.  Line breaks within a
    command example are for editorial purposes only.

    All example domains use "gork" as the top-level domain.

    The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
    in this document are to be interpreted as defined in [KEYWORDS].


3.  Message Submission

3.1.  Submission Identification

    Port 587 is reserved for email message submission as specified in
    this document.  Messages received on this port are defined to be
    submissions.  The protocol used is ESMTP [SMTP-MTA, ESMTP], with
    additional restrictions as specified here.

    While most email clients and servers can be configured to use port
    587 instead of 25, there are cases where this is not possible or
    convenient.  A site MAY choose to use port 25 for message
    submission, by designating some hosts to be MSAs and others to be
    MTAs.


3.2.  Message Rejection and Bouncing

    MTAs and MSAs MAY implement message rejection rules that rely in
    part on whether the message is a submission or a relay.

    For example, some sites might configure their MTA to reject all RCPT
    TOs for messages that do not reference local users, and configure
    their MSA to reject all message submissions that do not come from
    authorized users, based on IP address, or authenticated identity.


Gellens & Klensin              Expires March 1999              [Page
4]Internet Draft             Message Submission             September
1998

    NOTE:  It is better to reject a message than to risk sending one
    that is damaged.  This is especially true for problems that are
    correctable by the MUA, for example, an invalid 'From' field.

    If an MSA is not able to determine a return path to the submitting
    user, from a valid MAIL FROM, a valid source IP address, or based on
    authenticated identity, then the MSA SHOULD immediately reject the
    message.  A message can be immediately rejected by returning a 550
    code to the MAIL FROM command.

    Note that a null return path, that is, MAIL FROM <>, is permitted
    and MUST be accepted. (MUAs need to generate null return-path
    messages for a variety of reasons, including disposition
    notifications.)

    Except in the case where the MSA is unable to determine a valid
    return path for the message being submitted, text in this
    specification which instructs an MSA to issue a rejection code MAY
    be complied with by accepting the message and subsequently
    generating a bounce message. (That is, if the MSA is going to reject
    a message for any reason except being unable to determine a return
    path, it can optionally do an immediate rejection or accept the
    message and then mail a bounce.)

    NOTE:  In the normal case of message submission, immediately
    rejecting the message is preferred, as it gives the user and MUA
    direct feedback.  To properly handle delayed bounces the client MUA
    must maintain a queue of messages it has submitted, and match
    bounces to them.


3.3.  Authorized Submission

    Numerous methods have been used to ensure that only authorized users
    are able to submit messages.  These methods include authenticated
    SMTP, IP address restrictions, secure IP, and prior POP
    authentication.

    Authenticated SMTP [SMTP-AUTH] SHOULD be supported.  It allows the
    MSA to determine an authorization identity for the message
    submission, which is not tied to other protocols.

    IP address restrictions are very widely implemented, but do not
    allow for travellers and similar situations, and can be spoofed.

    Secure IP [IPSEC] can also be used, and provides additional benefits
    of protection against eavesdropping and traffic analysis.

    Requiring a POP [POP3] authentication (from the same IP address)
    within some amount of time (for example, 20 minutes) prior to the
    start of a message submission session has also been used, but this
    does impose restrictions on clients as well as servers which may


Gellens & Klensin              Expires March 1999              [Page
5]Internet Draft             Message Submission             September
1998

    cause difficulties.  Specifically, the client must do a POP
    authentication before an SMTP submission session, and not all
    clients are capable and configured for this.  Also, the MSA must
    coordinate with the POP server, which may be difficult.  There is
    also a window during which an unauthorized user can submit messages
    and appear to be a prior authorized user.


3.4.  Enhanced Status Codes

    This memo suggests several enhanced status codes [SMTP-CODES] for
    submission-specific rejections.  The specific codes used are:

     5.6.0  Bad content.  The content of the header or text is improper.

     5.6.2  Bad domain or address.  Invalid or improper domain or address
            in MAIL FROM, RCPT TO, or DATA.

     5.7.1  Not allowed.  The address in MAIL FROM appears to have
            insufficient submission rights, or is invalid, or is not
            authorized with the authentication used; the address in a
            RCPT TO command is inconsistent with the permissions given
            to the user; the message data is rejected based on the
            submitting user.

     5.7.0  Site policy.  The message appears to violate site policy in
            some way.


4.  Mandatory Actions

    An MSA MUST do all of the following:


4.1.  General Submission Rejection Code

    Unless covered by a more precise response code, response code 554 is
    to be used to reject a MAIL FROM, RCPT TO, or DATA command that
    contains something improper.  Enhanced status code 5.6.0 is to be
    used if no other code is more specific.


4.2.  Ensure All Domains are Fully-Qualified

    The MSA MUST ensure that all domains in the envelope are
    fully-qualified.

    If the MSA examines or alters the message text in way, except to add
    trace header fields [SMTP-MTA], it MUST ensure that all domains in
    address header fields are fully-qualified.




Gellens & Klensin              Expires March 1999              [Page
6]Internet Draft             Message Submission             September
1998

    Reply code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA
    command which contains improper domain references.

    NOTE:  A frequent local convention is to accept single-level domains
    (for example, 'sales') and then to expand the reference by adding
    the remaining portion of the domain name (for example, to
    'sales.foo.gork').  Local conventions that permit single-level
    domains SHOULD reject, rather than expand, incomplete multi-level
    domains, since such expansion is particularly risky.


5.  Recommended Actions

    The MSA SHOULD do all of the following:


5.1.  Enforce Address Syntax

    An MSA SHOULD reject messages with illegal syntax in a sender or
    recipient envelope address.

    If the MSA examines or alters the message text in way, except to add
    trace header fields, it SHOULD reject messages with illegal address
    syntax in address header fields.

    Reply code 501 is to be used to reject a MAIL FROM or RCPT TO
    command that contains a detectably improper address.

    When addresses are resolved after submission of the message body,
    reply code 554 with enhanced status code 5.6.2 is to be used after
    end-of-data, if the message contains invalid addresses in the
    header.


5.2.  Log Errors

    The MSA SHOULD log message errors, especially apparent
    misconfigurations of client software.

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


6.  Optional Actions

    The MSA MAY do any of the following:





Gellens & Klensin              Expires March 1999              [Page
7]Internet Draft             Message Submission             September
1998

6.1.  Enforce Submission Rights

    The MSA MAY issue an error response to the MAIL FROM command if the
    address in MAIL FROM appears to have insufficient submission rights,
    or is not authorized with the authentication used (if the session
    has been authenticated).

    Reply code 550 with enhanced status code 5.7.1 is used for this
    purpose.


6.2.  Require Authentication

    The MSA MAY issue an error response to the MAIL FROM command if the
    session has not been authenticated.

    Section 3.3 discusses authentication mechanisms.

    Reply code 530 [SMTP-AUTH] is used for this purpose.


6.3.  Enforce Permissions

    The MSA MAY issue an error response to the RCPT TO command if
    inconsistent with the permissions given to the user (if the session
    has been authenticated).

    Reply code 550 with enhanced status code 5.7.1 is used for this
    purpose.


6.4.  Check Message Data

    The MSA MAY issue an error response to 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), or violates site policy in some way.

    Reply code 554 is used for syntactic problems in the data.  Reply
    code 501 is used if the command itself is not syntactically valid.
    Reply code 550 with enhanced status code 5.7.1 is used to reject
    based on the submitting user.  Reply code 550 with enhanced status
    code 5.7.0 is used if the message violates site policy.


7.  Interaction with SMTP Extensions

    The following table lists the current standards-track and
    Experimental SMTP extensions.  Listed are the RFC, name, status, an
    indication as to the extension's use on the submit port, and a
    reference:



Gellens & Klensin              Expires March 1999              [Page
8]Internet Draft             Message Submission             September
1998

    RFC   Name             Status  Submission  Reference
    ----  ---------------  ------  ----------  ------------------
    2197  Pipelining           DS    SHOULD    [PIPELINING]
    2034  Error Codes          PS    SHOULD    [CODES-EXTENSION]
    1985  ETRN                 PS   MUST NOT   [ETRN]
    1893  Extended Codes       PS    SHOULD    [SMTP-CODES]
    1891  DSN                  PS    SHOULD    [DSN]
    1870  Size                  S     MAY      [SIZE]
    1846  521                   E   MUST NOT   [521REPLY]
    1845  Checkpoint            E     MAY      [Checkpoint]
    1830  Binary                E     MAY      [CHUNKING]
    1652  8-bit MIME           DS    SHOULD    [8BITMIME]
    ----  Authentication       --    SHOULD    [SMTP-AUTH]


    Future SMTP extensions should explicitly specify if they are valid
    on the Submission port.

    Some SMTP extensions are especially useful for message submission:

    Extended Status Codes [SMTP-CODES], SHOULD be supported and used
    according to [CODES-EXTENSION].  This permits the MSA to notify the
    client of specific configuration or other problems in more detail
    than the response codes listed in this memo.  Because some
    rejections are related to a site's security policy, care should be
    used not to expose more detail than is needed to correct the
    problem.

    [PIPELINING] SHOULD be supported by the MSA.

    [SMTP-AUTH] SHOULD be supported.  It allows the MSA to validate the
    authority and determine the identity of the submitting user.

    Any references to the DATA command in this memo also refer to any
    substitutes for DATA, such as the BDAT command used with [CHUNKING].


8.  Message Modifications

    Sites MAY modify submissions to ensure compliance with standards and
    site policy.  This section describes a number of such modifications
    that are often considered useful.

    NOTE:  As a matter of guidance for local decisions to implement
    message modification, a paramount rule is to limit such actions to
    remedies for specific problems that have clear solutions.  This is
    especially true with address elements.  For example,
    indiscriminately appending a domain to an address or element which
    lacks one typically results in more broken addresses.  An
    unqualified address must be verified to be a valid local part in the
    domain before the domain can be safely added.



Gellens & Klensin              Expires March 1999              [Page
9]Internet Draft             Message Submission             September
1998

8.1.  Add 'Sender'

    The MSA MAY add or replace the '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.


8.2.  Add 'Date'

    The MSA MAY add a 'Date' field to the submitted message, if it lacks
    it, or correct the 'Date' field if it does not conform to
    [MESSAGE-FORMAT] syntax.


8.3.  Add 'Message-ID'

    The MSA MAY add or replace the 'Message-ID' field, if it lacks it,
    or it is not valid syntax (as defined by [MESSAGE-FORMAT]).


8.4.  Transfer Encode

    The MSA MAY apply transfer encoding to the message according to MIME
    conventions, if needed and not harmful to the MIME type.


8.5.  Sign the Message

    The MSA MAY (digitally) sign or otherwise add authentication
    information to the message.


8.6.  Encrypt the Message

    The MSA MAY encrypt the message for transport to reflect
    organizational policies.

    NOTE:  To be useful, the addition of a signature and/or encryption
    by the MSA generally implies that the connection between the MUA and
    MSA must itself be secured in some other way, e.g., by operating
    inside of a secure environment, by securing the submission
    connection at the transport layer, or by using an [SMTP-AUTH]
    mechanism that provides for session integrity.


8.7.  Resolve Aliases

    The MSA MAY resolve aliases (CNAME records) for domain names, in the
    envelope and optionally in address fields of the header, subject to
    local policy.


Gellens & Klensin              Expires March 1999              [Page
10]Internet Draft             Message Submission             September
1998

    NOTE:  Unconditionally resolving aliases could be harmful.  For
    example, if www.ab.gork and ftp.ab.gork are both aliases for
    mail.ab.gork, rewriting them could lose useful information.


8.8.  Header Rewriting

    The MSA MAY rewrite local parts and/or domains, in the envelope and
    optionally 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.gork' as 'zyx.gork' to hide machine names and
    make it easier to move users.

    However, only addresses, local-parts, or domains which match
    specific local MSA configuration settings should be altered.  It
    would be very dangerous for the MSA to apply data-independent
    rewriting rules, such as always deleting the first element of a
    domain name.  So, for example, a rule which strips the left-most
    element of the domain if the complete domain matches
    '*.foo.bar.gork' would be acceptable.


9.  Security Considerations

    Separation of submission and relay of messages can allow a site to
    implement different policies for the two types of services,
    including requiring use of additional security mechanisms for one or
    both.  It can do this in a way which is simpler, both technically
    and administratively.  This increases the likelihood that policies
    will be applied correctly.

    Separation also can aid in tracking and preventing unsolicited bulk
    email.

    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.

    If a site fails to require any form of authorization for message
    submissions (see section 3.3 for discussion), it is allowing open
    use of its resources and name; unsolicited bulk email can be
    injected using its facilities.


10.  Acknowledgments

    This updated draft has been revised in part based on comments and
    discussions which took place on and off the IETF-Submit mailing
    list.  The help of those who took the time to review the draft and
    make suggestions is appreciated, especially that of Dave Crocker,


Gellens & Klensin              Expires March 1999              [Page
11]Internet Draft             Message Submission             September
1998

    Ned Freed, Keith Moore, John Myers, and Chris Newman.

    Special thanks to Harald Alvestrand, who got this effort started.


11.  References

    [521REPLY] A. Durand, and F. Dupont, "SMTP 521 Reply Code",
    September 1995, <ftp://ftp.isi.edu/in-notes/rfc1846.txt>

    [8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, and D.
    Crocker, "SMTP Service Extension for 8bit-MIMEtransport", July 1994,
    <ftp://ftp.isi.edu/in-notes/rfc1652.txt>

    [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
    Specifications:  ABNF", November 1997,
    <ftp://ftp.isi.edu/in-notes/rfc2234.txt>

    [CHECKPOINT] D. Crocker, N. Freed, and A. Cargille, "SMTP Service
    Extension for Checkpoint/Restart, September 1995,
    <ftp://ftp.isi.edu/in-notes/rfc1845.txt>

    [CHUNKING] G. Vaudreuil, "SMTP Service Extensions for Transmission
    of Large and Binary MIME Messages", August 1995,
    <ftp://ftp.isi.edu/in-notes/rfc1830.txt>

    [CODES-EXTENSION] N. Freed, "SMTP Service Extension for Returning
    Enhanced Error Codes", RFC 2034, October 1996,
    <ftp://ftp.isi.edu/in-notes/rfc2034.txt>

    [DSN] K. Moore, "SMTP Service Extension for Delivery Status
    Notifications, January 1996,
    <ftp://ftp.isi.edu/in-notes/rfc1891.txt>

    [ESMTP] J. Klensin, N. Freed, M. Rose, E. Stefferud, and D. Crocker,
    "SMTP Service Extensions", STD 10, RFC 1869, November 1995,
    <ftp://ftp.isi.edu/in-notes/rfc1869.txt>

    [ETRN] J. De Winter, "SMTP Service Extension for Remote Message
    Queue Starting", August 1996,
    <ftp://ftp.isi.edu/in-notes/rfc1985.txt>

    [HEADERS] J. Palme, "Common Internet Message Headers", RFC 2076,
    February 1997, <ftp://ftp.isi.edu/in-notes/rfc2076.txt>

    [IPSEC] R. Atkinson, "Security Architecture for the Internet
    Protocol", RFC 1825, August 1995,
    <ftp://ftp.isi.edu/in-notes/rfc1825.txt>

    [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
    Requirement Levels", BCP 14, RFC 2119, March 1997,
    <ftp://ftp.isi.edu/in-notes/rfc2119.txt>


Gellens & Klensin              Expires March 1999              [Page
12]Internet Draft             Message Submission             September
1998

    [MESSAGE-FORMAT] D. Crocker, "Standard for the format of ARPA
    Internet text messages", STD 11, RFC 822, August 1982,
    <ftp://ds.internic.net/rfc/rfc822.txt>; R. Braden, Editor,
    "Requirements for Internet Hosts -- Application and Support", STD 3,
    RFC 1123, October 1989, <ftp://ftp.isi.edu/in-notes/rfc1123.txt>

    [PIPELINING] N. Freed, "SMTP Service Extension for Command
    Pipelining", RFC 2197, September 1997,
    <ftp://ftp.isi.edu/in-notes/rfc2197.txt>

    [POP3] J. Myers, M. Rose, "Post Office Protocol -- Version 3", STD
    53, RFC 1939, May 1996, <ftp://ftp.isi.edu/in-notes/rfc1939.txt>

    [SIZE] J. Klensin, N. Freed, and K. Moore, "SMTP Service Extension
    for Message Size Declaration, November 1995,
    <ftp://ftp.isi.edu/in-notes/rfc1870.txt>

    [SMTP-AUTH] J. Myers, "SMTP Service Extension for Authentication",
    work in progress,
    <ftp://ftp.ietf.org/internet-drafts/draft-myers-smtp-auth-11.txt>

    [SMTP-CODES] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC
    1893, January 1996, <ftp://ftp.isi.edu/in-notes/rfc1893.txt>

    [SMTP-MTA] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC
    821, August 1982, <ftp://ds.internic.net/rfc/rfc821.txt>; C.
    Partridge, "Mail Routing and the Domain System", STD 14, RFC 974,
    January 1986, <ftp://ds.internic.net/rfc/rfc974.txt>; R. Braden,
    Editor, "Requirements for Internet Hosts -- Application and
    Support", STD 3, RFC 1123, October 1989,
    <ftp://ftp.isi.edu/in-notes/rfc1123.txt>


12.  Full Copyright Statement

    Copyright (C) The Internet Society 1998.  All Rights Reserved.

    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph
    are included on all such copies and derivative works.  However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for
    copyrights defined in the Internet Standards process must be
    followed, or as required to translate it into languages other than
    English.




Gellens & Klensin              Expires March 1999              [Page
13]Internet Draft             Message Submission             September
1998

    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assigns.

    This document and the information contained herein is provided on an
    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


13.  Authors' Addresses

    Randall Gellens                    +1 619 651 5115
    QUALCOMM Incorporated              +1 619 651 5334 (fax)
    6455 Lusk Blvd.                    Randy@Qualcomm.Com
    San Diego, CA  92121-2779
    U.S.A.


    John C. Klensin                    +1 617 960 1011
    MCI Telecommunications             klensin@mci.net
    800 Boylston St, 7th floor
    Boston, MA 02199
    USA





























Gellens & Klensin              Expires March 1999              [Page 14]