[Ltru] Re: [EAI] New draft for allowing UTF-8 inSMTP responses
Frank Ellermann <nobody@xyzzy.claranet.de> Thu, 24 August 2006 04:06 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG6UF-000564-0l; Thu, 24 Aug 2006 00:06:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG6UC-00055A-IX for ltru@lists.ietf.org; Thu, 24 Aug 2006 00:06:32 -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 1GG6UC-0001kt-G4 for ltru@lists.ietf.org; Thu, 24 Aug 2006 00:06:32 -0400
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GG6Gn-0006nE-MJ for ltru@lists.ietf.org; Wed, 23 Aug 2006 23:52:45 -0400
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GG6Gk-00020n-9a for ltru@lists.ietf.org; Thu, 24 Aug 2006 05:52:38 +0200
Received: from pd9fbad01.dip0.t-ipconnect.de ([217.251.173.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ltru@lists.ietf.org>; Thu, 24 Aug 2006 05:52:38 +0200
Received: from nobody by pd9fbad01.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ltru@lists.ietf.org>; Thu, 24 Aug 2006 05:52:38 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ltru@lists.ietf.org
From: Frank Ellermann <nobody@xyzzy.claranet.de>
Date: Thu, 24 Aug 2006 05:52:09 +0200
Organization: <URL:http://purl.net/xyzzy>
Lines: 63
Message-ID: <44ED2269.70F3@xyzzy.claranet.de>
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> <44EB4886.5010009@yahoo-inc.com> <CA5C301C3FE7D5F20D5A3DBE@p3.JCK.COM> <6.0.0.20.2.20060824072912.08dc0e60@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: pd9fbad01.dip0.t-ipconnect.de
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: ima@ietf.org
Subject: [Ltru] Re: [EAI] New draft for allowing UTF-8 inSMTP responses
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Errors-To: ltru-bounces@ietf.org
Martin Duerst wrote: > TR9 is an Unicode Standards Annex (UAX), which means it is > part of the Standard. In many ways, at the very moment you > say UTF-8, you include it. You could take UTF-8 as "ASCII plus opaque garbage" in various protocols, and then other parts of [Unicode] are not relevant. Nobody's forced to use say Unicode collation or hyphenation only because (s)he uses UTF-8 referencing STD 63, Another example would be 3066bis, it references ISO 3166. Nobody using language tags is now forced to use also 3166-3 codes, they can still make up their own stuff, use CLDR or what else. > as most of us know and Harald has shown again, the situation > with SMTP error message consistency is much worse than with > any other, comparable protocol. The RFC 4408 folks made sure that URIs work, indirectly that arrives as whatever e.g. http offers. A scenario for RFC 4408 is a user trying to send on a route not permitted by the sender policy of his domain. What really happens: User submits mail to the "wrong" MSA, and this MSA doesnt't enforce submission rights (RFC 4409 6.1), it tries to forward the mail towards the recipient. The MX checks the sender policy (RFC 4408) by querying a nameserver of the domain in the Return-Path. That policy says "FAIL" and offers an explanation in the form of an URI (optional of course). The MX "encodes" this as 5.7.1 error response (RFC 2034) - oops, the 2034-reference was still correct in draft 00, odd, maybe the missing 2034 was my bad - while talking with the "wrong" MSA (or its mailout). Of course the MX is not forced to add the explanation of this third party to its 5.7.1, but it can, let's assume that it did. The MSA had accepted the mail for forward or delivery, and that didn't work, therefore it MUST (RFC 821/2821) generate a non- delivery message (aka "bounce", not the definition in 2821). It will probably copy the 5.7.1 error message verbatim into its non-delivery message. It then puts the error message in the mailbox of the user of this domain. Or forwards it if the user arranged it this way. Later the user finds the bounce, that quotes the 5.7.1 (maybe), and the 5.7.1 quotes the FAIL-explanation (maybe), that is an URI, and now the user can contact that URI (maybe), and if it is HTTP depending on the server, the browser, LTRU, matching, and some other details the user can read the explanation of an admin in his domain in their preferred language, why this mail didn't make it on the wrong route. That's in a nutshell the reason why there are no explicit I18N considerations in RFC 4408: It would never do to tunnel some non-ASCII text from DNS through a 5.7.1 and a bounce, besides it would be pointless, the domain can have many users with many different languages. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru
- [Ltru] Re: [EAI] New draft for allowing UTF-8 in … Martin Duerst
- [Ltru] Re: [EAI] New draft for allowing UTF-8 in … Doug Ewell
- [Ltru] Re: [EAI] New draft for allowing UTF-8 in … Tony Finch
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Randy Presuhn
- [Ltru] Re: [EAI] New draft for allowing UTF-8 in … 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… Addison Phillips
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… John C Klensin
- [Ltru] Re: [EAI] New draft for allowing UTF-8 in … Doug Ewell
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Harald Alvestrand
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Tony Finch
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Kristin Hubner
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Ned Freed
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Martin Duerst
- [Ltru] Re: [EAI] New draft for allowing UTF-8 in … Frank Ellermann
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Martin Duerst
- [Ltru] Re: [EAI] New draft for allowing UTF-8 inS… Frank Ellermann
- [Ltru] Re: [EAI] New draft for allowing UTF-8 in … 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
- Re: [Ltru] Re: [EAI] New draft for allowing UTF-8… Alexey Melnikov