From ima-bounces@ietf.org Tue May 01 06:38:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HipkS-0006gN-Du; Tue, 01 May 2007 06:38:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HipkS-0006gI-1U for ima@ietf.org; Tue, 01 May 2007 06:38:20 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HipkP-0001dP-Bq for ima@ietf.org; Tue, 01 May 2007 06:38:19 -0400 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 46371897.b221.2e1 for ima@ietf.org; Tue, 1 May 2007 11:38:15 +0100 (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 l41AcFp2020904 for ; Tue, 1 May 2007 11:38:16 +0100 (BST) To: IMA Subject: Re: [EAI] MIME prohibition stupid vs. brilliant References: <69DEB4ACF63843407008496D@[192.168.1.119]> <4632E910.723@xyzzy.claranet.de> <4635FA85.7020104@alvestrand.no> Message-ID: Date: Tue, 01 May 2007 11:38:14 +0100 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: <4635FA85.7020104@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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, 30 Apr 2007 15:17:41 +0100, Harald Alvestrand wrote: > Frank Ellermann wrote: >> >> Now I'm confused. It's no stupid prohibition. It's based on three >> assumptions: (1) Messages consist of an ASCII header and a body. >> (2) The body can be structured and/or encoded as specified in the >> header of the message. (3) Eveybody knows how a message/rfc822 is >> structured, and how it specifies the encoding of its body, because >> the message/rfc822 structure is what MIME and RFC 2045 are about. >> > The thing that is (possibly) stupid is extending this restriction across > every future MIME type that starts with the letters "message/". See RFC > 2046 section 5.2.2 for the rather specific restrictions on encoding for > message/partial. There are lots of good things in MIME, but the message/* types are not one of them. They are so badly defined in RFC 204[56] that any attempt to add news ones, except of the most trivial kind, will inevitably lead to interoperability problems with the presently installed base. Contrast this with multipart/* types where the constraints on future types are well documented, allowing new such types to have been introduced on several occasions without problem. -- 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 May 01 06:44:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HipqR-0001cC-7U; Tue, 01 May 2007 06:44:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HipqQ-0001c7-Do for ima@ietf.org; Tue, 01 May 2007 06:44:30 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HipqP-0002pc-Si for ima@ietf.org; Tue, 01 May 2007 06:44:30 -0400 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 46371a0c.140fd.68 for ima@ietf.org; Tue, 1 May 2007 11:44:28 +0100 (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 l41AiSrQ021281 for ; Tue, 1 May 2007 11:44:28 +0100 (BST) To: IMA Subject: Re: [EAI] Strip 8th bit (was: Fwd: Re: Minutes from Prague) References: <0BE9565F3198DD14E350AB4A@[192.168.1.108]> <462E0B47.6564@xyzzy.claranet.de> <0589C738F42DFA3B1AE828DE@[192.168.1.119]> <4632FBAF.5966@xyzzy.claranet.de> <2FA402DB7D855174A6072E72@p3.JCK.COM> Message-ID: Date: Tue, 01 May 2007 11:44:27 +0100 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: <2FA402DB7D855174A6072E72@p3.JCK.COM> 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 Mon, 30 Apr 2007 19:35:27 +0100, John C Klensin wrote: > --On Monday, 30 April, 2007 11:58 +0100 Charles Lindsey > wrote: >> Clearly, bouncing the message as FUBAR is always the safe >> option. >> >> But I think it better, if you are determined to try to >> continue with delivery, just to send the 8bits regardless >> rather than to strip the MSB (this is what sendmail does >> AFAICT). > > But this is exactly the "just-send-8" option that was rejected > during the original MIME work, rejected again when MIME advanced > to Draft, and rejected again by DRUMS (and maybe a few other > times). Even if you were right, it would be too late. You misunderstand. I am not trying to make such things legal. All I am trying to say is that, if you have something that is illegal, and are determined to send it on regardless (as opposed to bouncing it), then it is better to send it on in an illegal form rather than to force it to be legal by making arbitrary changes, such as dropping MSBs. It is a matter of choosing the lesser of two evils. > >> .... >> And it is strictly of-topic for this group, ... > > So, why are you bringing it up here? I was merely responding to a remark by Frank, who was in turn responding to a remark by Harald. -- 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 May 01 14:21:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiwyy-0006Ng-MF; Tue, 01 May 2007 14:21:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiwyx-0006GR-7B for ima@ietf.org; Tue, 01 May 2007 14:21:47 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hiwyp-0005id-0G for ima@ietf.org; Tue, 01 May 2007 14:21:47 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hiwyc-0007Md-PX for ima@ietf.org; Tue, 01 May 2007 20:21:28 +0200 Received: from 1cust113.tnt6.hbg2.deu.da.uu.net ([149.225.18.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 May 2007 20:21:26 +0200 Received: from nobody by 1cust113.tnt6.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 May 2007 20:21:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 01 May 2007 20:17:21 +0200 Organization: Lines: 54 Message-ID: <46378431.156D@xyzzy.claranet.de> References: <69DEB4ACF63843407008496D@[192.168.1.119]> <4632E910.723@xyzzy.claranet.de> <4635FA85.7020104@alvestrand.no> 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: 1cust113.tnt6.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [EAI] Re: MIME prohibition stupid vs. brilliant 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: >> Now I'm confused. It's no stupid prohibition. It's based on three >> assumptions: (1) Messages consist of an ASCII header and a body. >> (2) The body can be structured and/or encoded as specified in the >> header of the message. (3) Eveybody knows how a message/rfc822 is >> structured, and how it specifies the encoding of its body, because >> the message/rfc822 structure is what MIME and RFC 2045 are about. [quotes rearranged] > The content of a message/partial doesn't consist of an ASCII header > and a body, so I lost you at (1). We're talking about different things. When I wrote "messages" I meant a complete message like a news article or an SMTP mail object, not the MIME type message/*. A message/partial is no complete mail, like an image/jpeg or text/pdf is no complete mail: They can only occur in the body of a complete mail or in the body of a complete MIME part. And for a complete mail (or a complete MIME part) there's a header. This header can be empty in some special cases related to multipart/*, but "empty" is no contradiction to ASCII. > The thing that is (possibly) stupid is extending this restriction > across every future MIME type that starts with the letters "message/". > See RFC 2046 section 5.2.2 for the rather specific restrictions on > encoding for message/partial. It uses the term "individual message" for what I called "message" or "complete message". When I'm talking about media types I'd (try to) say "message/*" or similar. The terminology is interchangable for message/rfc822, message/news, or message/utf8, not other message/*. The message/partial stuff is a bit odd, but it also follows the spirit of "make it as obvious for MIME unaware UAs as possible" with its 7bit requirement. There are subtle issues for EAI in 5.2.2, the spec. claims that the final result of the reassembly is a "complete MIME entity". That can be of course a complete EAI message using UTF-8 in its header. No "downgrading magic" can prevent this, after reassembly users may find something in their inbox that's a message/utf8, if they like it or not. We are doomed if we stick to the fiction of a "UTF8SMTP universe". Our message/utf8 can leak into legacy message/rfc822 environments, we can't control it everywhere. But we can document this case, the reassembly of a "complete MIME entity" isn't guaranteed to be a traditional message/rfc822. One thing with MIME is stupid, its security considerations are lousy, we have to roll our own. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue May 01 14:36:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HixCn-0005J5-Vr; Tue, 01 May 2007 14:36:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HixCl-0005G7-UQ for ima@ietf.org; Tue, 01 May 2007 14:36:03 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HixCk-000786-KE for ima@ietf.org; Tue, 01 May 2007 14:36:03 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HixCf-0000oS-K8 for ima@ietf.org; Tue, 01 May 2007 20:35:57 +0200 Received: from 1cust113.tnt6.hbg2.deu.da.uu.net ([149.225.18.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 May 2007 20:35:57 +0200 Received: from nobody by 1cust113.tnt6.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 May 2007 20:35:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 01 May 2007 20:34:27 +0200 Organization: Lines: 21 Message-ID: <46378833.130D@xyzzy.claranet.de> References: <69DEB4ACF63843407008496D@[192.168.1.119]> <4632E910.723@xyzzy.claranet.de> <4635FA85.7020104@alvestrand.no> <46378431.156D@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: 1cust113.tnt6.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [EAI] Re: MIME prohibition stupid vs. brilliant (CORRECTION) 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: > There are subtle issues for EAI in 5.2.2, the spec. claims that the > final result of the reassembly is a "complete MIME entity". That > can be of course a complete EAI message using UTF-8 in its header. No, that's crap, it can't be a message/utf8 because message/partial is always 7bit, including the first part with the original header of the "inner" message . It gives us another problem, it's impossible to use message/partial for fragments of a message/utf8. If somebody wishes to fragment a message/utf8 they have to downgrade it first. At least it avoids the ugly case of an unexpected message/utf8 (after reassembly) showing up in the inbox of a traditional user. We need a section somewhere stating that fragmentation is by definition (in 2046) impossible for a message/utf8. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue May 01 15:16:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hixpw-0006N2-SY; Tue, 01 May 2007 15:16:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hixpv-0006L4-1M for ima@ietf.org; Tue, 01 May 2007 15:16:31 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hixpt-0002fa-No for ima@ietf.org; Tue, 01 May 2007 15:16:31 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hixpi-0007ID-Mr for ima@ietf.org; Tue, 01 May 2007 21:16:18 +0200 Received: from 1cust113.tnt6.hbg2.deu.da.uu.net ([149.225.18.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 May 2007 21:16:18 +0200 Received: from nobody by 1cust113.tnt6.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 May 2007 21:16:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 01 May 2007 21:15:37 +0200 Organization: Lines: 18 Message-ID: <463791D9.4232@xyzzy.claranet.de> References: <0BE9565F3198DD14E350AB4A@[192.168.1.108]> <462E0B47.6564@xyzzy.claranet.de> <0589C738F42DFA3B1AE828DE@[192.168.1.119]> <4632FBAF.5966@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: 1cust113.tnt6.hbg2.deu.da.uu.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [EAI] Re: Strip 8th bit (CORRECTION) 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 minimal MIME conformance requires to support message/partial > and/or message/external-body add the missing steps. That was hogwash, message/partial is guaranteed to be 7bit, and adding the missing steps to handle it in an "8to7" algorithm is trivial. And a message/external-body (the lines defining it, encapsulated header + phantom body) is also guaranteed to be US ASCII, that's also trivial. IMO we should now decide that any attempt to allow UTF-8 in MIME part headers or generally Content-* header fields is doomed. If you (= EAI folks) want to try it anyway please say so, because I don't like to waste more time with it. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed May 02 02:37:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj8T8-0007Lw-AQ; Wed, 02 May 2007 02:37:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hj8T6-0007Lo-QV for ima@ietf.org; Wed, 02 May 2007 02:37:40 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hj8T2-0006ER-3I for ima@ietf.org; Wed, 02 May 2007 02:37:40 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l426bZjO003801 for ; Wed, 2 May 2007 06:37:35 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 <0JHE00C01GUTUB00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Wed, 02 May 2007 00:37:35 -0600 (MDT) Received: from [192.168.0.103] ([209.78.251.2]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHE00FR9IELJK00@mail-amer.sun.com>; Wed, 02 May 2007 00:37:35 -0600 (MDT) Date: Tue, 01 May 2007 23:37:18 -0700 From: Chris Newman Subject: Re: [EAI] Re: Strip 8th bit (CORRECTION) In-reply-to: <463791D9.4232@xyzzy.claranet.de> To: Frank Ellermann , ima@ietf.org Message-id: <00B24EBC1C257D35F7368B65@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: <0BE9565F3198DD14E350AB4A@[192.168.1.108]> <462E0B47.6564@xyzzy.claranet.de> <0589C738F42DFA3B1AE828DE@[192.168.1.119]> <4632FBAF.5966@xyzzy.claranet.de> <463791D9.4232@xyzzy.claranet.de> 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 The WG would need a very good reason not to support native UTF-8 in the Content-Disposition filename parameter. There is a clear need for that if we're doing "UTF-8 clean" i18n headers, and the standards track encoding mechanism (2231) has had more deployment/interop problems than general 2047 header encoding. - Chris Frank Ellermann wrote on 5/1/07 21:15 +0200: >> If minimal MIME conformance requires to support message/partial >> and/or message/external-body add the missing steps. > > That was hogwash, message/partial is guaranteed to be 7bit, and > adding the missing steps to handle it in an "8to7" algorithm is > trivial. > > And a message/external-body (the lines defining it, encapsulated > header + phantom body) is also guaranteed to be US ASCII, that's > also trivial. > > IMO we should now decide that any attempt to allow UTF-8 in MIME > part headers or generally Content-* header fields is doomed. If > you (= EAI folks) want to try it anyway please say so, because > I don't like to waste more time with it. > > Frank > > > > _______________________________________________ > 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 Wed May 02 07:13:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjCla-0000sK-LM; Wed, 02 May 2007 07:13:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjCla-0000sF-Ai for ima@ietf.org; Wed, 02 May 2007 07:13:02 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjClY-0000Jz-M9 for ima@ietf.org; Wed, 02 May 2007 07:13:02 -0400 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 4638723b.153e1.5b8 for ima@ietf.org; Wed, 2 May 2007 12:12:59 +0100 (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 l42BCwRl027260 for ; Wed, 2 May 2007 12:12:59 +0100 (BST) To: IMA Subject: Re: [EAI] Re: MIME prohibition stupid vs. brilliant (CORRECTION) References: <69DEB4ACF63843407008496D@[192.168.1.119]> <4632E910.723@xyzzy.claranet.de> <4635FA85.7020104@alvestrand.no> <46378431.156D@xyzzy.claranet.de> <46378833.130D@xyzzy.claranet.de> Message-ID: Date: Wed, 02 May 2007 12:12:58 +0100 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: <46378833.130D@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) 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 On Tue, 01 May 2007 19:34:27 +0100, Frank Ellermann wrote: > Frank Ellermann wrote: > It gives us another problem, it's impossible to use message/partial > for fragments of a message/utf8. If somebody wishes to fragment a > message/utf8 they have to downgrade it first. Yes, I think that is correct. Message/partial is a can of worms and I can no obvious way in which it could be extended to work with EAI. I could happily live without it. > > At least it avoids the ugly case of an unexpected message/utf8 (after > reassembly) showing up in the inbox of a traditional user. We need > a section somewhere stating that fragmentation is by definition (in > 2046) impossible for a message/utf8. Agreed. It needs to be mentioned somewhere, probably in utf8headers and maybe in smtpext. -- 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 May 02 07:29:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjD14-0003Pc-BU; Wed, 02 May 2007 07:29:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjD13-0003PX-Pv for ima@ietf.org; Wed, 02 May 2007 07:29:01 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjD12-00039h-7P for ima@ietf.org; Wed, 02 May 2007 07:29:01 -0400 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 463875fb.d283.8a for ima@ietf.org; Wed, 2 May 2007 12:28:59 +0100 (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 l42BSwiO028271 for ; Wed, 2 May 2007 12:28:59 +0100 (BST) To: IMA Subject: Re: [EAI] Re: Strip 8th bit (CORRECTION) References: <0BE9565F3198DD14E350AB4A@[192.168.1.108]> <462E0B47.6564@xyzzy.claranet.de> <0589C738F42DFA3B1AE828DE@[192.168.1.119]> <4632FBAF.5966@xyzzy.claranet.de> <463791D9.4232@xyzzy.claranet.de> Message-ID: Date: Wed, 02 May 2007 12:28:58 +0100 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: <463791D9.4232@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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, 01 May 2007 20:15:37 +0100, Frank Ellermann wrote: > IMO we should now decide that any attempt to allow UTF-8 in MIME > part headers or generally Content-* header fields is doomed. If > you (= EAI folks) want to try it anyway please say so, because > I don't like to waste more time with it. Why should it be "doomed"? We know exactly how to downgrade all known Content-* headers, and the result of downgrading should be comprehensible to existing agents, assuming they understand RFC 2047 and RFC 2231 (and if they don't they will just display the stuff still encoded, or in the case of s ignore them, as presumably happens already). There is never any need to construct a Downgraded header, And we also know how to deal with such headers when they occur in MIME part headers - it is simply a matter of extending the code in current MTAs that already handles the 8BITMIME downgrading, so that it looks at and downgrades those headers before it looks and and encodes the bodies that follow them. -- 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 May 02 10:19:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjFgD-0003NW-DA; Wed, 02 May 2007 10:19:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjFg9-0003LW-Ai for ima@ietf.org; Wed, 02 May 2007 10:19:39 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjFg8-0001Zh-0W for ima@ietf.org; Wed, 02 May 2007 10:19:37 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2EE262596F7; Wed, 2 May 2007 16:19:35 +0200 (CEST) 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 21612-03; Wed, 2 May 2007 16:19:30 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0A8CA2596DC; Wed, 2 May 2007 16:19:30 +0200 (CEST) Message-ID: <46389DF1.9030009@alvestrand.no> Date: Wed, 02 May 2007 16:19:29 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] Re: MIME prohibition stupid vs. brilliant References: <69DEB4ACF63843407008496D@[192.168.1.119]> <4632E910.723@xyzzy.claranet.de> <4635FA85.7020104@alvestrand.no> <46378431.156D@xyzzy.claranet.de> In-Reply-To: <46378431.156D@xyzzy.claranet.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Frank Ellermann wrote: > Harald Alvestrand wrote: > > >>> Now I'm confused. It's no stupid prohibition. It's based on three >>> assumptions: (1) Messages consist of an ASCII header and a body. >>> (2) The body can be structured and/or encoded as specified in the >>> header of the message. (3) Eveybody knows how a message/rfc822 is >>> structured, and how it specifies the encoding of its body, because >>> the message/rfc822 structure is what MIME and RFC 2045 are about. >>> > > [quotes rearranged] > >> The content of a message/partial doesn't consist of an ASCII header >> and a body, so I lost you at (1). >> > > We're talking about different things. When I wrote "messages" I meant > a complete message like a news article or an SMTP mail object, not the > MIME type message/*. A message/partial is no complete mail, like an > image/jpeg or text/pdf is no complete mail: They can only occur in > the body of a complete mail or in the body of a complete MIME part. > And for a complete mail (or a complete MIME part) there's a header. > > This header can be empty in some special cases related to multipart/*, > but "empty" is no contradiction to ASCII. > OK, I was confused about your message because you had 1) and 2) talking about a "message", and 3) talking about "message/rfc822", and I thought you meant "message/*" in 1) and 2). But you have still lost me, because I don't understand how you draw a conclusion from your 3 bullets that say anything about the stupidity or not of the restrictions on "message/*". Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun May 06 05:10:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkclL-0003eM-3l; Sun, 06 May 2007 05:10:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkclI-0003eB-Q9 for ima@ietf.org; Sun, 06 May 2007 05:10:36 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HkclG-0003X3-5G for ima@ietf.org; Sun, 06 May 2007 05:10:36 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hkcl7-0008UX-6h for ima@ietf.org; Sun, 06 May 2007 11:10:25 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 May 2007 11:10:25 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 May 2007 11:10:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 06 May 2007 12:10:13 +0300 Lines: 78 Message-ID: <5dwszm5nd6.fsf@Hurtta06k.keh.iki.fi> References: <69DEB4ACF63843407008496D@[192.168.1.119]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Kari Hurtta Subject: [EAI] Not a good reason? (Re: Minutes from Prague (fwd)) 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 writes in gmane.ietf.ima: > > And the dicussion completely failed to consider the third possibility > > of using message/rfc822, downgraded as necessary before it is allowed > > to be seen in the non-UTF8SMTP universe (but presumably upgraded again > > for display by recipients so capable). > Yes, it failed to consider this possibility. Rather, there was nobody in > the room who had taken leave of his senses enough to seriously want to > advance such a suggestion. > > Your suggestion has NOT seen any support on the list. And for good reason. Current drafts supports that: ( draft-ietf-eai-utf8headers-05.txt ) 4.2. Changes on MIME headers <...> In all those header fields, Observe that such Content-Type and other header fields may be found both amongst the top-level fields of a message and also within multiparts; and also that a complete message conforming to this document may now appear as a message/rfc822 (in both cases, subject to downgrade when that is necessary) ie. "a complete message conforming to this document may now appear as a message/rfc822" That is exactly same what Charles Lindsey was suggesting. When working group was decided that there is no need labeling for UTF8SMTP messages, that quite clearly follow that UTF8SMTP messages does not need new label (ie. message/utf-8 type) when they are attached to another message. When whole message is not need labeling on UTF8SMTP case (ie no ESMTP paramater), there is no need also different kind labeling if message is attached to another message. That makes "message/rfc822" just mean "mail message". And consistent that "message/rfc822" is just that type what occurs inside of DATA on smtp. Actually "message/rfc822" is not mean to be only mail message, but superset of it (rfc 2046): It should be noted that, despite the use of the numbers "822", a "message/rfc822" entity isn't restricted to material in strict conformance to RFC822, nor are the semantics of "message/rfc822" objects restricted to the semantics defined in RFC822. More specifically, a "message/rfc822" message could well be a News article or a MIME message. If there is reason why "message/rfc822" can not be used to mean any mail message on UTF8SMTP universe, same problems are also on top level. For example if there is some problems for IMAP on UTF8SMTP universe, when UTF8SMTP message is attaches as "message/rfc822", same problems also aply to top level message. If someone is sending UTF8SMTP message and mail bounces, normal situation is that sender is UTF8SMTP capable and therefore original UTF8SMTP message can be returned to sender as "message/rfc822" without that any downgrading occurs. This should not be optimized for rare cases where sender can send UTF8SMTP messages but can not receive them for some reason. Logically from this also follows, that "text/rfc822-headers; charset=utf-8" is used when mail header section is returned on bounced message on UTF8SMTP universe. ('charset' parameter is used, because text/* types require it. ) But that is side issue. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed May 09 05:18:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HliJF-0004wy-7x; Wed, 09 May 2007 05:18:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HliJD-0004wr-R3 for ima@ietf.org; Wed, 09 May 2007 05:18:07 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HliJC-0007xO-Ej for ima@ietf.org; Wed, 09 May 2007 05:18:07 -0400 Received: (eyou send program); Wed, 09 May 2007 17:18:01 +0800 Message-ID: <378702281.05046@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.35) by 159.226.7.146 with SMTP; Wed, 09 May 2007 17:18:01 +0800 Message-ID: <0ece01c7921a$f17462d0$236ff1da@yaojk> From: "YAO Jiankang" To: , "Kari Hurtta" References: <69DEB4ACF63843407008496D@[192.168.1.119]> <378442658.17718@cnnic.cn> Subject: Re: [EAI] Not a good reason? (Re: Minutes from Prague (fwd)) Date: Wed, 9 May 2007 17:18:01 +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: 1.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: , Content-Type: multipart/mixed; boundary="===============1201064736==" Errors-To: ima-bounces@ietf.org --===============1201064736== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkthcmkgSHVydHRhIiA8aHVy dHRhK2dtYW5lQHNpaWxvLmZtaS5maT4NClRvOiA8aW1hQGlldGYub3JnPg0KQ2M6ICJLYXJpIEh1 cnR0YSIgPGh1cnR0YStnbWFuZUBzaWlsby5mbWkuZmk+DQpTZW50OiBTdW5kYXksIE1heSAwNiwg MjAwNyA1OjEwIFBNDQpTdWJqZWN0OiBbRUFJXSBOb3QgYSBnb29kIHJlYXNvbj8gKFJlOiBNaW51 dGVzIGZyb20gUHJhZ3VlIChmd2QpKQ0KDQoNCj4gSGFyYWxkIFR2ZWl0IEFsdmVzdHJhbmQgPGhh cmFsZEBhbHZlc3RyYW5kLm5vPiB3cml0ZXMgaW4gZ21hbmUuaWV0Zi5pbWE6DQo+IA0KPj4gPiBB bmQgdGhlIGRpY3Vzc2lvbiBjb21wbGV0ZWx5IGZhaWxlZCB0byBjb25zaWRlciB0aGUgdGhpcmQg cG9zc2liaWxpdHkNCj4+ID4gb2YgdXNpbmcgbWVzc2FnZS9yZmM4MjIsIGRvd25ncmFkZWQgYXMg bmVjZXNzYXJ5IGJlZm9yZSBpdCBpcyBhbGxvd2VkDQo+PiA+IHRvIGJlIHNlZW4gaW4gdGhlIG5v bi1VVEY4U01UUCB1bml2ZXJzZSAoYnV0IHByZXN1bWFibHkgdXBncmFkZWQgYWdhaW4NCj4+ID4g Zm9yIGRpc3BsYXkgYnkgcmVjaXBpZW50cyBzbyBjYXBhYmxlKS4NCj4+IFllcywgaXQgZmFpbGVk IHRvIGNvbnNpZGVyIHRoaXMgcG9zc2liaWxpdHkuIFJhdGhlciwgdGhlcmUgd2FzIG5vYm9keSBp bg0KPj4gdGhlIHJvb20gd2hvIGhhZCB0YWtlbiBsZWF2ZSBvZiBoaXMgc2Vuc2VzIGVub3VnaCB0 byBzZXJpb3VzbHkgd2FudCB0bw0KPj4gYWR2YW5jZSBzdWNoIGEgc3VnZ2VzdGlvbi4NCj4+IA0K Pj4gWW91ciBzdWdnZXN0aW9uIGhhcyBOT1Qgc2VlbiBhbnkgc3VwcG9ydCBvbiB0aGUgbGlzdC4g QW5kIGZvciBnb29kIHJlYXNvbi4NCj4gDQo+IEN1cnJlbnQgZHJhZnRzIHN1cHBvcnRzIHRoYXQ6 ICAgKCBkcmFmdC1pZXRmLWVhaS11dGY4aGVhZGVycy0wNS50eHQgKQ0KDQoNCg0KSSBoYXZlIGRp c2N1c3NlZCB3aXRoIHRoZSB1dGY4aGVhZGVycyBlZGl0b3JzIHdobyBjb25maXJtZWQgdG8gbWUg dGhhdCBoZSBmb3Jnb3R0IHRvIHVwZGF0ZSB0aGlzIHBvaW50IHRvIHJlZmxlY3QgdGhlIGxhc3Qg RUFJIG1lZXRpbmcgZGlzY3Vzc2lvbiByZXN1bHQgaW4gUHJhZ3VlLg0KDQp0aGUgY29ycmVjdCBz dGF0bWVudCBpcyANCg0KImEgY29tcGxldGUgbWVzc2FnZQ0KICAgY29uZm9ybWluZyB0byB0aGlz IGRvY3VtZW50IG1heSBub3cgYXBwZWFyIGFzIGEgbWVzc2FnZS91dGY4c210cCAoaW4NCiAgIGJv dGggY2FzZXMsIHN1YmplY3QgdG8gZG93bmdyYWRlIHdoZW4gdGhhdCBpcyBuZWNlc3NhcnkpLiAi DQoNCnRoZSBlZGl0b3Igd2lsbCB1cGRhdGUgdGhpcyBpbiBuZXh0IHZlcnNpb24uDQoNCg0KWUFP IEppYW5rYW5nDQoNCg0KDQoNCj4gDQo+ICAgNC4yLiAgQ2hhbmdlcyBvbiBNSU1FIGhlYWRlcnMN Cj4gDQo+ICAgPC4uLj4NCj4gDQo+ICAgSW4gYWxsIHRob3NlIGhlYWRlciBmaWVsZHMsIE9ic2Vy dmUgdGhhdCBzdWNoIENvbnRlbnQtVHlwZSBhbmQgb3RoZXINCj4gICBoZWFkZXIgZmllbGRzIG1h eSBiZSBmb3VuZCBib3RoIGFtb25nc3QgdGhlIHRvcC1sZXZlbCBmaWVsZHMgb2YgYQ0KPiAgIG1l c3NhZ2UgYW5kIGFsc28gd2l0aGluIG11bHRpcGFydHM7IGFuZCBhbHNvIHRoYXQgYSBjb21wbGV0 ZSBtZXNzYWdlDQo+ICAgY29uZm9ybWluZyB0byB0aGlzIGRvY3VtZW50IG1heSBub3cgYXBwZWFy IGFzIGEgbWVzc2FnZS9yZmM4MjIgKGluDQo+ICAgYm90aCBjYXNlcywgc3ViamVjdCB0byBkb3du Z3JhZGUgd2hlbiB0aGF0IGlzIG5lY2Vzc2FyeSkNCj4gDQo+IGllLiAiYSBjb21wbGV0ZSBtZXNz YWdlIGNvbmZvcm1pbmcgdG8gdGhpcyBkb2N1bWVudCBtYXkgbm93IGFwcGVhciBhcyANCj4gYSBt ZXNzYWdlL3JmYzgyMiINCj4gDQo+IFRoYXQgaXMgZXhhY3RseSBzYW1lIHdoYXQgQ2hhcmxlcyBM aW5kc2V5IHdhcyBzdWdnZXN0aW5nLiANCj4gDQo+IFdoZW4gd29ya2luZyBncm91cCB3YXMgZGVj aWRlZCB0aGF0IHRoZXJlIGlzIG5vIG5lZWQgbGFiZWxpbmcNCj4gZm9yIFVURjhTTVRQIG1lc3Nh Z2VzLCB0aGF0IHF1aXRlIGNsZWFybHkgZm9sbG93IHRoYXQgVVRGOFNNVFANCj4gbWVzc2FnZXMg ZG9lcyBub3QgbmVlZCBuZXcgbGFiZWwgKGllLiBtZXNzYWdlL3V0Zi04IHR5cGUpIHdoZW4NCj4g dGhleSBhcmUgYXR0YWNoZWQgdG8gYW5vdGhlciBtZXNzYWdlLg0KPiANCj4gV2hlbiB3aG9sZSBt ZXNzYWdlIGlzIG5vdCBuZWVkIGxhYmVsaW5nIG9uIFVURjhTTVRQIGNhc2UgKGllIG5vIEVTTVRQ DQo+IHBhcmFtYXRlciksIHRoZXJlIGlzIG5vIG5lZWQgYWxzbyBkaWZmZXJlbnQga2luZCBsYWJl bGluZyBpZg0KPiBtZXNzYWdlIGlzIGF0dGFjaGVkIHRvIGFub3RoZXIgbWVzc2FnZS4NCj4gDQo+ IFRoYXQgbWFrZXMgIm1lc3NhZ2UvcmZjODIyIiBqdXN0IG1lYW4gIm1haWwgbWVzc2FnZSIuIEFu ZCBjb25zaXN0ZW50DQo+IHRoYXQgIm1lc3NhZ2UvcmZjODIyIiBpcyBqdXN0IHRoYXQgdHlwZSB3 aGF0IG9jY3VycyBpbnNpZGUgb2YgREFUQQ0KPiBvbiBzbXRwLg0KPiANCj4gQWN0dWFsbHkgIm1l c3NhZ2UvcmZjODIyIiBpcyBub3QgbWVhbiB0byBiZSBvbmx5IG1haWwgbWVzc2FnZSwNCj4gYnV0 IHN1cGVyc2V0IG9mIGl0IChyZmMgMjA0Nik6DQo+IA0KPiAgIEl0IHNob3VsZCBiZSBub3RlZCB0 aGF0LCBkZXNwaXRlIHRoZSB1c2Ugb2YgdGhlIG51bWJlcnMgIjgyMiIsIGENCj4gICAibWVzc2Fn ZS9yZmM4MjIiIGVudGl0eSBpc24ndCByZXN0cmljdGVkIHRvIG1hdGVyaWFsIGluIHN0cmljdA0K PiAgIGNvbmZvcm1hbmNlIHRvIFJGQzgyMiwgbm9yIGFyZSB0aGUgc2VtYW50aWNzIG9mICJtZXNz YWdlL3JmYzgyMiINCj4gICBvYmplY3RzIHJlc3RyaWN0ZWQgdG8gdGhlIHNlbWFudGljcyBkZWZp bmVkIGluIFJGQzgyMi4gTW9yZQ0KPiAgIHNwZWNpZmljYWxseSwgYSAibWVzc2FnZS9yZmM4MjIi IG1lc3NhZ2UgY291bGQgd2VsbCBiZSBhIE5ld3MgYXJ0aWNsZQ0KPiAgIG9yIGEgTUlNRSBtZXNz YWdlLg0KPiANCj4gDQo+IElmIHRoZXJlIGlzIHJlYXNvbiB3aHkgIm1lc3NhZ2UvcmZjODIyIiBj YW4gbm90IGJlIHVzZWQgdG8NCj4gbWVhbiBhbnkgbWFpbCBtZXNzYWdlIG9uIFVURjhTTVRQIHVu aXZlcnNlLCBzYW1lIHByb2JsZW1zIGFyZQ0KPiBhbHNvIG9uIHRvcCBsZXZlbC4gICANCj4gDQo+ IEZvciBleGFtcGxlIGlmIHRoZXJlIGlzIHNvbWUgcHJvYmxlbXMgZm9yIElNQVAgb24gVVRGOFNN VFAgdW5pdmVyc2UsDQo+IHdoZW4gVVRGOFNNVFAgbWVzc2FnZSBpcyBhdHRhY2hlcyBhcyAibWVz c2FnZS9yZmM4MjIiLCBzYW1lIHByb2JsZW1zDQo+IGFsc28gYXBseSB0byB0b3AgbGV2ZWwgbWVz c2FnZS4gDQo+IA0KPiANCj4gSWYgc29tZW9uZSBpcyBzZW5kaW5nIFVURjhTTVRQIG1lc3NhZ2Ug YW5kIG1haWwgYm91bmNlcywgbm9ybWFsIA0KPiBzaXR1YXRpb24gaXMgdGhhdCBzZW5kZXIgaXMg VVRGOFNNVFAgY2FwYWJsZSBhbmQgdGhlcmVmb3JlIG9yaWdpbmFsIA0KPiBVVEY4U01UUCBtZXNz YWdlIGNhbiBiZSByZXR1cm5lZCB0byBzZW5kZXIgYXMgIm1lc3NhZ2UvcmZjODIyIiB3aXRob3V0 IA0KPiB0aGF0IGFueSBkb3duZ3JhZGluZyBvY2N1cnMuICBUaGlzIHNob3VsZCBub3QgYmUgb3B0 aW1pemVkIGZvcg0KPiByYXJlIGNhc2VzIHdoZXJlIHNlbmRlciBjYW4gc2VuZCAgVVRGOFNNVFAg bWVzc2FnZXMgYnV0IGNhbiBub3QgcmVjZWl2ZQ0KPiB0aGVtIGZvciBzb21lIHJlYXNvbi4NCj4g DQo+IA0KPiBMb2dpY2FsbHkgZnJvbSB0aGlzIGFsc28gZm9sbG93cywgdGhhdCAidGV4dC9yZmM4 MjItaGVhZGVyczsgY2hhcnNldD11dGYtOCIgDQo+IGlzIHVzZWQgd2hlbiBtYWlsIGhlYWRlciBz ZWN0aW9uIGlzIHJldHVybmVkIG9uIGJvdW5jZWQgbWVzc2FnZSBvbg0KPiBVVEY4U01UUCB1bml2 ZXJzZS4gKCdjaGFyc2V0JyBwYXJhbWV0ZXIgaXMgdXNlZCwgYmVjYXVzZSB0ZXh0LyogdHlwZXMN Cj4gcmVxdWlyZSBpdC4gKSAgQnV0IHRoYXQgaXMgc2lkZSBpc3N1ZS4gIA0KPiANCj4gDQo+IC8g S2FyaSBIdXJ0dGENCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1hDQo+ --===============1201064736== 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 --===============1201064736==-- From ima-bounces@ietf.org Wed May 09 05:26:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HliRG-0001zN-PB; Wed, 09 May 2007 05:26:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HliRE-0001zI-V6 for ima@ietf.org; Wed, 09 May 2007 05:26:24 -0400 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HliRE-0001k7-4f for ima@ietf.org; Wed, 09 May 2007 05:26:24 -0400 Received: from aabbeell (pc093.twnic.net.tw [211.72.211.93]) (authenticated bits=0) by twnic.net.tw (8.13.8/8.13.8) with ESMTP id l499QKXi007642; Wed, 9 May 2007 17:26:20 +0800 Message-ID: <01d101c7921c$671816c0$c7d348d3@aabbeell> From: "abel" To: "YAO Jiankang" , , "Kari Hurtta" References: <69DEB4ACF63843407008496D@[192.168.1.119]> <378442658.17718@cnnic.cn> <378702281.05046@cnnic.cn> Subject: Re: [EAI] Not a good reason? (Re: Minutes from Prague (fwd)) Date: Wed, 9 May 2007 17:28:27 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 Yes, I am sorry about that I forgot to change that to 'message/utf8smtp'. Sorry to Kari. > I have discussed with the utf8headers editors who confirmed to me that he forgott to update this point to reflect the last EAI meeting discussion result in Prague. > > the correct statment is > > "a complete message > conforming to this document may now appear as a message/utf8smtp (in > both cases, subject to downgrade when that is necessary). " > > the editor will update this in next version. > > > YAO Jiankang > > > > > > > > 4.2. Changes on MIME headers > > > > <...> > > > > In all those header fields, Observe that such Content-Type and other > > header fields may be found both amongst the top-level fields of a > > message and also within multiparts; and also that a complete message > > conforming to this document may now appear as a message/rfc822 (in > > both cases, subject to downgrade when that is necessary) > > > > ie. "a complete message conforming to this document may now appear as > > a message/rfc822" > > > > That is exactly same what Charles Lindsey was suggesting. > > > > When working group was decided that there is no need labeling > > for UTF8SMTP messages, that quite clearly follow that UTF8SMTP > > messages does not need new label (ie. message/utf-8 type) when > > they are attached to another message. > > > > When whole message is not need labeling on UTF8SMTP case (ie no ESMTP > > paramater), there is no need also different kind labeling if > > message is attached to another message. > > > > That makes "message/rfc822" just mean "mail message". And consistent > > that "message/rfc822" is just that type what occurs inside of DATA > > on smtp. > > > > Actually "message/rfc822" is not mean to be only mail message, > > but superset of it (rfc 2046): > > > > It should be noted that, despite the use of the numbers "822", a > > "message/rfc822" entity isn't restricted to material in strict > > conformance to RFC822, nor are the semantics of "message/rfc822" > > objects restricted to the semantics defined in RFC822. More > > specifically, a "message/rfc822" message could well be a News article > > or a MIME message. > > > > > > If there is reason why "message/rfc822" can not be used to > > mean any mail message on UTF8SMTP universe, same problems are > > also on top level. > > > > For example if there is some problems for IMAP on UTF8SMTP universe, > > when UTF8SMTP message is attaches as "message/rfc822", same problems > > also aply to top level message. > > > > > > If someone is sending UTF8SMTP message and mail bounces, normal > > situation is that sender is UTF8SMTP capable and therefore original > > UTF8SMTP message can be returned to sender as "message/rfc822" without > > that any downgrading occurs. This should not be optimized for > > rare cases where sender can send UTF8SMTP messages but can not receive > > them for some reason. > > > > > > Logically from this also follows, that "text/rfc822-headers; charset=utf-8" > > is used when mail header section is returned on bounced message on > > UTF8SMTP universe. ('charset' parameter is used, because text/* types > > require it. ) But that is side issue. > > > > > > / 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 May 11 11:59:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmXWl-0006XR-Jn; Fri, 11 May 2007 11:59:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmXWk-0006XL-Al for ima@ietf.org; Fri, 11 May 2007 11:59:30 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmXWg-00086v-LA for ima@ietf.org; Fri, 11 May 2007 11:59:30 -0400 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 464492dd.3664.c5 for ima@ietf.org; Fri, 11 May 2007 16:59:25 +0100 (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 l4BFxOsH001752 for ; Fri, 11 May 2007 16:59:25 +0100 (BST) Subject: Re: [EAI] Not a good reason? (Re: Minutes from Prague (fwd)) References: <69DEB4ACF63843407008496D@[192.168.1.119]> <378442658.17718@cnnic.cn> <0ece01c7921a$f17462d0$236ff1da@yaojk> Message-ID: To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Fri, 11 May 2007 16:59:24 +0100 In-Reply-To: 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 Wed, 09 May 2007 10:18:01 +0100, YAO Jiankang wrote: > I have discussed with the utf8headers editors who confirmed to me that > he forgott to update this point to reflect the last EAI meeting > discussion result in Prague. > > the correct statment is > > "a complete message > conforming to this document may now appear as a message/utf8smtp (in > both cases, subject to downgrade when that is necessary). " > > the editor will update this in next version. No, you can't say that until there exists a correct definition of message/utf8smtp to refer to. And since it is the case that any message/utf8smtp that is invented will not interoperate with the existing network, because many existig (and compliant) MTAs will fail to downgrade it when sending it to non-8BITMIME agents, I do not see how any such beast could be defined. The only ways of sending an encapsulated UTF8SMTP message that will actually interoperate with the existing network are: 1. To send it as an application/utf8-message, or 2. To downgrade it (if needed), and then send it as a message/rfc822 In both those cases, a further downgrade to Non-8BITMIME will work correctly. -- 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 May 11 18:28:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmdbA-0000yD-5L; Fri, 11 May 2007 18:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmdb9-0000y4-GP for ima@ietf.org; Fri, 11 May 2007 18:28:27 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmdb3-0002YP-AC for ima@ietf.org; Fri, 11 May 2007 18:28:27 -0400 Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l4BMSKD4026026 for ; Fri, 11 May 2007 22:28:20 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 <0JHW00G01EALY200@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Fri, 11 May 2007 16:28:20 -0600 (MDT) 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 <0JHW001J5EF6B330@mail-amer.sun.com>; Fri, 11 May 2007 16:28:20 -0600 (MDT) Date: Fri, 11 May 2007 15:28:21 -0700 From: Chris Newman Subject: Re: [EAI] Not a good reason? (Re: Minutes from Prague (fwd)) In-reply-to: To: Charles Lindsey , IMA Message-id: <2AE4ADBFDF027DA3E2392E11@[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: <69DEB4ACF63843407008496D@[192.168.1.119]> <378442658.17718@cnnic.cn> <0ece01c7921a$f17462d0$236ff1da@yaojk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 5/11/07 16:59 +0100: > And since it is the case that any message/utf8smtp that is invented will > not interoperate with the existing network, because many existig (and > compliant) MTAs will fail to downgrade it when sending it to non-8BITMIME > agents, I do not see how any such beast could be defined. I question the claim that an MTA which passes material outside the US-ASCII octet range to a non-8BITMIME server is standards complaint. ----excerpt from RFC 1652: If a server SMTP does not support the 8-bit MIME transport extension (either by not responding with code 250 to the EHLO command, or by not including the EHLO keyword value 8BITMIME in its response), then the client SMTP must not, under any circumstances, attempt to transfer a content which contains characters outside the US-ASCII octet range (hex 00-7F). ----excerpt from RFC 1652 - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat May 12 04:42:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmnB2-0004fd-Ge; Sat, 12 May 2007 04:42:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmnB1-0004fY-N7 for ima@ietf.org; Sat, 12 May 2007 04:42:07 -0400 Received: from ppsw-3.csi.cam.ac.uk ([131.111.8.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmnAx-0003mX-Dz for ima@ietf.org; Sat, 12 May 2007 04:42:07 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:46509) by ppsw-3.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.153]:25) with esmtpa (EXTERNAL:fanf2) id 1HmnAt-0003kS-AL (Exim 4.63) (return-path ); Sat, 12 May 2007 09:41:59 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HmnAt-0001YG-5m (Exim 4.54) (return-path ); Sat, 12 May 2007 09:41:59 +0100 Date: Sat, 12 May 2007 09:41:59 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Harald Tveit Alvestrand Subject: Re: [EAI] Re: Fwd: Re: Minutes from Prague In-Reply-To: <0589C738F42DFA3B1AE828DE@[192.168.1.119]> Message-ID: References: <0BE9565F3198DD14E350AB4A@[192.168.1.108]> <462E0B47.6564@xyzzy.claranet.de> <0589C738F42DFA3B1AE828DE@[192.168.1.119]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Frank Ellermann , 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, 26 Apr 2007, Harald Tveit Alvestrand wrote: > I believe that both PP and Exim defaulted to "strip the 8th bit" for quite a > while. I'm not sure what current mailers default to. Sorry for the delayed reply. AFAIK Exim has always been 8-bit clean. Its oddity in this area is that it can be configured to offer 8BITMIME but it does not implement 8bit -> 7bit downgrades. Tony. -- f.a.n.finch http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE: EAST BACKING NORTHWEST 4 OR 5, OCCASIONALLY 6. MODERATE OR ROUGH. SHOWERS. GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat May 12 06:38:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmozm-0002Ks-OC; Sat, 12 May 2007 06:38:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmozl-0002Kn-Nr for ima@ietf.org; Sat, 12 May 2007 06:38:37 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmozk-0005z3-F3 for ima@ietf.org; Sat, 12 May 2007 06:38:37 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Hmozj-000FEq-Gm; Sat, 12 May 2007 06:38:35 -0400 Date: Sat, 12 May 2007 06:38:34 -0400 From: John C Klensin To: Tony Finch Subject: Re: [EAI] Re: Fwd: Re: Minutes from Prague Message-ID: <8A7A3832F1003C8E46FB29E5@p3.JCK.COM> In-Reply-To: References: <0BE9565F3198DD14E350AB4A@[192.168.1.108]> <462E0B47.6564@xyzzy.claranet.de> <0589C738F42DFA3B1AE828DE@[192.168.1.119]> X-Mailer: Mulberry/4.0.8 (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: 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, 12 May, 2007 09:41 +0100 Tony Finch wrote: > On Thu, 26 Apr 2007, Harald Tveit Alvestrand wrote: > >> I believe that both PP and Exim defaulted to "strip the 8th >> bit" for quite a while. I'm not sure what current mailers >> default to. > > Sorry for the delayed reply. AFAIK Exim has always been 8-bit > clean. Its oddity in this area is that it can be configured to > offer 8BITMIME but it does not implement 8bit -> 7bit > downgrades. Which, of course, is completely permitted by the standard unless it sends 8-bit to hosts that do not advertise 8BITMIME. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon May 14 05:37:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnWzB-0007sq-9e; Mon, 14 May 2007 05:36:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnWzA-0007sW-0p for ima@ietf.org; Mon, 14 May 2007 05:36:56 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnWz7-0003In-5t for ima@ietf.org; Mon, 14 May 2007 05:36:55 -0400 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 46482db3.d374.125 for ima@ietf.org; Mon, 14 May 2007 10:36:51 +0100 (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 l4E9alZN015586 for ; Mon, 14 May 2007 10:36:48 +0100 (BST) To: IMA Subject: Re: [EAI] Not a good reason? (Re: Minutes from Prague (fwd)) References: <69DEB4ACF63843407008496D@[192.168.1.119]> <378442658.17718@cnnic.cn> <0ece01c7921a$f17462d0$236ff1da@yaojk> <2AE4ADBFDF027DA3E2392E11@[10.1.110.5]> Message-ID: Date: Mon, 14 May 2007 10:36:46 +0100 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: <2AE4ADBFDF027DA3E2392E11@[10.1.110.5]> 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 Fri, 11 May 2007 23:28:21 +0100, Chris Newman wrote: > Charles Lindsey wrote on 5/11/07 16:59 +0100: >> And since it is the case that any message/utf8smtp that is invented will >> not interoperate with the existing network, because many existig (and >> compliant) MTAs will fail to downgrade it when sending it to >> non-8BITMIME >> agents, I do not see how any such beast could be defined. > > I question the claim that an MTA which passes material outside the > US-ASCII octet range to a non-8BITMIME server is standards complaint. Indeed. Correct behaviour for an MTA that finds it has 8bit data that it cannot downgrade to send to an non-8BITMIME system is to bounce the message back to the sender. However, it is known that some MTAs do, in fact, attempt to send the 8bit stuff as-is in that situation, and some truncate the 8th bit, which is worse IMO. But, given that the 'correct' behaviour is to bounce, in this case this means bouncing a DSN back to the Reporting MTA, which is not really in anybody's interest. Therefore, it would be quite wrong for us to define the EAI DSN extension in such a way that bouncing of the DNS was inevitable in such situations - especially as there are two other ways in which it could be defined (using application/message-utf8smtp or message/rfc822) which entirely avoid the problem. -- 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 May 18 01:40:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HovCQ-00047M-6t; Fri, 18 May 2007 01:40:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HovCP-00047E-4P for ima@ietf.org; Fri, 18 May 2007 01:40:21 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HovCN-0000M2-MR for ima@ietf.org; Fri, 18 May 2007 01:40:21 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C325C2596C8; Fri, 18 May 2007 07:40:18 +0200 (CEST) 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 11945-04; Fri, 18 May 2007 07:40:13 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 422562596CB; Fri, 18 May 2007 07:40:13 +0200 (CEST) Message-ID: <464D3C3D.1070707@alvestrand.no> Date: Fri, 18 May 2007 07:40:13 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] Not a good reason? (Re: Minutes from Prague (fwd)) References: <69DEB4ACF63843407008496D@[192.168.1.119]> <378442658.17718@cnnic.cn> <0ece01c7921a$f17462d0$236ff1da@yaojk> <2AE4ADBFDF027DA3E2392E11@[10.1.110.5]> 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: 52e1467c2184c31006318542db5614d5 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 Fri, 11 May 2007 23:28:21 +0100, Chris Newman > wrote: > >> Charles Lindsey wrote on 5/11/07 16:59 +0100: >>> And since it is the case that any message/utf8smtp that is invented >>> will >>> not interoperate with the existing network, because many existig (and >>> compliant) MTAs will fail to downgrade it when sending it to >>> non-8BITMIME >>> agents, I do not see how any such beast could be defined. >> >> I question the claim that an MTA which passes material outside the >> US-ASCII octet range to a non-8BITMIME server is standards complaint. > > Indeed. Correct behaviour for an MTA that finds it has 8bit data that > it cannot downgrade to send to an non-8BITMIME system is to bounce the > message back to the sender. However, it is known that some MTAs do, in > fact, attempt to send the 8bit stuff as-is in that situation, and some > truncate the 8th bit, which is worse IMO. > > But, given that the 'correct' behaviour is to bounce, in this case > this means bouncing a DSN back to the Reporting MTA, which is not > really in anybody's interest. Therefore, it would be quite wrong for > us to define the EAI DSN extension in such a way that bouncing of the > DNS was inevitable in such situations - especially as there are two > other ways in which it could be defined (using > application/message-utf8smtp or message/rfc822) which entirely avoid > the problem. The correct behaviour when sending a DSN is to use a MAIL FROM of <>. The correct behaviour when bouncing a message with MAIL FROM <> is to discard the message. Next question? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri May 18 05:27:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoykQ-0008D1-MC; Fri, 18 May 2007 05:27:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoykP-0008Cw-FC for ima@ietf.org; Fri, 18 May 2007 05:27:41 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoykN-0005hR-It for ima@ietf.org; Fri, 18 May 2007 05:27:41 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HoykB-0002Sn-Kz for ima@ietf.org; Fri, 18 May 2007 11:27:27 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 May 2007 11:27:27 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 May 2007 11:27:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Kari Hurtta" Date: 18 May 2007 12:27:09 +0300 Lines: 249 Message-ID: <5dbqgiv5w2.fsf_-_@Hurtta06k.keh.iki.fi> References: <69DEB4ACF63843407008496D@[192.168.1.119]> <378442658.17718@cnnic.cn> <0ece01c7921a$f17462d0$236ff1da@yaojk> <2AE4ADBFDF027DA3E2392E11@[10.1.110.5]> <464D3C3D.1070707@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: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: Charles Lindsey , Kari Hurtta Subject: [EAI] UTF8SMTP / 8BITMIME / ASCII -universe amd message/utf8smtp (Re: Not a good reason? (Re: Minutes from Prague (fwd))) 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 Fri, 11 May 2007 23:28:21 +0100, Chris Newman > > wrote: > > > >> Charles Lindsey wrote on 5/11/07 16:59 +0100: > >>> And since it is the case that any message/utf8smtp that is > >>> invented will > >>> not interoperate with the existing network, because many existig (and > >>> compliant) MTAs will fail to downgrade it when sending it to > >>> non-8BITMIME > >>> agents, I do not see how any such beast could be defined. > >> > >> I question the claim that an MTA which passes material outside the > >> US-ASCII octet range to a non-8BITMIME server is standards > >> complaint. > > > > Indeed. Correct behaviour for an MTA that finds it has 8bit data > > that it cannot downgrade to send to an non-8BITMIME system is to > > bounce the message back to the sender. However, it is known that > > some MTAs do, in fact, attempt to send the 8bit stuff as-is in that > > situation, and some truncate the 8th bit, which is worse IMO. > > > > But, given that the 'correct' behaviour is to bounce, in this case > > this means bouncing a DSN back to the Reporting MTA, which is not > > really in anybody's interest. Therefore, it would be quite wrong for > > us to define the EAI DSN extension in such a way that bouncing of > > the DNS was inevitable in such situations - especially as there are > > two other ways in which it could be defined (using > > application/message-utf8smtp or message/rfc822) which entirely > > avoid the problem. > The correct behaviour when sending a DSN is to use a MAIL FROM of <>. > > The correct behaviour when bouncing a message with MAIL FROM <> is to > discard the message. > > Next question? Yes. And therefore DSN on lost, if it reaches 8BITMIME to ASCII gateway. Of course it is unlikely that it reaches 8BITMIME to ASCII gateway when original message, which caused DSN, was UTF8SMTP message. To avoid these border cases, UTF8SMTP to 8BITMIME gateway is better downgrade this DSN. Specially many MTAs exists which do not support 8BITMIME. They can configured announce 8BITMIME, but then they just-send-8bit. More about that on later on this message. Therefore that border case where next host do not announce 8BITMIME is quite possible and common. Equal important case is when UTF8SMTP message is attached to some message and message is sent to ASCII user. Possible downgrade alternatives for UTF8SMTP to 8BITMIME gateway is discussed later on this message. Frank Ellerman is saying that that downgrade must be done on 8BITMIME to ASCII gateway. But there is problem: When mail is leaved UTF8SMTP universe, there is no any guarantee that next 8BITMIME to ASCII gateway knows anything about these message/utf8smtp and other new message/* types. Therefore correct place handle this is on UTF8SMTP to 8BITMIME gateway. +---------------------------------------------------------+ | ASCII universe | | | | +--------------------------------------------------+ | | | 8BITMIME universe | | | | | | | | +-------------------------------------------+ | | | | | UTF8SMTP universe | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-------------------------------------------+ | | | | | | | +--------------------------------------------------+ | | | +---------------------------------------------------------+ Seems that currently that (subset of) WG wants that message/utf8smtp is sent as is from UTF8SMTP universe to 8BITMIME universe; that is with content-transfer-encoding 8bit. That itself does not violate RFC 2045 "EXPRESSLY FORBIDDEN" rule. However if that is specified that way, it is saying: * 8BITMIME universe to ASCII universe gateways must violate standards, otherwise that does not work. I do not think that this is wise message to be sent. Of course it is possible that actually all implementations violate standards, but that is hard to prove. I oppose that attached 8BITMIME messages are sent as message/utf8smtp to 8BITMIME universe. UTF8SMTP universe is that area which knows these new types. UTF8SMTP extension for SMTP is defined so that experient can be compatible with existing software. When message/utf8smtp type with 8-bit content-transfer-encoding is sent from 8BITMIME universe to ASCII universe, there is following possibilities for gateway: (1) "bounce" message instead (or discard on case of DSN) -- that is case where can be said that this experiment does not work. (2) convert 8-bit to quoted-printable or base64 -- on that case it is violating standards (A2) (3) send 8-bit as is -- on that case it is violating standards (A3) (4) downgrade message/utf8smtp. This is corresponding that RFC 2045 says that encoding must be done at the innermost level. However most of 8BITMIME to ASCII universe gateways knows nothing about message/utf8smtp. If it knows about message/utf8smtp, it is from UTF8SMTP to ASCII universe gateway instead. (5) strip 8-bit to 7-bit -- on that case it is violating standards (A5) A2: RFC 2045 "EXPRESSLY FORBIDDEN" rule: 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. A3: RFC 1652 "under any circumstances" rule: If a server SMTP does not support the 8-bit MIME transport extension (either by not responding with code 250 to the EHLO command, or by not including the EHLO keyword value 8BITMIME in its response), then the client SMTP must not, under any circumstances, attempt to transfer a content which contains characters outside the US-ASCII octet range (hex 00-7F). A5: RFC 1652 "preserve data" rule: Once a server SMTP supporting the 8bit-MIMEtransport service extension accepts a content body containing octets with the high- order (8th) bit set, the server SMTP must deliver or relay the content in such a way as to preserve all bits in each octet. There is several possible alternatives which UTF8SMTP to 8BITMIME gatewaty may use when downgrading message which includes message/utf8smtp mime type as on subpart. (1) Type message/utf8smtp can be replaced with message/rfc822 and content downgraded same way than top level UTF8SMTP message. (2a) Type message/utf8smtp can be replaced with application/message-utf8smtp and content is keep unaltered. (2b) Type message/utf8smtp can be replaced with applicate/message; type=" message/utf8smtp" and content is keep unaltered. (3) Type message/utf8smtp can be replaced with multipart/utf8-encapsulated and content is generated as on draft-hurtta-eai-encapsulation have specified (chapter "5. Encapsulation"). (4) Type message/utf8smtp can be replaced with multipart/alternative and content is generated as following: (4.1) First body part is type message/rfc822 and content of that body part is downgraded from original message/utf8smtp same way than top level UTF8SMTP message. (4.1) Second body part is type application/message-utf8smtp and content is form original message/utf8smtp unaltered. This alternative duplicates space usage, but is quite easy to handle for exiting MUAs. On past discussions following MTAs are at least found which do not support 8BITMIME (but can be configured to announce 8BITMIME): Communigate Pro: http://www.stalker.com/CommuniGatePro/SMTP.html Advertise 8BITMIME If your Server does not report the 8BITMIME capability, some mailers and servers will MIME-encode all non-ASCII messages that they send to your Server . This server-side encoding can cause troubles for many old mail clients. To avoid these troubles, your Server should report the 8BITMIME capability. Note:The CommuniGate Pro SMTP module never converts non-ASCII messages into the MIME form itself, and (according to RFC1652) it should not advertise the 8BITMIME capability. But the modern Internet is completely 8-bit transparent and clean, so it is safe to enable the Advertise 8BITMIME option, preventing other servers from doing unneeded 8bit-to-MIME message conversion. Exim: http://www.exim.org/exim-html-current/doc/html/spec_html/ch14.html#SECTalomo accept_8bitmime Use: main Type: boolean Default: false This option causes Exim to send 8BITMIME in its response to an SMTP EHLO command, and to accept the BODY= parameter on MAIL commands. However, though Exim is 8-bit clean, it is not a protocol converter, and it takes no steps to do anything special with messages received by this route. Consequently, this option is turned off by default. Qmail: http://cr.yp.to/smtp/8bitmime.html http://en.wikipedia.org/wiki/8BITMIME lists also following MTAs which do not announce 8BITMIME: * Microsoft Exchange Internet Mail Service (through version 5.5) * Netscape Messaging Server 4.15 / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri May 18 09:09:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp2D8-0002kK-8s; Fri, 18 May 2007 09:09:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp2D6-0002iz-HI for ima@ietf.org; Fri, 18 May 2007 09:09:32 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp2D4-0002gR-Up for ima@ietf.org; Fri, 18 May 2007 09:09:32 -0400 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 464da589.451f.1a for ima@ietf.org; Fri, 18 May 2007 14:09:29 +0100 (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 l4ID9Sva014065 for ; Fri, 18 May 2007 14:09:29 +0100 (BST) To: IMA Subject: Re: [EAI] Not a good reason? (Re: Minutes from Prague (fwd)) References: <69DEB4ACF63843407008496D@[192.168.1.119]> <378442658.17718@cnnic.cn> <0ece01c7921a$f17462d0$236ff1da@yaojk> <2AE4ADBFDF027DA3E2392E11@[10.1.110.5]> <464D3C3D.1070707@alvestrand.no> Message-ID: Date: Fri, 18 May 2007 14:09:27 +0100 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: <464D3C3D.1070707@alvestrand.no> 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 Fri, 18 May 2007 06:40:13 +0100, Harald Alvestrand wrote: > Charles Lindsey wrote: >> But, given that the 'correct' behaviour is to bounce, in this case this >> means bouncing a DSN back to the Reporting MTA, which is not really in >> anybody's interest. Therefore, it would be quite wrong for us to define >> the EAI DSN extension in such a way that bouncing of the DNS was >> inevitable in such situations - especially as there are two other ways >> in which it could be defined (using application/message-utf8smtp or >> message/rfc822) which entirely avoid the problem. > The correct behaviour when sending a DSN is to use a MAIL FROM of <>. > > The correct behaviour when bouncing a message with MAIL FROM <> is to > discard the message. Indeed, but that is actually slightly worse than the bouncing scenario, because it will be less likely that the problem will get noticed. If we are defining a protocol for reporting delivery of messages, then it seems highy desirable that such reports should be returned through a reliable channel. So why are we proposing to define a reporting channel which actually has unreliability designed into 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 May 18 10:08:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp38X-0000LM-2v; Fri, 18 May 2007 10:08:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp38W-0000LE-4S for ima@ietf.org; Fri, 18 May 2007 10:08:52 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp38U-0002RD-Qs for ima@ietf.org; Fri, 18 May 2007 10:08:52 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Hp38U-000Iy4-3Q; Fri, 18 May 2007 10:08:50 -0400 Date: Fri, 18 May 2007 10:08:49 -0400 From: John C Klensin To: Charles Lindsey , IMA Subject: Re: [EAI] Not a good reason? (Re: Minutes from Prague (fwd)) Message-ID: In-Reply-To: References: <69DEB4ACF63843407008496D@[192.168.1.119]> <378442658.17718@cnnic.cn> <0ece01c7921a$f17462d0$236ff1da@yaojk> <2AE4ADBFDF027DA3E2392E11@[10.1.110.5]> <464D3C3D.1070707@alvestrand.no> X-Mailer: Mulberry/4.0.8 (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: 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 --On Friday, 18 May, 2007 14:09 +0100 Charles Lindsey wrote: >> The correct behaviour when bouncing a message with MAIL FROM >> <> is to discard the message. > > Indeed, but that is actually slightly worse than the bouncing > scenario, because it will be less likely that the problem will > get noticed. > > If we are defining a protocol for reporting delivery of > messages, then it seems highy desirable that such reports > should be returned through a reliable channel. So why are we > proposing to define a reporting channel which actually has > unreliability designed into it? Because otherwise it is really easy to get mail loops. More to the point, this has been established practice for more than a quarter century. Trying to reopen it at this point violates both the general principle that EIA doesn't try to change things that involve the same issue whether i18email is used or not as well as the simple improbability of the installed base agreeing to change this. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat May 19 02:05:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpI4Q-0005XP-6f; Sat, 19 May 2007 02:05:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpI4O-0005Tz-VC for ima@ietf.org; Sat, 19 May 2007 02:05:36 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpI4O-00031C-8n for ima@ietf.org; Sat, 19 May 2007 02:05:36 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HpI4I-0007Yf-SC for ima@ietf.org; Sat, 19 May 2007 08:05:30 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 May 2007 08:05:30 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 May 2007 08:05:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 19 May 2007 09:05:09 +0300 Lines: 297 Message-ID: <5dtzu9fiwa.fsf_-_@Hurtta06k.keh.iki.fi> References: <69DEB4ACF63843407008496D@[192.168.1.119]> <378442658.17718@cnnic.cn> <0ece01c7921a$f17462d0$236ff1da@yaojk> <2AE4ADBFDF027DA3E2392E11@[10.1.110.5]> <464D3C3D.1070707@alvestrand.no> 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: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: Charles Lindsey , Kari Hurtta Subject: [EAI] Ascii user X sends mail (Re: Not a good reason? (Re: Minutes from Prague (fwd))) 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 writes in gmane.ietf.ima: > --On Friday, 18 May, 2007 14:09 +0100 Charles Lindsey > wrote: > > >> The correct behaviour when bouncing a message with MAIL FROM > >> <> is to discard the message. > > > > Indeed, but that is actually slightly worse than the bouncing > > scenario, because it will be less likely that the problem will > > get noticed. > > > > If we are defining a protocol for reporting delivery of > > messages, then it seems highy desirable that such reports > > should be returned through a reliable channel. So why are we > > proposing to define a reporting channel which actually has > > unreliability designed into it? > > Because otherwise it is really easy to get mail loops. > > More to the point, this has been established practice for more > than a quarter century. Trying to reopen it at this point > violates both the general principle that EIA doesn't try to > change things that involve the same issue whether i18email is > used or not as well as the simple improbability of the installed > base agreeing to change this. > > john Let's look scenario again. I prove that removing UTF8SMTP from scenario DSN is not lost. Therefore this is UTF8SMTP issue. That is where there is " unreliability designed into it". Ascii user X sends mail to address which bounces (recipient mailbox is full or recipient address is mistyped) MUA which is used to send message is UTF8SMTP capable. Because UTF8SMTP is negotiated proprerty, there is no "use UTF8SMTP" switch on MUA. That just confuses users. Subject of message is Terveisiä täältä All addresses used are ASCII 1) Case: MSA is UTF8SMTP capable ( message/utf8smtp used on scenario) ( Sender X ) normal mail (A) [ MUA ] -------------> [ MSA ] UTF8SMTP | UTF8SMTP | v [ MTA ] | UTF8SMTP v [ MTA ] DSN with message/utf8smtp subpart | DSN ( B) with 8bit content | UTF8SMTP v [ MTA ] DSN with message/utf8smtp subpart | DSN (C) with 8bit content | 8BITMIME | v [ MTA ] DSN is dropped [ ] (D) [ ] . no 8BITMIME . . [ MTA ] [ mailstore ] ( Sender X ) (A) Message is UTF8SMTP message because subject is not encoded. (B) Mail bounces. On generated DSN there is subpart with Content-type: message/utf8smtp Content-Transfer-Encoding: 8bit (C) UTF8SMTP to 8BITMIME gateway was not downgraded message/utf8smtp subpart. It is still Content-type: message/utf8smtp Content-Transfer-Encoding: 8bit This allowed by MIME. (D) 8BITMIME to 7-bit gateway can not convert DSN with that message/utf8smtp subpart because of RFC 2045 (*) forbids: Content-type: message/utf8smtp Content-Transfer-Encoding: quoted-printable (*) RFC 2045 "EXPRESSLY FORBIDDEN" rule: 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. 2) Case: MSA is not UTF8SMTP capable ( Sender X ) normal mail (E) [ MUA ] -------------> [ MSA ] 8BITMIME | 8BITMIME | v [ MTA ] | 8BITMIME v [ MTA ] DSN with message/rfc822 subpart | DSN ( F) | 8BITMIME v [ MTA ] DSN with message/rfc822 subpart | DSN | 8BITMIME | v [ MTA ] DSN is not dropped [ ] (G) [ ] | DSN | no 8BITMIME v [ MTA ] [ mailstore ] ( Sender X ) (E) Because MSA does not annouce UTF8SMTP MUA encodes subject Terveisiä täältä Therefore mail is just normal 8BITMIME message (F) Mail bounces. On generated DSN there is subpart with Content-type: message/rfc822 Content-Transfer-Encoding: 8bit (G) 8BITMIME to 7-bit gateway can convert DSN with that message/rfc822 subpart to: Content-type: message/rfc822 Content-Transfer-Encoding: 7bit Now Sender X is informed that recipient mailbox is full or recipient address is mistyped. On case 1 it was because MSA was UTf8SMTP capable and message/utf8smtp was used outside of "UTF8SMTP universe". On next case spacification is rewritten and application/message-utf8smtp is used instead. 3) Case: MSA is UTF8SMTP capable ( application/message-utf8smtp used on scenario) ( Sender X ) normal mail (H) [ MUA ] -------------> [ MSA ] UTF8SMTP | UTF8SMTP | v [ MTA ] | UTF8SMTP v [ MTA ] DSN with application/message-utf8smtp | DSN ( I) subpart with 8bit content | UTF8SMTP v [ MTA ] DSN with application/message-utf8smtp | DSN subpart with 8bit content | 8BITMIME | v [ MTA ] DSN is not dropped [ ] (J) [ ] | DSN | no 8BITMIME v [ MTA ] [ mailstore ] ( Sender X ) (H) Message is UTF8SMTP message because subject is not encoded. (I) Mail bounces. On generated DSN there is subpart with Content-type: application/message-utf8smtp Content-Transfer-Encoding: 8bit (J) 8BITMIME to 7-bit gateway can convert DSN with that application/message-utf8smtp subpart to: Content-type: application/message-utf8smtp Content-Transfer-Encoding: quoted-printable Now Sender X is informed that recipient mailbox is full or recipient address is mistyped. On next case spacification is rewritten and message/utf8smtp is used firts and then downgraded to message/rfc822 4) Case: MSA is UTF8SMTP capable ( message/utf8smtp used and downgraded on scenario) ( Sender X ) normal mail (K) [ MUA ] -------------> [ MSA ] UTF8SMTP | UTF8SMTP | v [ MTA ] | UTF8SMTP v [ MTA ] DSN with message/utf8smtp subpart | DSN ( L) with 8bit content | UTF8SMTP v [ MTA ] DSN with message/rfc822 subpart | DSN (M) | 8BITMIME v [ MTA ] DSN is not dropped [ ] (N) [ ] | DSN | no 8BITMIME v [ MTA ] [ mailstore ] ( Sender X ) (K) Message is UTF8SMTP message because subject is not encoded. (L) Mail bounces. On generated DSN there is subpart with Content-type: message/utf8smtp Content-Transfer-Encoding: 8bit (M) UTF8SMTP to 8BITMIME gateway is downgrading message/utf8smtp subpart to: Content-type: message/rfc822 Content-Transfer-Encoding: 8bit (N) 8BITMIME to 7-bit gateway can convert DSN with that message/rfc822 subpart to: Content-type: message/rfc822 Content-Transfer-Encoding: 7bit Now Sender X is informed that recipient mailbox is full or recipient address is mistyped. ( If UTF8SMTP addresses are used on original message, then conversion message/utf8smtp to message/rfc822 can fail and DSN is dropped, but on this scenario all addresses are ASCII. ) Thank you for your attention. / Kari Hurtta PS. With subject Terveisiä täältä someone can think that ASCII user is using Internet cafe on his vacation trip. Even when this is case ASCII user can still access his 7-bit mailbox. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat May 19 02:51:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpIn3-0008Fy-Kn; Sat, 19 May 2007 02:51:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpIn3-0008Ft-Aq for ima@ietf.org; Sat, 19 May 2007 02:51:45 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpIn1-0006Dg-QO for ima@ietf.org; Sat, 19 May 2007 02:51:45 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F1ABC2596D9 for ; Sat, 19 May 2007 08:51:42 +0200 (CEST) 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 22738-04 for ; Sat, 19 May 2007 08:51:37 +0200 (CEST) Received: from [192.168.1.119] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 90C072596CE for ; Sat, 19 May 2007 08:51:37 +0200 (CEST) Date: Sat, 19 May 2007 08:51:10 +0200 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> 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: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [EAI] Issues open against SMTPEXT and UTF8HDR documents 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 Given that we have known open issues against the documents, the chairs have concluded that it's a bit premature to take these documents to WG Last Call. But we have to get these issues settled, and make sure we have raised all significant issues as soon as possible, if we're going to catch up with any reasonable schedule. Below are the tickets created for the issues we know. When following up, please use the following subject line convention: - Subject: #1483 for addressing issue 1483 - Subject: ISSUE:
: for raising a new issue. The chairs will enter issues raised with the ISSUE: convention into the tracker if they deem the issue well defined and important; if they are unsure of its importance, they may ask for a second before tracking it. Grammar and spelling notes should go directly to the editors. PLEASE raise issues against these 2 documents as soon as possible; preferably before May 23 (Wednesday of next week). Note that we're NOT calling for a final round of issues on -downgrade or the other documents at this time; issues will be noted, but we're not going to attempt to resolve all of them rapidly. Below are the tickets created so far. ------------- Forwarded Message ------------ Subject: [psg.com #1483] AutoReply: SMTPEXT 2.7: Non-ASCII in response texts In RFC 2821, SMTP responses are defined to be ASCII-only. If email addresses are extended to support non-ASCII, some responses, which today contain email addresses, will either have to not contain email addresses or be extended in some way. Alternatives include: - Just send non-ASCII - Send non-ASCII, but only in email addresses that were specified by the client - Send non-ASCII, but only if client enables that feature by a special command - Send ASCII only There may be more. ------------ Forwarded Message ------------ Subject: [psg.com #1484] AutoReply: SMTPEXT 2.2: More exact definition of action choices Section 2.2 contains the following text: ..... Instead, an SMTP client other than the Submission MTA MUST make one of the following three choices: 1. Reject or return the message as undeliverable. 2. Find an alternate route to the destination that permits UTF8SMTP. 3. If and only if an ASCII address is available for the return path and one or more of the specific forwarding paths being attempted, downgrade the message to an all-ASCII form as specified in [EAI-downgrading]. None of the 3 choices is fully described in detail in the document. It may be desirable to add more detail. ------------ Forwarded Message ------------ Subject: [psg.com #1485]: UTF8HDR 4.6/DSN: Choice of body part for transport of UTF8SMTP messages The choice of the body part to transport UTF8SMTP messages in a message has proved controversial. Suggestions include: - message/utf8 (inconsistent with certain statements in the MIME RFCs) - application/utf8smtp (stylistically questionable) - message/rfc822 (incompatible with existing definition) A decision needs to be made. ------------ Forwarded Message ------------ Subject: [psg.com #1486] AutoReply: SMTPEXT 2.7.3: Message retry It's been suggested that changing the message retry mechanism as specified in section 2.7.3 is a sensitive issue. We might want to either revisit the text or remove it entirely, so that the behaviour is identical to normal 2821 behaviour. ------------ Forwarded Message ------------ Subject: [psg.com #1487] AutoReply: UTF8HDR 4.2: Does this specification update MIME? As written, section 4.2 updates the MIME specification by allowing UTF-8 in MIME headers. The headers do not say that the MIME RFC is updated, and we need a proper descritption of what it means for an experimental RFC to "update" a standards-track one. ------------ Forwarded Message ------------ Subject: [psg.com #1488] AutoReply: UTF8HDR 4.2: List MIME headers that are modified? Should the UTF8HDR specification list the MIME headers that are updated by this specification? -------------------------------------------------- _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon May 21 01:18:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq0Hi-0000kJ-Ev; Mon, 21 May 2007 01:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq0Hg-0000jj-CL for ima@ietf.org; Mon, 21 May 2007 01:18:16 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq0Hf-0008Dh-Qd for ima@ietf.org; Mon, 21 May 2007 01:18:16 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EE4042596C3; Mon, 21 May 2007 07:18:14 +0200 (CEST) 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 11167-07; Mon, 21 May 2007 07:18:07 +0200 (CEST) Received: from [192.168.1.119] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id C52CD2596B7; Mon, 21 May 2007 07:18:07 +0200 (CEST) Date: Mon, 21 May 2007 07:17:38 +0200 From: Harald Tveit Alvestrand To: Kari Hurtta , ima@ietf.org Subject: Re: [EAI] Ascii user X sends mail (Re: Not a good reason? (Re: Minutes from Prague (fwd))) Message-ID: <093B204FA938F2B28EC03844@[192.168.1.119]> In-Reply-To: <5dtzu9fiwa.fsf_-_@Hurtta06k.keh.iki.fi> References: <69DEB4ACF63843407008496D@[192.168.1.119]> <378442658.17718@cnnic.cn> <0ece01c7921a$f17462d0$236ff1da@yaojk> <2AE4ADBFDF027DA3E2392E11@[10.1.110.5]> <464D3C3D.1070707@alvestrand.no> <5dtzu9fiwa.fsf_-_@Hurtta06k.keh.iki.fi> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 19. mai 2007 09:05 +0300 Kari Hurtta = wrote: >> More to the point, this has been established practice for more >> than a quarter century. Trying to reopen it at this point >> violates both the general principle that EIA doesn't try to >> change things that involve the same issue whether i18email is >> used or not as well as the simple improbability of the installed >> base agreeing to change this. >> >> john > > > Let's look scenario again. I prove that removing UTF8SMTP from > scenario DSN is not lost. Therefore this is UTF8SMTP issue. > > That is where there is " unreliability designed into it". > > Ascii user X sends mail to address which bounces (recipient mailbox > is full or recipient address is mistyped) > > MUA which is used to send message is UTF8SMTP capable. > Because UTF8SMTP is negotiated proprerty, there is no > "use UTF8SMTP" switch on MUA. That just confuses users. > >Subject of message is Terveisi=C3=A4 t=C3=A4=C3=A4lt=C3=A4 > >All addresses used are ASCII Here you have made the interesting assumption that the subject of the=20 message will be represented in raw UTF-8 when the message is available for=20 DSN creation. This is contrary to the WG decision of "no upgrade within the network". Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon May 21 02:51:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq1jh-0005Zi-PM; Mon, 21 May 2007 02:51:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq1jh-0005Zc-28 for ima@ietf.org; Mon, 21 May 2007 02:51:17 -0400 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq1jf-0001YI-Jg for ima@ietf.org; Mon, 21 May 2007 02:51:17 -0400 Received: from virkku.fmi.fi (virkku.fmi.fi [193.166.211.54]) (envelope-from hurtta@siilo.fmi.fi) by smtp1gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20070214) with ESMTP id l4L6pDVb013304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 May 2007 09:51:13 +0300 Received: from siilo.fmi.fi by virkku.fmi.fi with ESMTP id l4L6pDTB027817 ; Mon, 21 May 2007 09:51:13 +0300 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id l4L6pCx0001155 ; Mon, 21 May 2007 09:51:12 +0300 Received: by siilo.fmi.fi id l4L6pCam001152; Mon, 21 May 2007 09:51:12 +0300 Message-Id: <200705210651.l4L6pCam001152@siilo.fmi.fi> Subject: Please, read carefully! (Re: [EAI] Ascii user X sends mail (Re: Not a good reason? (Re: Minutes from Prague (fwd)))) In-Reply-To: <093B204FA938F2B28EC03844@[192.168.1.119]> To: Harald Tveit Alvestrand Date: Mon, 21 May 2007 09:51:12 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123f (25)] MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Filter: smtp1gate: 3 received headers rewritten with id 20070521/03909/01 X-Filter: smtp1gate: ID 3907/01, 1 parts scanned for known viruses X-Filter: virkku: ID 2219/01, 1 parts scanned for known viruses X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtp1gate.fmi.fi [193.166.223.31]); Mon, 21 May 2007 09:51:13 +0300 (EEST) X-Spam-Flag: NO X-Spam-Status: False, hits=-2.2 required=5 (smtp1gate: ID 3907/01) report=AWL,BAYES_00,FORGED_RCVD_HELO,PLING_QUERY Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp1gate.fmi.fi id l4L6pDVb013304 X-Spam-Score: 0.9 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Kari Hurtta , 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 >>> Harald Tveit Alvestrand [ Charset UTF-8 unsupported, converting... ] >=20 >=20 > --On 19. mai 2007 09:05 +0300 Kari Hurtta w= rote: >=20 > >> More to the point, this has been established practice for more > >> than a quarter century. Trying to reopen it at this point > >> violates both the general principle that EIA doesn't try to > >> change things that involve the same issue whether i18email is > >> used or not as well as the simple improbability of the installed > >> base agreeing to change this. > >> > >> john > > > > > > Let's look scenario again. I prove that removing UTF8SMTP from > > scenario DSN is not lost. Therefore this is UTF8SMTP issue. > > > > That is where there is " unreliability designed into it". > > > > Ascii user X sends mail to address which bounces (recipient mailbox > > is full or recipient address is mistyped) > > > > MUA which is used to send message is UTF8SMTP capable. > > Because UTF8SMTP is negotiated proprerty, there is no > > "use UTF8SMTP" switch on MUA. That just confuses users. > > > >Subject of message is Terveisi=E4 t=E4=E4lt=E4 > > > >All addresses used are ASCII >=20 > Here you have made the interesting assumption that the subject of the=20 > message will be represented in raw UTF-8 when the message is available = for=20 > DSN creation. >=20 > This is contrary to the WG decision of "no upgrade within the network". >=20 > Harald There is NO upgrade happened !!! There is no any contrary with the=20 WG decision of "no upgrade within the network". MSA and mail client supports UTF8SMTP. Read carefully, please. Message submission path is full UTF8SMTP. On first picture: 1) Case: MSA is UTF8SMTP capable ( message/utf8smtp used on scenario) =20 ( Sender X ) normal mail (A) [ MUA ] -------------> [ MSA ] =20 UTF8SMTP | UTF8SMTP | v [ MTA ] =20 | UTF8SMTP v Notice that key point between picture 1) and Picture 2) is that on picture 1 MSA announces UTF8SMTP and on picture 2 MSA do not announce UTF8SMTP to MUA. On second picture: 2) Case: MSA is not UTF8SMTP capable=20 ( Sender X ) normal mail (E) [ MUA ] -------------> [ MSA ] =20 8BITMIME | 8BITMIME | v [ MTA ] =20 | 8BITMIME v On both case MUA is UTF8SMTP capable. It is MUA which decides is message sent as UTF8SMTP or with MIME encoded words on Subject. It is message store and return path where there is no UTF8SMTP and 8BITMIME either available. Another key point is that what you quoted: > > MUA which is used to send message is UTF8SMTP capable. > > Because UTF8SMTP is negotiated proprerty, there is no > > "use UTF8SMTP" switch on MUA. That just confuses users. On my message with subject UTF8SMTP / 8BITMIME / ASCII -universe amd message/utf8smtp (Re: Not a good reason? (Re: Minutes from Prague (fwd))) =20 I explain why it is likely scenario that there is no 8BITMIME. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon May 21 09:01:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq7Vo-0006Yk-Jo; Mon, 21 May 2007 09:01:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq7Vi-0006Y6-OJ for ima@ietf.org; Mon, 21 May 2007 09:01:16 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq7Ve-0003en-26 for ima@ietf.org; Mon, 21 May 2007 09:01:14 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 580092596F4; Mon, 21 May 2007 15:01:09 +0200 (CEST) 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 23113-05; Mon, 21 May 2007 15:00:08 +0200 (CEST) Received: from [192.168.1.119] (unknown [62.92.16.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id 07B352596EB; Mon, 21 May 2007 15:00:08 +0200 (CEST) Date: Mon, 21 May 2007 13:44:11 +0200 From: Harald Tveit Alvestrand To: Kari Hurtta Subject: Re: Please, read carefully! (Re: [EAI] Ascii user X sends mail (Re: Not a good reason? (Re: Minutes from Prague (fwd)))) Message-ID: <6E167B2E6FFFFCF979514E40@B50854F0A9192E8EC6CDA126> In-Reply-To: <200705210651.l4L6pCam001152@siilo.fmi.fi> References: <200705210651.l4L6pCam001152@siilo.fmi.fi> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.9 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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 You are right - I did not read carefully enough. You have identified a message loss based on 3 assumptions: - Forward path (including sender) is UTF8SMTP capable - Reverse path is NOT UTF8SMTP capable - The RFC 2045 requirement is upheld. My source of confusion was because you used the term "ASCII user", which is = defined in -framework as: An "ASCII user" (i) exclusively uses email addresses that contain ASCII characters only, and (ii) cannot generate recipient addresses that contain non-ASCII characters. I missed the fact that you said the sender was UTF8SMTP capable. That said, I still have trouble taking the last 2 of your 3 assumptions as=20 given. Harald --On 21. mai 2007 09:51 +0300 Kari Hurtta wrote: >>>> Harald Tveit Alvestrand > [ Charset UTF-8 unsupported, converting... ] >> >> >> --On 19. mai 2007 09:05 +0300 Kari Hurtta >> wrote: >> >> >> More to the point, this has been established practice for more >> >> than a quarter century. Trying to reopen it at this point >> >> violates both the general principle that EIA doesn't try to >> >> change things that involve the same issue whether i18email is >> >> used or not as well as the simple improbability of the installed >> >> base agreeing to change this. >> >> >> >> john >> > >> > >> > Let's look scenario again. I prove that removing UTF8SMTP from >> > scenario DSN is not lost. Therefore this is UTF8SMTP issue. >> > >> > That is where there is " unreliability designed into it". >> > >> > Ascii user X sends mail to address which bounces (recipient mailbox >> > is full or recipient address is mistyped) >> > >> > MUA which is used to send message is UTF8SMTP capable. >> > Because UTF8SMTP is negotiated proprerty, there is no >> > "use UTF8SMTP" switch on MUA. That just confuses users. >> > >> > Subject of message is Terveisi=C3=A4 t=C3=A4=C3=A4lt=C3=A4 >> > >> > All addresses used are ASCII >> >> Here you have made the interesting assumption that the subject of the >> message will be represented in raw UTF-8 when the message is available >> for DSN creation. >> >> This is contrary to the WG decision of "no upgrade within the network". >> >> Harald > > There is NO upgrade happened !!! > There is no any contrary with the > WG decision of "no upgrade within the network". > > > MSA and mail client supports UTF8SMTP. > > Read carefully, please. > > Message submission path is full UTF8SMTP. > > On first picture: > > 1) Case: MSA is UTF8SMTP capable > ( message/utf8smtp used on scenario) > > ( Sender X ) > normal mail (A) > [ MUA ] -------------> [ MSA ] > UTF8SMTP | UTF8SMTP > | > v > [ MTA ] > | UTF8SMTP > v > > > > Notice that key point between picture 1) and Picture 2) > is that on picture 1 MSA announces UTF8SMTP > and on picture 2 MSA do not announce UTF8SMTP to MUA. > > On second picture: > > 2) Case: MSA is not UTF8SMTP capable > > ( Sender X ) > normal mail (E) > [ MUA ] -------------> [ MSA ] > 8BITMIME | 8BITMIME > | > v > [ MTA ] > | 8BITMIME > v > > On both case MUA is UTF8SMTP capable. > > It is MUA which decides is message sent as UTF8SMTP > or with MIME encoded words on Subject. > > > It is message store and return path where there > is no UTF8SMTP and 8BITMIME either available. > > Another key point is that what you quoted: > >> > MUA which is used to send message is UTF8SMTP capable. >> > Because UTF8SMTP is negotiated proprerty, there is no >> > "use UTF8SMTP" switch on MUA. That just confuses users. > > > > On my message with subject > UTF8SMTP / 8BITMIME / ASCII -universe amd message/utf8smtp > (Re: Not a good reason? (Re: Minutes from Prague (fwd))) > > I explain why it is likely scenario that there is no 8BITMIME. > > / Kari Hurtta > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon May 21 09:15:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq7jQ-0008KT-BY; Mon, 21 May 2007 09:15:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq7jM-0008Dc-Tn for ima@ietf.org; Mon, 21 May 2007 09:15:20 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq7jK-0008Ne-5c for ima@ietf.org; Mon, 21 May 2007 09:15:20 -0400 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 46519b64.7e98.a1 for ima@ietf.org; Mon, 21 May 2007 14:15:16 +0100 (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 l4LDFF5q001754 for ; Mon, 21 May 2007 14:15:15 +0100 (BST) References: <69DEB4ACF63843407008496D@[192.168.1.119]> <378442658.17718@cnnic.cn> <0ece01c7921a$f17462d0$236ff1da@yaojk> <2AE4ADBFDF027DA3E2392E11@[10.1.110.5]> <464D3C3D.1070707@alvestrand.no> Message-ID: To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Mon, 21 May 2007 14:15:14 +0100 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Subject: [EAI] Fwd: #1485 (was Not a good reason?) 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, 18 May 2007 15:08:49 +0100, John C Klensin wrote: > --On Friday, 18 May, 2007 14:09 +0100 Charles Lindsey > wrote: >> If we are defining a protocol for reporting delivery of >> messages, then it seems highy desirable that such reports >> should be returned through a reliable channel. So why are we >> proposing to define a reporting channel which actually has >> unreliability designed into it? > > > More to the point, this has been established practice for more > than a quarter century. Trying to reopen it at this point > violates both the general principle that EIA doesn't try to > change things that involve the same issue whether i18email is > used or not as well as the simple improbability of the installed > base agreeing to change this. Will you PLEASE STOP introducing a Strawman, accusing me of advocating that Strawman, and then shooting that Strawman down in flames. Of course it is out of the question to change the current practice that a DSN is sent with Return-Path:<>, and hence will be dropped silently if it fails to be delivered. But since I have NEVER suggested such a change, what was your point? Please can we get back to the issue at hand (which apparently bears the number #1485), and please can we address it on its technical merits. I think the following summarizes the problem: We are concerned with a UTF8SMTP message which contains 8bit (UTF-8) in some of its headers, and likely contains 8bit in its body as well. For whatever reason, a DSN including the full original message has to be returned along the Return-Path. The awkward case is where the route taken by the DSN an MTA that does not support UTF8SMTP and a further MTA that does not support 8BITMIME. There are three proposed methods to encapsulate the original message in the DSN: A. message/utf8smtp B. application/message-utf8smtp C. message/rfc822 Method C assumes an 'experimental extension' to RFC 204[56], together with a matching downgrade mechanism to be defined in our 'downgrade' draft. One may envisage the following types of MTA which may or may not currently exist, classified according to their behaviour when receiving an 8BITMIME message to be forwarded to a non-8BITMIME MTA: 1. 100% standards-compliant A. message/utf8smtp will be dropped, silently if Return-Path is <> B. application/message-utf8smtp will be converted to Q-P or Base64 C. message/rfc822 (already downgraded to 8BITMIME) will have its body converted to Q-P or Base64. 2. "EXPRESSLY OVERRIDDEN" These are what Chris Newman, as author of out DSN draft, and the attendees at Prague seem to have had in mind by suggesting that the "stupid" "EXPRESSLY FORBIDDEN" in RFC2045 should be ignored, and MTAs "educated" to treat unknown message types sensibly. A. message/utf8smtp will be converted to Q-P or Base64 B. application/message-utf8smtp will be converted to Q-P or Base64 C. message/rfc822 (already downgraded to 8BITMIME) will have its body converted to Q-P or Base64. 3. "Just send 8bit" for unknown message types A. message/utf8smtp will be sent as-is, including 8bit in headers and bodies B. application/message-utf8smtp will be converted to Q-P or Base64 C. message/rfc822 (already downgraded to 8BITMIME) will have its body converted to Q-P or Base64. 4. "Just send 8bit" always A. message/utf8smtp will be sent as-is, including 8bit in headers and bodies B. application/message-utf8smtp will be sent as-is, including 8bit in headers and bodies C. message/rfc822 (already downgraded to 8BITMIME) will be sent as-is, including 8bit in bodies. 5. Truncate everything to 7bit A. message/utf8smtp - both headers and bodies garbled B. applicatio/message-utf8smtp - both headers and bodies garbled C. message/rfc822 (already downgraded to 8BITMIME) - bodies garbled The currently deployed base of MTAs, with which UTF8SMTP will have to interoperate as best it can, doubtless includes examples of all five types, and maybe others. It has been reported that: Earlier versions of exim did #5. Current exim and gmail do #4, and some people (DJB) openly advocate this practice. Sendmail does #3. I am not aware of ANY that currently do either #1 or #2, but would welcome reports of any that do. But what is clear is that a significant proportion of the installed base exhibits behaviours #3 and #4. The possible outcomes when a DSN is processed by the various MTAs are: DSN delivered intact 8bit headers delivered, and hopefully displayed bodies garbled headers and bodies garbled Dropped silently, nothing delivered So we can now prepare a chart of the outcomes in the various scenarios: \ Encapsulation A B C \ MTA type #1 dropped intact intact #2 intact intact intact #3 8bit h&b intact intact #4 8bit h&b 8bit h&b 8bit b #5 garbled h&b garbled h&b garbled b It should be clear from that that Option A (message/utf8smtp) would be the worst choice to make. -- 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 May 21 09:21:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq7pO-0002eT-5T; Mon, 21 May 2007 09:21:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq7pM-0002eG-7g for ima@ietf.org; Mon, 21 May 2007 09:21:33 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq7pK-0000on-LL for ima@ietf.org; Mon, 21 May 2007 09:21:32 -0400 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 46519cc9.6c73.26e for ima@ietf.org; Mon, 21 May 2007 14:21:14 +0100 (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 l4LDL6Bk002107 for ; Mon, 21 May 2007 14:21:06 +0100 (BST) To: IMA Subject: Re: [EAI] Ascii user X sends mail (Re: Not a good reason? (Re: Minutes from Prague (fwd))) References: <69DEB4ACF63843407008496D@[192.168.1.119]> <378442658.17718@cnnic.cn> <0ece01c7921a$f17462d0$236ff1da@yaojk> <2AE4ADBFDF027DA3E2392E11@[10.1.110.5]> <464D3C3D.1070707@alvestrand.no> <5dtzu9fiwa.fsf_-_@Hurtta06k.keh.iki.fi> <093B204FA938F2B28EC03844@[192.168.1.119]> Message-ID: Date: Mon, 21 May 2007 14:21:05 +0100 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: <093B204FA938F2B28EC03844@[192.168.1.119]> 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 Mon, 21 May 2007 06:17:38 +0100, Harald Tveit Alvestrand wrote: >> Ascii user X sends mail to address which bounces (recipient mailbox >> is full or recipient address is mistyped) >> Subject of message is Terveisiä täältä >> >> All addresses used are ASCII > > Here you have made the interesting assumption that the subject of the > message will be represented in raw UTF-8 when the message is available > for DSN creation. > > This is contrary to the WG decision of "no upgrade within the network". I think you will find that, if you s/Ascii user X/UTF8SMTP user who uses ASCII-only addresses/, you will find that Kari has presented a valid scenario which needs proper technical consideration. I would expect that such users will commonly be found amongst Scandinavians who are fortunate enough to possess names which can be expresses without the extra Scandinavian characters. -- 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 May 21 09:45:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq8CL-0001Hi-PT; Mon, 21 May 2007 09:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq8CI-0001Hb-IB for ima@ietf.org; Mon, 21 May 2007 09:45:15 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq8CG-0003aS-UP for ima@ietf.org; Mon, 21 May 2007 09:45:14 -0400 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 4651a267.c5bc.b7 for ima@ietf.org; Mon, 21 May 2007 14:45:11 +0100 (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 l4LDjARS003550 for ; Mon, 21 May 2007 14:45:11 +0100 (BST) To: IMA References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: Date: Mon, 21 May 2007 14:45:10 +0100 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: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [EAI] #1483 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, 19 May 2007 07:51:10 +0100, Harald Tveit Alvestrand wrote: > ------------- Forwarded Message ------------ > Subject: [psg.com #1483] AutoReply: SMTPEXT 2.7: Non-ASCII in response > texts > - Just send non-ASCII > - Send non-ASCII, but only in email addresses that were specified by the > client > - Send non-ASCII, but only if client enables that feature by a special > command > - Send ASCII only Certainly the last case is wrong. Certainly, if the response is being sent in a DSN, then non-ASCII is in order. Certainly, if the original message contained non-ASCII, the originator can be presumed to understanda non-ASCII responses. We seem to have been arguing against "special command's (we got rid of Header-Type and HDR=UTF8). So I think either Case 1 or Case 2 are the only ppssibilites (I prefer Case 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 May 21 09:51:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq8Hw-0004hU-LG; Mon, 21 May 2007 09:51:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq8Ht-0004f3-H4 for ima@ietf.org; Mon, 21 May 2007 09:51:01 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq8Hr-0004hr-VJ for ima@ietf.org; Mon, 21 May 2007 09:51:01 -0400 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 4651a3c1.f99d.6d for ima@ietf.org; Mon, 21 May 2007 14:50:58 +0100 (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 l4LDovZZ003899 for ; Mon, 21 May 2007 14:50:58 +0100 (BST) To: IMA References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: Date: Mon, 21 May 2007 14:50:56 +0100 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: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [EAI] #1485 UTF8HDR 4.6/DSN: Choice of body part for messages 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, 19 May 2007 07:51:10 +0100, Harald Tveit Alvestrand wrote: > ------------ Forwarded Message ------------ > Subject: [psg.com #1485]: UTF8HDR 4.6/DSN: Choice of body part for > transport of UTF8SMTP messages > > The choice of the body part to transport UTF8SMTP messages in a message > has proved controversial. I have written separately on this. But utf8headers-05.txt is fine with me as it stands, and it should not be altered until we have decided on this issue in connection with DSN. -- 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 May 21 09:53:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq8KX-0006cR-Ck; Mon, 21 May 2007 09:53:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq8KT-0006c2-92 for ima@ietf.org; Mon, 21 May 2007 09:53:42 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq8KS-0004zB-Kw for ima@ietf.org; Mon, 21 May 2007 09:53:41 -0400 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1Hq8KP-0008Kq-U3; Mon, 21 May 2007 09:53:38 -0400 Date: Mon, 21 May 2007 09:53:34 -0400 From: John C Klensin To: Harald Tveit Alvestrand , Kari Hurtta Subject: Re: Please, read carefully! (Re: [EAI] Ascii user X sends mail (Re: Not a good reason? (Re: Minutes from Prague (fwd)))) Message-ID: <156C08F23D763EA64075D61F@[192.168.1.110]> In-Reply-To: <6E167B2E6FFFFCF979514E40@B50854F0A9192E8EC6CDA126> References: <200705210651.l4L6pCam001152@siilo.fmi.fi> <6E167B2E6FFFFCF979514E40@B50854F0A9192E8EC6CDA126> X-Mailer: Mulberry/4.0.8 (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.9 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 Monday, May 21, 2007 1:44 PM +0200 Harald Tveit Alvestrand wrote: > You are right - I did not read carefully enough. > > You have identified a message loss based on 3 assumptions: > > - Forward path (including sender) is UTF8SMTP capable > - Reverse path is NOT UTF8SMTP capable > - The RFC 2045 requirement is upheld. > > My source of confusion was because you used the term "ASCII > user", which is defined in -framework as: > > An "ASCII user" (i) exclusively uses email addresses that > contain > ASCII characters only, and (ii) cannot generate recipient > addresses that contain non-ASCII characters. > > I missed the fact that you said the sender was UTF8SMTP > capable. > > That said, I still have trouble taking the last 2 of your 3 > assumptions as given. Let me try to say that a little bit more strongly. It has been a property of the Internet's email system, at least since we switched over from FTP, that one can configure oneself into silly states in which mail won't go through and notifications will not get through either. Even reverse-paths with explicit, forward-generated, source-routes were not sufficient to prevent those cases. Some examples of this: (i) Even in the all-ASCII (no EAI facilities) world, it is possible to configure the MX records for a mail receiver so that one of the intermediate MX hosts will refuse to accept mail for the destination host or user. Cases of this will continue to increase if "intermediate MX server must know the current mailbox list at the destination site" plans develop and race conditions occur. (ii) Any moves toward "reject or drop" (rather than "reject or bounce") increase the number of messages that will silently disappear. No matter what precautions are taken, unless very fundamental changes are made to the SMTP model, cases remain in which a relay will either need to pass mail along for which neither the sender nor receiver can be adequately validated. The most obvious case arises from "mailbox temporarily full" conditions, which a relay cannot know about no matter how much information it has about mailbox name validity. Again, this is an issue even in the all-ASCII world. (iii) In the EAI-specific environment, configuring MX records so that a destination server that is EAI-capable and supports i18n mailboxes has intermediate servers that are not EAI-capable is, in the long term, dumb. The WG has agreed that, as a transitional matter, we need to allow for those cases and that is what downgrading is all about, but relays do not get into the mail path by accident. (iv) Sending mail that contains UTF-8 content to a submission server that is not EAI-capable is also dumb (and ignores protocol requirements that the server announce the capability to receive and process such messages). I would hope that such a submission server would simply reject such messages. (v) I suggest that sending mail that bears non-ASCII addresses (or other UTF-8 header content) from a host that cannot receive them -- or that is supported by relays that cannot receive them -- is significantly more dumb than (iii). In addition, we have always understood that delivery of MDNs and similar messages is more fragile than delivery of forward-pointing messages: the formal handoff of responsibility and requirement that NDNs be generated if needed for forward-pointing messages does not exist for these reverse ones and, as Harald has reminded us, one must not even attempt generate an NDN for a message that arrives with a null return path. For me, the situation here isn't that people can configure themselves into conditions in which a EAI NDN or the equivalent cannot be competently delivered. Nor do I believe that weak, non-conforming, implementations will not get themselves into trouble and risk trashing any mail that passes through them. I take both of those as given. Instead, the question is how much more complex we should make the protocol to ward off these cases or reduce the risk of them causing problems. My personal opinion is "very little". YMMD. Incidentally, for the specific case you listed in your note, unless I still don't understand it (and I have read your notes several times and very carefully), > Notice that key point between picture 1) and Picture 2) > is that on picture 1 MSA announces UTF8SMTP > and on picture 2 MSA do not announce UTF8SMTP to MUA. In case 2, the MUA MUST NOT send _any_ UTF-8 header material to the submission server. If it does, it is so far outside the specification that we are not obligated to specify, or even worry about, what happens next. And, if the MUA sends non-ASCII header information in encoded words, rather than UTF-8, and UTF-8 headers later appear anywhere in the system prior to final delivery, then we have "upgrade in the network". What am I missing? john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon May 21 10:15:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq8f8-0001wY-5n; Mon, 21 May 2007 10:15:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq8f4-0001v9-Iv for ima@ietf.org; Mon, 21 May 2007 10:14:59 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq8f3-0000pp-1w for ima@ietf.org; Mon, 21 May 2007 10:14:58 -0400 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 4651a95f.c5bc.da for ima@ietf.org; Mon, 21 May 2007 15:14:55 +0100 (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 l4LEEtuQ005354 for ; Mon, 21 May 2007 15:14:56 +0100 (BST) To: IMA References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: Date: Mon, 21 May 2007 15:14:55 +0100 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: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [EAI] #1486 Message retry 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, 19 May 2007 07:51:10 +0100, Harald Tveit Alvestrand wrote: > > ------------ Forwarded Message ------------ > Subject: [psg.com #1486] AutoReply: SMTPEXT 2.7.3: Message retry s/SMTPEXT 2.7.3/SMTPEXT 2.7.2/ > > It's been suggested that changing the message retry mechanism as > specified in section 2.7.3 is a sensitive issue. We might want to either > revisit the text or remove it entirely, so that the behaviour is > identical to normal 2821 behaviour. The behaviours is probably reasonable, provided the circumstances are appropriate, and waiting for an MX that is down to come up may be a good reason to queue the message for a while. But if all the available MXes do not support UTF8SMTP, then there is no point in further queuing. -- 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 May 21 10:22:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq8m0-0006b0-U3; Mon, 21 May 2007 10:22:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq8lv-0006Xl-Jv for ima@ietf.org; Mon, 21 May 2007 10:22:03 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq8ls-00025d-JC for ima@ietf.org; Mon, 21 May 2007 10:22:03 -0400 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 4651ab07.179ce.8c for ima@ietf.org; Mon, 21 May 2007 15:21:59 +0100 (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 l4LELwHM005779 for ; Mon, 21 May 2007 15:21:59 +0100 (BST) To: IMA References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: Date: Mon, 21 May 2007 15:21:58 +0100 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: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [EAI] #1487 Does this specification update MIME? 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, 19 May 2007 07:51:10 +0100, Harald Tveit Alvestrand wrote: > ------------ Forwarded Message ------------ > Subject: [psg.com #1487] AutoReply: UTF8HDR 4.2: Does this specification > update MIME? > > As written, section 4.2 updates the MIME specification by allowing UTF-8 > in MIME headers. > > The headers do not say that the MIME RFC is updated, and we need a > proper descritption of what it means for an experimental RFC to "update" > a standards-track one. And the same applies to RFC 2822, where we propose to allow things that 2822 forbids. I think, if an experimental RFC updates an existing RFC, then the proper wording would be "Experimentally Updates/Obsoletes/Whatever RFC xxxx". Then, if the experiment is abandoned, RFC xxxx remains unupdated. If the experiment later gets standardized, then RFC xxxx becomes fully updated. And, in the meantime, participants in the experiment do whatever the experimental document says. So I think the proper course is to included the words "Experimentally Updates ...", and then sit back and see if the IESG will allow it (maybe they will suggest something better). -- 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 May 21 10:24:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq8nv-0007ic-3f; Mon, 21 May 2007 10:24:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq8nr-0007eX-Ib for ima@ietf.org; Mon, 21 May 2007 10:24:04 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq8nm-0002qs-KN for ima@ietf.org; Mon, 21 May 2007 10:24:03 -0400 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 4651ab7d.2e04.283 for ima@ietf.org; Mon, 21 May 2007 15:23:57 +0100 (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 l4LENvKa005900 for ; Mon, 21 May 2007 15:23:57 +0100 (BST) To: IMA References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: Date: Mon, 21 May 2007 15:23:56 +0100 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: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [EAI] #1488 List MIME headers that are modified? 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, 19 May 2007 07:51:10 +0100, Harald Tveit Alvestrand wrote: > ------------ Forwarded Message ------------ > Subject: [psg.com #1488] AutoReply: UTF8HDR 4.2: List MIME headers that > are modified? > > Should the UTF8HDR specification list the MIME headers that are updated > by this specification? Yes (when we have finally agreed on the list :-( ). -- 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 May 21 12:44:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqAzh-0003Ev-Fg; Mon, 21 May 2007 12:44:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqAzg-0003EZ-4r for ima@ietf.org; Mon, 21 May 2007 12:44:24 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqAzd-0008JS-Ji for ima@ietf.org; Mon, 21 May 2007 12:44:23 -0400 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 4651cc64.3037.b8 for ima@ietf.org; Mon, 21 May 2007 17:44:20 +0100 (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 l4LGiIS7015298 for ; Mon, 21 May 2007 17:44:19 +0100 (BST) Date: Mon, 21 May 2007 17:44:18 +0100 To: IMA Subject: Re: [EAI] Fwd: #1485 (was Not a good reason?) References: <69DEB4ACF63843407008496D@[192.168.1.119]> <378442658.17718@cnnic.cn> <0ece01c7921a$f17462d0$236ff1da@yaojk> <2AE4ADBFDF027DA3E2392E11@[10.1.110.5]> <464D3C3D.1070707@alvestrand.no> 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: 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, 21 May 2007 14:15:14 +0100, Charles Lindsey wrote: > The currently deployed base of MTAs, with which UTF8SMTP will have to > interoperate as best it can, doubtless includes examples of all five > types, and maybe others. It has been reported that: > > Earlier versions of exim did #5. > Current exim and gmail do #4, and some people (DJB) openly advocate > this practice. s/gmail/qmail/ > Sendmail does #3. > I am not aware of ANY that currently do either #1 or #2, but would > welcome reports of any that do. But what is clear is that a significant > proportion of the installed base exhibits behaviours #3 and #4. -- 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 May 21 23:33:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqL89-0004lb-N3; Mon, 21 May 2007 23:33:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqL86-0004lC-II for ima@ietf.org; Mon, 21 May 2007 23:33:46 -0400 Received: from smtp2gate.fmi.fi ([193.166.223.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqL81-0006ZI-1H for ima@ietf.org; Mon, 21 May 2007 23:33:46 -0400 Received: from virkku.fmi.fi (virkku.fmi.fi [193.166.211.54]) (envelope-from hurtta@siilo.fmi.fi) by smtp2gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20070214) with ESMTP id l4M3XcOB000670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 May 2007 06:33:38 +0300 Received: from siilo.fmi.fi by virkku.fmi.fi with ESMTP id l4M3XcAe015754 ; Tue, 22 May 2007 06:33:38 +0300 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id l4M3XbbF005545 ; Tue, 22 May 2007 06:33:37 +0300 Received: by siilo.fmi.fi id l4M3Xbi4005542; Tue, 22 May 2007 06:33:37 +0300 Message-Id: <200705220333.l4M3Xbi4005542@siilo.fmi.fi> In-Reply-To: <4651FECF.2080908@alvestrand.no> To: Harald Alvestrand , ima@ietf.org Date: Tue, 22 May 2007 06:33:37 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp2gate: 3 received headers rewritten with id 20070522/07266/01 X-Filter: smtp2gate: ID 7265/01, 1 parts scanned for known viruses X-Filter: virkku: ID 3455/01, 1 parts scanned for known viruses X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtp2gate.fmi.fi [193.166.223.32]); Tue, 22 May 2007 06:33:38 +0300 (EEST) X-Spam-Flag: NO X-Spam-Status: False, hits=-2.4 required=5 (smtp2gate: ID 7265/01) report=AWL,BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Kari Hurtta , Kari Hurtta Subject: [EAI] #1485 "is intended to be transportable as part of an ordinary [RFC2822] message" (Re: #1485: Choices) 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 > Kari Hurtta wrote: > > Harald Tveit Alvestrand writes: > > > > > > > >> ------------ Forwarded Message ------------ > >> Subject: [psg.com #1485]: UTF8HDR 4.6/DSN: Choice of body part for > >> transport of UTF8SMTP messages > >> > >> The choice of the body part to transport UTF8SMTP messages in a message > >> has proved controversial. > >> Suggestions include: > >> > >> - message/utf8 (inconsistent with certain statements in the MIME RFCs) > >> - application/utf8smtp (stylistically questionable) > >> - message/rfc822 (incompatible with existing definition) > >> > >> A decision needs to be made. > >> > > > > In another message you said: > > > > Downgrading to message/rfc822 is not completely beyond the realm of the > > reasonable (imho). > > > > > > However seems that you did not listed that alternative > > > > - message/utf8 on UTF8SMTP compliant environment, > > downgraded it to message/rfc822 outside of UTF8SMTP environment > > > > > > To me it looks that on this alternative there is no problems > > mentioned inside of ( ) on list. > > > > > > Or what I have missed? > > > This is not an alternative for carrying an UTF8SMTP message. > It is an alternative for what to do with an UTF8SMTP message that is > carried as part of another message when it hits a UTF8SMTP-to-2821 > gateway, which is a separable issue. > > I believe that to be an issue that needs to be addressed in the > downgrading document, not the utf8hdr document. There is sentence on utf8hdr document which is affected: | the object defined in [EAI-dsn] is intended to be transportable as | part of an ordinary [RFC2822] message. That sentence imply that if message/utf8 is selected, it is not downgraded. So it is part of that issue. That is on chapter 4.6 on draft-ietf-eai-utf8headers-05.txt. / Kari Hurtta > > ( This do not imply that I prefer that alternative. I just noted that > > downgrading alternative was not listed. ) > > > > > > / Kari Hurtta > > > > PS. That was Picture 4 on my message "Ascii user X sends mail" > > (and alternative 1 on my message "UTF8SMTP / 8BITMIME / ASCII -universe > > amd message/utf8smtp"). _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue May 22 10:43:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqVa1-0001q2-5A; Tue, 22 May 2007 10:43:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqVa0-0001p9-AJ for ima@ietf.org; Tue, 22 May 2007 10:43:16 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqVZx-0003De-Kk for ima@ietf.org; Tue, 22 May 2007 10:43:16 -0400 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 4653017e.116d1.a for ima@ietf.org; Tue, 22 May 2007 15:43:11 +0100 (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 l4MEh97q009547 for ; Tue, 22 May 2007 15:43:10 +0100 (BST) To: IMA Subject: Re: [EAI] #1487 Does this specification update MIME? References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: Date: Tue, 22 May 2007 15:43:08 +0100 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: 69a74e02bbee44ab4f8eafdbcedd94a1 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, 21 May 2007 15:21:58 +0100, Charles Lindsey wrote: > On Sat, 19 May 2007 07:51:10 +0100, Harald Tveit Alvestrand > wrote: > >> ------------ Forwarded Message ------------ >> Subject: [psg.com #1487] AutoReply: UTF8HDR 4.2: Does this >> specification update MIME? >> >> As written, section 4.2 updates the MIME specification by allowing UTF-8 >> in MIME headers. > I think, if an experimental RFC updates an existing RFC, then the proper > wording would be "Experimentally Updates/Obsoletes/Whatever RFC xxxx". > Then, if the experiment is abandoned, RFC xxxx remains unupdated. If the > experiment later gets standardized, then RFC xxxx becomes fully updated. > And, in the meantime, participants in the experiment do whatever the > experimental document says. On further thought, I think the wording needed is "Experimentally extends RFC xxxx". Essentially, an "extension" allows you to say, or do, something that was not allowed by RFC xxxx. But you are only allowed to say or do it in envireonments that support the extension, So, for example, when speaking to an MTA that announces support for UTF8SMTP, it is safe to use both the extensions to RFC 2822 that we have defined, plus whatever extensions we define for RFC 204[56]. That restriction to supportive environments would still remain even if our experimental protocol eventually joins the standards track, -- 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 May 22 11:08:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqVxw-0002J0-3Z; Tue, 22 May 2007 11:08:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqVxv-0002Iu-9N for ima@ietf.org; Tue, 22 May 2007 11:07:59 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqVxt-0003HU-MV for ima@ietf.org; Tue, 22 May 2007 11:07:59 -0400 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 4653074c.869b.a6 for ima@ietf.org; Tue, 22 May 2007 16:07:56 +0100 (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 l4MF7udn011037 for ; Tue, 22 May 2007 16:07:56 +0100 (BST) To: IMA Subject: Re: Please, read carefully! (Re: [EAI] Ascii user X sends mail (Re: Not a good reason? (Re: Minutes from Prague (fwd)))) References: <200705210651.l4L6pCam001152@siilo.fmi.fi> <6E167B2E6FFFFCF979514E40@B50854F0A9192E8EC6CDA126> <156C08F23D763EA64075D61F@[192.168.1.110]> Message-ID: Date: Tue, 22 May 2007 16:07:55 +0100 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: <156C08F23D763EA64075D61F@[192.168.1.110]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.9 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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, 21 May 2007 14:53:34 +0100, John C Klensin wrote: > (v) I suggest that sending mail that bears non-ASCII > addresses (or other UTF-8 header content) from a host that > cannot receive them -- or that is supported by relays that > cannot receive them -- is significantly more dumb than > (iii). I would not put it as dumb as that. If you are on vacation, and have access only to an ASCII MUA cum submission agent, you might nevertheless try to send mail to a utf-8 address, or send it From: your own utf-8 address. If it works well enough to get out and be relayed to a UTF8SMTP-capable agent somewhere, then it will probably go the whole way, and Good Luck to you. It if didn't, then don't expect the bounce to get back to you, but it was probably still worth the attempt. > In addition, we have always understood that delivery > of MDNs and similar messages is more fragile than delivery > of forward-pointing messages: the formal handoff of > responsibility and requirement that NDNs be generated if > needed for forward-pointing messages does not exist for > these reverse ones and, as Harald has reminded us, one must > not even attempt generate an NDN for a message that arrives > with a null return path. However, a DSN consists of three parts, of which the first is textual and says something like "We were unable to deliver your message ...". Even if the third part, containing the full original message as message/utf8smtp or whatever else we decide, has got garbled beyond recognition, the DSN is still of some value to you, and certainly to silently drop the whole DSN just because that third part could not be delivered intact is simply counter-productive. > > > For me, the situation here isn't that people can configure themselves > into conditions in which a EAI NDN or the equivalent cannot be > competently delivered. Nor do I believe that weak, non-conforming, > implementations will not get themselves into trouble and risk trashing > any mail that passes through them. I take both of those as given. > Instead, the question is how much more complex we should make the > protocol to ward off these cases or reduce the risk of them causing > problems. My personal opinion is "very little". YMMD. However, the cost of specifying application/message-utf8smtp rather than message/utf8smtp in our DSN draft is zero, and even the cost of specifying a (downgraded if necessary) message/rfc822 is not large given that we already propose to allow (and downgrade) MIME body-part headers such as Content-Description. Once you have written the code to do that, extending that code to do message/rfc822 is quite simple. >> Notice that key point between picture 1) and Picture 2) >> is that on picture 1 MSA announces UTF8SMTP >> and on picture 2 MSA do not announce UTF8SMTP to MUA. > > In case 2, the MUA MUST NOT send _any_ UTF-8 header material to the > submission server. If it does, it is so far outside the specification > that we are not obligated to specify, or even worry about, what happens > next. I think you will find that Kari's Case 2 sent the Subject RFC2047-encoded, for just the reaon you gave, and consequently its DSN was returned to the sender without problem. It was his Case 1 that got the DSN silently dropped. -- 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 May 23 01:28:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqjOA-0005EO-E1; Wed, 23 May 2007 01:27:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqjO8-0005EG-85 for ima@ietf.org; Wed, 23 May 2007 01:27:56 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqjO7-0007ai-Jj for ima@ietf.org; Wed, 23 May 2007 01:27:56 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HqjO0-0001Hd-Um for ima@ietf.org; Wed, 23 May 2007 07:27:48 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 May 2007 07:27:48 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 May 2007 07:27:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 23 May 2007 08:27:42 +0300 Lines: 178 Message-ID: <5dveekgldd.fsf@Hurtta06k.keh.iki.fi> References: <200705210651.l4L6pCam001152@siilo.fmi.fi> <6E167B2E6FFFFCF979514E40@B50854F0A9192E8EC6CDA126> <156C08F23D763EA64075D61F@[192.168.1.110]> 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: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.9 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: Kari Hurtta Subject: [EAI] Re: Please, read carefully! (Re: Ascii user X sends mail (Re: Not a good reason? (Re: Minutes from Prague (fwd)))) 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 What you missed ? You missed that on Picture 2 MUA is sending Subject with using MIME encoded words on Subject: header field. And there is no "upgrade in the network" anywhere. In all pictures MUA is assumed to be same. Changed items are: Picture 1 / 2 : MSA UTF8SMTP capable or not Picture 3 and 4 : Specification changed ( Picture 1 was where DSN on lost. On all other cases DSN is not lost. ) In all cases Subject what user types is Terveisiä täältä MUA selects is Subject (and message) send with UTF8SMTP or is it encoded with mime encoded words based on fact that is MSA announcing UTF8SMTP on it's EHLO reponse or not. There is no GUI on MUA where this is selected -- that is just protocol level negation. ( It is not reasonable for MUA try look when sending message that is message store for return path UTF8SMTP capable or not. I say that format decision is based only from SMTP negation with MSA. ) -- start quote ------------------------------------------------- 2) Case: MSA is not UTF8SMTP capable ( Sender X ) normal mail (E) [ MUA ] -------------> [ MSA ] 8BITMIME | 8BITMIME | v [ MTA ] | 8BITMIME v [ MTA ] DSN with message/rfc822 subpart | DSN ( F) | 8BITMIME v [ MTA ] DSN with message/rfc822 subpart | DSN | 8BITMIME | v [ MTA ] DSN is not dropped [ ] (G) [ ] | DSN | no 8BITMIME v [ MTA ] [ mailstore ] ( Sender X ) (E) Because MSA does not annouce UTF8SMTP MUA encodes subject Terveisiä täältä Therefore mail is just normal 8BITMIME message (F) Mail bounces. On generated DSN there is subpart with Content-type: message/rfc822 Content-Transfer-Encoding: 8bit (G) 8BITMIME to 7-bit gateway can convert DSN with that message/rfc822 subpart to: Content-type: message/rfc822 Content-Transfer-Encoding: 7bit Now Sender X is informed that recipient mailbox is full or recipient address is mistyped. On case 1 it was because MSA was UTf8SMTP capable and message/utf8smtp was used outside of "UTF8SMTP universe". -- end quote -------------------------------------------------- I suggest that readers look pictures again and not make conclusions from Harald Alvestrand's or John Klensin's messages. On both cases significant details was missed. John C Klensin writes: > --On Monday, May 21, 2007 1:44 PM +0200 Harald Tveit Alvestrand > wrote: > > > You are right - I did not read carefully enough. > > > > You have identified a message loss based on 3 assumptions: > > > > - Forward path (including sender) is UTF8SMTP capable > > - Reverse path is NOT UTF8SMTP capable > > - The RFC 2045 requirement is upheld. > > > > My source of confusion was because you used the term "ASCII > > user", which is defined in -framework as: > > > > An "ASCII user" (i) exclusively uses email addresses that > > contain > > ASCII characters only, and (ii) cannot generate recipient > > addresses that contain non-ASCII characters. > > > > I missed the fact that you said the sender was UTF8SMTP > > capable. > > > > That said, I still have trouble taking the last 2 of your 3 > > assumptions as given. > > Let me try to say that a little bit more strongly. > > It has been a property of the Internet's email system, at least since > we switched over from FTP, that one can configure oneself into silly > states in which mail won't go through and notifications will not get > through either. Even reverse-paths with explicit, forward-generated, > source-routes were not sufficient to prevent those cases. Some > examples of this: > > (i) Even in the all-ASCII (no EAI facilities) world, it is > possible to configure the MX records for a mail receiver so > that one of the intermediate MX hosts will refuse to accept > mail for the destination host or user. Cases of this will > continue to increase if "intermediate MX server must know > the current mailbox list at the destination site" plans > develop and race conditions occur. > > (v) I suggest that sending mail that bears non-ASCII > addresses (or other UTF-8 header content) from a host that > cannot receive them -- or that is supported by relays that > cannot receive them -- is significantly more dumb than > (iii). In addition, we have always understood that delivery > of MDNs and similar messages is more fragile than delivery > of forward-pointing messages: the formal handoff of > responsibility and requirement that NDNs be generated if > needed for forward-pointing messages does not exist for > these reverse ones and, as Harald has reminded us, one must > not even attempt generate an NDN for a message that arrives > with a null return path. > > > For me, the situation here isn't that people can configure themselves > into conditions in which a EAI NDN or the equivalent cannot be > competently delivered. Nor do I believe that weak, non-conforming, > implementations will not get themselves into trouble and risk trashing > any mail that passes through them. I take both of those as given. > Instead, the question is how much more complex we should make the > protocol to ward off these cases or reduce the risk of them causing > problems. My personal opinion is "very little". YMMD. > > Incidentally, for the specific case you listed in your note, unless I > still don't understand it (and I have read your notes several times > and very carefully), > > > Notice that key point between picture 1) and Picture 2) > > is that on picture 1 MSA announces UTF8SMTP > > and on picture 2 MSA do not announce UTF8SMTP to MUA. > > In case 2, the MUA MUST NOT send _any_ UTF-8 header material to the > submission server. If it does, it is so far outside the specification > that we are not obligated to specify, or even worry about, what > happens next. > > And, if the MUA sends non-ASCII header information in encoded words, > rather than UTF-8, and UTF-8 headers later appear anywhere in the > system prior to final delivery, then we have "upgrade in the network". > > What am I missing? > > john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed May 23 03:21:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqlAQ-0000RE-KJ; Wed, 23 May 2007 03:21:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqlAP-0000R8-K1 for ima@ietf.org; Wed, 23 May 2007 03:21:53 -0400 Received: from mail1.exchange.microsoft.com ([131.107.1.17] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqlAO-0000Ir-Bh for ima@ietf.org; Wed, 23 May 2007 03:21:53 -0400 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) by DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 23 May 2007 00:21:46 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.10]) by df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) with mapi; Wed, 23 May 2007 00:21:45 -0700 From: Yuri Inglikov To: "ima@ietf.org" Date: Wed, 23 May 2007 00:21:43 -0700 Thread-Topic: #1485: Choices Thread-Index: AcecIgXlC4SN9fmMQCGbXDR6gioS5wA5mB3Q Message-ID: References: <4651FECF.2080908@alvestrand.no> <200705220333.l4M3Xbi4005542@siilo.fmi.fi> In-Reply-To: <200705220333.l4M3Xbi4005542@siilo.fmi.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [EAI] Re: #1485: Choices 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 +1 for message/rfc822. I think that even if it leaks outside UTF8SMTP environment without downgrad= ing (which /normally/ should not happen), it is better if older application= s can at least partially interpret it / show most of the content than let t= hem deal with unknown subtype of a message/ (which they certainly unable to= ) or deal with unstructured blob attachment (application/utf8smtp or anythi= ng like that). I don't quite understand the hesitation to extend the meanin= g of message/rfc822 to allow UTF8 content in UTF8SMTP environment. Isn't it= very similar to allowing any other incompatible thing in such environment,= like address headers with UTF8 local parts? Any such extensions likely wil= l cause same problems if leaked outside UTF8SMTP environment. On the other = hand, most applications are robust enough to deal with unexpected / malform= ed MIME content and could be able to reasonably recover in most cases if fa= ced with UTF8 embedded message. Yuri Inglikov _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu May 24 10:36:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrEQ0-0003GA-BM; Thu, 24 May 2007 10:35:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrEPz-0003G1-0j for ima@ietf.org; Thu, 24 May 2007 10:35:55 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrEPy-00063g-Az for ima@ietf.org; Thu, 24 May 2007 10:35:55 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HrEPo-0007Nu-Ka for ima@ietf.org; Thu, 24 May 2007 16:35:44 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 May 2007 16:35:44 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 May 2007 16:35:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 24 May 2007 17:35:34 +0300 Lines: 173 Message-ID: <5dps4q9tmx.fsf_-_@Hurtta06k.keh.iki.fi> References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> 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: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: Kari Hurtta Subject: [EAI] #1483 smtp reply (Re: #1483) 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 Sat, 19 May 2007 07:51:10 +0100, Harald Tveit Alvestrand > wrote: > > Subject: [psg.com #1483] AutoReply: SMTPEXT 2.7: Non-ASCII in > > response texts > > > - Just send non-ASCII > > - Send non-ASCII, but only in email addresses that were specified by the > > client > > - Send non-ASCII, but only if client enables that feature by a special > > command > > - Send ASCII only > > Certainly the last case is wrong. > Certainly, if the response is being sent in a DSN, then non-ASCII is > in order. > Certainly, if the original message contained non-ASCII, the originator > can be presumed to understanda non-ASCII responses. > We seem to have been arguing against "special command's (we got rid of > Header-Type and HDR=UTF8). > > So I think either Case 1 or Case 2 are the only ppssibilites (I prefer > Case 1) Because document is SMTPEXT, I think that response is smtp reply and not a response which is sent in a DSN. Of course also smtp reply can be copied to DSN ultimately. Problem is that when smtp server announce UTF8SMTP this does not indicate that smtp client supports UTF8SMTP. Therefore sending UTF-8 to unprepared smtp client is risky. On other hand this UTF8SMTP extension tries move smtp to UTF-8 so limiting smtp replies to UTF-8 does not show very wise. Therefore alternatives - Send non-ASCII, but only in email addresses that were specified by the client - Send non-ASCII, but only if client enables that feature by a special command are these which make sense. This case "special command" implies nothing about message. It only tells capabilities of smtp client. One of my scenarios was EHLO xxx 250-server.example 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250 UTF8SMTP 250 HELP EXPN root 250 2.1.5 Ville Keränen In these case EXPN response include phrase (fullname) and mailbox with UTF-8. Danger is that there is nothing which indicates that client supports UTF-8. Also usually (althoug smtp does not require it) mailbox is often repeated on smtp reply. That case it includes UTF-8 only if original command included UTF-8. Another theoretical example was MAIL FROM: 250 OK RCPT TO: 251 is new address, will forward ( client crashes ?) However 251 and 551 response codes (= new address) are not usually used. I was following suggestion. In that suggestion "special command" is part of argument in MAIL, EXPN and VRFY commands. (On other hand to enable UTF-8 replies to whole smtp session special command before MAIL command is required -- assuming that I interpreted Klensin correctly :-) ) ---------------------------------------------------------------------------------- To: Jiankang YAO , Wei MAO Date: Fri, 18 May 2007 08:57:36 +0300 (EEST) Subject: draft-ietf-eai-smtpext-05.txt: Revised text for UTF-8 reply Revised text for UTF-8 reply (with taking account Klensin's comments.) == 2.1. Framework for the Internationalization Extension | 4. One optional parameter, => | 4. Optional parameter, Addition: X. Optional parameter, UTF8REPLY, is added to SMTP MAIL, VRFY and EXPN commands. Paramater UTF8REPLY have no values. Parameter indicates SMTP cleant accepts UTF-8 on replies of SMTP commands. Specially this allows to use UTF-8 on mailboxes which occurs on replies. ( Now I ignore change for "9. The maximum length" text. ) == 2.2. The UTF8SMTP Extension Additions: | SMTP client following this specification MUST accept UTF-8 | on replies of SMTP commands. However on SMTP server SHOULD | not use UTF-8 on replies, if SMTP client do not ask UTF-8 | replies. Some replies includes mailbox, but usually most | of replies do not require that mailbox is include to reply | and therefore UTF-8 is not needed. | | UTF8REPLY parameter on MAIL, VRFY and EXPN commands tells | that SMTP client is prepared for UTF-8 on SMTP replies. | | VERIFY (VRFY) command syntax is changed to: | | "VRFY" [SP "UTF8REPLY"] SP String CRLF | | EXPAND (EXPN) command syntax is changed to: | | EXPN" [SP "UTF8REPLY"] SP String CRLF | | "UTF8REPLY" parameter is added to . | This parameter do not have value. | | If SMTP reply requires UTF-8, but SMTP client | is not used "UTF8REPLY" parameter on any command, | response code "550" is used, defined in [RFC2821], | meaning "mailbox unavailable". For VERIFY (VRFY) | and EXPAND (EXPN) commands also response code "252" | can be used, defined in [RFC2821], meaning "Cannot VRFY user, | but will accept message and attempt delivery". If enhanced | mail system status codes [RFC3463] is used, the response code | should be "5.6.y" or "2.6.y" [SMTP-codes], meaning that | "UTF-8 reply required, but UTF8REPLY parameter not used.". | | [[anchor: REMOVE THIS: IANA please assign the proper error codes for | "5.6.y" and "2.6.y".]] | | "UTF8REPLY" parameter in MAIL command command | enables UTF-8 replies for SMTP commands on that mail transaction. | "UTF8REPLY" on VERIFY (VRFY) and EXPAND (EXPN) enables UTF-8 | for that command only. == 6. IANA Considerations Addition: | IANA is requested to assign the proper error codes "5.6.y" and "2.6.y" | for this specification based on [SMTP-codes]. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri May 25 00:41:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrRce-000369-DV; Fri, 25 May 2007 00:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrRcd-0002xQ-13 for ima@ietf.org; Fri, 25 May 2007 00:41:51 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrRcc-0002MY-JA for ima@ietf.org; Fri, 25 May 2007 00:41:51 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HrRcb-0006NP-15 for ima@ietf.org; Fri, 25 May 2007 06:41:49 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 May 2007 06:41:49 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 May 2007 06:41:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 25 May 2007 07:41:36 +0300 Lines: 97 Message-ID: <5dejl5cy67.fsf@Hurtta06k.keh.iki.fi> References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> <5dps4q9tmx.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: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Kari Hurtta Subject: [EAI] Re: #1483 smtp reply (Re: #1483) 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 There is bad typo on my message. Kari Hurtta writes in gmane.ietf.ima: > "Charles Lindsey" writes in gmane.ietf.ima: > > > On Sat, 19 May 2007 07:51:10 +0100, Harald Tveit Alvestrand > > wrote: > > > > Subject: [psg.com #1483] AutoReply: SMTPEXT 2.7: Non-ASCII in > > > response texts > > > > > - Just send non-ASCII > > > - Send non-ASCII, but only in email addresses that were specified by the > > > client > > > - Send non-ASCII, but only if client enables that feature by a special > > > command > > > - Send ASCII only > > > > Certainly the last case is wrong. > > Certainly, if the response is being sent in a DSN, then non-ASCII is > > in order. > > Certainly, if the original message contained non-ASCII, the originator > > can be presumed to understanda non-ASCII responses. > > We seem to have been arguing against "special command's (we got rid of > > Header-Type and HDR=UTF8). > > > > So I think either Case 1 or Case 2 are the only ppssibilites (I prefer > > Case 1) > > Because document is SMTPEXT, I think that response is smtp reply and > not a response which is sent in a DSN. Of course also smtp reply > can be copied to DSN ultimately. > > > Problem is that when smtp server announce UTF8SMTP this does not > indicate that smtp client supports UTF8SMTP. Therefore sending > UTF-8 to unprepared smtp client is risky. > > > On other hand this UTF8SMTP extension tries move smtp to UTF-8 > so limiting smtp replies to UTF-8 does not show very wise. There is typo. That should be: On other hand this UTF8SMTP extension tries move smtp to UTF-8 so limiting smtp replies to ASCII does not show very wise. > Therefore alternatives > - Send non-ASCII, but only in email addresses that were specified by the > client > - Send non-ASCII, but only if client enables that feature by a special > command > > are these which make sense. > > > This case "special command" implies nothing about message. It only > tells capabilities of smtp client. > > > One of my scenarios was > > EHLO xxx > 250-server.example > 250-ENHANCEDSTATUSCODES > 250-8BITMIME > 250-DSN > 250 UTF8SMTP > 250 HELP > EXPN root > 250 2.1.5 Ville Keränen > > > In these case EXPN response include phrase (fullname) and mailbox with UTF-8. > Danger is that there is nothing which indicates that client supports > UTF-8. > > Also usually (althoug smtp does not require it) mailbox is > often repeated on smtp reply. That case it includes UTF-8 only > if original command included UTF-8. > > > Another theoretical example was > > MAIL FROM: > 250 OK > RCPT TO: > 251 is new address, will forward > > ( client crashes ?) > > However 251 and 551 response codes (= new address) are not usually > used. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun May 27 11:42:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsKtR-00057j-OA; Sun, 27 May 2007 11:42:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsKtQ-00057d-Sr for ima@ietf.org; Sun, 27 May 2007 11:42:52 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsKtQ-0004V8-9H for ima@ietf.org; Sun, 27 May 2007 11:42:52 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HsKtF-0002uL-Pk for ima@ietf.org; Sun, 27 May 2007 17:42:41 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 May 2007 17:42:41 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 27 May 2007 17:42:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 27 May 2007 18:42:26 +0300 Lines: 137 Message-ID: <5dfy5ib7dp.fsf@Hurtta06k.keh.iki.fi> References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: Kari Hurtta Subject: [EAI] #1485: Choice of body part for transport of UTF8SMTP messages 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 writes in gmane.ietf.ima: > Subject: [psg.com #1485]: UTF8HDR 4.6/DSN: Choice of body part for > transport of UTF8SMTP messages > > The choice of the body part to transport UTF8SMTP messages in a message > has proved controversial. > Suggestions include: > > - message/utf8 (inconsistent with certain statements in the MIME RFCs) > - application/utf8smtp (stylistically questionable) > - message/rfc822 (incompatible with existing definition) > > A decision needs to be made. I prefer UTF8SMTP messages labeled as message/rfc822 on UTF8SMTP environment and then downgraded to RFC 2822 messages when then leave UTF8SMTP environment. On downgrading there is two different cases A) bounce/reject is available B) bounce/reject is not available Case A is when downgrading is done by UTF8SMTP gateway on smtp when envelope sender is not <>. Case B is when downgrading is done after delivery (for example on IMAP or POP server) or when downgrading is done by UTF8SMTP gateway on smtp when envelope sender is <>. In case A if downgrading of attached message (with type message/rfc822) fails, enclosed message is rejected or bounced (NDN generated). In case B is it is just better leave out data what is not downgradeable (for example if there is no alternative address for some address on header) or on extreme case left out whole message/rfc822 body part. ( In case B also some other options exists, but they are better discussed when downgrading document is on subject. Also if embedded message is not downgradeable, one option is do some sort encapsulation on both cases A and B ) For why I prefer message/rfc822 I have mentioned these reasons already: When working group was decided that there is no need labeling for UTF8SMTP messages, that quite clearly follow that UTF8SMTP messages does not need new label (ie. message/utf8 type) when they are attached to another message. When whole message is not need labeling on UTF8SMTP case (ie no ESMTP paramater), there is no need also different kind labeling if message is attached to another message. That makes "message/rfc822" just mean "mail message". And consistent that "message/rfc822" is just that type what occurs inside of DATA on smtp. Actually "message/rfc822" is not mean to be only mail message, but superset of it (rfc 2046): It should be noted that, despite the use of the numbers "822", a "message/rfc822" entity isn't restricted to material in strict conformance to RFC822, nor are the semantics of "message/rfc822" objects restricted to the semantics defined in RFC822. More specifically, a "message/rfc822" message could well be a News article or a MIME message. If there is reason why "message/rfc822" can not be used to mean any mail message on UTF8SMTP universe, same problems are also on top level. For example if there is some problems for IMAP on UTF8SMTP universe, when UTF8SMTP message is attaches as "message/rfc822", same problems also aply to top level message. This issue have subject UTF8HDR 4.6. That chapter do not mention MIME type of UTF8SMTP message at all. Instead that chapter says: the object defined in [EAI-dsn] is intended to be transportable as part of an ordinary [RFC2822] message. That implies that UTF8SMTP messages transported inside of messages are not downgraded. I prefer that they are downgraded. That is important when this MIME type is just used for forwarding. On situation where UTF8SMTP messages start appear is when MUA and MSA supports UTF8SMTP, and just non-ascii subject is used. If embedded messages are downgraded when message is forwarded outside of UTF8SMTP environment, that does not cause surprises. If downgrading is not done (and encapsulation is done instead), recipient get different situation depending was just UTF8SMTP MSA+MUA used. That is: End result outside of UTF8SMTP environment should be same on following cases when non ascii subject is typed: 1) MUA sends ordinary MIME message (non UTF8SMTP message) 2) MUA sends UTF8SMTP message On both cases end result outside of UTF8SMTP environment should be ordinary MIME message with MIME encoded words on subject. And that should happend even when this message leaves UTF8SMTP environment inside of another message. Perhaps that can be say also on following way: "Fully downgradeable UTF8SMTP messages should be downgraded (and not encapsulated) when they leave UTF8SMTP environment. And that does not depend is message stand alone or is it embedded inside of another message." MIME type of UTF8SMTP message is mentioned on chapter 4.2 instead: In all those header fields, Observe that such Content-Type and other header fields may be found both amongst the top-level fields of a message and also within multiparts; and also that a complete message conforming to this document may now appear as a message/rfc822 (in both cases, subject to downgrade when that is necessary) application/utf8smtp have some values on situations where message is not downgradeable. In that case that type can be used for encapsulation, but I do not recommended it for general use. message/utf8 is bad if UTF8SMTP content is not downgraded (and retyped as message/rfc822) when message leaves UTF8SMTP environment. Some reasons I have discussed on my messages with subjects - Ascii user X sends mail - UTF8SMTP / 8BITMIME / ASCII -universe amd message/utf8smtp / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue May 29 13:02:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht555-00083S-QG; Tue, 29 May 2007 13:01:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht554-00083M-PE for ima@ietf.org; Tue, 29 May 2007 13:01:58 -0400 Received: from mail1.exchange.microsoft.com ([131.107.1.17] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht554-0007iT-7U for ima@ietf.org; Tue, 29 May 2007 13:01:58 -0400 Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.54.216) by DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 29 May 2007 10:01:57 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.10]) by df-bhd-01.exchange.corp.microsoft.com ([157.54.54.216]) with mapi; Tue, 29 May 2007 10:01:57 -0700 From: Yuri Inglikov To: Kari Hurtta , "ima@ietf.org" Date: Tue, 29 May 2007 10:02:07 -0700 Subject: RE: [EAI] #1485: Choice of body part for transport of UTF8SMTP messages Thread-Topic: [EAI] #1485: Choice of body part for transport of UTF8SMTP messages Thread-Index: AcegdbNbwQ2yqYMAQ5KhCU+R8FH9dwBnCULQ Message-ID: References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> <5dfy5ib7dp.fsf@Hurtta06k.keh.iki.fi> In-Reply-To: <5dfy5ib7dp.fsf@Hurtta06k.keh.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 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 I like the idea of changing labeling from message/rfc822 to something like = application/utf8smtp as a last resort if message is not downgradeable and c= annot be bounced. > -----Original Message----- > From: Kari Hurtta [mailto:hurtta+gmane@siilo.fmi.fi] > Sent: Sunday, May 27, 2007 8:42 AM > To: ima@ietf.org > Cc: Kari Hurtta > Subject: [EAI] #1485: Choice of body part for transport of UTF8SMTP > messages > > Harald Tveit Alvestrand writes in > gmane.ietf.ima: > > > Subject: [psg.com #1485]: UTF8HDR 4.6/DSN: Choice of body part for > > transport of UTF8SMTP messages > > > > The choice of the body part to transport UTF8SMTP messages in a > message > > has proved controversial. > > Suggestions include: > > > > - message/utf8 (inconsistent with certain statements in the MIME > RFCs) > > - application/utf8smtp (stylistically questionable) > > - message/rfc822 (incompatible with existing definition) > > > > A decision needs to be made. > > I prefer > UTF8SMTP messages labeled as message/rfc822 on UTF8SMTP environment > and then downgraded to RFC 2822 messages when then leave UTF8SMTP > environment. > > > On downgrading there is two different cases > A) bounce/reject is available > B) bounce/reject is not available > > Case A is when downgrading is done by UTF8SMTP gateway on smtp when > envelope > sender is not <>. > > Case B is when downgrading is done after delivery (for example on IMAP > or > POP server) or when downgrading is done by UTF8SMTP gateway on smtp > when > envelope sender is <>. > > In case A if downgrading of attached message (with type message/rfc822) > fails, enclosed message is rejected or bounced (NDN generated). > > In case B is it is just better leave out data what is not downgradeable > (for example if there is no alternative address for some address on > header) > or on extreme case left out whole message/rfc822 body part. > > > ( In case B also some other options exists, but they are better > discussed > when downgrading document is on subject. Also if embedded message is > not > downgradeable, one option is do some sort encapsulation on both > cases A and B ) > > > For why I prefer message/rfc822 I have mentioned these reasons already: > > When working group was decided that there is no need labeling > for UTF8SMTP messages, that quite clearly follow that UTF8SMTP > messages does not need new label (ie. message/utf8 type) when > they are attached to another message. > > When whole message is not need labeling on UTF8SMTP case (ie no > ESMTP > paramater), there is no need also different kind labeling if > message is attached to another message. > > That makes "message/rfc822" just mean "mail message". And consistent > that "message/rfc822" is just that type what occurs inside of DATA > on smtp. > > Actually "message/rfc822" is not mean to be only mail message, > but superset of it (rfc 2046): > > It should be noted that, despite the use of the numbers "822", a > "message/rfc822" entity isn't restricted to material in strict > conformance to RFC822, nor are the semantics of "message/rfc822" > objects restricted to the semantics defined in RFC822. More > specifically, a "message/rfc822" message could well be a News > article > or a MIME message. > > > If there is reason why "message/rfc822" can not be used to > mean any mail message on UTF8SMTP universe, same problems are > also on top level. > > For example if there is some problems for IMAP on UTF8SMTP universe, > when UTF8SMTP message is attaches as "message/rfc822", same problems > also aply to top level message. > > > This issue have subject UTF8HDR 4.6. That chapter do not mention > MIME type of UTF8SMTP message at all. Instead that chapter says: > > the object defined in [EAI-dsn] is intended to be transportable as > part of an ordinary [RFC2822] message. > > That implies that UTF8SMTP messages transported inside of messages are > not > downgraded. I prefer that they are downgraded. That is important when > this MIME type is just used for forwarding. > > On situation where UTF8SMTP messages start appear is when MUA and MSA > supports > UTF8SMTP, and just non-ascii subject is used. If embedded messages are > downgraded when message is forwarded outside of UTF8SMTP environment, > that > does not cause surprises. If downgrading is not done (and > encapsulation is > done instead), recipient get different situation depending was just > UTF8SMTP > MSA+MUA used. > > That is: End result outside of UTF8SMTP environment should be same on > following cases when non ascii subject is typed: > 1) MUA sends ordinary MIME message (non UTF8SMTP message) > 2) MUA sends UTF8SMTP message > On both cases end result outside of UTF8SMTP environment should be > ordinary > MIME message with MIME encoded words on subject. And that should > happend > even when this message leaves UTF8SMTP environment inside of another > message. > > Perhaps that can be say also on following way: "Fully downgradeable > UTF8SMTP > messages should be downgraded (and not encapsulated) when they leave > UTF8SMTP > environment. And that does not depend is message stand alone or is it > embedded > inside of another message." > > > > MIME type of UTF8SMTP message is mentioned on chapter 4.2 instead: > > In all those header fields, Observe that such Content-Type and other > header fields may be found both amongst the top-level fields of a > message and also within multiparts; and also that a complete message > conforming to this document may now appear as a message/rfc822 (in > both cases, subject to downgrade when that is necessary) > > > > application/utf8smtp have some values on situations where message is > not downgradeable. In that case that type can be used for > encapsulation, > but I do not recommended it for general use. > > > message/utf8 is bad if UTF8SMTP content is not downgraded (and retyped > as message/rfc822) when message leaves UTF8SMTP environment. Some > reasons > I have discussed on my messages with subjects > - Ascii user X sends mail > - UTF8SMTP / 8BITMIME / ASCII -universe amd message/utf8smtp > > > / 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 Wed May 30 11:56:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtQXD-0004Pl-KK; Wed, 30 May 2007 11:56:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtQXC-0004Pf-Kn for ima@ietf.org; Wed, 30 May 2007 11:56:26 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtQXB-0006YU-7X for ima@ietf.org; Wed, 30 May 2007 11:56:26 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HtQWx-0005HT-MJ for ima@ietf.org; Wed, 30 May 2007 17:56:12 +0200 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 May 2007 17:56:11 +0200 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 May 2007 17:56:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 30 May 2007 18:56:01 +0300 Lines: 43 Message-ID: <5dps4i9uge.fsf@Hurtta06k.keh.iki.fi> References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Kari Hurtta Subject: [EAI] #1487: Does this specification update MIME? 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 writes in gmane.ietf.ima: > Subject: [psg.com #1487] AutoReply: UTF8HDR 4.2: Does this > specification update MIME? > > As written, section 4.2 updates the MIME specification by allowing UTF-8 > in MIME headers. > > The headers do not say that the MIME RFC is updated, and we need a > proper descritption of what it means for an experimental RFC to "update" > a standards-track one. Also section 4.3 updates RFC 2822 specification by allowing UTF-8 on addresses and other places. Yes, RFC 2231 changes mime parameter syntax and encoded word syntax. And it updates RFC 2045, 2047, 2183. So perhaps that is similar situation. These syntax changes are limited to UTF8SMTP environment. There is similarity with 8BITMIME. 8BITMIME also is limited and changes syntax. But here RFC 1652 does not update RFC 821 or 822 either. So if this correspond then these UTF8SMTP related specifications does not need update RFC 2821, 2822, 2045, and so on either. I think there can be found reasoning because of this that headers do not need say that the MIME, MAIL or SMTP RFC are updated. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu May 31 09:49:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htl1y-0007SR-Ti; Thu, 31 May 2007 09:49:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htl1x-0007SL-OS for ima@ietf.org; Thu, 31 May 2007 09:49:33 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htl1w-0008Ev-5Q for ima@ietf.org; Thu, 31 May 2007 09:49:33 -0400 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 465ed26a.5cd2.334 for ima@ietf.org; Thu, 31 May 2007 14:49:30 +0100 (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 l4VDnTE7029007 for ; Thu, 31 May 2007 14:49:31 +0100 (BST) To: IMA Subject: Re: [EAI] #1485 UTF8HDR 4.6/DSN: Choice of body part for messages References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: Date: Thu, 31 May 2007 14:49:28 +0100 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 Mon, 21 May 2007 14:50:56 +0100, Charles Lindsey wrote: > On Sat, 19 May 2007 07:51:10 +0100, Harald Tveit Alvestrand > wrote: > >> ------------ Forwarded Message ------------ >> Subject: [psg.com #1485]: UTF8HDR 4.6/DSN: Choice of body part for >> transport of UTF8SMTP messages >> >> The choice of the body part to transport UTF8SMTP messages in a message >> has proved controversial. > > But utf8headers-05.txt is fine with me as it stands, and it should not > be altered until we have decided on this issue in connection with DSN. > May I reiterate that it would be quite improper to issue a further draft of the utf8headers document removing the possibility of using message/rfc822 to tranport a UTF8SMTP Message (within the UTF8SMTP universe) until this issue (#1485) has been resolved. I note that there is now an increasing recognition within the WG that message/rfc822 is the proper method to do this. Moreover, both Kari and myself have put forward technical arguments (as opposed to gut reactions) as to why message/utf8smtp is not suited to this purpose (whether within DSNs or otherwise), and NOBODY has yet even attempted to refute those arguments. -- 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 May 31 13:13:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtoCs-0005wp-7A; Thu, 31 May 2007 13:13:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtoCr-0005wk-E0 for ima@ietf.org; Thu, 31 May 2007 13:13:01 -0400 Received: from smtp6.pp.htv.fi ([213.243.153.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtoCn-0004q2-W6 for ima@ietf.org; Thu, 31 May 2007 13:13:01 -0400 Received: from Hurtta06k.keh.iki.fi (cs130027.pp.htv.fi [213.243.130.27]) by smtp6.pp.htv.fi (Postfix) with ESMTP id A40505BC066; Thu, 31 May 2007 20:12:56 +0300 (EEST) Received: from Hurtta06k.keh.iki.fi (localhost [127.0.0.1]) by Hurtta06k.keh.iki.fi (8.13.4/8.13.4/Debian-3ubuntu0.1) with ESMTP id l4VHCu1U012506; Thu, 31 May 2007 20:12:56 +0300 Received: (from hurtta@localhost) by Hurtta06k.keh.iki.fi (8.13.4/8.13.4/Submit) id l4VHCswL012505; Thu, 31 May 2007 20:12:54 +0300 Message-Id: <200705311712.l4VHCswL012505@Hurtta06k.keh.iki.fi> X-Authentication-Warning: Hurtta06k.keh.iki.fi: hurtta set sender to using -f In-Reply-To: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> To: ima@ietf.org Date: Thu, 31 May 2007 20:12:54 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version ME+ 2.5 PLalpha14+] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ELM1180631574-11914-0_" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 662324ecda47446db09bfd0a0092c4ba Cc: Kari Hurtta Subject: [EAI] Re: Issues open against SMTPEXT and UTF8HDR documents 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 --ELM1180631574-11914-0_ Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Harald Tveit Alvestrand : > But we have to get these issues settled, and make sure we have raised all > significant issues as soon as possible, if we're going to catch up with any > reasonable schedule. > > Below are the tickets created for the issues we know. > When following up, please use the following subject line convention: > > - Subject: #1483 for addressing issue 1483 > - Subject: ISSUE:
: for raising a new > issue. > > The chairs will enter issues raised with the ISSUE: convention into the > tracker if they deem the issue well defined and important; if they are > unsure of its importance, they may ask for a second before tracking it. > > Grammar and spelling notes should go directly to the editors. > > PLEASE raise issues against these 2 documents as soon as possible; > preferably before May 23 (Wednesday of next week). I posted May 19 following issues to you,. Nothing hear about these. Are these all found as unimportant or was they lost? ISSUE: UTF8HDR 4.4: should include ISSUE: UTF8HDR 4.3/4.5: Message-ID restriction not descibed ISSUE: SMTPEXT 2.6: Reply code so that downgrade is not possible ISSUE: SMTPEXT 2.4: Redefining of RCPT TO and MAIL FROM commands (ABNF grammar) ISSUE: SMTPEXT 2.7.3: syntax ISSUE: UTF8HDR 4.5: and on trace field syntax ISSUE: UTF8HDR 4.4: must always include "<" and ">" characters ISSUE: UTF8HDR 4.3: Incremental alternatives (ABNF grammar) ISSUE: UTF8HDR 4.2: Extending MIME (ABNF grammar) ISSUE: UTF8HDR 3: UTF-8 character defination ISSUE: UTF8HDR 3: "header" versus "header field" ISSUE: UTF8HDR 4.2: Including Content-Description to picture (grammar) These are included to that message for reference. Most of these I have earlier sent to authors of drafts. Today I got message Abel Yang which included pointer to new unpublished draft-ietf-eai-utf8headers-06.txt. That message was addressed also to Randall Gellens and Alexey Melnikov which was also commented draft and then also to eai-dt@alvestrand.no address. That address seems to be some members-only mailing list (I got bounce from Mailman when I used group reply.) Apparently these drafts are discussed also on some other mailing lists than on WG mailing list. Anyway draft-ietf-eai-utf8headers-06.txt seems have fixed some of these issues: ISSUE: UTF8HDR 4.4: should include seems to have fixed ISSUE: UTF8HDR 4.3/4.5: Message-ID restriction not descibed not handled ISSUE: UTF8HDR 4.5: and on trace field syntax not handled ISSUE: UTF8HDR 4.4: must always include "<" and ">" characters not handled ISSUE: UTF8HDR 4.3: Incremental alternatives (ABNF grammar) have some changes, but there is some problems still ISSUE: UTF8HDR 4.2: Extending MIME (ABNF grammar) fixed, except some old stray text is left behind ISSUE: UTF8HDR 3: UTF-8 character defination have some changes, but may require still touch ISSUE: UTF8HDR 3: "header" versus "header field" have some changes, but "header field" is not used ISSUE: UTF8HDR 4.2: Including Content-Description to picture (grammar) not handled / Kari Hurtta --ELM1180631574-11914-0_ Content-Transfer-Encoding: 7bit Content-Type: message/rfc822 From: Kari Hurtta To: Harald Tveit Alvestrand cc: Kari Hurtta Subject: ISSUE: UTF8HDR 4.2: Including Content-Description to picture (grammar) References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Date: 19 May 2007 10:11:10 +0300 In-Reply-To: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: <5dmz01ffu9.fsf@Hurtta06k.keh.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii This is related to UTF8HDR 4.2: List MIME headers that are modified? but actual question is that MIME headers are not defined with RFC 2822 grammar and it is unclear that extending of RFC 2822 gives extended syntax for to that MIME header. RFC 2045 defines Content-Description as description := "Content-Description" ":" *text That is clearly unstructured. That correspond RFC 822 defination optional-field = ... / "Subject" ":" *text However that is "utext" on RFC 2822: subject = "Subject:" unstructured CRLF unstructured = *([FWS] utext) [FWS] So it is little unclear is chapter "4.3. Syntax extensions to RFC 2822" redefination of "utext" in force here? Parhaps: " To able to use UTF-8 on Content-Description -header field, following " syntax is used " " description = "Content-Description:" unstructured CRLF " " syntax is extended on next chapter to allow UTF-8 characters " on header fields. --ELM1180631574-11914-0_ Content-Transfer-Encoding: 7bit Content-Type: message/rfc822 From: Kari Hurtta To: Harald Tveit Alvestrand cc: Kari Hurtta Subject: ISSUE: UTF8HDR 3: "header" versus "header field" References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Date: 19 May 2007 11:19:09 +0300 In-Reply-To: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: <5dirapfcoy.fsf@Hurtta06k.keh.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii | In this document, even ordinarg ASCII characters are UTF-8 characters | if the bodies of those headers contain s. I found that somewhat strange defination. Anyway it is better to use "header field". So perhaps: " A plain ASCII string is also a valid UTF-8 string, see [RFC3629]. " In this document, ordinary ASCII characters are UTF-8 characters " if the bodies of those header fields contain s. But that is still strange :-( Term "header" there is problem that "header" is ambiguous. draft-resnick-2822upd-01.txt uses terms "header field" and "header section". --ELM1180631574-11914-0_ Content-Transfer-Encoding: 7bit Content-Type: message/rfc822 Content-Description: From: Kari Hurtta To: Harald Tveit Alvestrand cc: Kari Hurtta Subject: ISSUE: UTF8HDR 3: UTF-8 character defination References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Date: 19 May 2007 11:25:15 +0300 In-Reply-To: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: <5dejldfces.fsf@Hurtta06k.keh.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii | In this document, even ordinarg ASCII characters are UTF-8 characters | if the bodies of those headers contain s. RFC3629 notes: | UTF-8, the object of this memo, has a one-octet encoding unit. It | uses all bits of an octet, but has the quality of preserving the full | US-ASCII [US-ASCII] range: US-ASCII characters are encoded in one | octet having the normal US-ASCII value, and any octet with such a | value can only stand for a US-ASCII character, and nothing else. Therefore ASCII characters are also UTF-8 characters even when there is no any s. / Kari Hurtta --ELM1180631574-11914-0_ Content-Transfer-Encoding: 7bit Content-Type: message/rfc822 From: Kari Hurtta To: Harald Tveit Alvestrand cc: Kari Hurtta Subject: ISSUE: UTF8HDR 4.2: Extending MIME (ABNF grammar) References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Date: 19 May 2007 11:38:58 +0300 In-Reply-To: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: <5dabw1fbrx.fsf@Hurtta06k.keh.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii | The syntax of , as defined in [RFC2045] is | | value = token / utf8-quoted-string | | To be able to use UTF-8 characters in MIME headers, | syntax is extended as | | qcontent = utf8-qtext / utf8-quoted-pair That is strange. Defination on [RFC2045] was value = token / quoted-string So perhaps it is mean " To be able to use UTF-8 characters in MIME header field " paramerer values, the syntax of , as defined in [RFC2045], " is extended as " " value =/ utf8-quoted-string " " is defined on chapter --ELM1180631574-11914-0_ Content-Transfer-Encoding: 7bit Content-Type: message/rfc822 From: Kari Hurtta To: Harald Tveit Alvestrand cc: Kari Hurtta Subject: ISSUE: UTF8HDR 4.3: Incremental alternatives (ABNF grammar) References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Date: 19 May 2007 11:48:34 +0300 In-Reply-To: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: <5d646pfbbx.fsf@Hurtta06k.keh.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii | ctext /= NO-WS-CTL / ; all of except | %d33-39 / ; SP, HTAB, "(", ")" | %d42-91 / ; and "\" | %d93-126 / | UTF8-xtra-char Is that mean just add terms to ? Then it is "=/" and not "/=". RFC 4234: | 3.3. Incremental Alternatives: Rule1 =/ Rule2 Also then existing alternatives need not need to be repeated: " ctext =/ UTF8-xtra-char Also | utext = NO-WS-CTL / ; Non white space controls | %d33-126 / ; The rest of US-ASCII | UTF8-xtra-char can be changed to " utext =/ UTF8-xtra-char --ELM1180631574-11914-0_ Content-Transfer-Encoding: 7bit Content-Type: message/rfc822 From: Kari Hurtta To: Harald Tveit Alvestrand Subject: ISSUE: UTF8HDR 4.4: must always include "<" and ">" characters cc: Kari Hurtta References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Date: 19 May 2007 11:56:17 +0300 In-Reply-To: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: <5d1whdfaz2.fsf@Hurtta06k.keh.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii | angle-addr = [CFWS] "<" utf8-addr-spec">" [CFWS] / \ | [CFWS] "<" utf8-addr-spec ">" [CFWS] / \ | [CFWS] utf8-addr-spec [CFWS] I lost track where that last "[CFWS] utf8-addr-spec [CFWS]" is needed. already includes is used on name-addr = [display-name] angle-addr angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr Anyway that produces VERY strange production: may be [display-name] [CFWS] utf8-addr-spec [CFWS] This definately is NOT what is wanted. must not include productions which do not produce "<" and ">" characters ! | Below list a few possible representation as example. ... | non-ASCII@non-ASCII | ; without DISPLAY_NAME and quoted string | ; UTF8SMTP but no ALT-ADDRESS parameter provided, | ; message will bounce if UTF8SMTP extension is not supported This was already allowed on production so addition of this to does not make sense. | mailbox = name-addr / addr-spec / utf8-addr-spec --ELM1180631574-11914-0_ Content-Transfer-Encoding: 7bit Content-Type: message/rfc822 From: Kari Hurtta To: Harald Tveit Alvestrand cc: Kari Hurtta Subject: ISSUE: UTF8HDR 4.5: and on trace field syntax References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Date: 19 May 2007 12:04:06 +0300 In-Reply-To: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: <5dwsz5dw1l.fsf@Hurtta06k.keh.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Only other place where is used is item-value = 1*angle-addr / addr-spec / atom / domain / msg-id Because addr-spec does not allow UTF-8 so there perhaps utf8-addr-spec is needed, but it is better to do with " item-value =/ utf8-addr-spec ( However draft-resnick-2822upd-01.txt updates Received: -syntax as: received = "Received:" *received-token ";" date-time CRLF received-token = word / angle-addr / addr-spec / domain so perhaps actually it is " received-token =/ utf8-addr-spec if RFC 2822 update is published before that document. [ I am not checked however. ] ) --ELM1180631574-11914-0_ Content-Transfer-Encoding: 7bit Content-Type: message/rfc822 From: Kari Hurtta To: Harald Tveit Alvestrand cc: Kari Hurtta Subject: ISSUE: SMTPEXT 2.7.3: syntax References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Date: 19 May 2007 12:26:42 +0300 In-Reply-To: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: <5dsl9tduzx.fsf@Hurtta06k.keh.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii draft-ietf-eai-smtpext-05.txt: | uFor = "FOR" FWS 1*( uPath / uMailbox ) CFWS | ; Replaces For in the section 4.4 of [RFC2821] | ; uPath is defined in section 2.4 of this document Compare to draft-klensin-rfc2821bis-04.txt: | For = CFWS "FOR" 1*( FWS ( Path / Mailbox )) I think that this is more correct placement of So that makes it to be: " uFor = "FOR" 1*( FWS (uPath / uMailbox) ) CFWS If RFC 2822 update is published before that document, then it is " uFor = CFWS "FOR" 1*( FWS (uPath / uMailbox) ) --ELM1180631574-11914-0_ Content-Transfer-Encoding: 7bit Content-Type: message/rfc822 From: Kari Hurtta To: Harald Tveit Alvestrand cc: Kari Hurtta Subject: ISSUE: SMTPEXT 2.4: Redefining of RCPT TO and MAIL FROM commands (ABNF grammar) References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Date: 19 May 2007 15:00:37 +0300 In-Reply-To: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: <5dk5v5dnve.fsf@Hurtta06k.keh.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii | If the UTF8SMTP extension is offered, the syntax of the SMTP MAIL and | RCPT commands is extended to support the optional esmtp-keyword "ALT- | ADDRESS", which specifies an alternate all-ASCII address which may be | used when downgrading. If the ALT-ADDRESS esmtp-keyword is used, it | MUST have an associated esmtp-value (ALT-ADDRESS-esmtp-value which is | defined below). | | Based on the definition of mail-parameters in [RFC2821], the ALT- | ADDRESS parameter usage in the commands of "mail from" and "rcpt to" | is defined below. | | | "MAIL FROM:" SP [ SP ] | ; Update mail command in RFC 2821, section 3.3 | ; The syntax for "esmtp-value" in RFC2821 | ; does not allow "=", SP and control characters. | ; Therefore ALT-ADDRESS-paramater is extended. | | "RCPT TO:" SP [ SP ] | ; Update rcpt command in RFC 2821, section 3.3 This failes to take account that ALT-ADDRESS is is valid both on MAIL and RCPT commands. And then there must not be SP between "FROM:" and and there must not be SP between "TO:" and Corresponding RFC 2821 syntaxes are: | Syntax: | | "MAIL FROM:" ("<>" / Reverse-Path) | [SP Mail-parameters] CRLF and | Syntax: | "RCPT TO:" ("" / "" / Forward-Path) | [SP Rcpt-parameters] CRLF Possible text: " Syntax of MAIL command is altered as following: " " "MAIL FROM:" ("<>" / uReverse-Path) " [SP uMail-parameters] CRLF " " " Syntax of RECIPIENT (RCPT) command is altered as following: " " "RCPT TO:" ("" / "" / uForward-Path) " [SP uRcpt-parameters] CRLF " " " These parameters are defined as following " " uMail-parameters = Mail-parameters | ALT-ADDRESS-parameter " " uRcpt-parameters = Rcpt-parameters | ALT-ADDRESS-parameter " " uReverse-path = uPath " ; Replace Reverse-path in RFC 2821, section 4.1.2 " " uForward-path = uPath " ; Replace Forward-path in RFC 2821, section 4.1.2 " " uPath = "<" [ A-d-l ":" ] uMailbox ">" " ; Replace Path in RFC 2821, section 4.1.2 " ; A-d-l is defined in RFC 2821, section 4.1.2 " ; uMailbox is defined in section 2.3 of this document " " ALT-ADDRESS-parameter="ALT-ADDRESS=" ALT-ADDRESS-esmtp-value " ; The syntax for "esmtp-value" in RFC2821 " ; does not allow "=", SP and control characters. " ; Therefore ALT-ADDRESS-paramater is extended. " " ALT-ADDRESS-esmtp-value=xtext " ; xtext is defined in RFC 3461, section 4.2 --ELM1180631574-11914-0_ Content-Transfer-Encoding: 7bit Content-Type: message/rfc822 From: Kari Hurtta cc: Kari Hurtta To: Harald Tveit Alvestrand Subject: ISSUE: SMTPEXT 2.6: Reply code so that downgrade is not possible References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Date: 19 May 2007 15:42:55 +0300 In-Reply-To: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: <5dfy5tdlww.fsf@Hurtta06k.keh.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii | Since there is no ESMTP parameter which tells whether the message is | UTF8SMTP message, SMTP server needs to parse all message header | fields and MIME header fields in the message body to discover which | messages are UTF8SMTP. There is needed reply for "." on final DATA which indicates that downgrade is not possible (for example is missing from mail headers). Nowdays accept and then bounce do not fly. Even when reply code is not specified on document, very much of parsing will be done on before ACKing that mail is received (nowdays for example virus scanning is done before ACKin that message is received). That means that possibility of downgrading is checked before mail is ACKed. If reply code is not assigned, implementations will invent own code for that. Addition: " Mail message may be rejected because downgrade is required and " is is not possible. Altenatively message may be accepted and " then DSN is send for downgarde failure. " " When messages are rejected because they require UTF8SMTP and " downgrading is not available or downgrading fails, response " code "554" is used, defined in [RFC2821], meaning "Transaction " failed". if enhanced mail system status codes [RFC3463] is " used, the response code should be "5.6.a" [SMTP-codes], meaning that " "UTF8SMTP downgrade failed". " " [[anchor: REMOVE THIS: IANA please assign the proper error codes for " "5.6.a".]] And to IANA Considerations: " IANA is requested to assign the proper error codes "5.6.a" and " "5.6.x" for this specification based on [SMTP-codes]. Section 2.5 talks also about return code, but it seems be for MAIL FROM and RCPT TO commands when ALT-ADDRESS paramater is missing. --ELM1180631574-11914-0_ Content-Transfer-Encoding: 7bit Content-Type: message/rfc822 From: Kari Hurtta cc: Kari Hurtta To: Harald Tveit Alvestrand Subject: ISSUE: UTF8HDR 4.3/4.5: Message-ID restriction not descibed References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Date: 19 May 2007 20:11:13 +0300 In-Reply-To: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: <5dlkfkwxfy.fsf@Hurtta06k.keh.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii | Besides, in order to allow UTF8 characters in we have to | change the syntax of . However, it would also lead | to allow UTF8 characters, which is not allowed due to the limitation | described in Section 4.5. So is added to meet this | requirement. However section 4.5 does not talk about that restriction: | 4.5. Trace field syntax | | "For" fields containing internationalized addresses are allowed, by | use of the new uFor syntax. UTF-8 information in needed in Received | fields and such information is therefore allowed, to preserve the | integrity of those fields. The uFor syntax retains the original | UTF-8 email address between EAI-aware MTAs. Note that, should | downgrading be required, the uFor parameter is dropped per the | procedure specified in [EAI-downgrading]. | | The "Return-Path" header provides the email returning address in the | mail delivery. Thus, it MUST able to carry UTF8 addresses (see the | revised syntax of in Section 4.3 of this document). | This will not break the rule of trace fied integrity, because it is | added at the last MTA. Message-ID may need own chapter? RFC 2822 uses on following places: message-id = "Message-ID:" msg-id CRLF in-reply-to = "In-Reply-To:" 1*msg-id CRLF references = "References:" 1*msg-id CRLF resent-msg-id = "Resent-Message-ID:" msg-id CRLF item-value = 1*angle-addr / addr-spec / atom / domain / msg-id So is actually also component on trace field, but text on chapter 4.5 actually do not describe reason of restriction. I think that following sentence is mutated: | UTF-8 information in needed in Received | fields and such information is therefore allowed, to preserve the | integrity of those fields. It may be that is NOT allowed to include UTF-8 so that intregrety of these fields of Received -header filed and other identity header fields is preserved. ( That pointer was making more sense when text was: | With these two restrictions, there should be no need for | UTF-8 information in Received fields and such information is | prohibited to preserve the integrity of those fields. ) Some serious rephrasing is needed. --ELM1180631574-11914-0_ Content-Transfer-Encoding: 7bit Content-Type: message/rfc822 From: Kari Hurtta cc: Kari Hurtta To: Harald Tveit Alvestrand Subject: ISSUE: UTF8HDR 4.4: should include References: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Date: 19 May 2007 21:53:57 +0300 In-Reply-To: <3B0DD2A4F26C894FA5B7DEC3@[192.168.1.119]> Message-ID: <5dfy5swsoq.fsf@Hurtta06k.keh.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii | angle-addr = [CFWS] "<" utf8-addr-spec">" [CFWS] / \ | [CFWS] "<" utf8-addr-spec ">" [CFWS] / \ | [CFWS] utf8-addr-spec [CFWS] RFC 2822 corresponding rule is: | angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr Because other rules also have retained obs-* then this should also. That makes (ignoring utf8-addr-spec): " angle-addr = [CFWS] "<" utf8-addr-spec">" [CFWS] / \ " [CFWS] "<" utf8-addr-spec ">" [CFWS] / \ " obs-angle-addr ( Although I think that it is easier to use incremental syntax with "=/" ) --ELM1180631574-11914-0_ 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 --ELM1180631574-11914-0_-- From ima-bounces@ietf.org Thu May 31 15:58:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtqnM-0001SM-TE; Thu, 31 May 2007 15:58:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtqnM-0001Nj-4f for ima@ietf.org; Thu, 31 May 2007 15:58:52 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtqnI-0006kO-48 for ima@ietf.org; Thu, 31 May 2007 15:58:52 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 68AD82596B7; Thu, 31 May 2007 21:58:47 +0200 (CEST) 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 09309-05; Thu, 31 May 2007 21:58:42 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id E2FCD2580E1; Thu, 31 May 2007 21:58:41 +0200 (CEST) Message-ID: <465F28F0.4010307@alvestrand.no> Date: Thu, 31 May 2007 21:58:40 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Kari Hurtta Subject: Re: [EAI] Re: Issues open against SMTPEXT and UTF8HDR documents References: <200705311712.l4VHCswL012505@Hurtta06k.keh.iki.fi> In-Reply-To: <200705311712.l4VHCswL012505@Hurtta06k.keh.iki.fi> 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: 5011df3e2a27abcc044eaa15befcaa87 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 Kari Hurtta wrote: > Harald Tveit Alvestrand : > >> But we have to get these issues settled, and make sure we have raised all >> significant issues as soon as possible, if we're going to catch up with any >> reasonable schedule. >> >> Below are the tickets created for the issues we know. >> When following up, please use the following subject line convention: >> >> - Subject: #1483 for addressing issue 1483 >> - Subject: ISSUE:
: for raising a new >> issue. >> >> The chairs will enter issues raised with the ISSUE: convention into the >> tracker if they deem the issue well defined and important; if they are >> unsure of its importance, they may ask for a second before tracking it. >> >> Grammar and spelling notes should go directly to the editors. >> >> PLEASE raise issues against these 2 documents as soon as possible; >> preferably before May 23 (Wednesday of next week). >> > > I posted May 19 following issues to you,. Nothing hear about > these. Are these all found as unimportant or was they lost? > > ISSUE: UTF8HDR 4.4: should include > ISSUE: UTF8HDR 4.3/4.5: Message-ID restriction not descibed > ISSUE: SMTPEXT 2.6: Reply code so that downgrade is not possible > ISSUE: SMTPEXT 2.4: Redefining of RCPT TO and MAIL FROM commands (ABNF grammar) > ISSUE: SMTPEXT 2.7.3: syntax > ISSUE: UTF8HDR 4.5: and on trace field syntax > ISSUE: UTF8HDR 4.4: must always include "<" and ">" characters > ISSUE: UTF8HDR 4.3: Incremental alternatives (ABNF grammar) > ISSUE: UTF8HDR 4.2: Extending MIME (ABNF grammar) > ISSUE: UTF8HDR 3: UTF-8 character defination > ISSUE: UTF8HDR 3: "header" versus "header field" > ISSUE: UTF8HDR 4.2: Including Content-Description to picture (grammar) > > > These are included to that message for reference. > Thanks for sending these. I have been very slow in entering them (did so a few hours ago). Four of these caused creation of tickets; some of them I considered editorial, one I claim is not an EAI issue. > Most of these I have earlier sent to authors of drafts. > > > Today I got message Abel Yang which included pointer to new > unpublished draft-ietf-eai-utf8headers-06.txt. That message > was addressed also to Randall Gellens and Alexey Melnikov which > was also commented draft and then also to eai-dt@alvestrand.no > address. That address seems to be some members-only mailing > list (I got bounce from Mailman when I used group reply.) > Apparently these drafts are discussed also on some other > mailing lists than on WG mailing list. > Yes, all the document editors + the WG chairs are members of the "design team" list. See RFC 2418 section 6.5 for what a design team is supposed to be. > > Anyway draft-ietf-eai-utf8headers-06.txt seems have fixed some > of these issues: > > ISSUE: UTF8HDR 4.4: should include > seems to have fixed > > ISSUE: UTF8HDR 4.3/4.5: Message-ID restriction not descibed > not handled > > ISSUE: UTF8HDR 4.5: and on trace field syntax > not handled > > ISSUE: UTF8HDR 4.4: must always include "<" and ">" characters > not handled > > ISSUE: UTF8HDR 4.3: Incremental alternatives (ABNF grammar) > have some changes, but there is some problems still > > ISSUE: UTF8HDR 4.2: Extending MIME (ABNF grammar) > fixed, except some old stray text is left behind > > ISSUE: UTF8HDR 3: UTF-8 character defination > have some changes, but may require still touch > > ISSUE: UTF8HDR 3: "header" versus "header field" > have some changes, but "header field" is not used > > ISSUE: UTF8HDR 4.2: Including Content-Description to picture (grammar) > not handled > We will see what can be resolved before submitting the next version. If something is contentious, the WG will have to weigh in on it. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu May 31 16:01:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtqqL-0004oc-Kz; Thu, 31 May 2007 16:01:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtqqL-0004oX-0A for ima@ietf.org; Thu, 31 May 2007 16:01:57 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtqqJ-0007Eo-N9 for ima@ietf.org; Thu, 31 May 2007 16:01:56 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 25CE02596B7 for ; Thu, 31 May 2007 22:01:55 +0200 (CEST) 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 09529-01 for ; Thu, 31 May 2007 22:01:50 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id AB8252580E1 for ; Thu, 31 May 2007 22:01:50 +0200 (CEST) Message-ID: <465F29AD.6000500@alvestrand.no> Date: Thu, 31 May 2007 22:01:49 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: "ima@ietf.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.5 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [EAI] No more issues known 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 Note: Apart from the set of issues raised by Kari in private mail, I have seen no messages using the "ISSUE:" format. We will proceed with the assumption that the list of issues is complete. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima