Re: New SMTP response codes

Ned Freed <Ned.Freed@innosoft.com> Wed, 14 May 1997 15:23 UTC

Received: from cnri by ietf.org id aa28000; 14 May 97 11:23 EDT
Received: from mail.proper.com by CNRI.Reston.VA.US id aa10682; 14 May 97 11:23 EDT
Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA00940 for ietf-smtp-bks; Wed, 14 May 1997 07:54:14 -0700 (PDT)
Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id HAA00934; Wed, 14 May 1997 07:54:11 -0700 (PDT)
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01IIUO3VNM2O99HHRS@INNOSOFT.COM>; Wed, 14 May 1997 07:53:48 PDT
Date: Wed, 14 May 1997 07:40:26 -0700
From: Ned Freed <Ned.Freed@innosoft.com>
Subject: Re: New SMTP response codes
In-reply-to: "Your message dated Tue, 13 May 1997 17:59:40 -0700" <v0310282eaf9ebd82fe9d@[165.227.249.100]>
To: "Paul E. Hoffman" <phoffman@imc.org>
Cc: ietf-smtp@imc.org
Message-id: <01IIUP38LLDK99HHRS@INNOSOFT.COM>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Sender: owner-ietf-smtp@imc.org
Precedence: bulk

> 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.

As John has already pointed out, you really don't need to formally register new
codes in this space. However, John didn't point out that there's another
codespace for response codes, the one defined in RFC1893. You should make sure
that a code exists in this space that works for you, and if it doesn't we need
to get the process going to define whatever additional codes you need.

Any effort at formalizing registration mechanisms needs to be associated
with this new code space, not the old SMTP code space.

Note that RFC2034 specifies the standard way for returning these codes in SMTP.

> (I'm pretty sure I didn't. I grepped all the mail-related drafts and RFCs
> on the IMC site for "560", the number I chose, and got nothing relevant.)

This, unfortunately, will not fly. You have to pick a code with a second digit
of 5 or less. Anything else may be rejected as syntactically illegal by
deployed servers. And such rejection is entirely in conformance with current
specifications, making this a true nonstarter in any case.

You can use the third digit of the code to give you whatever additional
precision you want.

> This isn't a pressing need, but it could be embarassing if we end up with
> two standards-track SMTP extensions that use the same new error code for
> very different things. Sounds like a job for IANA, but we need to define
> what IANA should do.

This really isn't that big a deal. There's lots of overlap in present usage;
one of the main reasons for defining a new code space was to address this
problem.

				Ned