SMTP 521 and 556 Reply Codes
draft-klensin-smtp-521code-07

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'SMTP 521 and 556 Reply Codes' to Proposed Standard (draft-klensin-smtp-521code-07.txt)

The IESG has approved the following document:
- 'SMTP 521 and 556 Reply Codes'
  (draft-klensin-smtp-521code-07.txt) as Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Barry Leiba.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-klensin-smtp-521code/

Ballot Text

Technical Summary

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 for
RFC-nullMX.  These codes are used to indicate that an Internet host
does not accept incoming mail at all (not just under particular
circumstances).

This is presented for publication as a Proposed Standard, as it adds codes
to RFC 5321, which is already standards track.


Review and Consensus

This document came out of discussions on both the apps discuss and ietf-smtp
mailing lists about (1) moving RFC 1846 to the standards track, and (2) the
nullMX idea. There was wide-spread agreement on both of those efforts,
including accepting nullMX as an APPS WG document.

The decision to create this document was mostly due to administrative ease so
that there was only one document updating RFC 5321 instead of two. The
nullMX document was then rewritten to point to this document. (The nullMX
document has been through 10 revisions since becoming an APPS WG document.)

There is widespread implementation of both of these return codes.


Personnel

Tony Hansen is the Document Shepherd. Barry Leiba is the responsible
Area Director. This document is an individual submission.

RFC Editor Note