Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
Tony Finch <dot@dotat.at> Wed, 23 August 2006 15:09 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuMJ-00081U-Cl; Wed, 23 Aug 2006 11:09:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuMI-00081L-Jg; Wed, 23 Aug 2006 11:09:34 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFsK4-0006up-NV; Wed, 23 Aug 2006 08:59:08 -0400
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by chiedprmail1.ietf.org 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
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:52637) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1GFrxZ-0006SQ-1G (Exim 4.54) (return-path <fanf2@hermes.cam.ac.uk>); Wed, 23 Aug 2006 13:35:53 +0100
Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1GFrxZ-0007fS-Ax (Exim 4.54) (return-path <fanf2@hermes.cam.ac.uk>); Wed, 23 Aug 2006 13:35:53 +0100
Date: Wed, 23 Aug 2006 13:35:53 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Harald Alvestrand <harald@alvestrand.no>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
In-Reply-To: <44EC3A45.90201@alvestrand.no>
Message-ID: <Pine.LNX.4.64.0608231231070.5633@hermes-2.csi.cam.ac.uk>
References: <44E09667.8070704@isode.com> <6.0.0.20.2.20060818150743.097d4ec0@localhost> <Pine.LNX.4.64.0608211251060.5633@hermes-2.csi.cam.ac.uk> <003401c6c54d$18765640$6501a8c0@oemcomputer> <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> <44EC3A45.90201@alvestrand.no>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: -2.4 (--)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: Randy Presuhn <randy_presuhn@mindspring.com>, LTRU Working Group <ltru@ietf.org>, Addison Phillips <addison@yahoo-inc.com>, ima@ietf.org
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
Errors-To: ima-bounces@ietf.org
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
- [EAI] New draft for allowing UTF-8 in SMTP respon… Alexey Melnikov
- Re: [Filtered!] [EAI] New draft for allowing UTF-… Tony Finch
- Re: [Filtered!] [EAI] New draft for allowing UTF-… Alexey Melnikov
- Re: [Filtered!] [EAI] New draft for allowing UTF-… Tony Finch
- Re: [EAI] New draft for allowing UTF-8 in SMTP re… Harald Alvestrand
- Re: [EAI] New draft for allowing UTF-8 in SMTP re… Alexey Melnikov
- Re: [EAI] New draft for allowing UTF-8 in SMTP re… Harald Alvestrand
- Re: [EAI] New draft for allowing UTF-8 in SMTP re… Tony Finch
- Re: [EAI] New draft for allowing UTF-8 in SMTP re… Alexey Melnikov
- Re: [EAI] New draft for allowing UTF-8 in SMTP re… Harald Alvestrand
- Re: [EAI] New draft for allowing UTF-8 in SMTP re… Martin Duerst
- Re: [EAI] New draft for allowing UTF-8 in SMTP re… Tony Finch
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Randy Presuhn
- Re: [EAI] New draft for allowing UTF-8 in SMTP re… Alexey Melnikov
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… John C Klensin
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… John C Klensin
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Charles Lindsey
- Re: [EAI] New draft for allowing UTF-8 in SMTP re… Charles Lindsey
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Harald Alvestrand
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Addison Phillips
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Tony Finch
- Re: [EAI] New draft for allowing UTF-8 in SMTP re… Martin Duerst
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Martin Duerst
- Re: [EAI] New draft for allowing UTF-8 inSMTP res… Frank Ellermann
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Charles Lindsey
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Alexey Melnikov