Re: New SMTP response codes

Keith Moore <> Wed, 21 May 1997 02:31 UTC

Received: from cnri by id aa15392; 20 May 97 22:31 EDT
Received: from by CNRI.Reston.VA.US id aa19074; 20 May 97 22:31 EDT
Received: (from majordomo@localhost) by (8.8.5/8.7.3) id TAA21309 for ietf-smtp-bks; Tue, 20 May 1997 19:13:11 -0700 (PDT)
Received: from (SPOT.CS.UTK.EDU []) by (8.8.5/8.7.3) with ESMTP id TAA21304; Tue, 20 May 1997 19:13:07 -0700 (PDT)
Received: from by with ESMTP (cf v2.11c-UTK) id WAA04267; Tue, 20 May 1997 22:14:02 -0400 (EDT)
Message-Id: <>
X-Mailer: exmh version 2.0gamma 1/27/96
From: Keith Moore <>
To: "Paul E. Hoffman" <>
Subject: Re: New SMTP response codes
In-reply-to: Your message of "Tue, 13 May 1997 17:59:40 PDT." <v0310282eaf9ebd82fe9d@[]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 20 May 1997 22:13:58 -0400
Precedence: bulk

just catching up on my mail after a week's vacation...

random thoughts on defining new SMTP response codes:

1. IANA should maintain the list of response codes.

2. The new SMTP document being written by DRUMS should specify the
registration procedure.  (offhand, I'd suggest that the code has to be
defined in a standards-track or experimental RFC with IESG approval)

3. New SMTP codes should probably be defined only when necessary for
the the server to notify the client of a state transition....not just
for new kinds of errors.  RFC 1893 codes, along with the
ENHANCEDSTATUSCODES option, should be used to communicate new kinds of
errors where no new state changes are introduced.

4. There's no problem with defining new SMTP codes if those codes will
only be generated by servers that claim to support a particular ESMTP
option, and only when a client explicitly invokes that option.
Otherwise, there needs to be a really good reason for defining a new a state change.