idnits 2.17.1 draft-ietf-mailext-smtp-521-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 52: '...entary solutions MAY be implemented to...' RFC 2119 keyword, line 64: '... these MX relays MAY bounce any messag...' RFC 2119 keyword, line 81: '...mailless host SHOULD do the same....' RFC 2119 keyword, line 89: '...host or its IP address MUST be sent as...' RFC 2119 keyword, line 95: '... reply, the server host MUST do one of...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 50 has weird spacing: '...4. Two comple...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force A. Durand, F. Dupont, J. G. Myers 2 INTERNET-DRAFT IMAG, INRIA Rocquencourt, CMU 3 March, 1995 5 SMTP 521 reply code 6 8 1. Status 10 Distribution of this memo is unlimited. 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, and 14 its Working Groups. Note that other groups may also distribute working 15 documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six months. 18 Internet Drafts may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet Drafts as 20 reference material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ds.internic.net (US East Coast), 25 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 26 munnari.oz.au (Pacific Rim). 28 2. Abstract 30 This memo defines a new SMTP ([1]) reply code, 521, which one may use 31 to indicate that an Internet host does not accept incoming mail. 33 3. Motivations 35 Hosts on the Internet have shifted from large, general-purpose hosts 36 to smaller, more specialized hosts. There is an increasing number of 37 hosts which are dedicated to specific tasks, such as serving NTP 38 or DNS. These dedicated hosts frequently do not provide mail service. 40 Usually, these mailless hosts do not run an SMTP server. 41 Unfortunately, users will occasionally misaddress mail to these hosts. 42 Regular SMTP clients attempting to deliver this misaddressed mail must 43 treat the lack of an SMTP server on the host as a temporary error. 44 They must queue the mail for later delivery, should an SMTP server be 45 started at a later time. 47 This causes the mail to remain queued for days, until it is returned 48 with what is usually a confusing error message. 50 4. Two complementary solutions 52 Two complementary solutions MAY be implemented to deal with this issue. 53 The first one is to use MX relays to bounce misaddressed mails. The 54 second one is to implement a minimal smtp server on the mailless host 55 to bounce all mails. 57 The choice between the two solutions is site dependent. 59 5. The MX relays solution 61 MX relays may be used to indicate SMTP clients that an Internet host 62 does not accept mail. 64 During the SMTP dialog, these MX relays MAY bounce any message 65 destinated to this particular host with an SMTP 521 reply code. 67 SMTP dialog example: 69 ---> 220 relay.imag.fr ready 70 <--- HELO client.inria.fr 71 ---> 250 relay.imag.fr Hello client.inria.fr 72 <--- MAIL FROM: 73 ---> 250 ... Sender Ok 74 <--- RCPT TO: 75 ---> 521 nomail.imag.fr does not accept mail 76 <--- QUIT 77 ---> 221 relay.imag.fr closing connection 79 If an MX relay of precedence n for a mailless host bounces mails on its 80 behalf, then any other MX relay of precedence lower than n for this 81 mailless host SHOULD do the same. 83 6. The SMTP server solution 85 6.1 521 greeting 87 A host may indicate that it does not accept mail by sending an initial 88 521 "Host does not accept mail" reply to an incoming SMTP connection. 89 The official name of the server host or its IP address MUST be sent as 90 the first word following the reply code. 92 For example: 521 canon.inria.fr does not accept mail 93 6.2 SMTP dialog 95 After issuing the initial 521 reply, the server host MUST do one of 96 the following two options: 98 a) Close the SMTP connection. 99 b) Read commands, issuing 521 replies to all commands except QUIT. 100 If the SMTP client does not issue the QUIT command after a reasonable 101 time, the SMTP server MUST time out and close the connection. 102 A suggested time-out value is 5 minutes. 104 DISCUSSION: 106 When an SMTP server closes the connection immediatly after issuing 107 the initial 521 reply, some existing SMTP clients treat the 108 condition as a transient error and requeue the mail for later 109 delivery. If the SMTP server leaves the connection open, those 110 clients immediately send the QUIT command and return the mail. 112 6.3 MX 114 A host which sends a 521 greeting message MUST NOT be listed as an MX 115 record for any domain. 117 6.4 Postmaster 119 An SMTP server which sends a 521 greeting message IS NOT subject to 120 the postmaster requirement of RFC1123 ([2]). 122 DISCUSSION: 124 Postmaster exists so you can report mail errors. A host 125 that doesn't support mail doesn't need a Postmaster. 127 7. SMTP client behavior 129 If an SMTP client encounters a host in an MX record that issues 130 a 521 greeting message, it must do one of the following two options: 132 a) Attempt to deliver it to a different MX host for that domain. 133 b) Return the mail with an appropriate non-delivery report. 135 If an SMTP client encounters a 521 reply code in any other part 136 of the SMTP dialog, it MUST return the mail with an appropriate 137 non-delivery report. 139 8. Security considerations 141 Not running any SMTP server, or running A SMTP server which simply 142 emits fixed strings in response to incoming connection should provide 143 significantly fewer opportunities for security problems than running 144 a complete SMTP implementation.. 146 9. Author addresses 148 Alain Durand 149 Institut de Mathematiques Appliquees de Grenoble (IMAG) 150 BP 53 38041 Grenoble CEDEX 9 France 151 Phone : +33 76 63 57 03 152 Fax : +33 76 44 66 75 153 E-Mail: Alain.Durand@imag.fr 155 Francis Dupont 156 Institut National de Recherche en Informatique et en Automatique 157 B.P. 105 / 78153 Le Chesnay CEDEX France 158 Phone : +33 1 39 63 52 13 159 fAx : +33 1 39 63 53 30 160 E-Mail: Francis.Dupont@inria.fr 162 John G. Myers 163 Carnegie-Mellon University 164 5000 Forbes Ave. Pittsburgh PA, 15213-3890 165 E-mail: jgm+@cmu.edu 167 10. References 169 [1] J.B. Postel. Simple Mail Transfer Protocol, Request For Comments 821 170 STD 10, (August, 1982). 172 [2] Braden, R.,ed. Requirements for Internet hosts - application and 173 support, Request For Comments 1123. (October 1989)