From ima-bounces@ietf.org Thu Feb 01 06:24:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCa36-0002ls-AA; Thu, 01 Feb 2007 06:24:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCa35-0002lY-2p for ima@ietf.org; Thu, 01 Feb 2007 06:24:15 -0500 Received: from ppsw-2.csi.cam.ac.uk ([131.111.8.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCa32-00051e-BZ for ima@ietf.org; Thu, 01 Feb 2007 06:24:15 -0500 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-1.csi.cam.ac.uk ([131.111.8.51]:42682) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1HCa2X-00021W-6V (Exim 4.63) (return-path ); Thu, 01 Feb 2007 11:23:41 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HCa2W-0002kw-Vx (Exim 4.54) (return-path ); Thu, 01 Feb 2007 11:23:40 +0000 Date: Thu, 1 Feb 2007 11:23:40 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Chris Newman Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 31 Jan 2007, Chris Newman wrote: > > MIME only forbids message encodings for the message subtypes it defines, no > normative restrictions are placed on other message subtypes. If one of the > functions of this experiment is to make email UTF-8 clean, then the advisory > text in section 5.2.4 of RFC 2046 does not apply to the documents in this > experiment. That seems sensible. The draft should say so explicitly. > Downgrading message/utf-8-delivery-status to message/delivery-status is a bad > idea, IMHO. It's not going to break anything if you leave it alone and it > will lose information if downgraded. [...] Encoding with QP or base64 is > fine if necessary. You're probably right. However these new types must be encoded when they leave the utf8 email system. The draft says "if this type is sent to a 7-bit-only system, it could be encoded in base64 or quoted-printable" which is not sufficient. If the DSN is sent from a utf8 mailer to a 8bitmime mailer without encoding, and the 8bitmime mailer then tries to send it to a 7bit mailer, the 8bitmime mailer will not know that it may encode the new message/* types so delivery will fail. This is catastrophic for a DSN. > FYI, Alexey is working on an individual submission adding the SMTP LANG > extension so clients can request localized SMTP error text. I know :-) Tony. -- f.a.n.finch http://dotat.at/ SOUTH UTSIRE FORTIES: WEST 5 TO 7, OCCASIONALLY GALE 8 AT FIRST IN SOUTH UTSIRE, DECREASING 4 OR 5. ROUGH OR VERY ROUGH, DECREASING MODERATE LATER. SHOWERS THEN OCCASIONAL RAIN. GOOD, OCCASIONALLY MODERATE. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 01 07:15:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCaqD-0006C7-P6; Thu, 01 Feb 2007 07:15:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCaqC-0006Bt-Ik for ima@ietf.org; Thu, 01 Feb 2007 07:15:00 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCaq7-00045q-I4 for ima@ietf.org; Thu, 01 Feb 2007 07:15:00 -0500 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1HCaq4-000Puv-CH; Thu, 01 Feb 2007 07:14:52 -0500 Date: Thu, 01 Feb 2007 07:14:51 -0500 From: John C Klensin To: Soobok Lee , Kari Hurtta Subject: Re: [EAI] other thought about > Message-ID: <01DF86AB1FD3343508C0392D@JCK-ACR.jck.com> In-Reply-To: <20070201024131.GK30318@ns5.lsb.org> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> <407B9EC989C15E72DF80867C@p3.JCK.COM> <20070201024131.GK30318@ns5.lsb.org> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, February 01, 2007 11:41 AM +0900 Soobok Lee wrote: >> Within an MUA, that certainly works. Not to my taste, but UI >> behavior is, after all, a matter of taste. > > I made manually a message file which contains unquoted > eai@address as below. > You can save the next rfc2822 message into a mbox file > "/tmp/mbx1" and open it using "mutt -f /tmp/mbx1" (or > elm,pine etc) and then try to make reply-all. If your MUAs > is "robust", > you will see quotations marks are added around CC's name_parts > below in the reply form. As with many other issues with email design, especially in MUAs, many violations of he specifications can be "robustness" to one person and "bugs" to another. The bottom line on this, I believe, is: (1) We should not specify syntax that varies from the base 2821/2822 model unless that is specifically necessary to our task. Permitting (i.e., requiring that systems accept) display names, without quotes, that contain special characters is such a change. We not only should not make it, we should not even be considering it. (2) This is symptomatic of the many reasons why the IETF very rarely tries to specify, or even make strong recommendations about, MUA behavior. When we do, typically we either tie ourselves in knots or people ignore us. The specifications we are working on are about the formats of messages as they are transmitted across the network. The behavior you describe essentially demonstrates that, while these systems are permissive at the user interface, they fix things up and put the right things on the wire. So, even if we somehow "like" the unquoted form, we should still be specifying it with quotes and without exceptions. Gentlemen, with the understanding that this is a personal reaction and request only... This WG has a very hard, and very important, task. We are horribly behind our original schedule: had we managed to keep to it, all of the protocol documents would be in Last Call by now. While I know your intentions are good, distracting everyone with many messages about either what are essentially UI issues or that seem to reopen and re-hash issues already settled (some of them settled by the time RFC 821 was published) do not move us forward and, at least for those participants who tend to tune out when they see a large series of irrelevant messages, may actually constitute an impediment. Let's try to focus on the core issues and get the work done. Please. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 01 08:22:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCbtC-0000dG-UF; Thu, 01 Feb 2007 08:22:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCbtC-0000cI-7O for ima@ietf.org; Thu, 01 Feb 2007 08:22:10 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCbt9-00043A-QC for ima@ietf.org; Thu, 01 Feb 2007 08:22:09 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l11DM4J5027934; Thu, 1 Feb 2007 22:22:04 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l11DM3Kf027933; Thu, 1 Feb 2007 22:22:03 +0900 Date: Thu, 1 Feb 2007 22:22:03 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] other thought about > Message-ID: <20070201132203.GA19841@ns5.lsb.org> References: <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> <407B9EC989C15E72DF80867C@p3.JCK.COM> <20070201024131.GK30318@ns5.lsb.org> <01DF86AB1FD3343508C0392D@JCK-ACR.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01DF86AB1FD3343508C0392D@JCK-ACR.jck.com> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Feb 01, 2007 at 07:14:51AM -0500, John C Klensin wrote: > > > --On Thursday, February 01, 2007 11:41 AM +0900 Soobok Lee > wrote: > > >>Within an MUA, that certainly works. Not to my taste, but UI > >>behavior is, after all, a matter of taste. > > > >I made manually a message file which contains unquoted > >eai@address as below. > >You can save the next rfc2822 message into a mbox file > >"/tmp/mbx1" and open it using "mutt -f /tmp/mbx1" (or > >elm,pine etc) and then try to make reply-all. If your MUAs > >is "robust", > >you will see quotations marks are added around CC's name_parts > >below in the reply form. > > As with many other issues with email design, especially in MUAs, > many violations of he specifications can be "robustness" to one > person and "bugs" to another. The bottom line on this, I > believe, is: > > (1) We should not specify syntax that varies from the > base 2821/2822 model unless that is specifically > necessary to our task. Permitting (i.e., requiring that > systems accept) display names, without quotes, that > contain special characters is such a change. We not > only should not make it, we should not even be > considering it. (This is the closing remark of this thread) I agree with you and have been so. I don't support permitting "eai@address " here, rather the opposite ! What I tried to point out with my examples is that "eai@address " are silently permitted now, while eai@address [ascii@address] will be rejected, by most existing non-EAI-capable parsers. That explains why I favor [ascii@address] over . Permitting "eai@address [ascii@address]" in [utf8headers] has no problem, but permitting "eai@address " make conflicts. This will clear my position for [ascii@address]. If you and others have other opinions, please make new subjects and thread about this. > > (2) This is symptomatic of the many reasons why the IETF > very rarely tries to specify, or even make strong > recommendations about, MUA behavior. When we do, > typically we either tie ourselves in knots or people > ignore us. The specifications we are working on are > about the formats of messages as they are transmitted > across the network. The behavior you describe > essentially demonstrates that, while these systems are > permissive at the user interface, they fix things up and > put the right things on the wire. So, even if we > somehow "like" the unquoted form, we should still be > specifying it with quotes and without exceptions. > > Gentlemen, with the understanding that this is a personal > reaction and request only... > > This WG has a very hard, and very important, task. We are > horribly behind our original schedule: had we managed to keep to > it, all of the protocol documents would be in Last Call by now. > While I know your intentions are good, distracting everyone with > many messages about either what are essentially UI issues or > that seem to reopen and re-hash issues already settled (some of > them settled by the time RFC 821 was published) do not move us > forward and, at least for those participants who tend to tune > out when they see a large series of irrelevant messages, may > actually constitute an impediment. > > Let's try to focus on the core issues and get the work done. > Please. Sure! Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 01 13:34:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCglR-0006CM-MG; Thu, 01 Feb 2007 13:34:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCglQ-0006C9-Kr for ima@ietf.org; Thu, 01 Feb 2007 13:34:28 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCglO-0008Mk-D9 for ima@ietf.org; Thu, 01 Feb 2007 13:34:28 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HCglI-0004iP-41 for ima@ietf.org; Thu, 01 Feb 2007 19:34:20 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Feb 2007 19:34:20 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Feb 2007 19:34:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: [ ] again (Re: [EAI] other thought about >) Date: 01 Feb 2007 20:34:09 +0200 Lines: 25 Message-ID: <5d1wl9n2vy.fsf_-_@Hurtta06k.keh.iki.fi> References: <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> <407B9EC989C15E72DF80867C@p3.JCK.COM> <20070201024131.GK30318@ns5.lsb.org> <01DF86AB1FD3343508C0392D@JCK-ACR.jck.com> <20070201132203.GA19841@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Soobok Lee writes in gmane.ietf.ima: > I agree with you and have been so. > I don't support permitting "eai@address " here, > rather the opposite ! > > What I tried to point out with my examples is that > "eai@address " are silently permitted now, while > eai@address [ascii@address] will be rejected, by most > existing non-EAI-capable parsers. > > That explains why I favor [ascii@address] over . > > Permitting "eai@address [ascii@address]" in [utf8headers] > has no problem, but permitting "eai@address " > make conflicts. > > This will clear my position for [ascii@address]. > > If you and others have other opinions, please make new subjects and > thread about this. With [ ] there is own problems. I have stated them already. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 01 15:41:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCike-0005XI-UU; Thu, 01 Feb 2007 15:41:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCike-0005XD-Ia for ima@ietf.org; Thu, 01 Feb 2007 15:41:48 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCikZ-00045k-6u for ima@ietf.org; Thu, 01 Feb 2007 15:41:48 -0500 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l11KfgG5028182 for ; Thu, 1 Feb 2007 13:41:42 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCS00B01XEDBA00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Thu, 01 Feb 2007 13:41:42 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCS000URXHFSE30@mail-amer.sun.com>; Thu, 01 Feb 2007 13:41:42 -0700 (MST) Date: Thu, 01 Feb 2007 12:41:40 -0800 From: Chris Newman Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt In-reply-to: To: Tony Finch Message-id: <4696405D8A8A092D3147741B@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Tony Finch wrote on 2/1/07 11:23 +0000: > On Wed, 31 Jan 2007, Chris Newman wrote: >> >> MIME only forbids message encodings for the message subtypes it defines, no >> normative restrictions are placed on other message subtypes. If one of the >> functions of this experiment is to make email UTF-8 clean, then the advisory >> text in section 5.2.4 of RFC 2046 does not apply to the documents in this >> experiment. > > That seems sensible. The draft should say so explicitly. Good idea. I'll add the following text to the end of section 5 in the next revision: All three new types will typically use the "8bit" Content-Transfer- Encoding (in the event all content is 7-bit, the equivalent traditional types for delivery status notifications are advised for greater backwards compatibility). While MIME [RFC2046] advises against the use of 8-bit in new message subtypes intended for the email infrastructure, that advice does not apply to these new types which are intended primarily for use by newer systems with full support for 8-bit MIME and UTF-8 headers. Alternative text proposals are welcome. >> Downgrading message/utf-8-delivery-status to message/delivery-status is a bad >> idea, IMHO. It's not going to break anything if you leave it alone and it >> will lose information if downgraded. [...] Encoding with QP or base64 is >> fine if necessary. > > You're probably right. However these new types must be encoded when they > leave the utf8 email system. The draft says "if this type is sent to a > 7-bit-only system, it could be encoded in base64 or quoted-printable" > which is not sufficient. If the DSN is sent from a utf8 mailer to a > 8bitmime mailer without encoding, and the 8bitmime mailer then tries to > send it to a 7bit mailer, the 8bitmime mailer will not know that it may > encode the new message/* types so delivery will fail. This is catastrophic > for a DSN. The MIME specification directs MIME agents to treat unknown message/* subtypes as if they were application/octet-stream. That means complaint MIME agents will know to base64 encode or quoted-printable encode 8bit body parts automatically as needed. I really don't see any chance of problems with compliant systems. If there are enough non-compliant systems talking to 7-bit-only systems deployed to cause real problems, then I'm sure the experiment will discover that. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 01 16:03:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCj5K-0007FI-Tl; Thu, 01 Feb 2007 16:03:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCj5K-0007F3-6b for ima@ietf.org; Thu, 01 Feb 2007 16:03:10 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCj4Q-00088A-QB for ima@ietf.org; Thu, 01 Feb 2007 16:03:08 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3$clerew*man#ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45c25554.bbbe.3d1 for ima@ietf.org; Thu, 1 Feb 2007 21:02:12 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l11L26eA019121 for ; Thu, 1 Feb 2007 21:02:07 GMT Date: Thu, 01 Feb 2007 21:02:05 -0000 To: IMA Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> <5dy7nl4ru5.fsf@Hurtta06k.keh.iki.fi> <5dmz401kzo.fsf@Hurtta06k.keh.iki.fi> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 31 Jan 2007 23:14:25 -0000, Chris Newman wrote: > Charles Lindsey wrote on 1/31/07 17:08 +0000: >> BTW, I tried an experiment to see how much overhead this check cost, >> and I >> could not detect any difference,... > > On modern hardware, the MTA bottlenecks are either the spam/virus engine > or the disk I/O subsystem. The cost to scan the MIME structure (or > scan/verify a DKIM signature) is negligible by comparison. You'd > probably see the same result (MIME scanning has no real cost) on any > modern MTA which properly commits messages to disk with fsync/fdatasync > or the equivalent. No, there was no spam/virus engine in my test, and the timing was done with /usr/bin/time which reports cpu time separately from real time - but in any case I have enough memory that it was all cached in memory anyway, so real time was little more than cpu time. However, the plot thickens - and then it thins out again. I have spent today doing more careful timing tests, and it turns out that sendmail actually runs _faster_ when you do the walk of the whole mime tree than when you don't! And that eventiually turned out to be becasue it actually copies the file to the output as it is doing the walk, and it just happens to use slightly faster (but I suspect buggier) code that when it does its normal copying. Anyway, here is how I now see it as regards downgrading (or bouncing) in the case of UTF8SMTP. 1. As you read the DATA, you check whether there is an 8th bit anywhere in the message. If not, then you have neither 8BITMIME nor UTF8SMTP problems, and everything else is simple. Note that this is only done once; what follows has to be done separately for each recipient of the message (though sensible cacheing of any downgraded form will help). 2. Moreover if, for each recipient you look at, the next MTA in line already supports UTF8SMTP (and hence 8BITMIME as well), you are still on the simple case and no special measures are needed. 3. Otherwise. if the message turns out to need 8BITMIME or UTF8SMTP, then downgrading is needed. If you try to discover this _beforehand_ (by walking through the whole tree, assuming we do not have a Header-Type to help us out), and then downgrade (or not) depending on the result of that test, then you will have a severe performance hit on account of doing the walk. So you don't do it that way. 4. Instead of that (and assuming you have already found an 8th bit somewhere in step #1, and no UTF8SMTP capability in the next agent in step #2), you start doing the full downgrade process, walking through the complete MIME tree and looking for an 8th bit in headers (which will need a UTF8SMTP downgrade) or an 8th bit in a body (which will need an 8BITMIME downgrade unless the nect MTA does 8BITMIME). So, in either case, you do each downgrade (or bouce/reject if you don't like downgrading) as you come to it. 5. If, in fact, it turns out out that no downgrading was needed at any stage, then no change will have been made to the message and no harm will have been done, but you will have wasted a bit of time analysing the MIME structure as you went throught it; but the imnportant thing is that you never had to scan the whole message twice. Obviously, much the same thing can be done by MDAs and MUAs. What worries me is still that people who write ad hoc scripts for processing mail are unlikely to go through all that properly, and that will lead to errors. So I would still prefer to see a Header-Type header, but it looks as though I am going to be outvoted on that one :-( . -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 01 16:24:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCjPS-00050I-Fm; Thu, 01 Feb 2007 16:23:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCjPR-0004z9-Jw for ima@ietf.org; Thu, 01 Feb 2007 16:23:57 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCjP8-00080a-Vd for ima@ietf.org; Thu, 01 Feb 2007 16:23:57 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3$clerew&man&ac*uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45c25a59.bbbe.3f1 for ima@ietf.org; Thu, 1 Feb 2007 21:23:37 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l11LNYBN020414 for ; Thu, 1 Feb 2007 21:23:34 GMT To: IMA Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt References: Message-ID: Date: Thu, 01 Feb 2007 21:23:33 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 31 Jan 2007 23:37:59 -0000, Chris Newman wrote: > Tony Finch wrote on 1/31/07 2:20 +0000: >> MIME forbids the encoding of message/* parts, so a message/utf-8 part >> would have to be downgraded instead. Note that new message/* parts >> inside >> 8bit messages will cause problems for existing 8BITMIME downgraders. > > MIME only forbids message encodings for the message subtypes it defines, > no normative restrictions are placed on other message subtypes. If one > of the functions of this experiment is to make email UTF-8 clean, then > the advisory text in section 5.2.4 of RFC 2046 does not apply to the > documents in this experiment. Hmmmm! That wording uses "should" rather than "SHOULD", so you are technically correct. However, much existing software may have assumed that advice would be followed, and so I do not think is necessarily wise to go against it. The problem we are faced with is this: If there is to be no Header-Type header (and it seems I am about to be outvoted on that), then there is a necessity to walk through the whole of the MIME tree looking for things that might need to be downgraded. Lots of software will be written that does that (and hopefully correctly, though our drafts need to stress the point so that nobody overlooks it). BUT if somebody then goes and invents a new message/* subtype that invalidates that carefully crafted software, then we are going to be in serious trouble, because we cannot expect writers of MTAs etc to keep up with all the latest MIME fads, and even less can we expect mailservers throughout the world to routinely upgrade to the latest release. It will be quite an achievement if we can get the bulk of the world's mailservers to upgrade to UTF8SMTP once, but to expect them to keep on upgrading for ever after is too much. Fortunately, treating all message subtypes as it they were message/rfc822 just happens to work with all the existing subtypes (and that might hopefully remain the case). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 01 18:15:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCl8e-00012u-7h; Thu, 01 Feb 2007 18:14:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCl8d-00012e-Ep for ima@ietf.org; Thu, 01 Feb 2007 18:14:43 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCl8b-0000eL-Ri for ima@ietf.org; Thu, 01 Feb 2007 18:14:43 -0500 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l11NEfu0007974 for ; Thu, 1 Feb 2007 16:14:41 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCT00G014KDN600@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Thu, 01 Feb 2007 16:14:41 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCT000VW4KESE40@mail-amer.sun.com>; Thu, 01 Feb 2007 16:14:40 -0700 (MST) Date: Thu, 01 Feb 2007 15:14:39 -0800 From: Chris Newman Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt In-reply-to: To: Charles Lindsey , IMA Message-id: <5123077E6AE114B2367CD502@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote on 2/1/07 21:23 +0000: > Fortunately, treating all message subtypes as it they were message/rfc822 > just happens to work with all the existing subtypes (and that might > hopefully remain the case). Software which did that would not be following this advice (RFC 2046, section 5.2.4): MIME implementations must in general treat unrecognized subtypes of "message" as being equivalent to "application/octet-stream". And would also incorrectly process message/external-body and message/delivery-status among others. Now if there turns out to be a lot of deployed software which doesn't follow that advice, then I presume we'll discover that as part of the experiment and we can move the new 8bit types under application. But shouldn't we at least try to put them under the semantically correct top-level type? - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 01 18:56:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HClnQ-0000kI-FR; Thu, 01 Feb 2007 18:56:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HClnO-0000kC-QM for ima@ietf.org; Thu, 01 Feb 2007 18:56:51 -0500 Received: from ppsw-2.csi.cam.ac.uk ([131.111.8.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HClnK-0000BH-Hv for ima@ietf.org; Thu, 01 Feb 2007 18:56:50 -0500 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-1.csi.cam.ac.uk ([131.111.8.51]:33429) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1HClnG-0003eO-8P (Exim 4.63) (return-path ); Thu, 01 Feb 2007 23:56:42 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HClnG-00040R-Id (Exim 4.54) (return-path ); Thu, 01 Feb 2007 23:56:42 +0000 Date: Thu, 1 Feb 2007 23:56:42 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Charles Lindsey Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.9 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 1 Feb 2007, Charles Lindsey wrote: > > That wording uses "should" rather than "SHOULD" It's pre-2119. Tony. -- f.a.n.finch http://dotat.at/ HUMBER THAMES: WEST OR SOUTHWEST 2 OR 3, INCREASING 4, OCCASIONALLY 5 IN HUMBER LATER. SMOOTH OR SLIGHT, OCCASIONALLY MODERATE. OCCASIONAL RAIN LATER. MODERATE OR GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 01 19:13:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCm32-00075Q-UT; Thu, 01 Feb 2007 19:13:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCm32-00073w-8P for ima@ietf.org; Thu, 01 Feb 2007 19:13:00 -0500 Received: from ppsw-4.csi.cam.ac.uk ([131.111.8.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCm2z-00041x-Rj for ima@ietf.org; Thu, 01 Feb 2007 19:13:00 -0500 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-1.csi.cam.ac.uk ([131.111.8.51]:35911) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1HCm2o-0003Ee-Et (Exim 4.63) (return-path ); Fri, 02 Feb 2007 00:12:46 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HCm2o-0006KA-In (Exim 4.54) (return-path ); Fri, 02 Feb 2007 00:12:46 +0000 Date: Fri, 2 Feb 2007 00:12:46 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Chris Newman Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt In-Reply-To: <4696405D8A8A092D3147741B@[10.1.110.5]> Message-ID: References: <4696405D8A8A092D3147741B@[10.1.110.5]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Tony Finch , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 1 Feb 2007, Chris Newman wrote: > > Good idea. I'll add the following text to the end of section 5 in the next > revision: > > All three new types will typically use the "8bit" Content-Transfer- > Encoding (in the event all content is 7-bit, the equivalent > traditional types for delivery status notifications are advised for > greater backwards compatibility). While MIME [RFC2046] advises > against the use of 8-bit in new message subtypes intended for the > email infrastructure, that advice does not apply to these new types > which are intended primarily for use by newer systems with full > support for 8-bit MIME and UTF-8 headers. I like that. I'd suggest referring specifically to section 5.2.4 of RFC 2046 and pointing out that the "equivalent to application/octet-stream" clause implies that existing 8bitmime mailers should already be happy to encode message/* if necessary. > The MIME specification directs MIME agents to treat unknown message/* > subtypes as if they were application/octet-stream. That means complaint > MIME agents will know to base64 encode or quoted-printable encode 8bit > body parts automatically as needed. Hmm, yes. I think I've been more conservative than necessary because I've been mixing up the message/* requirements with the stricter multipart/* requirements. I still have some residual worries about the message/utf-8 type, which you have mostly addressed in section 5 of the draft. I think the text about IMAP is too specific: it's just an example of possible interop problems (but still rather vague about the IMAP implications). In particular you are introducing a type that would normally be multipart-ish like message/rfc822 is, such that MUAs can extract attachments from enclosed messages, but unlike other multipart types it can be encoded. Tony. -- f.a.n.finch http://dotat.at/ HUMBER THAMES: WEST OR SOUTHWEST 2 OR 3, INCREASING 4, OCCASIONALLY 5 LATER. SMOOTH OR SLIGHT, OCCASIONALLY MODERATE. OCCASIONAL RAIN LATER. MODERATE OR GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 01 20:16:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCn2F-0006cZ-Rl; Thu, 01 Feb 2007 20:16:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCn2E-0006Ws-PY for ima@ietf.org; Thu, 01 Feb 2007 20:16:14 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCn2D-00049z-2Q for ima@ietf.org; Thu, 01 Feb 2007 20:16:14 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l121G5J5027086; Fri, 2 Feb 2007 10:16:05 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l121G4mV027084; Fri, 2 Feb 2007 10:16:04 +0900 Date: Fri, 2 Feb 2007 10:16:04 +0900 From: Soobok Lee To: Kari Hurtta Message-ID: <20070202011604.GB19841@ns5.lsb.org> References: <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> <407B9EC989C15E72DF80867C@p3.JCK.COM> <20070201024131.GK30318@ns5.lsb.org> <01DF86AB1FD3343508C0392D@JCK-ACR.jck.com> <20070201132203.GA19841@ns5.lsb.org> <5d1wl9n2vy.fsf_-_@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d1wl9n2vy.fsf_-_@Hurtta06k.keh.iki.fi> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: ima@ietf.org Subject: [EAI] [ascii@address] vs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Feb 01, 2007 at 08:34:09PM +0200, Kari Hurtta wrote: > Soobok Lee writes in gmane.ietf.ima: > > > I agree with you and have been so. > > I don't support permitting "eai@address " here, > > rather the opposite ! > > > > What I tried to point out with my examples is that > > "eai@address " are silently permitted now, while > > eai@address [ascii@address] will be rejected, by most > > existing non-EAI-capable parsers. > > > > That explains why I favor [ascii@address] over . > > > > Permitting "eai@address [ascii@address]" in [utf8headers] > > has no problem, but permitting "eai@address " > > make conflicts. > > > > This will clear my position for [ascii@address]. > > > > If you and others have other opinions, please make new subjects and > > thread about this. > > With [ ] there is own problems. I have stated them already. > Your examples against [] around domain literals were From: From: From: From: Domain literals are there mainly for specifying IP address. So, "[something]" above should be replaced with [128.124.1.1] etc. From: From: From: From: From: From: From: From: I can't find any visual confusibility here. No danger at least to me. From: From: > From: > From: I replaced [support*] with . I can't find any difference. Do you think the latter is safer than the former one in visual confusibility? And, there may be increased parser implementations complexity around using [ascii@address], as you pointed out. But, that is a minor cost that implementors cannot bu pay, I think. With [ascii@address], we have a "gain", since we can permit this convenient form, From: NON-ASCII-LOCAL@[IPv6:2001:db8:100:f101::1] [support@example.org] From: NON-ASCII-LOCAL@free.tld [support@example.org] With [ascii@address], we need <> surrounding them. That is another cost. Soobok Resnick Standards Track [Page 16] RFC 2822 Internet Message Format April 2001 characters), then the dot-atom form SHOULD be used and the quoted-string form SHOULD NOT be used. Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec. addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part domain = dot-atom / domain-literal / obs-domain domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS] dcontent = dtext / quoted-pair dtext = NO-WS-CTL / ; Non white space controls %d33-90 / ; The rest of the US-ASCII %d94-126 ; characters not including "[", ; "]", or "\" The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a host name or a mail exchanger name) as described in [STD3, STD13, STD14]. In the domain-literal form, the domain is interpreted as the literal Internet address of the <========== particular host. In both cases, how addressing is used and how messages are transported to a particular host is covered in the mail transport document [RFC2821]. These mechanisms are outside of the scope of this document. Klensin Standards Track [Page 36] RFC 2821 Simple Mail Transfer Protocol April 2001 esmtp-param = esmtp-keyword ["=" esmtp-value] esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") esmtp-value = 1*(%d33-60 / %d62-127) ; any CHAR excluding "=", SP, and control characters Keyword = Ldh-str Argument = Atom Domain = (sub-domain 1*("." sub-domain)) / address-literal sub-domain = Let-dig [Ldh-str] address-literal = "[" IPv4-address-literal / IPv6-address-literal / General-address-literal "]" ; See section 4.1.3 Mailbox = Local-part "@" Domain 4.1.3 Address Literals Sometimes a host is not known to the domain name system and communication (and, in particular, communication to report and repair the error) is blocked. To bypass this barrier a special literal form of the address is allowed as an alternative to a domain name. For IPv4 addresses, this form uses four small decimal integers separated by dots and enclosed by brackets such as [123.255.37.2], which indicates an (IPv4) Internet Address in sequence-of-octets form. For IPv6 and other forms of addressing that might eventually be standardized, the form consists of a standardized "tag" that identifies the address syntax, a colon, and the address itself, in a format specified as part of the IPv6 standards [17]. Specifically: IPv4-address-literal = Snum 3("." Snum) IPv6-address-literal = "IPv6:" IPv6-addr General-address-literal = Standardized-tag ":" 1*dcontent Standardized-tag = Ldh-str ; MUST be specified in a standards-track RFC ; and registered with IANA Snum = 1*3DIGIT ; representing a decimal integer ; value in the range 0 through 255 Let-dig = ALPHA / DIGIT Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp IPv6-hex = 1*4HEXDIG IPv6-full = IPv6-hex 7(":" IPv6-hex) IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":" IPv6-hex)] ; The "::" represents at least 2 16-bit groups of zeros ; No more than 6 groups in addition to the "::" may be ; present IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::" Klensin Standards Track [Page 38] RFC 2821 Simple Mail Transfer Protocol April 2001 [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal ; The "::" represents at least 2 16-bit groups of zeros ; No more than 4 groups in addition to the "::" and ; IPv4-address-literal may be present _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 01 20:28:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCnEI-0000sC-Mi; Thu, 01 Feb 2007 20:28:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCnEH-0000s2-1S for ima@ietf.org; Thu, 01 Feb 2007 20:28:41 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCnEF-00070W-Fm for ima@ietf.org; Thu, 01 Feb 2007 20:28:41 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l121SaJ5029189; Fri, 2 Feb 2007 10:28:37 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l121Sang029187; Fri, 2 Feb 2007 10:28:36 +0900 Date: Fri, 2 Feb 2007 10:28:36 +0900 From: Soobok Lee To: Kari Hurtta Message-ID: <20070202012836.GC17903@ns5.lsb.org> References: <7518047A15D398D1797627E5@p3.JCK.COM> <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> <407B9EC989C15E72DF80867C@p3.JCK.COM> <20070201024131.GK30318@ns5.lsb.org> <01DF86AB1FD3343508C0392D@JCK-ACR.jck.com> <20070201132203.GA19841@ns5.lsb.org> <5d1wl9n2vy.fsf_-_@Hurtta06k.keh.iki.fi> <20070202011604.GB19841@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070202011604.GB19841@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ima@ietf.org Subject: [EAI] Re: [ascii@address] vs X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Feb 02, 2007 at 10:16:04AM +0900, Soobok Lee wrote: > > With [ascii@address], we have a "gain", since we can permit this convenient form, > From: NON-ASCII-LOCAL@[IPv6:2001:db8:100:f101::1] [support@example.org] > From: NON-ASCII-LOCAL@free.tld [support@example.org] > > With [ascii@address], we need <> surrounding them. > That is another cost. ==> Errata: With , we need <> surrounding them. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 02 05:13:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCvQA-0006Gn-Mx; Fri, 02 Feb 2007 05:13:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCvQ8-0006D5-NS for ima@ietf.org; Fri, 02 Feb 2007 05:13:28 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCvQ4-0003OB-6p for ima@ietf.org; Fri, 02 Feb 2007 05:13:28 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3$clerew&man&ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45c30eb8.ad4c.b5 for ima@ietf.org; Fri, 2 Feb 2007 10:13:12 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l12AD8hs000932 for ; Fri, 2 Feb 2007 10:13:09 GMT To: IMA Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt References: Message-ID: Date: Fri, 02 Feb 2007 10:13:08 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 01 Feb 2007 23:56:42 -0000, Tony Finch wrote: > On Thu, 1 Feb 2007, Charles Lindsey wrote: >> >> That wording uses "should" rather than "SHOULD" > > It's pre-2119. But RFC 2046 uses MUST and SHOULD elsewhere in the customary manner. That convention was well-established long before 2119 formalized it. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 02 06:23:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCwVD-00064i-6g; Fri, 02 Feb 2007 06:22:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCwVB-00064Y-FB for ima@ietf.org; Fri, 02 Feb 2007 06:22:46 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCwUs-0002Za-3J for ima@ietf.org; Fri, 02 Feb 2007 06:22:45 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HCwUO-0001BM-Pe for ima@ietf.org; Fri, 02 Feb 2007 12:21:56 +0100 Received: from d252203.dialin.hansenet.de ([80.171.252.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Feb 2007 12:21:56 +0100 Received: from nobody by d252203.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Feb 2007 12:21:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 02 Feb 2007 12:18:05 +0100 Organization: Lines: 67 Message-ID: <45C31DED.7F27@xyzzy.claranet.de> References: <5123077E6AE114B2367CD502@[10.1.110.5]> 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: d252203.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [EAI] message/utfxxx (was: I-D ACTION:draft-ietf-eai-dsn-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Newman wrote: > shouldn't we at least try to put them under the semantically > correct top-level type? Yes. And state that minimal MIME conforming software (RFC 2049) wishing to participate in the UTF8SMTP experiment MUST support message/utf-8. A better name might be message/utf822, a mix of utf-8 + rfc822. In your draft you say: - This media type contains Internationalized Email Headers - [I-D.ietf-eai-utf8headers] and MIME message body content. How about this: + This media type supports Internationalized Email Headers + [I-D.ietf-eai-utf8headers], otherwise it's identical to + message/rfc822. Later you have: Applications that use this media type: SMTP servers and email clients that support multipart/report generation or parsing. Email clients which forward messages with international headers as attachments. The "attachments" is IMO wrong, it should be "MIME part or body". A message/rfc822 does not necessarily use a Content-Disposition: attachment, it can as well use Content-Disposition: inline. I think you need a note somewhere stating that multipart/digest continues to have a default message/rfc822, and multipart/digest parts deriving from that default need an explicit Content-Type, like Content-Type: message/utf-8 (or similar) for messages with an UTF-8 header. I don't like the proposed file extension ".u8msg", but I have no better idea, or is ".ums" still available ? What's the point of a different extension for the header, could we get away with the same file extension ? I think you need a chapter about complete MIME message objects which are not a part of a container: Complete messages used to be message/rfc822 by definition. With UTF8SMTP complete messages can be message/rfc822 or message/utfxxx, and the former is a proper subset of the latter. Any valid message/rfc822 is always a valid message/utfxxx. The opposite is not true. Applications trying to embed a complete valid message as MIME part or content have two options: 1 - Don't care, just say message/utfxxx. The draft should say that this lazy approach is NOT RECOMMENDED at this time. 2 - Figure it out, i.e. parse the header (only the header), if it's ASCII they can use message/rfc822, if it's valid UTF-8 they MUST use message/utfxxx, and if it's another variant of non-ASCII they MUST NOT use message/utfxxx. What I have in mind are "message/news" articles using non-ASCII in the header (especially in From: and Subject: fields) where non-ASCII is certainly not valid UTF-8 - maybe it's Latin-1 or even windows-1252. Of course that's no valid message/news, but folks try it anyway. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 02 06:47:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCwtO-0007Xk-MA; Fri, 02 Feb 2007 06:47:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCwtN-0007Xf-Q2 for ima@ietf.org; Fri, 02 Feb 2007 06:47:45 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCwtM-0008GD-Gk for ima@ietf.org; Fri, 02 Feb 2007 06:47:45 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HCwtD-0006S5-IO for ima@ietf.org; Fri, 02 Feb 2007 12:47:35 +0100 Received: from d252203.dialin.hansenet.de ([80.171.252.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Feb 2007 12:47:35 +0100 Received: from nobody by d252203.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Feb 2007 12:47:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt Date: Fri, 02 Feb 2007 12:46:45 +0100 Organization: Lines: 23 Message-ID: <45C324A5.20F3@xyzzy.claranet.de> References: <4696405D8A8A092D3147741B@[10.1.110.5]> 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: d252203.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Newman wrote: > I'll add the following text to the end of section 5 in the next revision: > All three new types will typically use the "8bit" Content-Transfer- > Encoding (in the event all content is 7-bit, the equivalent > traditional types for delivery status notifications are advised for Please s/advised/RECOMMENDED/ Let the future standard say "advised" if the experiment showed that there were no serious problems. But I think there will be serious problems for the remaining fourty "RFC 2277-years". > greater backwards compatibility). While MIME [RFC2046] advises > against the use of 8-bit in new message subtypes intended for the > email infrastructure, that advice does not apply to these new types > which are intended primarily for use by newer systems with full > support for 8-bit MIME and UTF-8 headers. +1 (Ignoring that advice is actually the point of UTF8SMTP experiment) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 02 07:32:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCxaU-0001ig-2C; Fri, 02 Feb 2007 07:32:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCxaT-0001ib-ME for ima@ietf.org; Fri, 02 Feb 2007 07:32:17 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCxaP-000459-56 for ima@ietf.org; Fri, 02 Feb 2007 07:32:17 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HCxa1-0008AK-A9 for ima@ietf.org; Fri, 02 Feb 2007 13:31:49 +0100 Received: from d252203.dialin.hansenet.de ([80.171.252.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Feb 2007 13:31:49 +0100 Received: from nobody by d252203.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Feb 2007 13:31:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 02 Feb 2007 13:28:57 +0100 Organization: Lines: 26 Message-ID: <45C32E89.2C10@xyzzy.claranet.de> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> <5dy7nl4ru5.fsf@Hurtta06k.keh.iki.fi> <5dmz401kzo.fsf@Hurtta06k.keh.iki.fi> 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: d252203.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [EAI] Re: Header-Format: Downgraded X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > Obviously, much the same thing can be done by MDAs and MUAs. What worries > me is still that people who write ad hoc scripts for processing mail are > unlikely to go through all that properly, and that will lead to errors. So > I would still prefer to see a Header-Type header, but it looks as though I > am going to be outvoted on that one :-( I think you're confusing 8BITMIME and UTF8SMTP. For the latter you have only to look at the header, check that it's either pure ASCII (including 2047/2231 encodings resulting in pure ASCII), or valid UTF-8, or invalid. Especially the presence of some non-ASCII octets isn't the same as UTF-8, you MUST NOT claim to have UTF8SMTP just because there's a non-ASCII byte. And as far as "message/utf822" (or similar) is concerned the body of the message, multipart, message, text, or what else, is irrelevant, it's the job of the producer to get this right, not the job of a "downgrade" from UTF8SMTP to ESMTP. Parsing the complete MIME structure is necessary for 8BITMIME to 7bit gateways, but not for a UTF8SMTP to 8BITMIME "downgrade" gateway. Or do I miss some odd scenarios here ? Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 02 08:40:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCyeH-00048C-Fs; Fri, 02 Feb 2007 08:40:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCyeG-00047p-5h for ima@ietf.org; Fri, 02 Feb 2007 08:40:16 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCyeC-0002KA-HN for ima@ietf.org; Fri, 02 Feb 2007 08:40:16 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l12DeATH026062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Feb 2007 05:40:11 -0800 Received: from [[192.168.8.88]] (vpn-10-50-0-76.qualcomm.com [10.50.0.76]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l12De2tj009662; Fri, 2 Feb 2007 05:40:08 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 2 Feb 2007 00:40:11 -0800 To: Chris Newman , John C Klensin , Frank Ellermann , ima@ietf.org From: Randall Gellens Subject: Re: [EAI] Re: for8 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 9:27 PM -0800 1/25/07, Chris Newman wrote: > John C Klensin wrote on 1/22/07 20:07 -0500: >> (i) It might be better to just drop "for" clauses that contain >> non-ASCII material rather than figure out some creative way to >> encode them.... possibly replacing them with a comment whose >> semantics are closer to "non-ASCII for clause dropped on >> downgrading" than to an attempted encoding of the prior address. >> >> (ii) we might want to require the MTA that does the downgrading >> to insert a very specific trace header that explains the damage >> it did. Any comments that contain encodings of prior addresses >> should probably be on that trace header, not retrofitted into >> headers that did not contain information in that form. > > The robustness gained by never altering Received headers greatly > exceeds the value of the "for" clause (for is a convenience -- the > relevant MTA logs are the only place where the canonical data can > be found). To an MTA administrator, perhaps so. To end users, especially those debugging scripts, the "for" clause can be very helpful, since such people usually don't have access to the server logs. > However, regardless of what the specification says, we can't > usefully stop email originators from putting a UTF-8 address in the > "for" clause of Received. A robust MTA has to deal with that case > anyway. So I'd say three things about this issue: > > 1. SHOULD NOT generate for clause with UTF-8 address: forcing > systems to alter > received headers is bad Yes, it is bad. But it is also temporary: we're planning for a world where UTF8SMTP has seen wide deployment and downgrades are rare. In such a world, "for" clauses can continue to be very useful. > 2. MUST remove a Received for clause with a UTF-8 address on > downgrade: to avoid > breaking systems further down the line Yes, I agree. > 3. MUST NOT include an encoded version of the UTF-8 address in the > existing Received header but MAY include it in a Downgraded-details trace > field to minimize risk of damage to Received headers. Yes, I agree. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Eggheads unite! You have nothing to lose but your yolks. --Adlai Stevenson _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 02 08:40:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCyeJ-0004A1-L8; Fri, 02 Feb 2007 08:40:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCyeI-00048M-Nv for ima@ietf.org; Fri, 02 Feb 2007 08:40:18 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCyeE-0002KP-4S for ima@ietf.org; Fri, 02 Feb 2007 08:40:18 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l12DeC5r030592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Feb 2007 05:40:13 -0800 Received: from [[192.168.8.88]] (vpn-10-50-0-76.qualcomm.com [10.50.0.76]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l12De2tl009662; Fri, 2 Feb 2007 05:40:11 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <5direuh06o.fsf@Hurtta06k.keh.iki.fi> References: <458A154A.4090707@twnic.net.tw> <5dmz47bo2p.fsf_-_@leija.fmi.fi> <18502.8610438623$1169782253@news.gmane.org> <5direuh06o.fsf@Hurtta06k.keh.iki.fi> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 2 Feb 2007 00:47:30 -0800 To: Kari Hurtta , ima@ietf.org From: Randall Gellens Subject: Re: Header-Type, Mime-Version (Re: [EAI] Status of utf8header draft) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 6:38 AM +0200 1/26/07, Kari Hurtta wrote: > Precense of ALT-ADDRESS does not indicate that headers are UTF-8. > > So I disagreed with "isn't needed in that case" part with you. What do you gain from the additional extension? It seems to me that you only get the ability to specify that a client is using non-ASCII addresses but all-ASCII headers. Yet, the recipient server can't trust this, so what is the benefit? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Never write software that patronizes the user. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 02 08:40:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCyeR-0004IN-Pq; Fri, 02 Feb 2007 08:40:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCyeO-0004F7-MY for ima@ietf.org; Fri, 02 Feb 2007 08:40:25 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCyeL-0002LH-HJ for ima@ietf.org; Fri, 02 Feb 2007 08:40:24 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l12DeHmu026077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Feb 2007 05:40:17 -0800 Received: from [[192.168.8.88]] (vpn-10-50-0-76.qualcomm.com [10.50.0.76]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l12De2tp009662; Fri, 2 Feb 2007 05:40:15 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Fri, 2 Feb 2007 01:04:56 -0800 To: Harald Tveit Alvestrand , ima@ietf.org From: Randall Gellens Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 11:13 AM +0100 1/26/07, Harald Tveit Alvestrand wrote: > 1. I agree with this resolution I support this view, since from an SMTP server point of view the header is useless. However, I agree that practically speaking, there is a need for the POP or IMAP server to know if the message contains non-ASCII. But there must be other ways to do so, that would be more reliable. For example, the delivery agent could scan the message and add something to the already horrible to parse "From " separator. Or, the POP or IMAP server could do the scan itself. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Maybe Computer Science should be in the College of Theology. - -R. S. Barton _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 02 09:05:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCz35-0003DM-GP; Fri, 02 Feb 2007 09:05:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCz31-00039f-Ou for ima@ietf.org; Fri, 02 Feb 2007 09:05:51 -0500 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCz16-00077Y-21 for ima@ietf.org; Fri, 02 Feb 2007 09:03:53 -0500 Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@siilo.fmi.fi) by smtp1gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20061220) with ESMTP id l12E3j7T015206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Feb 2007 16:03:45 +0200 Received: from siilo.fmi.fi by torkku.fmi.fi with ESMTP id l12E3jQR029055 ; Fri, 2 Feb 2007 16:03:45 +0200 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id l12E3ipn009969 ; Fri, 2 Feb 2007 16:03:44 +0200 Received: by siilo.fmi.fi id l12E3hrG009966; Fri, 2 Feb 2007 16:03:43 +0200 Message-Id: <200702021403.l12E3hrG009966@siilo.fmi.fi> Subject: Re: Header-Type, Mime-Version (Re: [EAI] Status of utf8header draft) In-Reply-To: To: Randall Gellens Date: Fri, 2 Feb 2007 16:03:43 +0200 (EET) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123e (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp1gate: 3 received headers rewritten with id 20070202/33849/01 X-Filter: smtp1gate: ID 33848/01, 1 parts scanned for known viruses X-Filter: torkku: ID 7329/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp1gate: ID 33848/01) report=BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >>> Randall Gellens > At 6:38 AM +0200 1/26/07, Kari Hurtta wrote: > > > Precense of ALT-ADDRESS does not indicate that headers are UTF-8. > > > > So I disagreed with "isn't needed in that case" part with you. > > What do you gain from the additional extension? It seems to me that > you only get the ability to specify that a client is using non-ASCII > addresses but all-ASCII headers. Yet, the recipient server can't > trust this, so what is the benefit? [ If I remember correctly wo which thread that was refering. It may be that I remember context incorrectly. ] Also on opposite. Missing precense of ALT-ADDRESS do not specify that headers are all-ASCII. That means that ALT-ADDRESS ESMTP option does not function as indicator. If some option claims incorrect information, it is garbage in garbage out. "Can not trust" is not reason for scanning (for me at least.) Additional extension was giving same that Header-Type header field. Avoid scanning of headers and mime structure to decide when to do downgrade. But it turned out that scanning all MIME headers on whole mail makes sense after all. (For example sendmail sendmail already parses mime structure every time when using default configuration. So scanning all headers do not add complication. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 02 09:47:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzgv-0002uu-4z; Fri, 02 Feb 2007 09:47:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzgu-0002uo-HS for ima@ietf.org; Fri, 02 Feb 2007 09:47:04 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCzgo-0008GV-PB for ima@ietf.org; Fri, 02 Feb 2007 09:47:04 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3^clerew#man*ac*uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45c34ee0.d4dd.1f8 for ima@ietf.org; Fri, 2 Feb 2007 14:46:56 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l12Ekt23017828 for ; Fri, 2 Feb 2007 14:46:57 GMT Date: Fri, 02 Feb 2007 14:46:54 -0000 To: IMA Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt References: <5123077E6AE114B2367CD502@[10.1.110.5]> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <5123077E6AE114B2367CD502@[10.1.110.5]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 01 Feb 2007 23:14:39 -0000, Chris Newman wrote: > Charles Lindsey wrote on 2/1/07 21:23 +0000: >> Fortunately, treating all message subtypes as it they were >> message/rfc822 >> just happens to work with all the existing subtypes (and that might >> hopefully remain the case). > > Software which did that would not be following this advice (RFC 2046, > section 5.2.4): > > MIME implementations must in general treat unrecognized subtypes of > "message" > as being equivalent to "application/octet-stream". > > And would also incorrectly process message/external-body and > message/delivery-status among others. Not so. I am suggesting you treat any message/* as follows: If the C-T-E is Q-P or Base64, then you treat it as such, so effectively the same as octet string. No current message subtype actually allows that AFAIK. Otherwise (it is 7bit, 8bit or binary) you proceed as it the next thing (up to the first empty CRLF-only line) was a header. As indeed it is for message/rfc82 and message/partial. A message/rfc822 can, of course, contain multiparts within it, so the recursive tree walk must follow those as it did in the Perl script I wrote. The case of message/partial is more problematic. The headers within the message/partial cannot contain any 8bit stuff, because the C-T-E of a message/partial MUST be 7bit, so the downgrading would have nothing to do. But I can see problems if the message that was split into partial its was itself a multipart, because it is not safe to do a tree walk on that until the partial bits have been reassembled. Is that correct? It is clear that splitting a UTF8SMTP message into partial bits cannot be done at present, though we might make an extension to allow it. Message/external-body also starts with its own header, though RFC 2046 is exceedingly vague as to what it is allowed to contain, except that a Content-ID must be included. The examples show Content-Type headers, and a Content-Type: multipart/* here could be troublesome as for message/partial. But I see no reason why UTF8SMTP headers should not be present there, and be downgraded as normal. I see no particular problem with message/partial. Its C-T-E must be 7bit (unless we choose to extend that for use withn UTF8SMTP). So one does not expect any 8bit stuff within it, so there can be nothing to downgrade. The first thing within it is a set of "per-message" fields which are, syntacticvally, of the form of email header fields, and would therefore be parsed as such by the treewalk program. But none of those fields can take the forn of a Content-Type or Content-Transfer-Encoding, so there is nothing there to set the tree-walk off on further descents. If the whole thing is parsed the same way as a message/rfc822, tho "per-message" fields would look like the rfc822 headers, and the "per-recipient" fields would look like its body. All that would be absorbed and cause no action and no harm. If we wanted to extend message/delivery-status to permit 8bit stuff in any of those fields (as an alternative to inventing a new message subtype for the opurpose), then care would have to be taken to ensure that it was done in a way which permitted a downgrade. Most of the other IANA-registered message-subtypes I have looked at seem to follow a similar structure, and treating them the same as message/rfc822 would have a similar effect - namely nothing untoward would happen. So the troublesome cases would appear to be partial and external-body where we do NOT want to trigger exploration of further subtrees. OTOH, if we don't treat them as message/rfc822, then some newly-invented types might appear which DID require such exploration. So it is hard to see how any tree-walk can be made future-proof if there is no Header-Type header which could be used to guide it. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 02 13:16:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD2x8-0005Ap-Pk; Fri, 02 Feb 2007 13:16:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD2x7-0005Ab-7B for ima@ietf.org; Fri, 02 Feb 2007 13:16:01 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD2x1-0004Xe-GC for ima@ietf.org; Fri, 02 Feb 2007 13:16:01 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HD2wv-0003bu-KR for ima@ietf.org; Fri, 02 Feb 2007 19:15:49 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Feb 2007 19:15:49 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Feb 2007 19:15:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] [ascii@address] vs Date: 02 Feb 2007 20:15:42 +0200 Lines: 88 Message-ID: <5dwt3077e9.fsf@Hurtta06k.keh.iki.fi> References: <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> <407B9EC989C15E72DF80867C@p3.JCK.COM> <20070201024131.GK30318@ns5.lsb.org> <01DF86AB1FD3343508C0392D@JCK-ACR.jck.com> <20070201132203.GA19841@ns5.lsb.org> <5d1wl9n2vy.fsf_-_@Hurtta06k.keh.iki.fi> <20070202011604.GB19841@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Soobok Lee writes in gmane.ietf.ima: > On Thu, Feb 01, 2007 at 08:34:09PM +0200, Kari Hurtta wrote: > > Soobok Lee writes in gmane.ietf.ima: > > > > > I agree with you and have been so. > > > I don't support permitting "eai@address " here, > > > rather the opposite ! > > > > > > What I tried to point out with my examples is that > > > "eai@address " are silently permitted now, while > > > eai@address [ascii@address] will be rejected, by most > > > existing non-EAI-capable parsers. > > > > > > That explains why I favor [ascii@address] over . > > > > > > Permitting "eai@address [ascii@address]" in [utf8headers] > > > has no problem, but permitting "eai@address " > > > make conflicts. > > > > > > This will clear my position for [ascii@address]. > > > > > > If you and others have other opinions, please make new subjects and > > > thread about this. > > > > With [ ] there is own problems. I have stated them already. > > > > Your examples against [] around domain literals were > > From: > From: > From: > From: > > Domain literals are there mainly for specifying IP address. > So, "[something]" above should be replaced with [128.124.1.1] etc. But not according of grammar. Grammar says that inside of [ ] can be almost anything. On grammar [ ] acts as " " That is a problem. ------------------------------------------------------------------------- From: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-02 : alt-address again Newsgroups: gmane.ietf.ima Date: 02 Nov 2006 06:59:39 +0200 Frank Ellermann writes in gmane.ietf.ima: > Kari Hurtta wrote: > > > From: Käyttäjätuki > > From: Käyttäjätuki > > From: Käyttäjätuki > > From: Käyttäjätuki > > > How easy it is to parse ? This is un-ambiguous, but still quite > > dangerous. > > Easy, I don't see the danger here, can't be empty. > The [something] is always a . Yes. It is un-ambiguous. I was more considered how tokenizer can be used. Käyttäjätuki Maybe someone want tokekize as Käyttäjätuki WSP < Käyttäjätuki @ [something] [ support @ [something] ] > On there was problem [ versus [something] selection/conflict. That is easy if top-down parser is used, but not otherwise. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 02 13:57:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD3ae-0000wW-IZ; Fri, 02 Feb 2007 13:56:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD3ad-0000ve-WA for ima@ietf.org; Fri, 02 Feb 2007 13:56:52 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD3ac-0002Nx-Eo for ima@ietf.org; Fri, 02 Feb 2007 13:56:51 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HD3aK-0002j1-Sl for ima@ietf.org; Fri, 02 Feb 2007 19:56:35 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Feb 2007 19:56:32 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Feb 2007 19:56:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Downgrade strategy (Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker)) Date: 02 Feb 2007 20:56:22 +0200 Lines: 144 Message-ID: <5dsldo75ih.fsf_-_@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> <5dy7nl4ru5.fsf@Hurtta06k.keh.iki.fi> <5dmz401kzo.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > On Wed, 31 Jan 2007 23:14:25 -0000, Chris Newman > wrote: > > > Charles Lindsey wrote on 1/31/07 17:08 +0000: > >> BTW, I tried an experiment to see how much overhead this check > >> cost, and I > >> could not detect any difference,... > > > However, the plot thickens - and then it thins out again. I have spent > today doing more careful timing tests, and it turns out that sendmail > actually runs _faster_ when you do the walk of the whole mime tree > than when you don't! And that eventiually turned out to be becasue it > actually copies the file to the output as it is doing the walk, and > it just happens to use slightly faster (but I suspect buggier) code > that when it does its normal copying. > > Anyway, here is how I now see it as regards downgrading (or bouncing) > in the case of UTF8SMTP. > > 1. As you read the DATA, you check whether there is an 8th bit > anywhere in the message. If not, then you have neither 8BITMIME nor > UTF8SMTP problems, and everything else is simple. Note that this is > only done once; what follows has to be done separately for each > recipient of the message (though sensible cacheing of any downgraded > form will help). > > 2. Moreover if, for each recipient you look at, the next MTA in line > already supports UTF8SMTP (and hence 8BITMIME as well), you are still > on the simple case and no special measures are needed. > > 3. Otherwise. if the message turns out to need 8BITMIME or UTF8SMTP, > then downgrading is needed. If you try to discover this _beforehand_ > (by walking through the whole tree, assuming we do not have a > Header-Type to help us out), and then downgrade (or not) depending on > the result of that test, then you will have a severe performance hit > on account of doing the walk. So you don't do it that way. > > 4. Instead of that (and assuming you have already found an 8th bit > somewhere in step #1, and no UTF8SMTP capability in the next agent in > step #2), you start doing the full downgrade process, walking through > the complete MIME tree and looking for an 8th bit in headers (which > will need a UTF8SMTP downgrade) or an 8th bit in a body (which will > need an 8BITMIME downgrade unless the nect MTA does 8BITMIME). So, in > either case, you do each downgrade (or bouce/reject if you don't like > downgrading) as you come to it. > > 5. If, in fact, it turns out out that no downgrading was needed at any > stage, then no change will have been made to the message and no harm > will have been done, but you will have wasted a bit of time analysing > the MIME structure as you went throught it; but the imnportant thing > is that you never had to scan the whole message twice. That is just that stragegy, where sendmail runs problems when it detects that some body part can not 8BITMIME downgraded. Because output is not stored but instead directly written to socket, it can not cancel it (at least without just closing socket.) I suspect that UTF8SMTP downgrade will run to similar problems. ---------------------------------------------------------------------- From: Kari Hurtta Subject: Re: [EAI] Re: Sendmail message/TBD handling Newsgroups: gmane.ietf.ima Date: 14 Oct 2006 18:58:04 +0300 Frank Ellermann writes in gmane.ietf.ima: > Kari Hurtta wrote: > > > Sendmail will strip message/TBD to 7-bit if next host do not > > announce 8BITMIME. > > Odd, does it try that stunt with any 8bit content ? 1652 says > "it must cause no loss of information; MIME transport encodings > must be employed as needed to insure this is the case". Losing > one of eight bits is FUBAR. > > > I suggested that mail should be bounced, but it is not > > implemented. > > We can't freeze this WG until sendmail is upgraded to support > RFC 1652 published more than 12 years ago. Maybe all poor old > pre-1652 MTAs (are forced to) duck behind non-sendmail MXs. I just warn :-) > Are you really saying that sendmail announces 8BITMIME support, > and then forwards 8bit mails to non-8BITMIME hops by stripping > this bit ? Only for types where quoted-printable or base64 is not allowed and type can not handled recursively. That means message/* other that message/rfc822 ( 8bit is also stripped from multipart preamble, I think. But that 8bit on multipart preamble is more or less undefined area. ) quoted-printable or base64 are applied to leaf mime types, where these encodings are allowed. > [2821 2.4] An originating SMTP client which has not successfully > | negotiated an appropriate extension with a particular server > | MUST NOT transmit messages with information in the high-order > | bit of octets. > > That certainly doesn't mean "just strip the 8th bit on the side > of the client if the server doesn't offer 8BITMIME". > > Frank / Kari Hurtta KNOWNBUGS file from sendmail distribution: * 8->7 bit MIME conversion When sendmail is doing 8->7 bit MIME conversions, and the message contains certain MIME body types that cannot be converted to 7-bit, sendmail will strip the message to 7-bit. doc/op/op.me from sendmail distribution: $=s contains the set of subtypes of message that can be treated recursively. By default it contains only "rfc822". Other "message/*" types cannot be 8->7 bit encoded. If a message containing eight bit data is sent to a seven bit host, and that message cannot be encoded into seven bits, it will be stripped to 7 bits. So at least documentation say so. 8BITMIME downgrade happens on sendmail/mime.c but it is difficult to give meaningfull quote. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 02 15:55:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD5Qv-0007OM-VY; Fri, 02 Feb 2007 15:54:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD5Qu-0007LB-5O for ima@ietf.org; Fri, 02 Feb 2007 15:54:56 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD5Qs-00038h-MT for ima@ietf.org; Fri, 02 Feb 2007 15:54:56 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HD5Qr-0004LU-Fg for ima@ietf.org; Fri, 02 Feb 2007 21:54:53 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Feb 2007 21:54:53 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Feb 2007 21:54:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: When message is UTF8SMTP? (Re: [EAI] Re: Header-Format: Downgraded) Date: 02 Feb 2007 22:54:42 +0200 Lines: 65 Message-ID: <5dodoc7019.fsf_-_@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> <5dy7nl4ru5.fsf@Hurtta06k.keh.iki.fi> <5dmz401kzo.fsf@Hurtta06k.keh.iki.fi> <45C32E89.2C10@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Charles Lindsey wrote: > > > Obviously, much the same thing can be done by MDAs and MUAs. What worries > > me is still that people who write ad hoc scripts for processing mail are > > unlikely to go through all that properly, and that will lead to errors. So > > I would still prefer to see a Header-Type header, but it looks as though I > > am going to be outvoted on that one :-( > > I think you're confusing 8BITMIME and UTF8SMTP. For the latter you have > only to look at the header, check that it's either pure ASCII (including > 2047/2231 encodings resulting in pure ASCII), or valid UTF-8, or invalid. > > Especially the presence of some non-ASCII octets isn't the same as UTF-8, > you MUST NOT claim to have UTF8SMTP just because there's a non-ASCII byte. So question: When message is UTF8SMTP and therefore candinate of UTF8SMTP downgrading ? Possibilities 1) Some top level header fields with UTF8 sequences and otherwise ASCII only header fields 2) Some top level header fields with UTF8 sequences and some top level header fields with non-ASCII byte which don't form UTF-8 3) Some top level header fields with UTF8 sequences and some MIME header fields with UTF8 sequences 4) Top level header fields ASCII only and some MIME header fields with UTF8 sequences 5) Some top level header fields with UTF8 sequences and some MIME header fields with non-ASCII byte which don't form UTF-8 1') Some top level header fields with non-ASCII bytes and otherwise ASCII only header fields I think that there is no good answer to that question. So perhaps just downgrade these header fields with are UTF-8. Other header fields are garbage in, garbage out. Alternatively they can be downgraded as UNKNOWN-8BIt charset. That part "you MUST NOT claim to have UTF8SMTP just because there's a non-ASCII byte" will not be problem when there is Header-Format: -header field and no ESMTP option for that. So there is no claim that message is UTF8SMTP. It is true that there is message header fields which are not pure ASCII and not either UTF-8. Specially Subject: -header field with random non-ASCII charset (without 2047 encoding) are seen daily. Other header fields seen are: phrases on From:, To:, CC, Content-Description:, filename on Content-Disposition: -header field. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 02 18:38:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD7yd-0000ed-4d; Fri, 02 Feb 2007 18:37:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD7yc-0000e5-AZ for ima@ietf.org; Fri, 02 Feb 2007 18:37:54 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD7yX-0004HS-VZ for ima@ietf.org; Fri, 02 Feb 2007 18:37:54 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A3DA3259708 for ; Sat, 3 Feb 2007 00:33:47 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03658-03 for ; Sat, 3 Feb 2007 00:33:41 +0100 (CET) Received: from [172.19.11.21] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 60AF7259703 for ; Sat, 3 Feb 2007 00:33:41 +0100 (CET) Date: Fri, 02 Feb 2007 15:37:37 -0800 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: <7D73245C9F1297E78C91A927@[172.19.11.21]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: -0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [EAI] Preliminary copy of the post-Last Call EAI framework draft posted X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org A copy of the updated EAI framework draft, updated to address Last Call comments, is available at: http://www.alvestrand.no/ietf/eai/eai-framework-05b.txt If people have any comments on the way issues raised at Last Call were resolved, please raise them now - and preferably before 10 AM US ET Monday, February 5 (7AM US PT, 3PM GMT). Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 02 22:34:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDBf9-00082s-SL; Fri, 02 Feb 2007 22:34:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDBf8-00082c-BQ for ima@ietf.org; Fri, 02 Feb 2007 22:34:02 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDBf7-0000mi-1C for ima@ietf.org; Fri, 02 Feb 2007 22:34:02 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDBez-0003rx-1s for ima@ietf.org; Sat, 03 Feb 2007 04:33:53 +0100 Received: from 212.82.251.96 ([212.82.251.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 04:33:53 +0100 Received: from nobody by 212.82.251.96 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 04:33:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 03 Feb 2007 04:31:07 +0100 Organization: Lines: 18 Message-ID: <45C401FB.5A4E@xyzzy.claranet.de> References: <7D73245C9F1297E78C91A927@[172.19.11.21]> 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: 212.82.251.96 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [EAI] Re: Preliminary copy of the post-Last Call EAI framework draft posted X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: > http://www.alvestrand.no/ietf/eai/eai-framework-05b.txt Hwdiff at - I think it's okay. Does the following statement still make sense ? | There is no such thing as an "i18mail message"; the term | applies only to users and their agents and capabilities. I-D.eai-dsn-00 now defines message/utf-8, and minus "TBD" details it's a major step forward in a promising direction. The paragraph ending with "there is no such thing" also makes sense without this statement about a "i18mail message". Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 00:30:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDDTY-0001EF-PB; Sat, 03 Feb 2007 00:30:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDDTY-0001EA-7i for ima@ietf.org; Sat, 03 Feb 2007 00:30:12 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDDTT-0000F1-OC for ima@ietf.org; Sat, 03 Feb 2007 00:30:12 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HDDTT-000IbH-3n; Sat, 03 Feb 2007 00:30:07 -0500 Date: Sat, 03 Feb 2007 00:30:06 -0500 From: John C Klensin To: Harald Tveit Alvestrand , ima@ietf.org Subject: Re: [EAI] Preliminary copy of the post-Last Call EAI framework draft posted Message-ID: <634E99D63D4991FD37C0C467@p3.JCK.COM> In-Reply-To: <7D73245C9F1297E78C91A927@[172.19.11.21]> References: <7D73245C9F1297E78C91A927@[172.19.11.21]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 02 February, 2007 15:37 -0800 Harald Tveit Alvestrand wrote: > A copy of the updated EAI framework draft, updated to address > Last Call comments, is available at: > > http://www.alvestrand.no/ietf/eai/eai-framework-05b.txt > > If people have any comments on the way issues raised at Last > Call were resolved, please raise them now - and preferably > before 10 AM US ET Monday, February 5 (7AM US PT, 3PM GMT). Preferably before 8 AM US ET Monday. By 10 (and probably by 8:15), it will be in the posting queue. I've promised Ted Hardie, the relevant AD, that this would be posted Monday afternoon. For that to happen, it needs to be in-queue before they start processing the things Monday morning. Anything that might require discussion or thought should be posted enough in advance of that cutoff to make such discussion possible. Sorry about the constrained schedule on this, but it is necessary if the thing is going to be signed off before mid-March (or later). Also, please do not even bother to send notes that quibble about presentation. If I have made stupid typographical errors or the equivalent, please tell me. If I have missed, or seriously misinterpreted or mis-implemented, a Last Call comment, I certainly want to know about that. But, for anything along the lines of minor wording changes or reopening old issues -- especially involving text that was not changed after -04 -- it is just too late: the odds of my making errors in trying to apply proposed fixes are unacceptably high. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 02:06:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDEy2-0007dy-7p; Sat, 03 Feb 2007 02:05:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDEy1-0007dt-24 for ima@ietf.org; Sat, 03 Feb 2007 02:05:45 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HDExz-0006Yl-Dc for ima@ietf.org; Sat, 03 Feb 2007 02:05:44 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l1375TJ5008469; Sat, 3 Feb 2007 16:05:30 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l1375TKY008468; Sat, 3 Feb 2007 16:05:29 +0900 Date: Sat, 3 Feb 2007 16:05:29 +0900 From: Soobok Lee To: Kari Hurtta Subject: Re: [EAI] [ascii@address] vs Message-ID: <20070203070529.GC19841@ns5.lsb.org> References: <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> <407B9EC989C15E72DF80867C@p3.JCK.COM> <20070201024131.GK30318@ns5.lsb.org> <01DF86AB1FD3343508C0392D@JCK-ACR.jck.com> <20070201132203.GA19841@ns5.lsb.org> <5d1wl9n2vy.fsf_-_@Hurtta06k.keh.iki.fi> <20070202011604.GB19841@ns5.lsb.org> <5dwt3077e9.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5dwt3077e9.fsf@Hurtta06k.keh.iki.fi> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, Feb 02, 2007 at 08:15:42PM +0200, Kari Hurtta wrote: > > From: > > From: > > From: > > > > Domain literals are there mainly for specifying IP address. > > So, "[something]" above should be replaced with [128.124.1.1] etc. > > But not according of grammar. Grammar says that inside of [ ] can be > almost anything. On grammar [ ] acts as " " > > That is a problem. Are there any other domain-literal usages/definitions beside ipv4 and ipv6? Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 09:21:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDLlS-0000b4-3p; Sat, 03 Feb 2007 09:21:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDLlO-0000LG-Tm for ima@ietf.org; Sat, 03 Feb 2007 09:21:10 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDLlM-0006up-7k for ima@ietf.org; Sat, 03 Feb 2007 09:21:10 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDLkz-0006Xo-8u for ima@ietf.org; Sat, 03 Feb 2007 15:20:45 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 15:20:45 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 15:20:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt Date: 03 Feb 2007 16:20:32 +0200 Lines: 35 Message-ID: <5d3b5ngw5r.fsf@Hurtta06k.keh.iki.fi> References: <4696405D8A8A092D3147741B@[10.1.110.5]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Tony Finch writes in gmane.ietf.ima: > On Thu, 1 Feb 2007, Chris Newman wrote: > > > > Good idea. I'll add the following text to the end of section 5 in the next > > revision: > > > > All three new types will typically use the "8bit" Content-Transfer- > > Encoding (in the event all content is 7-bit, the equivalent > > traditional types for delivery status notifications are advised for > > greater backwards compatibility). While MIME [RFC2046] advises > > against the use of 8-bit in new message subtypes intended for the > > email infrastructure, that advice does not apply to these new types > > which are intended primarily for use by newer systems with full > > support for 8-bit MIME and UTF-8 headers. > > I like that. I'd suggest referring specifically to section 5.2.4 of RFC > 2046 and pointing out that the "equivalent to application/octet-stream" > clause implies that existing 8bitmime mailers should already be happy to > encode message/* if necessary. > > > The MIME specification directs MIME agents to treat unknown message/* > > subtypes as if they were application/octet-stream. That means complaint > > MIME agents will know to base64 encode or quoted-printable encode 8bit > > body parts automatically as needed. No. 8BITMIME downgraders do not base64 encode or quoted-printable encode unknown message/* subtypes. When these downgraders are written, base64 and quoted-printable was not allowed on message/* subtypes. They are expected to bounce these mails instead. ( And all of them do not bounce mail, but instead do nasty things. I have said that already. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 09:55:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDMIi-0004bB-PJ; Sat, 03 Feb 2007 09:55:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDMIi-0004ab-3H for ima@ietf.org; Sat, 03 Feb 2007 09:55:36 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDMIg-0005QU-LQ for ima@ietf.org; Sat, 03 Feb 2007 09:55:36 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDMIN-0004wc-Pw for ima@ietf.org; Sat, 03 Feb 2007 15:55:15 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 15:55:15 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 15:55:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: message/utf-8 downgrade issue (Comment (Re: [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt)) Date: 03 Feb 2007 16:54:50 +0200 Lines: 49 Message-ID: <5dmz3vthol.fsf@Hurtta06k.keh.iki.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chapter "5. UTF-8 Delivery Status Notifications" | descend message/utf-8 body parts. Second, if this type is sent to a | 7-bit-only system, it could be encoded in base64 or quoted-printable | [RFC2045]. As a result, SMTP servers and other systems which Should be: Second, if this type is sent to a system which do not supports 8BITMIME, it could be encoded in base64 or quoted-printable [RFC2045]. ( You must not assume that 8BITMIME downgraders like unknown message/* subtypes, which have 8-bit data. This is discussed elsewhere. ) Suggested addition was (by Chris Newman): All three new types will typically use the "8bit" Content-Transfer- Encoding (in the event all content is 7-bit, the equivalent traditional types for delivery status notifications are advised for greater backwards compatibility). While MIME [RFC2046] advises against the use of 8-bit in new message subtypes intended for the email infrastructure, that advice does not apply to these new types which are intended primarily for use by newer systems with full support for 8-bit MIME and UTF-8 headers. This do not address RFC 2045 nested encoding rule. Which need be also addressed when message/utf-8 is base64 or quoted-printable encoded: Certain Content-Transfer-Encoding values may only be used on certain media types. In particular, it is EXPRESSLY FORBIDDEN to use any encodings other than "7bit", "8bit", or "binary" with any composite media type, i.e. one that recursively includes other Content-Type fields. Currently the only composite media types are "multipart" and "message". All encodings that are desired for bodies of type multipart or message must be done at the innermost level, by encoding the actual body that needs to be encoded. Therefore that needs update RFC 2045 (and that may be difficult, when documents of that working group are Experimental and RFC 2045 is Standards track. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 09:56:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDMJZ-0004kw-B1; Sat, 03 Feb 2007 09:56:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDMJY-0004kJ-Ox for ima@ietf.org; Sat, 03 Feb 2007 09:56:28 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDMJW-0005Wy-Cf for ima@ietf.org; Sat, 03 Feb 2007 09:56:28 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDMJJ-0005AB-AN for ima@ietf.org; Sat, 03 Feb 2007 15:56:13 +0100 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 15:56:13 +0100 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 15:56:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] [ascii@address] vs Date: Sat, 03 Feb 2007 15:55:39 +0100 Organization: Lines: 10 Message-ID: <45C4A26B.3F56@xyzzy.claranet.de> References: <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> <407B9EC989C15E72DF80867C@p3.JCK.COM> <20070201024131.GK30318@ns5.lsb.org> <01DF86AB1FD3343508C0392D@JCK-ACR.jck.com> <20070201132203.GA19841@ns5.lsb.org> <5d1wl9n2vy.fsf_-_@Hurtta06k.keh.iki.fi> <20070202011604.GB19841@ns5.lsb.org> <5dwt3077e9.fsf@Hurtta06k.keh.iki.fi> <20070203070529.GC19841@ns5.lsb.org> 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: 212.82.251.1 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Soobok Lee wrote: > Are there any other domain-literal usages/definitions beside ipv4 and ipv6? IPvFuture in RFC 3986, General-address-literal in RFC 2821, and speculations about other literals in discussions about NetNews Message-IDs. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 10:04:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDMRY-0007z6-Vw; Sat, 03 Feb 2007 10:04:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDMRX-0007y7-W3 for ima@ietf.org; Sat, 03 Feb 2007 10:04:43 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDMRW-0006uk-ME for ima@ietf.org; Sat, 03 Feb 2007 10:04:43 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDMRD-0006gX-Ob for ima@ietf.org; Sat, 03 Feb 2007 16:04:24 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 16:04:23 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 16:04:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: message/utf-8 downgrade issue (Comment (Re: [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt)) Date: 03 Feb 2007 17:04:10 +0200 Lines: 26 Message-ID: <5dsldncmfp.fsf_-_@Hurtta06k.keh.iki.fi> References: <5dmz3vthol.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes in gmane.ietf.ima: > This do not address RFC 2045 nested encoding rule. Which need be also > addressed when message/utf-8 is base64 or quoted-printable encoded: > > Certain Content-Transfer-Encoding values may only be used on certain > media types. In particular, it is EXPRESSLY FORBIDDEN to use any > encodings other than "7bit", "8bit", or "binary" with any composite > media type, i.e. one that recursively includes other Content-Type > fields. Currently the only composite media types are "multipart" and > "message". All encodings that are desired for bodies of type > multipart or message must be done at the innermost level, by encoding > the actual body that needs to be encoded. > > > Therefore that needs update RFC 2045 (and that may be difficult, > when documents of that working group are Experimental and RFC 2045 > is Standards track. ) Specially when that tries update something which affect these, which do not participate experiment defined on these Experimental RFCes. Is that allowed? / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 10:26:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDMmZ-0007fd-FR; Sat, 03 Feb 2007 10:26:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDMmX-0007XW-N6 for ima@ietf.org; Sat, 03 Feb 2007 10:26:25 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDMmV-0002j2-9y for ima@ietf.org; Sat, 03 Feb 2007 10:26:25 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDMlw-0003Hl-T5 for ima@ietf.org; Sat, 03 Feb 2007 16:25:48 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 16:25:48 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 16:25:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: message/utf-8-headers (Re: [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt) Date: 03 Feb 2007 17:24:37 +0200 Lines: 40 Message-ID: <5dodobclhm.fsf@Hurtta06k.keh.iki.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org | The third type, used for header return, is message/utf-8-headers and | contains only the UTF-8 headers of a message (all lines prior to the | first blank line in a UTF8SMTP message). Unlike message/utf-8, this | body part provides no difficulties for present infrastructure. This is not completely true, because RFC 2045 forbids base64 and quoted-printable encoding here: | Certain Content-Transfer-Encoding values may only be used on certain | media types. In particular, it is EXPRESSLY FORBIDDEN to use any | encodings other than "7bit", "8bit", or "binary" with any composite | media type, i.e. one that recursively includes other Content-Type | fields. Currently the only composite media types are "multipart" and | "message". All encodings that are desired for bodies of type Therefore text/utf-8-headers works better than message/utf-8-headers. Also for text/utf-8-headers there helps following rule of RFC 2046: | 4.1.4. Unrecognized Subtypes | | Unrecognized subtypes of "text" should be treated as subtype "plain" | as long as the MIME implementation knows how to handle the charset. | Unrecognized subtypes which also specify an unrecognized charset | should be treated as "application/octet- stream". My draft-hurtta-eai-encapsulation-00 was using text/utf8-header on here. ( That is "header" versus "header field" on terminology. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 10:49:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDN8W-0004GH-Up; Sat, 03 Feb 2007 10:49:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDN8V-0004GB-NH for ima@ietf.org; Sat, 03 Feb 2007 10:49:07 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDN8F-00067i-LE for ima@ietf.org; Sat, 03 Feb 2007 10:49:07 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDN5d-0001Lx-7Q for ima@ietf.org; Sat, 03 Feb 2007 16:46:10 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 16:46:09 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 16:46:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Registeration forms (Re: [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt) Date: 03 Feb 2007 17:41:59 +0200 Lines: 16 Message-ID: <5dk5yzckoo.fsf@Hurtta06k.keh.iki.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Encoding considerations: and Restrictions on usage: parts on these registrations forms do not fly. See RFC 2045 restrtrion of encodings for multipart and message types. ( I quoted it already twice. ) If this updates RFC 2045, it need to be noted on here I think. It may be that these types are OK only on UTF8SMTP environment. On that case RFC 2045 need not be updated. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 11:19:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDNcJ-0002WJ-51; Sat, 03 Feb 2007 11:19:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDNcH-0002WE-WA for ima@ietf.org; Sat, 03 Feb 2007 11:19:53 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDNcG-0003Mv-C0 for ima@ietf.org; Sat, 03 Feb 2007 11:19:53 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDNbv-0001rM-Q9 for ima@ietf.org; Sat, 03 Feb 2007 17:19:31 +0100 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 17:19:31 +0100 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 17:19:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 03 Feb 2007 17:08:46 +0100 Organization: Lines: 59 Message-ID: <45C4B38E.5C77@xyzzy.claranet.de> References: <5dmz3vthol.fsf@Hurtta06k.keh.iki.fi> 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: 212.82.251.1 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [EAI] Re: message/utf-8 downgrade issue (Comment) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > Chapter "5. UTF-8 Delivery Status Notifications" > | descend message/utf-8 body parts. Second, if this type is sent to a > | 7-bit-only system, it could be encoded in base64 or quoted-printable > | [RFC2045]. As a result, SMTP servers and other systems which > Should be: > Second, if this type is sent to a > system which do not supports 8BITMIME, it could be encoded in base64 > or quoted-printable [RFC2045]. [...] > This do not address RFC 2045 nested encoding rule. Which need be also > addressed when message/utf-8 is base64 or quoted-printable encoded [...] > Therefore that needs update RFC 2045 That's IMO impossible in Mime-Version: 1.0. A message has a header and a body, its header defines the Content-Type details of its body. But the message (header) itself has no Content-Type and no CTE, it can be 7bit or 8bit. If it's some kind of binary different from 8bit it's anyway invalid (for our purposes). By definition a message/rfc822 (header) is 7bit US-ASCII. In the wild it sometimes degenerates into unknown 8bit "extended ASCII". A message/utf-8 (header) is by definition 8bit UTF-8. In rare cases, explicitly noted as NOT RECOMMENDED somewhere, it can degenerate into 7bit US-ASCII if there happens to be no code point above U+007F in the header. We can put a message/utf-8 as is into the various multipart Content-Types, including multipart/report DSNs, as long as it's transmitted on 8BITMIME routes. We can also put it as is in the body of a message/rfc822 or other message types, using Content-Type: message/utf-8 + Content-Transfer-Encoding: 8bit. It's not possible to send a message/utf-8 (header) to a 7bit system, it's also impossible to send it via a 7bit relay to a 8bit system. We could invent some crude appplication/utf-8-message, but in essence that would be a variation of "ZIP it and send it as B64 application/zip" (or similar), an application/utf-8-message type is pointless (*1) The next thing we could try is to downgrade the message/utf-8 (header) to message/rfc822. After that its body might be still 8bit, among others it could contain text/plain Latin-1, text/html UTF-8, or nested message/utf-8 parts. But from our POV it's an ordinary message/rfc822 with 8bit body if the downgrade worked, and ordinary 8BITMIME to 7bit gateways can deal with that. Or is the problem that these gateways choke on a *nested* message/utf-8 ? They shouldn't, they're supposed to treat it as application/octect-stream. Frank 1: application/utf-8-message could be interesting for a transport via non-UTF8SMTP, if receivers know to "unpack" it into a message/utf-8. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 11:59:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDOEJ-0003UZ-MR; Sat, 03 Feb 2007 11:59:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDOEI-0003UU-SR for ima@ietf.org; Sat, 03 Feb 2007 11:59:10 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDOEH-0001u2-J6 for ima@ietf.org; Sat, 03 Feb 2007 11:59:10 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDOEE-0001tZ-S4 for ima@ietf.org; Sat, 03 Feb 2007 17:59:06 +0100 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 17:59:06 +0100 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 17:59:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 03 Feb 2007 17:58:24 +0100 Organization: Lines: 20 Message-ID: <45C4BF30.5CC9@xyzzy.claranet.de> References: <5dk5yzckoo.fsf@Hurtta06k.keh.iki.fi> 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: 212.82.251.1 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [EAI] Re: Registeration forms X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > parts on these registrations forms do not fly. Yes, it's impossible to send a "real" message/utf-8 via 7bit routes, it has to be "downgraded" and after that fed into some 8bit to 7bit gateway. > See RFC 2045 restrtrion of encodings for multipart and message > types. ( I quoted it already twice. ) What do existing 8to7 gateways with nested and unknown 8bit message subtypes ? We discussed that already, but I forgot the details - at that time we were still far into the woods with a Header-Type: UTF-8 trying to twist a message/rfc822 into something it isn't and can't be. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 12:29:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDOhP-0002AY-Ee; Sat, 03 Feb 2007 12:29:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDOhO-0002AS-B9 for ima@ietf.org; Sat, 03 Feb 2007 12:29:14 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDOhM-0006HB-T4 for ima@ietf.org; Sat, 03 Feb 2007 12:29:14 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HDOhJ-000ODd-GU; Sat, 03 Feb 2007 12:29:09 -0500 Date: Sat, 03 Feb 2007 12:29:08 -0500 From: John C Klensin To: Soobok Lee , Kari Hurtta Subject: Re: [EAI] [ascii@address] vs Message-ID: In-Reply-To: <20070203070529.GC19841@ns5.lsb.org> References: <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> <407B9EC989C15E72DF80867C@p3.JCK.COM> <20070201024131.GK30318@ns5.lsb.org> <01DF86AB1FD3343508C0392D@JCK-ACR.jck.com> <20070201132203.GA19841@ns5.lsb.org> <5d1wl9n2vy.fsf_-_@Hurtta06k.keh.iki.fi> <20070202011604.GB19841@ns5.lsb.org> <5dwt3077e9.fsf@Hurtta06k.keh.iki.fi> <20070203070529.GC19841@ns5.lsb.org> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Saturday, 03 February, 2007 16:05 +0900 Soobok Lee wrote: >> > Domain literals are there mainly for specifying IP address. >> > So, "[something]" above should be replaced with >> > [128.124.1.1] etc. >> >> But not according of grammar. Grammar says that inside of [ ] >> can be almost anything. On grammar [ ] acts as " " >> >> That is a problem. > > Are there any other domain-literal usages/definitions beside > ipv4 and ipv6? No. But, when 2821 was written, an explicit decision was made to provide for other cases in the event that they came along. That was precisely why the syntax rule was either [ ] was an IPv4 address (with some possibilities for syntax errors) and [keyword: ...] was some other sort of address literal. There were proposals to handle IPv6 is some other way, such as requiring that the parser recognize ":" rather than "." in the string, but the conclusion was that we should allow for explicit labeling rather than either "no plan if something succeeded IPv6" or heuristics on the contents of the string. If one encountered local-part@[some-string] and the first character of that string was not a digit, a correct interpretation of 2821 almost certainly requires that one parse the string looking for an address literal type keyword. If it can't be found, or isn't "IPv6:" (or something else considered valid at the time), then it is an error. But, while my personal preference would be to just accept > and get on with it --not because I especially like it but because it appears to be the rough consensus and "get on with it" is becoming important -- I don't see what this has to with the discussion. In 2821 and I think 2822, address literals are permitted only where a domain can appear, and domains can appear only after "@". So local-path@[address-literal] and <@[address-literal]:local-part@domain> are well-defined instance of address literals. But in all of local-part@domain [string] and [string] and "[string]" cannot, contextually, be an address literal. Barring extensions, it is a plain, ordinary, syntax error. The only issue it raises with address literals is that I assume that some MUAs would report the error as "address literal out of context" or "bad address-- no local part" rather than "where did that '[' came from". And that might be very confusion to users if was encountered in a non-upgraded but excessively syntax-permissive implementation (one that didn't notice the UTF-8 characters in the real local part until it had reported syntax errors). john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 13:28:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDPcR-00022m-PR; Sat, 03 Feb 2007 13:28:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDPcQ-00022g-IO for ima@ietf.org; Sat, 03 Feb 2007 13:28:10 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDPcP-0006e8-8s for ima@ietf.org; Sat, 03 Feb 2007 13:28:10 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDPcB-0003NA-5x for ima@ietf.org; Sat, 03 Feb 2007 19:27:55 +0100 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 19:27:55 +0100 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 19:27:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 03 Feb 2007 19:26:38 +0100 Organization: Lines: 30 Message-ID: <45C4D3DE.5E4B@xyzzy.claranet.de> 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: 212.82.251.1 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [EAI] Downgrade question X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hi, IMO the following table describes all "downgrade" scenarios for a message arriving via UTF8SMTP. If the header is not UTF-8, then "downgrade" is a NOOP, resulting in a valid or invalid message/rfc822 with a 7bit or 8bit body. If the header is UTF-8 a successful "downgrade" transforms it into a valid message/rfc822 with a 7bit or 8bit body. The assumption is that the conversion of any 8bit message/rfc822 to a 7bit message/rfc822 is a solved problem for all 8BITMIME MTAs trying to talk with 7bit MTAs. An 8bit message/rfc822 can contain nested message parts with arbitrary subtypes, that's already the case today before the introduction of message/utf-8 (and family). Therefore I think he complete problem of getting 8bit to 7bit right is simply not the job of EAI, we're not doing "2045bis" or "MIME version: 2.0" (unless we must if anything else fails). Is that correct, or am I missing something very critical ? Frank Table: Downgrade results for a (wannabe) message/utf-8 Message header | 8bit message body | 7bit message body | Comment ---------------+---------------------+---------------------+-------- UNKNOWN-8BIT | (actually invalid) | (actually invalid) | NOOP US-ASCII | message/rfc822 8bit | message/rfc822 7bit | NOOP UTF-8 | message/rfc822 8bit | message/rfc822 7bit | _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 13:30:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDPep-00043O-56; Sat, 03 Feb 2007 13:30:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDPen-00041Y-1c for ima@ietf.org; Sat, 03 Feb 2007 13:30:37 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDPeh-0006vT-Hr for ima@ietf.org; Sat, 03 Feb 2007 13:30:37 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDPeJ-0003of-0o for ima@ietf.org; Sat, 03 Feb 2007 19:30:07 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 19:30:07 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 19:30:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: 8to7 downgrade and message/* (Re: [EAI] Re: Registeration forms) Date: 03 Feb 2007 20:29:48 +0200 Lines: 148 Message-ID: <5d4pq3gkmb.fsf_-_@Hurtta06k.keh.iki.fi> References: <5dk5yzckoo.fsf@Hurtta06k.keh.iki.fi> <45C4BF30.5CC9@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes gmane.ietf.ima: > Kari Hurtta wrote: > > > parts on these registrations forms do not fly. > > Yes, it's impossible to send a "real" message/utf-8 via 7bit routes, > it has to be "downgraded" and after that fed into some 8bit to 7bit > gateway. > > > See RFC 2045 restrtrion of encodings for multipart and message > > types. ( I quoted it already twice. ) > > What do existing 8to7 gateways with nested and unknown 8bit message > subtypes ? > > We discussed that already, but I forgot the details - at that time > we were still far into the woods with a Header-Type: UTF-8 trying to > twist a message/rfc822 into something it isn't and can't be. Sendmail strips message/* (other than message/rfc822) to 7-bit. I do not know about others. Except that some MTAs announce 8BITMIME and always sends 8-bit even when next host do not announce 8BITMIME. Effectively gateways are required bounce unknown message/* types if they include 8-bit. Some probably encode these parts with quoted-printable or base64. ---------------------------------------------------------------------- From: Kari Hurtta Subject: Sendmail message/TBD handling (Re: [EAI] text for eai-framework re: 2047+S/MIME) Newsgroups: gmane.ietf.ima Date: 14 Oct 2006 11:10:27 +0300 Frank Ellermann writes in gmane.ietf.ima: > hurtta+gmane@siilo.fmi.fi wrote: > > > IMHO it will _not_ work as I stated earlier -- for > > encapsulation is needed something like application/utf8smtp > > A message/TBD 8bit won't work with a 7bit-MTA at the next hop, > but it's okay for an 8BITMIME-MTA. For 8bit to 7bit RFC 1652 > apparently says that this is left as an exercise for gateway > operators. Yes, but in practise there is problems. Sendmail will strip message/TBD to 7-bit if next host do not announce 8BITMIME. ( I have already mentioned that. ) That hapens with sendmail 8.7 (1995/09/16) or any newer version. (Yes. I'm perhaps somewhat quilty about that. (*) ) / Kari Hurtta (*) Well, I suggested that mail should be bounced, but it is not implemented. However, I may have some difficultions to found my over 10 year old mail archives... So on some details my memory may fail. -------------------------------------------------------------------- From: Kari Hurtta Subject: Re: [EAI] Re: Sendmail message/TBD handling Newsgroups: gmane.ietf.ima Date: 14 Oct 2006 18:58:04 +0300 Frank Ellermann writes in gmane.ietf.ima: > Kari Hurtta wrote: > > > Sendmail will strip message/TBD to 7-bit if next host do not > > announce 8BITMIME. > > Odd, does it try that stunt with any 8bit content ? 1652 says > "it must cause no loss of information; MIME transport encodings > must be employed as needed to insure this is the case". Losing > one of eight bits is FUBAR. > > > I suggested that mail should be bounced, but it is not > > implemented. > > We can't freeze this WG until sendmail is upgraded to support > RFC 1652 published more than 12 years ago. Maybe all poor old > pre-1652 MTAs (are forced to) duck behind non-sendmail MXs. I just warn :-) > Are you really saying that sendmail announces 8BITMIME support, > and then forwards 8bit mails to non-8BITMIME hops by stripping > this bit ? Only for types where quoted-printable or base64 is not allowed and type can not handled recursively. That means message/* other that message/rfc822 ( 8bit is also stripped from multipart preamble, I think. But that 8bit on multipart preamble is more or less undefined area. ) quoted-printable or base64 are applied to leaf mime types, where these encodings are allowed. > [2821 2.4] An originating SMTP client which has not successfully > | negotiated an appropriate extension with a particular server > | MUST NOT transmit messages with information in the high-order > | bit of octets. > > That certainly doesn't mean "just strip the 8th bit on the side > of the client if the server doesn't offer 8BITMIME". > > Frank / Kari Hurtta KNOWNBUGS file from sendmail distribution: * 8->7 bit MIME conversion When sendmail is doing 8->7 bit MIME conversions, and the message contains certain MIME body types that cannot be converted to 7-bit, sendmail will strip the message to 7-bit. doc/op/op.me from sendmail distribution: $=s contains the set of subtypes of message that can be treated recursively. By default it contains only "rfc822". Other "message/*" types cannot be 8->7 bit encoded. If a message containing eight bit data is sent to a seven bit host, and that message cannot be encoded into seven bits, it will be stripped to 7 bits. So at least documentation say so. 8BITMIME downgrade happens on sendmail/mime.c but it is difficult to give meaningfull quote. --------------------------------------------------------------------------- _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 13:58:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDQ5U-0004dv-78; Sat, 03 Feb 2007 13:58:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDQ5T-0004dq-8s for ima@ietf.org; Sat, 03 Feb 2007 13:58:11 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDQ5R-0002fO-Qa for ima@ietf.org; Sat, 03 Feb 2007 13:58:11 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDQ58-0001Ow-ON for ima@ietf.org; Sat, 03 Feb 2007 19:57:50 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 19:57:50 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 19:57:50 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Downgrade question Date: 03 Feb 2007 20:57:44 +0200 Lines: 64 Message-ID: <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> References: <45C4D3DE.5E4B@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Hi, IMO the following table describes all "downgrade" scenarios for > a message arriving via UTF8SMTP. > > If the header is not UTF-8, then "downgrade" is a NOOP, resulting > in a valid or invalid message/rfc822 with a 7bit or 8bit body. If > the header is UTF-8 a successful "downgrade" transforms it into a > valid message/rfc822 with a 7bit or 8bit body. > > The assumption is that the conversion of any 8bit message/rfc822 > to a 7bit message/rfc822 is a solved problem for all 8BITMIME MTAs > trying to talk with 7bit MTAs. An 8bit message/rfc822 can contain > nested message parts with arbitrary subtypes, that's already the > case today before the introduction of message/utf-8 (and family). > > Therefore I think he complete problem of getting 8bit to 7bit > right is simply not the job of EAI, we're not doing "2045bis" or > "MIME version: 2.0" (unless we must if anything else fails). > > Is that correct, or am I missing something very critical ? > > Frank > > Table: Downgrade results for a (wannabe) message/utf-8 > > Message header | 8bit message body | 7bit message body | Comment > ---------------+---------------------+---------------------+-------- > UNKNOWN-8BIT | (actually invalid) | (actually invalid) | NOOP > US-ASCII | message/rfc822 8bit | message/rfc822 7bit | NOOP > UTF-8 | message/rfc822 8bit | message/rfc822 7bit | Is 'header' there in RFC 2822 sense? Then there is also case where whom header fields are UTF-8 and some UNKNOWN-8BIT. That makes mixed | | | UNKNOWN-8BIT | (actually invalid) | (actually invalid) | UTF-8 | message/rfc822 8bit | message/rfc822 7bit | That also occurs when top level header of mail is UTF-8 and header of nested message/rfc822 uses UNKNOWN-8BIT. UTF-8 with | (actually invalid) | (not exists) | nested | message/rfc822 8bit | | UNKNOWN-8BIT | | | If on nested datatypes have 8-bit header fields, it actually makes top level 8bit (as content-transfer-encoding) On some cases there is possible UTF-8 | message/rfc822 7bit | | that is when on original 8bit body is just because UTF-8 header fields on mime structure. Downgrade changes them 7bit. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 14:14:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDQLN-0005Q1-3k; Sat, 03 Feb 2007 14:14:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDQLM-0005Pl-0B for ima@ietf.org; Sat, 03 Feb 2007 14:14:36 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDQLH-0005gd-Mz for ima@ietf.org; Sat, 03 Feb 2007 14:14:35 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDQKp-0004g9-8D for ima@ietf.org; Sat, 03 Feb 2007 20:14:03 +0100 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 20:14:03 +0100 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 20:14:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 03 Feb 2007 20:05:54 +0100 Organization: Lines: 40 Message-ID: <45C4DD12.5B7A@xyzzy.claranet.de> References: <5dk5yzckoo.fsf@Hurtta06k.keh.iki.fi> <45C4BF30.5CC9@xyzzy.claranet.de> <5d4pq3gkmb.fsf_-_@Hurtta06k.keh.iki.fi> 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: 212.82.251.1 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [EAI] Re: 8to7 downgrade and message/* X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > Sendmail strips message/* (other than message/rfc822) to 7-bit. Let's say that's a bug and move on, these sendmail versions won't claim to support UTF8SMTP. > some MTAs announce 8BITMIME and always sends 8-bit even when > next host do not announce 8BITMIME. Another bug, explicitly forbidden in RFC 1652. Not our problem. We should mention that this never worked, it also won't work for message/utf-8, and implementors had already 13 years to figure this out. > Effectively gateways are required bounce unknown message/* types > if they include 8-bit. Okay, so we should offer a better solution for message/utf-8 and family for the purpose of 8BITMIME to 7bit gateways - nobody else needs this. While we're at it let's support any message subtype, including invalid message/rfc822 headers with UNKNOWN-8BIT octets. How about an application/message-munged with a mandatory parameter indicating the original message subtype ? Where "munged" could be defined as a very radical procedure: Take the complete unknown message part (or a complete invalid message/rfc822 part), gzip it, B64 it, ready. Maybe gzip is overkill. > Some probably encode these parts with quoted-printable or base64. My first idea was QP, but it might be too easy to get this wrong or to misinterpret its (wannabe) user friendly output, if the consumer is a stupid script, not a human user or "unmunge" agent. Thanks for the copies of our thread in October. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 14:40:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDQkO-0005oA-89; Sat, 03 Feb 2007 14:40:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDQkM-0005mG-I2 for ima@ietf.org; Sat, 03 Feb 2007 14:40:26 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDQkL-000154-3w for ima@ietf.org; Sat, 03 Feb 2007 14:40:26 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDQjv-0001iE-Av for ima@ietf.org; Sat, 03 Feb 2007 20:39:59 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 20:39:59 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 20:39:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: sendmail 8.13.5 tested (Re: 8to7 downgrade and message/* (Re: [EAI] Re: Registeration forms)) Date: 03 Feb 2007 21:39:52 +0200 Lines: 96 Message-ID: <5dr6t7f2t3.fsf_-_@Hurtta06k.keh.iki.fi> References: <5dk5yzckoo.fsf@Hurtta06k.keh.iki.fi> <45C4BF30.5CC9@xyzzy.claranet.de> <5d4pq3gkmb.fsf_-_@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes in gmane.ietf.ima: > Frank Ellermann writes gmane.ietf.ima: > > > Kari Hurtta wrote: > > > > > parts on these registrations forms do not fly. > > > > Yes, it's impossible to send a "real" message/utf-8 via 7bit routes, > > it has to be "downgraded" and after that fed into some 8bit to 7bit > > gateway. > > > > > See RFC 2045 restrtrion of encodings for multipart and message > > > types. ( I quoted it already twice. ) > > > > What do existing 8to7 gateways with nested and unknown 8bit message > > subtypes ? > > > > We discussed that already, but I forgot the details - at that time > > we were still far into the woods with a Header-Type: UTF-8 trying to > > twist a message/rfc822 into something it isn't and can't be. > > Sendmail strips message/* (other than message/rfc822) to 7-bit. > I do not know about others. Except that some MTAs announce 8BITMIME > and always sends 8-bit even when next host do not announce 8BITMIME. Seems that actually sendmail 8.13.5 code just send 8-bit as is (instead of downgrading). ------------------------ MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=AA --AA Content-Type: text/plain Tässä 8-bit body --AA Content-Type: message/utf-8 Subject: Tässä 8-bit header Tässä 8-bit body --AA-- ------------------------- results after 8BITMIME downgrade: ------------------------- .... Date: Sat, 3 Feb 2007 21:32:24 +0200 From: Kari Hurtta Message-ID: <200702031932.l13JWO0P005559@CENSORED> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=AA To: undisclosed-recipients:; --AA Content-Type: text/plain Content-Transfer-Encoding: base64 X-MIME-Autoconverted: from 8bit to base64 by CENSORED id l13JWa5K005560 VMOkc3PDpCA4LWJpdCBib2R5DQo= --AA Content-Type: message/utf-8 Subject: Tässä 8-bit header Tässä 8-bit body --AA-- ------------------------- It it does not strip unknown message/* to 7bit as KNOWNBUGS claim. They are actually passed as it. On code there is if (sm_strcasecmp(type, "message") == 0) { if (!wordinclass(subtype, 's')) { flags |= M87F_NO8BIT; } else But M87F_NO8BIT have not actually that effect. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 14:45:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDQp7-0001nh-F9; Sat, 03 Feb 2007 14:45:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDQp6-0001nZ-AT for ima@ietf.org; Sat, 03 Feb 2007 14:45:20 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDQp4-0001eR-Su for ima@ietf.org; Sat, 03 Feb 2007 14:45:20 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDQod-0002xD-9I for ima@ietf.org; Sat, 03 Feb 2007 20:44:56 +0100 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 20:44:51 +0100 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 20:44:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 03 Feb 2007 20:42:08 +0100 Organization: Lines: 55 Message-ID: <45C4E590.59A9@xyzzy.claranet.de> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> 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: 212.82.251.1 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [EAI] Re: Downgrade question X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: >> Table: Downgrade results for a (wannabe) message/utf-8 >> Message header | 8bit message body | 7bit message body | Comment >> ---------------+---------------------+---------------------+-------- >> UNKNOWN-8BIT | (actually invalid) | (actually invalid) | NOOP >> US-ASCII | message/rfc822 8bit | message/rfc822 7bit | NOOP >> UTF-8 | message/rfc822 8bit | message/rfc822 7bit | > Is 'header' there in RFC 2822 sense? Actually in a message/utf-8 sense, extending some 2822 constructs to allow UTF-8. Some years ago Charles already did this for news, there's some "prior art" in the USEFOR archive... :-) > Then there is also case where whom header fields are UTF-8 and some > UNKNOWN-8BIT. IMO anything that's neither valid UTF-8 nor pure ASCII is just wrong, an invalid message/rfc822. > That also occurs when top level header of mail is UTF-8 > and header of nested message/rfc822 uses UNKNOWN-8BIT. My table is only for the top level message as transmitted by UTF8SMTP. Nested mesage parts belong to the body, we can ignore them for the purpose of "downgrade UTF8SMTP to 8BITMIME". Body problems are not our problems. If we'd offer application/message-munged it's a voluntary solution of a RFC 1652 exercise, not really a part of EAI. Only then do we ever need to look into the body, deep in 1652 / MIME territory. > If on nested datatypes have 8-bit header fields, it actually > makes top level 8bit (as content-transfer-encoding) Yes, but that's again an 8BITMIME issue, not an EAI issue. Nothing is wrong with an 8bit message/rfc822 (top level) containing anything it likes in its body. > On some cases there is possible > UTF-8 | message/rfc822 7bit | | > that is when on original 8bit body is just because UTF-8 header > fields on mime structure. Downgrade changes them 7bit. A 7bit message/utf-8 is perfectly okay. It's an UTF-8 header with any 7bit content type (including QP and B64). It's in the lower right cell of my table (UTF-8 row, 7bit column). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 14:56:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDQzb-0000HS-Pj; Sat, 03 Feb 2007 14:56:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDQzb-0000HE-5m for ima@ietf.org; Sat, 03 Feb 2007 14:56:11 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDQzZ-00034c-Sp for ima@ietf.org; Sat, 03 Feb 2007 14:56:11 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDQzM-0005tY-99 for ima@ietf.org; Sat, 03 Feb 2007 20:55:58 +0100 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 20:55:56 +0100 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 20:55:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Date: Sat, 03 Feb 2007 20:55:06 +0100 Organization: Lines: 18 Message-ID: <45C4E89A.6206@xyzzy.claranet.de> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <45B9F7D7.6B46@xyzzy.claranet.de> 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: 212.82.251.1 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > Harald Tveit Alvestrand wrote: >> 3. I have another opinion, which is: > I can't judge it at the moment. [...] > I'd feel far more confident that the WG is on the right track if we > nail the message/rfc822 vs. message/utf8smtp (or similar) question. Strike that, I hadn't seen the message/utf-8 draft when I posted that. Removing the "header-format" header field should now work, "top level" messages can be identified (and if necessary downgraded) by looking at their header, and a "nested" message/utf-8 is already tagged with an explicit Content-type in its container. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 15:19:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDRMR-00040Y-Lj; Sat, 03 Feb 2007 15:19:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDRMQ-0003wK-2n for ima@ietf.org; Sat, 03 Feb 2007 15:19:46 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDRMO-0006JU-PX for ima@ietf.org; Sat, 03 Feb 2007 15:19:46 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDRMI-0003Lj-SO for ima@ietf.org; Sat, 03 Feb 2007 21:19:38 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 21:19:38 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 21:19:38 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: BODY problems are our problems (Re: [EAI] Re: Downgrade question) Date: 03 Feb 2007 22:19:18 +0200 Lines: 36 Message-ID: <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Nested mesage parts belong to the body, we can ignore them for the > purpose of "downgrade UTF8SMTP to 8BITMIME". Body problems are not > our problems. I disagree strongly! MIME header fields on nested mime structure IS our problem. Top level header fields can be all US-ASCII only, but we have draft-ietf-eai-utf8headers-02.txt: ----------------------------------------------------------------------- 7.2. MIME headers The syntax of s containing UTF-8 characters (see the revised syntax of in Section 6.2 of this document). ------------------------------------------------------------------------- Therefore body problems are our problems when they are on MIME headers! That means also that you must parse whole MIME structure, before you know is message UTF8SMTP. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 15:25:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDRRb-0002pL-Uj; Sat, 03 Feb 2007 15:25:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDRRa-0002pF-Po for ima@ietf.org; Sat, 03 Feb 2007 15:25:06 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDRRZ-0006wz-G6 for ima@ietf.org; Sat, 03 Feb 2007 15:25:06 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HDRRW-0004NE-FI for ima@ietf.org; Sat, 03 Feb 2007 21:25:02 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 21:25:02 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 21:25:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Date: 03 Feb 2007 22:21:42 +0200 Lines: 25 Message-ID: <5direjf0vd.fsf@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <45B9F7D7.6B46@xyzzy.claranet.de> <45C4E89A.6206@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > > Harald Tveit Alvestrand wrote: > > >> 3. I have another opinion, which is: > > > I can't judge it at the moment. > [...] > > I'd feel far more confident that the WG is on the right track if we > > nail the message/rfc822 vs. message/utf8smtp (or similar) question. > > Strike that, I hadn't seen the message/utf-8 draft when I posted that. > > Removing the "header-format" header field should now work, "top level" > messages can be identified (and if necessary downgraded) by looking > at their header, and a "nested" message/utf-8 is already tagged with > an explicit Content-type in its container. You still not take account Content-Type and Content-Disposition header fields on MIME structure which are allowed include utf-8 on UTF8SMTP message. > Frank / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 15:44:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDRkS-0001kz-EF; Sat, 03 Feb 2007 15:44:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDRkR-0001i8-1j for ima@ietf.org; Sat, 03 Feb 2007 15:44:35 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDRkP-0001AK-OB for ima@ietf.org; Sat, 03 Feb 2007 15:44:35 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDRk4-0007sF-B3 for ima@ietf.org; Sat, 03 Feb 2007 21:44:12 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 21:44:12 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 21:44:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Date: 03 Feb 2007 22:43:58 +0200 Lines: 30 Message-ID: <5dr6t755v5.fsf@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <45B9F7D7.6B46@xyzzy.claranet.de> <45C4E89A.6206@xyzzy.claranet.de> <5direjf0vd.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes in gmane.ietf.ima: > Frank Ellermann writes in gmane.ietf.ima: > > > > Harald Tveit Alvestrand wrote: > > > > >> 3. I have another opinion, which is: > > > > > I can't judge it at the moment. > > [...] > > > I'd feel far more confident that the WG is on the right track if we > > > nail the message/rfc822 vs. message/utf8smtp (or similar) question. > > > > Strike that, I hadn't seen the message/utf-8 draft when I posted that. > > > Removing the "header-format" header field should now work, "top level" > > messages can be identified (and if necessary downgraded) by looking > > at their header, and a "nested" message/utf-8 is already tagged with > > an explicit Content-type in its container. > > You still not take account Content-Type and Content-Disposition header > fields on MIME structure which are allowed include utf-8 on UTF8SMTP > message. That of course is not problem. You need just also look all MIME headers on MIME structure, before you decide is that UTF8SMTP message. > > Frank / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 16:42:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDSeV-0007Qg-92; Sat, 03 Feb 2007 16:42:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDSeU-0007Qa-U3 for ima@ietf.org; Sat, 03 Feb 2007 16:42:30 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDSeT-0001kt-9b for ima@ietf.org; Sat, 03 Feb 2007 16:42:30 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDSeH-0002z8-OO for ima@ietf.org; Sat, 03 Feb 2007 22:42:17 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 22:42:17 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 22:42:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Re: 8to7 downgrade and message/* Date: 03 Feb 2007 23:42:01 +0200 Lines: 39 Message-ID: <5dmz3u6hqu.fsf@Hurtta06k.keh.iki.fi> References: <5dk5yzckoo.fsf@Hurtta06k.keh.iki.fi> <45C4BF30.5CC9@xyzzy.claranet.de> <5d4pq3gkmb.fsf_-_@Hurtta06k.keh.iki.fi> <45C4DD12.5B7A@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > > Effectively gateways are required bounce unknown message/* types > > if they include 8-bit. > > Okay, so we should offer a better solution for message/utf-8 and > family for the purpose of 8BITMIME to 7bit gateways - nobody else > needs this. While we're at it let's support any message subtype, > including invalid message/rfc822 headers with UNKNOWN-8BIT octets. Yes. Note that providers of that solution are UTF8SMTP to rfc(2)822 gateways. They must do that munging so that there is not these message/utf-8, message/utf-8-headers and so on types. > How about an application/message-munged with a mandatory parameter > indicating the original message subtype ? Where "munged" could be > defined as a very radical procedure: Take the complete unknown > message part (or a complete invalid message/rfc822 part), gzip it, > B64 it, ready. Maybe gzip is overkill. message/utf-8 can be downgraded to message/rfc822 or converted to multipart/utf8-encapsulated. message/utf-8-headers is better replaced with text/utf8-header Then there is left message/utf-8-delivery-status and message/utf-8-disposition-notification There is some details which need to be figured out. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 17:16:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDTA2-0000Cj-8X; Sat, 03 Feb 2007 17:15:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDTA1-0000Ce-3w for ima@ietf.org; Sat, 03 Feb 2007 17:15:05 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDT9x-0006yD-Lt for ima@ietf.org; Sat, 03 Feb 2007 17:15:05 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDT9c-0001Up-PZ for ima@ietf.org; Sat, 03 Feb 2007 23:14:40 +0100 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 23:14:40 +0100 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Feb 2007 23:14:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 03 Feb 2007 23:12:44 +0100 Organization: Lines: 48 Message-ID: <45C508DC.6D7F@xyzzy.claranet.de> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> 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: 212.82.251.1 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [EAI] Re: BODY problems are our problems X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: >> Nested mesage parts belong to the body, we can ignore them for the >> purpose of "downgrade UTF8SMTP to 8BITMIME". Body problems are not >> our problems. > I disagree strongly! > MIME header fields on nested mime structure IS our problem. [...] > draft-ietf-eai-utf8headers-02.txt: [...] > 7.2. MIME headers [...] > it will now be allowed to use s containing UTF-8 > characters (see the revised syntax of in Section 6.2 of this > document). Well, I never supported to screw with MIME header fields or comments, including 2822 comments. I never will support it, MIME is sacrosanct. So from my POV the problem doesn't exist. At some point in time when legacy charsets are ancient history, and UTF-8 is the only charset used "on the wire", somebody else can tackle this. RFC 2277 says that this will be 50 years after its publication *or* *later*. Maybe SMTP is also ancient history at this time. I don't care about it now. Getting message/utf-8 (and family) right is interesting enough, adding nonsense like UTF-8 in comments and Content-* only risks a complete failure. You've told me that popular MTAs don't support RFC 1652 yet. That's not the point where adding _unnecessary_ features to UTF8SMTP sounds like an attractive idea. > That means also that you must parse whole MIME structure, before you > know is message UTF8SMTP. You only need to do that if you want to know if it's Mime-Version: 2.0. But the Mime-Version: 2.0 is already noted in the "top-level" header. Besides EAI isn't MIME 2.0: We're not doing 2045bis, 2046bis, 2047bis, 2049bis, and 2231bis, gibbous or not. You mentioned that twice today: The message/utf-8 draft must not touch 2045. We only (hopefully) lay the fundament for somebody else to create a MIME 2.0 on top of UTF8SMTP, later. When the last 7bit MTAs are in a museum. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 18:34:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDUOf-0007Pu-GH; Sat, 03 Feb 2007 18:34:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDUOe-0007PU-Ce for ima@ietf.org; Sat, 03 Feb 2007 18:34:16 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDUOc-0003qQ-QY for ima@ietf.org; Sat, 03 Feb 2007 18:34:16 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDUOX-000745-0k for ima@ietf.org; Sun, 04 Feb 2007 00:34:09 +0100 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 00:34:09 +0100 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 00:34:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Re: 8to7 downgrade and message/* Date: Sun, 04 Feb 2007 00:18:32 +0100 Organization: Lines: 54 Message-ID: <45C51848.5A00@xyzzy.claranet.de> References: <5dk5yzckoo.fsf@Hurtta06k.keh.iki.fi> <45C4BF30.5CC9@xyzzy.claranet.de> <5d4pq3gkmb.fsf_-_@Hurtta06k.keh.iki.fi> <45C4DD12.5B7A@xyzzy.claranet.de> <5dmz3u6hqu.fsf@Hurtta06k.keh.iki.fi> 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: 212.82.251.1 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > Note that providers of that solution are UTF8SMTP to rfc(2)822 > gateways. We're not exactly on the same track. I think it's conceptually cleaner to consider UTF8SMTP to 8BITMIME as one step "downgrade", and then 8BITMIME to 7bit as _optional_ second step. These two steps aren't necessarily on one relay, an UTF8SMTP MTA finding "only" 8BITMIME MTAs as next hops can downgrade UTF8SMTP to 8BITMIME, forward it, end of story from its POV. An 8BITMIME MTA finding a 7bit MTA needs some "8to7" RFC 1652 magic, but it doesn't need to know what UTF8SMTP or message/utf-8 are. It's also possible that the UTF8SMTP MTA finds only a 7bit MTA, and then it either has to do both steps, or bounce. It really can bounce, the framework RFC guarantees that, no MTA is forced to support both UTF8SMTP to 7bis steps. > message/utf-8 can be downgraded to message/rfc822 > or converted to multipart/utf8-encapsulated. Yes. The latter is tricky, you tried that already, and while I didn't look at the details my vague impression was that it might be not simple and intuitive enough. > message/utf-8-headers is better replaced with text/utf8-header ACK, corresponding to text/rfc822-headers in RFC 3462. I guess that's a consistent typo in I-D.ietf-eai-dsn-00. > Then there is left message/utf-8-delivery-status and > message/utf-8-disposition-notification The message/delivery-status isn't the same kind of MIME message like message/rfc822, message/news, or message/utf-8. They all have a header and a body, but for rfc822 etc. that body can be anything, a general container, zero or more parts. For delivery-status the "body" is apparently a single part with a rather strict structure (maybe I missed RFC 3464 details, and what I say is nonsense). IFF that's the case we could use a different MIME type, application/* or text/*, for delivery-status. And then we'd be free to use B64 or QP as CTE for its complete structure, including the "body". > some details which need to be figured out. It's not hopeless if we stay away from UTF-8 in Content-* ;-) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 19:58:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDVhO-0003e4-H0; Sat, 03 Feb 2007 19:57:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDVhN-0003dg-An for ima@ietf.org; Sat, 03 Feb 2007 19:57:41 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDVhK-0000Sn-N2 for ima@ietf.org; Sat, 03 Feb 2007 19:57:41 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l140vOJ5008158; Sun, 4 Feb 2007 09:57:25 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l140vOu1008157; Sun, 4 Feb 2007 09:57:24 +0900 Date: Sun, 4 Feb 2007 09:57:24 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] [ascii@address] vs Message-ID: <20070204005724.GE19841@ns5.lsb.org> References: <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> <407B9EC989C15E72DF80867C@p3.JCK.COM> <20070201024131.GK30318@ns5.lsb.org> <01DF86AB1FD3343508C0392D@JCK-ACR.jck.com> <20070201132203.GA19841@ns5.lsb.org> <5d1wl9n2vy.fsf_-_@Hurtta06k.keh.iki.fi> <20070202011604.GB19841@ns5.lsb.org> <5dwt3077e9.fsf@Hurtta06k.keh.iki.fi> <20070203070529.GC19841@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, Feb 03, 2007 at 12:29:08PM -0500, John C Klensin wrote: > > If one encountered > local-part@[some-string] > and the first character of that string was not a digit, a > correct interpretation of 2821 almost certainly requires that > one parse the string looking for an address literal type > keyword. If it can't be found, or isn't "IPv6:" (or something > else considered valid at the time), then it is an error. > > But, while my personal preference would be to just accept > > > and get on with it --not because I especially like it but > because it appears to be the rough consensus and "get on with > it" is becoming important -- I don't see what this has to with > the discussion. What I try to point out is that, o domain-literals contain IP address sequences, and it won't affect the confusibility of 4) and 5) o Comparing 4) with 5), 4) seems safer than 5), at least to me. o we can permit 2) and 3) as valid ones if we choose []. This is a outstanding benefit and beyond our own personal preferrences. o 2) seems the natural and smooth extension of 1) o If we choose <>, we can't permit 6) 1) To: EAI-LCL@address.tld, EAI-LCL2@address.tld 2) To: LCL@address.tld [ascii@address.tld], LCL2@@address.tld [ascii2@address.tld] 3) To: LCL@[128.1.2.3] [ascii@address.tld], LCL2@@[128.1.2.3] [ascii2@address.tld] 4) To: , 5) To: >, > 6) To: LCL@[128.1.2.3] , LCL2@@[128.1.2.3] 7) To: , 6) will be parsed into DISPLAY_NAME , DISPLAY_NAME2 by most existing robost email addres parsers. > > In 2821 and I think 2822, address literals are permitted only > where a domain can appear, and domains can appear only after > "@". So > local-path@[address-literal] > and > <@[address-literal]:local-part@domain> > are well-defined instance of address literals. But in all of > local-part@domain [string] > and > [string] > and > > "[string]" cannot, contextually, be an address literal. Sure. [string] is always full ascii email address. pleass read above for my intention. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 23:40:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDZAb-0005X4-Lg; Sat, 03 Feb 2007 23:40:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDZAa-0005SV-Ti for ima@ietf.org; Sat, 03 Feb 2007 23:40:04 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDZAZ-00075m-9a for ima@ietf.org; Sat, 03 Feb 2007 23:40:04 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l144dxJ5002838 for ; Sun, 4 Feb 2007 13:39:59 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l144dxJv002834 for ima@ietf.org; Sun, 4 Feb 2007 13:39:59 +0900 Date: Sun, 4 Feb 2007 13:39:59 +0900 From: Soobok Lee To: ima@ietf.org Message-ID: <20070204043959.GF19841@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Subject: [EAI] proposal to permit unquoted UTF8 display_name X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org [utf8headers] already permit this quoted form by redefining qtext to have utf-8 characters: 1) To: "cafe'" , But, it does not permit this unquoted one: 2) To: cafe' , 3) To: IMA , Please read the rfc2822/[utf8headers] excerpts below. If we are happy only with 2) and need not 1), we can ignore this issue. But, if we need to permit 1) in order be consistent with permitting 2), we may need to redefine "phrase" and its subcomponents. name-addr = [display-name] angle-addr display-name = phrase phrase = 1*word / obs-phrase word = atom / quoted-string obs-phrase = word *(word / "." / CFWS) atom = [CFWS] 1*atext [CFWS] dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom-text = 1*atext *("." 1*atext) atext = ALPHA / DIGIT / ; Any character except controls, "!" / "#" / ; SP, and specials. "$" / "%" / ; Used for atoms "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" [utf8headers] does not redefine "atext" and "atom", by the reason described in itself (see below), and instead defined separate"utf8-atext" and "utf8-atom". And, its parent "phrase" is not redefined to contain "utf8-atom". 6.2. Syntax extend from RFC 2822 The following rules are intended to extend the corresponding rules in RFC 2822 to allow UTF8 characters. ctext = NO-WS-CTL / ; all of except %d33-39 / ; SP, HTAB, "(", ")" %d42-91 / ; and "\" %d93-126 / UTF8-xtra-char qtext = NO-WS-CTL / ; all of except %d33 / ; The rest of the US-ASCII %d35-91 / ; characters not including "\" %d93-126 / ; or the quote character UTF8-xtra-char text = %d1-9 / ; all UTF-8 characters except %d11-12 / ; US-ASCII NUL, CR and LF %d14-127 / UTF8-xtra-char utext = NO-WS-CTL / ; Non white space controls %d33-126 / ; The rest of US-ASCII UTF8-xtra-char This means that all the RFC 2822 constructs that build upon these will permit UTF-8 characters, including comments and quoted strings. Besides, in order to allow UTF8 characters in we have to change the syntax of . However, it will also lead to allow UTF8 characters, which is not allowed due to the limitation describe in Section 6.4. So is added to meet this requirement. utf8-atext = ALPHA / DIGIT / "!" / "#" / ; Any character except "$" / "%" / ; controls, SP, and specials. "&" / "'" / ; Used for atoms "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / UTF8-xtra-char utf8-atom = [CFWS] 1*utf8-atext [CFWS] utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS] utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext) We need to redefine "phrase" and define new "utf8-word". phrase = 1*utf8-word / obs-phrase utf8-word = utf8-atom / quoted-string obs-phrase = utf8-word *(utf8-word / "." / CFWS) Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 23:43:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDZDj-0003kk-Ry; Sat, 03 Feb 2007 23:43:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDZDj-0003kf-5F for ima@ietf.org; Sat, 03 Feb 2007 23:43:19 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDZDh-0007xc-Ib for ima@ietf.org; Sat, 03 Feb 2007 23:43:19 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l144hFJ5003211 for ; Sun, 4 Feb 2007 13:43:15 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l144hFxv003210 for ima@ietf.org; Sun, 4 Feb 2007 13:43:15 +0900 Date: Sun, 4 Feb 2007 13:43:15 +0900 From: Soobok Lee To: ima@ietf.org Subject: Re: [EAI] proposal to permit unquoted UTF8 display_name Message-ID: <20070204044315.GG19841@ns5.lsb.org> References: <20070204043959.GF19841@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070204043959.GF19841@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, Feb 04, 2007 at 01:39:59PM +0900, Soobok Lee wrote: > > [utf8headers] already permit this quoted form by redefining > qtext to have utf-8 characters: > 1) To: "cafe'" , > > But, it does not permit this unquoted one: > 2) To: cafe' , > 3) To: IMA , [NOTE] 3) is already permitted in RFC2822, I put this together with 2) to ease comparison and clarify the need for redefiniton of "phrase". Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 03 23:56:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDZQ7-0004bK-Ew; Sat, 03 Feb 2007 23:56:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDZQ5-0004bD-QR for ima@ietf.org; Sat, 03 Feb 2007 23:56:05 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDZQ4-0001iW-8J for ima@ietf.org; Sat, 03 Feb 2007 23:56:05 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l144u1J5004626 for ; Sun, 4 Feb 2007 13:56:01 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l144u17t004625 for ima@ietf.org; Sun, 4 Feb 2007 13:56:01 +0900 Date: Sun, 4 Feb 2007 13:56:01 +0900 From: Soobok Lee To: ima@ietf.org Subject: Re: [EAI] proposal to permit unquoted UTF8 display_name Message-ID: <20070204045601.GH19841@ns5.lsb.org> References: <20070204043959.GF19841@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070204043959.GF19841@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, Feb 04, 2007 at 01:39:59PM +0900, Soobok Lee wrote: > > [utf8headers] already permit this quoted form by redefining > qtext to have utf-8 characters: > 1) To: "cafe'" , > > But, it does not permit this unquoted one: > 2) To: cafe' , > > 3) To: IMA ( valid under rfc2822/utf8headers), > > Please read the rfc2822/[utf8headers] excerpts below. > > If we are happy only with 1) and need not 2), > we can ignore this issue. > > But, if we need to permit 1) in order be consistent with permitting 2), > we may need to redefine "phrase" and its subcomponents. [CORRECTION] But, if we need to permit 2) in order to be consistent with permitting 3) and 2), we may need to redefine "phrase" and its subcomponents. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 02:36:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDbui-0000E6-4T; Sun, 04 Feb 2007 02:35:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDbuh-00008t-9R for ima@ietf.org; Sun, 04 Feb 2007 02:35:51 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDbuc-0000V2-24 for ima@ietf.org; Sun, 04 Feb 2007 02:35:51 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDbuM-0006KD-UZ for ima@ietf.org; Sun, 04 Feb 2007 08:35:30 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 08:35:30 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 08:35:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Re: BODY problems are our problems Date: 04 Feb 2007 09:35:16 +0200 Lines: 45 Message-ID: <5d1wl6xtmz.fsf@Hurtta06k.keh.iki.fi> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Besides EAI isn't MIME 2.0: We're not doing 2045bis, 2046bis, 2047bis, > 2049bis, and 2231bis, gibbous or not. You mentioned that twice today: > The message/utf-8 draft must not touch 2045. I wrote: ---------------------------------------------------------------- > Therefore that needs update RFC 2045 (and that may be difficult, > when documents of that working group are Experimental and RFC 2045 > is Standards track. ) Specially when that tries update something which affect these, which do not participate experiment defined on these Experimental RFCes. ------------------------------------------------------------------------ These Content-* affect only these which participate experiment defined on these Experimental RFCes. That is not different that these Experimental RFCes update RFC 2821 which is Standards track. If message/utf-8 was used after 7-bit downgrade, it was affect these, which do not participate experiment. ( That is irrelevent, is it using Mime-Version: 1.0 or Mime-Version: 1.0 when these changes affect only these which participate experiment. ) If I guess correctly, it is just Last Call which says is something allowed or not. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 05:58:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDf4R-0003bo-LB; Sun, 04 Feb 2007 05:58:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDf4Q-0003aE-SL for ima@ietf.org; Sun, 04 Feb 2007 05:58:06 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDf4O-0005E9-EO for ima@ietf.org; Sun, 04 Feb 2007 05:58:06 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDf4E-0003Uf-Io for ima@ietf.org; Sun, 04 Feb 2007 11:57:54 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 11:57:54 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 11:57:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Re: BODY problems are our problems Date: 04 Feb 2007 12:57:34 +0200 Lines: 66 Message-ID: <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Kari Hurtta wrote: > > >> Nested mesage parts belong to the body, we can ignore them for the > >> purpose of "downgrade UTF8SMTP to 8BITMIME". Body problems are not > >> our problems. > > > I disagree strongly! > > MIME header fields on nested mime structure IS our problem. > [...] > > draft-ietf-eai-utf8headers-02.txt: > [...] > > 7.2. MIME headers > [...] > > it will now be allowed to use s containing UTF-8 > > characters (see the revised syntax of in Section 6.2 of this > > document). > > Well, I never supported to screw with MIME header fields or comments, > including 2822 comments. I never will support it, MIME is sacrosanct. > Besides EAI isn't MIME 2.0: We're not doing 2045bis, 2046bis, 2047bis, > 2049bis, and 2231bis, gibbous or not. You mentioned that twice today: > The message/utf-8 draft must not touch 2045. Actually draft-ietf-eai-utf8headers-02.txt updates RFC 2822 (or RFC 822). It just indirectly affects MIME. That is what quoted text says. ( Of course RFC 2822 and RFC 822 are on Standards track, but these are assumed to affect only when UTF8SMTP is negotiated. ) draft-ietf-eai-utf8headers-02.txt: | 6.2. Syntax extend from RFC 2822 | | The following rules are intended to extend the corresponding rules in | RFC 2822 to allow UTF8 characters. These naturally affects to all RFCes which uses these RFC 2822 syntax elements. There is probbaly also other than just MIME. What limits it is following: | SMTP client can send header fields in UTF-8 format, if the UTF8SMTP | extension advertised by SMTP server or as permitted by other | transport mechanisms. That was not redefining anything: | 7.2. MIME headers | | The syntax of , as defined in RFC 2045, is | | value = token / quoted-string ( And I say: If message/utf-8 uses base64 / quoted-printable, then it must also update (that wording of) RFC 2045, so that base64 / quoted-printable is allowed. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 07:42:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDghJ-0002wM-OO; Sun, 04 Feb 2007 07:42:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDghI-0002wG-QA for ima@ietf.org; Sun, 04 Feb 2007 07:42:20 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDghF-0006AZ-Fl for ima@ietf.org; Sun, 04 Feb 2007 07:42:20 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDggw-0003aW-BA for ima@ietf.org; Sun, 04 Feb 2007 13:41:58 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 13:41:58 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 13:41:58 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 04 Feb 2007 14:41:43 +0200 Lines: 40 Message-ID: <5dabzurt6g.fsf@Hurtta06k.keh.iki.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [EAI] Chapter 7.2. MIME headers (Re: I-D ACTION:draft-ietf-eai-utf8headers-02.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --------------------------------------------------------------- 7.2. MIME headers The syntax of s containing UTF-8 characters (see the revised syntax of in Section 6.2 of this document). ---------------------------------------------------------------- This needs one addition: ----------------------------------------------------------------- The syntax of , as defined in RFC 2045, is description = "Content-Description" ":" *text It will now be allowed to use s containing UTF-8 characters (see the revised syntax of in Section 6.2 of this document). ----------------------------------------------------------------- ( If work group consensus is that MIME headers fields must not use UTF-8, then there need to be chapter which says that UTF-8 is not allowed headers defined on RFC 2048, even when revised syntax in Section 6.2 of this document allows it. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 08:09:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDh7v-0003dN-MP; Sun, 04 Feb 2007 08:09:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDh7u-0003ck-4s for ima@ietf.org; Sun, 04 Feb 2007 08:09:50 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDh7s-0001XQ-C7 for ima@ietf.org; Sun, 04 Feb 2007 08:09:50 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDh7a-0000of-BK for ima@ietf.org; Sun, 04 Feb 2007 14:09:30 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 14:09:30 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 14:09:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 04 Feb 2007 15:09:21 +0200 Lines: 27 Message-ID: <5d64airrwe.fsf@Hurtta06k.keh.iki.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [EAI] RFC 2919 addition (Re: I-D ACTION:draft-ietf-eai-utf8headers-02.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Addition: ------------------------------------------------------------------------ 7.1.1 List-ID The syntax of , as defined in RFC 2919, is list-id-header = "List-ID:" [phrase] "<" list-id ">" CRLF and s as defined in RFC 2822 can include s. It will now be allowed to use s containing UTF-8 characters (see the revised syntax of in Section 6.2 of this document). Note that uses , and is not extended to containing UTF-8 characters. ---------------------------------------------------------------------- / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 08:28:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDhPo-0003qt-0z; Sun, 04 Feb 2007 08:28:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDhPm-0003qh-Bs for ima@ietf.org; Sun, 04 Feb 2007 08:28:18 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDhPk-0005Gr-2G for ima@ietf.org; Sun, 04 Feb 2007 08:28:18 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDhPX-0004Dq-04 for ima@ietf.org; Sun, 04 Feb 2007 14:28:03 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 14:28:02 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 14:28:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: RFC 2369 (Re: [EAI] RFC 2919 addition (Re: I-D ACTION:draft-ietf-eai-utf8headers-02.txt)) Date: 04 Feb 2007 15:27:54 +0200 Lines: 43 Message-ID: <5d1wl6rr1h.fsf_-_@Hurtta06k.keh.iki.fi> References: <5d64airrwe.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org However I'm not able to determine actual grammar for header fields defined on RFC 2369, so I can not determine is draft-ietf-eai-utf8headers-02 extending these. Seems that syntax is actually defined without giving formal grammar. Or is I missing something? Header fields are: List-Help, List-Subscribe, List-Unsubscribe, List-Post, List-Owner, List-Archive On some header fields there are comments inside of ( ). It may be that these use To me it seems that MUAs will process comments inside of List-* header fields same way than comment on structured RFC 2822 header fields. RFC 2369 quote: ------------------------------------------- 2. The Command Syntax The list header fields are subject to the encoding and character restrictions for mail headers as described in [RFC822]. Additionally, the URL content is further restricted to the set of URL safe characters [RFC1738]. ----------------------------------------------------------- / Kari Hurtta RFC 2369: The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 09:10:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDi4m-0006Wu-O2; Sun, 04 Feb 2007 09:10:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDi4l-0006Wg-RV for ima@ietf.org; Sun, 04 Feb 2007 09:10:39 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDi4k-00044C-96 for ima@ietf.org; Sun, 04 Feb 2007 09:10:39 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDi4Z-00035r-Tt for ima@ietf.org; Sun, 04 Feb 2007 15:10:27 +0100 Received: from du-017a-072.access.de.clara.net ([213.221.75.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 15:10:27 +0100 Received: from nobody by du-017a-072.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 15:10:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sun, 04 Feb 2007 15:06:12 +0100 Organization: Lines: 44 Message-ID: <45C5E854.3EF8@xyzzy.claranet.de> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5d1wl6xtmz.fsf@Hurtta06k.keh.iki.fi> 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: du-017a-072.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [EAI] Re: BODY problems are our problems X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: >> The message/utf-8 draft must not touch 2045. > I wrote: ---------------------------------------------------------------- >| Therefore that needs update RFC 2045 (and that may be difficult, >| when documents of that working group are Experimental and RFC 2045 >| is Standards track. ) > > Specially when that tries update something which affect these, > which do not participate experiment defined on these Experimental > RFCes. > ------------------------------------------------------------------------ > These Content-* affect only these which participate experiment defined > on these Experimental RFCes. It's allowed to put complete message/utf-8 (and family) objects as MIME parts into normal 2822 Internet Messages (or FWIW s-o-1036 NetNews), and then it will affect folks not participating in the experiment. As soon as message/utf-8 is registered it can be used and will pop up everywhere (as part of ordinary mesages), and nobody will ask if that's an "experiment" if UTF-8 in Content-* confuses their anti virus software. That's a major security issue, claiming that it's "only" experimental doesn't help. Don't screw with MIME. For a sneak preview of the MIME security considerations elsewhere (limited to RFC 2231 in NetNews) see > If I guess correctly, it is just Last Call which says is something > allowed or not. Yes, and the IESG evaluation. I've a vivid imagination of what they'd do if Ned or Keith ask "now what's that?" wrt RFC 2045 in a Last Call. Any "screw with MIME" might be also interesting enough for the IAB - if not I'd wonder what they're good for. Try a Google search for "MIME vulnerability", IMO it's madness to join this club for the obscure and unnecessary feature "UTF-8 in Content-*". Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 09:48:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDifF-0004da-Gj; Sun, 04 Feb 2007 09:48:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDifF-0004d5-2i for ima@ietf.org; Sun, 04 Feb 2007 09:48:21 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDifD-00034t-Oi for ima@ietf.org; Sun, 04 Feb 2007 09:48:21 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HDifC-0006bA-6W; Sun, 04 Feb 2007 09:48:18 -0500 Date: Sun, 04 Feb 2007 09:48:17 -0500 From: John C Klensin To: Soobok Lee , ima@ietf.org Subject: Re: [EAI] proposal to permit unquoted UTF8 display_name Message-ID: In-Reply-To: <20070204044315.GG19841@ns5.lsb.org> References: <20070204043959.GF19841@ns5.lsb.org> <20070204044315.GG19841@ns5.lsb.org> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Sunday, 04 February, 2007 13:43 +0900 Soobok Lee wrote: > On Sun, Feb 04, 2007 at 01:39:59PM +0900, Soobok Lee wrote: >> >> [utf8headers] already permit this quoted form by redefining >> qtext to have utf-8 characters: >> 1) To: "cafe'" , >> >> But, it does not permit this unquoted one: >> 2) To: cafe' , >> 3) To: IMA , > > [NOTE] 3) is already permitted in RFC2822, > I put this together with 2) to ease comparison and > clarify the need for redefiniton of "phrase". I obviously cannot speak for others, I would feel no pain over requiring quotes if "phrase" contains any non-ASCII characters (in addition to requiring them if it contains ASCII Specials). Not only would that choice be better for compatibility with legacy implementations, but, as the example above illustrates, not requiring that the string be quoted would require that we establish rules about things that look like quotes. The latter would take us down the rathole over which IDNA has had a monopoly and we really don't want to go there. That comment would apply whether the example in (3) was intended to be c a f U+0065 U+2019 or c a f U+00E9 (note that c a f U+0027 requires quotes today) john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 10:15:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDj4x-00036N-63; Sun, 04 Feb 2007 10:14:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDj4w-00036C-GV for ima@ietf.org; Sun, 04 Feb 2007 10:14:54 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDj4t-0008Vj-6K for ima@ietf.org; Sun, 04 Feb 2007 10:14:54 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDj4f-0005DQ-9z for ima@ietf.org; Sun, 04 Feb 2007 16:14:37 +0100 Received: from du-017a-072.access.de.clara.net ([213.221.75.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 16:14:37 +0100 Received: from nobody by du-017a-072.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 16:14:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sun, 04 Feb 2007 16:05:20 +0100 Organization: Lines: 26 Message-ID: <45C5F630.649B@xyzzy.claranet.de> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> 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: du-017a-072.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [EAI] Re: BODY problems are our problems X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: >> Well, I never supported to screw with MIME header fields or comments, >> including 2822 comments. I never will support it, MIME is sacrosanct. >> Besides EAI isn't MIME 2.0: We're not doing 2045bis, 2046bis, 2047bis, >> 2049bis, and 2231bis, gibbous or not. [...] > Actually draft-ietf-eai-utf8headers-02.txt updates RFC 2822 (or RFC 822). > It just indirectly affects MIME. That is what quoted text says. > ( Of course RFC 2822 and RFC 822 are on Standards track, but these are > assumed to affect only when UTF8SMTP is negotiated. ) EAI is experimental. 2822 is a PS. MIME is a DS, and it's based on 822, not 2822. Whatever EAI or a 2822bis say, it has zero consequences for the minimal MIME conformance specified in RFC 2049. The future message/utf-8 when registered has to work with 2049 MIME, not only with "proposals" like 2231 or 2822, let alone any EAI "experiments". We can't B64 any message subtypes, and we can't allow UTF-8 in Content-*. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 11:13:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDjzz-0004XL-RJ; Sun, 04 Feb 2007 11:13:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDjzy-0004TN-HM for ima@ietf.org; Sun, 04 Feb 2007 11:13:50 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDjzx-0001CC-2n for ima@ietf.org; Sun, 04 Feb 2007 11:13:50 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDjzn-00070z-AU for ima@ietf.org; Sun, 04 Feb 2007 17:13:39 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 17:13:39 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 17:13:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: message/utf-8 (Re: [EAI] Re: BODY problems are our problems) Date: 04 Feb 2007 18:13:16 +0200 Lines: 52 Message-ID: <5dbqk952ar.fsf_-_@Hurtta06k.keh.iki.fi> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5d1wl6xtmz.fsf@Hurtta06k.keh.iki.fi> <45C5E854.3EF8@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Kari Hurtta wrote: > > >> The message/utf-8 draft must not touch 2045. > > > I wrote: ---------------------------------------------------------------- > >| Therefore that needs update RFC 2045 (and that may be difficult, > >| when documents of that working group are Experimental and RFC 2045 > >| is Standards track. ) > > > > Specially when that tries update something which affect these, > > which do not participate experiment defined on these Experimental > > RFCes. > > ------------------------------------------------------------------------ > > > These Content-* affect only these which participate experiment defined > > on these Experimental RFCes. > > It's allowed to put complete message/utf-8 (and family) objects as MIME > parts into normal 2822 Internet Messages (or FWIW s-o-1036 NetNews), and > then it will affect folks not participating in the experiment. > > As soon as message/utf-8 is registered it can be used and will pop up > everywhere (as part of ordinary mesages), and nobody will ask if that's > an "experiment" if UTF-8 in Content-* confuses their anti virus software. > > That's a major security issue, claiming that it's "only" experimental > doesn't help. Don't screw with MIME. For a sneak preview of the MIME > security considerations elsewhere (limited to RFC 2231 in NetNews) see > Is that same issue already on top level mail header fields which have UTF-8 inside of message/utf-8 ? Anti virus software often picks Subject: -header field to report. And sometimes From: -header field. I do not see, how that is limited to Content-* header fields. Either anti virus software knows what message/utf-8 is or treat it as unknown type. There is lot of media types. You are these problems anyway, if you can not limit where message/utf-8 is allowed. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 11:24:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDkAB-0006Sd-7H; Sun, 04 Feb 2007 11:24:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDkAA-0006SY-No for ima@ietf.org; Sun, 04 Feb 2007 11:24:22 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDkA9-0003AV-DL for ima@ietf.org; Sun, 04 Feb 2007 11:24:22 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HDkA8-0007G4-Sg; Sun, 04 Feb 2007 11:24:21 -0500 Date: Sun, 04 Feb 2007 11:24:20 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: BODY problems are our problems Message-ID: In-Reply-To: <45C5F630.649B@xyzzy.claranet.de> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Sunday, 04 February, 2007 16:05 +0100 Frank Ellermann wrote: > EAI is experimental. 2822 is a PS. MIME is a DS, and it's > based on 822, not 2822. Whatever EAI or a 2822bis say, it has > zero consequences for the minimal MIME conformance specified > in RFC 2049. > > The future message/utf-8 when registered has to work with 2049 > MIME, not only with "proposals" like 2231 or 2822, let alone > any EAI "experiments". > > We can't B64 any message subtypes, and we can't allow UTF-8 in > Content-*. Frank, This type of argument is sometimes known as behaving like a "procedural lawyer", an extension of being a "protocol lawyer". It rarely works well in the IETF and is, I would suggest, inappropriate here. I think there is some merit in what you are advocating and that it needs to be considered carefully on the basis of interoperability with existing (non-upgraded) implementations that conform to existing standards. However, let's base those considerations on the technical facts and figuring out what the right thing to do is. Once we establish that, we can then figure out how to make it happen, rather than assuming that existing rules seriously constrain our choices. Just my opinion. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 11:42:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDkRd-0004eS-ES; Sun, 04 Feb 2007 11:42:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDkRc-0004ac-0r for ima@ietf.org; Sun, 04 Feb 2007 11:42:24 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDkRa-00052d-JB for ima@ietf.org; Sun, 04 Feb 2007 11:42:24 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HDkRY-0007Ol-K9; Sun, 04 Feb 2007 11:42:20 -0500 Date: Sun, 04 Feb 2007 11:42:19 -0500 From: John C Klensin To: Soobok Lee Subject: Re: [EAI] [ascii@address] vs Message-ID: <58E866B4E5F87A97E244D413@p3.JCK.COM> In-Reply-To: <20070204005724.GE19841@ns5.lsb.org> References: <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> <407B9EC989C15E72DF80867C@p3.JCK.COM> <20070201024131.GK30318@ns5.lsb.org> <01DF86AB1FD3343508C0392D@JCK-ACR.jck.com> <20070201132203.GA19841@ns5.lsb.org> <5d1wl9n2vy.fsf_-_@Hurtta06k.keh.iki.fi> <20070202011604.GB19841@ns5.lsb.org> <5dwt3077e9.fsf@Hurtta06k.keh.iki.fi> <20070203070529.GC19841@ns5.lsb.org> <20070204005724.GE19841@ns5.lsb.org> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Sunday, 04 February, 2007 09:57 +0900 Soobok Lee wrote: > What I try to point out is that, > o domain-literals contain IP address sequences, and it > won't affect the confusibility of 4) and 5) > o Comparing 4) with 5), 4) seems safer than 5), at least to > me. o we can permit 2) and 3) as valid ones if we choose []. > This is a outstanding benefit and beyond our own > personal preferrences. o 2) seems the natural and smooth > extension of 1) o If we choose <>, we can't permit 6) > > > 1) To: EAI-LCL@address.tld, EAI-LCL2@address.tld > > 2) To: LCL@address.tld [ascii@address.tld], LCL2@@address.tld > [ascii2@address.tld] > > 3) To: LCL@[128.1.2.3] [ascii@address.tld], LCL2@@[128.1.2.3] > [ascii2@address.tld] > > 4) To: , > I assume that the third "@" in the second line, here and below, is a typographical error: certainly I can't figure out what else it might be. > 5) To: >, > > > > 6) To: LCL@[128.1.2.3] , LCL2@@[128.1.2.3] > > > 7) To: , > > > 6) will be parsed into > DISPLAY_NAME , DISPLAY_NAME2 > by most existing robost email addres > parsers. Please also note, first, that you have no idea what a valid domain literal looks like once one passes beyond IPv6, other than it must start with an ASCII string that conforms to LDH rules followed by a colon. In particular, something like [HIP:semi-random-identifier] might turn out to be valid eventually: there is no requirement that the string consist of decimal or hex digits. Second, please note forms 4a and b and 5a and b: 4a) To: , 4b) To: , 5a) To: >, > 5b) To: >, > I am unconvinced that there is any significant difference between the two forms. I can construct really weak arguments for preferring either, but few if any strong ones. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 13:06:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDlkH-0000wk-Dz; Sun, 04 Feb 2007 13:05:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDlkG-0000wd-3v for ima@ietf.org; Sun, 04 Feb 2007 13:05:44 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDlkE-00028I-Qy for ima@ietf.org; Sun, 04 Feb 2007 13:05:44 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDljz-0006WU-NQ for ima@ietf.org; Sun, 04 Feb 2007 19:05:27 +0100 Received: from du-017a-072.access.de.clara.net ([213.221.75.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 19:05:27 +0100 Received: from nobody by du-017a-072.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 19:05:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Re: BODY problems are our problems Date: Sun, 04 Feb 2007 19:04:40 +0100 Organization: Lines: 18 Message-ID: <45C62038.5F12@xyzzy.claranet.de> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> 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: du-017a-072.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > This type of argument is sometimes known as behaving like a > "procedural lawyer", an extension of being a "protocol lawyer". The more substantial security concern was in another message. The procedural stuff was triggered by Kari's argument, that if EAI updates 2822, then MIME would automatically inherit this, because MIME uses 2822. I think that's wrong, procedurally. In practice it means that existing MIME software might be less robust than we hope and choke on UTF-8 in Content-*. Kari's argument also hit my "FUSSP" (here for worldwide MIME upgrade) nerve, and that made me angry, sorry. I like MIME up to 2049. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 13:26:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDm3v-0001FD-OK; Sun, 04 Feb 2007 13:26:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDm3u-0001AB-Ft for ima@ietf.org; Sun, 04 Feb 2007 13:26:02 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDm3t-0004jK-2f for ima@ietf.org; Sun, 04 Feb 2007 13:26:02 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HDm3s-00082C-GT; Sun, 04 Feb 2007 13:26:00 -0500 Date: Sun, 04 Feb 2007 13:25:59 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: BODY problems are our problems Message-ID: <9318B2B12A2EB8312936B046@p3.JCK.COM> In-Reply-To: <45C62038.5F12@xyzzy.claranet.de> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Sunday, 04 February, 2007 19:04 +0100 Frank Ellermann wrote: > John C Klensin wrote: > >> This type of argument is sometimes known as behaving like a >> "procedural lawyer", an extension of being a "protocol >> lawyer". > > The more substantial security concern was in another message. Yes, I know. But when you, or Kari, or Soobok, or Charles, or all of you in combination, generate a small storm of messages on closely-related subjects, many of us won't read carefully all the way to the end of all of them. The consequence is that the noise drowns out the signal. > The procedural stuff was triggered by Kari's argument, that if > EAI updates 2822, then MIME would automatically inherit this, > because MIME uses 2822. I think that's wrong, procedurally. It is also wrong factually. What is important in that regard is what actual implementations, especially those that have made a serious effort to be conforming, are doing, not what the standards happen to say. So, even if Kari (or your interpretation of what he is saying) were correct about impact on the standards, it would still be the case that conforming implementations of 2822 would not inherently know how to handle these new constructions. For the record, you just got unlucky -- I could as easily have complained about one of Kari's notes or one of Soobok's or one of Charles's, since I think all of you have fallen into the problem at one time or another. > In practice it means that existing MIME software might be less > robust than we hope and choke on UTF-8 in Content-*. Kari's > argument also hit my "FUSSP" (here for worldwide MIME upgrade) > nerve, and that made me angry, sorry. I like MIME up to 2049. Everything we do here that could hit a non-upgraded server or client is dangerous. The hardest part of our work, IMO, is to analyze and evaluate those risks to legacy conforming (and even nearly-conforming) implementations and, following something Randy Gellens has been saying repeatedly recently, make sure that we don't introduce problems for the longer term (in which most of the Internet has upgraded) in order to make things a little easier for short-term transitions. If we can focus on that case identification and analysis, we will make progress. If we get distracted by discussions about procedural models, we are less likely to be successful, IMO. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 14:59:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDnWO-0002Mr-Gm; Sun, 04 Feb 2007 14:59:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDnWM-0002Mg-Vw for ima@ietf.org; Sun, 04 Feb 2007 14:59:30 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDnWL-0002jd-Hz for ima@ietf.org; Sun, 04 Feb 2007 14:59:30 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HDnWC-0007Hb-K1 for ima@ietf.org; Sun, 04 Feb 2007 20:59:20 +0100 Received: from du-017a-072.access.de.clara.net ([213.221.75.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 20:59:20 +0100 Received: from nobody by du-017a-072.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Feb 2007 20:59:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sun, 04 Feb 2007 20:48:25 +0100 Organization: Lines: 57 Message-ID: <45C63889.6BEB@xyzzy.claranet.de> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> 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: du-017a-072.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [EAI] Summary of the "BODY problems" thread(s) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: [analyze and evaluate] > risks to legacy conforming (and even nearly-conforming) > implementations and [...] > make sure that we don't introduce problems for the longer > term (in which most of the Internet has upgraded) in order > to make things a little easier for short-term transitions. > If we can focus on that case identification and analysis, > we will make progress. Okay, I try a summary of Kari's and my "brain-storming" here wrt UTF-8 in Content-*: A message transported by SMTP (or NNTP or UUCP) is today implicitly a message/rfc822. It might be even "valid" as defined in the relevant RFCs like 2822. After the introduction of UTF8SMTP that's not more always the case, it can be a message/rfc822 or a message/utf-8. A valid message/rfc822 is also a valid message/utf-8, but the opposite isn't always true, they're not equivalent. Therefore we need a way to identify cases, where a message is a "real" message/utf-8. One way to do this is to look at its header, if it's pure ASCII it's a message/rfc822, if it's valid UTF-8 it's a message/utf-8. In both cases not necessarily syntactically valid, but it could be valid. If it's anything else ("non-ASCII") it can't be valid, and we can simply put it in the "invalid message/rfc822" bin. Another way to identify it is to parse its complete MIME structure, its "top" header, and headers of all contained MIME parts in its body. The "top header only" approach can't work if somewhere in the nested multipart MIME headers raw UTF-8 is used in a Content-* including comments (as the first used UTF-8). [end of summary] The "parse nested MIME parts" might be difficult, it has to descend into multipart/* parts, but not into message/*, and it's apparently an update of MIME. Kari, please correct me if I got it wrong. IMO we've to decide what we want, allowing UTF-8 in MIME part headers has various consequences, it also affects downgrading. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 16:33:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDoyt-0005Up-4Y; Sun, 04 Feb 2007 16:33:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDoyr-0005Uj-UM for ima@ietf.org; Sun, 04 Feb 2007 16:33:01 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDoyq-00045e-ET for ima@ietf.org; Sun, 04 Feb 2007 16:33:01 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9CBC02596EB for ; Sun, 4 Feb 2007 22:28:56 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24823-03 for ; Sun, 4 Feb 2007 22:28:50 +0100 (CET) Received: from [10.71.2.170] (unknown [12.108.175.130]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5B5F42596E7 for ; Sun, 4 Feb 2007 22:28:50 +0100 (CET) Date: Sun, 04 Feb 2007 13:33:08 -0800 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: <2EE91B161210ACF70C61C841@[10.71.2.170]> In-Reply-To: References: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [EAI] SUMMARY OF RESPONSES: Header format for alt-addr X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org The responses to the consensus call represented below are: 1. I agree with this resolution Tony Finch Frank Ellerman Charles Lindsey Kari Hurtta Chris Newman Yangwoo Ko William Leibzon Yao Jiankang John Klensin Alexey Melnikov Yoshiro Yoneya 2. I disagree with this resolution, for the following technical reason: 3: I have another opinion, which is: This issue is settled, and will not be reopened unless there is new technical evidence. Harald --On 26. januar 2007 11:05 +0100 Harald Tveit Alvestrand wrote: > I think it's time we settled the issue of the format of email addresses > in UTF8SMTP headers for this round. > > PROPOSED RESOLUTION: > > The representation of an internationalized email address with an > alternate ASCII address in an UTF8SMTP message is > > > > > A pure EAI address and a pure ASCII address are both encoded without the > extra field: as . > Details of ABNF to be worked out after a draft with this syntax has been > emitted. > > POSSIBLE RESPONSES: > > 1. I agree with this resolution > 2. I disagree with this resolution, for the following technical reason: > 3: I have another opinion, which is: > > RESPOND: > > - To the list, if you want to present an argument or just want to make > your position visible at once > - To the chairs, if you don't want to respond on-list. > > The deadline for responses is THURSDAY, FEBRUARY 1, 23:59 GMT > The chairs will prepare a summary, with names listed for each position, > hopefully on Friday, Feb 2. > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 16:40:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDp64-0007rc-9w; Sun, 04 Feb 2007 16:40:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDp62-0007rB-OL for ima@ietf.org; Sun, 04 Feb 2007 16:40:26 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDp2b-00058D-0J for ima@ietf.org; Sun, 04 Feb 2007 16:36:54 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 40E962596EB; Sun, 4 Feb 2007 22:32:49 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24823-05; Sun, 4 Feb 2007 22:32:44 +0100 (CET) Received: from [10.71.2.170] (unknown [12.108.175.130]) by eikenes.alvestrand.no (Postfix) with ESMTP id 14D7D2596E7; Sun, 4 Feb 2007 22:32:43 +0100 (CET) Date: Sun, 04 Feb 2007 13:37:02 -0800 From: Harald Tveit Alvestrand To: Charles Lindsey , IMA Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Message-ID: <490765080EC9FB5D03769DBB@[10.71.2.170]> In-Reply-To: References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <45BCFD71.6225@xyzzy.claranet.de> <5103A2A292C8E4D9539C0944@[172.19.11.21]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 30. januar 2007 17:33 +0000 Charles Lindsey wrote: > On Mon, 29 Jan 2007 19:18:50 -0000, Harald Tveit Alvestrand > wrote: > >> --On 29. januar 2007 11:13 +0000 Charles Lindsey >> wrote: > >>> But I suspect those languages mostly do not need the language >>> information >>> to assist in the display process, whereas I would imagine that it is >>> useful for a user agent to know whether it is displaying Chinese or >>> Japanese, even though those languages use essentially the same "CJK" >>> parts of Unicode. >> >> Have you read RFC 2277? > > Yes, the relevant bit seems to be: > > Many operations, including high quality formatting, text-to-speech > synthesis, searching, hyphenation, spellchecking and so on benefit > greatly from access to information about the language of a piece of > text. [WC 3.1.1.4]. > > Which seems to cover the sort of situation that I mentioned. And where in that text did you find any justification for assuming that this information is required for UTF-8 headers and not required for ASCII headers? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 04 16:41:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDp6d-00084o-Tr; Sun, 04 Feb 2007 16:41:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDp6c-00084c-P3 for ima@ietf.org; Sun, 04 Feb 2007 16:41:02 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HDp6b-0006fP-5H for ima@ietf.org; Sun, 04 Feb 2007 16:41:02 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B3EEE2596EB for ; Sun, 4 Feb 2007 22:36:54 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24543-10 for ; Sun, 4 Feb 2007 22:36:49 +0100 (CET) Received: from [10.71.2.170] (unknown [12.108.175.130]) by eikenes.alvestrand.no (Postfix) with ESMTP id 916252596E7 for ; Sun, 4 Feb 2007 22:36:48 +0100 (CET) Date: Sun, 04 Feb 2007 13:41:07 -0800 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: In-Reply-To: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [EAI] SUMMARY: Removal of Header-Format: marker X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org The responses to this consensus call are summarized as follows: 1. I agree with this resolution Tony Finch Bill McQuillan Chris Newman Yangwoo Ko Kari Hurtta Yao Jankang John Klensin Jeff Yeh Kazunori Fujiwara Yoshiro Yoneya Randall Gellens Frank Ellermann 2. I disagree with this resolution, for the following technical reasons: Charles Lindsey - multiple reasons 3. I have another opinion, which is: This issue is now settled. Further discussion is off-topic for the WG, unless new technical information can be brought to the table. I would STRONGLY recommend that dissenting voices not attempt to reopen the issue without having checked with at least a few other particpiants that they will support reopening the issue based on that new technical information. Harald Alvestrand The original call: --On 26. januar 2007 11:13 +0100 Harald Tveit Alvestrand wrote: > The discussion of whether or not we need a header marker for marking > UTF8SMTP messages that actually use UTF-8 characters has reached a point > where it seems that no new technical information is being provided. > > At this point, the chairs wish to see if the group is near a possible > consensus on the issue. > > PROPOSED RESOLUTOIN: > > There is no significant operational or implementation benefit in having a > marker in the headers of UTF8SMTP messages, and significant additional > complexity. Therefore, the proposed "Header-Type" section, > draft-ietf-eai-utf8headers-02 section 5, will be removed. > > Note that this is not a call on the proposal to have a similar marker in > the SMTP protocol; that's a separate issue. > > POSSIBLE RESPONSES: > > 1. I agree with this resolution > 2. I disagree with this resolution, for the following technical reasons: > 3. I have another opinion, which is: > > RESPOND: > > - To the list, if you want to present an argument or just want to make > your position visible at once > - To the chairs, if you don't want to respond on-list. > > The deadline for responses is THURSDAY, FEBRUARY 1, 23:59 GMT > The chairs will prepare a summary, with names listed for each position, > hopefully on Friday, Feb 2. > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 05 03:51:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDzYk-0003AB-39; Mon, 05 Feb 2007 03:50:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDzYj-0003A5-9j for ima@ietf.org; Mon, 05 Feb 2007 03:50:45 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDzYh-0004jz-Ke for ima@ietf.org; Mon, 05 Feb 2007 03:50:45 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l158oUJ5010344; Mon, 5 Feb 2007 17:50:30 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l158oUPS010343; Mon, 5 Feb 2007 17:50:30 +0900 Date: Mon, 5 Feb 2007 17:50:30 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] proposal to permit unquoted UTF8 display_name Message-ID: <20070205085029.GI19841@ns5.lsb.org> References: <20070204043959.GF19841@ns5.lsb.org> <20070204044315.GG19841@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, Feb 04, 2007 at 09:48:17AM -0500, John C Klensin wrote: > > > --On Sunday, 04 February, 2007 13:43 +0900 Soobok Lee > wrote: > > > On Sun, Feb 04, 2007 at 01:39:59PM +0900, Soobok Lee wrote: > >> > >> [utf8headers] already permit this quoted form by redefining > >> qtext to have utf-8 characters: > >> 1) To: "cafe'" , > >> > >> But, it does not permit this unquoted one: > >> 2) To: cafe' , > >> 3) To: IMA , > > > > [NOTE] 3) is already permitted in RFC2822, > > I put this together with 2) to ease comparison and > > clarify the need for redefiniton of "phrase". > > I obviously cannot speak for others, I would feel no pain over > requiring quotes if "phrase" contains any non-ASCII characters > (in addition to requiring them if it contains ASCII Specials). > Not only would that choice be better for compatibility with > legacy implementations, What I observed and described in the previous thread was this: 1) unquoted_display_name_in_utf8 (invalid under rfc2822) will be treated/parsed as if it were 2) "unquoted_display_name_in_utf8" (valid under utf8headers) by most existing email address parsers (from mutt1.4 to sendmail 8.13.x) and probably so by future EAI-capable email address parsers. Even though 1) is invalid under RFC2822, it has been respected by implementors so far. I guess such convention is prevailing and will be so even in the future. I think we have had the pressure from implementors to acknowledge 1) as de-facto (industry) standard and incorporate it into RFCs. So, I propose here : How about lifting up the rfc2822' sanction against 1) and making 1) as legitimate one from [utf8headers] ? > but, as the example above illustrates, > not requiring that the string be quoted would require that we > establish rules about things that look like quotes. Beside quotes-like characters, we have other problematic character candidates in display_name like : space-like,angle-bracket-like,@-like,:-like ones and many more. So, even if we leave current "requirement" for double quotes for non-ascii UTF8 display_name intact in [utf8headers], that *** won't be sufficient *** for preventing such confusions. Instead, we can permit unquoted forms explicitly and recommend MUA implementors that: unquoted non-ascii UTF8 display_name should be presented end users as quoted form by transforming 1) into 2) before displaying it, of course, with cautions about above-mentioned other candidates for confusions. > > That comment would apply whether the example in (3) was intended > to be > c a f U+0065 U+2019 or > c a f U+00E9 Both! > (note that > c a f U+0027 > requires quotes today) U+0027 is a single quote(') and is a "atom" element character along with backquote(`) (see below). So no requirement for double quotes. We need double quotation requirement for these ascii chars: ,@()[]<>\;:" etc. So, "c a f :" should be double-quoted, while "c a f '" is not. You may have numeric typo errors in "c a f U+0027" above. display-name = phrase phrase = 1*word / obs-phrase word = atom / quoted-string atom = [CFWS] 1*atext [CFWS] atext = ALPHA / DIGIT / ; Any character except controls, "!" / "#" / ; SP, and specials. "$" / "%" / ; Used for atoms "&" / "'" / <----------------- "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" Even after adding "utf8-xtra-char" to the end of "atext" (making utf8-atext), double quotations requirement above for(,@()[]<>\;:) is still intact. When utf8 display_name contains only extened Latin,Hiragana or Hangul characters , we should not require double quotes, for the same reason we do not require "" in "To: IMA ". If display_name contains non-ascii UTF8-encoded (quote|comma|@|space)-like homograph characters, MUA should take cautions in displaying them before end users, whether is quoted or not. This recommendation is valid even for local part of non-ascii email address. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 05 04:38:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0J4-0000JK-1Z; Mon, 05 Feb 2007 04:38:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0J2-0000HH-Oj for ima@ietf.org; Mon, 05 Feb 2007 04:38:36 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE0J0-0000Zz-48 for ima@ietf.org; Mon, 05 Feb 2007 04:38:36 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l159cVJ5016100; Mon, 5 Feb 2007 18:38:31 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l159cUBN016097; Mon, 5 Feb 2007 18:38:30 +0900 Date: Mon, 5 Feb 2007 18:38:30 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] proposal to permit unquoted UTF8 display_name Message-ID: <20070205093830.GJ19841@ns5.lsb.org> References: <20070204043959.GF19841@ns5.lsb.org> <20070204044315.GG19841@ns5.lsb.org> <20070205085029.GI19841@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070205085029.GI19841@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, Feb 05, 2007 at 05:50:30PM +0900, Soobok Lee wrote: > We need double quotation requirement for these ascii chars: > > ,@()[]<>\;:" etc. > > So, "c a f :" should be double-quoted, while "c a f '" is not. > > You may have numeric typo errors in "c a f U+0027" above. > > > display-name = phrase > > phrase = 1*word / obs-phrase > > word = atom / quoted-string > > atom = [CFWS] 1*atext [CFWS] > > atext = ALPHA / DIGIT / ; Any character except controls, > "!" / "#" / ; SP, and specials. > "$" / "%" / ; Used for atoms > "&" / "'" / <----------------- > "*" / "+" / > "-" / "/" / > "=" / "?" / > "^" / "_" / > "`" / "{" / > "|" / "}" / > "~" > > > Even after adding "utf8-xtra-char" to the end of "atext" (making utf8-atext), > double quotations requirement above for(,@()[]<>\;:) is still intact. In other words, even after [utf8headers] permits unquoted utf8-atext string in display_name, "cafe':" should be double-quoted, while "cafe'!" need not. ( e' == u+00e9) because ":" is not permitted even in "utf8-atext" as well as in "atext". Soobok > When utf8 display_name contains only extened Latin,Hiragana or Hangul characters , > we should not require double quotes, for the same reason we do not require "" > in "To: IMA ". _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 05 07:16:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE2l2-0003Gp-0i; Mon, 05 Feb 2007 07:15:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE2l1-0003Gk-Fr for ima@ietf.org; Mon, 05 Feb 2007 07:15:39 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE2kz-0001Ta-Ty for ima@ietf.org; Mon, 05 Feb 2007 07:15:39 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HE2kz-000DzO-7S; Mon, 05 Feb 2007 07:15:37 -0500 Date: Mon, 05 Feb 2007 07:15:36 -0500 From: John C Klensin To: Soobok Lee Subject: Re: [EAI] proposal to permit unquoted UTF8 display_name Message-ID: <1F0B9595CBA4801D02D04637@p3.JCK.COM> In-Reply-To: <20070205085029.GI19841@ns5.lsb.org> References: <20070204043959.GF19841@ns5.lsb.org> <20070204044315.GG19841@ns5.lsb.org> <20070205085029.GI19841@ns5.lsb.org> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 05 February, 2007 17:50 +0900 Soobok Lee wrote: > On Sun, Feb 04, 2007 at 09:48:17AM -0500, John C Klensin wrote: >> >> >> --On Sunday, 04 February, 2007 13:43 +0900 Soobok Lee >> wrote: >> >> > On Sun, Feb 04, 2007 at 01:39:59PM +0900, Soobok Lee wrote: >> >> >> >> [utf8headers] already permit this quoted form by redefining >> >> qtext to have utf-8 characters: >> >> 1) To: "cafe'" , >> >> >> >> But, it does not permit this unquoted one: >> >> 2) To: cafe' , >> >> 3) To: IMA , >> > >> > [NOTE] 3) is already permitted in RFC2822, >> > I put this together with 2) to ease comparison and >> > clarify the need for redefiniton of "phrase". >> >> I obviously cannot speak for others, I would feel no pain over >> requiring quotes if "phrase" contains any non-ASCII characters >> (in addition to requiring them if it contains ASCII Specials). >> Not only would that choice be better for compatibility with >> legacy implementations, > > What I observed and described in the previous thread was this: > > 1) unquoted_display_name_in_utf8 (invalid > under rfc2822) > > will be treated/parsed as if it were > > 2) "unquoted_display_name_in_utf8" (valid > under utf8headers) > > by most existing email address parsers (from mutt1.4 to > sendmail 8.13.x) and probably so by future EAI-capable email > address parsers. > > Even though 1) is invalid under RFC2822, it has been > respected by implementors so far. I guess such convention is > prevailing and will be so even in the future. I think we have > had the pressure from implementors to acknowledge 1) as > de-facto (industry) standard and incorporate it into RFCs. > > So, I propose here : > > How about lifting up the rfc2822' sanction against 1) > and making 1) as legitimate one from [utf8headers] ? (1) We cannot change RFC2822. This is an operational and implementation matter, not a procedural one. (2) RFC2822 --and our rules-- are not about what happens in an MUA, but about what goes out over the wire. I believe that you are making tests with what MUAs will accept and then confusing the two. Sending strings that RFC 2822 requires be quoted onto the wire without quotes is much less common than you seem to assume. Sending those strings unquoted is certainly not a "de-facto industry standard". There is at least one pair of MUAs that are widely enough used to claim "de-facto industry standard" status all by themselves that, at least in most versions, quote _all_ display name strings, whether they contain special characters or not, and insist on always having a display name, even if, to do so, they must transform To: user@domain into To: "user@domain" and... >> but, as the example above illustrates, >> not requiring that the string be quoted would require that we >> establish rules about things that look like quotes. > > Beside quotes-like characters, we have other problematic > character candidates in display_name like : > space-like,angle-bracket-like,@-like,:-like ones and many > more. > > So, even if we leave current "requirement" for double quotes > for non-ascii UTF8 display_name intact in [utf8headers], > that *** won't be sufficient *** for preventing such > confusions. That is why, despite the small inconvenience, I suggested just requiring quotes for all such strings that contain non-ASCII characters. Although a parser would have no problems, trying to figure out while characters look enough like others to be problematic is an exercise that we can best avoid. Of course, an MUA might accept whatever it liked without quotes and quote it before putting it on the wire, just as is the case today. > Instead, we can permit unquoted forms explicitly and > recommend MUA implementors that: > unquoted non-ascii UTF8 display_name should be presented > end users as quoted form by transforming 1) into 2) > before displaying it, of course, with cautions about > above-mentioned other candidates for confusions. This is not a matter within the charter of this WG. john p.s. Similar-looking characters are very rarely homographs. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 05 10:12:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE5WD-000661-Is; Mon, 05 Feb 2007 10:12:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE5WB-00062x-LB for ima@ietf.org; Mon, 05 Feb 2007 10:12:31 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE5WA-000657-1P for ima@ietf.org; Mon, 05 Feb 2007 10:12:31 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l15FCRJ5023931; Tue, 6 Feb 2007 00:12:27 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l15FCQoC023921; Tue, 6 Feb 2007 00:12:26 +0900 Date: Tue, 6 Feb 2007 00:12:26 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] proposal to permit unquoted UTF8 display_name Message-ID: <20070205151226.GK19841@ns5.lsb.org> References: <20070204043959.GF19841@ns5.lsb.org> <20070204044315.GG19841@ns5.lsb.org> <20070205085029.GI19841@ns5.lsb.org> <1F0B9595CBA4801D02D04637@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F0B9595CBA4801D02D04637@p3.JCK.COM> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, Feb 05, 2007 at 07:15:36AM -0500, John C Klensin wrote: > > > > How about lifting up the rfc2822' sanction against 1) > > and making 1) as legitimate one from [utf8headers] ? > > (1) We cannot change RFC2822. This is an operational and > implementation matter, not a procedural one. > > (2) RFC2822 --and our rules-- are not about what happens in an > MUA, but about what goes out over the wire. I believe that you > are making tests with what MUAs will accept and then confusing > the two. Sending strings that RFC 2822 requires be quoted onto > the wire without quotes is much less common than you seem to > assume. Sending those strings unquoted is certainly not a > "de-facto industry standard". I accept. > > There is at least one pair of MUAs that are widely enough used > to claim "de-facto industry standard" status all by themselves > that, at least in most versions, quote _all_ display name > strings, whether they contain special characters or not, and > insist on always having a display name, even if, to do so, they > must transform > To: user@domain > into > To: "user@domain" > > and... I see. If this WG has consensus that 'To: "display_name" ' is the most desirable & normal form which we should recommend in headers, we can "require" non-ascii display_name "MUST" be double-quoted always. > > >> but, as the example above illustrates, > >> not requiring that the string be quoted would require that we > >> establish rules about things that look like quotes. > > > > Beside quotes-like characters, we have other problematic > > character candidates in display_name like : > > space-like,angle-bracket-like,@-like,:-like ones and many > > more. > > > > So, even if we leave current "requirement" for double quotes > > for non-ascii UTF8 display_name intact in [utf8headers], > > that *** won't be sufficient *** for preventing such > > confusions. > > That is why, despite the small inconvenience, I suggested just > requiring quotes for all such strings that contain non-ASCII > characters. Although a parser would have no problems, trying to > figure out while characters look enough like others to be > problematic is an exercise that we can best avoid. I think requiring quotes does not cause any significant inconvenience. > Of course,an MUA might accept whatever it liked without quotes and quote > it before putting it on the wire, just as is the case today. How about putting this recommendation into [utf8headers] explicitly ? > > > Instead, we can permit unquoted forms explicitly and > > recommend MUA implementors that: > > unquoted non-ascii UTF8 display_name should be presented > > end users as quoted form by transforming 1) into 2) > > before displaying it, of course, with cautions about > > above-mentioned other candidates for confusions. > > This is not a matter within the charter of this WG. Okay. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 05 11:44:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6wt-0007WY-OK; Mon, 05 Feb 2007 11:44:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6wt-0007W9-E4 for ima@ietf.org; Mon, 05 Feb 2007 11:44:11 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE6wm-0006ng-LW for ima@ietf.org; Mon, 05 Feb 2007 11:44:11 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3*clerew^man#ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45c75ed3.12bcf.34b0 for ima@ietf.org; Mon, 5 Feb 2007 16:44:03 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l15Gi2U5022072 for ; Mon, 5 Feb 2007 16:44:03 GMT To: IMA Subject: Re: [EAI] Re: Preliminary copy of the post-Last Call EAI framework draft posted References: <7D73245C9F1297E78C91A927@[172.19.11.21]> <45C401FB.5A4E@xyzzy.claranet.de> Message-ID: Date: Mon, 05 Feb 2007 16:44:01 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <45C401FB.5A4E@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 03 Feb 2007 03:31:07 -0000, Frank Ellermann wrote: > Harald Tveit Alvestrand wrote: > >> http://www.alvestrand.no/ietf/eai/eai-framework-05b.txt > > Hwdiff at - I think it's okay. > Does the following statement still make sense ? > > | There is no such thing as an "i18mail message"; the term > | applies only to users and their agents and capabilities. > > I-D.eai-dsn-00 now defines message/utf-8, and minus "TBD" > details it's a major step forward in a promising direction. > > The paragraph ending with "there is no such thing" also makes > sense without this statement about a "i18mail message". I also spotted this paragraph when chasing something else, and I observe that we carefully define all the possibilities for addresses (ASCII, NON-ASCII and UTF8SMTP), but we do not seem to have defined any terminology for describing messages as such (apart from that sentence saying "there is no such thing"). And yet we are currently involved in heavy discussions about how messages of varuious sorts might or might not be handled. It seems to be the case that the same three types of message exist (ASCII, NON-ASCII and UTF8SMTP, where those terms apply to the '8bitiness' of headers, not bodies, at any level). Note that a message can still be Non-ASCII even if there if every address in it and in its envelope is pure ASCII. This strikes me as a notable omission. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 05 11:58:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7Ak-0007vu-Qs; Mon, 05 Feb 2007 11:58:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7Aj-0007vU-KS for ima@ietf.org; Mon, 05 Feb 2007 11:58:29 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7Ai-0000vY-8Q for ima@ietf.org; Mon, 05 Feb 2007 11:58:29 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HE7Ac-000FnW-CN; Mon, 05 Feb 2007 11:58:22 -0500 Date: Mon, 05 Feb 2007 11:58:21 -0500 From: John C Klensin To: Charles Lindsey , IMA Subject: Re: [EAI] Re: Preliminary copy of the post-Last Call EAI framework draft posted Message-ID: <4BC876B69B7F646FD0D8032E@p3.JCK.COM> In-Reply-To: References: <7D73245C9F1297E78C91A927@[172.19.11.21]> <45C401FB.5A4E@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org FWIW, the document went into the posting queue at 0805 US ET/ 1305 UT this morning, as promised/threatened. As I tried to indicate in my earlier note, the constraints on post-LC changes and the time pressure on getting this out made it impossible to make substantive changes not identified and resolved during Last Call. That constraint applies especially to situations, like this one, in which the comment is "something additional needs to be done" (in this case, adding a definition) but in which there was not time to develop a proposal and get WG consensus on it. john --On Monday, 05 February, 2007 16:44 +0000 Charles Lindsey wrote: > On Sat, 03 Feb 2007 03:31:07 -0000, Frank Ellermann > wrote: > >> Harald Tveit Alvestrand wrote: >> >>> http://www.alvestrand.no/ietf/eai/eai-framework-05b.txt >> >> Hwdiff at - I think it's okay. >> Does the following statement still make sense ? >... > I also spotted this paragraph when chasing something else, and > I observe that we carefully define all the possibilities for > addresses (ASCII, NON-ASCII and UTF8SMTP), but we do not seem > to have defined any terminology for describing messages as > such (apart from that sentence saying "there is no such > thing"). > > And yet we are currently involved in heavy discussions about > how messages of varuious sorts might or might not be handled. > It seems to be the case that the same three types of message >... _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 05 14:02:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE96E-0007Rn-97; Mon, 05 Feb 2007 14:01:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE96D-0007Oa-89 for ima@ietf.org; Mon, 05 Feb 2007 14:01:57 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE968-0008VW-ML for ima@ietf.org; Mon, 05 Feb 2007 14:01:57 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3#clerew^man*ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45c77f1f.28d0.684 for ima@ietf.org; Mon, 5 Feb 2007 19:01:51 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l15J1nRn001199 for ; Mon, 5 Feb 2007 19:01:50 GMT To: IMA Subject: Re: [EAI] Re: for8 References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> Message-ID: Date: Mon, 05 Feb 2007 19:01:49 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 22 Jan 2007 20:41:36 -0000, Randall Gellens wrote: > It seems we have two unpleasant choices: > > 1: Prohibit "for" clauses when the address is non-ASCII. > 2: Alter trace headers when downgrading. > > The basic direction of the group, as I understand it, assumes that mail > systems will fairly rapidly be upgraded to handle UTF8, and tries to > avoid creating short-term kludges which will inevitably live on long > after everyone has upgraded. > > We may be better off with choice 2. Choice 1 means that as systems are > upgraded, "for" clauses vanish. I've found these clauses to be very > helpful when debugging things. +1 -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 05 14:11:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9Fk-0002oG-9w; Mon, 05 Feb 2007 14:11:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9Fj-0002oB-Md for ima@ietf.org; Mon, 05 Feb 2007 14:11:47 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE9Fi-0001VR-4j for ima@ietf.org; Mon, 05 Feb 2007 14:11:47 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3#clerew^man#ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45c78171.18556.4a9 for ima@ietf.org; Mon, 5 Feb 2007 19:11:45 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l15JBiRL001794 for ; Mon, 5 Feb 2007 19:11:44 GMT To: IMA Subject: Re: Header-Type, Mime-Version (Re: [EAI] Status of utf8header draft) References: <458A154A.4090707@twnic.net.tw> <5dmz47bo2p.fsf_-_@leija.fmi.fi> <18502.8610438623$1169782253@news.gmane.org> <5direuh06o.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Mon, 05 Feb 2007 19:11:43 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 02 Feb 2007 08:47:30 -0000, Randall Gellens wrote: > At 6:38 AM +0200 1/26/07, Kari Hurtta wrote: > >> Precense of ALT-ADDRESS does not indicate that headers are UTF-8. >> >> So I disagreed with "isn't needed in that case" part with you. > > What do you gain from the additional extension? It seems to me that you > only get the ability to specify that a client is using non-ASCII > addresses but all-ASCII headers. Yet, the recipient server can't trust > this, so what is the benefit? Kari's proposed HDR=UTF8 was an alternative to the "Header-Type" header (which is now officially dead, though it remains to be seen whether it will lie down :-) ). The alternatives to both of those are scanning the whole message looking for headers which might need to be downgraded (which is indeed robust in the face of headers which you do not trust). However, it is not yet clear how to do such a scan, or whether it is even possible in the face of various strange message/* types. So we just have to hope that the ongoing discussions will find some agreed way to do it. But, for sure, please can we avoid any mention of the ALT-ADDRESS parameters in the envelope as being related to whether the actual message contains utf8headers or not. That would just confuse the issue, because there is no connection there whatsoever. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 05 14:18:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9MI-0007DR-S6; Mon, 05 Feb 2007 14:18:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9MI-0007DI-5e for ima@ietf.org; Mon, 05 Feb 2007 14:18:34 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE9MG-0003HF-JX for ima@ietf.org; Mon, 05 Feb 2007 14:18:33 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3&clerew$man^ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45c78307.3547.1af for ima@ietf.org; Mon, 5 Feb 2007 19:18:31 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l15JIUgK002201 for ; Mon, 5 Feb 2007 19:18:31 GMT To: IMA Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <45BCFD71.6225@xyzzy.claranet.de> <5103A2A292C8E4D9539C0944@[172.19.11.21]> <490765080EC9FB5D03769DBB@[10.71.2.170]> Message-ID: Date: Mon, 05 Feb 2007 19:18:30 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <490765080EC9FB5D03769DBB@[10.71.2.170]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, 04 Feb 2007 21:37:02 -0000, Harald Tveit Alvestrand wrote: > --On 30. januar 2007 17:33 +0000 Charles Lindsey > wrote: >> Many operations, including high quality formatting, text-to-speech >> synthesis, searching, hyphenation, spellchecking and so on benefit >> greatly from access to information about the language of a piece of >> text. [WC 3.1.1.4]. >> >> Which seems to cover the sort of situation that I mentioned. > > And where in that text did you find any justification for assuming that > this information is required for UTF-8 headers and not required for > ASCII headers? Nowhere. My point was that the need for such language information was greater in the case of Non-Ascii texts. Currently, we do not have any mechanism for indicating language in headers beyond the much-disliked RFC 2231. One would hope that one eventual byproduct of our endeavours would be that RFC 2047 and RFC 2231 could eventually be consigned to history. But that would require a Header-Language header (which might then even be useful in pure ASCII messages). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 05 16:28:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEBNt-0003C3-05; Mon, 05 Feb 2007 16:28:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEBNr-0003Aj-EU for ima@ietf.org; Mon, 05 Feb 2007 16:28:19 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEBNb-0005hu-Aj for ima@ietf.org; Mon, 05 Feb 2007 16:28:19 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3*clerew#man&ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45c7a161.11584.3a9 for ima@ietf.org; Mon, 5 Feb 2007 21:28:01 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l15LS0oN009988 for ; Mon, 5 Feb 2007 21:28:01 GMT To: IMA Subject: Re: [EAI] Summary of the "BODY problems" thread(s) References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> <45C63889.6BEB@xyzzy.claranet.de> Message-ID: Date: Mon, 05 Feb 2007 21:27:59 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <45C63889.6BEB@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, 04 Feb 2007 19:48:25 -0000, Frank Ellermann wrote: > Okay, I try a summary of Kari's and my "brain-storming" here > wrt UTF-8 in Content-*: > Therefore we need a way to identify cases, where a message > is a "real" message/utf-8. > > One way to do this is to look at its header, if it's pure > ASCII it's a message/rfc822, if it's valid UTF-8 it's a > message/utf-8. In both cases not necessarily syntactically > valid, but it could be valid. But that simply will not fly. > > If it's anything else ("non-ASCII") it can't be valid, and > we can simply put it in the "invalid message/rfc822" bin. > > Another way to identify it is to parse its complete MIME > structure, its "top" header, and headers of all contained > MIME parts in its body. And I don't see any alternative to that, given that we no longer (it seems) have Header-Type:. > > The "top header only" approach can't work if somewhere in > the nested multipart MIME headers raw UTF-8 is used in a > Content-* including comments (as the first used UTF-8). We have carefully given the impression, in [utf8headers], that (certainly at the top level) you can freely use Utf-8 in comments and unstructured headers (places where hitherto you would have had to use 2047). I think it is clear that this is not restricted to the set of headers defined in RFC 2822. Surely it applies everywhere? Which means that, for those header still defined in terms of RFC 822 (and 822 also allowed comments) you either assume that those comments can now be in UTF-8, or you mentally rewrite the ABNF of those headers into the RFC 2822 style and proceed from there. If you do not do that, then people are going to be utterly confused as to where they can use UTF-8 and where they can't. And for sure, all the Content-* headers come under that. Additionally, some of those |Content-* headers can make use of UTF-8 within parameters, in lieu of the ghastly RFC 2231. So if I can write Content-Description: some utf-8 text in the top level headers, then users are going to find it totally bizarre that they cannot also write it in the headers of individual (multi)parts (where it is arguably much more useful, since you do not have a Subject header available down there, and it would be nice to explain what the immage/jpeg that follows is actually a picture of the "Space Shuttle" , or "Le shuttle d'éspace" -feel free to mend my French). But even if you do not allow it in those body-part headers, you certainly have to allow it within an embedded message/rfc822 or message/utf-8 (whichever it turns out to be), and so you simply cannot avoid that recursive descent scan. > > [end of summary] > > The "parse nested MIME parts" might be difficult, it has > to descend into multipart/* parts, but not into message/*, > and it's apparently an update of MIME. But yes, it DOES have to descend into message/* (or at least some of them, though it is not yet clear which). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 05 16:48:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEBhd-0006RE-Cr; Mon, 05 Feb 2007 16:48:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEBhc-0006Qw-OC for ima@ietf.org; Mon, 05 Feb 2007 16:48:44 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEBhb-00028b-6M for ima@ietf.org; Mon, 05 Feb 2007 16:48:44 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3^clerew#man^ac&uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45c7a639.b029.f for ima@ietf.org; Mon, 5 Feb 2007 21:48:41 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l15LmdnQ011227 for ; Mon, 5 Feb 2007 21:48:41 GMT To: IMA Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> <5dy7nl4ru5.fsf@Hurtta06k.keh.iki.fi> <5dmz401kzo.fsf@Hurtta06k.keh.iki.fi> <5direi6gts.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Mon, 05 Feb 2007 21:48:39 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5direi6gts.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 03 Feb 2007 22:01:51 -0000, Kari Hurtta wrote: NOT on the list (he wrote a similar message to the list, but this version raises more issues) > "Charles Lindsey" writes in gmane.ietf.ima: >> 5. If, in fact, it turns out out that no downgrading was needed at any >> stage, then no change will have been made to the message and no harm >> will have been done, but you will have wasted a bit of time analysing >> the MIME structure as you went throught it; but the imnportant thing >> is that you never had to scan the whole message twice. > > That walking and downgrading need to be done whole before outputting > DATA command to next MTA. This is fine, if you can keep result on > memory. > You will hit on perfomance if you need write it to disk. But, in practice, even my 22MB attachment (30MB after Base64) happily sat in memory while sendmail fiddled with it, and few messages get that big. OTOH, even if you do a separate scan through the message prior to deciding whether it needs to be downgraded anywhere, you still have the problem that it may not still be in memory when you eventually do go back to do the actual downgrade. But I take your point that a separate pre-scan may indeed be necessary, unless you can be sure in advance that your donwgrade cannot fail. > > Sendmail gets away with this by never failing on downgrading (of > 8BITMIME). > That leads that some standard is always violated on message/{unknown} > case :-) Yes, like leaving 8bit stuff around even after downgrading from 8BITMIME :=( . -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 06 13:38:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEVCA-00077d-CC; Tue, 06 Feb 2007 13:37:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEVC9-00077Y-Cc for ima@ietf.org; Tue, 06 Feb 2007 13:37:33 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEVC0-0000ED-1v for ima@ietf.org; Tue, 06 Feb 2007 13:37:33 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HEVBj-0004Us-5V for ima@ietf.org; Tue, 06 Feb 2007 19:37:07 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Feb 2007 19:37:07 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Feb 2007 19:37:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Downgraded: -header field question (Re: [EAI] Re: for8) Date: 06 Feb 2007 20:36:54 +0200 Lines: 46 Message-ID: <5dtzxzrv3t.fsf_-_@Hurtta06k.keh.iki.fi> References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > On Mon, 22 Jan 2007 20:41:36 -0000, Randall Gellens > wrote: > > > It seems we have two unpleasant choices: > > > > 1: Prohibit "for" clauses when the address is non-ASCII. > > 2: Alter trace headers when downgrading. > > > > The basic direction of the group, as I understand it, assumes that > > mail systems will fairly rapidly be upgraded to handle UTF8, and > > tries to avoid creating short-term kludges which will inevitably > > live on long after everyone has upgraded. > > > > We may be better off with choice 2. Choice 1 means that as systems > > are upgraded, "for" clauses vanish. I've found these clauses to be > > very helpful when debugging things. > > +1 I assume that Downgraded: -header field is not trace header. If trace headers is modified, is there also need for correspond downgraded header filed? That makes Trace-Downgraded: -header field. Also for MIME structure there is need to downgraded header field. Because only Content-* is supported on MIME structure, is there need correspond downgraded header filed? That makes Content-Hdr-Downgraded: -header field. > -- > Charles H. Lindsey ---------At Home, doing my own thing------------------------ > Tel: +44 161 436 6131  >    Web: http://www.cs.man.ac.uk/~chl > Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. > PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 06 14:30:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEW1B-0007b5-FL; Tue, 06 Feb 2007 14:30:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEW1A-0007b0-Rx for ima@ietf.org; Tue, 06 Feb 2007 14:30:16 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEW19-0000Ie-Hp for ima@ietf.org; Tue, 06 Feb 2007 14:30:16 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HEW11-0002t3-IJ for ima@ietf.org; Tue, 06 Feb 2007 20:30:07 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Feb 2007 20:30:07 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Feb 2007 20:30:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 06 Feb 2007 21:29:49 +0200 Lines: 24 Message-ID: <5d3b5jhyoi.fsf@Hurtta06k.keh.iki.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [EAI] Messages on original form (Re: I-D ACTION:draft-ietf-eai-imap-utf8-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Question about imap draft. Is there possible to retrieve mail messages on original from ? I think that I missed to something, but it looked like IMAP server do all messages up conversion or down conversion depending of selected access method. What I have looked for is: 1) UTF8SMTP messages are returned UTF8SMTP form 2) Downgraded UTF8SMTP messages are returned UTF8SMTP form (ie. selective up conversion) 3) Non-UTF8SMTP messages are returned on RFC (2)822 from (ie. no up conversion) That is import for signed messages, I think. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 06 14:39:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEWA4-0003E3-Am; Tue, 06 Feb 2007 14:39:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEWA3-0003Dy-Nj for ima@ietf.org; Tue, 06 Feb 2007 14:39:27 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEWA2-0003aH-BE for ima@ietf.org; Tue, 06 Feb 2007 14:39:27 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HEWA1-000PAr-Vx; Tue, 06 Feb 2007 14:39:26 -0500 Date: Tue, 06 Feb 2007 14:39:25 -0500 From: John C Klensin To: Kari Hurtta , ima@ietf.org Message-ID: <20A029D5B7CB390EA6489B21@p3.JCK.COM> In-Reply-To: <5dtzxzrv3t.fsf_-_@Hurtta06k.keh.iki.fi> References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <5dtzxzrv3t.fsf_-_@Hurtta06k.keh.iki.fi> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: [EAI] Tracing 'for' through downgrades (was: Re: Downgraded: -header field question (Re: Re: for8)) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 06 February, 2007 20:36 +0200 Kari Hurtta wrote: >> > We may be better off with choice 2. Choice 1 means that as >> > systems are upgraded, "for" clauses vanish. I've found >> > these clauses to be very helpful when debugging things. >> >> +1 > > I assume that Downgraded: -header field is not trace header. > > > If trace headers is modified, is there also need for correspond > downgraded header filed? > > That makes Trace-Downgraded: -header field. One could do it that way, but it really adds a lot of clutter with little payoff. I would think that we would do something closer to what has been preferred for gateways. In other words, the downgrading machine inserts one or more standard Received fields that contain the relevant information. For example, one might have Received: from mumble.xyz by mumble.xyz with esmtp id 1HED2M-000I6F-JH for alt-address@alt-domain; Mon, 31 Feb 2008 18:14:35 -0200 (downgraded from utf8address, previous 'for' clauses deleted) Received: from foo.bar.baz by mumble.xyz with UTF8SMTP id 1HED2M-000I6F-JH; Mon, 31 Feb 2008 18:14:15 -0200 I don't think there is an problem figuring out what happened there. And there is zero new syntax to deal with, pin down, and worry about. Design suggestion (personal opinion): every new header and new variation on a header, has costs and introduces more risks of interoperability problems and general bad behavior. If we need new headers, let's design them carefully and do it. But "new header" should be the last resort, not the default answer to almost any question. That principle is particularly important when downgrading is involved because we need to understand that, regardless of whether we get information through a new header or field as documentation for the receiving user, the chances are high that a legacy MUA or MTA that knows nothing about our extensions will, at best, ignore and possibly delete or trash precisely the headers we are trying to invent to help people out. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 07 07:06:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HElZL-0004JE-80; Wed, 07 Feb 2007 07:06:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HElZJ-0004J6-Kf for ima@ietf.org; Wed, 07 Feb 2007 07:06:33 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HElZF-0007t1-Vt for ima@ietf.org; Wed, 07 Feb 2007 07:06:33 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3$clerew&man*ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45c9c0c4.7155.2bb6 for ima@ietf.org; Wed, 7 Feb 2007 12:06:28 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l17C6RRx011023 for ; Wed, 7 Feb 2007 12:06:28 GMT To: IMA Subject: Re: Downgraded: -header field question (Re: [EAI] Re: for8) References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <5dtzxzrv3t.fsf_-_@Hurtta06k.keh.iki.fi> Message-ID: Date: Wed, 07 Feb 2007 12:06:26 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5dtzxzrv3t.fsf_-_@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 06 Feb 2007 18:36:54 -0000, Kari Hurtta wrote: > I assume that Downgraded: -header field is not trace header. It was not planned as such, and newly invented trace headers are unlikely to be widely recognized for years to come (DKIM have tried it, but with not much expectation that it will work). The Downgraded header is provided primarly so that the opriginal header is preserved and can even be restored if/when the message is upgraded. It is also available for tracing purposes by those who can be bothered to look for it. But it is not the end of the world even if it gets thrown away by some over-zealous intermediate agent. But I like John's suggestion that downgraders should be encouraged to record the fact within a Received header (and the Downgrade draft should recommend this). But the Downgraded headers will still be needed for their original purpose. > Also for MIME structure there is need to downgraded header field. > Because only Content-* is supported on MIME structure, is there > need correspond downgraded header filed? I doubt that many existing agents actually worry if they see a non-Content-* header in these positions, and as I already said, it is not the end of the world if one of these occasionally gets lost. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 07 08:11:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEmZd-0001QD-0m; Wed, 07 Feb 2007 08:10:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEmZb-0001Q6-3Q for ima@ietf.org; Wed, 07 Feb 2007 08:10:55 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEmZZ-0001SU-Qf for ima@ietf.org; Wed, 07 Feb 2007 08:10:55 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HEmZZ-0005cN-2D; Wed, 07 Feb 2007 08:10:53 -0500 Date: Wed, 07 Feb 2007 08:10:49 -0500 From: John C Klensin To: Charles Lindsey , IMA Subject: Re: Downgraded: -header field question (Re: [EAI] Re: for8) Message-ID: <9C6128C90D272B22916D249D@p3.JCK.COM> In-Reply-To: References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <5dtzxzrv3t.fsf_-_@Hurtta06k.keh.iki.fi> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 07 February, 2007 12:06 +0000 Charles Lindsey wrote: >... > But I like John's suggestion that downgraders should be > encouraged to record the fact within a Received header (and > the Downgrade draft should recommend this). But the Downgraded > headers will still be needed for their original purpose. To be sure we are clear about the suggestion, the Downgraded headers are either needed or they are not (no comment in this note). The Received header change is built upon another principle, which is that systems that change messages in transit should record that fact. The two suggestions are largely independent of each other. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 07 15:51:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtl6-0005Iy-7J; Wed, 07 Feb 2007 15:51:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtkR-0003df-5u; Wed, 07 Feb 2007 15:50:35 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HEtkO-0002bE-Lh; Wed, 07 Feb 2007 15:50:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 9385E2ACA2; Wed, 7 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HEtju-0001aK-AA; Wed, 07 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-framework-05.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Overview and Framework for Internationalized Email Author(s) : J. Klensin, Y. Ko Filename : draft-ietf-eai-framework-05.txt Pages : 23 Date : 2007-2-7 Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of document set also includes discussion of key assumptions and issues in deploying fully internationalized email. email header syntax to accommodate UTF-8 data. The A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-framework-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-framework-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-7104745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-framework-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-framework-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-7104745.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Thu Feb 08 02:43:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF3wH-0000k2-J3; Thu, 08 Feb 2007 02:43:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF3wG-0000js-GL for ima@ietf.org; Thu, 08 Feb 2007 02:43:28 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF3wF-0000Lm-5u for ima@ietf.org; Thu, 08 Feb 2007 02:43:28 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l187hP4F001828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Feb 2007 23:43:26 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-9.qualcomm.com [10.50.0.9]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l187hOkK030809; Wed, 7 Feb 2007 23:43:25 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <45BB7797.2F3A@xyzzy.claranet.de> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <0EC11DC943D20065F77334C3@[10.0.1.3]> <45BB7797.2F3A@xyzzy.claranet.de> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 7 Feb 2007 23:42:00 -0800 To: Frank Ellermann , ima@ietf.org From: Randall Gellens Subject: Re: mbox & digests (was: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.6 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 5:02 PM +0100 1/27/07, Frank Ellermann wrote: > Chris Newman wrote: > >> A mbox-style file which contains UTF8SMTP messages would be a different >> file format from today's mbox format. There are multiple ways to >> distinguish the two file formats, including by file extension, > [...] >> A final delivery agent which put a UTF8SMTP message in a vanilla mbox >> file would have a software bug that needs to be corrected. > > Yes, and that's an important statement, we've to make sure that the > affected drafts (e.g., maybe the mailinglist I-D wrt "digest mode") > clearly say so. mailinglist -01 doesn't mention digests, and if it did, I think it would discuss MIME multiparts and not mbox format. I do think the POP and IMAP drafts might want to mention it. Perhaps the mailinglist draft, in a parenthetical aside about list agents that read from mbox format files. Also perhaps, the SMTP extension document might have an aside about final delivery to vanilla mbox spools. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Note that although IBM 'invented' virtual memory in 1972 it had been available in a multi-processor multi-tasking environment on the Burroughs B5000 line since 1963 and the B6000 line since 1968. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 02:54:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF472-0006T8-EL; Thu, 08 Feb 2007 02:54:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF471-0006T3-Vq for ima@ietf.org; Thu, 08 Feb 2007 02:54:35 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF46v-00048F-FP for ima@ietf.org; Thu, 08 Feb 2007 02:54:35 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AAB962596CA; Thu, 8 Feb 2007 08:50:16 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00799-06; Thu, 8 Feb 2007 08:50:09 +0100 (CET) Received: from [10.71.2.170] (unknown [89.202.240.63]) by eikenes.alvestrand.no (Postfix) with ESMTP id BEB0E2596D2; Thu, 8 Feb 2007 08:50:07 +0100 (CET) Date: Wed, 07 Feb 2007 15:12:13 -0800 From: Harald Tveit Alvestrand To: Charles Lindsey , IMA Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Message-ID: In-Reply-To: References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <45BCFD71.6225@xyzzy.claranet.de> <5103A2A292C8E4D9539C0944@[172.19.11.21]> <490765080EC9FB5D03769DBB@[10.71.2.170]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 5. februar 2007 19:18 +0000 Charles Lindsey wrote: > On Sun, 04 Feb 2007 21:37:02 -0000, Harald Tveit Alvestrand > wrote: > >> --On 30. januar 2007 17:33 +0000 Charles Lindsey >> wrote: > >>> Many operations, including high quality formatting, text-to-speech >>> synthesis, searching, hyphenation, spellchecking and so on benefit >>> greatly from access to information about the language of a piece of >>> text. [WC 3.1.1.4]. >>> >>> Which seems to cover the sort of situation that I mentioned. >> >> And where in that text did you find any justification for assuming that >> this information is required for UTF-8 headers and not required for >> ASCII headers? > > Nowhere. My point was that the need for such language information was > greater in the case of Non-Ascii texts. Good, then we have made it sufficiently clear that the RFC you are citing gives no backing for such a claim, and the claim is entirely your own. I, for one, don't believe it. > Currently, we do not have any > mechanism for indicating language in headers beyond the much-disliked RFC > 2231. One would hope that one eventual byproduct of our endeavours would > be that RFC 2047 and RFC 2231 could eventually be consigned to history. > But that would require a Header-Language header (which might then even be > useful in pure ASCII messages). Actually, the semantics of 2231 may have the right level of granularity. If I reply to a message, and the reply passes through a mailing list, the subject line will be in a language chosen by the original sender, the free-form text part of my email address will be in a language chosen by me, and the List-* headers will be in a language chosen by the list maintainer. But (speaking with my charter-guardian chair cap firmly pulled down over my ears) I believe you have sufficiently demonstrated that the need for "header-language" is an orthogonal issue to what EAI is trying to solve, and is therefore off-charter for this group. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 03:23:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4ZI-0002sk-Ox; Thu, 08 Feb 2007 03:23:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4ZG-0002s6-JF for ima@ietf.org; Thu, 08 Feb 2007 03:23:46 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF4ZE-0005e2-8E for ima@ietf.org; Thu, 08 Feb 2007 03:23:46 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l188Ndn6020079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Feb 2007 00:23:40 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-9.qualcomm.com [10.50.0.9]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l188NQKo003703; Thu, 8 Feb 2007 00:23:38 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <27BF69182779DF65C1BE3B40@[172.19.11.21]> References: <20070129100855.GB30318@ns5.lsb.org> <27BF69182779DF65C1BE3B40@[172.19.11.21]> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 8 Feb 2007 00:17:13 -0800 To: Harald Tveit Alvestrand , Soobok Lee , ima@ietf.org From: Randall Gellens Subject: Re: [EAI] other thought about > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 7:37 PM -0800 1/29/07, Harald Tveit Alvestrand wrote: >> 13) To: eai@address <----- >> 14) To: eai@address [ascii@address] >> 15) To: eai@address >> 16) To: > > I'm happy with not allowing cases 13 and 15 in the UTF8SMTP ABNF. > > Let the nonconformant UTF8SMTP UA implementations fail as they may. I agree. I don't see the use in perpetuating a potentially ambiguous syntax given that only upgraded software will be capable of generating/parsing UTF8 addresses anyway. Why not take the opportunity to require the angle brackets? (It might be useful to keep in mind that originally, even the "@" was not required, and " at " could be used instead. Tightening the syntax can be a good thing.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- It takes a wonderful brain and exquisite senses to produce a few stupid ideas. --Santayana _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 03:23:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4ZF-0002s0-Ks; Thu, 08 Feb 2007 03:23:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4ZE-0002rv-LU for ima@ietf.org; Thu, 08 Feb 2007 03:23:44 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF4ZD-0005dt-BJ for ima@ietf.org; Thu, 08 Feb 2007 03:23:44 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5From ima-bounces@ietf.org Thu Feb 08 03:23:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4ZI-0002sk-Ox; Thu, 08 Feb 2007 03:23:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4ZG-0002s6-JF for ima@ietf.org; Thu, 08 Feb 2007 03:23:46 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF4ZE-0005e2-8E for ima@ietf.org; Thu, 08 Feb 2007 03:23:46 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l188Ndn6020079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Feb 2007 00:23:40 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-9.qualcomm.com [10.50.0.9]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l188NQKo003703; Thu, 8 Feb 2007 00:23:38 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <27BF69182779DF65C1BE3B40@[172.19.11.21]> References: <20070129100855.GB30318@ns5.lsb.org> <27BF69182779DF65C1BE3B40@[172.19.11.21]> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 8 Feb 2007 00:17:13 -0800 To: Harald Tveit Alvestrand , Soobok Lee , ima@ietf.org From: Randall Gellens Subject: Re: [EAI] other thought about > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 7:37 PM -0800 1/29/07, Harald Tveit Alvestrand wrote: >> 13) To: eai@address <----- >> 14) To: eai@address [ascii@address] >> 15) To: eai@address >> 16) To: > > I'm happy with not allowing cases 13 and 15 in the UTF8SMTP ABNF. > > Let the nonconformant UTF8SMTP UA implementations fail as they may. I agree. I don't see the use in perpetuating a potentially ambiguous syntax given that only upgraded software will be capable of generating/parsing UTF8 addresses anyway. Why not take the opportunity to require the angle brackets? (It might be useful to keep in mind that originally, even the "@" was not required, and " at " could be used instead. Tightening the syntax can be a good thing.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- It takes a wonderful brain and exquisite senses to produce a few stupid ideas. --Santayana _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 03:23:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4ZF-0002s0-Ks; Thu, 08 Feb 2007 03:23:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4ZE-0002rv-LU for ima@ietf.org; Thu, 08 Feb 2007 03:23:44 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF4ZD-0005dt-BJ for ima@ietf.org; Thu, 08 Feb 2007 03:23:44 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l188Nc9O007700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Feb 2007 00:23:38 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-9.qualcomm.com [10.50.0.9]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l188NQKm003703; Thu, 8 Feb 2007 00:23:32 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <3D816681DA860388277BBD70@p3.JCK.COM> References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <66B5502F24092DF658DA31DF@p3.JCK.COM> <3D816681DA860388277BBD70@p3.JCK.COM> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 8 Feb 2007 00:22:11 -0800 To: John C Klensin , Charles Lindsey , IMA From: Randall Gellens Subject: Re: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft)) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.6 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 5:52 PM -0500 1/26/07, John C Klensin wrote: > Either they will get sorted out > at the right times, or the presence of DKIM signatures will be > taken in practice to encourage message rejection rather than > downgrading, or users (and MSAs) will end up with a choice > between internationalized email and DKIM. Given the presumption that delivery paths between I18n mail users will tend to be upgraded to be UTF8SMTP compatible, the choice between I18n and DKIM is likely to be a temporary one. Taking the presence of DKIM signatures to be an indication that, when needed, messages should be rejected rather than downgraded is perhaps another argument in favor of the requeue-and-retry-later technique when the next hop doesn't support UTF8SMTP. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Spotted on the back of a t-shirt worn by LAPD Bomb Squad: "If you see me running, try to keep up." _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima /1.0) with ESMTP id l188Nc9O007700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Feb 2007 00:23:38 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-9.qualcomm.com [10.50.0.9]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l188NQKm003703; Thu, 8 Feb 2007 00:23:32 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <3D816681DA860388277BBD70@p3.JCK.COM> References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <66B5502F24092DF658DA31DF@p3.JCK.COM> <3D816681DA860388277BBD70@p3.JCK.COM> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 8 Feb 2007 00:22:11 -0800 To: John C Klensin , Charles Lindsey , IMA From: Randall Gellens Subject: Re: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft)) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.6 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 5:52 PM -0500 1/26/07, John C Klensin wrote: > Either they will get sorted out > at the right times, or the presence of DKIM signatures will be > taken in practice to encourage message rejection rather than > downgrading, or users (and MSAs) will end up with a choice > between internationalized email and DKIM. Given the presumption that delivery paths between I18n mail users will tend to be upgraded to be UTF8SMTP compatible, the choice between I18n and DKIM is likely to be a temporary one. Taking the presence of DKIM signatures to be an indication that, when needed, messages should be rejected rather than downgraded is perhaps another argument in favor of the requeue-and-retry-later technique when the next hop doesn't support UTF8SMTP. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Spotted on the back of a t-shirt worn by LAPD Bomb Squad: "If you see me running, try to keep up." _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 03:23:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4ZN-0002xO-4D; Thu, 08 Feb 2007 03:23:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4ZL-0002t5-L1 for ima@ietf.org; Thu, 08 Feb 2007 03:23:51 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF4ZK-0005eD-Ap for ima@ietf.org; Thu, 08 Feb 2007 03:23:51 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l188NhwG007712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Feb 2007 00:23:43 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-9.qualcomm.com [10.50.0.9]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l188NQKq003703; Thu, 8 Feb 2007 00:23:40 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <7518047A15D398D1797627E5@p3.JCK.COM> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 8 Feb 2007 00:17:07 -0800 To: John C Klensin , Soobok Lee , Charles Lindsey From: Randall Gellens Subject: Re: [EAI] other thought about > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 6:45 PM -0500 1/30/07, John C Klensin wrote: > Sigh. Quotation marks have never been required, or even > recommended in that case. For your amusement, the exact rule is > the reason why I stopped using a period after the "C" in "John C > Klensin", which doesn't use quotation marks either. I suggest > that you might find reading the specification useful. We tried very hard in DRUMS to permit unquoted dots in phrases! After all, no one likes to see his or her name in sneer quotes. Too bad we couldn't find a way to do so. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Get your facts first, and then you can distort them as much as you please. --Mark Twain _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 03:49:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4yE-0007kK-Sp; Thu, 08 Feb 2007 03:49:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF4yC-0007eL-PT for ima@ietf.org; Thu, 08 Feb 2007 03:49:32 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF4yB-00041K-Ex for ima@ietf.org; Thu, 08 Feb 2007 03:49:32 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l188nTKl010760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Feb 2007 00:49:30 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-9.qualcomm.com [10.50.0.9]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l188nQF3003712; Thu, 8 Feb 2007 00:49:29 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <5dtzy94pgl.fsf@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d7iv8zu7k.fsf@Hurtta06k.keh.iki.fi> <5dd550by0t.fsf_-_@Hurtta06k.keh.iki.fi> <5dtzy94pgl.fsf@Hurtta06k.keh.iki.fi> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 8 Feb 2007 00:41:48 -0800 To: Kari Hurtta , ima@ietf.org From: Randall Gellens Subject: Re: required-fields (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 9:12 PM +0200 1/29/07, Kari Hurtta wrote: > > Please sunnarize again what the UTF8-required-fields would do. >> > > Downgrade needs able to delete headers (when it do not > know syntax of headers). Content of these headers are > stored to some encapsulation format (for example Downgraded > -header). > > These headers may be necessary for some protocols. > That header field makes possible to sender specify that. > > UTF8-required-fields sets requirements, which header fields > downgrading process must know. It says that these headers > must exists even when message is on downgraded form. Is the intent to force the presence of headers listed as being required even when they contained non-ASCII and were hence removed during downgrade? Or is it to force bounce instead of downgrade when headers listed as being required contain non-ASCII? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- It is impossible to make anything foolproof because fools are so ingenious. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 04:04:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF5CO-0008VR-6K; Thu, 08 Feb 2007 04:04:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF5CM-0008VJ-V0 for ima@ietf.org; Thu, 08 Feb 2007 04:04:10 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF5CL-0008Im-Kf for ima@ietf.org; Thu, 08 Feb 2007 04:04:10 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l1892V2P012247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Feb 2007 01:02:32 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-9.qualcomm.com [10.50.0.9]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1892T92015027; Thu, 8 Feb 2007 01:02:31 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <45C05399.8060103@twnic.net.tw> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 8 Feb 2007 00:59:23 -0800 To: Jeff Yeh , Charles Lindsey From: Randall Gellens Subject: Re: [EAI] other thought about > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 4:30 PM +0800 1/31/07, Jeff Yeh wrote: >>>> >13) To: eai@address <----- >>>> >15) To: eai@address > Speak as the editor of utf8header, my intension is not to allow 13 > and 15. As discussed in previous posts, I think it makes sense that > 15 is allowed as we use ascii@address right now. Sorry, for being confused. Do you want to allow or disallow unbracketed UTF8 addresses? I say let's ban them. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The curse of all Art is that the devotee or disciple is always more certain than the Priest. --Rudyard Kipling _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 05:45:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF6m2-0006Lz-Uk; Thu, 08 Feb 2007 05:45:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF6m2-0006IK-1g for ima@ietf.org; Thu, 08 Feb 2007 05:45:06 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF6lH-0004IW-UI for ima@ietf.org; Thu, 08 Feb 2007 05:44:22 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HF6l9-000Dmb-6e; Thu, 08 Feb 2007 05:44:11 -0500 Date: Thu, 08 Feb 2007 05:44:09 -0500 From: John C Klensin To: Randall Gellens , Jeff Yeh , Charles Lindsey Subject: Re: [EAI] other thought about > Message-ID: <8EF038A6C37EE47F7977B22C@p3.JCK.COM> In-Reply-To: References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 08 February, 2007 00:59 -0800 Randall Gellens wrote: > At 4:30 PM +0800 1/31/07, Jeff Yeh wrote: > >>>>> > 13) To: eai@address <----- > >>>>> > 15) To: eai@address > >> Speak as the editor of utf8header, my intension is not to >> allow 13 and 15. As discussed in previous posts, I think it >> makes sense that 15 is allowed as we use ascii@address right >> now. > > Sorry, for being confused. Do you want to allow or disallow > unbracketed UTF8 addresses? > > I say let's ban them. While I would _strongly_ prefer to permit them as long as there is no display name field, I think permitting them would force us to deal with a whole series of other issues about characters that may or may not be the same as others and what they would do to parsers. Since that long list of cases has completely confused me, and probably some others, about some of what we are talking about, what I am recommending/ would prefer is: (a) Any Mailbox or uMailbox (in the strict definitions of 2821 and eai-smtpext, respectively) that contains any non-ASCII character(s) MUST appear in brackets. (b) Any display-name (in the strict definition of 2822) that contains any non-ASCII character(s) MUST have the entire phrase (2822 definition) in quotes and follow 2822's rules about quoted phrases, including the rules for embedded quotes. Again, I don't really like this, but I the alternatives seem to lead to bad cases and perhaps even some attack vectors. Tedious explanations and examples on request, but anyone who asks had better be ready to understand Unicode normalization and the different places at which it can be applied. And, before we go down that rathole again, the above definitions apply to the forms of headers the go on the wire. What the user interface of an MUA decides to permit on input or display is Someone Else's Problem, as long as they get the "wire" form correct as specified above. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 07:18:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF8E5-0003BX-TS; Thu, 08 Feb 2007 07:18:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF8BG-0002N2-5N for ima@ietf.org; Thu, 08 Feb 2007 07:15:14 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HF872-0002Rq-6X for ima@ietf.org; Thu, 08 Feb 2007 07:10:53 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HF86k-000EVy-H7; Thu, 08 Feb 2007 07:10:34 -0500 Date: Thu, 08 Feb 2007 07:10:33 -0500 From: John C Klensin To: Randall Gellens , Charles Lindsey , IMA Subject: Re: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft)) Message-ID: In-Reply-To: References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <66B5502F24092DF658DA31DF@p3.JCK.COM> <3D816681DA860388277BBD70@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 08 February, 2007 00:22 -0800 Randall Gellens wrote: > At 5:52 PM -0500 1/26/07, John C Klensin wrote: > >> Either they will get sorted out >> at the right times, or the presence of DKIM signatures will >> be taken in practice to encourage message rejection rather >> than downgrading, or users (and MSAs) will end up with a >> choice between internationalized email and DKIM. > > Given the presumption that delivery paths between I18n mail > users will tend to be upgraded to be UTF8SMTP compatible, the > choice between I18n and DKIM is likely to be a temporary one. > Taking the presence of DKIM signatures to be an indication > that, when needed, messages should be rejected rather than > downgraded is perhaps another argument in favor of the > requeue-and-retry-later technique when the next hop doesn't > support UTF8SMTP. Agreed. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 07:41:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF8ap-0006Sf-KH; Thu, 08 Feb 2007 07:41:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF8an-0006RZ-KC for ima@ietf.org; Thu, 08 Feb 2007 07:41:37 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF8ak-0003ML-Ur for ima@ietf.org; Thu, 08 Feb 2007 07:41:37 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l18CfMJ5026031; Thu, 8 Feb 2007 21:41:22 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l18CfMvV026030; Thu, 8 Feb 2007 21:41:22 +0900 Date: Thu, 8 Feb 2007 21:41:22 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] other thought about > Message-ID: <20070208124121.GL19841@ns5.lsb.org> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> <8EF038A6C37EE47F7977B22C@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8EF038A6C37EE47F7977B22C@p3.JCK.COM> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Randall Gellens , Charles Lindsey , IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Feb 08, 2007 at 05:44:09AM -0500, John C Klensin wrote: > (a) Any Mailbox or uMailbox (in the strict definitions > of 2821 and eai-smtpext, respectively) that contains any > non-ASCII character(s) MUST appear in brackets. Here is a peculiar email address example worth to consider and leave in this list: To: , The string between first "<" and "@evil.tld>" is the single valid local-part if: First @ is U+FE6B or U+FF20, not U+0040 Second @ is U+0040 First , is U+FE50 or U+FF0C, not U+002C First < is U+003E First > is U+FF1E or U+FE65, not U+003E Second < is U+FF1C or U+FE64, not U+003C Second > is U+003E (compatability characters homographs) http://www.unicode.org/charts/PDF/UFE50.pdf http://www.unicode.org/charts/PDF/UFF00.pdf To: (after replacing all compatability chars with hyphens) In EAI, utf8-local-part's utf8-dot-atom (and quoted-string) has NO restriction on non-ascii characters at all. Should we prohibit all these compatability characters of ASCII punctuations ,:;[]<>()@ in utf8-local-part ? utf8-addr-spec = utf8-local-part "@" utf8-domain utf8-local-part= utf8-dot-atom / quoted-string / obs-local-part utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS] utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext) utf8-atom = [CFWS] 1*utf8-atext [CFWS] utf8-atext = ALPHA / DIGIT / "!" / "#" / ; Any character except "$" / "%" / ; controls, SP, and specials. "&" / "'" / ; Used for atoms "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / UTF8-xtra-char Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 08:00:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF8sm-0007HF-J1; Thu, 08 Feb 2007 08:00:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF8sg-0007CQ-WB for ima@ietf.org; Thu, 08 Feb 2007 08:00:07 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF8px-0007Dv-Lc for ima@ietf.org; Thu, 08 Feb 2007 07:57:20 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l18Cv6J5027960; Thu, 8 Feb 2007 21:57:07 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l18Cv6IU027959; Thu, 8 Feb 2007 21:57:06 +0900 Date: Thu, 8 Feb 2007 21:57:06 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] other thought about > Message-ID: <20070208125706.GM19841@ns5.lsb.org> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> <8EF038A6C37EE47F7977B22C@p3.JCK.COM> <20070208124121.GL19841@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070208124121.GL19841@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Randall Gellens , Charles Lindsey , IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Feb 08, 2007 at 09:41:22PM +0900, Soobok Lee wrote: > On Thu, Feb 08, 2007 at 05:44:09AM -0500, John C Klensin wrote: > > (a) Any Mailbox or uMailbox (in the strict definitions > > of 2821 and eai-smtpext, respectively) that contains any > > non-ASCII character(s) MUST appear in brackets. > > Here is a peculiar email address example worth to consider > and leave in this list: > > To: , > > The string between first "<" and "@evil.tld>" is > the single valid local-part if: > > First @ is U+FE6B or U+FF20, not U+0040 > Second @ is U+0040 > First , is U+FE50 or U+FF0C, not U+002C > First < is U+003E [correct] First < is U+003C [add] First . is U+FF0E or U+FE52, not U+002E > First > is U+FF1E or U+FE65, not U+003E > Second < is U+FF1C or U+FE64, not U+003C > Second > is U+003E > > (compatability characters homographs) > http://www.unicode.org/charts/PDF/UFE50.pdf > http://www.unicode.org/charts/PDF/UFF00.pdf > > To: > > (after replacing all compatability chars with hyphens) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 10:25:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFB9W-0003CX-27; Thu, 08 Feb 2007 10:25:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFB9U-0003A8-2g for ima@ietf.org; Thu, 08 Feb 2007 10:25:36 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFB9Q-0003t1-67 for ima@ietf.org; Thu, 08 Feb 2007 10:25:36 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HFB99-00035U-MK for ima@ietf.org; Thu, 08 Feb 2007 16:25:15 +0100 Received: from d255075.dialin.hansenet.de ([80.171.255.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Feb 2007 16:25:15 +0100 Received: from nobody by d255075.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Feb 2007 16:25:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Thu, 08 Feb 2007 16:23:34 +0100 Organization: Lines: 21 Message-ID: <45CB4076.103@xyzzy.claranet.de> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> <8EF038A6C37EE47F7977B22C@p3.JCK.COM> <20070208124121.GL19841@ns5.lsb.org> 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: d255075.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [EAI] Re: other thought about > X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Soobok Lee wrote: > Here is a peculiar email address example worth to consider > and leave in this list: > To: , All combinations from to with , , , , , , , . "Nice" example for the security considerations. But it doesn't affect John's proposals a + b. Or do you want more radical rules like NFKC or SASLprep ? Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 10:35:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFBJO-0008M8-6h; Thu, 08 Feb 2007 10:35:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFBJG-0008L9-Er for ima@ietf.org; Thu, 08 Feb 2007 10:35:43 -0500 Received: from ppsw-4.csi.cam.ac.uk ([131.111.8.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFBJB-0006Wu-Ss for ima@ietf.org; Thu, 08 Feb 2007 10:35:42 -0500 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-1.csi.cam.ac.uk ([131.111.8.51]:45863) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1HFBHV-0000mK-EB (Exim 4.63) (return-path ); Thu, 08 Feb 2007 15:33:53 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HFBHV-0006dK-Be (Exim 4.54) (return-path ); Thu, 08 Feb 2007 15:33:53 +0000 Date: Thu, 8 Feb 2007 15:33:53 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Soobok Lee Subject: Re: [EAI] other thought about > In-Reply-To: <20070208124121.GL19841@ns5.lsb.org> Message-ID: References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> <8EF038A6C37EE47F7977B22C@p3.JCK.COM> <20070208124121.GL19841@ns5.lsb.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Randall Gellens , Charles Lindsey , IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 8 Feb 2007, Soobok Lee wrote: > > Here is a peculiar email address example worth to consider > and leave in this list: Note that the addresses in the message header do not have to relate to the addresses in the message envelope, so spoofing attacks similar to yours are trivial without i18n. Tony. -- f.a.n.finch http://dotat.at/ FORTIES CROMARTY: EAST VEERING SOUTHEAST 5 OR 6, OCCASIONALLY 7, PERHAPS GALE 8 LATER. MODERATE OR ROUGH. SNOW SHOWERS. GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 10:43:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFBQz-0004yG-FC; Thu, 08 Feb 2007 10:43:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFBQx-0004y7-43 for ima@ietf.org; Thu, 08 Feb 2007 10:43:39 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFBQv-0000GJ-R5 for ima@ietf.org; Thu, 08 Feb 2007 10:43:39 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HFBQi-0006Wn-5Q for ima@ietf.org; Thu, 08 Feb 2007 16:43:24 +0100 Received: from d255075.dialin.hansenet.de ([80.171.255.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Feb 2007 16:43:23 +0100 Received: from nobody by d255075.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Feb 2007 16:43:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Antidot (was: [EAI] other thought about >) Date: Thu, 08 Feb 2007 16:42:05 +0100 Organization: Lines: 16 Message-ID: <45CB44CD.7B3F@xyzzy.claranet.de> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <23409.0294725776$1170923049@news.gmane.org> 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: d255075.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Randall Gellens wrote: > We tried very hard in DRUMS to permit unquoted dots in phrases I tried very hard to get rid of this idiosyncrasy in USEFOR, but it's now one of two "acceptable" (MUST accept, MUST NOT generate) obs-cenities adopted from RFC 2822... No leading, trailing, or adjacent dots as THE LAW is already odd. But adding an exception from this syntax only for the US middle initials or the DE title abbreviations is really weird, it has side effects for stuff like phrases in a Keywords header field. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 08 11:03:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFBkE-00079B-1C; Thu, 08 Feb 2007 11:03:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFBkD-000793-Jn for ima@ietf.org; Thu, 08 Feb 2007 11:03:33 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFBk8-0005dN-9t for ima@ietf.org; Thu, 08 Feb 2007 11:03:33 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HFBk1-00028B-Q0 for ima@ietf.org; Thu, 08 Feb 2007 17:03:21 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Feb 2007 17:03:21 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Feb 2007 17:03:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 08 Feb 2007 18:02:59 +0200 Lines: 34 Message-ID: <5dwt2sljrg.fsf@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d7iv8zu7k.fsf@Hurtta06k.keh.iki.fi> <5dd550by0t.fsf_-_@Hurtta06k.keh.iki.fi> <5dtzy94pgl.fsf@Hurtta06k.keh.iki.fi> <16536.4005639733$1170924595@news.gmane.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [EAI] Re: required-fields (Re: CONSENSUS CALL: Removal of Header-Format: marker) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Randall Gellens writes in gmane.ietf.ima: > At 9:12 PM +0200 1/29/07, Kari Hurtta wrote: > > > > Please sunnarize again what the UTF8-required-fields would do. > >> > > > > Downgrade needs able to delete headers (when it do not > > know syntax of headers). Content of these headers are > > stored to some encapsulation format (for example Downgraded > > -header). > > > > These headers may be necessary for some protocols. > > That header field makes possible to sender specify that. > > > > UTF8-required-fields sets requirements, which header fields > > downgrading process must know. It says that these headers > > must exists even when message is on downgraded form. > > Is the intent to force the presence of headers listed as being > required even when they contained non-ASCII and were hence removed > during downgrade? Or is it to force bounce instead of downgrade when > headers listed as being required contain non-ASCII? Force bounce when headers listed as being required contains non-ASCII and downgrading is not available (Downgraded: -header field is encapsulation and do not qualify. ) Sender do not know which all header syntax downgrading gateway knows, but it knowns protocol which it is using for signaling. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 09 06:12:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFTfe-0003Fa-TH; Fri, 09 Feb 2007 06:12:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFTfd-0003FH-O3 for ima@ietf.org; Fri, 09 Feb 2007 06:12:01 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFTfb-0004Jc-KZ for ima@ietf.org; Fri, 09 Feb 2007 06:12:01 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l19BBqJ5030174; Fri, 9 Feb 2007 20:11:52 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l19BBpiB030172; Fri, 9 Feb 2007 20:11:51 +0900 Date: Fri, 9 Feb 2007 20:11:51 +0900 From: Soobok Lee To: Frank Ellermann Subject: Re: [EAI] Re: other thought about > Message-ID: <20070209111151.GO19841@ns5.lsb.org> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> <8EF038A6C37EE47F7977B22C@p3.JCK.COM> <20070208124121.GL19841@ns5.lsb.org> <45CB4076.103@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45CB4076.103@xyzzy.claranet.de> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, Feb 08, 2007 at 04:23:34PM +0100, Frank Ellermann wrote: > > "Nice" example for the security considerations. But it doesn't > affect John's proposals a + b. Or do you want more radical rules > like NFKC or SASLprep ? What I tried to point out is that requiring <> don't guarantee more "safety". Instead of requiring <>, we can prohibit ,:;[]()<>@\" and their NFKC-equivalents in local-part explictly in [utf8headers]. There are many other look-alikes that are not their NFKC-equivalents, but let's ignore them here, and accept this as a cost. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 09 09:59:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXEF-00065H-L5; Fri, 09 Feb 2007 09:59:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXED-000654-Gt for ima@ietf.org; Fri, 09 Feb 2007 09:59:57 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFXE7-000684-Sh for ima@ietf.org; Fri, 09 Feb 2007 09:59:57 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3$clerew*man&ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45cc8c58.10e6c.54 for ima@ietf.org; Fri, 9 Feb 2007 14:59:36 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l19ExRXO009700 for ; Fri, 9 Feb 2007 14:59:28 GMT To: IMA Subject: Re: [EAI] other thought about > References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> Message-ID: Date: Fri, 09 Feb 2007 14:59:27 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 08 Feb 2007 08:17:07 -0000, Randall Gellens wrote: > We tried very hard in DRUMS to permit unquoted dots in phrases! After > all, no one likes to see his or her name in sneer quotes. Too bad we > couldn't find a way to do so. But you DID find a way to do so. It is called the which MUST be accepted, and it says: Note: The "period" (or "full stop") character (".") in obs-phrase is not a form that was allowed in earlier versions of this or any other standard. Period (nor any other character from specials) was not allowed in phrase because it introduced a parsing difficulty distinguishing between phrases and portions of an addr-spec (see section 4.4). It appears here because the period character is currently used in many messages in the display-name portion of addresses, especially for initials in names, and therefore must be interpreted properly. In the future, period may appear in the regular syntax of phrase. Clearly it should have been called the (how can it be "obs" when it was never in 822), and Pete has admitted on the ietf-822 list that that should have been so. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 09 10:13:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXR5-00071Y-GU; Fri, 09 Feb 2007 10:13:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXR4-0006um-3z for ima@ietf.org; Fri, 09 Feb 2007 10:13:14 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFXR2-0008RH-IE for ima@ietf.org; Fri, 09 Feb 2007 10:13:13 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3$clerew&man^ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45cc8f82.8f00.3e1 for ima@ietf.org; Fri, 9 Feb 2007 15:13:06 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l19FD2QY010519 for ; Fri, 9 Feb 2007 15:13:03 GMT To: IMA Subject: Re: [EAI] other thought about > References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> <8EF038A6C37EE47F7977B22C@p3.JCK.COM> <20070208124121.GL19841@ns5.lsb.org> Message-ID: Date: Fri, 09 Feb 2007 15:13:02 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <20070208124121.GL19841@ns5.lsb.org> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 08 Feb 2007 12:41:22 -0000, Soobok Lee wrote: > On Thu, Feb 08, 2007 at 05:44:09AM -0500, John C Klensin wrote: >> (a) Any Mailbox or uMailbox (in the strict definitions >> of 2821 and eai-smtpext, respectively) that contains any >> non-ASCII character(s) MUST appear in brackets. > > Here is a peculiar email address example worth to consider > and leave in this list: > > To: , > > The string between first "<" and "@evil.tld>" is > the single valid local-part if: > > First @ is U+FE6B or U+FF20, not U+0040 > Second @ is U+0040 > First , is U+FE50 or U+FF0C, not U+002C > First < is U+003E > First > is U+FF1E or U+FE65, not U+003E > Second < is U+FF1C or U+FE64, not U+003C > Second > is U+003E All of which merely goes to show that local-parts MUST be normalized to NFKC, and our drafts should state that clearly (if they don't do so already). It comes back to the 'fax' test and the 'telephone' test which I mentioned right at the start of these discussions which should apply to all s. Interoperability starts with the scrap of paper off which rou initially read the message, and ends with what the eye looking at the screen actually 'sees'. Moreover, it is the From and Reply-To headers that we should be particularly concerned with, because it is the envelope from that causes delivery to the correct destination (though even that should be normalized similarly). Didn't we agree that sasl-prep contained just about the right degree of normalization for our purposes? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 09 10:18:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXWH-0002fa-He; Fri, 09 Feb 2007 10:18:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXWF-0002em-S7 for ima@ietf.org; Fri, 09 Feb 2007 10:18:35 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFXWE-0000rB-AJ for ima@ietf.org; Fri, 09 Feb 2007 10:18:35 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3^clerew^man$ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45cc90c9.e927.42f for ima@ietf.org; Fri, 9 Feb 2007 15:18:33 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l19FI05g010820 for ; Fri, 9 Feb 2007 15:18:01 GMT To: IMA Subject: Re: [EAI] other thought about > References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> <8EF038A6C37EE47F7977B22C@p3.JCK.COM> Message-ID: Date: Fri, 09 Feb 2007 15:18:00 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <8EF038A6C37EE47F7977B22C@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 08 Feb 2007 10:44:09 -0000, John C Klensin wrote: > --On Thursday, 08 February, 2007 00:59 -0800 Randall Gellens > wrote: >> Sorry, for being confused. Do you want to allow or disallow >> unbracketed UTF8 addresses? >> >> I say let's ban them. > > While I would _strongly_ prefer to permit them as long as there > is no display name field, And why not. Nobody has demonstrated any harm arising from that particular cause, and it would be bizarre to discard the long-standing conventions contained in RFC [2]822 unless actual harm could be demonstrated. > I think permitting them would force us > to deal with a whole series of other issues about characters > that may or may not be the same as others and what they would do > to parsers. You deal with the issues that _will_ break parsers, not with the ones that won't. > (a) Any Mailbox or uMailbox (in the strict definitions > of 2821 and eai-smtpext, respectively) that contains any > non-ASCII character(s) MUST appear in brackets. > > (b) Any display-name (in the strict definition of 2822) > that contains any non-ASCII character(s) MUST have the > entire phrase (2822 definition) in quotes and follow > 2822's rules about quoted phrases, including the rules > for embedded quotes. I disagree. None of the problems being reported would be cured by doing either of those things. If it ain't broke ... -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 09 10:29:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXgW-0001I9-5h; Fri, 09 Feb 2007 10:29:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXgU-0001HL-FU for ima@ietf.org; Fri, 09 Feb 2007 10:29:10 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFXgP-0002Lq-Tq for ima@ietf.org; Fri, 09 Feb 2007 10:29:10 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3^clerew$man&ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45cc9340.850e.3a8 for ima@ietf.org; Fri, 9 Feb 2007 15:29:04 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l19FSw9l011479 for ; Fri, 9 Feb 2007 15:28:59 GMT To: IMA Subject: Re: [EAI] Summary of the "BODY problems" thread(s) References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> <45C63889.6BEB@xyzzy.claranet.de> <5dhctzs52f.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Fri, 09 Feb 2007 15:28:58 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5dhctzs52f.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 06 Feb 2007 15:01:44 -0000, Kari Hurtta wrote: But apparently not sent to the list, so it is repeated in full here. > "Charles Lindsey" writes in gmane.ietf.ima: > >> On Sun, 04 Feb 2007 19:48:25 -0000, Frank Ellermann >> wrote: >> > <...> >> > The "parse nested MIME parts" might be difficult, it has >> > to descend into multipart/* parts, but not into message/*, >> > and it's apparently an update of MIME. >> >> But yes, it DOES have to descend into message/* (or at least some of >> them, though it is not yet clear which). >> > > Avoiding descend to message/rfc822 requires that message/utf-8 > attachments are not allowed on RFC 822 mail. > > I'm advocating that, but Frank Ellermann was claiming on some mail > that message/utf-8 is allowed if it is registered. > > We must keep that message/utf-8-anything types out regular mail > and message/rfc822 attachments or types. You can't state that without stating very clearly exactly how a message/utf-8 is constructed, otherwise we shall all be arguing at cross-purposes. If its internal structure is identical to that of message/rfc822 (e.g. it can contain message/rfc822s inside it, which might have to be downgraded when leaving the 8BITMIME world), then MTAs will have to be able to descend through its structure. In which case, would it not be simpler just to use message/rfc822 in the first place? I have not yet seen a single technical argument to show that we need a separate message type here. Introducing new message types unnecessarily is just going to cause yet more trouble with assorted agents that are not aware of them (we have already seem that sendmail gets some message types wrong). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 09 19:57:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgYU-0004El-6K; Fri, 09 Feb 2007 19:57:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgYS-0004Eg-NA for ima@ietf.org; Fri, 09 Feb 2007 19:57:28 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFgYR-00052G-BI for ima@ietf.org; Fri, 09 Feb 2007 19:57:28 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HFgYD-0001Jx-97 for ima@ietf.org; Sat, 10 Feb 2007 01:57:13 +0100 Received: from d254119.dialin.hansenet.de ([80.171.254.119]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Feb 2007 01:57:13 +0100 Received: from nobody by d254119.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Feb 2007 01:57:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 10 Feb 2007 01:54:01 +0100 Organization: Lines: 19 Message-ID: <45CD17A9.31EA@xyzzy.claranet.de> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> <8EF038A6C37EE47F7977B22C@p3.JCK.COM> <20070208124121.GL19841@ns5.lsb.org> <45CB4076.103@xyzzy.claranet.de> <20070209111151.GO19841@ns5.lsb.org> 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: d254119.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [EAI] Re: other thought about > X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Soobok Lee wrote: > What I tried to point out is that requiring <> don't guarantee > more "safety". I think we're talking about different things, the a + b proposal was about simplifying the task of a parser, but not some kind of anti-phishing scheme. > Instead of requiring <>, we can prohibit ,:;[]()<>@\" and > and their NFKC-equivalents in local-part explictly Maybe. I certainly won't miss anything working only as quoted pair. And months ago, long before EAI was a WG, John proposed to get rid of all obscure "features" in local parts (the cruft in the RFC 3696 errata). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 10 05:02:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFp3e-0000g7-Hr; Sat, 10 Feb 2007 05:02:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFp3c-0000cj-MM for ima@ietf.org; Sat, 10 Feb 2007 05:02:12 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFp3b-0000eI-2H for ima@ietf.org; Sat, 10 Feb 2007 05:02:12 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C5BC82596D6; Sat, 10 Feb 2007 10:58:02 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17489-03; Sat, 10 Feb 2007 10:57:57 +0100 (CET) Received: from [10.71.2.170] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 74A9B2596D1; Sat, 10 Feb 2007 10:57:57 +0100 (CET) Date: Sat, 10 Feb 2007 11:02:00 +0100 From: Harald Tveit Alvestrand To: Charles Lindsey , IMA Subject: "Fax test" (Re: [EAI] other thought about >) Message-ID: <4BA9BC2B529E6905F10E3E00@[192.168.1.108]> In-Reply-To: References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> <8EF038A6C37EE47F7977B22C@p3.JCK.COM> <20070208124121.GL19841@ns5.lsb.org> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 9. februar 2007 15:13 +0000 Charles Lindsey wrote: > All of which merely goes to show that local-parts MUST be normalized to > NFKC, and our drafts should state that clearly (if they don't do so > already). It comes back to the 'fax' test and the 'telephone' test which > I mentioned right at the start of these discussions which should apply to > all s. My memory says that you proposed the fax test, and the WG rejected it. After all, the fax test fails for many occurences of USER05 vs USERO5. > Interoperability starts with the scrap of paper off > which rou initially read the message, and ends with what the eye looking > at the screen actually 'sees'. Moreover, it is the From and Reply-To > headers that we should be particularly concerned with, because it is the > envelope from that causes delivery to the correct destination (though > even that should be normalized similarly). > > Didn't we agree that sasl-prep contained just about the right degree of > normalization for our purposes? I have not agreed to that. I have seen lots of text suggesting that wise postmasters will only define mailboxes that are in SASLPrep or stronger, but I have seen lots of text suggesting that it would be unwise to require such normalization at any point between the sender and recipient. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 11 01:44:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG8RA-00081f-3P; Sun, 11 Feb 2007 01:43:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG8R8-0007zl-9m for ima@ietf.org; Sun, 11 Feb 2007 01:43:46 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG8R7-0004pX-0F for ima@ietf.org; Sun, 11 Feb 2007 01:43:46 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HG8Qm-0004uG-NG for ima@ietf.org; Sun, 11 Feb 2007 07:43:24 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Feb 2007 07:43:24 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Feb 2007 07:43:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 11 Feb 2007 08:43:13 +0200 Lines: 42 Message-ID: <5dwt2pgpoe.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [EAI] ESMTP -- is bounce only (no downgrade) allowed X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On 8BITMIME there is on operation mode where - SMTP server announces 8BITMIME - never parses or downgrades MIME structure Instead mail is always bounces if next hop does not support 8BITMIME This is possible because on ESMTP there is parameter BODY=8BITMIME Is following wanted on UTF8SMTP - SMTP server announces UTF8SMTP - never parses or downgrades MIME structure - never downgrades mail header fields Instead mail is always bounces if next hop does not support UTF8SMTP This requires that SMTP server knows that mail is using UTF8SMTP. So if that opartion mode is make posible, that requires that on ESMTP there is parameter HDR=UTF8 Basically that is: Do we allow SMTP servers which do not parse MIME structure ? ( SMTP servers which does downgrade do not need either HDR=UTF8 or BODY=8BITMIME. They can just start downgrading if next hop does not support 8BITMIME or UTF8SMTP. If there is no anything that requires downgrading, output is original mail. That downgrade process is also that pass when mail is parsed. No other parsing is required, if that output is stored to memory and after full succesfully downgrade then is DATA commend given to next hop. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 11 10:46:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGGuI-0006Gt-Th; Sun, 11 Feb 2007 10:46:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGGuH-0006GG-D0 for ima@ietf.org; Sun, 11 Feb 2007 10:46:25 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGGuB-0004to-Uh for ima@ietf.org; Sun, 11 Feb 2007 10:46:25 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HGGu4-0007F0-Na for ima@ietf.org; Sun, 11 Feb 2007 16:46:12 +0100 Received: from du-001-047.access.de.clara.net ([212.82.227.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Feb 2007 16:46:12 +0100 Received: from nobody by du-001-047.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Feb 2007 16:46:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sun, 11 Feb 2007 16:41:16 +0100 Organization: Lines: 73 Message-ID: <45CF391C.3D75@xyzzy.claranet.de> References: <5dwt2pgpoe.fsf@Hurtta06k.keh.iki.fi> 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: du-001-047.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [EAI] Re: ESMTP -- is bounce only (no downgrade) allowed X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > On 8BITMIME there is on operation mode where > - SMTP server announces 8BITMIME > - never parses or downgrades MIME structure > Instead mail is always bounces if next hop > does not support 8BITMIME It better rejects it instead of "accept and bounce" in this situation, otherwise it's in serious trouble. > This is possible because on ESMTP there is parameter > BODY=8BITMIME Yes. Are you using the confusing 2821-definition of "bounce == reject" ? Please don't, let's stick to "bounce == send NDN", or don't use "bounce" at all. > Is following wanted on UTF8SMTP > - SMTP server announces UTF8SMTP > - never parses or downgrades MIME structure > - never downgrades mail header fields > Instead mail is always bounces if next hop > does not support UTF8SMTP The next hop could still support 8BITMIME, and for that it's good enough to downgrade the mail header. > This requires that SMTP server knows that mail > is using UTF8SMTP. So if that opartion mode > is make posible, that requires that on ESMTP > there is parameter HDR=UTF8 With an UTF-8 address for the MAIL FROM that's not necessary: At some point in time it would cause an UTF-8 Return-Path => message/utf-8. With an UTF-8 address for the RCPT TO it could in theory cause an UTF-8 "for" clause in the timestamp line => message/utf-8 for these RCPT TOs, as far as the relay uses "for". So your scenario is apparently "no UTF-8 in the envelope" (or only in some RCPT TOs), and then it can determine "HDR=UTF8" by looking at the header. Anything related to the body is already determined by BODY=8BITMIME, it's only relevant for next hops not supporting 8BITMIME. > Basically that is: Do we allow SMTP servers > which do not parse MIME structure ? Sure, not parsing MIME is fine as long as you stay within an 8BITMIME environment. > SMTP servers which does downgrade do not need > either HDR=UTF8 or BODY=8BITMIME. They can > just start downgrading if next hop does not > support 8BITMIME or UTF8SMTP. UTF8SMTP to 8BITMIME is a simple procedure. But 8BITMIME to 7bit is tricky. I think you have all info you need (without HDR=UTF8). We have to say that "look at the header" is actually about the header as created by an MDA (incl. Return-Path), even if the MTA in question is no MDA, because UTF-8 could be used _only_ in the envelope. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 11 11:38:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGHio-00019M-GL; Sun, 11 Feb 2007 11:38:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGHin-00014b-Bx for ima@ietf.org; Sun, 11 Feb 2007 11:38:37 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGHim-00045D-2n for ima@ietf.org; Sun, 11 Feb 2007 11:38:37 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HGHiY-0000Cb-Rv for ima@ietf.org; Sun, 11 Feb 2007 17:38:23 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Feb 2007 17:38:22 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Feb 2007 17:38:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 11 Feb 2007 18:38:12 +0200 Lines: 14 Message-ID: <5d4pps4pl7.fsf@Hurtta06k.keh.iki.fi> References: <5dwt2pgpoe.fsf@Hurtta06k.keh.iki.fi> <45CF391C.3D75@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [EAI] Re: ESMTP -- is bounce only (no downgrade) allowed X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima. > Anything related to the body is already determined > by BODY=8BITMIME, it's only relevant for next hops > not supporting 8BITMIME. No. It is not only relevent for next hops not supporting 8BITMIME. So, I disagree with that answer. It is already on many messages discussed what all is required for UTF8SMTP downgrade. So I will not repeat it on here. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 11 12:24:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGIQW-000070-PH; Sun, 11 Feb 2007 12:23:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGIQV-00006u-2a for ima@ietf.org; Sun, 11 Feb 2007 12:23:47 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGIQT-0001Jp-PR for ima@ietf.org; Sun, 11 Feb 2007 12:23:47 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HGIQJ-0008Q2-MX for ima@ietf.org; Sun, 11 Feb 2007 18:23:35 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Feb 2007 18:23:35 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Feb 2007 18:23:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 11 Feb 2007 19:23:26 +0200 Lines: 14 Message-ID: <5dire8vca9.fsf@Hurtta06k.keh.iki.fi> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> <45C63889.6BEB@xyzzy.claranet.de> <5dhctzs52f.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [EAI] Re: Summary of the "BODY problems" thread(s) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > You can't state that without stating very clearly exactly how a > message/utf-8 is constructed, otherwise we shall all be arguing at > cross-purposes. message/utf-8 exists only on draft-ietf-eai-dsn-00.txt | The second type, used for content return, is message/utf-8 is similar | to message/rfc822, except it contains a message with UTF-8 headers. ( That whole thread started from comments about draft-ietf-eai-dsn-00.txt ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 11 20:24:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGPuo-0001Zs-T2; Sun, 11 Feb 2007 20:23:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGPun-0001Zk-10 for ima@ietf.org; Sun, 11 Feb 2007 20:23:33 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGPuj-0006oT-Mw for ima@ietf.org; Sun, 11 Feb 2007 20:23:33 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HGPua-000429-FU for ima@ietf.org; Mon, 12 Feb 2007 02:23:20 +0100 Received: from du-001-047.access.de.clara.net ([212.82.227.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Feb 2007 02:23:20 +0100 Received: from nobody by du-001-047.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Feb 2007 02:23:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Mon, 12 Feb 2007 02:22:36 +0100 Organization: Lines: 29 Message-ID: <45CFC15C.59B5@xyzzy.claranet.de> References: <5dwt2pgpoe.fsf@Hurtta06k.keh.iki.fi> <45CF391C.3D75@xyzzy.claranet.de> <5d4pps4pl7.fsf@Hurtta06k.keh.iki.fi> 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: du-001-047.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [EAI] Re: ESMTP -- is bounce only (no downgrade) allowed X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: >> Anything related to the body is already determined >> by BODY=8BITMIME, it's only relevant for next hops >> not supporting 8BITMIME. > No. It is not only relevent for next hops not supporting > 8BITMIME. > So, I disagree with that answer. It is already on many > messages discussed what all is required for UTF8SMTP > downgrade. I propose to get a MIME expert (e.g., Keith, or Ned) to tell us how 2049-MIME is supposed to work: Is a message/utf-8 or message/unknown part within a message/rfc822 an opaque object, only subject to 8bit vs. 7bit considerations, or is its "internal" structure inherently known. Likewise we need to know if message/utf-8 or message/unknown parts within an (implicitly) message/utf-8 are opaque objects, not subject to UTF8SMTP to 8BITMIME downgrading efforts. Finally we should know whether introducing UTF-8 in MIME part headers (Content-*) is somehow possible for MIME version 1.0, or if that would require a new MIME version (as I think). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 11 20:48:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGQIR-0005hF-Ev; Sun, 11 Feb 2007 20:47:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGQIP-0005h8-RR for ima@ietf.org; Sun, 11 Feb 2007 20:47:57 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGQIO-0005mA-Ht for ima@ietf.org; Sun, 11 Feb 2007 20:47:57 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HGQIE-0008AI-0I for ima@ietf.org; Mon, 12 Feb 2007 02:47:46 +0100 Received: from du-001-047.access.de.clara.net ([212.82.227.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Feb 2007 02:47:45 +0100 Received: from nobody by du-001-047.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Feb 2007 02:47:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Mon, 12 Feb 2007 02:47:00 +0100 Organization: Lines: 22 Message-ID: <45CFC714.4B8E@xyzzy.claranet.de> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> <45C63889.6BEB@xyzzy.claranet.de> <5dhctzs52f.fsf@Hurtta06k.keh.iki.fi> <5dire8vca9.fsf@Hurtta06k.keh.iki.fi> 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: du-001-047.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [EAI] Re: Summary of the "BODY problems" thread(s) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > message/utf-8 exists only on draft-ietf-eai-dsn-00.txt Anything like a message/rfc822 with UTF-8 in its header is a message/utf-8, because it obviously can't be a message/rfc822. | NOTE: In certain transport enclaves, RFC 822 restrictions such as | the one that limits bodies to printable US-ASCII characters may not | be in force. (That is, the transport domains may exist that resemble | standard Internet mail transport as specified in RFC 821 and assumed | by RFC 822, but without certain restrictions.) The relaxation of | these restrictions should be construed as locally extending the | definition of bodies, for example to include octets outside of the | US-ASCII range, as long as these extensions are supported by the | transport and adequately documented in the Content- Transfer-Encoding | header field. However, in no event are headers (either message | headers or body part headers) allowed to contain anything other than | US-ASCII characters. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 12 09:46:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGcRt-0007VZ-Kj; Mon, 12 Feb 2007 09:46:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGcRs-0007UU-Ac for ima@ietf.org; Mon, 12 Feb 2007 09:46:32 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGcRX-0002Mo-I4 for ima@ietf.org; Mon, 12 Feb 2007 09:46:13 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l1CEk2J5032498; Mon, 12 Feb 2007 23:46:03 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l1CEk1fp032493; Mon, 12 Feb 2007 23:46:01 +0900 Date: Mon, 12 Feb 2007 23:46:01 +0900 From: Soobok Lee To: Frank Ellermann Subject: Re: [EAI] Re: other thought about > Message-ID: <20070212144601.GR19841@ns5.lsb.org> References: <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> <8EF038A6C37EE47F7977B22C@p3.JCK.COM> <20070208124121.GL19841@ns5.lsb.org> <45CB4076.103@xyzzy.claranet.de> <20070209111151.GO19841@ns5.lsb.org> <45CD17A9.31EA@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45CD17A9.31EA@xyzzy.claranet.de> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, Feb 10, 2007 at 01:54:01AM +0100, Frank Ellermann wrote: > Soobok Lee wrote: > > > What I tried to point out is that requiring <> don't guarantee > > more "safety". > > I think we're talking about different things, the a + b proposal > was about simplifying the task of a parser, but not some kind of > anti-phishing scheme. I understand that 1) looks clearer to our eyes than 2). 1) To: , 2) To: abc@address.tld,def@address.tld But, I can't imagine that future parsers drop support of form 2) for simplicity of implementations. This is another well-known example using BIDI control RLO (U+202E,right-to-left override). I applied this into utf8-local-part. From: (RLO)dlt.mitciv@evil1.tld is visually rendered to recipients as: From: dlt.1live@victim.tld This is angle-bracked one. From: <(RLO)dlt.mitciv@evil2.tld> is rendered as: From: < document.write(unescape('

To: %u202Edlt.mitciv@evil1.tld')); document.writeln("
"); document.write(unescape('

To: <%u202Edlt.mitciv@evil2.tld>')); document.writeln("
"); (All BIDI control characters behavior looks complex to me. I had misused them in idna-ipdate list. The above javascript scriptlet s for verification purpose, especialy for me myself to be sure ). > > > Instead of requiring <>, we can prohibit ,:;[]()<>@\" and > > and their NFKC-equivalents in local-part explictly > > Maybe. I certainly won't miss anything working only as quoted > pair. And months ago, long before EAI was a WG, John proposed > to get rid of all obscure "features" in local parts (the cruft > in the RFC 3696 errata). I am not sure whether I understood your word, but, unlike utf8-dot-atom, quoted-string local-part can contain _any_ characters including these quoted-pairs \\ and \". >From my reading RFC2822, quoted pairs cannot appear in utf8-dot-atom and dot-atom , but can appear in dcontent(domain literal) and qcontent (every quoted-string). (Correct me if I am wrong.) Soobok ---------------------------------------------------------------------- local-part = dot-atom / quoted-string / obs-local-part qcontent = qtext / quoted-pair quoted-pair = ("\" text) / obs-qp obs-qp = "\" (%d0-127) The only places in this standard where quoted-pair currently appears are ccontent, qcontent, dcontent, no-fold-quote, and no-fold-literal. domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS] dcontent = dtext / quoted-pair utf8-local-part = utf8-dot-atom / quoted-string / obs-local-part _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 12 10:20:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGcya-0000te-Ph; Mon, 12 Feb 2007 10:20:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGcyZ-0000tX-EC for ima@ietf.org; Mon, 12 Feb 2007 10:20:19 -0500 Received: from www.nabble.com ([72.21.53.35] helo=talk.nabble.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGcyV-0005ND-4a for ima@ietf.org; Mon, 12 Feb 2007 10:20:19 -0500 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HGcyS-00071z-BX for ima@ietf.org; Mon, 12 Feb 2007 07:20:12 -0800 Message-ID: <8926188.post@talk.nabble.com> Date: Mon, 12 Feb 2007 07:20:12 -0800 (PST) From: "Dr. Reda" To: ima@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Nabble-From: reda.reda@siemens.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [EAI] Call for Papers: ICDT 2007 Silicon Valley, California, USA July 1-6, 2007 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Call for Papers: ICDT 2007 Silicon Valley, California, USA July 1-6, 2007 DEADLINE FEBRUARY 20 ICIMP 2007, The Second International Conference on Internet Monitoring and Protection=20 http://www.iaria.org/conferences2007/ICIMP07.html CALL FOR PAPERS: _____________________________________________________ Place: =09=09=09=09=09Silicon Valley, California, USA Important deadlines: Full paper submission =09=09=09February 20, 2007 Author notification =09=09=09March 10, 2007 Registration and Camera ready =09March 31, 2007 _____________________________________________________ Featuring the workshops: o=09SYVUL 2007: The First International Workshop on Systems Vulnerabilities= =20 o=09SYDIA 2007: The First International Workshop on Systems Diagnosis=20 o=09CYBER-FRAUD 2007: The First International Workshop on Cyber-Fraud=20 ______________________________________________________________ Conference Topics: ICIMP 2007 Tracks: =E2=80=A2=09TRASI: Internet traffic surveillance and interception=20 =E2=80=A2=09IPERF: Internet Performance=20 =E2=80=A2=09RTSEC: Security for Internet-based real-time systems=20 =E2=80=A2=09DISAS: Disaster prevention and recovery=20 =E2=80=A2=09EMERG: Networks and applications emergency services =20 =E2=80=A2=09MONIT: End-to-end sampling, measurement, and monitoring=20 =E2=80=A2=09REPORT: Experiences & lessons learnt in securing networks and a= pplications=20 =E2=80=A2=09USSAF: User safety, privacy, and protection over Interne=20 ICIMP 2007 Chairs=20 Yann Berthier, CSRRT-LU, Canada=20 Liwen He, BT, UK --=20 View this message in context: http://www.nabble.com/Call-for-Papers%3A-ICDT= -2007-Silicon-Valley%2C-California%2C-USA-July-1-6%2C-2007-tf3214349.html#a= 8926188 Sent from the IETF - IMA mailing list archive at Nabble.com. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 12 11:25:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGdzh-00039z-Kq; Mon, 12 Feb 2007 11:25:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGdxi-0002ZL-BH for ima@ietf.org; Mon, 12 Feb 2007 11:23:30 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGdst-00015x-BI for ima@ietf.org; Mon, 12 Feb 2007 11:18:40 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HGdsp-0004IK-1B; Mon, 12 Feb 2007 11:18:27 -0500 Date: Mon, 12 Feb 2007 11:18:26 -0500 From: John C Klensin To: Soobok Lee , Frank Ellermann Subject: Re: [EAI] Re: other thought about > Message-ID: <10526F6F329D488C47651795@p3.JCK.COM> In-Reply-To: <20070212144601.GR19841@ns5.lsb.org> References: <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> <8EF038A6C37EE47F7977B22C@p3.JCK.COM> <20070208124121.GL19841@ns5.lsb.org> <45CB4076.103@xyzzy.claranet.de> <20070209111151.GO19841@ns5.lsb.org> <45CD17A9.31EA@xyzzy.claranet.de> <20070212144601.GR19841@ns5.lsb.org> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 12 February, 2007 23:46 +0900 Soobok Lee wrote: > This is another well-known example using BIDI control RLO > (U+202E,right-to-left override). I applied this into > utf8-local-part. > > From: (RLO)dlt.mitciv@evil1.tld > > is visually rendered to recipients as: > > From: dlt.1live@victim.tld > > This is angle-bracked one. > > From: <(RLO)dlt.mitciv@evil2.tld> > > is rendered as: > > From: < > Is the angled form safer in this case? Maybe. Anyone who permits in an email address had better understand what he or she is doing and what the implications of it might be. We aren't going to be able to help avoid the mess that could cause without writing global rules about the use of Unicode and what characters can appear in local-parts, and we have agreed to not do that. My own opinion is that it would be as stupid to insert such a character as it would be to insert X'0E' or (X'18' X'28') at the beginning of an ASCII local-part. One can do it, but the capability has been there all along and no one who is sensible and trying to get mail sent and delivered takes advantage of it. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 12 18:08:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGkH0-0000Sr-Nm; Mon, 12 Feb 2007 18:07:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGkGz-0000Sm-Eg for ima@ietf.org; Mon, 12 Feb 2007 18:07:49 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGkGx-0004YU-GR for ima@ietf.org; Mon, 12 Feb 2007 18:07:49 -0500 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1CN7k8M012099 for ; Mon, 12 Feb 2007 16:07:47 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JDD00101HEMSB00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 12 Feb 2007 16:07:46 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JDD00357HKWGD20@mail-amer.sun.com>; Mon, 12 Feb 2007 16:07:46 -0700 (MST) Date: Mon, 12 Feb 2007 15:08:02 -0800 From: Chris Newman Subject: Re: message/utf-8 downgrade issue (Comment (Re: [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt)) In-reply-to: <5dsldncmfp.fsf_-_@Hurtta06k.keh.iki.fi> To: Kari Hurtta , ima@ietf.org Message-id: <453E4D125EE2E3F65533E50A@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <5dmz3vthol.fsf@Hurtta06k.keh.iki.fi> <5dsldncmfp.fsf_-_@Hurtta06k.keh.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote on 2/3/07 17:04 +0200: > Kari Hurtta writes in gmane.ietf.ima: > >> This do not address RFC 2045 nested encoding rule. Which need be also >> addressed when message/utf-8 is base64 or quoted-printable encoded: >> >> Certain Content-Transfer-Encoding values may only be used on certain >> media types. In particular, it is EXPRESSLY FORBIDDEN to use any >> encodings other than "7bit", "8bit", or "binary" with any composite >> media type, i.e. one that recursively includes other Content-Type >> fields. Currently the only composite media types are "multipart" and >> "message". All encodings that are desired for bodies of type >> multipart or message must be done at the innermost level, by encoding >> the actual body that needs to be encoded. >> >> >> Therefore that needs update RFC 2045 (and that may be difficult, >> when documents of that working group are Experimental and RFC 2045 >> is Standards track. ) > > Specially when that tries update something which affect these, > which do not participate experiment defined on these Experimental > RFCes. > > Is that allowed? We're certainly free to require systems that support message/utf-8 to support nested encodings, as that does not place any constraints on systems that don't support message/utf-8 and treat it as a single opaque object. However, you are correct the specification needs text to address this issue. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 12 18:24:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGkX2-0000EC-2P; Mon, 12 Feb 2007 18:24:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGkX1-0000E7-Gl for ima@ietf.org; Mon, 12 Feb 2007 18:24:23 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HGkWw-0006Bq-U6 for ima@ietf.org; Mon, 12 Feb 2007 18:24:23 -0500 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1CNOC6N017897 for ; Mon, 12 Feb 2007 16:24:12 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JDD00501IAO6I00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 12 Feb 2007 16:24:12 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JDD00LLBIC8LB40@mail-amer.sun.com>; Mon, 12 Feb 2007 16:24:11 -0700 (MST) Date: Mon, 12 Feb 2007 15:24:26 -0800 From: Chris Newman Subject: Re: [EAI] other thought about > In-reply-to: <0JD400710Y0DUY00@nwk-avmta-2.sfbay.sun.com> To: Randall Gellens , John C Klensin , Soobok Lee , Charles Lindsey Message-id: <184943BBD64635E16553A950@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <0JD400710Y0DUY00@nwk-avmta-2.sfbay.sun.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Actually, RFC 2822 does require recipients to accept unquoted dot in phrase (see the "obs-phrase" rule). It's one of the few additions to the obsolete grammar that was not in RFC 822. It should have been called out in a separate section as something we might move from the "MUST NOT generate" to "MAY generate" category in the future. But at least it's there. - Chris Randall Gellens wrote on 2/8/07 0:17 -0800: > At 6:45 PM -0500 1/30/07, John C Klensin wrote: > >> Sigh. Quotation marks have never been required, or even >> recommended in that case. For your amusement, the exact rule is >> the reason why I stopped using a period after the "C" in "John C >> Klensin", which doesn't use quotation marks either. I suggest >> that you might find reading the specification useful. > > We tried very hard in DRUMS to permit unquoted dots in phrases! After all, no > one likes to see his or her name in sneer quotes. Too bad we couldn't find a > way to do so. > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly-selected tag: --------------- > Get your facts first, and then you can distort them as much as you please. > --Mark Twain > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 12 18:40:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGkmq-0005Cc-CQ; Mon, 12 Feb 2007 18:40:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGkmo-0005CI-R2 for ima@ietf.org; Mon, 12 Feb 2007 18:40:42 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGkmn-0004IR-58 for ima@ietf.org; Mon, 12 Feb 2007 18:40:42 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l1CNebJ5026859 for ; Tue, 13 Feb 2007 08:40:37 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l1CNeaJ4026858 for ima@ietf.org; Tue, 13 Feb 2007 08:40:36 +0900 Date: Tue, 13 Feb 2007 08:40:36 +0900 From: Soobok Lee To: ima@ietf.org Subject: Re: [EAI] Re: other thought about > Message-ID: <20070212234036.GA24872@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > >--On Monday, 12 February, 2007 23:46 +0900 Soobok Lee > wrote: > >> This is another well-known example using BIDI control RLO >> (U+202E,right-to-left override). I applied this into >> utf8-local-part. >> >> From: (RLO)dlt.mitciv at evil1.tld >> > >Anyone who permits in an email address had better >understand what he or she is doing and what the implications of >it might be. In the case that the owner of evil1.tld is the attacker himself, he/she might have understood that well, in order to exploit it for unlawful phishing purpose. This WG and I regard current permissive rule on utf8-local-part as "feature" and a design choice from good intents, but phishers might regard that as exploitable "security hole". > We aren't going to be able to help avoid the mess >that could cause without writing global rules about the use of >Unicode and what characters can appear in local-parts, and we >have agreed to not do that. My own opinion is that it would be >as stupid to insert such a character as it would be to insert >X'0E' or (X'18' X'28') at the beginning of an ASCII local-part. >One can do it, but the capability has been there all along and >no one who is sensible and trying to get mail sent and delivered >takes advantage of it. For other cases, I agree with you. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 12 20:42:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGmgS-0002ot-5b; Mon, 12 Feb 2007 20:42:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGmgQ-0002oc-Oq for ima@ietf.org; Mon, 12 Feb 2007 20:42:14 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HGmgO-0002Cn-Nf for ima@ietf.org; Mon, 12 Feb 2007 20:42:14 -0500 Received: (eyou send program); Tue, 13 Feb 2007 09:42:04 +0800 Message-ID: <371330924.26428@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Tue, 13 Feb 2007 09:42:04 +0800 Message-ID: <02a101c74f10$29335710$1206e29f@cnnicyao> From: "YAO Jiankang" To: , "Kari Hurtta" References: <5d64airrwe.fsf@Hurtta06k.keh.iki.fi> <370595737.09415@cnnic.cn> Subject: Re: RFC 2369 (Re: [EAI] RFC 2919 addition (Re: I-DACTION:draft-ietf-eai-utf8headers-02.txt)) Date: Tue, 13 Feb 2007 09:41:56 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1535940487==" Errors-To: ima-bounces@ietf.org --===============1535940487== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkthcmkgSHVydHRhIiA8aHVy dHRhK2dtYW5lQHNpaWxvLmZtaS5maT4NClRvOiA8aW1hQGlldGYub3JnPg0KU2VudDogU3VuZGF5 LCBGZWJydWFyeSAwNCwgMjAwNyA5OjI3IFBNDQpTdWJqZWN0OiBSRkMgMjM2OSAoUmU6IFtFQUld IFJGQyAyOTE5IGFkZGl0aW9uIChSZTogSS1EQUNUSU9OOmRyYWZ0LWlldGYtZWFpLXV0ZjhoZWFk ZXJzLTAyLnR4dCkpDQoNCg0KPiANCj4gSG93ZXZlciBJJ20gbm90IGFibGUgdG8gZGV0ZXJtaW5l IGFjdHVhbCBncmFtbWFyIGZvcg0KPiBoZWFkZXIgZmllbGRzICBkZWZpbmVkIG9uIFJGQyAyMzY5 LCBzbyBJIGNhbiBub3QgZGV0ZXJtaW5lIGlzIA0KPiBkcmFmdC1pZXRmLWVhaS11dGY4aGVhZGVy cy0wMiBleHRlbmRpbmcgdGhlc2UuDQo+IA0KPiBTZWVtcyB0aGF0IHN5bnRheCBpcyBhY3R1YWxs eSBkZWZpbmVkIHdpdGhvdXQgZ2l2aW5nDQo+IGZvcm1hbCBncmFtbWFyLg0KPiANCj4gT3IgaXMg SSBtaXNzaW5nIHNvbWV0aGluZz8NCj4gDQo+IEhlYWRlciBmaWVsZHMgYXJlOg0KPiAgICAgICAg IExpc3QtSGVscCwgDQo+ICAgICAgICAgTGlzdC1TdWJzY3JpYmUsIA0KPiAgICAgICAgIExpc3Qt VW5zdWJzY3JpYmUsDQo+ICAgICAgICAgTGlzdC1Qb3N0LCANCj4gICAgICAgICBMaXN0LU93bmVy LCANCj4gICAgICAgICBMaXN0LUFyY2hpdmUNCg0KDQpJTU8sIHRoZSBoZWFkZXIgZmllbGRzIGFi b3ZlIGluIHRoZSBtYWlsaW5nIGxpc3Qgc2hvdWxkIGdvIHRvIGRyYWZ0LWlldGYtZWFpLW1haWxp bmdsaXN0Lg0KDQpXaGVuIFJhbmRhbGwgR2VsbGVucyAgdXBkYXRlcyB0aGUgbWFpbGluZ2xpc3Qg ZHJhZnQsIGhlIG1heSBjb25zaWRlciBpdC4NCg0KWUFPIEppYW5rYW5nDQpDTk5JQw0KDQoNCg0K DQo+IA0KPiBPbiBzb21lIGhlYWRlciBmaWVsZHMgdGhlcmUgYXJlIGNvbW1lbnRzIGluc2lkZSBv ZiAoICkuDQo+IEl0IG1heSBiZSB0aGF0IHRoZXNlIHVzZSA8Y3RleHQ+DQo+IA0KPiBUbyBtZSBp dCBzZWVtcyB0aGF0IE1VQXMgd2lsbCBwcm9jZXNzIGNvbW1lbnRzIGluc2lkZSBvZg0KPiBMaXN0 LSogaGVhZGVyIGZpZWxkcyBzYW1lIHdheSB0aGFuIGNvbW1lbnQgb24gc3RydWN0dXJlZCBSRkMg MjgyMg0KPiBoZWFkZXIgZmllbGRzLg0KPiANCj4gDQo+IFJGQyAyMzY5IHF1b3RlOiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAyLiBUaGUgQ29tbWFu ZCBTeW50YXgNCj4gDQo+ICAgVGhlIGxpc3QgaGVhZGVyIGZpZWxkcyBhcmUgc3ViamVjdCB0byB0 aGUgZW5jb2RpbmcgYW5kIGNoYXJhY3Rlcg0KPiAgIHJlc3RyaWN0aW9ucyBmb3IgbWFpbCBoZWFk ZXJzIGFzIGRlc2NyaWJlZCBpbiBbUkZDODIyXS4gQWRkaXRpb25hbGx5LA0KPiAgIHRoZSBVUkwg Y29udGVudCBpcyBmdXJ0aGVyIHJlc3RyaWN0ZWQgdG8gdGhlIHNldCBvZiBVUkwgc2FmZQ0KPiAg IGNoYXJhY3RlcnMgW1JGQzE3MzhdLg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IA0KPiAvIEthcmkgSHVydHRh DQo+IA0KPiBSRkMgMjM2OTogVGhlIFVzZSBvZiBVUkxzIGFzIE1ldGEtU3ludGF4IGZvciBDb3Jl IE1haWwgTGlzdCBDb21tYW5kcw0KPiAgICAgICAgICBhbmQgdGhlaXIgVHJhbnNwb3J0IHRocm91 Z2ggTWVzc2FnZSBIZWFkZXIgRmllbGRzDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1B QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ== --===============1535940487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============1535940487==-- From ima-bounces@ietf.org Tue Feb 13 01:28:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGr8m-000233-Sq; Tue, 13 Feb 2007 01:27:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGr8k-00022P-UR for ima@ietf.org; Tue, 13 Feb 2007 01:27:46 -0500 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGr8j-0000oW-FI for ima@ietf.org; Tue, 13 Feb 2007 01:27:46 -0500 Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@siilo.fmi.fi) by smtp1gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20070206) with ESMTP id l1D6Rd8o018543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Feb 2007 08:27:39 +0200 Received: from siilo.fmi.fi by torkku.fmi.fi with ESMTP id l1D6RcnV015652 ; Tue, 13 Feb 2007 08:27:38 +0200 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id l1D6RcIw023660 ; Tue, 13 Feb 2007 08:27:38 +0200 Received: by siilo.fmi.fi id l1D6RcxN023657; Tue, 13 Feb 2007 08:27:38 +0200 Message-Id: <200702130627.l1D6RcxN023657@siilo.fmi.fi> Subject: Re: message/utf-8 downgrade issue (Comment (Re: [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt)) In-Reply-To: <453E4D125EE2E3F65533E50A@[10.1.110.5]> To: Chris Newman Date: Tue, 13 Feb 2007 08:27:38 +0200 (EET) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123e (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp1gate: 3 received headers rewritten with id 20070213/09342/01 X-Filter: smtp1gate: ID 9340/01, 1 parts scanned for known viruses X-Filter: torkku: ID 1921/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp1gate: ID 9340/01) report=BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >>> Chris Newman > Kari Hurtta wrote on 2/3/07 17:04 +0200: > > Kari Hurtta writes in gmane.ietf.ima: > > > >> This do not address RFC 2045 nested encoding rule. Which need be also > >> addressed when message/utf-8 is base64 or quoted-printable encoded: > >> > >> Certain Content-Transfer-Encoding values may only be used on certain > >> media types. In particular, it is EXPRESSLY FORBIDDEN to use any > >> encodings other than "7bit", "8bit", or "binary" with any composite > >> media type, i.e. one that recursively includes other Content-Type > >> fields. Currently the only composite media types are "multipart" and > >> "message". All encodings that are desired for bodies of type > >> multipart or message must be done at the innermost level, by encoding > >> the actual body that needs to be encoded. > >> > >> > >> Therefore that needs update RFC 2045 (and that may be difficult, > >> when documents of that working group are Experimental and RFC 2045 > >> is Standards track. ) > > Is that allowed? > > We're certainly free to require systems that support message/utf-8 to support > nested encodings, as that does not place any constraints on systems that don't > support message/utf-8 and treat it as a single opaque object. > > However, you are correct the specification needs text to address this issue. > > - Chris OK. Only issue then 8BITMIME downgraders, which do not know about this specification and see 8-bit message/utf-8 types. ( If 8BITMIME downgrade is also UTF8SMTP downgrader, then we can assume that it follows this specification. ) If we assume that they follow RFC 2045, that means that they will bounce message which includes message/utf-8 (*). And bacause that message/utf-8 occurs on DSN this means that envelope sender is <>. Therefore these DSNes is just dropped (or forwarded to postmaster of 8BITMIME downgrader.) However DSN which includes message/utf-8 (ot other these message/utf-8-* types), implicates that original bounced mail was using UTF8SMTP. So either return route which mail travels is somewhat strange or envelope sender address of original message was pointing some other system than from where that original UTF8SMTP message was sent. If danger of that is high enough, then it must be required that UTF8SMTP downgrader also base64 or quote-printable encodes message/utf-8 and message/utf-8-* types. / Kari Hurtta (*) In reality some 8BITMIME downgraders does strange things for 8-bit message/* types. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 13 13:54:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2mv-0006ah-Jl; Tue, 13 Feb 2007 13:54:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2mu-0006ab-BB for ima@ietf.org; Tue, 13 Feb 2007 13:54:00 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH2ms-000316-Un for ima@ietf.org; Tue, 13 Feb 2007 13:54:00 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HH2mn-000Fon-RY; Tue, 13 Feb 2007 13:53:54 -0500 Date: Tue, 13 Feb 2007 13:53:53 -0500 From: John C Klensin To: Soobok Lee , ima@ietf.org Subject: Unicode presentation-formatting characters (Re: [EAI] Re: other thought about >) Message-ID: <346B8D9E0284D6AC352A98AA@p3.JCK.COM> In-Reply-To: <20070212234036.GA24872@ns5.lsb.org> References: <20070212234036.GA24872@ns5.lsb.org> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 13 February, 2007 08:40 +0900 Soobok Lee wrote: >> >> --On Monday, 12 February, 2007 23:46 +0900 Soobok Lee >> wrote: >> >>> This is another well-known example using BIDI control RLO >>> (U+202E,right-to-left override). I applied this into >>> utf8-local-part. >>> >>> From: (RLO)dlt.mitciv at evil1.tld >>> >> >> Anyone who permits in an email address had better >> understand what he or she is doing and what the implications >> of it might be. > > In the case that the owner of evil1.tld is the attacker > himself, he/she might have understood that well, in order to > exploit it for unlawful phishing purpose. > > This WG and I regard current permissive rule on > utf8-local-part as "feature" and a design choice from good > intents, but phishers might regard that as exploitable > "security hole". Sure. >> We aren't going to be able to help avoid the mess >> that could cause without writing global rules about the use of >> Unicode and what characters can appear in local-parts, and we >> have agreed to not do that. My own opinion is that it would >> be as stupid to insert such a character as it would be to >> insert X'0E' or (X'18' X'28') at the beginning of an ASCII >> local-part. One can do it, but the capability has been there >> all along and no one who is sensible and trying to get mail >> sent and delivered takes advantage of it. > > For other cases, I agree with you. But that was the point of mentioning the ASCII control characters that are often used for code-table-shifting. While they are permitted in local parts on the wire, almost every self-respecting MUA will go beyond the "wire" standard, either imposing special quoting or simply deleting them before transmitting or presenting the message. The result is that a phishing technique based on the use of such characters becomes fairly ineffective. I would assume we would see the same behavior with formatting code points in Unicode. One could write a document explicitly suggesting such things if one wanted to, but it is not part of this WG's task to generate, or even review, such a thing (i.e., please don't turn this into another long and distracting discussion on the WG mailing list). john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 13 15:52:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH4dY-0003Aa-20; Tue, 13 Feb 2007 15:52:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH4cC-0000vh-Bl; Tue, 13 Feb 2007 15:51:04 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HH4cB-0003IG-J5; Tue, 13 Feb 2007 15:51:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 8BCB72AD45; Tue, 13 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HH4bD-0002yX-9c; Tue, 13 Feb 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 13 Feb 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-smtpext-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : SMTP extension for internationalized email address Author(s) : J. Yao, W. Mao Filename : draft-ietf-eai-smtpext-03.txt Pages : 19 Date : 2007-2-13 Internationalized email address includes two parts, the local part and the domain part. The ways email addresses are used by protocols are different from the ways domain names are used. The most critical difference is that emails are delivered through a chain of peering clients and servers while domain names are resolved by name servers by looking up their own tables. In addition to this, email transport protocols SMTP and ESMTP provide a negotiation mechanism through which clients can make decisions for further processing. This document specifies the use of SMTP extension for internationalized email address delivery. It also mentions the backward compatible mechanism for downgrade procedure, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-smtpext-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-smtpext-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-13143850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-smtpext-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-smtpext-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-13143850.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Tue Feb 13 16:20:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH54S-0003Sk-Gj; Tue, 13 Feb 2007 16:20:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH54R-0003SY-LW for ima@ietf.org; Tue, 13 Feb 2007 16:20:15 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH54I-0005Ig-3X for ima@ietf.org; Tue, 13 Feb 2007 16:20:15 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3^clerew#man&ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45d22b83.514b.21 for ima@ietf.org; Tue, 13 Feb 2007 21:20:03 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l1DLK1wC015025 for ; Tue, 13 Feb 2007 21:20:02 GMT To: IMA Subject: Re: "Fax test" (Re: [EAI] other thought about >) References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> <8EF038A6C37EE47F7977B22C@p3.JCK.COM> <20070208124121.GL19841@ns5.lsb.org> <4BA9BC2B529E6905F10E3E00@[192.168.1.108]> Message-ID: Date: Tue, 13 Feb 2007 21:20:01 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <4BA9BC2B529E6905F10E3E00@[192.168.1.108]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 10 Feb 2007 10:02:00 -0000, Harald Tveit Alvestrand wrote: > My memory says that you proposed the fax test, and the WG rejected it. > After all, the fax test fails for many occurences of USER05 vs USERO5. It was not a matter of accepting or rejecting it, because it is not a feature to in in(ex)cluded in any draft. Rather it is a self-evidently useful yardstick that should aid in deciding between various proposals that might be under discussion. > >> Didn't we agree that sasl-prep contained just about the right degree of >> normalization for our purposes? > > I have not agreed to that.# I think we agreed that SASL-prep was the best fit for any normalization that we might want to include/recommend/whatever. > I have seen lots of text suggesting that wise postmasters will only > define mailboxes that are in SASLPrep or stronger, Whether any normalization we may decide to include/recommend/whatever should take the form of "advice to poastmasters", or of stronger requirements for tests to be performed by agents in prescribed circumstances is an orthogonal issue as to whether it is best expressed in terms of sasl-prep or otherwise. But, for sure, the issue certainly needs covering in some manner within our documents, and it seems to me that that is precisely what Soobok was calling for, given the nature of the examples he gave, which are far more troublesome than the well-known confusion between O and 0. One gathers also that the internationalization of domains names is also currently stuck on much the same problem. > but I have seen lots of text suggesting that it would be unwise to > require such normalization at any point between the sender and recipient. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 13 16:31:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5FV-0007SH-NP; Tue, 13 Feb 2007 16:31:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5FU-0007S8-CB for ima@ietf.org; Tue, 13 Feb 2007 16:31:40 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH5FP-0007ic-Pd for ima@ietf.org; Tue, 13 Feb 2007 16:31:40 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3*clerew*man^ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45d22e36.fa04.1c0 for ima@ietf.org; Tue, 13 Feb 2007 21:31:34 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l1DLVXm5015720 for ; Tue, 13 Feb 2007 21:31:34 GMT Date: Tue, 13 Feb 2007 21:31:33 -0000 To: IMA Subject: Re: message/utf-8 downgrade issue (Comment (Re: [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt)) References: <5dmz3vthol.fsf@Hurtta06k.keh.iki.fi> <5dsldncmfp.fsf_-_@Hurtta06k.keh.iki.fi> <453E4D125EE2E3F65533E50A@[10.1.110.5]> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <453E4D125EE2E3F65533E50A@[10.1.110.5]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 12 Feb 2007 23:08:02 -0000, Chris Newman wrote: > Kari Hurtta wrote on 2/3/07 17:04 +0200: >>> Therefore that needs update RFC 2045 (and that may be difficult, >>> when documents of that working group are Experimental and RFC 2045 >>> is Standards track. ) >> Is that allowed? Of course it is allowed. We (an experimental draft) have already updated RFC 2822, which is Standards Track. So it we can do it for 2822, we can also do it for 2045. However, in both cases, the extensions are done on the strict understanding that rules will be in place to prevent extended messages from being seen by unextended software (hence downgrading and/or bouncing^H^H^H^H^H^H^H^Hrejecting). > > We're certainly free to require systems that support message/utf-8 to > support nested encodings, as that does not place any constraints on > systems that don't support message/utf-8 and treat it as a single opaque > object. But if some systems are going to treat message/utf-8 and some are going to treat it as application/octet stream, there is going to be chaos. Which suggests that it would be far better to use message/rfc822 for all cases, since existing software knows what structure is present there. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 13 16:35:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5JS-0000GA-Jv; Tue, 13 Feb 2007 16:35:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5JR-0000G1-R5 for ima@ietf.org; Tue, 13 Feb 2007 16:35:45 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH5JQ-0008JG-AX for ima@ietf.org; Tue, 13 Feb 2007 16:35:45 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3*clerew#man^ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45d22f2f.3b7e.27d for ima@ietf.org; Tue, 13 Feb 2007 21:35:43 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l1DLZgeK015969 for ; Tue, 13 Feb 2007 21:35:43 GMT To: IMA Subject: Re: [EAI] Re: Summary of the "BODY problems" thread(s) References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> <45C63889.6BEB@xyzzy.claranet.de> <5dhctzs52f.fsf@Hurtta06k.keh.iki.fi> <5dire8vca9.fsf@Hurtta06k.keh.iki.fi> <45CFC714.4B8E@xyzzy.claranet.de> Message-ID: Date: Tue, 13 Feb 2007 21:35:42 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <45CFC714.4B8E@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 12 Feb 2007 01:47:00 -0000, Frank Ellermann wrote: > Kari Hurtta wrote: > >> message/utf-8 exists only on draft-ietf-eai-dsn-00.txt > > Anything like a message/rfc822 with UTF-8 in its header is a > message/utf-8, because it obviously can't be a message/rfc822. Yes it can, if we extend the definition (within UTF8SMTP messages only, of course) of message/rfc822 accordingly. That implies, of course, that the downghrade process must upgrade such 'extended' message/rfc822s, but then we already agree that it would have to dowbgrade each message/utf-8, so the requirement is exactly the same whatever name we call it by. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 13 16:42:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5Pq-0004Yz-22; Tue, 13 Feb 2007 16:42:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5Pp-0004Yt-4H for ima@ietf.org; Tue, 13 Feb 2007 16:42:21 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH5Pm-0000pE-Fa for ima@ietf.org; Tue, 13 Feb 2007 16:42:21 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3$clerew#man&ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45d230b9.1495e.2ba for ima@ietf.org; Tue, 13 Feb 2007 21:42:17 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l1DLgGbJ016364 for ; Tue, 13 Feb 2007 21:42:17 GMT To: IMA Subject: Re: [EAI] ESMTP -- is bounce only (no downgrade) allowed References: <5dwt2pgpoe.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Tue, 13 Feb 2007 21:42:15 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5dwt2pgpoe.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, 11 Feb 2007 06:43:13 -0000, Kari Hurtta wrote: > This is possible because on ESMTP there is parameter > BODY=8BITMIME Except that even where BODY=8BITMIME is absent, systems (e.g. sendmail) still do the full recursive descetn check, just to make sure. > This requires that SMTP server knows that mail > is using UTF8SMTP. So if that opartion mode > is make posible, that requires that on ESMTP > there is parameter HDR=UTF8 And there again, this WG seems to have decided that systems are expected to do the full recursive descent check regardless (that is why we got rid of Header-Type, which was a far better marker for the existence of UTF8SMTP in the message than HDR=UTF8 would be). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 13 16:46:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5Te-0006Nc-Js; Tue, 13 Feb 2007 16:46:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5Td-0006NS-Gb for ima@ietf.org; Tue, 13 Feb 2007 16:46:17 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH5Tb-0001L7-Q5 for ima@ietf.org; Tue, 13 Feb 2007 16:46:17 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3#clerew$man^ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45d231a7.a8c9.20b for ima@ietf.org; Tue, 13 Feb 2007 21:46:15 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l1DLkDRF016605 for ; Tue, 13 Feb 2007 21:46:14 GMT To: IMA Subject: Re: [EAI] Re: ESMTP -- is bounce only (no downgrade) allowed References: <5dwt2pgpoe.fsf@Hurtta06k.keh.iki.fi> <45CF391C.3D75@xyzzy.claranet.de> Message-ID: Date: Tue, 13 Feb 2007 21:46:13 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <45CF391C.3D75@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, 11 Feb 2007 15:41:16 -0000, Frank Ellermann wrote: > UTF8SMTP to 8BITMIME is a simple procedure. But > 8BITMIME to 7bit is tricky. I think you have all > info you need (without HDR=UTF8). We have to say > that "look at the header" is actually about the > header as created by an MDA (incl. Return-Path), > even if the MTA in question is no MDA, because > UTF-8 could be used _only_ in the envelope. No! It has been explained to you again and again that you need a full recursive-descent check in both cases, in order to find the places that need to be downgraded. The overall structure of the test is exactly the same in both cases (just that you are looking to downgrade bodies on one case, and to donwgrade headers (or maybe both) in the other. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 13 16:58:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5ew-0001ts-N3; Tue, 13 Feb 2007 16:57:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH5eu-0001tL-Ro for ima@ietf.org; Tue, 13 Feb 2007 16:57:56 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH5et-0002r2-8N for ima@ietf.org; Tue, 13 Feb 2007 16:57:56 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3*clerew&man^ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45d23461.1597e.1ee for ima@ietf.org; Tue, 13 Feb 2007 21:57:53 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l1DLvqxa017306 for ; Tue, 13 Feb 2007 21:57:53 GMT To: IMA References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> <45C63889.6BEB@xyzzy.claranet.de> <5dhctzs52f.fsf@Hurtta06k.keh.iki.fi> <5dtzxvfaok.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Tue, 13 Feb 2007 21:57:51 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5dtzxvfaok.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [EAI] Re: Summary of the "BODY problems" thread(s) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 09 Feb 2007 18:27:55 -0000, Kari Hurtta wrote: Sigh! Another message to me from Kari not posted to the full list. > "Charles Lindsey" writes in gmane.ietf.ima: > >> If its internal structure is identical to that of message/rfc822 >> (e.g. it can contain message/rfc822s inside it, which might have to >> be downgraded when leaving the 8BITMIME world), then MTAs will have >> to be able to descend through its structure. In which case, would it >> not be simpler just to use message/rfc822 in the first place? I have >> not yet seen a single technical argument to show that we need a >> separate message type here. > > To me it makes sense to use message/rfc822 Good! That makes two of us. > > draft-ietf-eai-dsn-00.txt gives following reason why message/rfc822 > is not used: > > The second type, used for content return, is message/utf-8 is similar > to message/rfc822, except it contains a message with UTF-8 headers. > This type has profound implications on the email infrastructure. > First, Internet Message Access Protocol [RFC3501] servers MUST NOT > descend a message/utf-8 when generating the message BODYSTRUCTURE, it > is likely a new variant on BODYSTRUCTURE will be necessary that does > descend message/utf-8 body parts. Can someone please explain the nature of this problem? I have looked at RFC 3501, and it says NOTHING about BODYSTRUCTURE, except that such a thjing exists. But, in any case, this argument is bogus. A UTF8SMTP message is meant to be dongraded before it ever reaches any non-extended agent, and that includes IMAP stores. So any message/rfc822 that succeeds in reaching an old IMAP store should already be 100% safe. OTOH, new IMAP systems will presumably be aware of the extensions, and will do the "right thing", whatever that is (and our IMAP draft needs to cover whatever BODYSTRUCTURE problem there might be). > > It gives also another reason, which is bogus: > > Second, if this type is sent to a > 7-bit-only system, it could be encoded in base64 or quoted-printable > [RFC2045]. As a result, SMTP servers and other systems which > transfer a message/utf-8 body part MAY choose to down-convert it to a > message/rfc822 body part using the rules described in Downgrading > mechanism for Email Address Internationalization [I-D.ietf-eai- > downgrade]. > > > That second reason do not take account that base64 and quoted-printable > are fobidded for message/* +1 > > > I do not know is that first rwason valid. See above. > > / Kari Hurtta > > -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 14 01:04:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHDEu-0008Sn-Bt; Wed, 14 Feb 2007 01:03:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHDEs-0008Sd-R7 for ima@ietf.org; Wed, 14 Feb 2007 01:03:34 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHDEn-0001CX-HB for ima@ietf.org; Wed, 14 Feb 2007 01:03:34 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HHDEV-0006mb-5v for ima@ietf.org; Wed, 14 Feb 2007 07:03:11 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Feb 2007 07:03:11 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Feb 2007 07:03:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 14 Feb 2007 08:03:03 +0200 Lines: 36 Message-ID: <5dr6stgtt4.fsf@Hurtta06k.keh.iki.fi> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> <45C63889.6BEB@xyzzy.claranet.de> <5dhctzs52f.fsf@Hurtta06k.keh.iki.fi> <5dire8vca9.fsf@Hurtta06k.keh.iki.fi> <45CFC714.4B8E@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [EAI] Re: Summary of the "BODY problems" thread(s) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > On Mon, 12 Feb 2007 01:47:00 -0000, Frank Ellermann > wrote: > > > Kari Hurtta wrote: > > > >> message/utf-8 exists only on draft-ietf-eai-dsn-00.txt > > > > Anything like a message/rfc822 with UTF-8 in its header is a > > message/utf-8, because it obviously can't be a message/rfc822. > > Yes it can, if we extend the definition (within UTF8SMTP messages > only, of course) of message/rfc822 accordingly. That implies, of > course, that the downghrade process must upgrade such 'extended' > message/rfc822s, but then we already agree that it would have to > dowbgrade each message/utf-8, so the requirement is exactly the same > whatever name we call it by. +1 ( I agree ) draft-ietf-eai-dsn-00.txt gives IMAP BODYSTRUCTURE as reason for message/utf-8. I can be wrong, but There are also on IMAP extensions for UTF-8 which protects UTF8SMTP messages. Therefore UTF8SMTP unaware imap clients do not see UTF8SMTP messages, but instead they are downgraded. Therefore they do not see UTF-8 fields on BODYSTRUCTURE, because also these message/rfc822 objects are downgraded. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 14 03:39:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHFff-0006eg-LW; Wed, 14 Feb 2007 03:39:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHFfe-0006bz-2q for ima@ietf.org; Wed, 14 Feb 2007 03:39:22 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHFcS-0008Ip-OC for ima@ietf.org; Wed, 14 Feb 2007 03:36:11 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HHFcK-0001OS-Vw for ima@ietf.org; Wed, 14 Feb 2007 09:35:56 +0100 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Feb 2007 09:35:56 +0100 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Feb 2007 09:35:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 14 Feb 2007 10:35:55 +0200 Lines: 60 Message-ID: <5dlkj16sr8.fsf_-_@leija.fmi.fi> References: <5dwt2pgpoe.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [EAI] HDR=UTF8 paramater or not? (Re: ESMTP -- is bounce only (no downgrade) allowed) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > On Sun, 11 Feb 2007 06:43:13 -0000, Kari Hurtta > wrote: > > > This is possible because on ESMTP there is parameter > > BODY=8BITMIME > > Except that even where BODY=8BITMIME is absent, systems > (e.g. sendmail) still do the full recursive descetn check, just to > make sure. > > > This requires that SMTP server knows that mail > > is using UTF8SMTP. So if that opartion mode > > is make posible, that requires that on ESMTP > > there is parameter HDR=UTF8 > > And there again, this WG seems to have decided that systems are > expected to do the full recursive descent check regardless (that is > why we got rid of Header-Type, which was a far better marker for the > existence of UTF8SMTP in the message than HDR=UTF8 would be). On consensus call there was: | Note that this is not a call on the proposal to have a similar marker | in the SMTP protocol; that's a separate issue. So I was analyzing on what situations HDR=UTF8 parameter is required. I'm assuming that this parameter goes to MAIL command. Seems that it is required, if WG want allow MTAs to announce UTF8SMTP without full recursive mime structure parsers. On that case these MTAs which announce UTF8SMTP, and they do not have full recursive mime structure parser then need bounce (*) message if next hop of any rcpt do not announce UTF8SMTP. (*) Bounce means, either 1) accept on SMTP level and send NDN later or 2) reject RCPT TO on SMTP level or 3) reject SMTP level after DATA If there is not HDR=UTF8 paramater, but there is full recursive parser, then possibilities are 1) accept message, and downgrade it 2) accept on SMTP level and send NDN later 3) reject SMTP level after DATA (when next hop of any rcpt do not announce UTF8SMTP.) Without HDR=UTF8 paramater there is no possibility - reject RCPT TO on SMTP level > -- > Charles H. Lindsey ---------At Home, doing my own thing------------------------ > Tel: +44 161 436 6131  >    Web: http://www.cs.man.ac.uk/~chl > Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. > PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 14 04:06:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHG5p-0006sz-Jv; Wed, 14 Feb 2007 04:06:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHG5o-0006st-1a for ima@ietf.org; Wed, 14 Feb 2007 04:06:24 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHG5m-0005gh-6j for ima@ietf.org; Wed, 14 Feb 2007 04:06:24 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DAC64259736 for ; Wed, 14 Feb 2007 10:02:10 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19628-05 for ; Wed, 14 Feb 2007 10:02:00 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4801E259735 for ; Wed, 14 Feb 2007 10:02:00 +0100 (CET) Message-ID: <45D2D102.2000007@alvestrand.no> Date: Wed, 14 Feb 2007 10:06:10 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Subject: [EAI] IESG evaluation record for -framework X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Just for your information, here is the current state of play wrt the -framework document. I am replying to the two outstanding DISCUSSes. Harald To: Internet Engineering Steering Group From: IESG Secretary Reply-To: IESG Secretary Subject: Evaluation: draft-ietf-eai-framework-05.txt to Informational RFC -------- Evaluation for draft-ietf-eai-framework-05.txt can be found at https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14701&rfc_flag=0 Last Call to expire on: 2007-01-26 Please return the full line with your position. Yes No-Objection Discuss Abstain Jari Arkko [ ] [ ] [ X ] [ ] Ross Callon [ ] [ X ] [ ] [ ] Brian Carpenter [ ] [ X ] [ ] [ ] Lisa Dusseault [ ] [ ] [ ] [ ] Lars Eggert [ ] [ ] [ X ] [ ] Bill Fenner [ ] [ ] [ ] [ ] Ted Hardie [ X ] [ ] [ ] [ ] Sam Hartman [ X ] [ ] [ ] [ ] Russ Housley [ ] [ X ] [ . ] [ ] Cullen Jennings [ ] [ X ] [ ] [ ] David Kessens [ ] [ ] [ . ] [ X ] Jon Peterson [ ] [ ] [ ] [ ] Dan Romascanu [ ] [ X ] [ ] [ ] Mark Townsley [ ] [ ] [ ] [ ] Magnus Westerlund [ ] [ X ] [ ] [ ] "Yes" or "No-Objection" positions from 2/3 of non-recused ADs, with no "Discuss" positions, are needed for approval. DISCUSSES AND COMMENTS: ====================== Jari Arkko: Discuss [2007-02-08]: I believe this is important work and long overdue. I do have a question abou the server downgrade behaviour, however: > Since the final delivery SMTP server (or, to be more specific, its > corresponding mail storage agent) cannot safely assume that agents > accessing email storage will always be capable of handling the > extensions proposed here, it MAY either downgrade internationalized > emails or specially identify messages that utilize these extensions, > or both. If this done, the final delivery SMTP server SHOULD include > a mechanism to preserve or recover the original internationalized > forms without information loss to support access by UTF8SMTP-aware > agents. Does this suggest that the final server downgrades mails without knowing that the client is uncapable of reading them in the internationalized form? This seems surprising. Can you elaborate why? And what is the identification mechanism, and how does it affect POP/IMAP access to the messages? Comment [2007-02-08]: > US-ASCII character repertoire, use of punycode on the right hand The term Punycode is used here without reference or definition. Brian Carpenter: Comment [2007-02-02]: Some changes expected following Gen-ART review at http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-eai-framework-04-sparks.txt [anchor...] notes need to be removed Lars Eggert: Discuss [2007-02-05]: Section 6.5., paragraph 1: > [[anchor16: WGLC, "Framework 7": This section tentatively added to > keep track of the relevant text. There may not be consensus for it > in this form (or at all).]] DISCUSS: I didn't expect such a comment in a document that makes it to the IESG. Is there consensus and the anchor should be removed, or is there still no consensus? Section 6.6., paragraph 1: > [[anchor18: WGLC, "Framework 3": This section tentatively added to > keep track of the relevant text. There may not be consensus for it > in this form (or at all).]] DISCUSS: Same issue as above. Comment [2007-02-05]: Contains a bunch of other comments ("[[anchorX...]]") that should probably be removed. Sam Hartman: Comment [2007-02-08]: me too on removing the anchors. Besides that a really solid document. Strong disagreement with most of David's discuss, especially the parts that refer to the abstract. Russ Housley: Comment [2007-02-06]: I agree with Lars, the various [anchorX...] notes need to be resolved before IESG approval. I'll let Lars hold the DISCUSS position on this point. Section 11 should be deleted before publication as an RFC. Cullen Jennings: Comment [2007-02-08]: In section 9 it says that this work "must not leave the Internet less secure than it is". I worry that this is too strong - I think this work inherently will make the internet slightly less secure due to the homograph issues discussed. However, I think that is a trade off worth making. I would hate to see the later protocol documents held up because of this text. David Kessens: Comment [2007-02-09]: >From a procedural point, I am quite unhappy that this draft changed in the middle of the telechat review period. We specifically discourage this as it causes us to have to do a review twice. It would have been more appropriate to remove the defer review of this document to a telechat where it was actually ready. In '1. Introduction': Without the extensions specified in this document, the mailbox name is restricted to a subset of 7-bit ASCII [RFC2821]. And this is probably a good thing as far as me concerned (note that my native language includes characters that cannot be represented in 7-bit ASCII) In section '1.2. Problem statement': If the names and initials used in email addresses can be expressed in the native languages and writing systems of the users, the Internet will be perceived as more natural, especially by those whose native language is not written in a subset of a Roman-derived script. In addition, the use of internationaled email addresses will serve to fragmentize the email name address namespace, thereby fragmenting and isolating people by making it harder to communicate with people that use different charactersets and thus undermining the usefulness of email. In section '7. Experimental Targets': un-upgraded I cannot wait to see what kind of word the RFC editor is going to use instead of this one ;-). ------ Please see below for the original text of my DISCUSS: Most people are probably aware that I am not a big fan of this effort. However, this was unfortunately chartered as I seem to be the only AD with this position. As such I don't believe that I can stop this work. However, I do feel that there are inaccuracies that need to be fixed. After that has been fixed, I will change my position to an ABSTAIN. In 'Abstract:': Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. There is absolutely no requirement to use peoples own name to be able to fully use email. In fact, there is and has been a long tradition to use something else than one's own name and there are countries who use other scripts but have had no difficulties at all to use email. In section '4.3. Downgrading Mechanism for Backward Compatibility' and the selection of potential intermediate relays is under the control of the administration of the final delivery server. This seems a rather optimistic assumption. The first of these two options, that of rejecting or returning the message to the sender MAY always be chosen. This is a completely unacceptable approach: emails that conform to the spec should be delivered. emails success is based on the fact that it is an extremely robust service and delivery is almost guaranteed. Therefore, some form of backwards compatibility will be required, rejecting or returning messages doesn't follow that approach. In section '9. Security Considerations': It should be noted that one of the proposed fixes for, e.g., domain names in URLs, does not work for email local parts since they are case-sensitive. This text is ambiguous. It is not clear what the 'they' refers to. (and it might need more work as both domain names and local parts are case-insensitive as far as I know - please correct me if I am wrong!) The requirements and mechanisms documented in this set of specifications do not, in general, raise any new security issues. This is factually incorrect as explained in this section itself. Internationalization has issues for domains, and it will introduce the same issues for email while this was previously not a problem. Dan Romascanu: Comment [2007-02-07]: I support Lars' DISCUSS concerning the need to remove the [anchor ...] comments prior to IESG approval. ^L ---- following is a DRAFT of message to be sent AFTER approval --- From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , eai mailing list , eai chair Subject: Document Action: 'Overview and Framework for Internationalized Email' to Informational RFC The IESG has approved the following document: - 'Overview and Framework for Internationalized Email ' as an Informational RFC This document is the product of the Email Address Internationalization Working Group. The IESG contact persons are Ted Hardie and Lisa Dusseault. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-04.txt Technical Summary Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. Working Group Summary The decision to not provide any means of "automatic encapsulation" of UTF-8 email addresses, but instead insist that the sender specify an alternate address for downgrading purposes was controversial, but was definitely the decision of the working group. Document Quality This document is not subject to independent implementation, but the Chairs believe that it will be a useful tool in producing further specifications and guiding subsequent efforts. The Document Shepherd is Harald Alvestrand. The responsible AD is Ted Hardie.Note to RFC Editor (Insert note to RFC Editor here) IESG Note (Insert IESG Note here) IANA Note (Insert IANA Note here) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 14 04:07:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHG7H-0007VL-C1; Wed, 14 Feb 2007 04:07:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHG7G-0007V2-Py for ima@ietf.org; Wed, 14 Feb 2007 04:07:54 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHG7F-0005uB-Fl for ima@ietf.org; Wed, 14 Feb 2007 04:07:54 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 439D4259738; Wed, 14 Feb 2007 10:03:42 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19382-10; Wed, 14 Feb 2007 10:03:36 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2A865259735; Wed, 14 Feb 2007 10:03:36 +0100 (CET) Message-ID: <45D2D162.4030405@alvestrand.no> Date: Wed, 14 Feb 2007 10:07:46 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: "Fax test" (Re: [EAI] other thought about >) References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> <8EF038A6C37EE47F7977B22C@p3.JCK.COM> <20070208124121.GL19841@ns5.lsb.org> <4BA9BC2B529E6905F10E3E00@[192.168.1.108]> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > On Sat, 10 Feb 2007 10:02:00 -0000, Harald Tveit Alvestrand > wrote: > >> My memory says that you proposed the fax test, and the WG rejected it. >> After all, the fax test fails for many occurences of USER05 vs USERO5. > > It was not a matter of accepting or rejecting it, because it is not a > feature to in in(ex)cluded in any draft. Rather it is a self-evidently > useful yardstick that should aid in deciding between various proposals > that might be under discussion. It is, however, rejected, so the claim that it's "self-evidently useful" has self-evidently failed. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 14 04:30:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHGT8-0001Vh-Gd; Wed, 14 Feb 2007 04:30:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHGT7-0001VR-PD; Wed, 14 Feb 2007 04:30:29 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHGT6-0001z6-9p; Wed, 14 Feb 2007 04:30:29 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0E8DB25973A; Wed, 14 Feb 2007 10:26:17 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20003-06; Wed, 14 Feb 2007 10:26:10 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 80129259738; Wed, 14 Feb 2007 10:26:10 +0100 (CET) Message-ID: <45D2D6AD.20701@alvestrand.no> Date: Wed, 14 Feb 2007 10:30:21 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Jari Arkko Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: iesg@ietf.org, EAI WG Subject: [EAI] Your DISCUSS on draft-ietf-eai-framework-05 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org (Apologies for my previous mail, which should have been addressed to Lars Eggert) You raised an issue at IESG, with the following text: > Jari Arkko: > > Discuss [2007-02-08]: > I believe this is important work and long overdue. > I do have a question abou the server downgrade > behaviour, however: > > > Since the final delivery SMTP server (or, to be more specific, its > > corresponding mail storage agent) cannot safely assume that agents > > accessing email storage will always be capable of handling the > > extensions proposed here, it MAY either downgrade internationalized > > emails or specially identify messages that utilize these extensions, > > or both. If this done, the final delivery SMTP server SHOULD include > > a mechanism to preserve or recover the original internationalized > > forms without information loss to support access by UTF8SMTP-aware > > agents. > > Does this suggest that the final server downgrades mails > without knowing that the client is uncapable of reading > them in the internationalized form? This seems surprising. > Can you elaborate why? And what is the identification mechanism, > and how does it affect POP/IMAP access to the messages? Since this is an issue with a bit of substance, I'm CCing the WG on this note. The issue with POP and IMAP servers is that there is no knowing what kind of client software the user will use to connect to the mail store the *next* time it connects. Especially in the case of IMAP, it is not uncommon to connect to a single mailbox using multiple clients (often including a Web client) - at the same time, serially, or switching randomly between them. So not only is the final delvery agent incapable of knowing the client's capabilities, it wouldn't help if it knew at the time of delivery, because the capabilities might change at any time. And messages in mailstores last for years, unline messages in transit, which generally expire after days at most, so it is very possible that a client's capabilities will change over the lifetime of the message in the mailstore. What is knowable is whether or not the *mailbox server* is capable of supporting UTF8SMTP; in the case of delivery via SMTP or LMTP, the "UTF8SMTP" extension is a good way of signalling such support. The issues in the specific context of IMAP and POP, including identification mechanisms, are addressed in the drafts specific to these protocols; however, I think it would not be appropriate to go into details on those protocols in an overview document - also because those proposals are still under discussion by the WG, and might change considerably before they are finished. I don't know if this is enough clarification of why the text is the way it is - do you need more information to clear your DISCUSS? Harald, document shepherd _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 14 09:35:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHLDr-000592-Af; Wed, 14 Feb 2007 09:35:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHJKS-0002sY-2x; Wed, 14 Feb 2007 07:33:44 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHJKP-0005b7-KE; Wed, 14 Feb 2007 07:33:44 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 55120198777; Wed, 14 Feb 2007 14:33:36 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D9AC61986AF; Wed, 14 Feb 2007 14:33:35 +0200 (EET) Message-ID: <45D3019F.7070807@piuha.net> Date: Wed, 14 Feb 2007 14:33:35 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Harald Alvestrand References: <45D2D6AD.20701@alvestrand.no> In-Reply-To: <45D2D6AD.20701@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-Mailman-Approved-At: Wed, 14 Feb 2007 09:35:01 -0500 Cc: iesg@ietf.org, EAI WG Subject: [EAI] Re: Your DISCUSS on draft-ietf-eai-framework-05 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >> >> > Since the final delivery SMTP server (or, to be more specific, its >> > corresponding mail storage agent) cannot safely assume that agents >> > accessing email storage will always be capable of handling the >> > extensions proposed here, it MAY either downgrade internationalized >> > emails or specially identify messages that utilize these extensions, >> > or both. If this done, the final delivery SMTP server SHOULD include >> > a mechanism to preserve or recover the original internationalized >> > forms without information loss to support access by UTF8SMTP-aware >> > agents. >> >> Does this suggest that the final server downgrades mails >> without knowing that the client is uncapable of reading >> them in the internationalized form? This seems surprising. >> Can you elaborate why? And what is the identification mechanism, >> and how does it affect POP/IMAP access to the messages? > Since this is an issue with a bit of substance, I'm CCing the WG on > this note. > The issue with POP and IMAP servers is that there is no knowing what > kind of client software the user will use to connect to the mail store > the *next* time it connects. > > Especially in the case of IMAP, it is not uncommon to connect to a > single mailbox using multiple clients (often including a Web client) - > at the same time, serially, or switching randomly between them. > Right. > So not only is the final delvery agent incapable of knowing the > client's capabilities, it wouldn't help if it knew at the time of > delivery, because the capabilities might change at any time. And > messages in mailstores last for years, unline messages in transit, > which generally expire after days at most, so it is very possible that > a client's capabilities will change over the lifetime of the message > in the mailstore. > Exactly. That is why it is important that we do not downgrade mail permanently if we can avoid it. I reacted to the text because it seemed to be saying that. Specifically, it says the storage agent may downgrade i18n e-mail. Does that mean that it would actually downgrade it in the storage, or just for the purpose of serving it to this particular client at this one time? > What is knowable is whether or not the *mailbox server* is capable of > supporting UTF8SMTP; in the case of delivery via SMTP or LMTP, the > "UTF8SMTP" extension is a good way of signalling such support. > > The issues in the specific context of IMAP and POP, including > identification mechanisms, are addressed in the drafts specific to > these protocols; however, I think it would not be appropriate to go > into details on those protocols in an overview document - also because > those proposals are still under discussion by the WG, and might change > considerably before they are finished. Fair enough. > > I don't know if this is enough clarification of why the text is the > way it is - do you need more information to clear your DISCUSS? Let me suggest a small reformulation: Since the final delivery SMTP server (or, to be more specific, its corresponding mail storage agent) cannot safely assume that agents accessing email storage will always be capable of handling the extensions proposed here, it MAY either provide a downgraded version of the internationalized email to these agents, or specially identify messages that utilize these extensions, or both. In any case, the final delivery SMTP server SHOULD allow the original internationalized forms to be accessed by UTF8SMTP-aware agents without information loss, even if they are also accessed in downgraded form by other agents. Jari _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 14 09:47:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHLPM-00021S-U6; Wed, 14 Feb 2007 09:46:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHLPL-00020v-MJ; Wed, 14 Feb 2007 09:46:55 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHLPJ-0005OX-6r; Wed, 14 Feb 2007 09:46:55 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AE32225973A; Wed, 14 Feb 2007 15:42:41 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27810-08; Wed, 14 Feb 2007 15:42:36 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 068F925971B; Wed, 14 Feb 2007 15:42:36 +0100 (CET) Message-ID: <45D320D6.5050509@alvestrand.no> Date: Wed, 14 Feb 2007 15:46:46 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Jari Arkko References: <45D2D6AD.20701@alvestrand.no> <45D3019F.7070807@piuha.net> In-Reply-To: <45D3019F.7070807@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: iesg@ietf.org, EAI WG Subject: [EAI] Re: Your DISCUSS on draft-ietf-eai-framework-05 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Jari Arkko wrote: > >> So not only is the final delvery agent incapable of knowing the >> client's capabilities, it wouldn't help if it knew at the time of >> delivery, because the capabilities might change at any time. And >> messages in mailstores last for years, unline messages in transit, >> which generally expire after days at most, so it is very possible that >> a client's capabilities will change over the lifetime of the message >> in the mailstore. >> >> > > Exactly. That is why it is important that we do not downgrade mail > permanently > if we can avoid it. I reacted to the text because it seemed to be saying > that. Specifically, it says the storage agent may downgrade i18n e-mail. > Does that mean that it would actually downgrade it in the storage, > or just for the purpose of serving it to this particular client at this > one time? > > Actually there are two possible conceptual approaches, which are equivalent seen from the outside: - Store the message in a downgraded format, but with enough information to reconstruct the non-downgraded format. This is faster for old clients, slower for new ones. - Store the message in an UTF8SMTP compatible format, and downgrade at read time. This is faster for new clients, and slower for old ones. Tradeoff. >> What is knowable is whether or not the *mailbox server* is capable of >> supporting UTF8SMTP; in the case of delivery via SMTP or LMTP, the >> "UTF8SMTP" extension is a good way of signalling such support. >> >> The issues in the specific context of IMAP and POP, including >> identification mechanisms, are addressed in the drafts specific to >> these protocols; however, I think it would not be appropriate to go >> into details on those protocols in an overview document - also because >> those proposals are still under discussion by the WG, and might change >> considerably before they are finished. >> > > Fair enough. > > >> I don't know if this is enough clarification of why the text is the >> way it is - do you need more information to clear your DISCUSS? >> > > Let me suggest a small reformulation: > > Since the final delivery SMTP server (or, to be more specific, its > corresponding mail storage agent) cannot safely assume that agents > accessing email storage will always be capable of handling the > extensions proposed here, it MAY either provide a downgraded > version of the internationalized email to these agents, or > specially identify messages that utilize these extensions, > or both. In any case, the final delivery SMTP server SHOULD allow > the original internationalized forms to be accessed by UTF8SMTP-aware > agents without information loss, even if they are also accessed > in downgraded form by other agents. I'll have to think about whether that actually says what I want it to say..... _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 14 09:57:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHLZ7-0007Ak-4B; Wed, 14 Feb 2007 09:57:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHLZ6-0007AW-25; Wed, 14 Feb 2007 09:57:00 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHLZ4-0006k8-Ll; Wed, 14 Feb 2007 09:57:00 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 630BE198774; Wed, 14 Feb 2007 16:56:55 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 181BE19862E; Wed, 14 Feb 2007 16:56:55 +0200 (EET) Message-ID: <45D32337.5060702@piuha.net> Date: Wed, 14 Feb 2007 16:56:55 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Harald Alvestrand References: <45D2D6AD.20701@alvestrand.no> <45D3019F.7070807@piuha.net> <45D320D6.5050509@alvestrand.no> In-Reply-To: <45D320D6.5050509@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: iesg@ietf.org, EAI WG Subject: [EAI] Re: Your DISCUSS on draft-ietf-eai-framework-05 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald, >> >> Exactly. That is why it is important that we do not downgrade mail >> permanently >> if we can avoid it. I reacted to the text because it seemed to be saying >> that. Specifically, it says the storage agent may downgrade i18n e-mail. >> Does that mean that it would actually downgrade it in the storage, >> or just for the purpose of serving it to this particular client at this >> one time? >> >> > Actually there are two possible conceptual approaches, which are > equivalent seen from the outside: > > - Store the message in a downgraded format, but with enough > information to reconstruct the non-downgraded format. This is faster > for old clients, slower for new ones. > - Store the message in an UTF8SMTP compatible format, and downgrade at > read time. This is faster for new clients, and slower for old ones. > > Tradeoff. Sure. But if these are equivalent from the outside, maybe we should not be debating how to do it... the external behavior matters. (See also the last sentence of my proposed text.) > I'll have to think about whether that actually says what I want it to > say..... > Ok. Jari _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 14 10:23:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHLyR-0002wM-Na; Wed, 14 Feb 2007 10:23:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHLyQ-0002w6-L6; Wed, 14 Feb 2007 10:23:10 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHLyN-0002A8-Vj; Wed, 14 Feb 2007 10:23:10 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HHLyL-000NrH-6N; Wed, 14 Feb 2007 10:23:05 -0500 Date: Wed, 14 Feb 2007 10:23:04 -0500 From: John C Klensin To: Jari Arkko , Harald Alvestrand Subject: Re: [EAI] Re: Your DISCUSS on draft-ietf-eai-framework-05 Message-ID: In-Reply-To: <45D3019F.7070807@piuha.net> References: <45D2D6AD.20701@alvestrand.no> <45D3019F.7070807@piuha.net> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: iesg@ietf.org, EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Jari, The IETF has never specified what happens between the point at which the delivery MTA receives a message and the point at which something that a mail reader connects to (a direct mailbox-reader, POP or IMAP client, internal delivery mechanism such as LMTP, etc.) might pick it up. Our lack of specifications in that area has been intentional and conscious, not an accident. But the absence of such specifications makes it hard to specify how they should be extended for i18n email. We talk about "mailboxes" a lot but they are an abstraction without a precise definition (other than the 2821/2822 definition how they are named externally and the POP/IMAP definitions of how they are named for access purposes). In particular, suppose one assumes a model based on an intermediate "mail store" (that model is _not_ required by anything we now have standardized. We lack protocols or specifications for delivery-MTA -> mail store Format of mail store Format of data in mail store and what metadata are stored. API, primitives, or protocol for accessing the mail store from (POP, IMAP, LMAP, and other protocols) I suggest that assuming enough about those things, starting with whether a mail store is required at all, to start specifying i18n details is dangerous as well as hard and that putting in further details would have us dancing on extremely thin ice. More below. --On Wednesday, 14 February, 2007 14:33 +0200 Jari Arkko wrote: >... >> So not only is the final delvery agent incapable of knowing >> the client's capabilities, it wouldn't help if it knew at the >> time of delivery, because the capabilities might change at >> any time. And messages in mailstores last for years, unline >> messages in transit, which generally expire after days at >> most, so it is very possible that a client's capabilities >> will change over the lifetime of the message in the mailstore. > > Exactly. That is why it is important that we do not downgrade > mail permanently > if we can avoid it. I reacted to the text because it seemed to > be saying that. Specifically, it says the storage agent may > downgrade i18n e-mail. Does that mean that it would actually > downgrade it in the storage, or just for the purpose of > serving it to this particular client at this one time? If the interface between the delivery-MTA and the mailstore (assuming there is one) is only capable of a legacy seven-bit path, and the mailstore only offers legacy seven-bit interfaces to things that read from it, then: (i) It is fairly stupid for the delivery-MTA to be offering these extensions at all because doing so will almost certainly cause a loss of information. We can't prohibit that, because it is on the far side of a delivery boundary, but there is no question, with just about any protocol, that stupidity can be a source of problems. (ii) Because these interfaces are unspecified, all sorts of recoding options (not just downgrading in the sense specified by the WG) are available to a mailstore that has some knowledge of the upgrades and intelligence about what is going on, even if its only storage options are 7bit. But the bottom line is (i) yes, the message might be downgraded before being stored if that seems to be the right thing to do (ii) smart implementations won't get themselves into that situation. But (ii) is not unlike a ban on stupidity. >> I don't know if this is enough clarification of why the text >> is the way it is - do you need more information to clear your >> DISCUSS? > > Let me suggest a small reformulation: > > Since the final delivery SMTP server (or, to be more specific, > its corresponding mail storage agent) cannot safely assume > that agents accessing email storage will always be capable of > handling the extensions proposed here, it MAY either provide a > downgraded version of the internationalized email to these > agents, or specially identify messages that utilize these > extensions, or both. In any case, the final delivery SMTP > server SHOULD allow the original internationalized forms to be > accessed by UTF8SMTP-aware agents without information loss, > even if they are also accessed in downgraded form by other > agents. I am, personally, opposed to this change. It assumes a model of post-delivery processing that we have not standardized. It assumes identification models have have been hotly debated in the WG and concluded to be out of scope. It imposes a conformance requirement that is either so trivial and obvious as to constitute a ban on stupidity or that requires the MTA implementer to require the impossible (that the "mail storage agent" be concurrently upgraded and in just the right way)... or it imposes requirements on something whose existence we haven't standardized. At most, I think we could add a statement that says that it would be ill-advised (and inconsistent with existing 2821 provisions prohibiting accepting mail that one expects to trash) for a system to offer i18n extensions and mailbox names unless it was capable of preserving the information in those messages through to the message-receiving endpoint to the maximum limit of that endpoints capabilities. But, if we need to do that, I propose, not entirely in jest, that we add a "Stupidity Considerations" section and put this advice, and some related points, into it. :-( Again, my opinion only. regards, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 14 11:10:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMiJ-0003T7-L2; Wed, 14 Feb 2007 11:10:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMi2-0002vC-PZ; Wed, 14 Feb 2007 11:10:19 -0500 Received: from ppsw-2.csi.cam.ac.uk ([131.111.8.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHMgR-0007wl-Fv; Wed, 14 Feb 2007 11:08:44 -0500 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-1.csi.cam.ac.uk ([131.111.8.51]:45024) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1HHMfl-0003Dn-7X (Exim 4.63) (return-path ); Wed, 14 Feb 2007 16:07:57 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HHMfk-0001Cg-Hq (Exim 4.54) (return-path ); Wed, 14 Feb 2007 16:07:56 +0000 Date: Wed, 14 Feb 2007 16:07:56 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin Subject: Re: [EAI] Re: Your DISCUSS on draft-ietf-eai-framework-05 In-Reply-To: Message-ID: References: <45D2D6AD.20701@alvestrand.no> <45D3019F.7070807@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Jari Arkko , iesg@ietf.org, EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 14 Feb 2007, John C Klensin wrote: > > The IETF has never specified what happens between the point at > which the delivery MTA receives a message and the point at which > something that a mail reader connects to [...] might pick it up. I don't think this is entirely true. For example, (2)821 talks about "final delivery" although I admit that it means little more than appending a Return-Path: field. > In particular, suppose one assumes a model based on an intermediate > "mail store" (that model is _not_ required by anything we now have > standardized. We lack protocols or specifications for > delivery-MTA -> mail store LMTP is a counter example. It's experimental rather than standards-track, and I understand that this is because it's supposedly just a private arrangement within an organization. However there are multiple interoperable implementations of LMTP, both clients and servers, and it's normal for each end of an LMTP connection to be software from different vendors. This is exactly what standards are supposed to be about. Also, the "private arrangement" argument is bogus since it also applies to POP and IMAP, and many other Internet standards. ODMR also fits somewhere in this space - between the MX and the message store - though it's closer to the MX than the message store. (LMTP is closer to the message store than the MX.) Fortunately the EAI SMTP extension should just work with both LMTP and ODMR. > Format of data in mail store and what metadata are stored. > API, primitives, or protocol for accessing the mail store > from (POP, IMAP, LMAP, and other protocols) I'm not sure what distinction you are getting at here. IMAP specifies in some detail the mailbox metadata that MUAs must be able to store and retrieve, and of course IMAP and POP are protocols for accessing mail stores. I agree that message store formats and APIs are not topics for IETF standardization, and this is a good thing - there's plenty of good competition in the IMAP server space developing more efficient message store formats. > On Wednesday, 14 February, 2007 14:33 +0200 Jari Arkko wrote: > > > > Since the final delivery SMTP server (or, to be more specific, > > its corresponding mail storage agent) cannot safely assume > > that agents accessing email storage will always be capable of > > handling the extensions proposed here, it MAY either provide a > > downgraded version of the internationalized email to these > > agents, or specially identify messages that utilize these > > extensions, or both. In any case, the final delivery SMTP > > server SHOULD allow the original internationalized forms to be > > accessed by UTF8SMTP-aware agents without information loss, > > even if they are also accessed in downgraded form by other > > agents. No, this is a job for the message store (i.e. POP or IMAP server) not any SMTP server. Message delivery into the message store (e.g. over LMTP) must be internationalized if the message store wants to be able to serve UTF-8 email to MUAs. Tony. -- f.a.n.finch http://dotat.at/ DOGGER: MAINLY SOUTHERLY 4 OR 5 INCREASING 6 OR 7. MODERATE, INCREASING ROUGH LATER. RAIN AT FIRST. MODERATE OR GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 14 23:36:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHYM5-0001Gm-3H; Wed, 14 Feb 2007 23:36:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHYM4-0001Gh-Iu for ima@ietf.org; Wed, 14 Feb 2007 23:36:24 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHYM1-0004tL-SK for ima@ietf.org; Wed, 14 Feb 2007 23:36:24 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l1F4aEJ5023539; Thu, 15 Feb 2007 13:36:14 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l1F4aDuC023536; Thu, 15 Feb 2007 13:36:13 +0900 Date: Thu, 15 Feb 2007 13:36:13 +0900 From: Soobok Lee To: John C Klensin Subject: Re: Unicode presentation-formatting characters (Re: [EAI] Re: other thought about >) Message-ID: <20070215043613.GE24872@ns5.lsb.org> References: <20070212234036.GA24872@ns5.lsb.org> <346B8D9E0284D6AC352A98AA@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <346B8D9E0284D6AC352A98AA@p3.JCK.COM> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, Feb 13, 2007 at 01:53:53PM -0500, John C Klensin wrote: > > But that was the point of mentioning the ASCII control > characters that are often used for code-table-shifting. While > they are permitted in local parts on the wire, SI/SO/ESC escaping sequences are permitted in quoted-form local-part like "any_chars"@evil1.tld under RFC2822. Quoted display-name and comment can contain such strings as well. Such code-table-shifting based attacks are restricted by code tables and surrounding quotations marks. Forged email addresses using them will look so bizarre, so easily detected by end users. But, that RLO (and <>'s NFKC-equivalents) examples do not change end user's default code table to achieve elaborate impersonations of arbitrary email domain name origins. > almost every > self-respecting MUA will go beyond the "wire" standard, either > imposing special quoting or simply deleting them before > transmitting or presenting the message. The result is that a > phishing technique based on the use of such characters becomes > fairly ineffective. I would assume we would see the same > behavior with formatting code points in Unicode. > One could > write a document explicitly suggesting such things if one wanted > to, but it is not part of this WG's task to generate, or even > review, such a thing (i.e., please don't turn this into another > long and distracting discussion on the WG mailing list). Is there any active WG that can accept such topic other than this WG? As you know, IDNA and IDNA-update are very strict about permitted Unicode characters in domain name parts of EAI email addresses. If they contain RLO, they will be rejected and return errors to users. BTW, I am curious when idna-update list will be a formal WG. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 15 01:13:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHZrK-0008Us-FG; Thu, 15 Feb 2007 01:12:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHZrJ-0008UW-EQ for ima@ietf.org; Thu, 15 Feb 2007 01:12:45 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHZrI-0000pf-4P for ima@ietf.org; Thu, 15 Feb 2007 01:12:45 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0880A259757; Thu, 15 Feb 2007 07:08:32 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24235-01; Thu, 15 Feb 2007 07:08:25 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 37043259756; Thu, 15 Feb 2007 07:08:25 +0100 (CET) Message-ID: <45D3F9D2.9060108@alvestrand.no> Date: Thu, 15 Feb 2007 07:12:34 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Soobok Lee Subject: Re: Unicode presentation-formatting characters (Re: [EAI] Re: other thought about >) References: <20070212234036.GA24872@ns5.lsb.org> <346B8D9E0284D6AC352A98AA@p3.JCK.COM> <20070215043613.GE24872@ns5.lsb.org> In-Reply-To: <20070215043613.GE24872@ns5.lsb.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Soobok Lee wrote: > On Tue, Feb 13, 2007 at 01:53:53PM -0500, John C Klensin wrote: > >> But that was the point of mentioning the ASCII control >> characters that are often used for code-table-shifting. While >> they are permitted in local parts on the wire, >> > > SI/SO/ESC escaping sequences are permitted in quoted-form local-part > like "any_chars"@evil1.tld under RFC2822. Quoted display-name and > comment can contain such strings as well. > > Such code-table-shifting based attacks are restricted by code tables and > surrounding quotations marks. Forged email addresses using them will look > so bizarre, so easily detected by end users. > There used to be a fairly well known ESC hack for VT100 terminals that would reprogram a softkey on the terminal and trigger it - effectively forcing the terminal to send a text string defined by the attacker to the computer if the string was displayed. For instance "rm -rf /". Applications usually don't "display" ESC, and for good reason. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 15 06:32:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHeqb-0005GJ-7e; Thu, 15 Feb 2007 06:32:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHeqZ-0005G2-Fs for ima@ietf.org; Thu, 15 Feb 2007 06:32:19 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHeqS-0006vB-QI for ima@ietf.org; Thu, 15 Feb 2007 06:32:19 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3^clerew$man&ac*uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45d444bb.154bc.35f for ima@ietf.org; Thu, 15 Feb 2007 11:32:11 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l1FBWAjg023896 for ; Thu, 15 Feb 2007 11:32:11 GMT To: IMA Subject: Re: [EAI] HDR=UTF8 paramater or not? (Re: ESMTP -- is bounce only (no downgrade) allowed) References: <5dwt2pgpoe.fsf@Hurtta06k.keh.iki.fi> <5dlkj16sr8.fsf_-_@leija.fmi.fi> Message-ID: Date: Thu, 15 Feb 2007 11:32:09 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5dlkj16sr8.fsf_-_@leija.fmi.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 14 Feb 2007 08:35:55 -0000, Kari Hurtta wrote: > "Charles Lindsey" writes in gmane.ietf.ima: >> And there again, this WG seems to have decided that systems are >> expected to do the full recursive descent check regardless (that is >> why we got rid of Header-Type, which was a far better marker for the >> existence of UTF8SMTP in the message than HDR=UTF8 would be). > > On consensus call there was: > > | Note that this is not a call on the proposal to have a similar marker > | in the SMTP protocol; that's a separate issue. > > So I was analyzing on what situations HDR=UTF8 parameter is required. > I'm assuming that this parameter goes to MAIL command. Oh! I had supposed it would go with the DATA command, since it gives information about the message that is to follow. > > Seems that it is required, if WG want allow MTAs to announce UTF8SMTP > without full recursive mime structure parsers. Sure, but the WG seemed not to be wanting to do that. If you want to avoid a full recursive descent, and provide HDR=UTF8 in order to achieve that, then you might as well provide Header-Type as well. So in practice the decision not to allow Header-Type seems to force the other decision as well. But if the WG still wants to go that route, then I don't object - but OTOH I hear no clamour to do so. The WG seems happy to accept recursive descent. I didn't like it (and still don't), but I now see that it is not as inefficient as I had thought it might be, though there are still uncertainties on how to handle message types -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 15 07:06:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHfNZ-0003d4-LL; Thu, 15 Feb 2007 07:06:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHfNY-0003cz-Jp for ima@ietf.org; Thu, 15 Feb 2007 07:06:24 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHfNT-0003CT-W6 for ima@ietf.org; Thu, 15 Feb 2007 07:06:24 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3$clerew*man^ac#uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45d44cba.57ae.9a for ima@ietf.org; Thu, 15 Feb 2007 12:06:18 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l1FC6Gud025939 for ; Thu, 15 Feb 2007 12:06:18 GMT To: IMA Subject: Re: [EAI] Re: Your DISCUSS on draft-ietf-eai-framework-05 References: <45D2D6AD.20701@alvestrand.no> <45D3019F.7070807@piuha.net> Message-ID: Date: Thu, 15 Feb 2007 12:06:16 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 14 Feb 2007 15:23:04 -0000, John C Klensin wrote: > We talk about "mailboxes" a lot but they are an abstraction > without a precise definition (other than the 2821/2822 > definition how they are named externally and the POP/IMAP > definitions of how they are named for access purposes). > > In particular, suppose one assumes a model based on an > intermediate "mail store" (that model is _not_ required by > anything we now have standardized. We lack protocols or > specifications for > delivery-MTA -> mail store > Format of mail store > Format of data in mail store and what metadata are stored. > API, primitives, or protocol for accessing the mail store > from (POP, IMAP, LMAP, and other protocols) I think it is clear from the existence of RFCs defining the POP3 and IMAP protocols that "mail stores" undoubtedly exist (and that "mailboxes" must exist inside them). Moreover, those protocols pretty well constrain what is kept inside those stores - just that what we specify is the external view visible through the protocols, rather than the actual format inside them. And we do not expect to be able to use the IMAP protocol on a store designed for POP3 (though the converse might be possible). So I see no harm in referring to "mail stores" in our documewnts. Moreover, since our drafts define UTF8SMTP extensions for both POP3 and IMAP, we should be able to use the term "UTF8SMTP extended mail store" to describe a mail store capable of being accessed by our extended POP3 or IMAP. And then all we need to say is that if the "final delivery" MTA knows (and it needs to know) that it is being asked to store into an extended mail store, then it does not downgrade, and if it is being asked to store into an un-extended mail store then it MUST downgrade (or bounce). And that is all we should say. So it is none of our business whether, in communicating with a supposedly extended mail store, the data is compressed into 7-bits in a manner which enables it subsequently to be restored to 8-bit (as you say, if implementors are determined to be stupid, then we can't stop them). So indeed the present wording says too much. And likewise, it is none of the MTA's business how the mail store negotiates with the final user as to whether he sees an up- or down-graded nessage, though that IS a matter for our POP3 and IMAP drafts, and some mention of those drafts in the framework document might be useful at this point. >> Let me suggest a small reformulation: >> >> Since the final delivery SMTP server (or, to be more specific, >> its corresponding mail storage agent) cannot safely assume >> that agents accessing email storage will always be capable of >> handling the extensions proposed here, it MAY either provide a >> downgraded version of the internationalized email to these >> agents, or specially identify messages that utilize these >> extensions, or both. In any case, the final delivery SMTP >> server SHOULD allow the original internationalized forms to be >> accessed by UTF8SMTP-aware agents without information loss, >> even if they are also accessed in downgraded form by other >> agents. > > I am, personally, opposed to this change. It assumes a model of > post-delivery processing that we have not standardized. It is an improvement on the present text, but I agree with you that it still goes too far. What we need is a text that says that it is the job of the mail storage agent (if it supports UTF8SMTP extensions at all) to arrange that UTF8SMTP-aware user agents see UTF8 and others don't. With reference to our POP3 and IMAP drafts. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 15 18:12:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHpmC-0003DC-HY; Thu, 15 Feb 2007 18:12:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHpmB-0003D7-1h for ima@ietf.org; Thu, 15 Feb 2007 18:12:31 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHpm0-0004Hl-Ct for ima@ietf.org; Thu, 15 Feb 2007 18:12:31 -0500 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1FNCJbi010192 for ; Thu, 15 Feb 2007 16:12:19 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JDJ003011MQ2J00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Thu, 15 Feb 2007 16:12:19 -0700 (MST) Received: from [10.1.110.5] ([129.153.188.127]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JDJ00CKM1SHFO40@mail-amer.sun.com>; Thu, 15 Feb 2007 16:12:19 -0700 (MST) Date: Thu, 15 Feb 2007 15:12:39 -0800 From: Chris Newman Subject: Re: [EAI] Re: Summary of the "BODY problems" thread(s) In-reply-to: To: Charles Lindsey , IMA Message-id: <859EF3AD619BF900F10F5C4C@nifty-silver.stc.com> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: inline References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> <45C63889.6BEB@xyzzy.claranet.de> <5dhctzs52f.fsf@Hurtta06k.keh.iki.fi> <5dire8vca9.fsf@Hurtta06k.keh.iki.fi> <45CFC714.4B8E@xyzzy.claranet.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org MIME today has three types of body parts: 1. unstructured body parts. 2. structured body parts: multipart/*, message/rfc822 3. quasi-structured body parts: application/zip, etc All compliant MIME agents are required to process types 1 and 2 consi= stently. For case 3, which has never been formalized, MIME agents are not requ= ired to=20 understand or descend the quasi-structured body part (further, the ne= sted=20 encoding restriction has already been ignored by the real-world). Bu= t certain=20 MIME agents are fundamentally broken if they don't descent the quasi-= structured=20 part. In the case of application/zip, any virus scanner which fails = to descend=20 the structure is just plain broken. The intention of message/utf-8 is to be another quasi-structured body= part like=20 application/zip. In this case, we expect UTF-8 header aware agents t= o descend=20 the structure and we expect non-UTF-8-header agents to not descend th= e=20 structure. There is no requirement for a UTF8SMTP agent to downgrade= a=20 message/utf-8 body part (and in the case of a DSN, I'd say it SHOULD = NOT=20 downgrade message/utf-8). An argument could be made that message/utf= -8 should=20 be "application/utf-8-message" -- I'd consider that discussion helpfu= l and=20 would like to see information about what implementations do with mess= age/utf-8=20 vs. application/utf-8-message so we can make an intelligent choice. I'm strongly opposed to putting UTF-8 header content into a MIME body= part with=20 a message/rfc822 label. Having a label which has different meanings = in=20 different contexts is dangerous and having a data-object label with t= hat=20 property is even more dangerous. MIME agents allow users to save MIM= E bodies=20 to files which don't have any typing context beyond the filename exte= nsion=20 derived from the media type label. I'm much more comfortable that we= 're=20 avoiding installed base breakage if "stuff which traditional agent mi= ght crash=20 or mangle when processing" has a different label so the traditional a= gent won't=20 even attempt to process it. - Chris Charles Lindsey wrote on 2/13/07 21:35 +0000: > On Mon, 12 Feb 2007 01:47:00 -0000, Frank Ellermann > wrote: > >> Kari Hurtta wrote: >> >>> message/utf-8 exists only on draft-ietf-eai-dsn-00.txt >> >> Anything like a message/rfc822 with UTF-8 in its header is a >> message/utf-8, because it obviously can't be a message/rfc822. > > Yes it can, if we extend the definition (within UTF8SMTP messages o= nly, of > course) of message/rfc822 accordingly. That implies, of course, tha= t the > downghrade process must upgrade such 'extended' message/rfc822s, bu= t then we > already agree that it would have to dowbgrade each message/utf-8, s= o the > requirement is exactly the same whatever name we call it by. > > -- > Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own= =A0thing---------------------- > -- > Tel:=A0+44=A0161=A0436=A06131=A0 > =A0=A0=A0Web:=A0http://www.cs.man.ac.uk/~chl > Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewo= od=A0Ave,=A0CHEADLE,=A0SK8=A03JU,=A0U. > K. > PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051= =A093=A0A0=A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0 > A5 > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 15 18:33:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHq5v-000834-1V; Thu, 15 Feb 2007 18:32:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHq5t-00082r-Cf for ima@ietf.org; Thu, 15 Feb 2007 18:32:53 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHq5r-0007Pa-EM for ima@ietf.org; Thu, 15 Feb 2007 18:32:53 -0500 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1FNWo1m005843 for ; Thu, 15 Feb 2007 16:32:50 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JDJ00K0123E8Y00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Thu, 15 Feb 2007 16:32:50 -0700 (MST) Received: from [10.1.110.5] ([129.153.188.127]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JDJ00A6A2QNFR20@mail-amer.sun.com>; Thu, 15 Feb 2007 16:32:50 -0700 (MST) Date: Thu, 15 Feb 2007 15:33:10 -0800 From: Chris Newman Subject: Re: [EAI] Messages on original form (Re: I-D ACTION:draft-ietf-eai-imap-utf8-00.txt) In-reply-to: <5d3b5jhyoi.fsf@Hurtta06k.keh.iki.fi> To: Kari Hurtta , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <5d3b5jhyoi.fsf@Hurtta06k.keh.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org If I put my IMAP/POP server implementer hat on, I have no concept what "original form" means. There's typically only one message form available, which is the form of the message that's in the mail store. More often than not, the IMAP/POP server has no idea how the message got into the mail store or what it looked like before it was delivered. Attempting to make signatures survive message transformation is unnecessary complexity. End-to-end signatures can be embedded in a multipart/signed which already forbids any transformation of the embedded content (the downgrade document should reiterate this restriction, IMHO). - Chris Kari Hurtta wrote on 2/6/07 21:29 +0200: > > Question about imap draft. > > > Is there possible to retrieve mail messages on original from ? > > I think that I missed to something, but it looked like IMAP server > do all messages up conversion or down conversion depending of selected > access method. > > What I have looked for is: > 1) UTF8SMTP messages are returned UTF8SMTP form > > 2) Downgraded UTF8SMTP messages are returned UTF8SMTP form > (ie. selective up conversion) > > 3) Non-UTF8SMTP messages are returned on RFC (2)822 from > (ie. no up conversion) > > That is import for signed messages, I think. > > / Kari Hurtta > > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 16 00:01:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHvDs-0008R4-WB; Fri, 16 Feb 2007 00:01:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHvDp-0008Ok-Us for ima@ietf.org; Fri, 16 Feb 2007 00:01:27 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHvDk-000304-Dd for ima@ietf.org; Fri, 16 Feb 2007 00:01:25 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HHvDb-0006Zt-Qs for ima@ietf.org; Fri, 16 Feb 2007 06:01:11 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Feb 2007 06:01:11 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Feb 2007 06:01:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 16 Feb 2007 07:01:01 +0200 Lines: 177 Message-ID: <5dodnuitma.fsf@Hurtta06k.keh.iki.fi> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> <45C63889.6BEB@xyzzy.claranet.de> <5dhctzs52f.fsf@Hurtta06k.keh.iki.fi> <5dire8vca9.fsf@Hurtta06k.keh.iki.fi> <45CFC714.4B8E@xyzzy.claranet.de> <859EF3AD619BF900F10F5C4C@nifty-silver.stc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Subject: [EAI] Re: Summary of the "BODY problems" thread(s) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Newman writes in gmane.ietf.ima: > MIME today has three types of body parts: > > 1. unstructured body parts. > 2. structured body parts: multipart/*, message/rfc822 > 3. quasi-structured body parts: application/zip, etc > > All compliant MIME agents are required to process types 1 and 2 consistently. > > For case 3, which has never been formalized, MIME agents are not > required to understand or descend the quasi-structured body part > (further, the nested encoding restriction has already been ignored by > the real-world). But certain MIME agents are fundamentally broken if > they don't descent the quasi-structured part. In the case of > application/zip, any virus scanner which fails to descend the > structure is just plain broken. > > The intention of message/utf-8 is to be another quasi-structured body > part like application/zip. In this case, we expect UTF-8 header aware > agents to descend the structure and we expect non-UTF-8-header agents > to not descend the structure. There is no requirement for a UTF8SMTP > agent to downgrade a message/utf-8 body part (and in the case of a > DSN, I'd say it SHOULD NOT downgrade message/utf-8). An argument > could be made that message/utf-8 should be "application/utf-8-message" > -- I'd consider that discussion helpful and would like to see > information about what implementations do with message/utf-8 > vs. application/utf-8-message so we can make an intelligent choice. Effectively 8BITMIME downgraders are required to bounce messages if they see unknown message/* with 8-bit content -- this is only available possibility on specifications which they know. Sendmail's documentation says that it strip unknown message/* to 7-bit (instead of base64 ou quoted-printable encoding). When I tested it (see below), sendmail passed 8-bit content as it to next host although next host not announced 8BITMIME (other parts of mail sendmail base64 encoded.) When message/utf-8 is used for MUAs for attached messages, on that case downgrading message/utf-8 to message/rfc822 is required on UTF8SMTP downgraders. MUAs on general can not know is recipient of message UTF8SMTP capable, so to them it makes sense to use message/utf-8 when user attached some UTF8SMTP message to new mail. And if recipient is not UTF8SMTP capable, it is better that recipient still get message and also attached message on downgraded form. Ie. on same form than new recipient would get attached message if it was sent to him/her on first place. > I'm strongly opposed to putting UTF-8 header content into a MIME body > part with a message/rfc822 label. Having a label which has different > meanings in different contexts is dangerous and having a data-object > label with that property is even more dangerous. MIME agents allow > users to save MIME bodies to files which don't have any typing context > beyond the filename extension derived from the media type label. I'm > much more comfortable that we're avoiding installed base breakage if > "stuff which traditional agent might crash or mangle when processing" > has a different label so the traditional agent won't even attempt to > process it. > > - Chris That work group already decided once that marker is not required (on removal of Header-Type vote). Using message/utf-8 versus message/rfc822 is just another kind label. Many of same considerations apply to here. ( I also suggested HDR=UTF8 marker of ESTMP. ) / Kari Hurtta -------------------------------------------------------------------------- From: Kari Hurtta Subject: sendmail 8.13.5 tested (Re: 8to7 downgrade and message/* (Re: [EAI] Re: Registeration forms)) Newsgroups: gmane.ietf.ima To: ima@ietf.org Date: 03 Feb 2007 21:39:52 +0200 Kari Hurtta writes in gmane.ietf.ima: > Frank Ellermann writes gmane.ietf.ima: > > > Kari Hurtta wrote: > > > > > parts on these registrations forms do not fly. > > > > Yes, it's impossible to send a "real" message/utf-8 via 7bit routes, > > it has to be "downgraded" and after that fed into some 8bit to 7bit > > gateway. > > > > > See RFC 2045 restrtrion of encodings for multipart and message > > > types. ( I quoted it already twice. ) > > > > What do existing 8to7 gateways with nested and unknown 8bit message > > subtypes ? > > > > We discussed that already, but I forgot the details - at that time > > we were still far into the woods with a Header-Type: UTF-8 trying to > > twist a message/rfc822 into something it isn't and can't be. > > Sendmail strips message/* (other than message/rfc822) to 7-bit. > I do not know about others. Except that some MTAs announce 8BITMIME > and always sends 8-bit even when next host do not announce 8BITMIME. Seems that actually sendmail 8.13.5 code just send 8-bit as is (instead of downgrading). ------------------------ MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=AA --AA Content-Type: text/plain Tässä 8-bit body --AA Content-Type: message/utf-8 Subject: Tässä 8-bit header Tässä 8-bit body --AA-- ------------------------- results after 8BITMIME downgrade: ------------------------- .... Date: Sat, 3 Feb 2007 21:32:24 +0200 From: Kari Hurtta Message-ID: <200702031932.l13JWO0P005559@CENSORED> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=AA To: undisclosed-recipients:; --AA Content-Type: text/plain Content-Transfer-Encoding: base64 X-MIME-Autoconverted: from 8bit to base64 by CENSORED id l13JWa5K005560 VMOkc3PDpCA4LWJpdCBib2R5DQo= --AA Content-Type: message/utf-8 Subject: Tässä 8-bit header Tässä 8-bit body --AA-- ------------------------- It it does not strip unknown message/* to 7bit as KNOWNBUGS claim. They are actually passed as it. On code there is if (sm_strcasecmp(type, "message") == 0) { if (!wordinclass(subtype, 's')) { flags |= M87F_NO8BIT; } else But M87F_NO8BIT have not actually that effect. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 16 09:45:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4KD-0002px-8K; Fri, 16 Feb 2007 09:44:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4KB-0002pg-Ob for ima@ietf.org; Fri, 16 Feb 2007 09:44:35 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI4Ju-0007Uq-Qq for ima@ietf.org; Fri, 16 Feb 2007 09:44:35 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HI4Jo-0000Zw-Kw for ima@ietf.org; Fri, 16 Feb 2007 15:44:12 +0100 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Feb 2007 15:44:12 +0100 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Feb 2007 15:44:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 16 Feb 2007 16:44:19 +0200 Lines: 27 Message-ID: <5dfy96yxfg.fsf@leija.fmi.fi> References: <5d3b5jhyoi.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [EAI] Re: Messages on original form (Re: I-D ACTION:draft-ietf-eai-imap-utf8-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Newman writes in gmane.ietf.ima: > If I put my IMAP/POP server implementer hat on, I have no concept what > "original form" means. There's typically only one message form > available, which is the form of the message that's in the mail store. > More often than not, the IMAP/POP server has no idea how the message > got into the mail store or what it looked like before it was delivered. > > Attempting to make signatures survive message transformation is > unnecessary complexity. End-to-end signatures can be embedded in a > multipart/signed which already forbids any transformation of the > embedded content (the downgrade document should reiterate this > restriction, IMHO). > > - Chris Well, I have seen servers which combine at least final delivery, mailstore and imap to one product. Well, I still do not like that if mailstore, imap combination helpfully "upgrades" messages which do not have sent as UTF8SMTP on first place. At least UTF8SMTP capable IMAP clients should have way to avoid that. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 16 17:21:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIBRt-0005gY-3K; Fri, 16 Feb 2007 17:21:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIBRo-0005WJ-Al for ima@ietf.org; Fri, 16 Feb 2007 17:20:56 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIBRh-0000yz-JN for ima@ietf.org; Fri, 16 Feb 2007 17:20:56 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3&clerew&man*ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45d62e3f.a169.a8 for ima@ietf.org; Fri, 16 Feb 2007 22:20:47 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l1GMKjLI025429 for ; Fri, 16 Feb 2007 22:20:46 GMT To: IMA Subject: Re: [EAI] Re: Summary of the "BODY problems" thread(s) References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> <45C63889.6BEB@xyzzy.claranet.de> <5dhctzs52f.fsf@Hurtta06k.keh.iki.fi> <5dire8vca9.fsf@Hurtta06k.keh.iki.fi> <45CFC714.4B8E@xyzzy.claranet.de> <859EF3AD619BF900F10F5C4C@nifty-silver.stc.com> Message-ID: Date: Fri, 16 Feb 2007 22:20:44 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <859EF3AD619BF900F10F5C4C@nifty-silver.stc.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 15 Feb 2007 23:12:39 -0000, Chris Newman wrote: > MIME today has three types of body parts: > > 1. unstructured body parts. > 2. structured body parts: multipart/*, message/rfc822 > 3. quasi-structured body parts: application/zip, etc > > All compliant MIME agents are required to process types 1 and 2 > consistently. Ah! I see where you are coming from now, and your explanations clarify what the possibilities are (which is not to say that I agree with your conclusion). I had regarded cases #3 and #1 as equivalent for the puspose of most unspecialized agents, since their content can be regarded as opaque unless you really need to understand what is inside it (which probably means you are at one of the end points of the communication). In particular, you are allowed to apply any C-T-E that suits you, and then it is applied over the whole of the object. The difference with case #2 is that you are not allowed to do that. > > > The intention of message/utf-8 is to be another quasi-structured body > part like application/zip. In this case, we expect UTF-8 header aware > agents to descend the structure and we expect non-UTF-8-header agents to > not descend the structure. There is no requirement for a UTF8SMTP agent > to downgrade a message/utf-8 body part (and in the case of a DSN, I'd > say it SHOULD NOT downgrade message/utf-8). An argument could be made > that message/utf-8 should be "application/utf-8-message" -- I'd consider > that discussion helpful and would like to see information about what > implementations do with message/utf-8 vs. application/utf-8-message so > we can make an intelligent choice. Yes, it would definitely have to be application/utf-8-message, but then you have just invented an encapsulation mechanism (rather like application/new-transmission which is intended to enable arbitrary news articles to be tunneled through 7bit only channels, with a view to having them reconstituted at the far end in exactly their original form, then to be injected into Usenet, as when an article is emailed to a moderator, for example). But we have been strenuously trying to avoid the encapsulation method as a routine means of sending I18N mail. Moreover, we have been trying to make the UTF8SMTP world appear and behave just like the ASCII world within its own confines (leaving all the messiness of downgrading etc to cases where messages pass between those two worlds). In which case, people will naturally expect to be able to attach UTF8SMTP messages as message/rfc822 objects within other UTF8SMTP messages in the normal manner, in the expectatation that appropriate downgrading (or bouncing) will take place in the few cases where such messages are passed into the other world. In fact, you won't be able to stop them using message/rfc822 in that way, so it had better work correctly (and in fact it is not hard to do, because 8BITMIME downgraders have already invented the necessary basic machinery). > > I'm strongly opposed to putting UTF-8 header content into a MIME body > part with a message/rfc822 label. Having a label which has different > meanings in different contexts is dangerous and having a data-object > label with that property is even more dangerous. It is no different from allowing complete RFC 2822 messages to have different properties in the two worlds, which is in fact the fundamental basis of our whole approach. But it only works if you eliminate unintended leaks between the two worlds (which is what we are strenuously trying to do). And ensuring that things do not leak through being contained with some message/rfc822 is no different (except in detail) from ensuring that things do not leak through being contained within some multipart, and yet I hear no clamour from people wanting to invent multipart/utf-8. Or is there something special about DSN that means that message/rfc822 will not work within DSN, even though it is quite capable of being made to work in normal message passing? -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 16 21:50:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIFeH-0002e3-4I; Fri, 16 Feb 2007 21:50:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIFeF-0002bD-OW for ima@ietf.org; Fri, 16 Feb 2007 21:50:03 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIFeD-00014e-Nu for ima@ietf.org; Fri, 16 Feb 2007 21:50:03 -0500 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1H2o10j019441 for ; Sat, 17 Feb 2007 02:50:01 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JDL00I016FFKO00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Fri, 16 Feb 2007 19:50:01 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JDL00MXX6JAFC50@mail-amer.sun.com>; Fri, 16 Feb 2007 19:50:00 -0700 (MST) Date: Fri, 16 Feb 2007 18:49:58 -0800 From: Chris Newman Subject: Re: [EAI] Re: Summary of the "BODY problems" thread(s) In-reply-to: <5dodnuitma.fsf@Hurtta06k.keh.iki.fi> To: Kari Hurtta , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> <45C63889.6BEB@xyzzy.claranet.de> <5dhctzs52f.fsf@Hurtta06k.keh.iki.fi> <5dire8vca9.fsf@Hurtta06k.keh.iki.fi> <45CFC714.4B8E@xyzzy.claranet.de> <859EF3AD619BF900F10F5C4C@nifty-silver.stc.com> <5dodnuitma.fsf@Hurtta06k.keh.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote on 2/16/07 7:01 +0200: > When message/utf-8 is used for MUAs for attached messages, on that > case downgrading message/utf-8 to message/rfc822 is required on > UTF8SMTP downgraders. I've been convinced it should be "application/utf-8-message" (due to the ambiguity in the MIME specification with respect to unknown message subtypes). In that case, there is no requirement to downgrade. > MUAs on general can not know is recipient > of message UTF8SMTP capable, so to them it makes sense to use > message/utf-8 when user attached some UTF8SMTP message to new mail. > And if recipient is not UTF8SMTP capable, it is better that recipient > still get message and also attached message on downgraded form. > Ie. on same form than new recipient would get attached message if > it was sent to him/her on first place. Sometimes this may be true and sometimes this may not be true. I'd leave the decision of whether to pass or downgrade application/utf-8-message to site policy, although for DSNs, I'd say "SHOULD NOT downgrade" since an undamaged encapsulated message is more likely useful for that scenario. > That work group already decided once that marker is not required > (on removal of Header-Type vote). Using message/utf-8 versus message/rfc822 > is just another kind label. Many of same considerations apply to here. A robust UTF-8 aware MIME agent should treat message/rfc822 and application/utf-8-message as identical types (except the latter might be QP or base64 encoded). However, the label distinction is necessary so that legacy MIME agents will not attempt to descend the structure of application/utf-8-message and thus will continue to function properly. The difference between this case and Header-Type is that the media type label already exists so we have to make sure the label doesn't lie in order to avoid breaking deployed software. After all, a UTF-8 header message is not an RFC 822/2822 message. They are incompatible types. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 16 22:19:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIG6T-0007lU-9B; Fri, 16 Feb 2007 22:19:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIG6S-0007lO-10 for ima@ietf.org; Fri, 16 Feb 2007 22:19:12 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIG6Q-0002Hx-5U for ima@ietf.org; Fri, 16 Feb 2007 22:19:12 -0500 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1H3J9qg018561 for ; Sat, 17 Feb 2007 03:19:09 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JDL00J017E60J00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Fri, 16 Feb 2007 20:19:09 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JDL00MYZ7VVFC50@mail-amer.sun.com>; Fri, 16 Feb 2007 20:19:09 -0700 (MST) Date: Fri, 16 Feb 2007 19:19:06 -0800 From: Chris Newman Subject: Re: [EAI] Re: Summary of the "BODY problems" thread(s) In-reply-to: To: Charles Lindsey , IMA Message-id: <06F479AAE2BF7054BF2C2B1D@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> <45C63889.6BEB@xyzzy.claranet.de> <5dhctzs52f.fsf@Hurtta06k.keh.iki.fi> <5dire8vca9.fsf@Hurtta06k.keh.iki.fi> <45CFC714.4B8E@xyzzy.claranet.de> <859EF3AD619BF900F10F5C4C@nifty-silver.stc.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote on 2/16/07 22:20 +0000: > Yes, it would definitely have to be application/utf-8-message, but then you > have just invented an encapsulation mechanism Ok, I've been convinced application/utf-8-message is a safer label for the type. And DSNs require an encapsulation mechanism for return-of-content, so it was absolutely my intention to create an encapsulation mechanism. > But we have been strenuously trying to avoid the encapsulation method as a > routine means of sending I18N mail. Agreed. > Moreover, we have been trying to make > the UTF8SMTP world appear and behave just like the ASCII world within its > own confines (leaving all the messiness of downgrading etc to cases where > messages pass between those two worlds). In which case, people will > naturally expect to be able to attach UTF8SMTP messages as message/rfc822 > objects within other UTF8SMTP messages in the normal manner, in the > expectatation that appropriate downgrading (or bouncing) will take place in > the few cases where such messages are passed into the other world. I disagree with all your assertions here. > In fact, > you won't be able to stop them using message/rfc822 in that way, so it had > better work correctly I agree with this statement. I would expect a robust UTF-8-aware MIME agent to do the following things: 1. Treat message/rfc822 and application/utf-8-message as semantically identical except the latter might be QP or base-64 encoded at the top-level. 2. Correct the label in the event content which is not, in fact, RFC 822/2822 complaint happens to be mislabeled as such. 3. When passing to a non-UTF-8 system, perform downgrading on an application/utf-8-message according to site policy. I expect the initial policy to be "don't downgrade application/utf-8-message in a DSN/MDN", but do downgrade it otherwise. However, over time I expect downgrading of application/utf-8-message to become less and less desirable/useful. It really depends on how well utf-8-message support deploys in clients at any given site, so writing strict rules would be highly inappropriate. The goal here is to minimize risk of breaking legacy systems by protecting them from mislabeled content, but also to avoid burdening the future with today's limitations. The former has always been a goal of the IETF. What's new about this WG is we're attempting the latter at the same time. Please keep both of these goals in mind as I suspect it's why you're having trouble syncing up with the rest of the working group. > It is no different from allowing complete RFC 2822 messages to have > different properties in the two worlds, which is in fact the fundamental > basis of our whole approach. I could not disagree more. An SMTP server which advertises UTF8SMTP is advertising that it accepts not only RFC 2822 messages, but that it also accepts UTF-8 header messages. However, such systems also must assume all other systems support _only_ RFC 2822 messages until they learn otherwise through a negotiation mechanism. Otherwise we risk breaking the installed base. We're not redefining RFC 2822, we're creating a new infrastructure which accepts a new message format that is incompatible with RFC 2822. > But it only works if you eliminate unintended > leaks between the two worlds (which is what we are strenuously trying to > do). And ensuring that things do not leak through being contained with some > message/rfc822 is no different (except in detail) from ensuring that things > do not leak through being contained within some multipart, and yet I hear no > clamour from people wanting to invent multipart/utf-8. That's because multipart/utf-8 (if it does what I think it does) is a terrible idea. Turning an atomic media type into a compound type with syntax incompatible with the canonical format causes all sorts of problems. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 16 22:28:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIGEy-0000ED-R8; Fri, 16 Feb 2007 22:28:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIGEx-0000AH-Uc for ima@ietf.org; Fri, 16 Feb 2007 22:27:59 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIGEt-0003zD-6C for ima@ietf.org; Fri, 16 Feb 2007 22:27:59 -0500 Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1H3RoWh004761 for ; Sat, 17 Feb 2007 03:27:50 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JDL006018530X00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Fri, 16 Feb 2007 20:27:50 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JDL00BBB8ACJ500@mail-amer.sun.com>; Fri, 16 Feb 2007 20:27:50 -0700 (MST) Date: Fri, 16 Feb 2007 19:27:47 -0800 From: Chris Newman Subject: Re: [EAI] Re: Messages on original form (Re: I-D ACTION:draft-ietf-eai-imap-utf8-00.txt) In-reply-to: <5dfy96yxfg.fsf@leija.fmi.fi> To: Kari Hurtta , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <5d3b5jhyoi.fsf@Hurtta06k.keh.iki.fi> <5dfy96yxfg.fsf@leija.fmi.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote on 2/16/07 16:44 +0200: > Well, I still do not like that if > > mailstore, imap combination helpfully "upgrades" messages > which do not have sent as UTF8SMTP on first place. At least > UTF8SMTP capable IMAP clients should have way to avoid that. The WG has not had a consensus discussion on the "upgrade" behavior in the IMAP/POP specifications so I consider that point an open issue. However, my goal in writing the specifications the way I did was to begin the process of deprecating RFC 2047/2231 in favor of native UTF-8. If the WG decides not to pursue that goal, then the specifications will have to be modified accordingly. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 17 03:25:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIKsm-0004A3-Hb; Sat, 17 Feb 2007 03:25:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIKsl-00049p-6s for ima@ietf.org; Sat, 17 Feb 2007 03:25:23 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIKsf-0003BD-UF for ima@ietf.org; Sat, 17 Feb 2007 03:25:23 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HIKsG-0001sq-Q2 for ima@ietf.org; Sat, 17 Feb 2007 09:24:52 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 17 Feb 2007 09:24:52 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 17 Feb 2007 09:24:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 17 Feb 2007 10:24:40 +0200 Lines: 14 Message-ID: <5d4ppljinr.fsf_-_@Hurtta06k.keh.iki.fi> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> <45C63889.6BEB@xyzzy.claranet.de> <5dhctzs52f.fsf@Hurtta06k.keh.iki.fi> <5dire8vca9.fsf@Hurtta06k.keh.iki.fi> <45CFC714.4B8E@xyzzy.claranet.de> <859EF3AD619BF900F10F5C4C@nifty-silver.stc.com> <06F479AAE2BF7054BF2C2B1D@[10.1.110.5]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [EAI] multipart/utf8* (Re: Summary of the "BODY problems" thread(s)) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Newman writes in gmane.ietf.ima: <...> > That's because multipart/utf-8 (if it does what I think it does) is a > terrible idea. Turning an atomic media type into a compound type with > syntax incompatible with the canonical format causes all sorts of > problems. > > - Chris You are refering to multipart/utf8-encapsulated on my draft-hurtta-eai-encapsulation-00 draft? / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 18 11:03:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIoV6-000463-LX; Sun, 18 Feb 2007 11:02:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIoV5-00045v-LN for ima@ietf.org; Sun, 18 Feb 2007 11:02:55 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIoV3-0003dq-2y for ima@ietf.org; Sun, 18 Feb 2007 11:02:55 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HIoUk-0004Vq-VD for ima@ietf.org; Sun, 18 Feb 2007 17:02:34 +0100 Received: from du-001-150.access.de.clara.net ([212.82.227.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Feb 2007 17:02:34 +0100 Received: from nobody by du-001-150.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Feb 2007 17:02:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sun, 18 Feb 2007 16:58:26 +0100 Organization: Lines: 87 Message-ID: <45D877A2.1009@xyzzy.claranet.de> References: <45C4D3DE.5E4B@xyzzy.claranet.de> <5dwt2zf4rb.fsf@Hurtta06k.keh.iki.fi> <45C4E590.59A9@xyzzy.claranet.de> <5dmz3vf0zd.fsf_-_@Hurtta06k.keh.iki.fi> <45C508DC.6D7F@xyzzy.claranet.de> <5dfy9m6vhd.fsf@Hurtta06k.keh.iki.fi> <45C5F630.649B@xyzzy.claranet.de> <45C62038.5F12@xyzzy.claranet.de> <9318B2B12A2EB8312936B046@p3.JCK.COM> <45C63889.6BEB@xyzzy.claranet.de> <5dhctzs52f.fsf@Hurtta06k.keh.iki.fi> <5dire8vca9.fsf@Hurtta06k.keh.iki.fi> <45CFC714.4B8E@xyzzy.claranet.de> <859EF3AD619BF900F10F5C4C@nifty-silver.stc.com> 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: du-001-150.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [EAI] Re: Summary of the "BODY problems" thread(s) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Newman wrote: > MIME today has three types of body parts: > 1. unstructured body parts. > 2. structured body parts: multipart/*, message/rfc822 > 3. quasi-structured body parts: application/zip, etc > All compliant MIME agents are required to process types > 1 and 2 consistently. > For case 3, which has never been formalized, MIME agents are > not required to understand or descend the quasi-structured > body part I don't understand this classification. Is (1) the same as text/plain and only text/plain ? If yes (3) could be "all other MIME types excl. multipart/* and message/rfc822", and a simple example would be text/html. (3) would then also cover all message/* excl. message/rfc822, message/partial, and message/external-body. A message/partial or message/external-body would then belong to (2), but these message subtypes are anyway irrelevant for our purposes, they use ASCII headers like messsage/rfc822. > But certain MIME agents are fundamentally broken if they > don't descent the quasi-structured part. In the case of > application/zip, any virus scanner which fails to descend > the structure is just plain broken. It would look into any part, remove the CTE and check it, no matter what the content-type claims to be. And as long as nobody invents a new MIME version, e.g. here "allowing" UTF-8 in body part headers, this continues to work (or not) as is. The one situation where this might fail is a message/utf-8, a "legacy" scanner would consider it as "unknown garbage", and if it then verifies that it's no B64 starting with TV or UE it will never consider the body of the message/utf-8. Tough, but unavoidable, the new message/utf-8 needs clear security considerations. After all message/partial is still worse. > The intention of message/utf-8 is to be another > quasi-structured body part like application/zip. By definition (as above, in an RFC 2049 sense). Ideally it will belong to (2) in the future, obsoleting messsage/rfc822. A gentle case of "embrace, extend, and extinguish". If the UTF8SMTP experiment works we'll have to update 2049, adding message/utf-8 to "minimal MIME conformance for UTF8SMTP", or similar. > There is no requirement for a UTF8SMTP agent to downgrade a > message/utf-8 body part (and in the case of a DSN, I'd say > it SHOULD NOT downgrade message/utf-8). Yes. But of course the 8bit DSN like any other 8bit message (rfc822 and utf-8 alike) is in trouble when it hits a 7bit relay. > An argument could be made that message/utf-8 should be > "application/utf-8-message" -- I'd consider that discussion > helpful That argument is stated in chapter 5.2.4 of RFC 2046, and it's the very idea of UTF8SMTP to ignore this advice. In the "real world" (8BITMIME) application/utf-8-message is an unnecessary and unintuitive kludge. It's only required to tunnel 7bit hops with base64 (or QP (?)). IMO "8to7" gateways have a problem with _any_ 8bit message part, not limited to message/utf-8. Therefore we could offer a more general kludge, application/8bit-message or similar, preserving the original subtype as parameter. All these "8to7" headaches are not directly a part of UTF8SMTP, we should extract the kludge into a separate "8to7" document. And while we're at it let's promote RFC 1652 to STD, no erratum in 13 years sounds like "ready" for me. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 18 23:19:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIzzp-00019r-Kd; Sun, 18 Feb 2007 23:19:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIzzo-000161-5x for ima@ietf.org; Sun, 18 Feb 2007 23:19:24 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIzzi-00024e-NJ for ima@ietf.org; Sun, 18 Feb 2007 23:19:24 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HIzzb-00030n-Vt for ima@ietf.org; Mon, 19 Feb 2007 05:19:11 +0100 Received: from du-001-150.access.de.clara.net ([212.82.227.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Feb 2007 05:19:11 +0100 Received: from nobody by du-001-150.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 19 Feb 2007 05:19:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Mon, 19 Feb 2007 05:13:58 +0100 Organization: Lines: 95 Message-ID: <45D92406.4E42@xyzzy.claranet.de> References: 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: du-001-150.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [EAI] Re: I-D ACTION:draft-ietf-eai-smtpext-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Internet-Drafts@ietf.org wrote: > Filename : draft-ietf-eai-smtpext-03.txt Some ABNF nits: 1: Please replace all by UTF8-2 / UTF8-3 / UTF8-4. is an ambiguous term. RFC 3977 uses the term if you insist on some kind of shorthand. 2: - ; Let-dig in the right of '=' is defined in RFC 2822 + ; Augment Let-dig in RFC 2821, section 4.1.3 3: - ; Replace Ldh-str in RFC 2821, section 4.1.2 + ; Replace Ldh-str in RFC 2821, section 4.1.3 Do we really want an for UTF8SMTP source routing ? IMO relays should simply use the ASCII version of domain names in reverse or forward paths. It's anyway deprecated. Without there's of course also no . - sender, the email must be bounced to the original sender. If the - email is bounced due to the incapability of supporting UTF8SMTP, the + sender, the email must be rejected. If the email is rejected due + to the incapability of supporting UTF8SMTP, the Better don't talk about "bounces to the original sender", that's a wild and dangerous battlefield reserved for 2821bis. The start of section 2.5 is rather obscure: The "ALT-ADDRESS" requires an all-ASCII address. There are two alternative ways to set ALT-ADDRESS value: one is set by the sender using the all-ASCII address, the other is set using the transformed email address. IMO the other way is that the MSA (knowing the sender) could supply an ALT-ADRESSS for the MAIL FROM. If that's in some way "transformed" or not is the local business of the MSA. The following discussion about "transformations" could be deleted, we didn't pick that option. It's also unclear what "the predefined way" is, (quote) the sender can specify that these addresses are safe to be converted in the predefined way (unquote). For the RHS there is a clear predefined way, but not for the LHS. Assuming that the server advertises UTF8SMTP and 8BITMIME, and at etc. IMO that paragraph should be deleted, it's obscure and unnecessary. Of course BODY=8BITMIME and BODY=BINARY mean what they always mean, that doesn't depend on UTF8SMTP, as explained in the first paragraph in 2.6. It's IMO misleading to assume that the presence of non-ASCII addresses in the envelope _always_ announces a message/utf-8. For a RCPT TO it could be still a message/rfc822 (depending on the generated timestamp lines). The oppposite also isn't necessarily true, the envelope could be ASCII, but the message header can contain UTF-8. This alternate-MX-or-retry-later technique SHOULD NOT be used when It SHOULD NOT be discussed at all, it's really odd. Especially "retry later", what's the idea, the receiver just happens to upgrade their MX today ? - uFor = "FOR" FWS 1*( Path / uMailbox ) CFWS + uFor = "FOR" FWS 1*( uPath / uMailbox ) CFWS 2.7.5: Please delete the complete section, there's no "Header-Type" anymore. 2.7.6 could be also deleted, POP3 and IMAP are introduced in the framework RFC, they will get their own RFCs. No SMTP business, no case for a "SHOULD". Or is that about the job of MDAs ? Then it doesn't say what special actions an MDA is expected to perform (after it got the uReturn-path-line right as specified in 2.7.3). 3.1: Please delete this section, mailto URIs are no SMTP business. 3.2: s/2476/4409/ everywhere, and s/EAI protocol/UTF8SMTP/ (?) The complete chapter 3 should go. Chapter 4 is also unnecessary. How about some nice example sessions ? Another nit in 2.2: - transmit a mail body which contains internationalized mail headers + transmit a message which contains internationalized mail headers Maybe 'mail data', SMTP transports complete messages, header + body. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 20 06:44:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJTPm-0002P1-TR; Tue, 20 Feb 2007 06:44:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJTPl-0002Lt-Aw for ima@ietf.org; Tue, 20 Feb 2007 06:44:09 -0500 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJTPj-0002mn-Pn for ima@ietf.org; Tue, 20 Feb 2007 06:44:09 -0500 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l1KBhuR9029164 for ; Tue, 20 Feb 2007 20:43:56 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007022020435530942 for ; Tue, 20 Feb 2007 20:43:56 +0900 Date: Tue, 20 Feb 2007 20:43:55 +0900 (JST) Message-Id: <20070220.204355.23039284.fujiwara@jprs.co.jp> To: ima@ietf.org Subject: utf-8-address syntax: [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt From: fujiwara@jprs.co.jp In-Reply-To: References: X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org draft-ietf-eai-dsn-00.txt section 3. UTF-8 Address Type is defined: > utf-8-type-addr = "utf-8;" utf-8-address > utf-8-address = "<" Mailbox [ *WSP "<" Mailbox ">" ] ">" But mailbox is defined in RFC 2822 as: mailbox = name-addr / addr-spec name-addr = [display-name] angle-addr angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr addr-spec = local-part "@" domain As a result, this utf-8-address may be parsed as " >". The 'utf-8-address' should be 'angle-addr' defined in [utf8smtp]. Or utf-8-type-addr = "utf-8;" angle-addr ; angle-addr is defined in [utf8smtp] This specification cannot hold '[route]' parameter defined in RFC 3461 section 9.1 rfc822 address-type. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 20 13:15:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJZVi-0007lb-Ff; Tue, 20 Feb 2007 13:14:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJZVh-0007lV-TW for ima@ietf.org; Tue, 20 Feb 2007 13:14:41 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJZVg-00026k-KQ for ima@ietf.org; Tue, 20 Feb 2007 13:14:41 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HJZVT-000PSe-Lx; Tue, 20 Feb 2007 13:14:27 -0500 Date: Tue, 20 Feb 2007 13:14:27 -0500 From: John C Klensin To: fujiwara@jprs.co.jp, ima@ietf.org Subject: Re: utf-8-address syntax: [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt Message-ID: <1BBD4A5D619E668BC071E65E@p3.JCK.COM> In-Reply-To: <20070220.204355.23039284.fujiwara@jprs.co.jp> References: <20070220.204355.23039284.fujiwara@jprs.co.jp> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 20 February, 2007 20:43 +0900 fujiwara@jprs.co.jp wrote: > draft-ietf-eai-dsn-00.txt section 3. UTF-8 Address Type is > defined: > >> utf-8-type-addr = "utf-8;" utf-8-address >> utf-8-address = "<" Mailbox [ *WSP "<" Mailbox ">" ] ">" > > But mailbox is defined in RFC 2822 as: > > mailbox = name-addr / addr-spec > name-addr = [display-name] angle-addr > angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / > obs-angle-addr addr-spec = local-part "@" domain > > As a result, this utf-8-address may be parsed as > " >". > > The 'utf-8-address' should be 'angle-addr' defined in > [utf8smtp]. > > Or > utf-8-type-addr = "utf-8;" angle-addr > ; angle-addr is defined in [utf8smtp] Arggh. Yes. Good catch. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 21 10:29:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtOn-0001dI-Pe; Wed, 21 Feb 2007 10:28:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtOm-0001d7-Pg for ima@ietf.org; Wed, 21 Feb 2007 10:28:52 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJtOl-00006j-Ax for ima@ietf.org; Wed, 21 Feb 2007 10:28:52 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 21 Feb 2007 15:28:40 +0000 Message-ID: <45DC6508.3070008@isode.com> Date: Wed, 21 Feb 2007 15:28:08 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ima@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [EAI] Updated draft-melnikov-smtp-lang-06.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : SMTP Language Extension > Author(s) : A. Melnikov > Filename : draft-melnikov-smtp-lang-06.txt > Pages : 0 > Date : 2007-2-20 > >The Simple Mail Transfer Protocol (RFC 2821) allows server responses > to include human-readable text that in many cases needs to be > presented to the user. This document specifies a way for a client to > negotiate which language the server should use when sending > human-readable text. It also extends the UTF-8 Delivery Status > Notifications format to include language field for the human-readable > text. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-melnikov-smtp-lang-06.txt > > I've updated the document based on comments received so far (Note that there is a big ToDo section stating the comments which were not addressed). The latest version is now pointing to Chris' EAI-DSN draft. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Feb 21 10:38:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtY1-0004sn-Al; Wed, 21 Feb 2007 10:38:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtXz-0004se-Rh for ima@ietf.org; Wed, 21 Feb 2007 10:38:23 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJtXy-0001WY-I2 for ima@ietf.org; Wed, 21 Feb 2007 10:38:23 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HJtXr-0000ew-5l for ima@ietf.org; Wed, 21 Feb 2007 16:38:15 +0100 Received: from d253235.dialin.hansenet.de ([80.171.253.235]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Feb 2007 16:38:15 +0100 Received: from nobody by d253235.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Feb 2007 16:38:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Wed, 21 Feb 2007 16:36:40 +0100 Organization: Lines: 26 Message-ID: <45DC6708.4DFD@xyzzy.claranet.de> References: <20070220.204355.23039284.fujiwara@jprs.co.jp> <1BBD4A5D619E668BC071E65E@p3.JCK.COM> 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: d253235.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [EAI] Re: utf-8-address syntax: I-D ACTION:draft-ietf-eai-dsn-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > Arggh. Yes. Good catch. Sure ? I thought it was another (*1) case of confusing 2822 with 2821 The eai-dsn draft says: utf-8-address = "<" Mailbox [ *WSP "<" Mailbox ">" ] ">" ; The first occurrence of 'Mailbox' is defined in [utf8smtp] ; The second occurrence of 'Mailbox' is defined in RFC 2821 .............................................................^^^^^^^^ RFC 2821 has no display-name etc., it's (in 4.1.2): Mailbox = Local-part "@" Domain There's no [utf8smtp] in the references. I guess it's supposed to be [I-D.ietf-eai-smtpext] chapter 2.3 : uMailbox = uLocal-part "@" uDomain ; Replace Mailbox in RFC 2821, section 4.1.2 Frank *1: One other person confusing and was me... :-) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 22 06:48:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKCR1-0002fg-Bq; Thu, 22 Feb 2007 06:48:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKCR0-0002fb-C6 for ima@ietf.org; Thu, 22 Feb 2007 06:48:26 -0500 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKCQy-0007fd-Pd for ima@ietf.org; Thu, 22 Feb 2007 06:48:26 -0500 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l1MBmNR9024882 for ; Thu, 22 Feb 2007 20:48:23 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007022220482211054 for ; Thu, 22 Feb 2007 20:48:22 +0900 Date: Thu, 22 Feb 2007 20:48:22 +0900 (JST) Message-Id: <20070222.204822.52193432.fujiwara@jprs.co.jp> To: ima@ietf.org Subject: Re: [EAI] Re: utf-8-address syntax: I-D ACTION:draft-ietf-eai-dsn-00.txt From: fujiwara@jprs.co.jp In-Reply-To: <45DC6708.4DFD@xyzzy.claranet.de> References: <20070220.204355.23039284.fujiwara@jprs.co.jp> <1BBD4A5D619E668BC071E65E@p3.JCK.COM> <45DC6708.4DFD@xyzzy.claranet.de> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org sorry my confusion about . I have two questions about ORCPT UTF8 address type. 1. UTF-8 address type is used in UTF8SMTP environment. When and where UTF-8 encoded address type used ? 2. Is ORCPT UTF-8 address downgrading required when SMTP downgrading occures. -- Kazunori Fujiwara, JPRS > From: Frank Ellermann > John C Klensin wrote: > > > Arggh. Yes. Good catch. > > Sure ? I thought it was another (*1) case of confusing 2822 > with 2821 The eai-dsn draft says: > > utf-8-address = "<" Mailbox [ *WSP "<" Mailbox ">" ] ">" > ; The first occurrence of 'Mailbox' is defined in [utf8smtp] > ; The second occurrence of 'Mailbox' is defined in RFC 2821 > .............................................................^^^^^^^^ > > RFC 2821 has no display-name etc., it's (in 4.1.2): > > Mailbox = Local-part "@" Domain > > There's no [utf8smtp] in the references. I guess it's supposed to be > [I-D.ietf-eai-smtpext] chapter 2.3 : > > uMailbox = uLocal-part "@" uDomain > ; Replace Mailbox in RFC 2821, section 4.1.2 > > Frank > > *1: One other person confusing and was me... :-) > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 22 09:45:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKFCW-0007t0-RI; Thu, 22 Feb 2007 09:45:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKFCV-0007sm-U6 for ima@ietf.org; Thu, 22 Feb 2007 09:45:39 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKFCQ-0002DU-JA for ima@ietf.org; Thu, 22 Feb 2007 09:45:39 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HKFCJ-0008CR-VV for ima@ietf.org; Thu, 22 Feb 2007 15:45:27 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Feb 2007 15:45:27 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Feb 2007 15:45:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 22 Feb 2007 16:45:09 +0200 Lines: 31 Message-ID: <5d7iuajloq.fsf@Hurtta06k.keh.iki.fi> References: <5d3b5jhyoi.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [EAI] Re: Messages on original form (Re: I-D ACTION:draft-ietf-eai-imap-utf8-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Newman writes in gmane.ietf.ima: > If I put my IMAP/POP server implementer hat on, I have no concept what > "original form" means. There's typically only one message form > available, which is the form of the message that's in the mail store. > More often than not, the IMAP/POP server has no idea how the message > got into the mail store or what it looked like before it was delivered. > > Attempting to make signatures survive message transformation is > unnecessary complexity. End-to-end signatures can be embedded in a > multipart/signed which already forbids any transformation of the > embedded content (the downgrade document should reiterate this > restriction, IMHO). Multipart/signed does not help for DKIM. It also requires that message is converted to 7-bit form before signing. So for header fields which are part of signature that then means that EAI/UTF8SMTP is not used, but instead MNIME encoding is used. If these header fields are 'upgraded' then MUA, which check signature, will see broken message. Better to not go to full conflict with that working group. / Kari Hurtta http://www.ietf.org/internet-drafts/draft-ietf-dkim-base-10.txt ( The IESG has approved 'DomainKeys Identified Mail (DKIM) Signatures' as a Proposed Standard. ) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 22 13:14:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKIRa-0001Tq-Uo; Thu, 22 Feb 2007 13:13:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKIRZ-0001T7-PJ for ima@ietf.org; Thu, 22 Feb 2007 13:13:25 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKIRT-0003vY-3s for ima@ietf.org; Thu, 22 Feb 2007 13:13:25 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3#clerew&man$ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45dddd33.1157c.2e8 for ima@ietf.org; Thu, 22 Feb 2007 18:13:07 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l1MID5AP021260 for ; Thu, 22 Feb 2007 18:13:06 GMT To: IMA Subject: Re: [EAI] Re: Messages on original form (Re: I-D ACTION:draft-ietf-eai-imap-utf8-00.txt) References: <5d3b5jhyoi.fsf@Hurtta06k.keh.iki.fi> <5d7iuajloq.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Thu, 22 Feb 2007 18:13:05 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5d7iuajloq.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 22 Feb 2007 14:45:09 -0000, Kari Hurtta wrote: > Multipart/signed does not help for DKIM. It also requires that > message is converted to 7-bit form before signing. Indeed, the fact that both multipart/signed and DKIM insist on signing the C-T-encoded form on the wire (which may vary as it passes through various agents), instead of signing the original, unencoded form of the message (which is presumably what the signer actually cares about) is one of the major stupidities of both those schemes. > Better to not go to full conflict with that working group. I have already been there and done that. And it is accepted that the only way out is to define a new 8bit-clean canonicalization that signs the unencoded form. I intend to do that, but want to wait until I understand message/* types better (which just happens to be an active topic on this group). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Feb 22 17:19:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKMHR-0005jG-U5; Thu, 22 Feb 2007 17:19:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKMHR-0005j6-5H for ima@ietf.org; Thu, 22 Feb 2007 17:19:13 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKMHP-0006pI-Df for ima@ietf.org; Thu, 22 Feb 2007 17:19:13 -0500 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1MMJAZg008783 for ; Thu, 22 Feb 2007 22:19:11 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JDV00201XUCUV00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Thu, 22 Feb 2007 15:19:10 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JDV006JVXZTLX40@mail-amer.sun.com>; Thu, 22 Feb 2007 15:19:08 -0700 (MST) Date: Thu, 22 Feb 2007 14:19:06 -0800 From: Chris Newman Subject: Re: [EAI] Re: utf-8-address syntax: I-D ACTION:draft-ietf-eai-dsn-00.txt In-reply-to: <20070222.204822.52193432.fujiwara@jprs.co.jp> To: fujiwara@jprs.co.jp, ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <20070220.204355.23039284.fujiwara@jprs.co.jp> <1BBD4A5D619E668BC071E65E@p3.JCK.COM> <45DC6708.4DFD@xyzzy.claranet.de> <20070222.204822.52193432.fujiwara@jprs.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org fujiwara@jprs.co.jp wrote on 2/22/07 20:48 +0900: > sorry my confusion about . > > I have two questions about ORCPT UTF8 address type. > > 1. UTF-8 address type is used in UTF8SMTP environment. > When and where UTF-8 encoded address type used ? The quick overview would be: * The utf-8 address type is completely un-encoded. * The utf-8-enc address type has two types of encoding: mandatory (SP, +, =), and optional (Unicode characters). The utf-8-enc address type is always used in the ORCPT parameter, but the Unicode encoding is only required when an SMTP server advertises DSN without UTF8SMTP. The utf-8-enc address type is used with Unicode encoding in a 7-bit message/delivery-status. The utf-8 address type is recommend for utf-8-delivery-status. > 2. Is ORCPT UTF-8 address downgrading required > when SMTP downgrading occures. Yes, the Unicode-encoded version of utf-8-enc address type must be used in that case. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 23 01:22:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKTox-00008K-QG; Fri, 23 Feb 2007 01:22:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKTow-0008Tu-5U for ima@ietf.org; Fri, 23 Feb 2007 01:22:18 -0500 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKTot-0004rr-J1 for ima@ietf.org; Fri, 23 Feb 2007 01:22:18 -0500 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l1N6M4RF003127; Fri, 23 Feb 2007 15:22:12 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007022315221114985 ; Fri, 23 Feb 2007 15:22:11 +0900 Date: Fri, 23 Feb 2007 15:22:11 +0900 (JST) Message-Id: <20070223.152211.91341781.fujiwara@jprs.co.jp> To: Chris.Newman@Sun.COM Subject: Re: [EAI] Re: utf-8-address syntax: I-D ACTION:draft-ietf-eai-dsn-00.txt From: fujiwara@jprs.co.jp In-Reply-To: References: <45DC6708.4DFD@xyzzy.claranet.de> <20070222.204822.52193432.fujiwara@jprs.co.jp> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > From: Chris Newman > The quick overview would be: > * The utf-8 address type is completely un-encoded. > * The utf-8-enc address type has two types of encoding: mandatory (SP, +, =), > and optional (Unicode characters). > > The utf-8-enc address type is always used in the ORCPT parameter, but the > Unicode encoding is only required when an SMTP server advertises DSN without > UTF8SMTP. utf-8 address type is not used in SMTP ORCPT parameter ? (and always utf-8-enc address type is used?) > > 2. Is ORCPT UTF-8 address downgrading required > > when SMTP downgrading occures. > > Yes, the Unicode-encoded version of utf-8-enc address type must be used in that > case. before downgrading, (it's equal to first question.) which is right? both? ORCPT=utf8;> ORCPT=utf-8-enc;> after downgrading, which is right? ORCPT=rfc822;ascii@ascii ORCPT=utf-8-enc;> I'm updating draft-ietf-eai-downgrading. My current text is written as 'ORCPT=utf8;>' to be downgraded as 'ORCPT=rfc822;ascii@ascii'. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 23 03:22:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKVgz-0003iW-R1; Fri, 23 Feb 2007 03:22:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKVgy-0003iF-SO for ima@ietf.org; Fri, 23 Feb 2007 03:22:12 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKVgx-0007vd-0D for ima@ietf.org; Fri, 23 Feb 2007 03:22:12 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 80D3F2596E5; Fri, 23 Feb 2007 09:17:52 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16001-08; Fri, 23 Feb 2007 09:17:47 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 60F5B2596E4; Fri, 23 Feb 2007 09:17:47 +0100 (CET) Message-ID: <45DEA42C.2040905@alvestrand.no> Date: Fri, 23 Feb 2007 09:22:04 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] Re: Messages on original form (Re: I-D ACTION:draft-ietf-eai-imap-utf8-00.txt) References: <5d3b5jhyoi.fsf@Hurtta06k.keh.iki.fi> <5d7iuajloq.fsf@Hurtta06k.keh.iki.fi> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > On Thu, 22 Feb 2007 14:45:09 -0000, Kari Hurtta > wrote: > >> Multipart/signed does not help for DKIM. It also requires that >> message is converted to 7-bit form before signing. > > Indeed, the fact that both multipart/signed and DKIM insist on signing > the C-T-encoded form on the wire (which may vary as it passes through > various agents), instead of signing the original, unencoded form of > the message (which is presumably what the signer actually cares about) > is one of the major stupidities of both those schemes. Charles, the consensus of all the WGs that have been over this field was that it was impossible to preserve signatures if one signed the unencoded format. It's possible that you are a genius and everyone else who's worked on it is an idiot. But it's also possible that you haven't understood the problem. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 23 03:29:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKVoJ-00073G-8N; Fri, 23 Feb 2007 03:29:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKVoI-000738-T1 for ima@ietf.org; Fri, 23 Feb 2007 03:29:46 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKVoH-0001Kg-FH for ima@ietf.org; Fri, 23 Feb 2007 03:29:46 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 11E172596EC; Fri, 23 Feb 2007 09:25:27 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16949-04; Fri, 23 Feb 2007 09:25:21 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 58D062596EA; Fri, 23 Feb 2007 09:25:21 +0100 (CET) Message-ID: <45DEA5F2.7070904@alvestrand.no> Date: Fri, 23 Feb 2007 09:29:38 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: fujiwara@jprs.co.jp Subject: Re: [EAI] Re: utf-8-address syntax: I-D ACTION:draft-ietf-eai-dsn-00.txt References: <45DC6708.4DFD@xyzzy.claranet.de> <20070222.204822.52193432.fujiwara@jprs.co.jp> <20070223.152211.91341781.fujiwara@jprs.co.jp> In-Reply-To: <20070223.152211.91341781.fujiwara@jprs.co.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Chris.Newman@Sun.COM, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org fujiwara@jprs.co.jp wrote: >> From: Chris Newman >> The quick overview would be: >> * The utf-8 address type is completely un-encoded. >> * The utf-8-enc address type has two types of encoding: mandatory (SP,= +, =3D), >> and optional (Unicode characters). >> >> The utf-8-enc address type is always used in the ORCPT parameter, but = the=20 >> Unicode encoding is only required when an SMTP server advertises DSN w= ithout=20 >> UTF8SMTP. >> =20 > > utf-8 address type is not used in SMTP ORCPT parameter ? > (and always utf-8-enc address type is used?) > > =20 >>> 2. Is ORCPT UTF-8 address downgrading required >>> when SMTP downgrading occures. >>> =20 >> Yes, the Unicode-encoded version of utf-8-enc address type must be use= d in that=20 >> case. >> =20 > > before downgrading, (it's equal to first question.) > which is right? both? > ORCPT=3Dutf8;> > ORCPT=3Dutf-8-enc;> > > after downgrading, which is right? > ORCPT=3Drfc822;ascii@ascii > ORCPT=3Dutf-8-enc;> > > =20 As far as I understood Chris, if the address is : Before downgrading (UTF8SMTP environment) ORCPT=3Dutf-8-enc; After downgrading (DSN supported, but UTF8SMTP not supported): ORCPT=3Dutf-8-enc: You never, ever, ever throw away information in an ORCPT as long as you=20 can carry it. Clearer? (the codepoints are wrong. Sorry 'bout that.) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 23 04:32:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKWme-0001Fc-UK; Fri, 23 Feb 2007 04:32:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKWmd-0001Bl-C9 for ima@ietf.org; Fri, 23 Feb 2007 04:32:07 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKWmc-0007eo-26 for ima@ietf.org; Fri, 23 Feb 2007 04:32:07 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HKWmF-0006yS-HO for ima@ietf.org; Fri, 23 Feb 2007 10:31:43 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Feb 2007 10:31:43 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Feb 2007 10:31:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 23 Feb 2007 11:31:26 +0200 Lines: 34 Message-ID: <5dr6shte35.fsf@Hurtta06k.keh.iki.fi> References: <5d3b5jhyoi.fsf@Hurtta06k.keh.iki.fi> <5d7iuajloq.fsf@Hurtta06k.keh.iki.fi> <45DEA42C.2040905@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [EAI] Re: Messages on original form (Re: I-D ACTION:draft-ietf-eai-imap-utf8-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand writes in gmane.ietf.ima: > Charles Lindsey wrote: > > On Thu, 22 Feb 2007 14:45:09 -0000, Kari Hurtta > > wrote: > > > >> Multipart/signed does not help for DKIM. It also requires that > >> message is converted to 7-bit form before signing. > > > > Indeed, the fact that both multipart/signed and DKIM insist on > > signing the C-T-encoded form on the wire (which may vary as it > > passes through various agents), instead of signing the original, > > unencoded form of the message (which is presumably what the signer > > actually cares about) is one of the major stupidities of both those > > schemes. > Charles, the consensus of all the WGs that have been over this field > was that it was impossible to preserve signatures if one signed the > unencoded format. > > It's possible that you are a genius and everyone else who's worked on > it is an idiot. > But it's also possible that you haven't understood the problem. > > Harald For leaf body parts on MIME structure similar than Content-MD5 can be used ( RFC 1864 ). That calculates hash from unencoded format. But I do not believe that something like that works with header fields. Also that kind signature is difficult extend to mime structure (and not just to MIME leaf parts.) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 23 08:16:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKaHX-0002Qy-3C; Fri, 23 Feb 2007 08:16:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKaHV-0002Q8-7X for ima@ietf.org; Fri, 23 Feb 2007 08:16:13 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKaHQ-0007ZI-L6 for ima@ietf.org; Fri, 23 Feb 2007 08:16:13 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3&clerew*man^ac^uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45dee914.14efe.1a8 for ima@ietf.org; Fri, 23 Feb 2007 13:16:04 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l1NDG2gl001752 for ; Fri, 23 Feb 2007 13:16:04 GMT To: IMA Subject: Re: [EAI] Re: Messages on original form (Re: I-D ACTION:draft-ietf-eai-imap-utf8-00.txt) References: <5d3b5jhyoi.fsf@Hurtta06k.keh.iki.fi> <5d7iuajloq.fsf@Hurtta06k.keh.iki.fi> <45DEA42C.2040905@alvestrand.no> Message-ID: Date: Fri, 23 Feb 2007 13:16:02 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <45DEA42C.2040905@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 23 Feb 2007 08:22:04 -0000, Harald Alvestrand wrote: > Charles Lindsey wrote: >> Indeed, the fact that both multipart/signed and DKIM insist on signing >> the C-T-encoded form on the wire (which may vary as it passes through >> various agents), instead of signing the original, unencoded form of the >> message (which is presumably what the signer actually cares about) is >> one of the major stupidities of both those schemes. > Charles, the consensus of all the WGs that have been over this field was > that it was impossible to preserve signatures if one signed the > unencoded format. It is certainly impossible using the tools as defined in RFC 1847 and RFC 3156. The question is whether they could have written things differently. Both Q-P and Base64 and fully reversible encodings (if implemented correctly), so there is no fundamental problem that I can see, and Content-MD5 was defined successfully on the basis that the unencoded text would be signed. If the object to be signed is a multipart or message type, it is not clear how RFC 3156 is supooosed to work (it instructs you to encode something that MIME does not permit you to encode). RFC 1847 does seem to indicate how to deal with that case. It is also interesting to note that RFC 3156 contains the words Implementor's note: It cannot be stressed enough that applications using this standard follow MIME's suggestion that you "be conservative in what you generate, and liberal in what you accept." In this particular case it means it would be wise for an implementation to accept messages with any content-transfer- encoding, but restrict generation to the 7-bit format required by this memo. This will allow future compatibility in the event the Internet SMTP framework becomes 8-bit friendly. Since our present task is to bring about that state where "the Internet SMTP framework becomes 8-bit friendly", it may yet one day become possible to take full advantage of that liberality. > > It's possible that you are a genius and everyone else who's worked on it > is an idiot. > But it's also possible that you haven't understood the problem. Evidently so. Perhaps you could explain it. As far as DKIM is concerned, see http://www.cs.man.ac.uk/~chl/uncode/uncode.html for a Perl script to do what is required (it is not quite correct in the case of some message types as it stands, but that shold be fixable). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Feb 23 08:21:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKaMN-0004iV-DV; Fri, 23 Feb 2007 08:21:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKaMN-0004i8-24 for ima@ietf.org; Fri, 23 Feb 2007 08:21:15 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKaM9-00017F-AJ for ima@ietf.org; Fri, 23 Feb 2007 08:21:15 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HKaLq-0002sy-0t for ima@ietf.org; Fri, 23 Feb 2007 14:20:42 +0100 Received: from d253084.dialin.hansenet.de ([80.171.253.84]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Feb 2007 14:20:42 +0100 Received: from nobody by d253084.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 23 Feb 2007 14:20:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 23 Feb 2007 14:11:51 +0100 Organization: Lines: 33 Message-ID: <45DEE817.6FDF@xyzzy.claranet.de> References: <45DC6708.4DFD@xyzzy.claranet.de> <20070222.204822.52193432.fujiwara@jprs.co.jp> <20070223.152211.91341781.fujiwara@jprs.co.jp> <45DEA5F2.7070904@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253084.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [EAI] Re: utf-8-address syntax: I-D ACTION:draft-ietf-eai-dsn-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: [raw UTF-8 not fixed, what you see is what I get] > if the address is : > Before downgrading (UTF8SMTP environment) > ORCPT=3Dutf-8-enc; So here it's a "normal" percent-encoded "+", %2B > After downgrading (DSN supported, but UTF8SMTP not supported): > ORCPT=3Dutf-8-enc: But here it's some obscure %u1234 or %U12345678 style. IMO that's ugly. We're not in a position where we have to escape Unicode as in John's I-D.klensin-unicode-escapes-02. The input is already valid (one hopes) raw UTF-8, why not simply use RFC 3987 style for it ? I.e. "percent-encoded" everywhere, not only for some forbidden ASCII octets (CTL, SP, %, +, and =3D). With 3987 style we'd get a decent chance that the result will be compatible (to some degree) with IRIs in a future 2368ter. The %u plus %U invention is very near to \u and \U in chapter 2.1 of John's draft, but not exactly the same, see http://www.w3.org/TR/charmod/#C042 Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 24 00:15:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKpEt-0001YL-KV; Sat, 24 Feb 2007 00:14:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKpEs-0001T7-AW for ima@ietf.org; Sat, 24 Feb 2007 00:14:30 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HKpEo-0001Nx-9w for ima@ietf.org; Sat, 24 Feb 2007 00:14:29 -0500 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1O5EPDT004779 for ; Sat, 24 Feb 2007 05:14:25 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JDY00201BNWNC00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Fri, 23 Feb 2007 22:14:25 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JDY00NWJBVY0940@mail-amer.sun.com>; Fri, 23 Feb 2007 22:14:25 -0700 (MST) Date: Fri, 23 Feb 2007 21:14:21 -0800 From: Chris Newman Subject: HEX-UTF-8 vs. Unicode-escapes (was Re: [EAI] Re: utf-8-address syntax: ...) In-reply-to: <45DEE817.6FDF@xyzzy.claranet.de> To: Frank Ellermann , ima@ietf.org Message-id: <7B2BD15534B1152F690C2D08@[10.1.110.5]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <45DC6708.4DFD@xyzzy.claranet.de> <20070222.204822.52193432.fujiwara@jprs.co.jp> <20070223.152211.91341781.fujiwara@jprs.co.jp> <45DEA5F2.7070904@alvestrand.no> <45DEE817.6FDF@xyzzy.claranet.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann wrote on 2/23/07 14:11 +0100: > But here it's some obscure %u1234 or %U12345678 > style. IMO that's ugly. We're not in a position > where we have to escape Unicode as in John's > I-D.klensin-unicode-escapes-02. > > The input is already valid (one hopes) raw UTF-8, > why not simply use RFC 3987 style for it ? I.e. > "percent-encoded" everywhere, not only for some > forbidden ASCII octets (CTL, SP, %, +, and =). I slightly favor HEX-UTF-8 encoding for this particular application, but I felt using the unicode-escapes approach in the first draft was more likely to result in appropriate consideration of the issue. This is an interesting design tradeoff with no clear right or wrong answer. > With 3987 style we'd get a decent chance that the > result will be compatible (to some degree) with > IRIs in a future 2368ter. A relevant and substantive benefit. > The %u plus %U invention is very near to \u and \U > in chapter 2.1 of John's draft, but not exactly > the same, see http://www.w3.org/TR/charmod/#C042 The current proposal arguably violates but HEX-UTF-8 arguably violates and is a double encoding. So we have: HEX-UTF-8 Benefits: * Simpler for most software using this format * Potential benefits from IRI mailto compatibility * Familiar encoding Unicode-escape benefits: * Prevents a double-encoding * Simpler for humans to lookup and interpret in transcripts * Encoded form is often shorter than HEX-UTF-8 While I don't feel strongly about the outcome, I do feel strongly that this topic is worthy of debate. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 24 09:18:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKxj8-0007CK-Tb; Sat, 24 Feb 2007 09:18:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKxj7-0007CA-Rl for ima@ietf.org; Sat, 24 Feb 2007 09:18:17 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKxj2-0002j1-Hy for ima@ietf.org; Sat, 24 Feb 2007 09:18:17 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HKxir-0005Sf-7b for ima@ietf.org; Sat, 24 Feb 2007 15:18:01 +0100 Received: from 212.82.251.32 ([212.82.251.32]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Feb 2007 15:18:01 +0100 Received: from nobody by 212.82.251.32 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 24 Feb 2007 15:18:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 24 Feb 2007 15:16:21 +0100 Organization: Lines: 35 Message-ID: <45E048B5.31CE@xyzzy.claranet.de> References: <45DC6708.4DFD@xyzzy.claranet.de> <20070222.204822.52193432.fujiwara@jprs.co.jp> <20070223.152211.91341781.fujiwara@jprs.co.jp> <45DEA5F2.7070904@alvestrand.no> <45DEE817.6FDF@xyzzy.claranet.de> <7B2BD15534B1152F690C2D08@[10.1.110.5]> 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: 212.82.251.32 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [EAI] Re: HEX-UTF-8 vs. Unicode-escapes X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Newman wrote: > HEX-UTF-8 arguably violates ACK. Maybe we can say that we should use one style consistently, either 3987 or %u + %U, No exceptions for CTL, SP, %, +, and =. > HEX-UTF-8 Benefits: > * Simpler for most software using this format > * Potential benefits from IRI mailto compatibility > * Familiar encoding > Unicode-escape benefits: > * Prevents a double-encoding > * Simpler for humans to lookup and interpret in transcripts > * Encoded form is often shorter than HEX-UTF-8 %23%56%89 vs. %u3456 for u+0800 up to u+FFFF or %23%56%89%BC vs. %U3456789A for u+10000 up to u+10FFFF (of course excluding non-characters and surrogates). > I don't feel strongly about the outcom Nor me, but using three styles, %23, %u3456, and %U3456789A is against my KISS instincts. The original used only "+" for its own purposes, i.e. introducing 2HEXDIG to escape CTL, SP, +, or =. You've replaced "+" by "%" for . I like that better, but why did you keep "+" in the list of forbidden characters requiring %2B ? Is it necessary to escape "+" in the context of utf-8-enc ? Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Feb 24 14:12:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL2J5-0004w7-QZ; Sat, 24 Feb 2007 14:11:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HL2J4-0004vI-PG for ima@ietf.org; Sat, 24 Feb 2007 14:11:42 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HL2Ee-0007ki-MN for ima@ietf.org; Sat, 24 Feb 2007 14:07:11 -0500 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1HL2Ea-000J7X-IS; Sat, 24 Feb 2007 14:07:05 -0500 Date: Sat, 24 Feb 2007 14:07:03 -0500 From: John C Klensin To: Chris Newman , Frank Ellermann , ima@ietf.org Subject: Re: HEX-UTF-8 vs. Unicode-escapes (was Re: [EAI] Re: utf-8-address syntax: ...) Message-ID: In-Reply-To: <7B2BD15534B1152F690C2D08@[10.1.110.5]> References: <45DC6708.4DFD@xyzzy.claranet.de> <20070222.204822.52193432.fujiwara@jprs.co.jp> <20070223.152211.91341781.fujiwara@jprs.co.jp> <45DEA5F2.7070904@alvestrand.no> <45DEE817.6FDF@xyzzy.claranet.de> <7B2BD15534B1152F690C2D08@[10.1.110.5]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris, A few observations... --On Friday, February 23, 2007 9:14 PM -0800 Chris Newman wrote: > Frank Ellermann wrote on 2/23/07 14:11 +0100: >> But here it's some obscure %u1234 or %U12345678 >> style. IMO that's ugly. We're not in a position >> where we have to escape Unicode as in John's >> I-D.klensin-unicode-escapes-02. >> >> The input is already valid (one hopes) raw UTF-8, >> why not simply use RFC 3987 style for it ? I.e. >> "percent-encoded" everywhere, not only for some >> forbidden ASCII octets (CTL, SP, %, +, and =). > > I slightly favor HEX-UTF-8 encoding for this particular > application, but I felt using the unicode-escapes approach in > the first draft was more likely to result in appropriate > consideration of the issue. This is an interesting design > tradeoff with no clear right or wrong answer. Note that the strong recommendation for \u \U (or %u %U) has been taken out of unicode-escapes after a good deal of fairly aggressive input and no defenders. If there is a recommendation left in that document, it is for delimited strings rather than length cues built into the introducer-syntax (especially not cues based on case-sensitive interpretations). I agree that there is a tradeoff with no clear answer. I do believe that there is a very strong case to be made for a single encoding in a given string, not a mixture. If that forces us to Hex-UTF-8, that would sadden me a bit, but it seems more attractive than mixtures. >> With 3987 style we'd get a decent chance that the >> result will be compatible (to some degree) with >> IRIs in a future 2368ter. > > A relevant and substantive benefit. This opinion may not make me very popular, but I think it needs to be expressed. With all due respect to Martin, Michel, and the review process, some of our work, the thinking that led to the Unicode-Escapes work, and the RFC 4690 and IDNAbis efforts have left me wondering (at least) whether it is possible that we completely botched IRIs. As an intermediate translation format, it may be fine. But, for general-purpose, end-user use, it appears insufficiently ambitious. It can generate some very strange-looking strings when right-to-left elements are included, it doesn't provide a clean way to map between characters that seem natural in the user's localized environment and protocol (scheme) names, and so on. I know that 3987-style IRIs are deployed in a few important products, but it seems to me that there is still an opportunity to review some of the decisions and, if appropriate, define a different and more user-friendly abstraction that rests above URIs and perhaps about IRIs. To that end, I think we should figure out what we really need for UTF8SMTP and the associated protocols, create an appropriate abstraction and syntax for a mail-address reference, and then figure what that means for mailto (2368ter or otherwise) and IRIs, not the other way around. As one handy example, there are several reasons, including both R to L scripts and countries in which a "mail host, then mailbox" syntax seems more natural than "mailbox at host", why an internationalized email address format, expressed in abstract reference form, might benefit from avoiding use of the "@" entirely. I don't have good ideas that don't take us back a few steps toward the dreaded X.400 syntax, but I wonder whether, at an object-naming abstraction level, we wouldn't be better off with mailbox="Chris.Newman" org="Sun.COM" altmailbox=... or its XML-ish equivalent with the name-value pairs being order-independent and maybe a bunch of synonyms or mappings for the keywords, rather than seeing whether we can preserve "mailto:" and what IRIs turned out to be given the constraints that were assumed. And, in _that_ format, I go back to contending that we are better off with code point offsets than Hex-encoded UTF-8. >> The %u plus %U invention is very near to \u and \U >> in chapter 2.1 of John's draft, but not exactly >> the same, see http://www.w3.org/TR/charmod/#C042 > > The current proposal arguably violates > but HEX-UTF-8 arguably > violates and is a double > encoding. > > So we have: > > HEX-UTF-8 Benefits: > * Simpler for most software using this format > * Potential benefits from IRI mailto compatibility About which I'm dubious... see above. > * Familiar encoding Depends on who one thinks it is being familiar with. I contend that it is pathological for the casual user, which is exactly the concern that started my on what became the uncode-escapes exercise. Certainly if is more geek- and URI-friendly, but that may be a symptom of the problem, not a benefit. > Unicode-escape benefits: > * Prevents a double-encoding > * Simpler for humans to lookup and interpret in transcripts > * Encoded form is often shorter than HEX-UTF-8 And, of course, often much shorter with East Asian languages whose users are assumed to be a major beneficiary of i18n email. > While I don't feel strongly about the outcome, I do feel > strongly that this topic is worthy of debate. Yes. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 25 10:00:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLKqV-0004t1-Mm; Sun, 25 Feb 2007 09:59:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLKqU-0004sk-GH for ima@ietf.org; Sun, 25 Feb 2007 09:59:26 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLKqP-0005B9-R3 for ima@ietf.org; Sun, 25 Feb 2007 09:59:26 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3&clerew^man*ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45e1a439.2f1.142 for ima@ietf.org; Sun, 25 Feb 2007 14:59:05 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l1PEx3nT017618 for ; Sun, 25 Feb 2007 14:59:04 GMT To: IMA Subject: Re: HEX-UTF-8 vs. Unicode-escapes (was Re: [EAI] Re: utf-8-address syntax: ...) References: <45DC6708.4DFD@xyzzy.claranet.de> <20070222.204822.52193432.fujiwara@jprs.co.jp> <20070223.152211.91341781.fujiwara@jprs.co.jp> <45DEA5F2.7070904@alvestrand.no> <45DEE817.6FDF@xyzzy.claranet.de> <7B2BD15534B1152F690C2D08@[10.1.110.5]> Message-ID: Date: Sun, 25 Feb 2007 14:59:03 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <7B2BD15534B1152F690C2D08@[10.1.110.5]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 24 Feb 2007 05:14:21 -0000, Chris Newman wrote: > Frank Ellermann wrote on 2/23/07 14:11 +0100: >> The input is already valid (one hopes) raw UTF-8, >> why not simply use RFC 3987 style for it ? I.e. >> "percent-encoded" everywhere, not only for some >> forbidden ASCII octets (CTL, SP, %, +, and =). Or, for that matter, why not just use ? That would be no more of a mess that RFC 3461 already made of it. There is nothing in RFC 3461 thst prevents the use of for octets >=128, except that they didn't anticipate it. Existing software (and humans) that understand the addr-type rfc822 would then immediately understand addr-type utf-8-enc. ain't (that) broken. Why fix it? There are already too many ways of encoding 8bits into 7. Why invent yet another one? > > I slightly favor HEX-UTF-8 encoding for this particular application, +1 > The current proposal arguably violates > but HEX-UTF-8 arguably violates > and is a double encoding. I think your average user will be vaguely aware that he is using utf-8, but will never have heard of Unicode. Moreover, our whole EAI endeavour is based on the use of UTF-8 throughout (some software may internally translate it into Unicode - probably in the form of UCS-16 - but that will, and should remain, entirely invisible from the outside). Hence he will not regard it as a "double encoding", and hence IMO it is better to violate #CO45 than to violate #CO42 (and #CO42 would support xtext in these contexts also). > > So we have: > > HEX-UTF-8 Benefits: > * Simpler for most software using this format > * Potential benefits from IRI mailto compatibility > * Familiar encoding and even more familiar, in this context, as xtext. > Unicode-escape benefits: > * Prevents a double-encoding > * Simpler for humans to lookup and interpret in transcripts Not true for a human who thinks in terms of Utf-8. > * Encoded form is often shorter than HEX-UTF-8 For something to be used only in ORCPT/etc parameters and in DSNs, that is a minor consideration, especially as raw UTF-8 is also to be permitted in UTF8SMTP environments which is where this stuff will mostly be seen. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Feb 25 11:01:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLLo3-0007We-CM; Sun, 25 Feb 2007 11:00:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLLo1-0007SI-OS for ima@ietf.org; Sun, 25 Feb 2007 11:00:57 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLLnv-0007K4-2G for ima@ietf.org; Sun, 25 Feb 2007 11:00:57 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HLLnT-0000nz-1k for ima@ietf.org; Sun, 25 Feb 2007 17:00:23 +0100 Received: from du-042-227.access.de.clara.net ([213.221.65.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Feb 2007 17:00:23 +0100 Received: from nobody by du-042-227.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Feb 2007 17:00:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sun, 25 Feb 2007 16:59:32 +0100 Organization: Lines: 12 Message-ID: <45E1B264.3045@xyzzy.claranet.de> References: <45DC6708.4DFD@xyzzy.claranet.de> <20070222.204822.52193432.fujiwara@jprs.co.jp> <20070223.152211.91341781.fujiwara@jprs.co.jp> <45DEA5F2.7070904@alvestrand.no> <45DEE817.6FDF@xyzzy.claranet.de> <7B2BD15534B1152F690C2D08@[10.1.110.5]> 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: du-042-227.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [EAI] Re: HEX-UTF-8 vs. Unicode-escapes X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > why not just use ? Good question, it's not nice, but as you say it's also not broken. What you get is in essence the same as "3987 style" swapping "+" and "%" everywhere. John argued it's too long for the relevant range u+0800 up to u+FFFF. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 26 01:01:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLYul-0000n6-7e; Mon, 26 Feb 2007 01:00:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLYuj-0000mk-Lp for ima@ietf.org; Mon, 26 Feb 2007 01:00:45 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLYuh-0008Vy-CG for ima@ietf.org; Mon, 26 Feb 2007 01:00:45 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l1Q60Usu027175 for ; Mon, 26 Feb 2007 15:00:30 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 0e29_a9ac691c_c55e_11db_9e3c_0014221f2a2d; Mon, 26 Feb 2007 15:00:30 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:47344) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 26 Feb 2007 14:59:31 +0900 Message-Id: <6.0.0.20.2.20070225181911.07b73b30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 25 Feb 2007 18:46:29 +0900 To: John C Klensin , Chris Newman , Frank Ellermann , ima@ietf.org From: Martin Duerst Subject: Re: HEX-UTF-8 vs. Unicode-escapes (was Re: [EAI] Re:utf-8-address syntax: ...) In-Reply-To: References: <45DC6708.4DFD@xyzzy.claranet.de> <20070222.204822.52193432.fujiwara@jprs.co.jp> <20070223.152211.91341781.fujiwara@jprs.co.jp> <45DEA5F2.7070904@alvestrand.no> <45DEE817.6FDF@xyzzy.claranet.de> <7B2BD15534B1152F690C2D08@[10.1.110.5]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 04:07 07/02/25, John C Klensin wrote: >Chris, > >A few observations... > >--On Friday, February 23, 2007 9:14 PM -0800 Chris Newman wrote: > >> Frank Ellermann wrote on 2/23/07 14:11 +0100: >>> But here it's some obscure %u1234 or %U12345678 >>> style. IMO that's ugly. We're not in a position >>> where we have to escape Unicode as in John's >>> I-D.klensin-unicode-escapes-02. >>> >>> The input is already valid (one hopes) raw UTF-8, >>> why not simply use RFC 3987 style for it ? I.e. >>> "percent-encoded" everywhere, not only for some >>> forbidden ASCII octets (CTL, SP, %, +, and =). >> >> I slightly favor HEX-UTF-8 encoding for this particular >> application, but I felt using the unicode-escapes approach in >> the first draft was more likely to result in appropriate >> consideration of the issue. This is an interesting design >> tradeoff with no clear right or wrong answer. > >Note that the strong recommendation for \u \U (or %u %U) has been taken out of unicode-escapes after a good deal of fairly aggressive input and no defenders. If there is a recommendation left in that document, it is for delimited strings rather than length cues built into the introducer-syntax (especially not cues based on case-sensitive interpretations). > >I agree that there is a tradeoff with no clear answer. I do believe that there is a very strong case to be made for a single encoding in a given string, not a mixture. If that forces us to Hex-UTF-8, that would sadden me a bit, but it seems more attractive than mixtures. > >>> With 3987 style %hh escaping didn't in any way originate in RFC 3987. The only thing that RFC 3987 did with respect to escaping was to make it possible to go from characters to %hh, rather than only from arbitrary octets to %hh. >>> we'd get a decent chance that the >>> result will be compatible (to some degree) with >>> IRIs in a future 2368ter. As far as I understand, this escaping discussion only concerns DSN, right? I'm not an expert, but I think that while such 'to some degree compatibility' might not hurt too much, it's also not terribly important. >> A relevant and substantive benefit. > >This opinion may not make me very popular, but I think it needs to be expressed. With all due respect to Martin, Michel, and the review process, some of our work, the thinking that led to the Unicode-Escapes work, and the RFC 4690 and IDNAbis efforts have left me wondering (at least) whether it is possible that we completely botched IRIs. As an intermediate translation format, it may be fine. But, for general-purpose, end-user use, it appears insufficiently ambitious. There was never a claim that IRIs would address user's needs around the world better than URIs do this job for English-speaking, basic-Latin-letter- using people. Google and other search services are way better for "give me the Web page I want that I don't know about, but I know must be out there". IRIs just close an important gap to make sure references to character strings not in US-ASCII work reliably in IRIs and via URIs. >It can generate some very strange-looking strings when right-to-left elements are included, Yes. That has virtually nothing to do with URIs or IRIs, and quite a lot with the fundamental problems of bidi. Strange-looking things can easily be produced for your syntax proposals below, too. >it doesn't provide a clean way to map between characters that seem natural in the user's localized environment and protocol (scheme) names, Yes, we didn't provide a way to write http:, ftp:, mailto:, and so on in different scripts. For some work in this direction, please check out http://www.ietf.org/rfc/rfc2324.txt :-). Given that to most people, strings such as http and ftp are opaque, providing lists of correspondences for each script wouldn't have been too difficult (choices can essentially be almost arbitrary, and there are only around 100 scripts, and probably way less really relevant ones). But still, there are scalability and deployment problems. >and so on. I know that 3987-style IRIs are deployed in a few important products, but it seems to me that there is still an opportunity to review some of the decisions and, if appropriate, define a different and more user-friendly abstraction that rests above URIs and perhaps about IRIs. If we had any reasonably good idea of how such an abstration would look and work (as opposed to what services and benefits it should provide), that might be a good way to spend our time. >To that end, I think we should figure out what we really need for UTF8SMTP and the associated protocols, create an appropriate abstraction and syntax for a mail-address reference, and then figure what that means for mailto (2368ter or otherwise) and IRIs, not the other way around. As one handy example, there are several reasons, including both R to L scripts and countries in which a "mail host, then mailbox" syntax seems more natural than "mailbox at host", There are definitely a lot of countries where postal addresses are written outside-in, rather than inside-out as in the US and Western Europe. But once we go there, we would have to turn around domain name hierarchies, too, e.g. COM.Sun in the examples below (which is probably why X.400 had things chopped apart much more finely). >why an internationalized email address format, expressed in abstract reference form, might benefit from avoiding use of the "@" entirely. I don't have good ideas that don't take us back a few steps toward the dreaded X.400 syntax, but I wonder whether, at an object-naming abstraction level, we wouldn't be better off with > mailbox="Chris.Newman" org="Sun.COM" altmailbox=... >or its XML-ish equivalent > > >with the name-value pairs being order-independent and maybe a bunch of synonyms or mappings for the keywords, rather than seeing whether we can preserve "mailto:" and what IRIs turned out to be given the constraints that were assumed. And, in _that_ format, I go back to contending that we are better off with code point offsets than Hex-encoded UTF-8. Of course, except that once you're using XML, real UTF-8 comes for free. >>> The %u plus %U invention is very near to \u and \U >>> in chapter 2.1 of John's draft, but not exactly >>> the same, see http://www.w3.org/TR/charmod/#C042 >> >> The current proposal arguably violates >> but HEX-UTF-8 arguably >> violates and is a double >> encoding. >> >> So we have: >> >> HEX-UTF-8 Benefits: >> * Simpler for most software using this format >> * Potential benefits from IRI mailto compatibility > >About which I'm dubious... see above. Same for me, but with somewhat different reasons. >> * Familiar encoding > >Depends on who one thinks it is being familiar with. I contend that it is pathological for the casual user, which is exactly the concern that started my on what became the uncode-escapes exercise. Certainly if is more geek- and URI-friendly, but that may be a symptom of the problem, not a benefit. > >> Unicode-escape benefits: >> * Prevents a double-encoding >> * Simpler for humans to lookup and interpret in transcripts >> * Encoded form is often shorter than HEX-UTF-8 > >And, of course, often much shorter with East Asian languages whose users are assumed to be a major beneficiary of i18n email. It's actually not East Asian languages that benefit most. Because they use a large character repertoire and correspondingly short actual data (in number of characters), length restrictions are much less of an issue for them. Those who get hit hardest are languages that use alphabetic scrits, or scripts close in size to alphabetic ones, but don't get the benefit of short UTF-8 sequences. >> While I don't feel strongly about the outcome, I do feel >> strongly that this topic is worthy of debate. Well, I guess I have written too much already to contradict here :-(. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Feb 26 17:08:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLo0e-0005YK-PP; Mon, 26 Feb 2007 17:07:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmoJ-0005mS-F8; Mon, 26 Feb 2007 15:51:03 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HLmoI-0007jj-Su; Mon, 26 Feb 2007 15:51:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 830E12AD20; Mon, 26 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HLmnL-000503-7O; Mon, 26 Feb 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Feb 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-scenarios-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : UTF-8 Mail: Scenarios Author(s) : H. Alvestrand Filename : draft-ietf-eai-scenarios-02.txt Pages : 9 Date : 2007-2-26 This document describes some scenarios in which one can imagine internationalized email addresses deployed, and tries to draw some conclusions about what's acceptable and what's not for users in those scenarios. One possible set of extensions that can work in these scenarios is those described in the UTF8SMTP extension documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-scenarios-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-scenarios-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-scenarios-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-26122333.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-scenarios-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-scenarios-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-26122333.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Tue Feb 27 00:44:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLv88-0008Tg-Au; Tue, 27 Feb 2007 00:44:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLv86-0008Ss-5R for ima@ietf.org; Tue, 27 Feb 2007 00:44:02 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLv84-0002hd-93 for ima@ietf.org; Tue, 27 Feb 2007 00:44:02 -0500 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l1R5hxUp019966 for ; Tue, 27 Feb 2007 05:43:59 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JE300B01VIGB600@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 26 Feb 2007 22:43:59 -0700 (MST) Received: from dhcp-usca15-127-48.red.iplanet.com (host-48-127-18-192.iplanet.com [192.18.127.48]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JE300GONX99PV50@mail-amer.sun.com>; Mon, 26 Feb 2007 22:43:59 -0700 (MST) Date: Mon, 26 Feb 2007 15:27:29 -0800 From: Chris Newman Subject: Re: HEX-UTF-8 vs. Unicode-escapes (was Re: [EAI] Re: utf-8-address syntax: ...) In-reply-to: To: Charles Lindsey , IMA Message-id: <51E3A2BCF75F818680F0D4A6@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <45DC6708.4DFD@xyzzy.claranet.de> <20070222.204822.52193432.fujiwara@jprs.co.jp> <20070223.152211.91341781.fujiwara@jprs.co.jp> <45DEA5F2.7070904@alvestrand.no> <45DEE817.6FDF@xyzzy.claranet.de> <7B2BD15534B1152F690C2D08@[10.1.110.5]> X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote on 2/25/07 14:59 +0000: > On Sat, 24 Feb 2007 05:14:21 -0000, Chris Newman > wrote: >> Frank Ellermann wrote on 2/23/07 14:11 +0100: >>> The input is already valid (one hopes) raw UTF-8, >>> why not simply use RFC 3987 style for it ? I.e. >>> "percent-encoded" everywhere, not only for some >>> forbidden ASCII octets (CTL, SP, %, +, and =). > > Or, for that matter, why not just use ? That would be no more of a > mess that RFC 3461 already made of it. There is nothing in RFC 3461 thst > prevents the use of for octets >=128, except that they didn't > anticipate it. Existing software (and humans) that understand the addr-type > rfc822 would then immediately understand addr-type utf-8-enc. ain't > (that) broken. Why fix it? There are already too many ways of encoding 8bits > into 7. Why invent yet another one? Good question. I would have preferred to use xtext, but this text from RFC 3461 makes that not possible without too much risk of breakage: Due to limitations in the Delivery Status Notification format, the value of the original recipient address prior to encoding as "xtext" MUST consist entirely of printable (graphic and white space) characters from the US-ASCII [4] repertoire. If an addr-type is defined for addresses which use characters outside of this repertoire, the specification for that addr-type MUST define the means of encoding those addresses in printable US-ASCII characters when are then encoded as xtext. The problem is that xtext is a transfer encoding which is removed when a traditional message/delivery-status part is generated and there's a hard requirement in today's deployed MTAs that the result of xtext removal be 7-bit ASCII. So the choice is to produce a non-xtext encoding for all the 8-bit characters and have two encodings present, or to design an encoding that obviates the need for xtext. The latter seemed cleaner to me, although an approach that used xtext for encoding 7-bit and something else for non-ASCII is an approach the working group might want to consider. So xtext was badly botched. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Feb 27 09:26:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3Gp-0004x4-VY; Tue, 27 Feb 2007 09:25:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM3Go-0004rU-Uv for ima@ietf.org; Tue, 27 Feb 2007 09:25:34 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM3Gn-0004nM-Cn for ima@ietf.org; Tue, 27 Feb 2007 09:25:34 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3&clerew#man^ac*uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45e43f51.13984.191 for ima@ietf.org; Tue, 27 Feb 2007 14:25:21 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l1REPL9M028414 for ; Tue, 27 Feb 2007 14:25:22 GMT Date: Tue, 27 Feb 2007 14:25:20 -0000 To: IMA Subject: Re: HEX-UTF-8 vs. Unicode-escapes (was Re: [EAI] Re: utf-8-address syntax: ...) References: <45DC6708.4DFD@xyzzy.claranet.de> <20070222.204822.52193432.fujiwara@jprs.co.jp> <20070223.152211.91341781.fujiwara@jprs.co.jp> <45DEA5F2.7070904@alvestrand.no> <45DEE817.6FDF@xyzzy.claranet.de> <7B2BD15534B1152F690C2D08@[10.1.110.5]> <51E3A2BCF75F818680F0D4A6@446E7922C82D299DB29D899F> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <51E3A2BCF75F818680F0D4A6@446E7922C82D299DB29D899F> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 26 Feb 2007 23:27:29 -0000, Chris Newman wrote: > Good question. I would have preferred to use xtext, but this text from > RFC 3461 makes that not possible without too much risk of breakage: > > Due to limitations in the Delivery Status Notification format, the > value of the original recipient address prior to encoding as "xtext" > MUST consist entirely of printable (graphic and white space) > characters from the US-ASCII [4] repertoire. If an addr-type is > defined for addresses which use characters outside of this > repertoire, the specification for that addr-type MUST define the > means of encoding those addresses in printable US-ASCII characters > when are then encoded as xtext. > > The problem is that xtext is a transfer encoding which is removed when a > traditional message/delivery-status part is generated and there's a hard > requirement in today's deployed MTAs that the result of xtext removal be > 7-bit ASCII. Ah! I had not appreciated that the xtext had to be unscrambled when it was put into a message/delivery-status. So they force us into a double encoding. All right, suppose we use %HEX for the utf-8, and we have a local-part Aa+å then it becomes %1BAa%2B%C3%B8 which then has to be encoded into , which turns out to be a Null transformation. I suppose that is as good as we are going to get. The problem arises, of course, because delivery status was made (quite wrongly) to be a message type, and you are not allowed to C-T-encode message types. Really, one or other of those decisions needs to be reversed, but that is not so easy. > So xtext was badly botched. Indeed so. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima