7Internet Engineering Task Force (IETF) J. Klensin
8Request for Comments: 7504 June 2015
10Category: Standards Track
14 SMTP 521 and 556 Reply Codes
18 This memo defines two Simple Mail Transfer Protocol (SMTP) reply
19 codes, 521 and 556. The 521 code was originally described in an
20 Experimental RFC in 1995 and is in wide use, but has not previously
21 been formally incorporated into SMTP. The 556 code was created to
22 support the new tests and actions specified in RFC 7505. These codes
23 are used to indicate that an Internet host does not accept incoming
24 mail at all. This specification is not applicable when the host
25 sometimes accepts mail but may reject particular messages, or even
26 all messages, under specific circumstances.
30 This is an Internet Standards Track document.
32 This document is a product of the Internet Engineering Task Force
33 (IETF). It represents the consensus of the IETF community. It has
34 received public review and has been approved for publication by the
35 Internet Engineering Steering Group (IESG). Further information on
36 Internet Standards is available in Section 2 of RFC 5741.
38 Information about the current status of this document, any errata,
39 and how to provide feedback on it may be obtained at
40 http://www.rfc-editor.org/info/rfc7504.
58Klensin Standards Track [Page 1]
60RFC 7504 SMTP 521 and 556 Reply Codes June 2015
65 Copyright (c) 2015 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
81 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
82 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
83 3. The 521 Reply Code . . . . . . . . . . . . . . . . . . . . . 4
84 4. The 556 Reply Code . . . . . . . . . . . . . . . . . . . . . 4
85 5. Small Details to Avoid Loose Ends . . . . . . . . . . . . . . 5
86 5.1. Specific Changes to RFC 5321 . . . . . . . . . . . . . . 5
87 5.2. The RFC 1846 Experiment . . . . . . . . . . . . . . . . . 5
88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
91 8.1. Normative References . . . . . . . . . . . . . . . . . . 6
92 8.2. Informative References . . . . . . . . . . . . . . . . . 6
93 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7
94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
114Klensin Standards Track [Page 2]
116RFC 7504 SMTP 521 and 556 Reply Codes June 2015
121 The SMTP specification [2] (referred to, along with its various
122 updates, as "SMTP" below) contains a list and discussion of reply
123 codes. This document updates that list with a new code, 521, for use
124 in response to an initial connection. In that context, it
125 specifically denotes a system that does not receive mail or otherwise
126 handle SMTP mail or inquiry transactions. That code differs from the
127 use of reply code 554, recommended by RFC 5321, because the latter
128 code can be used in a larger variety of situations, including mail
129 that is not accepted for, or from, particular sources, destinations,
130 or addresses. It also introduces a second reply code, 556, for use
131 when an SMTP client encounters a domain in a forward-pointing address
132 that it can determine (e.g., from the DNS "null MX" convention [5])
133 does not support receipt of mail and has to report that condition to
134 a host that delivered the message to it for further processing.
136 This specification updates RFC 5321 to add the new codes. The 521
137 code was first formally proposed in the Experimental RFC 1846 [4];
138 this document updates that specification to standardize the code and
139 provide more specific treatment of it.
143 The reader of this document is expected to have reasonable
144 familiarity with the SMTP specification in RFC 5321, particularly its
145 discussion of reply codes and their use and theory.
147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
149 document are to be interpreted as described in RFC 2119 [1].
153 Many Internet hosts are not in a position -- whether technically,
154 operationally, or administratively -- to offer mail service. If an
155 SMTP client (sender) attempts to open a mail connection to a system
156 that does not have an SMTP server, the connection attempt will time
157 out. SMTP requires that timeouts result in the client queuing the
158 message and retrying it for an extended period. That behavior will
159 result in wasted resources and long delays in getting an error
160 message back to its originator.
162 One alternative is to run a dummy SMTP server on hosts that do not
163 receive mail under any circumstances and have that dummy server
164 return a fatal error reply code in response to any connection-opening
170Klensin Standards Track [Page 3]
172RFC 7504 SMTP 521 and 556 Reply Codes June 2015
175 attempt. Another is to determine, from a separate source such as a
176 DNS record, that the host does not receive mail. This document
177 specifies reply codes to be used for those purposes.
181 This specification adds the 521 reply code to the repertoire
182 specified in SMTP, reserving it for use at connection-opening time to
183 indicate that the host does not accept mail under any circumstances.
184 It SHOULD be used for dummy SMTP servers whose sole purpose is to
185 notify systems that attempt to open mail connections that the host
186 never accepts mail. It MAY be used in other situations where the
187 intent is to indicate that the host never accepts mail. It SHOULD
188 NOT be used for situations in which the server rejects mail from
189 particular hosts or addresses or in which mail for a particular
190 destination host is not accepted. As discussed in SMTP, reply code
191 554 is more appropriate for most of those conditions; an additional
192 case, in which the determination that mail is not accepted is
193 determined outside the mail system, is covered in the next section
196 "Server does not accept mail" (or a variant such as "Host", "Domain",
197 or a related term) is an acceptable message to accompany a 521 code
198 used for this purpose.
200 Once the 521 reply code is returned instead of the usual 220, the
201 SMTP session proceeds normally. If the SMTP client attempts to send
202 additional commands other than QUIT, the server MAY either continue
203 sending 521 reply codes or simply close the connection. If the
204 purpose of running a dummy SMTP server that returns a 521 code is to
205 conserve resources, the latter will usually be preferable.
209 This specification adds the 556 reply code to the repertoire
210 specified in SMTP. When an intermediate SMTP system (typically a
211 relay) that would normally attempt to open a mail connection to a
212 host referred to in a forward-pointing address can determine that the
213 host does not accept mail connections, and do so without attempting
214 to open a connection to that target host, it is appropriate for it to
215 return a reply with a 556 code to the system that sent it the message
216 for outbound transmission. Interpretation of a special DNS record,
217 found when a lookup is performed in conjunction with a RCPT command
218 [5], is one such method (and the only standardized one at the time
219 this specification was written).
226Klensin Standards Track [Page 4]
228RFC 7504 SMTP 521 and 556 Reply Codes June 2015
231 When an SMTP server returns a 556 reply code after receiving a
232 command (such as RCPT, which contains a forward-pointing address)
233 because it has information (such as discussed above) that the mail
234 will not be accepted, the SMTP client is expected to handle the
235 response like any other permanent negative completion reply to the
236 command. This is consistent with the SMTP specification.
2385. Small Details to Avoid Loose Ends
2405.1. Specific Changes to RFC 5321
242 This document adds the 521 code, with message "Host does not accept
243 mail", and the 556 code, with message "Domain does not accept mail",
244 to the function group and numerical lists (Sections 4.2.2 and 4.2.3,
245 respectively) of RFC 5321. It also adds the 521 code to the
246 "CONNECTION ESTABLISHMENT" portion of Section 4.3.2 ("Command-Reply
247 Sequences"), preceding the 554 code, and the 556 code to the "RCPT"
248 portion of that same section.
2505.2. The RFC 1846 Experiment
252 By formalizing reply code 521, this specification ends the experiment
253 proposed in RFC 1846. That document also discusses general
254 strategies for hosts that do not accept mail directly. That
255 discussion is out of scope for the present document.
2576. IANA Considerations
259 This document updates RFC 5321 to add descriptions and text for two
260 reply codes, but there is no registry for those codes. IANA has
261 updated the "Enumerated Status Codes" subregistry of the "Simple Mail
262 Transfer Protocol (SMTP) Enhanced Status Codes Registry" [3] to
263 include these codes, specifically:
265 o Added 521 to the list of codes associated with the enhanced code
266 entry for X.3.2, which now references this document.
268 o Added this document to the references associated with the enhanced
269 code entry for X.1.10 and reply code 556. Note that, if a use for
270 556 arises that is not associated with null MX [5], it may be
271 necessary to add an additional enhanced code, but such action is
272 outside the scope of this document.
282Klensin Standards Track [Page 5]
284RFC 7504 SMTP 521 and 556 Reply Codes June 2015
2877. Security Considerations
289 Not running any SMTP server, or running an SMTP server that simply
290 emits fixed strings in response to incoming connections, should
291 provide significantly fewer opportunities for security problems than
292 running a complete SMTP implementation. See the Security
293 Considerations section of RFC 7505 [5] for a discussion of security
294 issues with that approach. Use of the specific codes provided here
295 provides more information to the client than a generic or arbitrarily
296 chosen 5yz code but should have no other effect on security.
3008.1. Normative References
302 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
303 Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
304 <http://www.rfc-editor.org/info/rfc2119>.
306 [2] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
307 DOI 10.17487/RFC5321, October 2008,
308 <http://www.rfc-editor.org/info/rfc5321>.
310 [3] IANA, "Simple Mail Transfer Protocol (SMTP) Enhanced Status
312 <http://www.iana.org/assignments/smtp-enhanced-status-codes>.
3148.2. Informative References
316 [4] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846,
317 DOI 10.17487/RFC1846, September 1995,
318 <http://www.rfc-editor.org/info/rfc1846>.
320 [5] Levine, J. and M. Delany, "A "Null MX" No Service Resource
321 Record for Domains That Accept No Mail", RFC 7505,
322 DOI 10.17487/RFC7505, June 2015,
323 <http://www.rfc-editor.org/info/rfc7505>.
338Klensin Standards Track [Page 6]
340RFC 7504 SMTP 521 and 556 Reply Codes June 2015
345 Alain Durand and Francis Dupont proposed the 521 code in RFC 1846
346 [4]. They also participated in an extended conversation and provided
347 many useful comments that led to this document. The document also
348 contains, with their permission, some text copied from that early
351 Discussion of the "null MX" approach and proposal [5] inspired the
352 creation of this specification. Specific comments and suggestions
353 from John Levine (co-author of that document) were also helpful.
355 Martin Duerst and Tom Petch identified significant issues in the
356 initial draft of the current form of the document.
358 Dilyan Palauzov did a careful reading and identified an editorial
361 Ned Freed, Tony Hansen, and Rolf Sonneveld suggested textual
362 improvements that were incorporated. Tony Hansen also acted as
363 document shepherd and made several contributions in conjunction with
369 1770 Massachusetts Ave, Ste 322
373 Phone: +1 617 245 1457
374 Email: john-ietf@jck.com
394Klensin Standards Track [Page 7]