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
newname.cam.ac.uk 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.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima