Browse Prior Art Database

SMTP 521 and 556 Reply Codes (RFC7504)

IP.com Disclosure Number: IPCOM000242281D
Original Publication Date: 2015-Jun-01
Included in the Prior Art Database: 2015-Jul-01
Document File: 14 page(s) / 14K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Klensin: AUTHOR

Abstract

The SMTP specification [2] (referred to, along with its various updates, as "SMTP" below) contains a list and discussion of reply codes. This document updates that list with a new code, 521, for use in response to an initial connection. In that context, it specifically denotes a system that does not receive mail or otherwise handle SMTP mail or inquiry transactions. That code differs from the use of reply code 554, recommended by RFC 5321, because the latter code can be used in a larger variety of situations, including mail that is not accepted for, or from, particular sources, destinations, or addresses. It also introduces a second reply code, 556, for use when an SMTP client encounters a domain in a forward-pointing address that it can determine (e.g., from the DNS "null MX" convention [5]) does not support receipt of mail and has to report that condition to a host that delivered the message to it for further processing.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 20% of the total text.

Internet Engineering Task Force (IETF)                        J. Klensin Request for Comments: 7504                                     June 2015 Updates: 1846, 5321 Category: Standards Track ISSN: 2070-1721

                       SMTP 521 and 556 Reply Codes

Abstract

   This memo defines two Simple Mail Transfer Protocol (SMTP) reply    codes, 521 and 556.  The 521 code was originally described in an    Experimental RFC in 1995 and is in wide use, but has not previously    been formally incorporated into SMTP.  The 556 code was created to    support the new tests and actions specified in RFC 7505.  These codes    are used to indicate that an Internet host does not accept incoming    mail at all.  This specification is not applicable when the host    sometimes accepts mail but may reject particular messages, or even    all messages, under specific circumstances.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force    (IETF).  It represents the consensus of the IETF community.  It has    received public review and has been approved for publication by the    Internet Engineering Steering Group (IESG).  Further information on    Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,    and how to provide feedback on it may be obtained at    http://www.rfc-editor.org/info/rfc7504.

Klensin                      Standards Track                    [Page 1]
 RFC 7504              SMTP 521 and 556 Reply Codes             June 2015

 Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the    document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal    Provisions Relating to IETF Documents    (http://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3

     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3

   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3

   3.  The 521 Reply Code  . . . . . . . . . . . . . . . . . . . . .   4

   4.  The 556 Reply Code  . . . . . . . . . . . . . . . . . . . . .   4

   5.  Small Details to Avoid Loose Ends . . ....