home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1846.txt < prev    next >
Text File  |  1996-05-07  |  7KB  |  150 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          A. Durand Request For Comments: 1846                                          IMAG Category: Experimental                                         F. Dupont                                                       INRIA Rocquencourt                                                           September 1995 
  8.  
  9.                            SMTP 521 Reply Code 
  10.  
  11.  Status of this Memo 
  12.  
  13.    This memo defines an Experimental Protocol for the Internet    community.  This memo does not specify an Internet standard of any    kind.  Discussion and suggestions for improvement are requested.    Distribution of this memo is unlimited. 
  14.  
  15. Abstract 
  16.  
  17.    This memo defines a new Simple Mail Transfer Protocol (SMTP) [1]    reply code, 521, which one may use to indicate that an Internet host    does not accept incoming mail. 
  18.  
  19. 1. Motivations 
  20.  
  21.    Hosts on the Internet have shifted from large, general-purpose hosts    to smaller, more specialized hosts.  There is an increasing number of    hosts which are dedicated to specific tasks, such as serving NTP or    DNS.  These dedicated hosts frequently do not provide mail service. 
  22.  
  23.    Usually, these mailless hosts do not run an SMTP server.    Unfortunately, users will occasionally misaddress mail to these    hosts.  Regular SMTP clients attempting to deliver this misaddressed    mail must treat the lack of an SMTP server on the host as a temporary    error.  They must queue the mail for later delivery, should an SMTP    server be started at a later time. 
  24.  
  25.    This causes the mail to remain queued for days, until it is returned    with what is usually a confusing error message. 
  26.  
  27. 2. Two  complementary solutions 
  28.  
  29.    Two complementary solutions MAY be implemented to deal with this    issue.  The first one is to use MX relays to bounce misaddressed    mails.  The second one is to implement a  minimal smtp server on the    mailless host to bounce all mails. 
  30.  
  31.    The choice between the two solutions is site dependent. 
  32.  
  33.  
  34.  
  35. Durand & Dupont               Experimental                      [Page 1] 
  36.  RFC 1846                  SMTP 521 Reply Code             September 1995 
  37.  
  38.  3. The MX relays solution 
  39.  
  40.    MX relays may be used to indicate SMTP clients that an Internet host    does not accept mail. 
  41.  
  42.    During the SMTP dialog, these MX relays MAY bounce any message    destinated to this particular host with an SMTP 521 reply code. 
  43.  
  44.     SMTP dialog example: 
  45.  
  46.    ---> 220 relay.imag.fr ready    <--- HELO client.inria.fr    ---> 250 relay.imag.fr Hello client.inria.fr    <--- MAIL FROM: <user1@client.inria.fr>    ---> 250 <user1@client.inria.fr>... Sender Ok    <--- RCPT TO: <user2@nomail.imag.fr>    ---> 521 nomail.imag.fr does not accept mail    <--- QUIT    ---> 221 relay.imag.fr closing connection 
  47.  
  48.    If an MX relay of precedence n for a mailless host bounces mails on    its behalf, then any other MX relay of precedence lower than n for    this mailless host SHOULD do the same. 
  49.  
  50. 4. The SMTP server solution 
  51.  
  52. 4.1 521 greeting 
  53.  
  54.    A host may indicate that it does not accept mail by sending an    initial 521 "Host does not accept mail" reply to an incoming SMTP    connection.  The official name of the server host or its IP address    MUST be sent as the first word following the reply code. 
  55.  
  56.    For example: 521 canon.inria.fr does not accept mail 
  57.  
  58. 4.2 SMTP dialog 
  59.  
  60.    After issuing the initial 521 reply, the server host MUST do one of    the following two options: 
  61.  
  62.    a) Close the SMTP connection.    b) Read commands, issuing 521 replies to all commands except QUIT.       If the SMTP client does not issue the QUIT command after a       reasonable time, the SMTP server MUST time out and close the       connection.  A suggested time-out value is 5 minutes. 
  63.  
  64.  
  65.  
  66.  
  67.  
  68. Durand & Dupont               Experimental                      [Page 2] 
  69.  RFC 1846                  SMTP 521 Reply Code             September 1995 
  70.  
  71.     DISCUSSION: 
  72.  
  73.    When an SMTP server closes the connection immediatly after issuing    the initial 521 reply, some existing SMTP clients treat the    condition as a transient error and requeue the mail for later    delivery.  If the SMTP server leaves the connection open, those    clients immediately send the QUIT command and return the mail. 
  74.  
  75. 4.3 MX 
  76.  
  77.    A host which sends a 521 greeting message MUST NOT be listed as an MX    record for any domain. 
  78.  
  79. 4.4 Postmaster 
  80.  
  81.    An SMTP server which sends a 521 greeting message IS NOT subject to    the postmaster requirement of STD 3, RFC 1123 ([2]). 
  82.  
  83.    DISCUSSION: 
  84.  
  85.    Postmaster exists so you can report mail errors.  A host that doesn't    support mail doesn't need a Postmaster. 
  86.  
  87. 5. SMTP client behavior 
  88.  
  89.    If an SMTP client encounters a host in an MX record that issues a 521    greeting message, it must do one of the following two options: 
  90.  
  91.    a) Attempt to deliver it to a different MX host for that domain.    b) Return the mail with an appropriate non-delivery report. 
  92.  
  93.    If an SMTP client encounters a 521 reply code in any other part of    the SMTP dialog, it MUST return the mail with an appropriate non-    delivery report. 
  94.  
  95. 6. Security Considerations 
  96.  
  97.    Not running any SMTP server, or running an SMTP server which simply    emits fixed strings in response to incoming connection should provide    significantly fewer opportunities for security problems than running    a complete SMTP implementation. 
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  Durand & Dupont               Experimental                      [Page 3] 
  108.  RFC 1846                  SMTP 521 Reply Code             September 1995 
  109.  
  110.  7. Authors' Addresses 
  111.  
  112.    Alain Durand    Institut de Mathematiques Appliquees de Grenoble (IMAG)    BP 53 38041 Grenoble CEDEX 9 France 
  113.  
  114.    Phone : +33 76 63 57 03    Fax   : +33 76 44 66 75    EMail: Alain.Durand@imag.fr 
  115.  
  116.     Francis Dupont    Institut National de Recherche en Informatique et en Automatique    B.P. 105 / 78153 Le Chesnay CEDEX France 
  117.  
  118.    Phone : +33 1 39 63 52 13    Fax   : +33 1 39 63 53 30    EMail: Francis.Dupont@inria.fr 
  119.  
  120. 8. Expericences 
  121.  
  122.    People implementing this reply code are suggested to send a message    to mailext@list.cren.net to report their experience. 
  123.  
  124. 9. References 
  125.  
  126.    [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,        USC/Information Sciences Institute, August 1982. 
  127.  
  128.    [2] Braden, R., Editor, "Requirements for Internet Hosts -        Application and Support", STD 3, RFC 1123, USC/Information        Sciences Institute, October 1989. 
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148. Durand & Dupont               Experimental                      [Page 4] 
  149.  
  150.