Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses

Tony Finch <> Wed, 23 August 2006 15:09 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GFuMJ-00081U-Cl; Wed, 23 Aug 2006 11:09:35 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GFuMI-00081L-Jg; Wed, 23 Aug 2006 11:09:34 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1GFsK4-0006up-NV; Wed, 23 Aug 2006 08:59:08 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GFrxy-0008G3-Fh; Wed, 23 Aug 2006 08:36:21 -0400
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
Received: from ([]:52637) by ( []:25) with esmtpa (EXTERNAL:fanf2) id 1GFrxZ-0006SQ-1G (Exim 4.54) (return-path <>); Wed, 23 Aug 2006 13:35:53 +0100
Received: from fanf2 (helo=localhost) by ( with local-esmtp id 1GFrxZ-0007fS-Ax (Exim 4.54) (return-path <>); Wed, 23 Aug 2006 13:35:53 +0100
Date: Wed, 23 Aug 2006 13:35:53 +0100
From: Tony Finch <>
To: Harald Alvestrand <>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <003401c6c54d$18765640$6501a8c0@oemcomputer> <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: -2.4 (--)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: Randy Presuhn <>, LTRU Working Group <>, Addison Phillips <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Wed, 23 Aug 2006, Harald Alvestrand wrote:
> Query: Has anyone seen a production piece of software that tries to decode the
> extendedstatuscodes as text for display to the users?

Yes, and the result is usually unhelpful in my experience. A significant
number of support queries that I have to deal with are solved by me
pulling an error message out of the logs that was hidden by some software
between my servers and the user. (Admittedly, this is more likely to
happen for us because we don't support enhanced status codes, but since
they carry so little extra information I doubt they would help.)

John says:
> As with many other Internet protocols, the most effective model is to
> use a single form on the wire and then perform translations (of
> character sets, terminal information, formats, and, yes, languages) at
> the endpoints.  The "rely on the codes" requirement of 821 was, and is,
> part of that concern.

That's not the way I read it. To me it says that the non-enhanced codes
are for the client state machine and the text is for a human; it does not
imply that a client should replace the server's text with its own idea of
what went wrong.

> If a user needs to look at an SMTP reply message directly, then I
> suggest that either there is a debugging case in action or the relevant
> MUA is broken.  Debugging cases are easier with more uniformity and
> simplicity, not more options.

If a user sees an SMTP response then something has gone wrong so it's a
debugging case by definition.

Addison says:
> Almost no one interacts with SMTP servers directly.

Of course they do, to the same extent that they interact with IMAP or POP
or HTTP servers - mediated by a user agent.

>From my point of view, and from the point of view of my colleagues on the
help desk, it would be much easier if MUAs did not try to impose their own
gloss on my servers' error messages (or do other stupid things like
truncate them). That way I can provide helpful text that explains what
went wrong, and/or a URL to help pages or a directory.

The current set of enhanced status codes is non-orthogonal and does not
cover the range of possibilities or provide enough detail within their
coverage. For example, there are codes for bad syntax and bad domain for
both sender and recipient addresses, but you can only specifically say the
local part is bad for destination addresses, and there are different OK
codes for senders and recipients. There's a code for "too many recipients"
but not "too few recipients" (e.g. RFC 4468 has a different gloss of 5.5.0
for this situation). In SMTP you can say that an address has changed (551)
but not with enhanced status codes. (We've had a number departments
changing name recently where it might have been useful to use the 551
feature, but since no-one implements it we just used an ad-hoc "try instead" error.) The range of codes for client policy
restrictions is inadequate: there's no way of expressing the distinction
between "relaying is not permitted", "you have been blacklisted", "you are
making too many concurrent connections", "you have been rate-limited",
"you have been greylisted", etc. There are no codes for saying that the
message content violates security restrictions, such as a virus infection
or a forbidden attachment type or a spam classification.

Even if you solve these problems, there is no provision for extending the
set of status codes except as a standards action - there is no IANA
registry. And in fact an IANA registry wouldn't solve the problem because
no existing software will have glosses for any new status codes you might
register, so the new codes would be useless.

The idea of a fixed set of status codes is fundamentally unable to cope
with evolving operational requirements.

f.a.n.finch  <>

IMA mailing list