Re: New SMTP response codes

John C Klensin <> Wed, 14 May 1997 11:05 UTC

Received: from cnri by id aa20972; 14 May 97 7:05 EDT
Received: from by CNRI.Reston.VA.US id aa06604; 14 May 97 7:05 EDT
Received: (from majordomo@localhost) by (8.8.5/8.7.3) id DAA27443 for ietf-smtp-bks; Wed, 14 May 1997 03:43:38 -0700 (PDT)
Received: from ( []) by (8.8.5/8.7.3) with ESMTP id DAA27438; Wed, 14 May 1997 03:43:35 -0700 (PDT)
Received: from ("port 1373"@[]) by (PMDF V5.1-8 #21705) with SMTP id <>; Wed, 14 May 1997 06:44:12 -0400 (EDT)
Date: Wed, 14 May 1997 06:44:05 -0400 (EDT)
From: John C Klensin <>
Subject: Re: New SMTP response codes
To: "Paul E. Hoffman" <>
Reply-to: John C Klensin <>
Message-id: <>
MIME-version: 1.0
X-Mailer: Simeon for Win32 Version 4.1.1 Build (14)
X-Authentication: none
Precedence: bulk

On Tue, 13 May 1997 17:59:40 -0700 "Paul E. Hoffman" 
<> wrote:

> And now for something completely different. I needed a new SMTP response
> code for an SMTP extension I'm writing. However, I could not find any
> central registry of them. This seems to be a bit of a problem, because I
> don't want to choose the same one that some other extension writer has
> chosen.


Unfotunately, we have a number of implementations that 
believe that the only valid codes are those that are in 821 
-- every time a new one has been added, there has been 
trouble.  Conversely, one or two implementations have 
promiscuously implemented all sorts of codes without 
documenting them.  This was a reason why the "be prepared 
to use first digit only" rule went into RFC 1123 (perhaps 
the main reason).

Consequently, much as a code registry would be a good idea 
--and IANA is probably the right place-- you might as well, 
in practice, just make something up and assume that only 
the first digit will be relevant.

There is a case to be made for trying the following 

 * Make up one more set of codes, e.g.,
    299, 399, 499, 599
   And give them the definition "extended code of 
   status/severity (2, 3, 4, 5), see extended reply 
   code" and a phrase syntax of "n.n.n text".
 * Make absolutely sure that the definitions and extension 
   mechanisms of RFC 1893 are adequate.