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