home *** CD-ROM | disk | FTP | other *** search
/ ftp.qualcomm.com / 2014.06.ftp.qualcomm.com.tar / ftp.qualcomm.com / eudora / pubs / draft-gellens-submit-09.txt next >
Text File  |  1998-06-21  |  32KB  |  812 lines
  1. Internet Draft: Message Submission                           R. Gellens
  2. Document: draft-gellens-submit-09.txt                          QUALCOMM
  3. Expires: 18 December 1998                                    J. Klensin
  4.                                                                     MCI
  5.                                                            18 June 1998
  6.                                                                     
  7.                                                      
  8.     
  9.                            Message Submission
  10.     
  11.     
  12. Status of this Memo:
  13.     
  14.     This document is an Internet Draft.  Internet Drafts are working
  15.     documents of the Internet Engineering Task Force (IETF), its Areas,
  16.     and its Working Groups.  Note that other groups may also distribute
  17.     working documents as Internet Drafts.
  18.     
  19.     Internet Drafts are draft documents valid for a maximum of six
  20.     months.  Internet Drafts may be updated, replaced, or obsoleted by
  21.     other documents at any time.  It is not appropriate to use Internet
  22.     Drafts as reference material or to cite them other than as a
  23.     "working draft" or "work in progress."
  24.     
  25.     To learn the current status of any Internet Draft, please check the
  26.     "1id-abstracts.txt" listing contained in the Internet Drafts shadow
  27.     directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  28.     munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
  29.     ftp.isi.edu (US West Coast).
  30.     
  31.     
  32.     A version of this draft document will be submitted to the RFC editor
  33.     as a Best Current Practice for the Internet Community.  Discussion
  34.     and suggestions for improvement are requested.  Public comments
  35.     should be sent to the IETF Submit mailing list,
  36.     <ietf-submit@imc.org>.  To subscribe, send a message containing
  37.     SUBSCRIBE to <ietf-submit-request@imc.org>.  Private comments can be
  38.     sent to the authors.
  39.     
  40.     
  41. Copyright Notice
  42.     
  43.     Copyright (C) The Internet Society 1998.  All Rights Reserved.
  44.     
  45.     
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.     
  57. Gellens & Klensin             Expires December 1998             [Page 1]
  58. Internet Draft               Message Submission               June 1998
  59.  
  60.  
  61.     1.  Abstract  . . . . . . . . . . . . . . . . . . . . . . . . . .  2
  62.     2.  Document Information   . . . . . . . . . . . . . . . . . . . . 3
  63.       2.1.  Definitions of Terms Used in this Memo  . . . . . . . . .  3
  64.       2.2.  Conventions Used in this Document  . . . . . . . . . . . . 4
  65.     3.  Message Submission  . . . . . . . . . . . . . . . . . . . . .  4
  66.       3.1.  Submission Identification  . . . . . . . . . . . . . . . . 4
  67.       3.2.  Message Rejection and Bouncing  . . . . . . . . . . . . .  4
  68.       3.3  Authorized Submission   . . . . . . . . . . . . . . . . . . 5
  69.       3.4.  Enhanced Status Codes . . . . . . . . . . . . . . . . . .  6
  70.     4.  Mandatory Actions  . . . . . . . . . . . . . . . . . . . . . . 6
  71.       4.1.  General Submission Rejection Code . . . . . . . . . . . .  6
  72.       4.2.  Ensure All Domains are Fully-Qualified   . . . . . . . . . 6
  73.     5.  Recommended Actions . . . . . . . . . . . . . . . . . . . . .  7
  74.       5.1.  Enforce Address Syntax   . . . . . . . . . . . . . . . . . 7
  75.       5.2.  Log Errors  . . . . . . . . . . . . . . . . . . . . . . .  7
  76.     6.  Optional Actions   . . . . . . . . . . . . . . . . . . . . . . 7
  77.       6.1.  Enforce Submission Rights . . . . . . . . . . . . . . . .  7
  78.       6.2.  Require Authentication   . . . . . . . . . . . . . . . . . 8
  79.       6.3.  Enforce Permissions . . . . . . . . . . . . . . . . . . .  8
  80.       6.4.  Check Message Data   . . . . . . . . . . . . . . . . . . . 8
  81.     7.  Interaction with SMTP Extensions  . . . . . . . . . . . . . .  8
  82.     8.  Message Modifications  . . . . . . . . . . . . . . . . . . . . 9
  83.       8.1.  Add 'Sender'  . . . . . . . . . . . . . . . . . . . . . .  9
  84.       8.2.  Add 'Date'   . . . . . . . . . . . . . . . . . . . . . .  10
  85.       8.3.  Add 'Message-ID'  . . . . . . . . . . . . . . . . . . . . 10
  86.       8.4.  Transfer Encode  . . . . . . . . . . . . . . . . . . . .  10
  87.       8.5.  Sign the Message  . . . . . . . . . . . . . . . . . . . . 10
  88.       8.6.  Encrypt the Message  . . . . . . . . . . . . . . . . . .  10
  89.       8.7.  Resolve Aliases . . . . . . . . . . . . . . . . . . . . . 10
  90.       8.8.  Header Rewriting   . . . . . . . . . . . . . . . . . . .  10
  91.     9.  Security Considerations . . . . . . . . . . . . . . . . . . . 11
  92.    10.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  11
  93.    11.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 11
  94.    12.  Full Copyright Statement . . . . . . . . . . . . . . . . . .  13
  95.    13.  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . 14
  96.     
  97.     
  98. 1.  Abstract
  99.     
  100.     SMTP was defined as a message *transfer* protocol, that is, a means
  101.     to route (if needed) and deliver finished (complete) messages.
  102.     Message Transfer Agents (MTAs) are not supposed to alter the message
  103.     text, except to add 'Received', 'Return-Path', and other header
  104.     fields as required by [SMTP-MTA].
  105.     
  106.     However, SMTP is now also widely used as a message *submission*
  107.     protocol, that is, a means for message user agents (MUAs) to
  108.     introduce new messages into the MTA routing network.  The process
  109.     which accepts message submissions from MUAs is termed a Message
  110.     Submission Agent (MSA).
  111.     
  112.  
  113.  
  114.  
  115. Gellens & Klensin             Expires December 1998             [Page 2]
  116. Internet Draft               Message Submission               June 1998
  117.  
  118.  
  119.     Messages being submitted are in some cases finished (complete)
  120.     messages, and in other cases are unfinished (incomplete) in some
  121.     aspect or other.  Unfinished messages need to be completed to ensure
  122.     they conform to [MESSAGE-FORMAT], and later requirements.  For
  123.     example, the message may lack a proper 'Date' header field, and
  124.     domains might not be fully qualified.  In some cases, the MUA may be
  125.     unable to generate finished messages (for example, it might not know
  126.     its time zone).  Even when submitted messages are complete, local
  127.     site policy may dictate that the message text be examined or
  128.     modified in some way.  Such completions or modifications have been
  129.     shown to cause harm when performed by downstream MTAs -- that is,
  130.     MTAs after the first-hop submission MTA -- and are in general
  131.     considered to be outside the province of standardized MTA
  132.     functionality.
  133.     
  134.     Separating messages into submissions and transfers allows developers
  135.     and network administrators to more easily:
  136.     
  137.     *   Implement security policies and guard against unauthorized mail
  138.         relaying or injection of unsolicited bulk mail
  139.         
  140.     *   Implement authenticated submission, including off-site
  141.         submission by authorized users such as travelers
  142.         
  143.     *   Separate the relevant software code differences, thereby making
  144.         each code base more straightforward and allowing for
  145.         different programs for relay and submission
  146.         
  147.     *   Detect configuration problems with a site's mail clients
  148.    
  149.     *   Provide a basis for adding enhanced submission services in the
  150.         future
  151.     
  152.     This memo describes a low cost, deterministic means for messages to
  153.     be identified as submissions, and specifies what actions are to be
  154.     taken by a submission server.
  155.     
  156.     
  157. 2.  Document Information
  158.     
  159. 2.1.  Definitions of Terms Used in this Memo
  160.     
  161.     Fully-Qualified
  162.     
  163.     Containing or consisting of a domain which can be globally resolved
  164.     using the global Domain Name Service; that is, not a local alias or
  165.     partial specification.
  166.     
  167.     Message Submission Agent (MSA)
  168.     
  169.     A process which conforms to this specification, which acts as a
  170.     submission server to accept messages from MUAs, and either delivers
  171.  
  172.  
  173. Gellens & Klensin             Expires December 1998             [Page 3]
  174. Internet Draft               Message Submission               June 1998
  175.  
  176.  
  177.     them or acts as an SMTP client to relay them to an MTA.
  178.     
  179.     Message Transfer Agent (MTA)
  180.     
  181.     A process which conforms to [SMTP-MTA], which acts as an SMTP server
  182.     to accept messages from an MSA or another MTA, and either delivers
  183.     them or acts as an SMTP client to relay them to another MTA.
  184.     
  185.     Message User Agent (MUA)
  186.     
  187.     A process which acts (usually on behalf of a user) to compose and
  188.     submit new messages, and process delivered messages.  In the
  189.     split-MUA model, POP or IMAP is used to access delivered messages.
  190.     
  191.     
  192. 2.2.  Conventions Used in this Document
  193.     
  194.     In examples, "C:" is used to indicate lines sent by the client, and
  195.     "S:" indicates those sent by the server.  Line breaks within a
  196.     command example are for editorial purposes only.
  197.     
  198.     All example domains use "gork" as the top-level domain.
  199.     
  200.     The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
  201.     in this document are to be interpreted as defined in [KEYWORDS].
  202.     
  203.     
  204. 3.  Message Submission
  205.     
  206. 3.1.  Submission Identification
  207.     
  208.     Port 587 is reserved for email message submission as specified in
  209.     this document.  Messages received on this port are defined to be
  210.     submissions.  The protocol used is ESMTP [SMTP-MTA, ESMTP], with
  211.     additional restrictions as specified here.
  212.     
  213.     While most email clients and servers can be configured to use port
  214.     587 instead of 25, there are cases where this is not possible or
  215.     convenient.  A site MAY choose to use port 25 for message
  216.     submission, by designating some hosts to be MSAs and others to be
  217.     MTAs.
  218.     
  219.     
  220. 3.2.  Message Rejection and Bouncing
  221.     
  222.     MTAs and MSAs MAY implement message rejection rules that rely in
  223.     part on whether the message is a submission or a relay.
  224.     
  225.     For example, some sites might configure their MTA to reject all RCPT
  226.     TOs for messages that do not reference local users, and configure
  227.     their MSA to reject all message submissions that do not come from
  228.     authorized users, based on IP address, or authenticated identity.
  229.  
  230.  
  231. Gellens & Klensin             Expires December 1998             [Page 4]
  232. Internet Draft               Message Submission               June 1998
  233.  
  234.  
  235.     
  236.     NOTE:  It is better to reject a message than to risk sending one
  237.     that is damaged.  This is especially true for problems that are
  238.     correctable by the MUA, for example, an invalid 'From' field.
  239.     
  240.     If an MSA is not able to determine a return path to the submitting
  241.     user, from a valid MAIL FROM, a valid source IP address, or based on
  242.     authenticated identity, then the MSA SHOULD immediately reject the
  243.     message.  A message can be immediately rejected by returning a 550
  244.     code to the MAIL FROM command.
  245.     
  246.     Note that a null return path, that is, MAIL FROM <>, is permitted
  247.     and MUST be accepted. (MUAs need to generate null return-path
  248.     messages for a variety of reasons, including disposition
  249.     notifications.)
  250.     
  251.     Except in the case where the MSA is unable to determine a valid
  252.     return path for the message being submitted, text in this
  253.     specification which instructs an MSA to issue a rejection code MAY
  254.     be complied with by accepting the message and subsequently
  255.     generating a bounce message.
  256.     
  257.     NOTE:  In the normal case of message submission, immediately
  258.     rejecting the message is preferred, as it gives the user and MUA
  259.     direct feedback.  To properly handle delayed bounces the client MUA
  260.     must maintain a queue of messages it has submitted, and match
  261.     bounces to them.
  262.     
  263.     
  264. 3.3 Authorized Submission
  265.     
  266.     Numerous methods have been used to ensure that only authorized users
  267.     are able to submit messages.  These methods include authenticated
  268.     SMTP, IP address restrictions, secure IP, and prior POP
  269.     authentication.
  270.     
  271.     Authenticated SMTP [SMTP-AUTH] SHOULD be supported if possible.  It
  272.     allows the MSA to determine an authorization identity for the
  273.     message submission, which is not tied to other protocols.
  274.     
  275.     IP address restrictions are very widely implemented, but do not
  276.     allow for travellers and similar situations, and can be spoofed.
  277.     
  278.     Secure IP [IPSEC] can also be used, and provides additional benefits
  279.     of protection against eavesdropping and traffic analysis.
  280.     
  281.     Requiring a POP [POP3] authentication (from the same IP address)
  282.     within some amount of time (for example, 20 minutes) prior to the
  283.     start of a message submission session has also been used, but this
  284.     does impose restrictions on clients as well as servers which may
  285.     cause difficulties.  Specifically, the client must do a POP
  286.     authentication before an SMTP submission session, and not all
  287.  
  288.  
  289. Gellens & Klensin             Expires December 1998             [Page 5]
  290. Internet Draft               Message Submission               June 1998
  291.  
  292.  
  293.     clients are capable and configured for this. Also, the MSA must
  294.     coordinate with the POP server, which may be difficult.  There is
  295.     also a window during which an unauthorized user can submit messages
  296.     and appear to be a prior authorized user.
  297.     
  298.     
  299. 3.4.  Enhanced Status Codes
  300.     
  301.     This memo suggests several enhanced status codes [SMTP-CODES] for
  302.     submission-specific rejections.  The specific codes used are:
  303.     
  304.      5.6.0  Bad content.  The content of the header or text is improper.
  305.       
  306.      5.6.2  Bad domain or address.  Invalid or improper domain or address
  307.             in MAIL FROM, RCPT TO, or DATA.
  308.           
  309.      5.7.1  Not allowed.  The address in MAIL FROM appears to have
  310.             insufficient submission rights, or is invalid, or is not 
  311.             authorized with the authentication used; the address in a 
  312.             RCPT TO command is inconsistent with the permissions given
  313.             to the user; the message data is rejected based on the 
  314.             submitting user.
  315.         
  316.      5.7.0  Site policy.  The message appears to violate site policy in
  317.             some way.
  318.     
  319.     
  320. 4.  Mandatory Actions
  321.     
  322.     An MSA MUST do all of the following:
  323.     
  324.     
  325. 4.1.  General Submission Rejection Code
  326.     
  327.     Unless covered by a more precise response code, response code 554 is
  328.     to be used to reject a MAIL FROM, RCPT TO, or DATA command that
  329.     contains something improper.  Enhanced status code 5.6.0 is to be
  330.     used if no other code is more specific.
  331.     
  332.     
  333. 4.2.  Ensure All Domains are Fully-Qualified
  334.     
  335.     The MSA MUST ensure that all domains in the envelope are
  336.     fully-qualified.
  337.     
  338.     If the MSA examines or alters the message text in way, except to add
  339.     trace header fields [SMTP-MTA], it MUST ensure that all domains in
  340.     address header fields are fully-qualified.
  341.     
  342.     Reply code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA
  343.     command which contains improper domains references.
  344.     
  345.  
  346.  
  347. Gellens & Klensin             Expires December 1998             [Page 6]
  348. Internet Draft               Message Submission               June 1998
  349.  
  350.  
  351.     NOTE:  A frequent local convention is to accept single-level domains
  352.     (for example, 'sales') and then to expand the reference by adding
  353.     the remaining portion of the domain name (for example, to
  354.     'sales.foo.gork').  Local conventions that permit single-level
  355.     domains SHOULD reject, rather than expand, multi-level domains,
  356.     since such expansion is particularly risky.
  357.     
  358.     
  359. 5.  Recommended Actions
  360.     
  361.     The MSA SHOULD do all of the following:
  362.     
  363.     
  364. 5.1.  Enforce Address Syntax
  365.     
  366.     An MSA SHOULD reject messages with illegal syntax in a sender or
  367.     recipient envelope address.
  368.     
  369.     If the MSA examines or alters the message text in way, except to add
  370.     trace header fields, it SHOULD reject messages with illegal address
  371.     syntax in address header fields.
  372.     
  373.     Reply code 501 is to be used to reject a MAIL FROM or RCPT TO
  374.     command that contains a detectably improper address.
  375.     
  376.     When addresses are resolved after submission of the message body,
  377.     reply code 554 with enhanced status code 5.6.2 is to be used after
  378.     end-of-data, if the message contains invalid addresses in the
  379.     header.
  380.     
  381.     
  382. 5.2.  Log Errors
  383.     
  384.     The MSA SHOULD log message errors, especially apparent
  385.     misconfigurations of client software.
  386.     
  387.     Note:  It can be very helpful to notify the administrator when
  388.     problems are detected with local mail clients.  This is another
  389.     advantage of distinguishing submission from relay: system
  390.     administrators might be interested in local configuration problems,
  391.     but not in client problems at other sites.
  392.     
  393.     
  394. 6.  Optional Actions
  395.     
  396.     The MSA MAY do any of the following:
  397.     
  398.     
  399. 6.1.  Enforce Submission Rights
  400.     
  401.     The MSA MAY issue an error response to the MAIL FROM command if the
  402.     address in MAIL FROM appears to have insufficient submission rights,
  403.  
  404.  
  405. Gellens & Klensin             Expires December 1998             [Page 7]
  406. Internet Draft               Message Submission               June 1998
  407.  
  408.  
  409.     or is invalid, or is not authorized with the authentication used (if
  410.     the session has been authenticated).
  411.     
  412.     Reply code 554 with enhanced status code 5.7.1 is used for this
  413.     purpose.
  414.     
  415.     
  416. 6.2.  Require Authentication
  417.     
  418.     The MSA MAY issue an error response to the MAIL FROM command if the
  419.     session has not been authenticated.
  420.     
  421.     Section 3.3 discusses authentication mechanisms.
  422.     
  423.     Reply code 505 [SMTP-AUTH] is used for this purpose.
  424.     
  425.     
  426. 6.3.  Enforce Permissions
  427.     
  428.     The MSA MAY issue an error response to the RCPT TO command if
  429.     inconsistent with the permissions given to the user (if the session
  430.     has been authenticated).
  431.     
  432.     Reply code 554 with enhanced status code 5.7.1 is used for this
  433.     purpose.
  434.     
  435.     
  436. 6.4.  Check Message Data
  437.     
  438.     The MSA MAY issue an error response to the DATA command or send a
  439.     failure result after end-of-data if the submitted message is
  440.     syntactically invalid, or seems inconsistent with permissions given
  441.     to the user (if known), or violates site policy in some way.
  442.     
  443.     Reply code 554 is used for syntactic problems in the data.  Reply
  444.     code 501 is used if the command itself is not syntactically valid.
  445.     Reply code 550 with enhanced status code 5.7.1 is used to reject
  446.     based on the submitting user.  Reply code 550 with enhanced status
  447.     code 5.7.0 is used if the message violates site policy.
  448.     
  449.     
  450. 7.  Interaction with SMTP Extensions
  451.     
  452.     The following table lists the current standards-track and
  453.     Experimental SMTP extensions.  Listed are the RFC, name, status, an
  454.     indication as to the extension's use on the submit port, and a
  455.     reference:
  456.     
  457.     RFC   Name             Status  Submission  Reference
  458.     ----  ---------------  ------  ----------  ------------------
  459.     2197  Pipelining           DS    SHOULD    [PIPELINING]
  460.     2034  Error Codes          PS    SHOULD    [CODES-EXTENSION]
  461.  
  462.  
  463. Gellens & Klensin             Expires December 1998             [Page 8]
  464. Internet Draft               Message Submission               June 1998
  465.  
  466.  
  467.     1985  ETRN                 PS   MUST NOT   [ETRN]
  468.     1893  Extended Codes       PS    SHOULD    [SMTP-CODES]
  469.     1891  DSN                  PS     MAY      [DSN]
  470.     1870  Size                  S     MAY      [SIZE]
  471.     1846  521                   E   MUST NOT   [521REPLY]
  472.     1845  Checkpoint            E     MAY      [Checkpoint]
  473.     1830  Binary                E     MAY      [CHUNKING]
  474.     1652  8-bit MIME           DS    SHOULD    [8BITMIME]
  475.     ----  Authentication       --    SHOULD    [SMTP-AUTH]
  476.     
  477.     
  478.     Future SMTP extensions should explicitly specify if they are valid
  479.     on the Submission port.
  480.     
  481.     Some SMTP extensions are especially useful for message submission:
  482.     
  483.     Extended Status Codes [SMTP-CODES], SHOULD be supported and used
  484.     according to [CODES-EXTENSION].  This permits the MSA to notify the
  485.     client of specific configuration or other problems in more detail
  486.     than the response codes listed in this memo.  Because some
  487.     rejections are related to a site's security policy, care should be
  488.     used not to expose more detail than is needed to correct the
  489.     problem.
  490.     
  491.     [PIPELINING] SHOULD be supported by the MSA.
  492.     
  493.     [SMTP-AUTH] SHOULD be supported if possible.  It allows the MSA to
  494.     validate the authority and determine the identity of the submitting
  495.     user.
  496.     
  497.     Any references to the DATA command in this memo also refer to any
  498.     substitutes for DATA, such as the BDAT command used with [CHUNKING].
  499.     
  500.     
  501. 8.  Message Modifications
  502.     
  503.     Sites MAY modify submissions to ensure compliance with standards,
  504.     and/or site policy.  This section describes a number of such
  505.     modifications that are often considered useful.
  506.     
  507.     NOTE:  As a matter of guidance for local decisions to implement
  508.     message modification, a paramount rule is to limit such actions to
  509.     remedies for specific problems that have clear solutions.  This is
  510.     especially true with address elements.  For example,
  511.     indiscriminately appending a domain to an address or element which
  512.     lacks one typically results in more broken addresses.  An
  513.     unqualified address must be verified to be a valid local part in the
  514.     domain before the domain can be safely added.
  515.     
  516.     
  517. 8.1.  Add 'Sender'
  518.     
  519.  
  520.  
  521. Gellens & Klensin             Expires December 1998             [Page 9]
  522. Internet Draft               Message Submission               June 1998
  523.  
  524.  
  525.     The MSA MAY add or replace the 'Sender' field, if the identity of
  526.     the sender is known and this is not given in the 'From' field.
  527.     
  528.     The MSA MUST ensure that any address it places in a 'Sender' field
  529.     is in fact a valid mail address.
  530.     
  531.     
  532. 8.2.  Add 'Date'
  533.     
  534.     The MSA MAY add a 'Date' field to the submitted message, if it lacks
  535.     it, or correct the 'Date' field if it does not conform to
  536.     [MESSAGE-FORMAT] syntax.
  537.     
  538.     
  539. 8.3.  Add 'Message-ID'
  540.     
  541.     The MSA MAY add or replace the 'Message-ID' field, if it lacks it,
  542.     or it is not valid syntax (as defined by [MESSAGE-FORMAT]).
  543.     
  544.     
  545. 8.4.  Transfer Encode
  546.     
  547.     The MSA MAY apply transfer encoding to the message according to MIME
  548.     conventions, if needed and not harmful to the MIME type.
  549.     
  550.     
  551. 8.5.  Sign the Message
  552.     
  553.     The MSA MAY (digitally) sign or otherwise add authentication
  554.     information to the message.
  555.     
  556.     
  557. 8.6.  Encrypt the Message
  558.     
  559.     The MSA MAY encrypt the message for transport to reflect
  560.     organizational policies.
  561.     
  562.     
  563. 8.7.  Resolve Aliases
  564.     
  565.     The MSA MAY resolve aliases (CNAME records) for domain names, in the
  566.     envelope and optionally in address fields of the header, subject to
  567.     local policy.
  568.     
  569.     NOTE: unconditionally resolving aliases could be harmful.  For
  570.     example, if www.ab.gork and ftp.ab.gork are both aliases for
  571.     mail.ab.gork, rewriting them could lose useful information.
  572.     
  573.     
  574. 8.8.  Header Rewriting
  575.     
  576.  
  577.  
  578.  
  579. Gellens & Klensin            Expires December 1998            [Page 10]
  580. Internet Draft               Message Submission               June 1998
  581.  
  582.  
  583.     The MSA MAY rewrite local parts and/or domains, in the envelope and
  584.     optionally in address fields of the header, according to local
  585.     policy.  For example, a site may prefer to rewrite 'JRU' as
  586.     'J.Random.User' in order to hide logon names, and/or to rewrite
  587.     'squeeky.sales.xyz.gork' as 'zyx.gork' to hide machine names and
  588.     make it easier to move users.
  589.     
  590.     However, only addresses, local-parts, or domains which match
  591.     specific local MSA configuration settings should be altered.  It
  592.     would be very dangerous for the MSA to apply data-independent
  593.     rewriting rules, such as always deleting the first element of a
  594.     domain name.  So, for example, a rule which strips the left-most
  595.     element of the domain if the complete domain matches
  596.     '*.foo.bar.gork' would be acceptable.
  597.     
  598.     
  599. 9.  Security Considerations
  600.     
  601.     Separation of submission and relay of messages can allow a site to
  602.     implement different policies for the two types of services,
  603.     including requiring use of additional security mechanisms for one or
  604.     both.  It can do this in a way which is simpler, both technically
  605.     and administratively.  This increases the likelihood that policies
  606.     will be applied correctly.
  607.     
  608.     Separation also can aid in tracking and preventing unsolicited bulk
  609.     email.
  610.     
  611.     For example, a site could configure its MSA to require
  612.     authentication before accepting a message, and could configure its
  613.     MTA to reject all RCPT TOs for non-local users.  This can be an
  614.     important element in a site's total email security policy.
  615.     
  616.     If a site fails to require any form of authorization for message
  617.     submissions (as discussed in 3.3 ), it is allowing open use of its
  618.     resources and name, since unsolicited bulk email can be injected
  619.     using its facilities.
  620.     
  621.     
  622. 10.  Acknowledgments
  623.     
  624.     This updated draft has been revised in part based on comments and
  625.     discussions which took place on and off the IETF-Submit mailing
  626.     list.  The help of those who took the time to review the draft and
  627.     make suggestions is appreciated, especially that of Dave Crocker,
  628.     Ned Freed, Keith Moore, John Myers, and Chris Newman.
  629.     
  630.     Special thanks to Harald Alvestrand, who got this effort started.
  631.     
  632.     
  633. 11.  References
  634.     
  635.  
  636.  
  637. Gellens & Klensin            Expires December 1998            [Page 11]
  638. Internet Draft               Message Submission               June 1998
  639.  
  640.  
  641.     [521REPLY] A.  Durand, and F.  Dupont, "SMTP 521 Reply Code",
  642.     September 1995, <ftp://ftp.isi.edu/in-notes/rfc1846.txt>
  643.     
  644.     [8BITMIME] J.  Klensin, N.  Freed, M.  Rose, E.  Stefferud, and D.
  645.     Crocker, "SMTP Service Extension for 8bit-MIMEtransport", July 1994,
  646.     <ftp://ftp.isi.edu/in-notes/rfc1652.txt>
  647.     
  648.     [ABNF] D.  Crocker, Ed., P.  Overell, "Augmented BNF for Syntax
  649.     Specifications:  ABNF", November 1997,
  650.     <ftp://ftp.isi.edu/in-notes/rfc2234.txt>
  651.     
  652.     [CHECKPOINT] D.  Crocker, N.  Freed, and A.  Cargille, "SMTP Service
  653.     Extension for Checkpoint/Restart, September 1995,
  654.     <ftp://ftp.isi.edu/in-notes/rfc1845.txt>
  655.     
  656.     [CHUNKING] G.  Vaudreuil, "SMTP Service Extensions for Transmission
  657.     of Large and Binary MIME Messages", August 1995,
  658.     <ftp://ftp.isi.edu/in-notes/rfc1830.txt>
  659.     
  660.     [CODES-EXTENSION] N.  Freed, "SMTP Service Extension for Returning
  661.     Enhanced Error Codes", RFC 2034, October 1996,
  662.     <ftp://ftp.isi.edu/in-notes/rfc2034.txt>
  663.     
  664.     [DSN] K.  Moore, "SMTP Service Extension for Delivery Status
  665.     Notifications, January 1996,
  666.     <ftp://ftp.isi.edu/in-notes/rfc1891.txt>
  667.     
  668.     [ESMTP] J.  Klensin, N.  Freed, M.  Rose, E.  Stefferud, and D.
  669.     Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995,
  670.     <ftp://ftp.isi.edu/in-notes/rfc1869.txt>
  671.     
  672.     [ETRN] J.  De Winter, "SMTP Service Extension for Remote Message
  673.     Queue Starting", August 1996,
  674.     <ftp://ftp.isi.edu/in-notes/rfc1985.txt>
  675.     
  676.     [HEADERS] J.  Palme, "Common Internet Message Headers", RFC 2076,
  677.     February 1997, <ftp://ftp.isi.edu/in-notes/rfc2076.txt>
  678.     
  679.     [IPSEC] R.  Atkinson, "Security Architecture for the Internet
  680.     Protocol", RFC 1825, August 1995,
  681.     <ftp://ftp.isi.edu/in-notes/rfc1825.txt>
  682.     
  683.     [KEYWORDS] S.  Bradner, "Key words for use in RFCs to Indicate
  684.     Requirement Levels", BCP 14, RFC 2119, March 1997,
  685.     <ftp://ftp.isi.edu/in-notes/rfc2119.txt>
  686.     
  687.     [MESSAGE-FORMAT] D.  Crocker, "Standard for the format of ARPA
  688.     Internet text messages", STD 11, RFC 822, August 1982,
  689.     <ftp://ds.internic.net/rfc/rfc822.txt>; R.  Braden, Editor,
  690.     "Requirements for Internet Hosts -- Application and Support", STD 3,
  691.     RFC 1123, October 1989, <ftp://ftp.isi.edu/in-notes/rfc1123.txt>
  692.     
  693.  
  694.  
  695. Gellens & Klensin            Expires December 1998            [Page 12]
  696. Internet Draft               Message Submission               June 1998
  697.  
  698.  
  699.     [PIPELINING] N.  Freed, "SMTP Service Extension for Command
  700.     Pipelining", RFC 2197, September 1997,
  701.     <ftp://ftp.isi.edu/in-notes/rfc2197.txt>
  702.     
  703.     [POP3] J.  Myers, M.  Rose, "Post Office Protocol -- Version 3", STD
  704.     53, RFC 1939, May 1996, <ftp://ftp.isi.edu/in-notes/rfc1939.txt>
  705.     
  706.     [SIZE] J.  Klensin, N.  Freed, and K.  Moore, "SMTP Service
  707.     Extension for Message Size Declaration, November 1995,
  708.     <ftp://ftp.isi.edu/in-notes/rfc1870.txt>
  709.     
  710.     [SMTP-AUTH] J.  Myers, "SMTP Service Extension for Authentication",
  711.     work in progress,
  712.     <ftp://ftp.ietf.org/internet-drafts/draft-myers-smtp-auth-11.txt>
  713.     
  714.     [SMTP-CODES] G.  Vaudreuil, "Enhanced Mail System Status Codes", RFC
  715.     1893, January 1996, <ftp://ftp.isi.edu/in-notes/rfc1893.txt>
  716.     
  717.     [SMTP-MTA] J.  Postel, "Simple Mail Transfer Protocol", STD 10, RFC
  718.     821, August 1982, <ftp://ds.internic.net/rfc/rfc821.txt>; C.
  719.     Partridge, "Mail Routing and the Domain System", STD 14, RFC 974,
  720.     January 1986, <ftp://ds.internic.net/rfc/rfc974.txt>; R.  Braden,
  721.     Editor, "Requirements for Internet Hosts -- Application and
  722.     Support", STD 3, RFC 1123, October 1989,
  723.     <ftp://ftp.isi.edu/in-notes/rfc1123.txt>
  724.     
  725.     
  726. 12.  Full Copyright Statement
  727.     
  728.     Copyright (C) The Internet Society 1998.  All Rights Reserved.
  729.     
  730.     This document and translations of it may be copied and furnished to
  731.     others, and derivative works that comment on or otherwise explain it
  732.     or assist in its implementation may be prepared, copied, published
  733.     and distributed, in whole or in part, without restriction of any
  734.     kind, provided that the above copyright notice and this paragraph
  735.     are included on all such copies and derivative works.  However, this
  736.     document itself may not be modified in any way, such as by removing
  737.     the copyright notice or references to the Internet Society or other
  738.     Internet organizations, except as needed for the purpose of
  739.     developing Internet standards in which case the procedures for
  740.     copyrights defined in the Internet Standards process must be
  741.     followed, or as required to translate it into languages other than
  742.     English.
  743.     
  744.     The limited permissions granted above are perpetual and will not be
  745.     revoked by the Internet Society or its successors or assigns.
  746.     
  747.     This document and the information contained herein is provided on an
  748.     "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  749.     TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  750.     BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  751.  
  752.  
  753. Gellens & Klensin            Expires December 1998            [Page 13]
  754. Internet Draft               Message Submission               June 1998
  755.  
  756.  
  757.     HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  758.     MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  759.     
  760.     
  761. 13.  Authors' Addresses
  762.     
  763.     Randall Gellens                    +1 619 651 5115
  764.     QUALCOMM Incorporated              +1 619 651 5334 (fax)
  765.     6455 Lusk Blvd.                    Randy@Qualcomm.Com
  766.     San Diego, CA  92121-2779
  767.     U.S.A.
  768.     
  769.     
  770.     John C. Klensin                    +1 617 960 1011
  771.     MCI Telecommunications             klensin@mci.net
  772.     800 Boylston St, 7th floor
  773.     Boston, MA 02199
  774.     USA
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786.  
  787.  
  788.  
  789.  
  790.  
  791.  
  792.  
  793.  
  794.  
  795.  
  796.  
  797.  
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811. Gellens & Klensin            Expires December 1998            [Page 14]
  812.