From ima-bounces@ietf.org Tue Oct 03 10:20:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUl7b-0004S4-QD; Tue, 03 Oct 2006 10:19:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUS5H-0000PZ-RR for ima@ietf.org; Mon, 02 Oct 2006 14:00:07 -0400 Received: from smtp2.pp.htv.fi ([213.243.153.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUS5G-0001d2-I2 for ima@ietf.org; Mon, 02 Oct 2006 14:00:07 -0400 Received: from Hurtta06k.keh.iki.fi (cs181108174.pp.htv.fi [82.181.108.174]) by smtp2.pp.htv.fi (Postfix) with ESMTP id 5E107296C97; Mon, 2 Oct 2006 20:59:55 +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 k92HxskB013727; Mon, 2 Oct 2006 20:59:55 +0300 Received: (from hurtta@localhost) by Hurtta06k.keh.iki.fi (8.13.4/8.13.4/Submit) id k92HxrQb013726; Mon, 2 Oct 2006 20:59:53 +0300 Message-Id: <200610021759.k92HxrQb013726@Hurtta06k.keh.iki.fi> To: yaojk@cnnic.cn, mao@cnnic.cn Date: Mon, 2 Oct 2006 20:59:53 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Tue, 03 Oct 2006 10:19:47 -0400 Cc: hurtta+ietf@siilo.fmi.fi, ima@ietf.org Subject: [EAI] Comment about draft-ietf-eai-smtpext-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org draft-ietf-eai-smtpext-01.txt: | 6. Servers offering this extension MUST provide support for, and | announce, the 8BITMIME extension [RFC1652]. | Support and use of this extension requires support for 8BITMIME. It | means that 8BITMIME MUST be advertised by the UTF8SMTP capability | SMTP server. Perhaps also using of BINARYMIME (RFC 3030) is possible ? At least both BODY=8BITMIME and BODY=BINARYMIME are theoretically possible to occur with international mail. ( Althoug implementation of RFC 3030 is not common. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 03 10:20:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUl7b-0004Rx-Ms; Tue, 03 Oct 2006 10:19:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTubc-0001R3-7D for ima@ietf.org; Sun, 01 Oct 2006 02:15:16 -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 1GTubW-0008VG-UM for ima@ietf.org; Sun, 01 Oct 2006 02:15:16 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GTubO-00084q-7f for ima@ietf.org; Sun, 01 Oct 2006 08:15:02 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Oct 2006 08:15:02 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 01 Oct 2006 08:15:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 01 Oct 2006 09:00:54 +0300 Lines: 36 Message-ID: <5d4puod17t.fsf@Hurtta06k.keh.iki.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Tue, 03 Oct 2006 10:19:47 -0400 Subject: [EAI] smtp MAIL FROM dowgrading 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 One method for smtp MAIL FROM: downgrading is use similar trick what SPF uses for it's forwarding problem. For SPF that is SRS (Sender Rewriting Scheme). So when mail with MAIL FROM: need to go to next smtp hop which do not support UTF8SMTP it can be similarry replaced with MAIL FROM: and then maintain that bounces and DSNes with MAIL FROM:<> RCPT TO: are forwarded as RCPT TO: for one month time. That have same problems than SRS that it is not used as involuntary relay, but if SRS can be used then that also is possible. This trick also do not require that any other participant knows that trick and do not require standard. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 03 14:22:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUou4-0000zq-8X; Tue, 03 Oct 2006 14:22:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUou3-0000zk-Nw for ima@ietf.org; Tue, 03 Oct 2006 14:22:03 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUou2-0007Cu-DP for ima@ietf.org; Tue, 03 Oct 2006 14:22:03 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 3605B2596BB; Tue, 3 Oct 2006 20: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 26648-02; Tue, 3 Oct 2006 20:19:30 +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 DB9EE2596BA; Tue, 3 Oct 2006 20:19:29 +0200 (CEST) Message-ID: <4522AA43.2070506@alvestrand.no> Date: Tue, 03 Oct 2006 20:21:55 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Kari Hurtta Subject: Re: [EAI] smtp MAIL FROM dowgrading References: <5d4puod17t.fsf@Hurtta06k.keh.iki.fi> In-Reply-To: <5d4puod17t.fsf@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: 8b431ad66d60be2d47c7bfeb879db82c 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 This would work for MAIL FROM (at the cost of creating state in the relay). But how would one do downgrading of From: and Cc: fields in the message header? After all, "email works" is closely related to "reply works"..... Kari Hurtta wrote: > One method for smtp > MAIL FROM: > > downgrading is use similar trick what SPF uses for > it's forwarding problem. For SPF that is SRS > (Sender Rewriting Scheme). > > So when mail with > MAIL FROM: > > need to go to next smtp hop which do not support UTF8SMTP > it can be similarry replaced with > > MAIL FROM: > > and then maintain that bounces and DSNes with > > MAIL FROM:<> > RCPT TO: > > are forwarded as > > RCPT TO: > > > for one month time. > > That have same problems than SRS that it is not > used as involuntary relay, but if SRS can be used > then that also is possible. > > This trick also do not require that any other participant > knows that trick and do not require standard. > > / 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 Tue Oct 03 16:37:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUr1M-0003er-O0; Tue, 03 Oct 2006 16:37:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUr1L-0003ei-Ii for ima@ietf.org; Tue, 03 Oct 2006 16:37:43 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUr1E-0000Hg-Jr for ima@ietf.org; Tue, 03 Oct 2006 16:37:43 -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.232) id 4522ca01.164c.2f5 for ima@ietf.org; Tue, 3 Oct 2006 21:37:21 +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 k93KbJXQ015257 for ; Tue, 3 Oct 2006 21:37:20 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] smtp MAIL FROM dowgrading References: <5d4puod17t.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Tue, 03 Oct 2006 21:37:18 +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: <5d4puod17t.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, 01 Oct 2006 07:00:54 +0100, Kari Hurtta wrote: > So when mail with > MAIL FROM: > > need to go to next smtp hop which do not support UTF8SMTP > it can be similarry replaced with > > MAIL FROM: > > and then maintain that bounces and DSNes with > > MAIL FROM:<> > RCPT TO: > > are forwarded as > > RCPT TO: Actually, that raises several interesting possibilities, which we really ought to allow. Essentially, some agent (even a MUA perhaps) finds that the host it wants to send to does not support UTF8smtp. So far, we have said "in that case, either bounce or downgrade". But we should not preclude other solutions, and notably we should allow it to send instead to some "smarter" host that can figure it out. There are many things that "sarter host" might do, and the obvious one is the case of a (more or less) public service that will do a proper job of downgrading and then forward it to the intended destination. That might enable many other servers not to have to implement downgrading themselves, which might in turn lead to a faster takeup of this whole scheme. And doubtless there are other things a "smarter" server could do, such as the man-in-the-middle scheme that Kari has just proposed. -- 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 Oct 04 01:32:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUzMh-0003zw-ER; Wed, 04 Oct 2006 01:32:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUzMg-0003zo-Hy for ima@ietf.org; Wed, 04 Oct 2006 01:32:18 -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 1GUzMb-0000Lf-7v for ima@ietf.org; Wed, 04 Oct 2006 01:32:18 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GUzMS-0001EG-Ab for ima@ietf.org; Wed, 04 Oct 2006 07:32:04 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Oct 2006 07:32:04 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Oct 2006 07:32:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] smtp MAIL FROM dowgrading Date: 04 Oct 2006 08:31:52 +0300 Lines: 66 Message-ID: <5dejtor6if.fsf@Hurtta06k.keh.iki.fi> References: <5d4puod17t.fsf@Hurtta06k.keh.iki.fi> <4522AA43.2070506@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand writes in gmane.ietf.ima: > This would work for MAIL FROM (at the cost of creating state in the relay). > But how would one do downgrading of From: and Cc: fields in the > message header? > > After all, "email works" is closely related to "reply works"..... Yes, "smart proxy" is willing to do From: conversion on headers From: only if it ready to relay incoming mail to 'domain' for any arriving mail with MAIL FROM: RCPT TO: These means some kind agreement between converting-smtp-host and 'domain' for service. > Kari Hurtta wrote: > > One method for smtp > > MAIL FROM: > > > > downgrading is use similar trick what SPF uses for > > it's forwarding problem. For SPF that is SRS > > (Sender Rewriting Scheme). > > > > So when mail with > > MAIL FROM: > > > > need to go to next smtp hop which do not support UTF8SMTP > > it can be similarry replaced with > > > > MAIL FROM: > > > > and then maintain that bounces and DSNes with > > > > MAIL FROM:<> > > RCPT TO: > > > > are forwarded as > > > > RCPT TO: > > > > > > for one month time. > > > > That have same problems than SRS that it is not > > used as involuntary relay, but if SRS can be used > > then that also is possible. > > > > This trick also do not require that any other participant > > knows that trick and do not require standard. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 04 12:48:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9u3-0005jL-4L; Wed, 04 Oct 2006 12:47:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9tz-0005gC-JQ for ima@ietf.org; Wed, 04 Oct 2006 12:47:23 -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 1GV9tY-0005Dd-US for ima@ietf.org; Wed, 04 Oct 2006 12:46:58 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GV9qI-0002Oz-0J for ima@ietf.org; Wed, 04 Oct 2006 18:43:34 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Oct 2006 18:43:33 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Oct 2006 18:43:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] smtp MAIL FROM dowgrading Date: 04 Oct 2006 19:40:50 +0300 Lines: 28 Message-ID: <5dmz8cqbjh.fsf@Hurtta06k.keh.iki.fi> References: <5d4puod17t.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 "Charles Lindsey" writes: > Actually, that raises several interesting possibilities, which we > really ought to allow. > > Essentially, some agent (even a MUA perhaps) finds that the host it > wants to send to does not support UTF8smtp. > And doubtless there are other things a "smarter" server could do, such > as the man-in-the-middle scheme that Kari has just proposed. Yes, one possibile for example what that kind gateway can do: - Gateway puts original message to store accessible via http or https - Then gateway sends short note whare gives URL to that message on store - Replying is done via WWW form That kind products exists (for different purpose). / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 05 01:10:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVLUM-0005wV-AY; Thu, 05 Oct 2006 01:09:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVLUK-0005uW-8O for ima@ietf.org; Thu, 05 Oct 2006 01:09:40 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVLJQ-0005DP-2s for ima@ietf.org; Thu, 05 Oct 2006 00:58:25 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 86E312596BB; Thu, 5 Oct 2006 06:55:53 +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 18760-04; Thu, 5 Oct 2006 06:55:47 +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 1C4B82596B8; Thu, 5 Oct 2006 06:55:47 +0200 (CEST) Message-ID: <452490E6.6040902@alvestrand.no> Date: Thu, 05 Oct 2006 06:58:14 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Kari Hurtta Subject: Re: [EAI] smtp MAIL FROM dowgrading References: <5d4puod17t.fsf@Hurtta06k.keh.iki.fi> <5dmz8cqbjh.fsf@Hurtta06k.keh.iki.fi> In-Reply-To: <5dmz8cqbjh.fsf@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: 769a46790fb42fbb0b0cc700c82f7081 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 I think this kind of "gateway" is out of scope for this working group. There's a limit to what kind of complexity I see a point in making standards for. Harald Kari Hurtta wrote: > "Charles Lindsey" writes: > > >> Actually, that raises several interesting possibilities, which we >> really ought to allow. >> >> Essentially, some agent (even a MUA perhaps) finds that the host it >> wants to send to does not support UTF8smtp. >> > > >> And doubtless there are other things a "smarter" server could do, such >> as the man-in-the-middle scheme that Kari has just proposed. >> > > Yes, > > one possibile for example what that kind gateway can do: > > - Gateway puts original message to store accessible via http or https > > - Then gateway sends short note whare gives URL to that message > on store > > - Replying is done via WWW form > > > That kind products exists (for different purpose). > > > / 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 Thu Oct 05 06:05:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVQ6d-0004Yx-B0; Thu, 05 Oct 2006 06:05:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVQ6b-0004UH-VG for ima@ietf.org; Thu, 05 Oct 2006 06:05:29 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVPtP-00045p-1Q for ima@ietf.org; Thu, 05 Oct 2006 05:51:56 -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.231) id 4524d5b5.226f.1f6 for ima@ietf.org; Thu, 5 Oct 2006 10:51:49 +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 k959pklm009064 for ; Thu, 5 Oct 2006 10:51:47 +0100 (BST) To: "ima@ietf.org" Subject: Re: [EAI] smtp MAIL FROM dowgrading References: <5d4puod17t.fsf@Hurtta06k.keh.iki.fi> <5dmz8cqbjh.fsf@Hurtta06k.keh.iki.fi> <452490E6.6040902@alvestrand.no> Message-ID: Date: Thu, 05 Oct 2006 10:51: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: <452490E6.6040902@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 05 Oct 2006 05:58:14 +0100, Harald Alvestrand wrote: > I think this kind of "gateway" is out of scope for this working group. > There's a limit to what kind of complexity I see a point in making > standards for. Sure, but we should not write the standard in such a way as to actively forbid such schemes - just so long as they do succeed in getting the messages delivered to their recipients intact (essentially, so that your scenarios still work). I agree that Kari's suggestion for putting the message on a website and inviting the recipient to look there would stretch that principle right to the limit, but the scheme for a man-in-the-middle to deliver replies looks workable, even if bizarre. -- 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 Oct 05 06:56:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVQu9-0008Rq-Gm; Thu, 05 Oct 2006 06:56:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVQu8-0008Rk-16 for ima@ietf.org; Thu, 05 Oct 2006 06:56:40 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVQu5-00072r-N5 for ima@ietf.org; Thu, 05 Oct 2006 06:56:40 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 13C4325817F; Thu, 5 Oct 2006 12:54: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 29639-08; Thu, 5 Oct 2006 12:54:03 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 399CF2596B8; Thu, 5 Oct 2006 12:54:03 +0200 (CEST) Message-ID: <4524E4DF.4040806@alvestrand.no> Date: Thu, 05 Oct 2006 03:56:31 -0700 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] smtp MAIL FROM dowgrading References: <5d4puod17t.fsf@Hurtta06k.keh.iki.fi> <5dmz8cqbjh.fsf@Hurtta06k.keh.iki.fi> <452490E6.6040902@alvestrand.no> 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: ea4ac80f790299f943f0a53be7e1a21a 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 Charles Lindsey wrote: > On Thu, 05 Oct 2006 05:58:14 +0100, Harald Alvestrand > wrote: > >> I think this kind of "gateway" is out of scope for this working group. >> There's a limit to what kind of complexity I see a point in making >> standards for. > > Sure, but we should not write the standard in such a way as to > actively forbid such schemes - just so long as they do succeed in > getting the messages delivered to their recipients intact > (essentially, so that your scenarios still work). > > I agree that Kari's suggestion for putting the message on a website > and inviting the recipient to look there would stretch that principle > right to the limit, but the scheme for a man-in-the-middle to deliver > replies looks workable, even if bizarre. I operated such schemes in the late 80s/early 90s (x.400 to SMTP gatewaying). "workable" is not exactly a false statement, if your criteria for "workable" are low enough. /C=no/PRMD=uninett/O=sintef/OU=delab/S=Alvestrand/I=T/G=Harald/@aun.uninett.no would reach me for a while - provided none of the mailers involved bounced mail with an address that started with a slash "for security reasons"...... Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 05 16:08:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZVj-0002BS-LK; Thu, 05 Oct 2006 16:08:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVZVi-0002BM-Hq for ima@ietf.org; Thu, 05 Oct 2006 16:08:02 -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 1GVZVd-0004qt-2W for ima@ietf.org; Thu, 05 Oct 2006 16:08:02 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GVZU3-0006yr-Hp for ima@ietf.org; Thu, 05 Oct 2006 22:06:19 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 22:06:19 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 22:06:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] header (822) address syntax Date: 05 Oct 2006 23:05:21 +0300 Lines: 78 Message-ID: <5diriyjzpa.fsf@Hurtta06k.keh.iki.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Tony Finch writes in gmane.ietf.ima: > mailbox = (utf8-name-addr / utf8-addr-spec) [downgrade] > downgrade = "[" ascii-addr-spec "]" > > i.e. one of > > From: Tony Finch [dot@dotat.at] > From: döt@dotät.at (Tony Finch) [dot@dotat.at] > > The downgraded form could be > > mailbox = (name-addr / addr-spec) [downgrade-comment] > downgrade-comment = "([" rfc2047-addr-spec "])" > > where the latter part is the RFC 2047 encoding of the UTF8 address. The > ([]) is a comment wrapping a [] bracketed address, so that it parses as a > comment but still has a distinctive form. For example, > > From: Tony Finch ([=?utf-8?q?d=F6t@dot=A4t.at]) > From: dot@dotat.at (Tony Finch) ([=?utf-8?q?d=F6t@dot=A4t.at]) I think you mean From: Tony Finch ([ =?utf-8?q?d=F6t@dot=A4t.at?= ]) (***) otherwise it does not work. (*) > This might get mangled into one of the following, which I think is OK. > > From: Tony Finch "[=?utf-8?q?d=F6t@dot=A4t.at]" =? and " are alternative ways to do quotation, so that does not make sense. (**) 'Correct' mangling is perhaps From: Tony Finch =?utf-8?q?=5Bd=F6t=40dot=A4t=2Eat=5D?= or if (***) is used From: Tony Finch "[" =?utf-8?q?d=F6t=40dot=A4t=2Eat?= "]" > From: dot@dotat.at (Tony Finch [=?utf-8?q?d=F6t@dot=A4t.at]) From: dot@dotat.at (Tony Finch =?utf-8?q?=5Bd=F6t@dot=A4t.at=5D?= ) of from (***) becomes From: dot@dotat.at (Tony Finch [ =?utf-8?q?d=F6t@dot=A4t.at?= ]) > > Note that this proposal makes the UTF8 header and downgraded ASCII header > forms look quite similar, and keeps the UTF8 email address easily > accessible. > > Tony. Dowgraded form should be compatible with current standards. / Kari Hurtta (*) RFC 2047: | (2) An 'encoded-word' may appear within a 'comment' delimited by "(" and | ")", i.e., wherever a 'ctext' is allowed. More precisely, the RFC | 822 ABNF definition for 'comment' is amended as follows: | | comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")" | | A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT | contain the characters "(", ")" or " | 'encoded-word' that appears in a 'comment' MUST be separated from | any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'. (**) RFC 2047: | + An 'encoded-word' MUST NOT appear within a 'quoted-string'. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 06 00:37:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVhSc-0000il-Tk; Fri, 06 Oct 2006 00:37:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVhSc-0000id-Au for ima@ietf.org; Fri, 06 Oct 2006 00:37:22 -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 1GVhSb-0005IC-0o for ima@ietf.org; Fri, 06 Oct 2006 00:37:22 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GVhSZ-0003jQ-Eo for ima@ietf.org; Fri, 06 Oct 2006 06:37:19 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Oct 2006 06:37:19 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Oct 2006 06:37:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] header (822) address syntax Date: 06 Oct 2006 07:37:11 +0300 Lines: 33 Message-ID: <5dac4ajc08.fsf@Hurtta06k.keh.iki.fi> References: <5diriyjzpa.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes: > Tony Finch writes in gmane.ietf.ima: > > > mailbox = (utf8-name-addr / utf8-addr-spec) [downgrade] > > downgrade = "[" ascii-addr-spec "]" > > > > i.e. one of > > > > From: Tony Finch [dot@dotat.at] > > From: döt@dotät.at (Tony Finch) [dot@dotat.at] > > > > The downgraded form could be > > > > mailbox = (name-addr / addr-spec) [downgrade-comment] > > downgrade-comment = "([" rfc2047-addr-spec "])" > > > > where the latter part is the RFC 2047 encoding of the UTF8 address. The > > ([]) is a comment wrapping a [] bracketed address, so that it parses as a > > comment but still has a distinctive form. For example, > > > > From: Tony Finch ([=?utf-8?q?d=F6t@dot=A4t.at]) > > From: dot@dotat.at (Tony Finch) ([=?utf-8?q?d=F6t@dot=A4t.at]) > > I think you mean > From: Tony Finch ([ =?utf-8?q?d=F6t@dot=A4t.at?= ]) (***) Seems that I have sleeping. That charset is actually iso-8859-1 and not utf-8 :-) So if enconding is fixed: From: Tony Finch ([ =?UTF-8?Q?d=C3=B6t=40dot=C3=A4t=2Eat?= ]) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 06 01:07:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVhvU-0000KQ-9j; Fri, 06 Oct 2006 01:07:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVhvT-0000K8-6f for ima@ietf.org; Fri, 06 Oct 2006 01:07:11 -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 1GVhvP-0007XS-TG for ima@ietf.org; Fri, 06 Oct 2006 01:07:11 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GVhvH-0000a6-TY for ima@ietf.org; Fri, 06 Oct 2006 07:07:00 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Oct 2006 07:06:59 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Oct 2006 07:06:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 06 Oct 2006 08:06:50 +0300 Lines: 18 Message-ID: <5d3ba2jamt.fsf@Hurtta06k.keh.iki.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [EAI] draft-ietf-eai-utf8headers-01.txt comment X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org header-content = "UTF8SMTP:" [FWS] content-code [FWS] *( ";" parameter ) CRLF content-code = "UTF8" / "ASCII" / "Downgraded" parameter = "Header-Language:" [FWS] Language-List Language-List = Language-Tag [FWS] *("," [FWS] Language-Tag [FWS]) Should 'parameter' use mime-style syntax instead ? Several different header parameter syntaxes is not good. (In other hand language-list then requires quoted string if it includes sevaral values. But I still think that implementation is easier if existing parser can be used. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 06 06:11:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVmfi-0000TL-Qf; Fri, 06 Oct 2006 06:11:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVmfh-0000TF-P5 for ima@ietf.org; Fri, 06 Oct 2006 06:11:13 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVmfg-0001i9-Fx for ima@ietf.org; Fri, 06 Oct 2006 06:11:13 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 430792580CF; Fri, 6 Oct 2006 12:08:43 +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 01615-10; Fri, 6 Oct 2006 12:08:36 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 36C512580D1; Fri, 6 Oct 2006 12:08:36 +0200 (CEST) Message-ID: <45262BB6.6080207@alvestrand.no> Date: Fri, 06 Oct 2006 03:11:02 -0700 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-01.txt comment References: <5d3ba2jamt.fsf@Hurtta06k.keh.iki.fi> In-Reply-To: <5d3ba2jamt.fsf@Hurtta06k.keh.iki.fi> 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: 7655788c23eb79e336f5f8ba8bce7906 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: > header-content = "UTF8SMTP:" [FWS] content-code [FWS] > *( ";" parameter ) CRLF > content-code = "UTF8" / "ASCII" / "Downgraded" > parameter = "Header-Language:" [FWS] Language-List > Language-List = Language-Tag [FWS] > *("," [FWS] Language-Tag [FWS]) > > > Should 'parameter' use mime-style syntax instead ? > > Several different header parameter syntaxes is not good. > (In other hand language-list then requires quoted string > if it includes sevaral values. But I still think that > implementation is easier if existing parser can be used. ) I still regard the whole idea of putting parameters into the UTF8SMTP "marker" header as controversial, but I may be the only one. If it causes extra complexity in implementations, I am afraid that it will just end up as yet another piece of unimplemented cruft. Thoughts? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 06 08:28:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVooS-0001Tx-Fj; Fri, 06 Oct 2006 08:28:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVooQ-0001Ts-Rb for ima@ietf.org; Fri, 06 Oct 2006 08:28:22 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVooP-0003yK-9M for ima@ietf.org; Fri, 06 Oct 2006 08:28:22 -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.232) id 45264be3.123a7.1a5 for ima@ietf.org; Fri, 6 Oct 2006 13:28:19 +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 k96CSGj9014071 for ; Fri, 6 Oct 2006 13:28:17 +0100 (BST) Date: Fri, 06 Oct 2006 13:28:16 +0100 To: ima@ietf.org Subject: Re: [EAI] draft-ietf-eai-utf8headers-01.txt comment References: <5d3ba2jamt.fsf@Hurtta06k.keh.iki.fi> <45262BB6.6080207@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: <45262BB6.6080207@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 06 Oct 2006 11:11:02 +0100, Harald Alvestrand wrote: > Kari Hurtta wrote: >> parameter = "Header-Language:" [FWS] Language-List >> Should 'parameter' use mime-style syntax instead ? Yes, I already made that point in my commentary on that draft. > I still regard the whole idea of putting parameters into the UTF8SMTP > "marker" header as controversial, but I may be the only one. > > If it causes extra complexity in implementations, I am afraid that it > will just end up as yet another piece of unimplemented cruft. > > Thoughts? I think it is useful to allow some room for additional material that may be needed (naturally, we don't know what yet, but we can surely expect that there will be unanticipated situations once this stuff goes live). The nice thing about having space for s is that existing implementations are guaranteed not to break when they suddenly start to appear. That was one of the better ideas introduced by the MIME people, and we have since reaped the benefit of it (format=flowed is the best-known example). -- 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 Oct 06 12:19:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsPb-0005ym-4s; Fri, 06 Oct 2006 12:18:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVsPa-0005xT-Gm for ima@ietf.org; Fri, 06 Oct 2006 12:18:58 -0400 Received: from smtp6.pp.htv.fi ([213.243.153.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVsPZ-0003p2-70 for ima@ietf.org; Fri, 06 Oct 2006 12:18:58 -0400 Received: from Hurtta06k.keh.iki.fi (cs181108174.pp.htv.fi [82.181.108.174]) by smtp6.pp.htv.fi (Postfix) with ESMTP id B8E0C5BC0FF for ; Fri, 6 Oct 2006 19:18:55 +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 k96GItxZ009867 for ; Fri, 6 Oct 2006 19:18:55 +0300 Received: (from hurtta@localhost) by Hurtta06k.keh.iki.fi (8.13.4/8.13.4/Submit) id k96GIsf6009866 for ima@ietf.org; Fri, 6 Oct 2006 19:18:54 +0300 Message-Id: <200610061618.k96GIsf6009866@Hurtta06k.keh.iki.fi> To: EAI mailing list Date: Fri, 6 Oct 2006 19:18:54 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [EAI] draft-ietf-eai-utf8headers-01.txt comment #2 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 This is perhaps already discussed to dead. angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] utf8-addr-spec = utf8-local-part "@" utf8-domain utf8-local-part= utf8-dot-atom / quoted-string / obs-local-part utf8-domain = utf8-dot-atom / domain-literal / obs-domain alt-address = "{" [CFWS] addr-spec [CFWS] "}" Is that alt-address really necessary? That have quite large impact. It does not only require that MUAs need new parser. That also affect to MTAs. Usually MTAs provides way to rewrite addresses on headers. That is often requirement to border MTAs. These MTAs must also then change parser (more that just passing utf-8 characters around.) Downgrading also requires parser, but these alt-address syntaxes may cause that existing code can not be reused. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 06 13:09:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVtCU-0002Li-9W; Fri, 06 Oct 2006 13:09:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVtCT-0002Jk-8X for ima@ietf.org; Fri, 06 Oct 2006 13:09:29 -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 1GVtCR-0004ki-V7 for ima@ietf.org; Fri, 06 Oct 2006 13:09:29 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GVtC1-0001cv-9v for ima@ietf.org; Fri, 06 Oct 2006 19:09:01 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Oct 2006 19:09:01 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Oct 2006 19:09:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] header (822) address syntax Date: 06 Oct 2006 20:07:57 +0300 Lines: 38 Message-ID: <5d8xjtgyoi.fsf@Hurtta06k.keh.iki.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Fri, 11 Aug 2006 02:08:39 +0100, Tony Finch wrote: > > > > mailbox = (utf8-name-addr / utf8-addr-spec) [downgrade] > > downgrade = "[" ascii-addr-spec "]" > > > > i.e. one of > > > > From: Tony Finch [dot@dotat.at] > > From: döt@dotät.at (Tony Finch) [dot@dotat.at] > > > > Having been on holiday for 10 days, and just seen this, I am surprised > to find that there has been no response to this proposal on the list. > > It seems to have some merit, insofar as it is a less drastic change to > the present syntax, and it would seem to permit CFWS in more > reasonable places. I certainly think it is worth looking at > (especially, as we still have not really decided on a precise syntax > for the current proposal). Yes, specially From: Tony Finch [dot@dotat.at] may (perhaps) work with (some) existing parsers (without changes). For From: döt@dotät.at (Tony Finch) [dot@dotat.at] there is no that advantage. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 07 05:30:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW8Up-0004Dk-OJ; Sat, 07 Oct 2006 05:29:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW8Uo-0004DZ-7L for ima@ietf.org; Sat, 07 Oct 2006 05:29: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 1GW8Ue-00068b-Nf for ima@ietf.org; Sat, 07 Oct 2006 05:29:21 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GW8UT-0001iY-Pl for ima@ietf.org; Sat, 07 Oct 2006 11:29:05 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Oct 2006 11:29:05 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 Oct 2006 11:29:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP Date: 07 Oct 2006 12:28:48 +0300 Lines: 19 Message-ID: <5d64ewjwz3.fsf@Hurtta06k.keh.iki.fi> References: <44E1B2D5.8040105@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: > In draft-ietf-eai-downgrade-01 section 5, the editors have identified > a design decision that the WG needs to take: Whether to use an > encapsulation strategy or a conversion strategy when downgrading > messages from an UTF8SMTP user to an ASCII user. > > A few of us (editors + chairs) have had a discussion about this, and > reached a proposed resolution: > > - It is of paramount importance that ASCII users are able to interpret > downgraded messages without special software. Therefore, a conversion > approach MUST be used, and this will be documented in the next version. Is there differences between these two strategies (encapsulation strategy and a conversion strategy) on what situations these strategies are possible when downgrading is required? / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Oct 08 03:11:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWSo6-00049T-0C; Sun, 08 Oct 2006 03:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWSo5-00049O-Fj for ima@ietf.org; Sun, 08 Oct 2006 03:10:41 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GWSo3-0000kM-Pd for ima@ietf.org; Sun, 08 Oct 2006 03:10:41 -0400 Received: (eyou send program); Sun, 08 Oct 2006 15:10:22 +0800 Message-ID: <360291422.02247@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Sun, 08 Oct 2006 15:10:22 +0800 Message-ID: <005901c6eaa8$d2f191d0$1206e29f@cnnicyao> From: "Yao Jiankang" To: "Kari Hurtta" References: <359811996.18208@cnnic.cn> Date: Sun, 8 Oct 2006 15:10:23 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: hurtta+ietf@siilo.fmi.fi, ima@ietf.org Subject: [EAI] Re: Comment about draft-ietf-eai-smtpext-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0689421895==" Errors-To: ima-bounces@ietf.org --===============0689421895== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCmFzIHlvdSBzYWlkLCBpbXBsZW1lbnRhdGlvbiBvZiBSRkMgMzAzMCBpcyBub3QgY29tbW9u IHdoaWxlIDhCSVRNSU1FIGlzIHBvcHVsYXIuDQoNClNvIGltcGxlbWVudGluZyBFQUkgd2l0aCA4 QklUTUlNRSBzdXBwb3J0IGlzIGVhc2llciB0aGFuIGltcGxlbWVudGluZyBFQUkgd2l0aCBCSU5B UllNSU1FIHN1cHBvcnQuDQoNCk9uIG15IHZpZXcsIEkgc3RpbGwgcHJlZmVyIDhCSVRNSU1FIHN1 cHBvcnQgd2hpbGUgYW5ub3VuY2luZyBVVEY4U01UUCBjYXBhYmlsaXR5IC4NCg0KDQpZYW8gSmlh bmthbmcuDQoNCg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiS2Fy aSBIdXJ0dGEiIDxodXJ0dGEraWV0ZkBzaWlsby5mbWkuZmk+DQpUbzogPHlhb2prQGNubmljLmNu PjsgPG1hb0Bjbm5pYy5jbj4NCkNjOiA8aHVydHRhK2lldGZAc2lpbG8uZm1pLmZpPjsgPGltYUBp ZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDMsIDIwMDYgMTo1OSBBTQ0KU3ViamVj dDogQ29tbWVudCBhYm91dCBkcmFmdC1pZXRmLWVhaS1zbXRwZXh0LTAxLnR4dA0KDQoNCj4gDQo+ IGRyYWZ0LWlldGYtZWFpLXNtdHBleHQtMDEudHh0Og0KPiANCj4gfCAgIDYuICBTZXJ2ZXJzIG9m ZmVyaW5nIHRoaXMgZXh0ZW5zaW9uIE1VU1QgcHJvdmlkZSBzdXBwb3J0IGZvciwgYW5kDQo+IHwg ICAgICAgYW5ub3VuY2UsIHRoZSA4QklUTUlNRSBleHRlbnNpb24gW1JGQzE2NTJdLg0KPiANCj4g DQo+IHwgICBTdXBwb3J0IGFuZCB1c2Ugb2YgdGhpcyBleHRlbnNpb24gcmVxdWlyZXMgc3VwcG9y dCBmb3IgOEJJVE1JTUUuICBJdA0KPiB8ICAgbWVhbnMgdGhhdCA4QklUTUlNRSBNVVNUIGJlIGFk dmVydGlzZWQgYnkgdGhlIFVURjhTTVRQIGNhcGFiaWxpdHkNCj4gfCAgIFNNVFAgc2VydmVyLg0K PiANCj4gDQo+IFBlcmhhcHMgYWxzbyB1c2luZyBvZiBCSU5BUllNSU1FIChSRkMgMzAzMCkgaXMg cG9zc2libGUgPw0KPiANCj4gQXQgbGVhc3QgYm90aCBCT0RZPThCSVRNSU1FIGFuZCBCT0RZPUJJ TkFSWU1JTUUgIGFyZSB0aGVvcmV0aWNhbGx5DQo+IHBvc3NpYmxlIHRvIG9jY3VyIHdpdGggaW50 ZXJuYXRpb25hbCBtYWlsLg0KPiANCj4gKCBBbHRob3VnIGltcGxlbWVudGF0aW9uIG9mIFJGQyAz MDMwIGlzIG5vdCBjb21tb24uICkNCj4gDQo+IC8gS2FyaSBIdXJ0dGE= --===============0689421895== 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 --===============0689421895==-- From ima-bounces@ietf.org Sun Oct 08 03:36:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWTDG-0002Ox-Pd; Sun, 08 Oct 2006 03:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWTDF-0002Os-JI for ima@ietf.org; Sun, 08 Oct 2006 03:36: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 1GWTDD-0003km-4E for ima@ietf.org; Sun, 08 Oct 2006 03:36:41 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GWTCy-0002Xj-36 for ima@ietf.org; Sun, 08 Oct 2006 09:36:24 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Oct 2006 09:36:24 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Oct 2006 09:36:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Re: Comment about draft-ietf-eai-smtpext-01.txt Date: 08 Oct 2006 10:36:07 +0300 Lines: 63 Message-ID: <5dmz871cpk.fsf@Hurtta06k.keh.iki.fi> References: <359811996.18208@cnnic.cn> <360291422.02247@cnnic.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 "Yao Jiankang" writes in gmane.ietf.ima: > as you said, implementation of RFC 3030 is not common while 8BITMIME is popular. > > So implementing EAI with 8BITMIME support is easier than implementing EAI with BINARYMIME support. > > On my view, I still prefer 8BITMIME support while announcing UTF8SMTP capability . > > > Yao Jiankang. It occurs me that it is somewhat unclear what BODY -values can be on EAI mail. If non-ascii characters is only on envelope, can it be: MAIL FROM: BODY=7BIT ALT-ADDRESS=support@example.com RCPT TO: DATA From: support@example.com To: user@example.org Subject: Ticket #XYC-234-VNC Ticket closed. . In other hands if it is required to use BODY=8BITMIME, then also BODY=BINARYMIME is forbidded. / Kari Hurtta > ----- Original Message ----- > From: "Kari Hurtta" > To: ; > Cc: ; > Sent: Tuesday, October 03, 2006 1:59 AM > Subject: Comment about draft-ietf-eai-smtpext-01.txt > > > > > > draft-ietf-eai-smtpext-01.txt: > > > > | 6. Servers offering this extension MUST provide support for, and > > | announce, the 8BITMIME extension [RFC1652]. > > > > > > | Support and use of this extension requires support for 8BITMIME. It > > | means that 8BITMIME MUST be advertised by the UTF8SMTP capability > > | SMTP server. > > > > > > Perhaps also using of BINARYMIME (RFC 3030) is possible ? > > > > At least both BODY=8BITMIME and BODY=BINARYMIME are theoretically > > possible to occur with international mail. > > > > ( Althoug implementation of RFC 3030 is not common. ) > > > > / 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 Sun Oct 08 07:49:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWX8n-0003us-V2; Sun, 08 Oct 2006 07:48:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWX8m-0003un-Jc for ima@ietf.org; Sun, 08 Oct 2006 07:48:20 -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 1GWX8h-00078Y-9h for ima@ietf.org; Sun, 08 Oct 2006 07:48:20 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GWX8a-0007Fs-Tc for ima@ietf.org; Sun, 08 Oct 2006 13:48:08 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Oct 2006 13:48:08 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Oct 2006 13:48:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: 8BITMIME (Re: [EAI] Re: Comment about draft-ietf-eai-smtpext-01.txt) Date: 08 Oct 2006 14:48:01 +0300 Lines: 37 Message-ID: <5dvemv81vy.fsf_-_@Hurtta06k.keh.iki.fi> References: <359811996.18208@cnnic.cn> <360291422.02247@cnnic.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 "Yao Jiankang" writes in gmane.ietf.ima: > as you said, implementation of RFC 3030 is not common while 8BITMIME is popular. > > So implementing EAI with 8BITMIME support is easier than implementing EAI with BINARYMIME support. > > On my view, I still prefer 8BITMIME support while announcing UTF8SMTP capability . > > > Yao Jiankang. My impression is that most MTAs are lying when then announce 8BITMIME capacity. Announcement of 8BITMIME includes promise of downgrading message. I know some MTAs which can be configured to announce 8BITMIME although they newer will downgrade message. Effectively 8BITMIME is mutated to be "I'm 8-bit clean" but do not include promise that message can be delivered without that 8-bit is lost on rest of path. I'm thinking of idea that UTF8SMTP itself (without 8BITMIME) includes promise of 8-bit clean implementation. Then without 8BITMIME it just means bounce if next hop requires downgrading. Hmm. However that means problems if next hop announces UTF8SMTP without 8BITMIME and message was received with BODY=8BITMIME. This means that message body must be converted (otherwise MTA is laying about 8BITMIME announcement) but headers can be kept on utf-8. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Oct 08 17:35:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWgIc-0002AC-6U; Sun, 08 Oct 2006 17:35:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWgIa-0002A7-NE for ima@ietf.org; Sun, 08 Oct 2006 17:35:04 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWgIZ-0008V8-ED for ima@ietf.org; Sun, 08 Oct 2006 17:35:04 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2BC3F25817F; Sun, 8 Oct 2006 23:32:32 +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 02298-04; Sun, 8 Oct 2006 23:32:27 +0200 (CEST) Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 441442580E1; Sun, 8 Oct 2006 23:32:27 +0200 (CEST) Message-ID: <45296F00.8010800@alvestrand.no> Date: Sun, 08 Oct 2006 23:34:56 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Yao Jiankang Subject: Re: [EAI] Re: Comment about draft-ietf-eai-smtpext-01.txt References: <359811996.18208@cnnic.cn> <360291422.02247@cnnic.cn> In-Reply-To: <360291422.02247@cnnic.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Kari Hurtta , 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 Yao Jiankang wrote: > as you said, implementation of RFC 3030 is not common while 8BITMIME is popular. > > So implementing EAI with 8BITMIME support is easier than implementing EAI with BINARYMIME support. > > On my view, I still prefer 8BITMIME support while announcing UTF8SMTP capability . The current text says that 8BITMIME is REQUIRED for conformant UTF8SMTP implementations. They are free to implement BINARYMIME if they want to, but it's not required. I think that's a wise choice. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Oct 08 19:28:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWi3z-0001tb-Q9; Sun, 08 Oct 2006 19:28:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWi3x-0001tA-IB for ima@ietf.org; Sun, 08 Oct 2006 19:28:05 -0400 Received: from ppsw-4.csi.cam.ac.uk ([131.111.8.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWhy5-00081X-6x for ima@ietf.org; Sun, 08 Oct 2006 19:22:03 -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]:39669) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1GWhy0-0003Wy-EZ (Exim 4.63) (return-path ); Mon, 09 Oct 2006 00:21:56 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1GWhy0-0003Wr-F6 (Exim 4.54) (return-path ); Mon, 09 Oct 2006 00:21:56 +0100 Date: Mon, 9 Oct 2006 00:21:56 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Kari Hurtta Subject: Re: [EAI] header (822) address syntax In-Reply-To: <5diriyjzpa.fsf@Hurtta06k.keh.iki.fi> Message-ID: References: <5diriyjzpa.fsf@Hurtta06k.keh.iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 5 Oct 2006, Kari Hurtta wrote: > > I think you mean [...] Thanks for the corrections. Tony. -- f.a.n.finch http://dotat.at/ FORTIES CROMARTY FORTH: SOUTHERLY 6 TO GALE 8, DECREASING 5 OR 6 LATER. RAIN OR SHOWERS. MODERATE OR GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 09 03:04:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWpBd-0002NB-5q; Mon, 09 Oct 2006 03:04:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWpBb-0002N1-Fl for ima@ietf.org; Mon, 09 Oct 2006 03:04:27 -0400 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWpBa-0001xC-1U for ima@ietf.org; Mon, 09 Oct 2006 03:04:27 -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-20041007) with ESMTP id k9974LEN009550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Oct 2006 10:04:21 +0300 Received: from siilo.fmi.fi by virkku.fmi.fi with ESMTP id k9974LeT030279 ; Mon, 9 Oct 2006 10:04:21 +0300 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id k9974LpR028889 ; Mon, 9 Oct 2006 10:04:21 +0300 Received: by siilo.fmi.fi id k9974KuE028886; Mon, 9 Oct 2006 10:04:20 +0300 Message-Id: <200610090704.k9974KuE028886@siilo.fmi.fi> Subject: Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP In-Reply-To: <45296EA7.4080309@alvestrand.no> To: Harald Alvestrand Date: Mon, 9 Oct 2006 10:04:20 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp1gate: 3 received headers rewritten with id 20061009/03379/01 X-Filter: smtp1gate: ID 3378/01, 1 parts scanned for known viruses X-Filter: virkku: ID 2084/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp1gate: ID 3378/01) report=BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Kari Hurtta , 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 >>> Harald Alvestrand > Kari Hurtta wrote: > > Harald Alvestrand writes in gmane.ietf.ima: > > > > > >> In draft-ietf-eai-downgrade-01 section 5, the editors have identified > >> a design decision that the WG needs to take: Whether to use an > >> encapsulation strategy or a conversion strategy when downgrading > >> messages from an UTF8SMTP user to an ASCII user. > >> > >> A few of us (editors + chairs) have had a discussion about this, and > >> reached a proposed resolution: > >> > >> - It is of paramount importance that ASCII users are able to interpret > >> downgraded messages without special software. Therefore, a conversion > >> approach MUST be used, and this will be documented in the next version. > >> > > > > Is there differences between these two strategies (encapsulation strategy > > and a conversion strategy) on what situations these strategies are > > possible when downgrading is required? > I'm sorry, but I can't parse this question. Can you try again? Lets assume that dowgrade is required for message Case 1) Select encapsulation strategy When this is succeed and when bounce is required ? Case 2) Select conversion strategy When this is succeed and when bounce is required ? / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 09 04:48:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWqoO-0005mH-B2; Mon, 09 Oct 2006 04:48:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWqoN-0005mC-C2 for ima@ietf.org; Mon, 09 Oct 2006 04:48:35 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWqoH-0003Te-TV for ima@ietf.org; Mon, 09 Oct 2006 04:48:35 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4670A25817F; Mon, 9 Oct 2006 10:45:58 +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 22739-03; Mon, 9 Oct 2006 10:45:53 +0200 (CEST) Received: from [172.28.60.246] (unknown [195.18.164.170]) by eikenes.alvestrand.no (Postfix) with ESMTP id 313462580D3; Mon, 9 Oct 2006 10:45:53 +0200 (CEST) Message-ID: <452A0CD7.5050705@alvestrand.no> Date: Mon, 09 Oct 2006 10:48:23 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kari Hurtta Subject: Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP References: <200610090704.k9974KuE028886@siilo.fmi.fi> In-Reply-To: <200610090704.k9974KuE028886@siilo.fmi.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: 7aafa0432175920a4b3e118e16c5cb64 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 Alvestrand >>>> >> Kari Hurtta wrote: >> >>> Harald Alvestrand writes in gmane.ietf.ima: >>> >>> >>> >>>> In draft-ietf-eai-downgrade-01 section 5, the editors have identified >>>> a design decision that the WG needs to take: Whether to use an >>>> encapsulation strategy or a conversion strategy when downgrading >>>> messages from an UTF8SMTP user to an ASCII user. >>>> >>>> A few of us (editors + chairs) have had a discussion about this, and >>>> reached a proposed resolution: >>>> >>>> - It is of paramount importance that ASCII users are able to interpret >>>> downgraded messages without special software. Therefore, a conversion >>>> approach MUST be used, and this will be documented in the next version. >>>> >>>> >>> Is there differences between these two strategies (encapsulation strategy >>> and a conversion strategy) on what situations these strategies are >>> possible when downgrading is required? >>> >> I'm sorry, but I can't parse this question. Can you try again? >> > > Lets assume that dowgrade is required for message > > Case > 1) Select encapsulation strategy > > When this is succeed and when bounce is required > > Case > > 2) Select conversion strategy > > When this is succeed and when bounce is required ? > In both cases, the message has to bounce when the senders' email address cannot be represented to the recipient in an usable format (that is, on the From: line of the message, not inside any encapsulation). Otherwise "reply" won't work. I think the same has to apply to To: and Cc: addresses (same argument, but for "reply all"), but am not 100% sure here. Anyway, the decision seems to be to go for the conversion strategy. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 09 07:13:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWt47-0008Se-2U; Mon, 09 Oct 2006 07:12:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWt45-0008SV-QC for ima@ietf.org; Mon, 09 Oct 2006 07:12:57 -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 1GWt41-00029M-9u for ima@ietf.org; Mon, 09 Oct 2006 07:12:57 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1GWt3z-0003py-EG; Mon, 09 Oct 2006 07:12:52 -0400 Date: Sun, 08 Oct 2006 10:57:30 -0400 From: John C Klensin To: Kari Hurtta , ima@ietf.org Subject: Re: 8BITMIME (Re: [EAI] Re: Comment about draft-ietf-eai-smtpext-01.txt) Message-ID: X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Sunday, October 08, 2006 14:48 +0300 Kari Hurtta wrote: > "Yao Jiankang" writes in gmane.ietf.ima: > >> as you said, implementation of RFC 3030 is not common while >> 8BITMIME is popular. >> >> So implementing EAI with 8BITMIME support is easier than >> implementing EAI with BINARYMIME support. >> >> On my view, I still prefer 8BITMIME support while announcing >> UTF8SMTP capability . >> >> >> Yao Jiankang. > > > My impression is that most MTAs are lying when then announce > 8BITMIME capacity. > > Announcement of 8BITMIME includes promise of downgrading > message. I know some MTAs which can be configured to announce > 8BITMIME although they newer will downgrade message. Actually, it includes no such promise. Read the spec carefully. 8BITMIME can be announced/advertised if one can accept and handle it properly. "Properly" includes either downgrading or bouncing when a next-hop is encountered that does not support the option. If I'm an SMTP server and announce and accept 8BITMIME content, I am obligated to not trash the bits. But, if then become an SMTP client and the next hop does not offer the option, I may bounce as an alternative to downgrading. In particular, the text says: A client SMTP has two options in this case: first, it may implement a gateway transformation to convert the message into valid 7bit MIME, or second, or may treat this as a permanent error and handle it in the usual manner for delivery failures. > Effectively 8BITMIME is mutated to be "I'm 8-bit clean" but do > not include promise that message can be delivered without that > 8-bit is lost on rest of path. It is a bit more than "8 bit clean", since meaningful MIME support is required. > I'm thinking of idea that UTF8SMTP itself (without 8BITMIME) > includes promise of 8-bit clean implementation. Then without > 8BITMIME it just means bounce if next hop requires > downgrading. I don't see that, perhaps because you meant "with" in one of the two places where you wrote "without", but even then. UTF8SMTP requires support for UTF-8 headers, which implies rather different parsing flags/ conditions than normal MIME/822 headers. It might even change the format of the trace fields inserted by the MTA, although I personally continue to resist that for other reasons. > Hmm. However that means problems if next hop announces > UTF8SMTP without 8BITMIME and message was received with > BODY=8BITMIME. This means that message body must be converted > (otherwise MTA is laying about 8BITMIME announcement) but > headers can be kept on utf-8. You are identifying some, but only some, of the reasons why the initial specs suggested that 8BITMIME was a requirement. Without it, not only does one have to face this problem, but a whole series of header encoding problems as well. But let's turn this around, using the principle that having more different options and way of doing things is typically a threat to interoperability, not a help. Do you have a strong argument for _not_ requiring that 8BITMIME be supported if UTF8SMTP is? It is pretty easy to demonstrate why having them linked makes things easier... I think that demonstration has been provided already. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 09 07:41:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWtW0-000162-9X; Mon, 09 Oct 2006 07:41:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWtVz-00011R-37 for ima@ietf.org; Mon, 09 Oct 2006 07:41:47 -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 1GWtVx-0002Zf-9O for ima@ietf.org; Mon, 09 Oct 2006 07:41:47 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1GWtVv-00044U-Pg; Mon, 09 Oct 2006 07:41:45 -0400 Date: Mon, 09 Oct 2006 07:41:41 -0400 From: John C Klensin To: Kari Hurtta , ima@ietf.org Message-ID: X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: [EAI] BODY=8BITMIME or BINARYMIME (was: Re: Comment about draft-ietf-eai-smtpext-01.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Sunday, October 08, 2006 10:36 +0300 Kari Hurtta=20 wrote: > It occurs me that it is somewhat unclear what BODY -values can > be on EAI mail. > > If non-ascii characters is only on envelope, can it be: > > MAIL FROM: = BODY=3D7BIT > ALT-ADDRESS=3Dsupport@example.com > RCPT TO: > DATA > From: support@example.com > To: user@example.org > Subject: Ticket #XYC-234-VNC > > Ticket closed. > . This definitely needs some clarification. First, I don't think it is required to have BODY=3D8BITMIME = unless=20 that is true. The clear requirement is that the server support=20 and announce the 8BITMIME option. After that, the UTF8SMTP=20 option controls what happens to the headers. In principle, that = means one could have either BODY=3D option. I believe that: (1) we should require BODY=3D8BITMIME be = supported=20 by all clients and servers. If nothing else, this is part of=20 our philosophy, discussed long ago, that i18n mail should not be = supported except by fairly capable servers and clients. (2) We=20 might provide for BINARYMIME with a "MAY" option -- i.e., one=20 could support it if desired -- but I'd be much more inclined in=20 that direction if someone could show enough implementations and=20 operational experience with 3030 to get it moved to DRAFT, more=20 or less now. If there is no ability or motivation to do that, I = don't think we should waste time on it. > In other hands if it is required to use BODY=3D8BITMIME, then > also BODY=3DBINARYMIME is forbidded. One can't have both on the same message. But BINARYMIME doesn't = change the syntax or mechanisms of the headers, only that of=20 body parts (which is clear from the description). So I don't=20 see any conflict, i.e., parameters of UTF8HEADERS implies 7BIT body and 8bit, line-oriented = headers UTF8HEADERS+8BITMIME implies line-oriented 8bit body and=20 8bit, line-oriented headers UTF8HEADERS+BINARYMIME implies arbitrary bitstream binary=20 body in 8bit transmission form and 8bit, line-oriented headers. Does that seem plausible? john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 09 08:08:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWtvG-0007lW-Eb; Mon, 09 Oct 2006 08:07:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWtvE-0007kS-So for ima@ietf.org; Mon, 09 Oct 2006 08:07:52 -0400 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWtv8-0008Q1-8A for ima@ietf.org; Mon, 09 Oct 2006 08:07:52 -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-20041007) with ESMTP id k99C7ikM022446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Oct 2006 15:07:44 +0300 Received: from siilo.fmi.fi by virkku.fmi.fi with ESMTP id k99C7iIW015334 ; Mon, 9 Oct 2006 15:07:44 +0300 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id k99C7hTb031590 ; Mon, 9 Oct 2006 15:07:43 +0300 Received: by siilo.fmi.fi id k99C7hlw031587; Mon, 9 Oct 2006 15:07:43 +0300 Message-Id: <200610091207.k99C7hlw031587@siilo.fmi.fi> In-Reply-To: To: John C Klensin Date: Mon, 9 Oct 2006 15:07:43 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp1gate: 3 received headers rewritten with id 20061009/04941/01 X-Filter: smtp1gate: ID 4940/01, 1 parts scanned for known viruses X-Filter: virkku: ID 3595/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-1.9 required=5 (smtp1gate: ID 4940/01) report=AWL,BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ima@ietf.org, Kari Hurtta Subject: [EAI] Re: BODY=8BITMIME or BINARYMIME (was: Re: Comment about draft-ietf-eai-smtpext-01.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >>> John C Klensin > One can't have both on the same message. But BINARYMIME doesn't > change the syntax or mechanisms of the headers, only that of > body parts (which is clear from the description). So I don't > see any conflict, i.e., parameters of > > UTF8HEADERS implies 7BIT body and 8bit, line-oriented headers > > UTF8HEADERS+8BITMIME implies line-oriented 8bit body and > 8bit, line-oriented headers > > UTF8HEADERS+BINARYMIME implies arbitrary bitstream binary > body in 8bit transmission form and 8bit, line-oriented headers. > > Does that seem plausible? Yes. > john / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 09 08:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWuCf-0001qr-H5; Mon, 09 Oct 2006 08:25:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWuCe-0001qb-Ai for ima@ietf.org; Mon, 09 Oct 2006 08:25: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 1GWuCd-0005C3-1P for ima@ietf.org; Mon, 09 Oct 2006 08:25:52 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1GWuCa-0004Sp-1C; Mon, 09 Oct 2006 08:25:48 -0400 Date: Mon, 09 Oct 2006 08:25:45 -0400 From: John C Klensin To: Kari Hurtta Message-ID: <2A9DA6D5180D5160BF9CD9CE@as-s2n> In-Reply-To: <200610091207.k99C7hlw031587@siilo.fmi.fi> References: <200610091207.k99C7hlw031587@siilo.fmi.fi> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ima@ietf.org Subject: [EAI] Re: BODY=8BITMIME or BINARYMIME (was: Re: Comment about draft-ietf-eai-smtpext-01.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, October 09, 2006 15:07 +0300 Kari Hurtta wrote: >>>> John C Klensin >> One can't have both on the same message. But BINARYMIME >> doesn't change the syntax or mechanisms of the headers, only >> that of body parts (which is clear from the description). >> So I don't see any conflict, i.e., parameters of >> >> UTF8HEADERS implies 7BIT body and 8bit, line-oriented >> headers >> >> UTF8HEADERS+8BITMIME implies line-oriented 8bit body and >> 8bit, line-oriented headers >> >> UTF8HEADERS+BINARYMIME implies arbitrary bitstream binary >> body in 8bit transmission form and 8bit, line-oriented >> headers. >> >> Does that seem plausible? > > Yes. Yao, if others agree, can we get this into the spec? Would you like me to draft text, or can you manage that? john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 09 09:26:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWv90-0006IG-HB; Mon, 09 Oct 2006 09:26:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWv8y-0006I0-Ro for ima@ietf.org; Mon, 09 Oct 2006 09:26:09 -0400 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWutY-0002dB-No for ima@ietf.org; Mon, 09 Oct 2006 09:10:17 -0400 Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@siilo.fmi.fi) by smtp1gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20041007) with ESMTP id k99DABc3025317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Oct 2006 16:10:11 +0300 Received: from siilo.fmi.fi by torkku.fmi.fi with ESMTP id k99DABWi006761 ; Mon, 9 Oct 2006 16:10:11 +0300 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id k99DAAC9003015 ; Mon, 9 Oct 2006 16:10:10 +0300 Received: by siilo.fmi.fi id k99DAARt003012; Mon, 9 Oct 2006 16:10:10 +0300 Message-Id: <200610091310.k99DAARt003012@siilo.fmi.fi> In-Reply-To: <2A9DA6D5180D5160BF9CD9CE@as-s2n> To: John C Klensin Date: Mon, 9 Oct 2006 16:10:10 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp1gate: 3 received headers rewritten with id 20061009/05266/01 X-Filter: smtp1gate: ID 5265/01, 1 parts scanned for known viruses X-Filter: torkku: ID 1186/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2 required=5 (smtp1gate: ID 5265/01) report=AWL,BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ima@ietf.org, Kari Hurtta Subject: [EAI] Re: BODY=8BITMIME or BINARYMIME (was: Re: Comment about draft-ietf-eai-smtpext-01.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >>> John C Klensin > > > --On Monday, October 09, 2006 15:07 +0300 Kari Hurtta > wrote: > > >>>> John C Klensin > >> One can't have both on the same message. But BINARYMIME > >> doesn't change the syntax or mechanisms of the headers, only > >> that of body parts (which is clear from the description). > >> So I don't see any conflict, i.e., parameters of > >> > >> UTF8HEADERS implies 7BIT body and 8bit, line-oriented > >> headers > >> > >> UTF8HEADERS+8BITMIME implies line-oriented 8bit body and > >> 8bit, line-oriented headers > >> > >> UTF8HEADERS+BINARYMIME implies arbitrary bitstream binary > >> body in 8bit transmission form and 8bit, line-oriented > >> headers. > >> > >> Does that seem plausible? > > > > Yes. > > Yao, if others agree, can we get this into the spec? Would you > like me to draft text, or can you manage that? You can draft it. > john / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 09 09:36:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWvJ0-0004tT-En; Mon, 09 Oct 2006 09:36:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWvIz-0004tO-HP for ima@ietf.org; Mon, 09 Oct 2006 09:36:29 -0400 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWvIx-0002PX-0k for ima@ietf.org; Mon, 09 Oct 2006 09:36:29 -0400 Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@leija.mh.fmi.fi) by smtp1gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20041007) with ESMTP id k99DaPDN026519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 Oct 2006 16:36:25 +0300 Received: from leija.fmi.fi by torkku.fmi.fi with ESMTP id k99DaPoM007073 for ; Mon, 9 Oct 2006 16:36:25 +0300 Received: from leija.fmi.fi ([127.0.0.1]) by leija.fmi.fi with ESMTP id k99DaO7o012915 for ; Mon, 9 Oct 2006 16:36:24 +0300 Received: by leija.fmi.fi id k99DaOGp012912; Mon, 9 Oct 2006 16:36:24 +0300 From: Kari Hurtta To: ima@ietf.org Subject: Re: 8BITMIME (Re: [EAI] Re: Comment about draft-ietf-eai-smtpext-01.txt) References: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 Date: 09 Oct 2006 16:36:24 +0300 In-Reply-To: Message-ID: <5dmz85627b.fsf@leija.fmi.fi> Lines: 70 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Filter: smtp1gate: 3 received headers rewritten with id 20061009/05412/01 X-Filter: smtp1gate: ID 5411/01, 1 parts scanned for known viruses X-Filter: torkku: ID 1209/01, 1 parts scanned for known viruses X-Filter: leija.fmi.fi: 1 received headers rewritten with id 20061009/16869/01 X-Filter: leija.fmi.fi: ID 16869/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.2 required=5 (smtp1gate: ID 5411/01) report=AWL,BAYES_00 X-Spam-Score: 0.0 (/) 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 John C Klensin writes: > --On Sunday, October 08, 2006 14:48 +0300 Kari Hurtta > wrote in gmane.ietf.ima: > > > "Yao Jiankang" writes in gmane.ietf.ima: > > > >> as you said, implementation of RFC 3030 is not common while > >> 8BITMIME is popular. > >> > >> So implementing EAI with 8BITMIME support is easier than > >> implementing EAI with BINARYMIME support. > >> > >> On my view, I still prefer 8BITMIME support while announcing > >> UTF8SMTP capability . > >> > >> > >> Yao Jiankang. > > > > > > My impression is that most MTAs are lying when then announce > > 8BITMIME capacity. > > > > Announcement of 8BITMIME includes promise of downgrading > > message. I know some MTAs which can be configured to announce > > 8BITMIME although they newer will downgrade message. > > Actually, it includes no such promise. Read the spec > carefully. 8BITMIME can be announced/advertised if one can accept and > handle it properly. "Properly" includes either downgrading or > bouncing when a next-hop is encountered that does not support the > option. If I'm an SMTP server and announce and accept 8BITMIME > content, I am obligated to not trash the bits. But, if then become an > SMTP client and the next hop does not offer the option, I may bounce > as an alternative to downgrading. In particular, the text says: > > A client SMTP has two options in this case: first, it may > implement a gateway transformation to convert the message > into valid 7bit MIME, or second, or may treat this as a > permanent error and handle it in the usual manner for > delivery failures. > > > Effectively 8BITMIME is mutated to be "I'm 8-bit clean" but do > > not include promise that message can be delivered without that > > 8-bit is lost on rest of path. > > It is a bit more than "8 bit clean", since meaningful MIME support is > required. Following is one example of mailer. Quote from documentation: 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. This either do not mention that it will bounce message. Another example of mailer: http://cr.yp.to/smtp/8bitmime.html ( http://www-dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 09 10:35:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwEC-00007t-PS; Mon, 09 Oct 2006 10:35:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwEB-0008Uv-M4 for ima@ietf.org; Mon, 09 Oct 2006 10:35:35 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwE6-0003kp-0h for ima@ietf.org; Mon, 09 Oct 2006 10:35:35 -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.231) id 452a5e2d.13a4d.34a for ima@ietf.org; Mon, 9 Oct 2006 15:35: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 k99EZMk0010771 for ; Mon, 9 Oct 2006 15:35:24 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP References: <44E1B2D5.8040105@alvestrand.no> <5d64ewjwz3.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Mon, 09 Oct 2006 15:35:22 +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: <5d64ewjwz3.fsf@Hurtta06k.keh.iki.fi> 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 Sat, 07 Oct 2006 10:28:48 +0100, Kari Hurtta wrote: > Harald Alvestrand writes in gmane.ietf.ima: >> - It is of paramount importance that ASCII users are able to interpret >> downgraded messages without special software. Therefore, a conversion >> approach MUST be used, and this will be documented in the next version. > > Is there differences between these two strategies (encapsulation strategy > and a conversion strategy) on what situations these strategies are > possible when downgrading is required? Yes, there is a difference snd the chairs, have made the right call. Dealing with an encapsulated message in my inbox is a coufounded nuisance. OTOH, there may be a few cases where UTF8smtp is not implemented (or properly implemented) on the intended route when a sender may choose _manually_ to encapsulate his message if he cannot get it through any other way. -- 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 Oct 09 10:37:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwGR-00025B-D2; Mon, 09 Oct 2006 10:37:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwGP-00023I-K1 for ima@ietf.org; Mon, 09 Oct 2006 10:37:53 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwGO-0004Ie-3M for ima@ietf.org; Mon, 09 Oct 2006 10:37:53 -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.231) id 452a5ebf.12757.1d0 for ima@ietf.org; Mon, 9 Oct 2006 15:37: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 k99Ebnje010923 for ; Mon, 9 Oct 2006 15:37:50 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] Re: Comment about draft-ietf-eai-smtpext-01.txt References: <359811996.18208@cnnic.cn> <005901c6eaa8$d2f191d0$1206e29f@cnnicyao> Message-ID: Date: Mon, 09 Oct 2006 15:37:49 +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: <005901c6eaa8$d2f191d0$1206e29f@cnnicyao> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, 08 Oct 2006 08:10:23 +0100, Yao Jiankang wrote: > > > as you said, implementation of RFC 3030 is not common while 8BITMIME is > popular. > > So implementing EAI with 8BITMIME support is easier than implementing > EAI with BINARYMIME support. I doubt that any server that ofers BINARYMIME fails to offer 8BITMIME as well, so the question hardly arises. -- 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 Oct 09 11:00:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwc5-0004GR-LM; Mon, 09 Oct 2006 11:00:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwWe-0002wN-Qm for ima@ietf.org; Mon, 09 Oct 2006 10:54:40 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwP9-0005aH-3u for ima@ietf.org; Mon, 09 Oct 2006 10:46:56 -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.231) id 452a60de.4371.161 for ima@ietf.org; Mon, 9 Oct 2006 15:46:54 +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 k99Ekqaq011478 for ; Mon, 9 Oct 2006 15:46:52 +0100 (BST) To: ima@ietf.org Subject: Re: 8BITMIME (Re: [EAI] Re: Comment about draft-ietf-eai-smtpext-01.txt) References: <359811996.18208@cnnic.cn> <360291422.02247@cnnic.cn> <5dvemv81vy.fsf_-_@Hurtta06k.keh.iki.fi> Message-ID: Date: Mon, 09 Oct 2006 15:46:51 +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: <5dvemv81vy.fsf_-_@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, 08 Oct 2006 12:48:01 +0100, Kari Hurtta wrote: > "Yao Jiankang" writes in gmane.ietf.ima: > >> as you said, implementation of RFC 3030 is not common while 8BITMIME is >> popular. >> >> So implementing EAI with 8BITMIME support is easier than implementing >> EAI with BINARYMIME support. >> >> On my view, I still prefer 8BITMIME support while announcing UTF8SMTP >> capability . >> >> >> Yao Jiankang. > > > My impression is that most MTAs are lying when then announce 8BITMIME > capacity. > > Announcement of 8BITMIME includes promise of downgrading message. > I know some MTAs which can be configured to announce 8BITMIME although > they newer will downgrade message. Yes, it is well known that happens, and it usually works because nearly all servers support 8BITMIME, so downgrading is almost never needed. But it is not our job to get involved in the rights and wrongs of that. OTOH, is is NOT true that bearly all servers are 8-bit clean as regards the headers (sendmail is the most notable one that isn't). Therefore we need to write our standard so that downgrading (or maybe rerouting) is REQUIRED. Perhaps in 15 years time when all servers can be considered 8-bit clean in the headers, people will start omitting the downgrade code even if they announce UTF8SMTP (maybe some future standard may even make that official). But again it is not our job to take that decision now. -- 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 Oct 09 12:14:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxm6-0007wD-4Y; Mon, 09 Oct 2006 12:14:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxm4-0007w8-Na for ima@ietf.org; Mon, 09 Oct 2006 12:14:41 -0400 Received: from smtp4.pp.htv.fi ([213.243.153.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWxm3-0001jL-CZ for ima@ietf.org; Mon, 09 Oct 2006 12:14:40 -0400 Received: from Hurtta06k.keh.iki.fi (cs181108174.pp.htv.fi [82.181.108.174]) by smtp4.pp.htv.fi (Postfix) with ESMTP id 3A5C35BC0B7 for ; Mon, 9 Oct 2006 19:14:33 +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 k99GEWAW010052 for ; Mon, 9 Oct 2006 19:14:32 +0300 Received: (from hurtta@localhost) by Hurtta06k.keh.iki.fi (8.13.4/8.13.4/Submit) id k99GEWjo010051 for ima@ietf.org; Mon, 9 Oct 2006 19:14:32 +0300 Message-Id: <200610091614.k99GEWjo010051@Hurtta06k.keh.iki.fi> To: EAI mailing list Date: Mon, 9 Oct 2006 19:14:32 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version ME+ 2.5 PLalpha11+] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [EAI] "downgrade must able to fail" -- or comment about draft-ietf-eai-smtpext-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Perhaps there is needed warning that downgrading EAI message must be able to fail. In other words MTA must be prepared to bounce message if downgrade is not possible. That means that downgrade must be done before MTA issues DATA -command. Sendmail does that mistake when it is downgrading 8BITMIME messages. It does downgrading on fly and therefore is not able to bounce message if downgrade is not possible. / Kari Hurtta ( documentation: $=s contains the set of subtypes of message that can be treated recursively. By default it contains only "rfc822". Other "message/*" types cannot be 8->7 bit encoded. If a message containing eight bit data is sent to a seven bit host, and that message cannot be encoded into seven bits, it will be stripped to 7 bits. ) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 09 12:55:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWyPc-0000eW-Qv; Mon, 09 Oct 2006 12:55:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWyPb-0000W5-Iv for ima@ietf.org; Mon, 09 Oct 2006 12:55:31 -0400 Received: from mail146.messagelabs.com ([216.82.245.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GWyPX-0000u7-AE for ima@ietf.org; Mon, 09 Oct 2006 12:55:31 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-13.tower-146.messagelabs.com!1160412926!855595!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.67] Received: (qmail 19081 invoked from network); 9 Oct 2006 16:55:26 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.67) by server-13.tower-146.messagelabs.com with SMTP; 9 Oct 2006 16:55:26 -0000 Received: from [135.210.128.219] (unknown[135.210.128.219](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20061009165525gw100re3a8e> (Authid: tony); Mon, 9 Oct 2006 16:55:26 +0000 Message-ID: <452A7EFA.1040600@att.com> Date: Mon, 09 Oct 2006 12:55:22 -0400 From: Tony Hansen User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 CC: ima@ietf.org Subject: Re: [EAI] BODY=8BITMIME or BINARYMIME (was: Re: Comment about draft-ietf-eai-smtpext-01.txt) References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > > One can't have both on the same message. But BINARYMIME doesn't change > the syntax or mechanisms of the headers, only that of body parts (which > is clear from the description). So I don't see any conflict, i.e., > parameters of > > UTF8HEADERS implies 7BIT body and 8bit, line-oriented headers > > UTF8HEADERS+8BITMIME implies line-oriented 8bit body and 8bit, > line-oriented headers > > UTF8HEADERS+BINARYMIME implies arbitrary bitstream binary body in 8bit > transmission form and 8bit, line-oriented headers. > > Does that seem plausible? consistent and plausible Tony _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 09 15:38:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX0x3-00034Q-2o; Mon, 09 Oct 2006 15:38:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX0x1-00034L-AI for ima@ietf.org; Mon, 09 Oct 2006 15:38:11 -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 1GX0wv-0003ba-Sv for ima@ietf.org; Mon, 09 Oct 2006 15:38:11 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GX0wv-000872-DP; Mon, 09 Oct 2006 15:38:05 -0400 Date: Mon, 09 Oct 2006 15:38:04 -0400 From: John C Klensin To: Kari Hurtta , ima@ietf.org Subject: Re: 8BITMIME (Re: [EAI] Re: Comment about draft-ietf-eai-smtpext-01.txt) Message-ID: <1F937D35D41D7AF177441A71@p3.JCK.COM> In-Reply-To: <5dmz85627b.fsf@leija.fmi.fi> References: <5dmz85627b.fsf@leija.fmi.fi> X-Mailer: Mulberry/4.0.6 (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: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 09 October, 2006 16:36 +0300 Kari Hurtta wrote: >... > Following is one example of mailer. Quote from documentation: > > 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. I did not claim that there were no stupid, lying, non-conformant systems out there. Of course there are. The assertion here that "the modern Internet is completely 8-bit transparent and clean" is just nonsense... unless, of course, one defines any system that doesn't meet their criteria for "8-bit transparent and clean" as "not modern". The rule is exactly as I stated it: if they advertise the option, they are required to either downgrade or bounce. The advice above is equivalent to "'just send 8' and advertise the 8BITMIME option so as to give permission for that". It _will_ cause problems and, certainly, it is not an excuse for encouraging similar things in eai-smtpext. > This either do not mention that it will bounce message. See above. > Another example of mailer: http://cr.yp.to/smtp/8bitmime.html > ( http://www-dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html ) And that particular system is widely known to be non-conformant with 2821 as well as with many of the associated options/extensions. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 09 16:05:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1NS-0003gC-V3; Mon, 09 Oct 2006 16:05:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX1NS-0003g2-5Z for ima@ietf.org; Mon, 09 Oct 2006 16:05:30 -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 1GX1N7-0000wB-Db for ima@ietf.org; Mon, 09 Oct 2006 16:05:30 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1GX1N4-0008Mc-Ef; Mon, 09 Oct 2006 16:05:06 -0400 Date: Mon, 09 Oct 2006 16:03:05 -0400 From: John C Klensin To: Kari Hurtta , Harald Alvestrand Subject: Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP Message-ID: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, October 09, 2006 10:04 +0300 Kari Hurtta wrote: >> > Is there differences between these two strategies >> > (encapsulation strategy and a conversion strategy) on >> > what situations these strategies are possible when >> > downgrading is required? >> I'm sorry, but I can't parse this question. Can you try again? > > Lets assume that dowgrade is required for message > > Case > 1) Select encapsulation strategy > > When this is succeed and when bounce is required ? > > Case > > 2) Select conversion strategy > > When this is succeed and when bounce is required ? Let me take a shot at reviewing this... I hope we are in agreement by now that offering the possibility of both as alternatives in the specification would be a bad idea. One must be required (on either a "do it or bounce" basis, similar to 8BITMIME) and the other, at most, permitted as optional. Beyond that, each requires a fair amount of work relative to bouncing. Some implementations will do the work, with whatever option is selected. Others won't. It is not possible to estimate accurately how many would do either. My own guess is that, whatever choice we make, it won't have a very significant impact on the number of implementations that will choose to support downgrading. That is just a guess, but I don't think a decision can be made on projections of "(1) is more likely to be fully supported than (2)" or "(2) is more likely to be fully supported than (1)". So there is a "bounce" case for either option that results from "no downgrade implementation". Now, the questions seem to hinge on what you mean by "success". My criterion for "success" is "be deliverable with little or no information loss and have a good chance of figuring out how to reply, even if that requires out of band communications and information". Harald adds "being able to reply automatically". By Harald's criterion, encapsulation without _also_ doing most of the work of conversion is a non-starter. By mine, one might still consider encapsulation, but is would not be an easy sell. Does that answer your question? john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 09 20:44:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX5jh-0003uF-6R; Mon, 09 Oct 2006 20:44:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX5jf-0003uA-Ur for ima@ietf.org; Mon, 09 Oct 2006 20:44:43 -0400 Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX5jb-0005Sq-LV for ima@ietf.org; Mon, 09 Oct 2006 20:44:43 -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]:60928) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1GX5jW-0004Ht-4W (Exim 4.63) for ima@ietf.org (return-path ); Tue, 10 Oct 2006 01:44:34 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1GX5jW-00060L-AF (Exim 4.54) for ima@ietf.org (return-path ); Tue, 10 Oct 2006 01:44:34 +0100 Date: Tue, 10 Oct 2006 01:44:34 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ima@ietf.org Subject: Re: [EAI] BODY=8BITMIME or BINARYMIME (was: Re: Comment about draft-ietf-eai-smtpext-01.txt) In-Reply-To: <452A7EFA.1040600@att.com> Message-ID: References: <452A7EFA.1040600@att.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 9 Oct 2006, Tony Hansen wrote: > John C Klensin wrote: > > > > UTF8HEADERS implies 7BIT body and 8bit, line-oriented headers > > > > UTF8HEADERS+8BITMIME implies line-oriented 8bit body and 8bit, > > line-oriented headers > > > > UTF8HEADERS+BINARYMIME implies arbitrary bitstream binary body in 8bit > > transmission form and 8bit, line-oriented headers. > > > > Does that seem plausible? > > consistent and plausible Agreed. http://fanf.livejournal.com/64533.html I note that CHUNKING is part of the Lemonade profile, so more implementations should be appearing. Whether they also support BINARYMIME remains to be seen. Tony. -- f.a.n.finch http://dotat.at/ FORTIES CROMARTY FORTH: SOUTHERLY 6 TO GALE 8, DECREASING 5 OR 6 LATER. RAIN OR SHOWERS. MODERATE OR GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 09 21:33:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6UR-0005Ee-ND; Mon, 09 Oct 2006 21:33:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX6UR-0005EZ-7Z for ima@ietf.org; Mon, 09 Oct 2006 21:33:03 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GX6UP-0001WJ-6x for ima@ietf.org; Mon, 09 Oct 2006 21:33:03 -0400 Received: (eyou send program); Tue, 10 Oct 2006 09:32:47 +0800 Message-ID: <360443967.13923@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Tue, 10 Oct 2006 09:32:47 +0800 Message-ID: <04bd01c6ec0c$00710f50$1206e29f@cnnicyao> From: "Yao Jiankang" To: "Kari Hurtta" References: <360410499.30927@cnnic.cn> Subject: Re: [EAI] "downgrade must able to fail" -- or comment about draft-ietf-eai-smtpext-01.txt Date: Tue, 10 Oct 2006 09:32:49 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: EAI mailing list 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="===============0676422491==" Errors-To: ima-bounces@ietf.org --===============0676422491== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkthcmkgSHVydHRhIiA8aHVy dHRhK2lldGZAc2lpbG8uZm1pLmZpPg0KVG86ICJFQUkgbWFpbGluZyBsaXN0IiA8aW1hQGlldGYu b3JnPg0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxMCwgMjAwNiAxMjoxNCBBTQ0KU3ViamVjdDog W0VBSV0gImRvd25ncmFkZSBtdXN0IGFibGUgdG8gZmFpbCIgLS0gb3IgY29tbWVudCBhYm91dCBk cmFmdC1pZXRmLWVhaS1zbXRwZXh0LTAxLnR4dA0KDQoNCj4gDQo+IFBlcmhhcHMgdGhlcmUgaXMg bmVlZGVkIHdhcm5pbmcgdGhhdCBkb3duZ3JhZGluZw0KPiBFQUkgbWVzc2FnZSBtdXN0IGJlIGFi bGUgdG8gZmFpbC4NCj4gDQo+IEluIG90aGVyIHdvcmRzIE1UQSBtdXN0IGJlIHByZXBhcmVkIHRv IGJvdW5jZQ0KPiBtZXNzYWdlIGlmIGRvd25ncmFkZSBpcyBub3QgcG9zc2libGUuDQo+IA0KPiBU aGF0IG1lYW5zIHRoYXQgZG93bmdyYWRlIG11c3QgYmUgZG9uZSBiZWZvcmUgDQo+IE1UQSBpc3N1 ZXMgREFUQSAtY29tbWFuZC4NCg0KWWVzLg0KRUFJIHNvbHV0aW9uIGhhcyBhbHJlYWR5IHByb3Zp ZGVkIHN1Y2ggbWVjaGFuaXNtLg0KQ2xpZW50IFNNVFAgaXNzdWVkIGEgRUhMTyBjb21tYW5kIHRv IFNlcnZlciBTTVRQLg0KaWYgIFNlcnZlciBTTVRQIGZhaWxlZCB0byByZXNwb25zZSB3aXRoIHRo ZSBVVEY4U01UUCBrZXl3b3Jkcy4NClRoZSBjbGllbnQgU01UUCB3aWxsIGJvdW5jZSB0aGUgbWVz c2FnZSBvciBkbyBzb21lIGRvd25ncmFkaW5nLg0KDQoNCllhbyBKaWFua2FuZw0KQ05OSUMNCg0K DQo+IA0KPiANCj4gU2VuZG1haWwgZG9lcyB0aGF0IG1pc3Rha2Ugd2hlbiBpdCBpcyBkb3duZ3Jh ZGluZw0KPiA4QklUTUlNRSBtZXNzYWdlcy4gSXQgZG9lcyBkb3duZ3JhZGluZyBvbiBmbHkNCj4g YW5kIHRoZXJlZm9yZSBpcyBub3QgYWJsZSB0byBib3VuY2UgbWVzc2FnZSBpZg0KPiBkb3duZ3Jh ZGUgaXMgbm90IHBvc3NpYmxlLg0KPiANCj4gLyBLYXJpIEh1cnR0YQ0KPiANCj4gKCBkb2N1bWVu dGF0aW9uOg0KPiANCj4gICAgICAkPXMgIGNvbnRhaW5zIHRoZSBzZXQgb2Ygc3VidHlwZXMgb2Yg bWVzc2FnZSB0aGF0ICBjYW4NCj4gICAgICAgICAgIGJlICB0cmVhdGVkICByZWN1cnNpdmVseS4g IEJ5IGRlZmF1bHQgaXQgY29udGFpbnMNCj4gICAgICAgICAgIG9ubHkgInJmYzgyMiIuICBPdGhl ciAibWVzc2FnZS8qIiB0eXBlcyBjYW5ub3QgYmUNCj4gICAgICAgICAgIDgtPjcgIGJpdCBlbmNv ZGVkLiAgSWYgYSBtZXNzYWdlIGNvbnRhaW5pbmcgZWlnaHQNCj4gICAgICAgICAgIGJpdCBkYXRh IGlzIHNlbnQgdG8gYSBzZXZlbiBiaXQgIGhvc3QsICBhbmQgIHRoYXQNCj4gICAgICAgICAgIG1l c3NhZ2UgIGNhbm5vdCAgYmUgIGVuY29kZWQgIGludG8gc2V2ZW4gYml0cywgaXQNCj4gICAgICAg ICAgIHdpbGwgYmUgc3RyaXBwZWQgdG8gNyBiaXRzLg0KPiANCj4gKQ0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlz dA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaW1h --===============0676422491== 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 --===============0676422491==-- From ima-bounces@ietf.org Tue Oct 10 00:45:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX9UD-00014v-Nr; Tue, 10 Oct 2006 00:45:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX9UC-00014l-EL for ima@ietf.org; Tue, 10 Oct 2006 00:45:00 -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 1GX9U7-0003Ql-5c for ima@ietf.org; Tue, 10 Oct 2006 00:45:00 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GX9Tv-0006TV-K7 for ima@ietf.org; Tue, 10 Oct 2006 06:44:43 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 06:44:43 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 06:44:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: 8BITMIME (Re: [EAI] Re: Comment about draft-ietf-eai-smtpext-01.txt) Date: 10 Oct 2006 07:44:33 +0300 Lines: 19 Message-ID: <5dejtgkcem.fsf@Hurtta06k.keh.iki.fi> References: <5dmz85627b.fsf@leija.fmi.fi> <1F937D35D41D7AF177441A71@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: > --On Monday, 09 October, 2006 16:36 +0300 Kari Hurtta > wrote: > > >... > > Following is one example of mailer. Quote from documentation: <...> > I did not claim that there were no stupid, lying, non-conformant > systems out there. Of course there are. The assertion here My text was: My impression is that most MTAs are lying when then announce 8BITMIME capacity Other was just explanation. But perhaps that "most" is incorrect. Perhaps it is just "some" ? / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 10 01:12:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX9uu-0005dP-EL; Tue, 10 Oct 2006 01:12:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX9ut-0005dH-90 for ima@ietf.org; Tue, 10 Oct 2006 01:12:35 -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 1GX9uq-0002tW-7j for ima@ietf.org; Tue, 10 Oct 2006 01:12:34 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GX9ug-00037p-4I for ima@ietf.org; Tue, 10 Oct 2006 07:12:22 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 07:12:22 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 07:12:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP Date: 10 Oct 2006 08:12:07 +0300 Lines: 67 Message-ID: <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Monday, October 09, 2006 10:04 +0300 Kari Hurtta > wrote: > > >> > Is there differences between these two strategies > >> > (encapsulation strategy and a conversion strategy) on > >> > what situations these strategies are possible when > >> > downgrading is required? > >> I'm sorry, but I can't parse this question. Can you try again? > > > > Lets assume that dowgrade is required for message > > > > Case > > 1) Select encapsulation strategy > > > > When this is succeed and when bounce is required ? > > > > Case > > > > 2) Select conversion strategy > > > > When this is succeed and when bounce is required ? > > Let me take a shot at reviewing this... > > I hope we are in agreement by now that offering the possibility of > both as alternatives in the specification would be a bad idea. > One must be required (on either a "do it or bounce" basis, similar to > 8BITMIME) and the other, at most, permitted as optional. > So there is a "bounce" case for either option that results from "no > downgrade implementation". Now, the questions seem to hinge on what > you mean by "success". My criterion for "success" is "be deliverable > with little or no information loss and have a good chance of figuring > out how to reply, even if that requires out of band communications and > information". Harald adds "being able to reply automatically". By > Harald's criterion, encapsulation without _also_ doing most of the > work of conversion is a non-starter. By mine, one might still > consider encapsulation, but is would not be an easy sell. > > Does that answer your question? > > john I was thinking requiring "conversion strategy", but I was looking cases where "encapsulation strategy" may succeed (when "conversion strategy" may require bounce.) If these cases ("conversion strategy" bounces, "encapsulation strategy" succees), are many, then "encapsulation strategy" should have permitted as optional. ( Although I suspect that most of implementions will generate mime encoding words (RFC 2047) incorrectly. Correctly parsing mail headers seems hard problem. So that RFC 2047 encoding is applied syntaxtically correct places. Generally MTAs do not have parses which handles all syntax. Just some parser for address headers (not for other headers.) That using RFC 2047 (syntaxtically correct places) was required on "conversion strategy". ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 10 02:28:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXB6P-00089f-GG; Tue, 10 Oct 2006 02:28:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXB6O-00089a-CC for ima@ietf.org; Tue, 10 Oct 2006 02:28:32 -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 1GXB6K-0008F5-Uu for ima@ietf.org; Tue, 10 Oct 2006 02:28:32 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXB5q-000246-Dc for ima@ietf.org; Tue, 10 Oct 2006 08:27:58 +0200 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 08:27:58 +0200 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 08:27:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Encapsulation is required (for some headers) (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) Date: 10 Oct 2006 09:27:50 +0300 Lines: 43 Message-ID: <5dzmc4d6s9.fsf_-_@leija.fmi.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes: > ( Although I suspect that most of implementions will generate mime > encoding words (RFC 2047) incorrectly. Correctly parsing mail > headers seems hard problem. So that RFC 2047 encoding is applied > syntaxtically correct places. > > Generally MTAs do not have parses which handles all syntax. Just > some parser for address headers (not for other headers.) > > That using RFC 2047 (syntaxtically correct places) was required on > "conversion strategy". > ) Encapsulation is required for some headers. That is needed for future compatibility. Otherwise MTAs is required to know syntax of all headers (including these standards which are not yet written.) There must be encapsulation (as opposite of "conversion strategy") for headers which MTA do not know. I suggest that conversion is limited to RFC 2822 headers and syntax. All other headers (and headers with obsolete syntax on RFC 2822) are encapsulated. (If on result have missing required headers, then there is bounce option.) Or perhaps it can be considered to limited more: - Only convert Subject: From: To: Cc: Reply-To: and correspond Resend-* headers. - All other headers are encapsulated (if downgrading is required) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 10 03:46:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXCIy-0005eJ-DR; Tue, 10 Oct 2006 03:45:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXCIx-0005e2-2n for ima@ietf.org; Tue, 10 Oct 2006 03:45:35 -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 1GXCIv-0004AN-Lx for ima@ietf.org; Tue, 10 Oct 2006 03:45:35 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GXCIu-000E0K-TG; Tue, 10 Oct 2006 03:45:33 -0400 Date: Tue, 10 Oct 2006 03:45:32 -0400 From: John C Klensin To: Kari Hurtta , ima@ietf.org Subject: Re: Encapsulation is required (for some headers) (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) Message-ID: In-Reply-To: <5dzmc4d6s9.fsf_-_@leija.fmi.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> X-Mailer: Mulberry/4.0.6 (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: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari, Before I try to comment on this, could you be absolutely clear about what you mean by "encapsulating headers"? I know, more or less, how to encapsulate a body part. I can probably devise ways to encapsulate an entire header set. But it seems to me that you are asking for/ requiring encapsulation of individual headers. john --On Tuesday, 10 October, 2006 09:27 +0300 Kari Hurtta wrote: > Kari Hurtta writes: > >> ( Although I suspect that most of implementions will generate >> mime encoding words (RFC 2047) incorrectly. Correctly >> parsing mail headers seems hard problem. So that RFC 2047 >> encoding is applied syntaxtically correct places. >> >> Generally MTAs do not have parses which handles all syntax. >> Just some parser for address headers (not for other >> headers.) >> >> That using RFC 2047 (syntaxtically correct places) was >> required on "conversion strategy". >> ) > > Encapsulation is required for some headers. > That is needed for future compatibility. > > Otherwise MTAs is required to know syntax of all headers > (including these standards which are not yet written.) > > There must be encapsulation (as opposite of "conversion > strategy") for headers which MTA do not know. > > I suggest that conversion is limited to RFC 2822 headers and > syntax. > > All other headers (and headers with obsolete syntax on RFC > 2822) are encapsulated. (If on result have missing required > headers, then there is bounce option.) > > Or perhaps it can be considered to limited more: > > - Only convert > Subject: > From: > To: > Cc: > Reply-To: > > and correspond Resend-* headers. > > - All other headers are encapsulated (if downgrading is > required) > > / 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 Tue Oct 10 04:33:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXD3M-0004Pf-VN; Tue, 10 Oct 2006 04:33:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXD3L-0004PM-K3 for ima@ietf.org; Tue, 10 Oct 2006 04:33:31 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXD3H-00068A-OC for ima@ietf.org; Tue, 10 Oct 2006 04:33:31 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k9A8XQQH024003 for ; Tue, 10 Oct 2006 17:33:26 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 70b2_ff7de9b6_5839_11db_9c7a_0014221fa3c9; Tue, 10 Oct 2006 17:33:25 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:41841) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 10 Oct 2006 17:33:10 +0900 Message-Id: <6.0.0.20.2.20061010173201.0797e0f0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 10 Oct 2006 17:32:11 +0900 To: Harald Alvestrand , Yao Jiankang From: Martin Duerst Subject: Re: [EAI] Re: Comment about draft-ietf-eai-smtpext-01.txt In-Reply-To: <45296F00.8010800@alvestrand.no> References: <359811996.18208@cnnic.cn> <360291422.02247@cnnic.cn> <45296F00.8010800@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Kari Hurtta , 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 I agree. Regards, Martin. At 06:34 06/10/09, Harald Alvestrand wrote: >Yao Jiankang wrote: >> as you said, implementation of RFC 3030 is not common while 8BITMIME is popular. >> >> So implementing EAI with 8BITMIME support is easier than implementing EAI with BINARYMIME support. >> >> On my view, I still prefer 8BITMIME support while announcing UTF8SMTP capability . >The current text says that 8BITMIME is REQUIRED for conformant UTF8SMTP implementations. >They are free to implement BINARYMIME if they want to, but it's not required. > >I think that's a wise choice. > > Harald > > >_______________________________________________ >IMA mailing list >IMA@ietf.org >https://www1.ietf.org/mailman/listinfo/ima #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 10 04:38:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXD7x-0007oq-Vd; Tue, 10 Oct 2006 04:38:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXD7w-0007ok-Ug for ima@ietf.org; Tue, 10 Oct 2006 04:38:16 -0400 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXD7v-0007Ic-EX for ima@ietf.org; Tue, 10 Oct 2006 04:38:16 -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-20041007) with ESMTP id k9A8c9eU025063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Oct 2006 11:38:09 +0300 Received: from siilo.fmi.fi by virkku.fmi.fi with ESMTP id k9A8c84Y023308 ; Tue, 10 Oct 2006 11:38:09 +0300 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id k9A8c8qA002896 ; Tue, 10 Oct 2006 11:38:08 +0300 Received: by siilo.fmi.fi id k9A8c8hb002893; Tue, 10 Oct 2006 11:38:08 +0300 Message-Id: <200610100838.k9A8c8hb002893@siilo.fmi.fi> Subject: Re: Encapsulation is required (for some headers) (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) In-Reply-To: To: John C Klensin Date: Tue, 10 Oct 2006 11:38:08 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp1gate: 3 received headers rewritten with id 20061010/08552/01 X-Filter: smtp1gate: ID 8551/01, 1 parts scanned for known viruses X-Filter: virkku: ID 6120/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp1gate: ID 8551/01) report=BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >>> John C Klensin > Kari, > > Before I try to comment on this, could you be absolutely clear > about what you mean by "encapsulating headers"? I know, more or > less, how to encapsulate a body part. I can probably devise > ways to encapsulate an entire header set. But it seems to me > that you are asking for/ requiring encapsulation of individual > headers. > > john I mean invidual headers, because all is not possible to downgraded that way that they are usefull. There is two possibilities. Either put these headers to new body part, or put them to some header Encapsulated: {header-name}: {RFC 2047 data} where {RFC 2047 data} is treated as unstructured. ( That was something also on Charles Lindsey's "Comments on draft-ietf-eai-downgrade-02". ) / Kari Hurtta > --On Tuesday, 10 October, 2006 09:27 +0300 Kari Hurtta > wrote: > > > Kari Hurtta writes: > > > >> ( Although I suspect that most of implementions will generate > >> mime encoding words (RFC 2047) incorrectly. Correctly > >> parsing mail headers seems hard problem. So that RFC 2047 > >> encoding is applied syntaxtically correct places. > >> > >> Generally MTAs do not have parses which handles all syntax. > >> Just some parser for address headers (not for other > >> headers.) > >> > >> That using RFC 2047 (syntaxtically correct places) was > >> required on "conversion strategy". > >> ) > > > > Encapsulation is required for some headers. > > That is needed for future compatibility. > > > > Otherwise MTAs is required to know syntax of all headers > > (including these standards which are not yet written.) > > > > There must be encapsulation (as opposite of "conversion > > strategy") for headers which MTA do not know. > > > > I suggest that conversion is limited to RFC 2822 headers and > > syntax. > > > > All other headers (and headers with obsolete syntax on RFC > > 2822) are encapsulated. (If on result have missing required > > headers, then there is bounce option.) > > > > Or perhaps it can be considered to limited more: > > > > - Only convert > > Subject: > > From: > > To: > > Cc: > > Reply-To: > > > > and correspond Resend-* headers. > > > > - All other headers are encapsulated (if downgrading is > > required) > > > > / 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 Tue Oct 10 05:59:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXEOJ-0000Ex-J4; Tue, 10 Oct 2006 05:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXEOH-000091-If for ima@ietf.org; Tue, 10 Oct 2006 05:59:13 -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 1GXEOG-0007w5-8K for ima@ietf.org; Tue, 10 Oct 2006 05:59:13 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXENR-0001UO-4m for ima@ietf.org; Tue, 10 Oct 2006 11:58:21 +0200 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 11:58:21 +0200 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 11:58:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Kari Hurtta" Subject: Re: [EAI] "downgrade must able to fail" -- or comment about draft-ietf-eai-smtpext-01.txt Date: 10 Oct 2006 12:57:26 +0300 Lines: 44 Message-ID: <5dac447at5.fsf@leija.fmi.fi> References: <360410499.30927@cnnic.cn> <360443967.13923@cnnic.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 "Yao Jiankang" writes in gmane.ietf.ima: > ----- Original Message ----- > From: "Kari Hurtta" > To: "EAI mailing list" > Sent: Tuesday, October 10, 2006 12:14 AM > Subject: [EAI] "downgrade must able to fail" -- or comment about draft-ietf-eai-smtpext-01.txt > > > Perhaps there is needed warning that downgrading > > EAI message must be able to fail. > > > > In other words MTA must be prepared to bounce > > message if downgrade is not possible. > > > > That means that downgrade must be done before > > MTA issues DATA -command. > > Yes. > EAI solution has already provided such mechanism. > Client SMTP issued a EHLO command to Server SMTP. > if Server SMTP failed to response with the UTF8SMTP keywords. > The client SMTP will bounce the message or do some downgrading. > > > Yao Jiankang > CNNIC I was warning about sequence client SMTP - issues DATA command - does some downgrading - notices that all data is not downgradeable ... you lost ... it is not possible to cancel mail on that point ... In other words downgrading must not do on fly. But perhaps it is more obvious on here that downgrade is not always possible that it was on 8BITMIME, so that this "optimization" is not tried. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 10 06:04:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXETJ-0002Xj-Uu; Tue, 10 Oct 2006 06:04:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXETI-0002XE-Ru for ima@ietf.org; Tue, 10 Oct 2006 06:04:24 -0400 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXETH-0000Ru-9k for ima@ietf.org; Tue, 10 Oct 2006 06:04:24 -0400 Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@siilo.fmi.fi) by smtp1gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20041007) with ESMTP id k9AA4LoD028787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Oct 2006 13:04:21 +0300 Received: from siilo.fmi.fi by torkku.fmi.fi with ESMTP id k9AA4L9O023911 ; Tue, 10 Oct 2006 13:04:21 +0300 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id k9AA4LFT008604 ; Tue, 10 Oct 2006 13:04:21 +0300 Received: by siilo.fmi.fi id k9AA4Klt008601; Tue, 10 Oct 2006 13:04:20 +0300 Message-Id: <200610101004.k9AA4Klt008601@siilo.fmi.fi> Subject: Re: Encapsulation is required (for some headers) (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) In-Reply-To: <200610100838.k9A8c8hb002893@siilo.fmi.fi> To: John C Klensin Date: Tue, 10 Oct 2006 13:04:20 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp1gate: 3 received headers rewritten with id 20061010/09001/01 X-Filter: smtp1gate: ID 9000/01, 1 parts scanned for known viruses X-Filter: torkku: ID 0282/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp1gate: ID 9000/01) report=BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 > >>> John C Klensin > > Kari, > > > > Before I try to comment on this, could you be absolutely clear > > about what you mean by "encapsulating headers"? I know, more or > > less, how to encapsulate a body part. I can probably devise > > ways to encapsulate an entire header set. But it seems to me > > that you are asking for/ requiring encapsulation of individual > > headers. > > > > john > > I mean invidual headers, because all is not possible to downgraded > that way that they are usefull. Or perhaps correct terminology is: invidual header fields _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 10 10:12:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXIKH-0003vu-KI; Tue, 10 Oct 2006 10:11:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXIKG-0003qL-5R for ima@ietf.org; Tue, 10 Oct 2006 10:11:20 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXIKB-00064F-JC for ima@ietf.org; Tue, 10 Oct 2006 10:11: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.232) id 452ba9fa.1239c.e for ima@ietf.org; Tue, 10 Oct 2006 15:11:06 +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 k9AEB31G021021 for ; Tue, 10 Oct 2006 15:11:04 +0100 (BST) To: ima@ietf.org Subject: Re: Encapsulation is required (for some headers) (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> Message-ID: Date: Tue, 10 Oct 2006 15:11:03 +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: <5dzmc4d6s9.fsf_-_@leija.fmi.fi> 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 Tue, 10 Oct 2006 07:27:50 +0100, Kari Hurtta wrote: > Encapsulation is required for some headers. > That is needed for future compatibility. > > Otherwise MTAs is required to know syntax of all headers > (including these standards which are not yet written.) That is a flaw in the design of RFC 2047 (and one that Keith steadfastly refuses to recognize). But it is not our job to fix that (though in the long run UTF8smtp will render the use of RFC 2047 unnecessary). > > There must be encapsulation (as opposite of "conversion strategy") > for headers which MTA do not know. Yes you are correct there, but the downgrade document already provides that, in the form of the Downgraded header. What it doesn't do is to make it clear that mechanism MUST be used for all headers for which there is no special provision. It _does_ make special provision for most of the headers which are necessary for propagation, though it could usefully add a few more (notably the List-* headers). -- 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 Oct 10 12:04:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXK5B-0005hJ-Rl; Tue, 10 Oct 2006 12:03:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXK59-0005hE-Pm for ima@ietf.org; Tue, 10 Oct 2006 12:03: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 1GXK58-00062u-Bt for ima@ietf.org; Tue, 10 Oct 2006 12:03:51 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXK4v-0006o4-TH for ima@ietf.org; Tue, 10 Oct 2006 18:03:37 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 18:03:37 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 18:03:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: Encapsulation is required (for some headers) (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) Date: 10 Oct 2006 19:03:24 +0300 Lines: 50 Message-ID: <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Tue, 10 Oct 2006 07:27:50 +0100, Kari Hurtta > wrote: > > > > Encapsulation is required for some headers. > > That is needed for future compatibility. > > > > Otherwise MTAs is required to know syntax of all headers > > (including these standards which are not yet written.) > > That is a flaw in the design of RFC 2047 (and one that Keith > steadfastly refuses to recognize). But it is not our job to fix that > (though in the long run UTF8smtp will render the use of RFC 2047 > unnecessary). I do not suggest that we try fix RFC 2047 > > There must be encapsulation (as opposite of "conversion strategy") > > for headers which MTA do not know. > > Yes you are correct there, but the downgrade document already provides > that, in the form of the Downgraded header. What it doesn't do is to > make it clear that mechanism MUST be used for all headers for which > there is no special provision. It (draft-ietf-eai-downgrade-02.txt) says + If the header is an address header which is described in Section 5.1.1, - Preserve the header in 'Downgraded' header. If I read correctly, that provides Downgraded -header ONLY for address header. (I think that you mentioned that already.) For other headers it says: + The other header case, encode the header by [RFC2047] with UTF-8 tag. That of course can not be done, when syntax of header is not known. I say that it must provide Downgraded -header for other headers (when syntax is not known). > It _does_ make special provision for most of the headers which are > necessary for propagation, though it could usefully add a few more > (notably the List-* headers). / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 10 13:13:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXL9r-0003CP-6r; Tue, 10 Oct 2006 13:12:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXL9q-00039G-IQ for ima@ietf.org; Tue, 10 Oct 2006 13:12:46 -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 1GXL9o-0002Ol-8o for ima@ietf.org; Tue, 10 Oct 2006 13:12:46 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXL8G-00051n-NT for ima@ietf.org; Tue, 10 Oct 2006 19:11:08 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 19:11:08 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 19:11:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: Encapsulation is required (for some headers) (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) Date: 10 Oct 2006 20:09:52 +0300 Lines: 24 Message-ID: <5d1wpgxfkv.fsf@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Kari Hurtta writes: > It (draft-ietf-eai-downgrade-02.txt) says > + If the header is an address header which is described in > Section 5.1.1, > - Preserve the header in 'Downgraded' header. > > If I read correctly, that provides Downgraded -header ONLY for address header. > (I think that you mentioned that already.) ^ this sentence should refer other header case below. -----------------+ | > For other headers it says: | > | > + The other header case, encode the header by [RFC2047] with | > UTF-8 tag. | > | > That of course can not be done, when syntax of header is not known. <--+ > > I say that it must provide Downgraded -header for other headers > (when syntax is not known). / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 10 13:19:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXLGY-00056G-Qn; Tue, 10 Oct 2006 13:19:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXLGX-00056B-56 for ima@ietf.org; Tue, 10 Oct 2006 13:19:41 -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 1GXLGV-0003s7-Rk for ima@ietf.org; Tue, 10 Oct 2006 13:19:41 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GXLGV-000J7w-Ed; Tue, 10 Oct 2006 13:19:39 -0400 Date: Tue, 10 Oct 2006 13:19:38 -0400 From: John C Klensin To: Kari Hurtta , ima@ietf.org Subject: Re: [EAI] "downgrade must able to fail" -- or comment about draft-ietf-eai-smtpext-01.txt Message-ID: <006F42C5A3AE0FB0A62A6D6B@p3.JCK.COM> In-Reply-To: <5dac447at5.fsf@leija.fmi.fi> References: <360410499.30927@cnnic.cn> <360443967.13923@cnnic.cn> <5dac447at5.fsf@leija.fmi.fi> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 10 October, 2006 12:57 +0300 Kari Hurtta wrote: >... > I was warning about sequence > > client SMTP > - issues DATA command > - does some downgrading > - notices that all data is not downgradeable > ... you lost ... it is not possible to cancel > mail on that point ... Sure it is. It is bad to just close the connection, but it is certainly done. The design of SMTP might have been better if, after sending CRLF.CRLF, the client was forced to either send "CONFIRM" or "ABOR", but the fact that we didn't do that doesn't imply that things never go wrong after DATA is sent and confirmed. > In other words downgrading must not do on fly. Certainly it isn't a wonderful idea, but it is well short of a MUST NOT. > But perhaps it is more obvious on here that downgrade > is not always possible that it was on 8BITMIME, so that this > "optimization" is not tried. I'm not certain I understand that comment, but it may not make much difference. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 10 13:20:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXLHn-0005S3-MV; Tue, 10 Oct 2006 13:20:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXLHm-0005Rs-9r for ima@ietf.org; Tue, 10 Oct 2006 13:20:58 -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 1GXLHl-00049E-0N for ima@ietf.org; Tue, 10 Oct 2006 13:20:58 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXLGu-0006z5-Vh for ima@ietf.org; Tue, 10 Oct 2006 19:20:04 +0200 Received: from d252018.dialin.hansenet.de ([80.171.252.18]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 19:20:04 +0200 Received: from nobody by d252018.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 19:20:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 10 Oct 2006 19:17:03 +0200 Organization: Lines: 33 Message-ID: <452BD58F.87C@xyzzy.claranet.de> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252018.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [EAI] Re: Encapsulation is required (for some headers) 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: [quoting Charles] >> That is a flaw in the design of RFC 2047 (and one that Keith >> steadfastly refuses to recognize). I'm not aware of any flaws in RFC 2047 apart from its minimalistic security considerations, what's that about ? > (draft-ietf-eai-downgrade-02.txt) says > + If the header is an address header which is described > in Section 5.1.1, > - Preserve the header in 'Downgraded' header. > If I read correctly, that provides Downgraded -header ONLY for > address header. [...] > For other headers it says: > + The other header case, encode the header by [RFC2047] > with UTF-8 tag. > That of course can not be done, when syntax of header is not known. If the syntax isn't known the default is , and the gateway (UTF8SMTP to SMTP or vice versa is a gateway) could handle it like say a Subject: header field with UTF-8. Maybe UTF8SMTP could register header fields (3864 registry) where supporting the header field syntax is critical for SMTP-gateways. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 10 15:00:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMpg-00060o-RC; Tue, 10 Oct 2006 15:00:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMpf-00060J-CD for ima@ietf.org; Tue, 10 Oct 2006 15:00:03 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXMpX-00006k-74 for ima@ietf.org; Tue, 10 Oct 2006 15:00: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-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id 452beda9.15a3b.5ba; Tue, 10 Oct 2006 19:59:53 +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 k9AIxod6009323; Tue, 10 Oct 2006 19:59:51 +0100 (BST) To: "Kari Hurtta" , ima@ietf.org Subject: Re: Encapsulation is required (for some headers) (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> Message-ID: Date: Tue, 10 Oct 2006 19:59:49 +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: <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) 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 Tue, 10 Oct 2006 17:03:24 +0100, Kari Hurtta wrote: > It (draft-ietf-eai-downgrade-02.txt) says > + If the header is an address header which is described in > Section 5.1.1, > - Preserve the header in 'Downgraded' header. > > If I read correctly, that provides Downgraded -header ONLY for address > header. > (I think that you mentioned that already.) > > For other headers it says: > > + The other header case, encode the header by [RFC2047] with > UTF-8 tag. > > That of course can not be done, when syntax of header is not known. Exactly. > > I say that it must provide Downgraded -header for other headers > (when syntax is not known). And there I agree with you entirely. I have been asking for this to be included in the downgrade document for a long time. -- 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 Oct 10 15:19:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXN8f-0006M7-49; Tue, 10 Oct 2006 15:19:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXN8d-0006KN-2o for ima@ietf.org; Tue, 10 Oct 2006 15:19:39 -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 1GXN0q-0001wE-GC for ima@ietf.org; Tue, 10 Oct 2006 15:11:37 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXN05-00065r-0i for ima@ietf.org; Tue, 10 Oct 2006 21:10:49 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 21:10:48 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 21:10:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Re: Encapsulation is required (for some headers) Date: 10 Oct 2006 22:10:04 +0300 Lines: 43 Message-ID: <5dmz846l83.fsf@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > > That of course can not be done, when syntax of header is not known. > > If the syntax isn't known the default is , and the > gateway (UTF8SMTP to SMTP or vice versa is a gateway) could handle > it like say a Subject: header field with UTF-8. I disagree on here. If MTA does not know syntax, MUA may still know syntax. And syntax what MUA is using may give completely different parsing rules. If MUA think that header is structured, it must _first_ parse structure and after that do RFC 2047 decoding on comment ('ctext') phrase (*word) > Maybe UTF8SMTP could register header fields (3864 registry) where > supporting the header field syntax is critical for SMTP-gateways. > > Frank / Kari Hurtta Quote from RFC 2047: 6.2. Display of 'encoded-word's Any 'encoded-word's so recognized are decoded, and if possible, the resulting unencoded text is displayed in the original character set. NOTE: Decoding and display of encoded-words occurs *after* a structured field body is parsed into tokens. It is therefore possible to hide 'special' characters in encoded-words which, when displayed, will be indistinguishable from 'special' characters in the surrounding text. For this and other reasons, it is NOT generally possible to translate a message header containing 'encoded-word's to an unencoded form which can be parsed by an RFC 822 mail reader. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 10 17:11:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOss-0002n9-LJ; Tue, 10 Oct 2006 17:11:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOsr-0002my-Si for ima@ietf.org; Tue, 10 Oct 2006 17:11:29 -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 1GXOsq-0007vj-J6 for ima@ietf.org; Tue, 10 Oct 2006 17:11:29 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXOsZ-0007v9-LR for ima@ietf.org; Tue, 10 Oct 2006 23:11:11 +0200 Received: from d252018.dialin.hansenet.de ([80.171.252.18]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 23:11:11 +0200 Received: from nobody by d252018.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Oct 2006 23:11:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 10 Oct 2006 23:09:10 +0200 Organization: Lines: 36 Message-ID: <452C0BF6.6F6@xyzzy.claranet.de> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <5dmz846l83.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d252018.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [EAI] Re: Encapsulation is required (for some headers) 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: >> If the syntax isn't known the default is , and the >> gateway (UTF8SMTP to SMTP or vice versa is a gateway) could handle >> it like say a Subject: header field with UTF-8. > I disagree on here. > If MTA does not know syntax, MUA may still know syntax. The gateway could note it as Downgraded-unknown-: =?UTF-8?B?etc?= where is the original header field name, and Downgraded-unknown- indicates "garbage in garbage out" processing. Or maybe the original field should appear behind the colon, e.g. Downgraded-unknown: : =?UTF-8?Q?etc?= The next downgrade draft could profit from an example how that's all supposed to work. > If MUA think that header is structured, it must _first_ parse > structure and after that do RFC 2047 decoding ACK, using the same header field name won't fly. A more radical idea could be to transform the complete message/utf8smtp as is into the body (= MIME message/utf8smtp part) of a forwarded mail, and only keep the downgraded "vital" header fields (anything in 2822 + the Content header fields for a message/utf8smtp). In some situations like a mailing list on the downgraded route it won't be possible to reliably upgrade it later. Maybe the MUA should figure this out. Most MUAs can handle message/rfc822 today, they will learn how to handle message/utf8smtp (it's almost identical). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 10 23:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXV7o-0005VB-TT; Tue, 10 Oct 2006 23:51:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXV7n-0005V6-Ut for ima@ietf.org; Tue, 10 Oct 2006 23:51:19 -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 1GXV7m-0003Xc-Ge for ima@ietf.org; Tue, 10 Oct 2006 23:51:19 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXV7b-0008RB-LX for ima@ietf.org; Wed, 11 Oct 2006 05:51:07 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 05:51:07 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 05:51:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Kari Hurtta" Subject: Re: [EAI] Re: Encapsulation is required (for some headers) Date: 11 Oct 2006 06:50:52 +0300 Lines: 58 Message-ID: <5dzmc3h5nn.fsf@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <5dmz846l83.fsf@Hurtta06k.keh.iki.fi> <452C0BF6.6F6@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Kari Hurtta wrote: > > >> If the syntax isn't known the default is , and the > >> gateway (UTF8SMTP to SMTP or vice versa is a gateway) could handle > >> it like say a Subject: header field with UTF-8. > > The next downgrade draft could profit from an example how that's all > supposed to work. > > > If MUA think that header is structured, it must _first_ parse > > structure and after that do RFC 2047 decoding > > ACK, using the same header field name won't fly. A more radical idea > could be to transform the complete message/utf8smtp as is into the body > (= MIME message/utf8smtp part) of a forwarded mail, and only keep the > downgraded "vital" header fields (anything in 2822 + the Content header > fields for a message/utf8smtp). In here there is no disagreement (except that message/* subparts do not work) Putting unknown header fields _only_ to Downgraded: -header fields or to MIME part are both using "encapsulation strategy". Using same header field name and trying to use RFC 2047 without syntax is using "conversion strategy" (which do not work on here). ( I suggest text/utf8smtp part instead of message/utf8smtp part. Reason why message/* parts do not work is mentioned on my article with title: "downgrade must able to fail" Another reason is that RFC 2045 forbids other than Content-Transfer-Encoding "7bit", "8bit", and "binary" on message/* subparts. That means that 8BITMIME downgrading of message/utf8smtp is not possible.) > In some situations like a mailing list on the downgraded route it won't > be possible to reliably upgrade it later. Maybe the MUA should figure > this out. Most MUAs can handle message/rfc822 today, they will learn > how to handle message/utf8smtp (it's almost identical). > > Frank / Kari Hurtta RFC 2045 quote: 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. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 00:16:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXVVs-0001Ud-PV; Wed, 11 Oct 2006 00:16:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXVVr-0001UX-Qp for ima@ietf.org; Wed, 11 Oct 2006 00:16:11 -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 1GXVVq-0007WQ-62 for ima@ietf.org; Wed, 11 Oct 2006 00:16:11 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXVVk-0005jp-TA for ima@ietf.org; Wed, 11 Oct 2006 06:16:05 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 06:16:04 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 06:16:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: MIME subpart (Re: [EAI] Re: Encapsulation is required (for some headers)) Date: 11 Oct 2006 07:15:57 +0300 Lines: 77 Message-ID: <5dvemrh4hu.fsf_-_@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <5dmz846l83.fsf@Hurtta06k.keh.iki.fi> <452C0BF6.6F6@xyzzy.claranet.de> <5dzmc3h5nn.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Kari Hurtta" writes: > Frank Ellermann writes in gmane.ietf.ima: > > > If MUA think that header is structured, it must _first_ parse > > > structure and after that do RFC 2047 decoding > > > > ACK, using the same header field name won't fly. A more radical idea > > could be to transform the complete message/utf8smtp as is into the body > > (= MIME message/utf8smtp part) of a forwarded mail, and only keep the > > downgraded "vital" header fields (anything in 2822 + the Content header > > fields for a message/utf8smtp). > > In here there is no disagreement (except that message/* subparts do not work) > > Putting unknown header fields _only_ to Downgraded: -header fields or > to MIME part are both using "encapsulation strategy". > > Using same header field name and trying to use RFC 2047 without syntax is > using "conversion strategy" (which do not work on here). > > ( I suggest text/utf8smtp part instead of message/utf8smtp part. > Reason why message/* parts do not work is mentioned on my article > with title: "downgrade must able to fail" > > Another reason is that RFC 2045 forbids other than > Content-Transfer-Encoding "7bit", "8bit", and "binary" on message/* > subparts. That means that 8BITMIME downgrading of message/utf8smtp > is not possible.) > That MIME subparts idea is quite complex. It needs little more than just one MIME subparts. Example: ===================================== {received-header-fields} | original header {ascii-header-fields} | {utf-8 header-fields} | MIME-Version: 1.0 | {content-header-fields} | {body} ===================================== becomes => ===================================== {received-header-fields} | {ascii-header-fields} | converted header {converted-header-fields} | MIME-Version: 1.0 | Content-Transfer-Encoding: 8bit | or "binary" if original was "binary" Content-Type: message/utf8message; | boundary="{new-boundary}" | --{new-boundary} | Header for new body part Content-Transfer-Encoding: 8bit | Content-Type: text/utf8smtp; | charset=utf-8 | {original-utf-8 header-fields} --{new-boundary} | Content header fields from {content-header-fields} | original header {original body} --{new-boundary}-- ===================================== / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 00:20:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXVZo-0003Ir-CL; Wed, 11 Oct 2006 00:20:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXVZm-0003FY-Bz for ima@ietf.org; Wed, 11 Oct 2006 00:20:14 -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 1GXVZk-00087M-Ui for ima@ietf.org; Wed, 11 Oct 2006 00:20:14 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GXVZZ-0006Zi-TL for ima@ietf.org; Wed, 11 Oct 2006 06:20:01 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 06:20:01 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 06:20:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: MIME subpart (Re: [EAI] Re: Encapsulation is required (for some headers)) Date: 11 Oct 2006 07:19:29 +0300 Lines: 53 Message-ID: <5dr6xfh4by.fsf@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <5dmz846l83.fsf@Hurtta06k.keh.iki.fi> <452C0BF6.6F6@xyzzy.claranet.de> <5dzmc3h5nn.fsf@Hurtta06k.keh.iki.fi> <5dvemrh4hu.fsf_-_@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes: > "Kari Hurtta" writes: > > That MIME subparts idea is quite complex. It needs little more than > just one MIME subparts. > > Example: > > ===================================== > {received-header-fields} | original header > {ascii-header-fields} | > {utf-8 header-fields} | > MIME-Version: 1.0 | > {content-header-fields} | > > {body} > ===================================== > > becomes => > > > ===================================== > {received-header-fields} | > {ascii-header-fields} | converted header > {converted-header-fields} | > MIME-Version: 1.0 | > Content-Transfer-Encoding: 8bit | or "binary" if original was "binary" > Content-Type: message/utf8message; | > boundary="{new-boundary}" | this is mistake. "message/utf8message" should be "multipart/utf8message" > > --{new-boundary} | Header for new body part > Content-Transfer-Encoding: 8bit | > Content-Type: text/utf8smtp; | > charset=utf-8 | > > {original-utf-8 header-fields} > > --{new-boundary} | Content header fields from > {content-header-fields} | original header > > {original body} > > --{new-boundary}-- > ===================================== > / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 03:11:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXYEu-0002At-Ir; Wed, 11 Oct 2006 03:10:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXYEt-0002Ao-Ck for ima@ietf.org; Wed, 11 Oct 2006 03:10:51 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXYEr-0006PX-1r for ima@ietf.org; Wed, 11 Oct 2006 03:10:51 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CC26B2596BB; Wed, 11 Oct 2006 09:08:15 +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 06019-03; Wed, 11 Oct 2006 09:08:08 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7AD0E2596BD; Wed, 11 Oct 2006 09:08:08 +0200 (CEST) Message-ID: <452C98F0.4040802@alvestrand.no> Date: Wed, 11 Oct 2006 00:10:40 -0700 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Kari Hurtta Subject: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> In-Reply-To: <5d3b9wkb4o.fsf@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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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, please be specific - I can't tell what you are thinking about. Please use the language from draft-ietf-eai-scenarios, and describe a specific scenario in which you think that "encapsulation strategy" may succeed, while "conversion strategy" requires a bounce, and explain why. Note: Encapsulation by the sender will be allowed as soon as someone delivers on the promise to write up a draft on what the MIME part for an encapsulation should look like - but this isn't in the critical path of this effort.... Harald Kari Hurtta wrote: > > > I was thinking requiring "conversion strategy", but I was looking cases > where "encapsulation strategy" may succeed (when "conversion strategy" > may require bounce.) > > If these cases ("conversion strategy" bounces, "encapsulation strategy" > succees), are many, then "encapsulation strategy" should have permitted as > optional. > > / 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 Oct 11 03:34:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXYbX-0003z9-Ig; Wed, 11 Oct 2006 03:34:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXYbW-0003yz-AJ for ima@ietf.org; Wed, 11 Oct 2006 03:34:14 -0400 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXYbU-0003i6-ND for ima@ietf.org; Wed, 11 Oct 2006 03:34:14 -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-20041007) with ESMTP id k9B7YAT7002583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Oct 2006 10:34:10 +0300 Received: from siilo.fmi.fi by virkku.fmi.fi with ESMTP id k9B7YA8b008775 ; Wed, 11 Oct 2006 10:34:10 +0300 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id k9B7YA5S028614 ; Wed, 11 Oct 2006 10:34:10 +0300 Received: by siilo.fmi.fi id k9B7Y9mA028611; Wed, 11 Oct 2006 10:34:09 +0300 Message-Id: <200610110734.k9B7Y9mA028611@siilo.fmi.fi> Subject: Re: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) In-Reply-To: <452C98F0.4040802@alvestrand.no> To: Harald Alvestrand Date: Wed, 11 Oct 2006 10:34:09 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp1gate: 3 received headers rewritten with id 20061011/13095/01 X-Filter: smtp1gate: ID 13094/01, 1 parts scanned for known viruses X-Filter: virkku: ID 9292/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp1gate: ID 13094/01) report=BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 >>> Harald Alvestrand > Kari, > > please be specific - I can't tell what you are thinking about. > > Please use the language from draft-ietf-eai-scenarios, and describe a > specific scenario in which you think that "encapsulation strategy" may > succeed, while "conversion strategy" requires a bounce, and explain why. > > Note: Encapsulation by the sender will be allowed as soon as someone > delivers on the promise to write up a draft on what the MIME part for an > encapsulation should look like - but this isn't in the critical path of > this effort.... > > Harald At least now it look that "conversion strategy" requires knowledge about syntax of header fields. Problem seems to be that converting MTA is required to know all possible standards which define syntax of mail header fields. Of course that does not prevent conversion of RFC 2822 header fields or any other standard header fields, when it is given list of standards, which syntax must be supported on conversion. Encapsulation can be done without without knowledge. Encapsulation (of unknown header field) can be either to new header field or to new MIME part. There may be some other cases also. These was what I was asking. I do not know what are these cases. I was asking about that. ( Also conversion may be impossible if there is allowed UTF-8 on some places, to where conversion is not possible. For example mime-encoded-words or some other currently existing standard does not define ascii compatible encoding. If new encoding is defined for missing parts, it is equivalent of encapsulation. ) I try look draft-ietf-eai-scenarios. / Kari Hurtta > Kari Hurtta wrote: > > > > > > I was thinking requiring "conversion strategy", but I was looking cases > > where "encapsulation strategy" may succeed (when "conversion strategy" > > may require bounce.) > > > > If these cases ("conversion strategy" bounces, "encapsulation strategy" > > succees), are many, then "encapsulation strategy" should have permitted as > > optional. > > > > / 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 Oct 11 04:40:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXZdh-0007uX-Lh; Wed, 11 Oct 2006 04:40:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXZdh-0007uR-12 for ima@ietf.org; Wed, 11 Oct 2006 04:40:33 -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 1GXZdf-0007du-O2 for ima@ietf.org; Wed, 11 Oct 2006 04:40:33 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXZct-0007iM-A7 for ima@ietf.org; Wed, 11 Oct 2006 10:39:43 +0200 Received: from pd9fbad9d.dip0.t-ipconnect.de ([217.251.173.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 10:39:43 +0200 Received: from nobody by pd9fbad9d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 10:39:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Wed, 11 Oct 2006 10:38:22 +0200 Organization: Lines: 31 Message-ID: <452CAD7E.6BBE@xyzzy.claranet.de> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <5dmz846l83.fsf@Hurtta06k.keh.iki.fi> <452C0BF6.6F6@xyzzy.claranet.de> <5dzmc3h5nn.fsf@Hurtta06k.keh.iki.fi> <5dvemrh4hu.fsf_-_@Hurtta06k.keh.iki.fi> <5dr6xfh4by.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad9d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [EAI] Re: MIME subpart 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: >> Content-Type: message/utf8message; | >> boundary="{new-boundary}" | > this is mistake. "message/utf8message" should be > "multipart/utf8message" Yes, you want a boundary. Okay, RFC 2045 says EXPRESSLY FORBIDDEN about base64 for message/*. But it does allow 8bit as needed by a hypothetical message/utf8smtp. With that you'd get... =============================== converted-header-fields MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: message/utf8smtp original-utf-8 header-fields original body =============================== ...and we're in trouble if we hit a 7bit MTA. If all else fails there's application/utf8smtp and base64. After a short look into RFC 1495 + 1652: Harald and John can do gateway-giggle-tests. :-) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 04:43:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXZgf-0000IG-Jp; Wed, 11 Oct 2006 04:43:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXZge-0000IB-4B for ima@ietf.org; Wed, 11 Oct 2006 04:43:36 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXZgc-000840-NR for ima@ietf.org; Wed, 11 Oct 2006 04:43:36 -0400 Received: from [10.201.0.58] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id k9B8hKds024788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Oct 2006 01:43:23 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k9B8hKds024788 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1160556205; bh=MoPYYLhTKngijGCnfMP9nV9bBEs=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:Message-ID: MIME-Version:Content-Type; b=o4Fd50hH0mVsxapzmvCldzXU1HX8T7wWJ9L0mx AQL2X6akJGpAtWisn109iTqvQ6Ma4Ict5g3+OaWkS1ZcuOIR8uFH/zfz80TD+WZVUiY 8BZX7k2fevJD3w4O1msx3jfOX3BTvtwKoAGWzVqt2FC5Uus5HYraGHy5cz0EAZ7Kw8= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k9B8hKds024788 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:message-id: mime-version:content-type; b=iqbQgJ6xXSAhM+GS7POW6TfR7KaKuROLhrBNzKC1X+reZlBetSkaNl3zoopNGYYb0 YI9ZPZSRKuCr2hHlKmeATYfWzvrnKrMo9gFuDJz9Edow99XN7hq6CSWNVbYxW9jQSwr vxCmAZL3c5+A3KUxxePlt0W6s69g1RIasPP6Mss= Date: Wed, 11 Oct 2006 02:43:19 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: john-ietf@jck.com, yw@mrko.pe.kr Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ima@ietf.org Subject: [EAI] text for eai-framework re: 2047+S/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 I was asked to provide text for this an eternity ago (i.e., Montreal), so here finally is text for inclusion in section 4.2, "Transmission of Email Header in UTF-8 Encoding": One particular characteristic of the email format is its persistency: MUA are expected to handle messages that were originally sent decades ago and not just those delivered seconds ago. As such, MUAs and mail filtering software will need to continue to accept and decode header fields that use the RFC 2047 encoding. While extensions to both POP3 and IMAP have been proposed to enable automatic EAI-upgrade---including RFC 2047 decoding---of messages by the POP3 or IMAP server, there are MIME content-types for which that cannot be done or where the change would have unacceptable side-effects. For example, message parts that are cryptographicaly signed (Content-Type: multipart/signed [SMIME][OpenPGP]) cannot be upgraded without breaking the signature. Similarly, message parts that are encrypted (Content-Type: multipart/ encrypted) may contain, when decrypted, header fields that use the RFC 2047 encoding; such messages cannot be 'fully' upgraded without access to cryptographic keys. [[The possibility of server-side decryption and/or signature verification was briefly discussed in the LEMONADE working group. The former would permit application of the forward-without-download support to encrypted messages, while the latter would permit verification-without-download. As currently stands, S/MIME and OpenPGP features are not practically available to a LEMONADE client.]] ...and add references for [SMIME] (RFC 2633) and [OpenPGP] (RFC 3156). This is unrelated, but while it's on my mind: for the security considerations: If the EAI framework creates new forms of 'invalid' or 'malformed' message, then a new email attack is created: in an effort to be robust, some or or most agents will accept such message and interpret them as if they were well-formed. If a filter interprets such a message differently than then final MUA, then it may be possible to create a message which appears acceptable under the filter's interpretation but which should be rejected under the interpretation given it by the final MUA. Such attacks already exist for the existing encoding layers, e.g., invalid MIME syntax, invalid HTML markup, and invalid GIF [reference?] encoding. This exists at all layers, but mentioning TCP segment duplication or IP fragment overlaps is probably more distracting than helpful. Philip Guenther _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 05:49:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXaiI-0003eZ-8y; Wed, 11 Oct 2006 05:49:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXaiG-0003eU-Nu for ima@ietf.org; Wed, 11 Oct 2006 05:49:20 -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 1GXaiD-00041f-6o for ima@ietf.org; Wed, 11 Oct 2006 05:49:20 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXahs-0005dd-Oj for ima@ietf.org; Wed, 11 Oct 2006 11:48:56 +0200 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 11:48:56 +0200 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 11:48:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Re: MIME subpart Date: 11 Oct 2006 12:48:19 +0300 Lines: 50 Message-ID: <5dslhvyyho.fsf@leija.fmi.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <5dmz846l83.fsf@Hurtta06k.keh.iki.fi> <452C0BF6.6F6@xyzzy.claranet.de> <5dzmc3h5nn.fsf@Hurtta06k.keh.iki.fi> <5dvemrh4hu.fsf_-_@Hurtta06k.keh.iki.fi> <5dr6xfh4by.fsf@Hurtta06k.keh.iki.fi> <452CAD7E.6BBE@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes gmane.ietf.ima : > Kari Hurtta wrote: > > >> Content-Type: message/utf8message; | > >> boundary="{new-boundary}" | > > > this is mistake. "message/utf8message" should be > > "multipart/utf8message" > > Yes, you want a boundary. > > Okay, RFC 2045 says EXPRESSLY FORBIDDEN about base64 for message/*. > But it does allow 8bit as needed by a hypothetical message/utf8smtp. > With that you'd get... > > =============================== > converted-header-fields > MIME-Version: 1.0 > Content-Transfer-Encoding: 8bit > Content-Type: message/utf8smtp > > original-utf-8 header-fields > > original body > =============================== > > ...and we're in trouble if we hit a 7bit MTA. If all else fails > there's application/utf8smtp and base64. After a short look into > RFC 1495 + 1652: Harald and John can do gateway-giggle-tests. :-) > > Frank I was essentially suggesting multipart/utf8message for top level, and put utf-header to inside of text/utf8smtp or application/utf8smtp. I think that text/* is more friendly. It can be used multipart/mixed instead of ultipart/utf8message, but I think that multipart/utf8message is usefull for upgrading, and MUAs which will implement that standard. But really challenge is handling of Content-* headers, which includes utf-8 data. That encapulation not really fly on here (result is messy when done recursively for mime parts and content-type and content-transfer-encoding need different handling). Conversion is doable for content-type and content-disposition. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 05:55:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXanl-0008U6-GP; Wed, 11 Oct 2006 05:55:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXank-0008Ty-KR for ima@ietf.org; Wed, 11 Oct 2006 05:55:00 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXang-0005UW-2A for ima@ietf.org; Wed, 11 Oct 2006 05:55:00 -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.231) id 452cbf6c.1507b.fa6 for ima@ietf.org; Wed, 11 Oct 2006 10:54:52 +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 k9B9snbw016043 for ; Wed, 11 Oct 2006 10:54:50 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] Re: Encapsulation is required (for some headers) References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> Message-ID: Date: Wed, 11 Oct 2006 10:54:48 +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: <452BD58F.87C@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 10 Oct 2006 18:17:03 +0100, Frank Ellermann wrote: > Kari Hurtta wrote: > > [quoting Charles] >>> That is a flaw in the design of RFC 2047 (and one that Keith >>> steadfastly refuses to recognize). > > I'm not aware of any flaws in RFC 2047 apart from its minimalistic > security considerations, what's that about ? It requires that every agent (especially agents generating encoded-words) knows which headers are structured and which are unstructured. So if somebody invents a new header and gets it approved by the IETF as a Proposed Standard, then all implementations that encode or decode RFC 2047 stuff magically become non-compliant overnight. Hence the rule, that Kari quoted, that any protocol action brought about in any MUA by any header must be applied _before_ the decoding is done (and the decoding is only to be done for human intelligibility). Hence if we prescribe the use of the Downgraded header (as Kari and I propose), and if that header (in its original UTF8smtp form) is intended to have some protocol effect, then the 'upgrading' operation must be performed _before_ protocol actions are taken (i.e. before it gets to the MUA, or as the very first action taken by the MUA). Yes, this needs pointing out somewhere, but fortunately most new headers that get invented don't lead to protocol actions. > If the syntax isn't known the default is , No it isn't, and it cannot be. For the sending agent may then treat is as unstructured and the receiving agent as structured, and vice versa (becuase one has been upgraded to the latest standard and the other has not). But this is a situation that present implementatiosn have to work around somehow, and the result is that few of them are strictly compliant with RFC 2047. -- 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 Oct 11 08:10:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXcun-0001E8-47; Wed, 11 Oct 2006 08:10:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXcr9-0007UV-Pc for ima@ietf.org; Wed, 11 Oct 2006 08:06:39 -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 1GXcfC-000803-Io for ima@ietf.org; Wed, 11 Oct 2006 07:54:21 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXcem-00033Q-A3 for ima@ietf.org; Wed, 11 Oct 2006 13:53:52 +0200 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 13:53:52 +0200 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 13:53:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Re: MIME subpart Date: 11 Oct 2006 14:52:50 +0300 Lines: 120 Message-ID: <5dr6xf133h.fsf@leija.fmi.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <5dmz846l83.fsf@Hurtta06k.keh.iki.fi> <452C0BF6.6F6@xyzzy.claranet.de> <5dzmc3h5nn.fsf@Hurtta06k.keh.iki.fi> <5dvemrh4hu.fsf_-_@Hurtta06k.keh.iki.fi> <5dr6xfh4by.fsf@Hurtta06k.keh.iki.fi> <452CAD7E.6BBE@xyzzy.claranet.de> <5dslhvyyho.fsf@leija.fmi.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes: > Frank Ellermann writes gmane.ietf.ima : > > Kari Hurtta wrote: > > > this is mistake. "message/utf8message" should be > > > "multipart/utf8message" > > > > Yes, you want a boundary. > > > > Okay, RFC 2045 says EXPRESSLY FORBIDDEN about base64 for message/*. > > But it does allow 8bit as needed by a hypothetical message/utf8smtp. > > With that you'd get... > > > > =============================== > > converted-header-fields > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 8bit > > Content-Type: message/utf8smtp > > > > original-utf-8 header-fields > > > > original body > > =============================== > > > > ...and we're in trouble if we hit a 7bit MTA. If all else fails > > there's application/utf8smtp and base64. After a short look into > > RFC 1495 + 1652: Harald and John can do gateway-giggle-tests. :-) > > > > Frank > > I was essentially suggesting multipart/utf8message for top level, > and put utf-header to inside of text/utf8smtp or application/utf8smtp. > I think that text/* is more friendly. > > It can be used multipart/mixed instead of ultipart/utf8message, > but I think that multipart/utf8message is usefull for upgrading, > and MUAs which will implement that standard. > > But really challenge is handling of Content-* headers, which > includes utf-8 data. That encapulation not really fly on here > (result is messy when done recursively for mime parts and > content-type and content-transfer-encoding need different > handling). If there is {utf-8-content-header-fields} {bodypart} that seems that then it is needed to use application/utf8smtp and replace {utf-8-content-header-fields} with application/utf8smtp. That makes it Content-Type: application/utf8smtp Content-Transfer-Encoding: 8bit | or "binary" if original was "binary" {utf-8-content-header-fields} {bodypart} That essentially collapses mime structure starting from {utf-8-content-headers} to one MIME subpart. Otherwise structure multipart/utf8message text/utf8smtp {original-type} may be used. So if originally there {utf-8-header-fields} Content-Type: multipart/mixed; boundary=.... Content-Transfer-Encoding: 8bit --.... Content-Type: text/plain something --.... {utf-8-content-header-fields} {bodypart} --....-- that makes it {converted-header-fields} Content-Type: multipart/utf8message=boundary=xxxx Content-Transfer-Encoding: 8bit --xxxx Content-Type: text/utf8smtp; charset=utf-8 Content-Transfer-Encoding: 8bit {utf-8-header-fields} --xxxx Content-Type: multipart/mixed; boundary=.... Content-Transfer-Encoding: 8bit --.... Content-Type: text/plain something --.... Content-Type: application/utf8smtp Content-Transfer-Encoding: 8bit {utf-8-content-header-fields} {bodypart} --....-- --xxxx-- / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 10:40:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXfEr-00058n-RQ; Wed, 11 Oct 2006 10:39:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXfEq-00058i-0H for ima@ietf.org; Wed, 11 Oct 2006 10:39:16 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXfEl-0000i9-Ae for ima@ietf.org; Wed, 11 Oct 2006 10:39:15 -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.231) id 452d0202.11e29.d7 for ima@ietf.org; Wed, 11 Oct 2006 15:38: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 k9BEcu97004058 for ; Wed, 11 Oct 2006 15:38:57 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] text for eai-framework re: 2047+S/MIME References: Message-ID: Date: Wed, 11 Oct 2006 15:38: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: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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, 11 Oct 2006 09:43:19 +0100, Philip Guenther wrote: > One particular characteristic of the email format is its > persistency: MUA are expected to handle messages that were > originally sent decades ago and not just those delivered > seconds ago. Indeed, but I don't think there is any requirement for those decades-old messages to be transportable through the modern SMTP network, or for them to survive filtering software. If you want to resend one of them to somebody, then you are more likely to send it as text/plain or message/rfc822. But yes, we still expect modern MUAs to display them correctly. > As such, MUAs and mail filtering software > will need to continue to accept and decode header fields > that use the RFC 2047 encoding. While extensions to both > POP3 and IMAP have been proposed to enable automatic > EAI-upgrade---including RFC 2047 decoding---of messages by > the POP3 or IMAP server, there are MIME content-types for > which that cannot be done or where the change would have > unacceptable side-effects. But I am not so sure which MIME content-types (s/content/media/ BTW) are going to cause problems. > > For example, message parts that are cryptographicaly > signed (Content-Type: multipart/signed [SMIME][OpenPGP]) > cannot be upgraded without breaking the signature. Similarly, > message parts that are encrypted (Content-Type: multipart/ > encrypted) may contain, when decrypted, header fields that > use the RFC 2047 encoding; such messages cannot be 'fully' > upgraded without access to cryptographic keys. In the first place, I think we have to assume that the signature was done _before_ any downgrading (i.e. not by any intermediate MTA). Hence you need to be able to restore the original message by upgrading before you try to check the signature. And for that you _do_ need to restore the original CTE (certainly for multipart/signed - well actually you are supposed to use only 7bit, though you might get away with 8bit). Therefore, it should in principle suffice to upgrade the message before checking the signature. Snags that can arise are when the signed material includes some Content-Type or Content-Disposition with UTF8 somewhere in it. That is most likely to be in some , in which case is it RFC 2231 that you have to worry about, not RFC 2047. And we also need to say somewhere that Downgraded headers are to be allowed within MIME body-part headers (which currently are all supposed to begin with "Content-"). It may also be that some idiot tries to include a comment containing UTF-8 within one of those Content-* headers. More realistic problems can arise if the signed object is a message/rfc822, in which case the downgrading may indeed have introduced some RFC 2047 encoding into the rfc822 headers therein. But RFC 3156 is totally silent on how to sign message/rfc888 and multipart objects, which is not helpful (they don't have their own CTEs for a start). An alternative approach is to NOT downgrade message/rfc822 and body-part headers arising from multiparts, since it is most unlikely that they will fail to be transported intact through MTAs that provide 8BITMIME. I think we really need to see some examples that might go wrong before we can proceed further. > This is unrelated, but while it's on my mind: for the security > considerations: > If the EAI framework creates new forms of 'invalid' or > 'malformed' message, then a new email attack is created: > in an effort to be robust, some or or most agents will > accept such message and interpret them as if they were > well-formed. If a filter interprets such a message > differently than then final MUA, then it may be possible > to create a message which appears acceptable under the > filter's interpretation but which should be rejected under > the interpretation given it by the final MUA. Such attacks > already exist for the existing encoding layers, e.g., > invalid MIME syntax, invalid HTML markup, and invalid GIF > [reference?] encoding. And a good example off that is where a downgraded is different to the version in the Downgraded header (that would be a difference in the , of course), and that is a Security Issue to be mentioned somewhere. -- 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 Oct 11 11:20:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXfsq-0007xe-BM; Wed, 11 Oct 2006 11:20:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXfsp-0007v2-EZ for ima@ietf.org; Wed, 11 Oct 2006 11:20:35 -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 1GXflE-0004J3-NF for ima@ietf.org; Wed, 11 Oct 2006 11:12:50 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXfjx-0000DN-31 for ima@ietf.org; Wed, 11 Oct 2006 17:11:25 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 17:11:25 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 17:11:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Re: Encapsulation is required (for some headers) Date: 11 Oct 2006 18:07:27 +0300 Lines: 60 Message-ID: <5dpscyq4b4.fsf@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Tue, 10 Oct 2006 18:17:03 +0100, Frank Ellermann > wrote: > > > Kari Hurtta wrote: > > > > [quoting Charles] > >>> That is a flaw in the design of RFC 2047 (and one that Keith > >>> steadfastly refuses to recognize). > > > > I'm not aware of any flaws in RFC 2047 apart from its minimalistic > > security considerations, what's that about ? > > It requires that every agent (especially agents generating > encoded-words) knows which headers are structured and which are > unstructured. So if somebody invents a new header and gets it > approved by the IETF as a Proposed Standard, then all implementations > that encode or decode RFC 2047 stuff magically become non-compliant > overnight. Well, if MUA does not implement some standard, it either do not generate headers of that standard. So I do not think that this happends on MUAs which are generating encoded-words. (or what I are missed?) Yes, technically that (non-compliant) happens on receiving MUAs. > Hence the rule, that Kari quoted, that any protocol action brought > about in any MUA by any header must be applied _before_ the decoding > is done (and the decoding is only to be done for human > intelligibility). Yes. > Hence if we prescribe the use of the Downgraded header (as Kari and I > propose), and if that header (in its original UTF8smtp form) is > intended to have some protocol effect, then the 'upgrading' operation > must be performed _before_ protocol actions are taken (i.e. before it > gets to the MUA, or as the very first action taken by the MUA). Yes, > this needs pointing out somewhere, but fortunately most new headers > that get invented don't lead to protocol actions. Yes. That happens with Downgraded header or with any new MIME subpart, if that is used for encapsulation. Encapsulation requires 'upgrading' operation before protocol actions are taken. There is no that problem with conversion, but unfortunately conversion to existing (and widely implemented) protocols is not always possible. > > If the syntax isn't known the default is , > > No it isn't, and it cannot be. For the sending agent may then treat is > as unstructured and the receiving agent as structured, and vice versa > (becuase one has been upgraded to the latest standard and the other > has not). Yes. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 11:20:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXfsz-00080Q-Rn; Wed, 11 Oct 2006 11:20:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXfsy-0007zs-FN for ima@ietf.org; Wed, 11 Oct 2006 11:20:44 -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 1GXfij-00040l-1L for ima@ietf.org; Wed, 11 Oct 2006 11:10:10 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GXfii-0004MU-8y; Wed, 11 Oct 2006 11:10:08 -0400 Date: Wed, 11 Oct 2006 11:10:07 -0400 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [EAI] text for eai-framework re: 2047+S/MIME Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.6 (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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 11 October, 2006 15:38 +0100 Charles Lindsey wrote: >... >> For example, message parts that are cryptographicaly >> signed (Content-Type: multipart/signed [SMIME][OpenPGP]) >> cannot be upgraded without breaking the signature. >> Similarly, message parts that are encrypted (Content-Type: >> multipart/ encrypted) may contain, when decrypted, header >> fields that use the RFC 2047 encoding; such messages cannot >> be 'fully' upgraded without access to cryptographic keys. > > In the first place, I think we have to assume that the > signature was done_before_ any downgrading (i.e. not by any > intermediate MTA). Hence youneed to be able to restore the > original message by upgrading before youtry to check the > signature. And for that you _do_ need to restore theoriginal > CTE (certainly for multipart/signed - well actually you > aresupposed to use only 7bit, though you might get away with > 8bit). > > Therefore, it should in principle suffice to upgrade the > message beforechecking the signature. But signed messages are sensitive enough to any changes at all in whatever the signature was calculated over that "sign, downgrade, upgrade, check signature" is almost guaranteed to fail (again, assuming signature over what is being upgraded or downgraded). I see only a few ways out of this: (1) Sign only body parts, one at a time, not headers. Gee, that is what S/MIME and PGP usually do. (2) Encapsulate the signed message, signature and all. This will require some very careful de-encapsulation but should, in principle, work. As Harald points out, many of us are convinced that we need a mechanism for encapsulation --for forwarding in a pure 8bit environment even if not for downgrading. As he also points out, it is not on this WG's critical path, but someone should write it up. If no one else gets to it, I'll do so sooner or later. But I believe that it will have inevitable normative dependencies on the UTF-8 Headers document so, until there is rough consensus on that... (3) Prohibit downgrading of signed messages. I note that we have no mechanism for doing that today. One can prohibit automatic and general downgrading by leaving off the ALT-ADDRESS parameter, but cannot now prohibit a number of other possible strategies, especially those performed by a Submission MTA using out of band information. Suggestions welcome, but I think the discussion is moving toward the kicking of dead horses. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 11:29:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXg15-0004E5-8W; Wed, 11 Oct 2006 11:29:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXg13-0004DZ-LE for ima@ietf.org; Wed, 11 Oct 2006 11:29:05 -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 1GXg12-0006wz-C1 for ima@ietf.org; Wed, 11 Oct 2006 11:29:05 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXfxg-0004pZ-Bs for ima@ietf.org; Wed, 11 Oct 2006 17:25:36 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 17:25:36 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 17:25:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) Date: 11 Oct 2006 18:20:16 +0300 Lines: 31 Message-ID: <5diriqq3pr.fsf_-_@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <452C98F0.4040802@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Harald Alvestrand writes in gmane.ietf.ima: > Kari, > > please be specific - I can't tell what you are thinking about. > > Please use the language from draft-ietf-eai-scenarios, and describe a > specific scenario in which you think that "encapsulation strategy" may > succeed, while "conversion strategy" requires a bounce, and explain > why. > > Note: Encapsulation by the sender will be allowed as soon as someone > delivers on the promise to write up a draft on what the MIME part for > an encapsulation should look like - but this isn't in the critical > path of this effort.... > > Harald > A, an i18mail user, sends to X, an ascii user. Message contains protocol elements for which converting gateway is not aware. Encapsulation does not require knowing these protocol elements. Converting gateway need to know these protocol elements, otherwise it is not able convert them. If there is no permission to drop these elements, it is required to bounce message. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 13:02:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhSu-00039l-Vp; Wed, 11 Oct 2006 13:01:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhSu-00039G-Hk for ima@ietf.org; Wed, 11 Oct 2006 13:01:56 -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 1GXhSr-0003U9-SE for ima@ietf.org; Wed, 11 Oct 2006 13:01:56 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GXhSq-0005Pd-Vj; Wed, 11 Oct 2006 13:01:53 -0400 Date: Wed, 11 Oct 2006 13:01:52 -0400 From: John C Klensin To: Kari Hurtta , ima@ietf.org Subject: Re: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) Message-ID: In-Reply-To: <5diriqq3pr.fsf_-_@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <452C98F0.4040802@alvestrand.no> <5diriqq3pr.fsf_-_@Hurtta06k.keh.iki.fi> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.6 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 11 October, 2006 18:20 +0300 Kari Hurtta wrote: > A, an i18mail user, sends to X, an ascii user. > > Message contains protocol elements for which converting > gateway is not aware. > > Encapsulation does not require knowing these protocol > elements. > > Converting gateway need to know these protocol elements, > otherwise it is not able convert them. If there is no > permission to drop these elements, it is required to bounce > message. Kari, There is no question that there is a problem in this area. Oddly, it isn't an i18nemail problem, although i18n may make it more obvious. The problem derives from the fact that one can invent new headers at will _and_ that there is no way to tell a header whose interpretation is expected to be mandatory for interpretation of the message and one whose interpretation is strictly optional. We have dealt with that by pretending that _all_ unrecognized headers are optional, but we do so knowing that assumption is neither completely reasonable nor completely safe. For example, assume that a plain-ASCII (821/822 conformant) user sends a message to A, a plain-ASCII (2821/2822 conformant) user. Somewhere between the two there is a protective relay or gateway -- a spam filter, an applications-level firewall trying to keep malware out of a LAN, a gateway into some other transport environment, or something else. Now that intermediate system is faced with the following sorts of headers: (i) Those that it understands by virtue of their being required by 2822 (ii) Those that it thinks it understands. Note that it could be wrong about this, because there is no required /standard definition of the content of any header field other than those in 2822 and updating standards and, more important, no way to know the properties of any header developed subsequent to the implementation base of the intermediary. (iii) Those that it does not understand but that might, in the mind of the sender, be required for understanding or properly processing the message. In other words, the sender would prefer that the message be bounced if the receiver (or an intermediate system) cannot properly interpret that field as intended. (iv) Those that it does not understand but that are, in the mind of the sender, simply additional information associated about the message. In other words, the sender would like the message delivered regardless of whether this information can be delivered or not. There is no possible way for the intermediate system to distinguish between (iii) and (iv). There is actually no way to distinguish (ii) from either of them either, but the belief that one understands the field might be worth the risk. Now, what is the intermediate to do? If it has a security motivation and fears malware triggers or inappropriate information disclosure, it should probably either bounce the message or discard all headers that are not in the first category or maybe the first two. "Discard" is more common than "bounce" today, but neither is unheard of. Unfortunately, if a signature has been computed across the full set of headers and some are discarded, verification of the signature by the receiver will fail. Again, none of this requires any i18n extensions. It is consequently unreasonable to expect this WG to solve the problems in the general case -- we have lived with them for years and will probably continue to do so, with or without EAI. Now, what does this mean for downgrading? I suggest it means: (1) It is at least as plausible, if not more so, to discard any unknown headers than it is to convert them. (2) One should have no, or very limited, expectations that signed headers will survive downgrading (or downgrading and later upgrading) unless the signature mechanism is defined as occurring only over known headers that are well-defined wrt both syntax and semantics. (3) If one had a signature over the entire message body (not one body part at a time), any attempt to encapsulate the headers and incorporate them as a new body part (or multipart/ part) will probably destroy that signature unless it is very carefully defined and interpreted in a way that is sensitive to the downgrade process. (4) Certainly the insertion of new headers (in addition to the ones sent) will destroy a full-header signature. They, I believe obviously, should do so because otherwise there are wonderful opportunities for precisely the attacks that signed headers are typically intended to protect against. On the other hand, upgrading back to a signed message using additional ("Downgraded-...") headers for which responsibility is not guaranteed by a trusted party creates even greater risks of attacks unless one has a hash that is completely resistant to any possible alternate text matching the same signature. Recent developments suggest that the only way to get that involves massive good luck, not long-term technology. (5) If the combination of a signed full header set and a requirement for downgrading are encountered, there is a strong case to be made for bouncing, rather than downgrading the message and delivering the downgraded approximation. If that reasoning is even close to correct, then the documents (probably "downgrade", but possibly "framework") should contain an appropriate explanation and warning, but this topic is otherwise a rathole. Do you disagree? If so, do you have a proposal for how to do the downgrading in a way that will be robust against both filtering and signature techniques, both those that are now available and those that might be invented in the future? Such a proposal would be welcome for the current, 821/2821/822/2822 mail environment, quite independent of any i18n work. I await an I-D. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 14:22:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXiiv-0003mt-Gp; Wed, 11 Oct 2006 14:22:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXiiu-0003mn-B1 for ima@ietf.org; Wed, 11 Oct 2006 14:22:32 -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 1GXiis-0007G7-Rz for ima@ietf.org; Wed, 11 Oct 2006 14:22:32 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXihf-0000mx-3S for ima@ietf.org; Wed, 11 Oct 2006 20:21:15 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 20:21:15 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 20:21:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) Date: 11 Oct 2006 21:19:27 +0300 Lines: 127 Message-ID: <5dac42pvf4.fsf@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <452C98F0.4040802@alvestrand.no> <5diriqq3pr.fsf_-_@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.6 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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: > Kari, > > There is no question that there is a problem in this area. > Oddly, it isn't an i18nemail problem, although i18n may make it > more obvious. Well, are you saying that we should not try help i18nemail downgrade ? <...> > (iii) Those that it does not understand but that might, > in the mind of the sender, be required for understanding > or properly processing the message. In other words, the > sender would prefer that the message be bounced if the > receiver (or an intermediate system) cannot properly > interpret that field as intended. If it is allowed to try help i18nemail downgrade process, then draft-ietf-eai-utf8headers can define UTF8SMTP-required-headers header field, which list these header fields which sender want preserve and would prefer that the message be bounced if downgrade destrys these header fields. Note that this can not be UTF8SMTP-optional-headers because someone other that sender may add header fields during transport. > (1) It is at least as plausible, if not more so, to discard any > unknown headers than it is to convert them. Yes. However its is possible to try help i18nemail downgrade process. > (2) One should have no, or very limited, expectations that > signed headers will survive downgrading (or downgrading and > later upgrading) unless the signature mechanism is defined as > occurring only over known headers that are well-defined wrt both > syntax and semantics. > > (3) If one had a signature over the entire message body (not one > body part at a time), any attempt to encapsulate the headers and > incorporate them as a new body part (or multipart/ part) will > probably destroy that signature unless it is very carefully > defined and interpreted in a way that is sensitive to the > downgrade process. This prevent encapsulation of headers to new bydy part. This does NOT prevent encapsulation of whole mail to application/utf8smtp -part. But problem is that it may not be possible to detect, when this encapsulation of whole mail is required. One option is draft-ietf-eai-utf8headers to define UTF8SMTP-full-encapsulation header field, which triggers this. For example there may be UTF8SMTP-full-encapsulation: required when sender done signature over the entire message body. Essentially UTF8SMTP-full-encapsulation: required says that sender wants gatewaying operation and sender knows that recipient is able to upgrade i18nemail. > (4) Certainly the insertion of new headers (in addition to the > ones sent) will destroy a full-header signature. They, I > believe obviously, should do so because otherwise there are > wonderful opportunities for precisely the attacks that signed > headers are typically intended to protect against. On the other > hand, upgrading back to a signed message using additional > ("Downgraded-...") headers for which responsibility is not > guaranteed by a trusted party creates even greater risks of > attacks unless one has a hash that is completely resistant to > any possible alternate text matching the same signature. Recent > developments suggest that the only way to get that involves > massive good luck, not long-term technology. Also insertion of new headers happens to all mails. So signature mechanism are somewhat selective what they sign. > (5) If the combination of a signed full header set and a > requirement for downgrading are encountered, there is a strong > case to be made for bouncing, rather than downgrading the > message and delivering the downgraded approximation. Yes. Full encapsulation however is possible, although not desired. If contining my suggestion, there may be UTF8SMTP-full-encapsulation: bounce header field. > If that reasoning is even close to correct, then the documents > (probably "downgrade", but possibly "framework") should contain > an appropriate explanation and warning, but this topic is > otherwise a rathole. > > Do you disagree? If so, do you have a proposal for how to do > the downgrading in a way that will be robust against both > filtering and signature techniques, both those that are now > available and those that might be invented in the future? Such > a proposal would be welcome for the current, 821/2821/822/2822 > mail environment, quite independent of any i18n work. I await > an I-D. > > john / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 16:07:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXkMi-0004L8-Ul; Wed, 11 Oct 2006 16:07:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXkMh-0004Kw-MW for ima@ietf.org; Wed, 11 Oct 2006 16:07:43 -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 1GXkMe-0001mC-TM for ima@ietf.org; Wed, 11 Oct 2006 16:07:43 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GXkMe-00077F-69; Wed, 11 Oct 2006 16:07:40 -0400 Date: Wed, 11 Oct 2006 16:07:39 -0400 From: John C Klensin To: Kari Hurtta , ima@ietf.org Subject: Re: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) Message-ID: <50ECE5CFA15AA7519414B57B@p3.JCK.COM> In-Reply-To: <5dac42pvf4.fsf@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <452C98F0.4040802@alvestrand.no> <5diriqq3pr.fsf_-_@Hurtta06k.keh.iki.fi> <5dac42pvf4.fsf@Hurtta06k.keh.iki.fi> X-Mailer: Mulberry/4.0.6 (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: 2bf730a014b318fd3efd65b39b48818c Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 11 October, 2006 21:19 +0300 Kari Hurtta wrote: > John C Klensin writes in gmane.ietf.ima: > >> Kari, >> >> There is no question that there is a problem in this area. >> Oddly, it isn't an i18nemail problem, although i18n may make >> it more obvious. > > Well, are you saying that we should not try help i18nemail > downgrade ? Nope. See below. > <...> >> (iii) Those that it does not understand but that might, >> in the mind of the sender, be required for understanding >> or properly processing the message. In other words, the >> sender would prefer that the message be bounced if the >> receiver (or an intermediate system) cannot properly >> interpret that field as intended. > > If it is allowed to try help i18nemail downgrade process, > then draft-ietf-eai-utf8headers can define > > UTF8SMTP-required-headers > > header field, which list these header fields which sender > want preserve and would prefer that the message be bounced > if downgrade destrys these header fields. This is a very interesting idea, IMO. We would have to think through what should be listed and how, which would require a very specific proposal, but the idea is interesting. See below. > Note that this can not be > > UTF8SMTP-optional-headers > > because someone other that sender may add header fields > during transport. Yes, obviously. >> (1) It is at least as plausible, if not more so, to discard >> any unknown headers than it is to convert them. > > Yes. However its is possible to try help i18nemail downgrade > process. Perhaps. Or even "probably". >> (2) One should have no, or very limited, expectations that >> signed headers will survive downgrading (or downgrading and >> later upgrading) unless the signature mechanism is defined as >> occurring only over known headers that are well-defined wrt >> both syntax and semantics. >> >> (3) If one had a signature over the entire message body (not >> one body part at a time), any attempt to encapsulate the >> headers and incorporate them as a new body part (or >> multipart/ part) will probably destroy that signature unless >> it is very carefully defined and interpreted in a way that is >> sensitive to the downgrade process. > > This prevent encapsulation of headers to new bydy part. > This does NOT prevent encapsulation of whole mail to > application/utf8smtp -part. But I have yet to see a serious/complete proposal that provides whole-message encapsulation without a potential violation of the multiple encoding rule. Remember that the fact that I've got UTF8SMTP headers, and even 8BITMIME transport specified, does not prevent having a body part that is in Base64 or Q-P encoding. There are some other issues about using application/ for this, but maybe they aren't important in comparison. > But problem is that it may not be possible to detect, > when this encapsulation of whole mail is required. > > One option is draft-ietf-eai-utf8headers to define > > UTF8SMTP-full-encapsulation > > header field, which triggers this. I _think_ it just defers the problem. One of the things that yields complex MIME structures is message forwarding, with or without message/??? encapsulation. Someone trying to forward an i18n message to a non-i18n site presumably has to do the same analysis (or make the same determination) that an in-transit downgrading gateway would. That strikes me as hard and unlikely to be gotten right. > For example there may be > > UTF8SMTP-full-encapsulation: required > > when sender done signature over the entire message body. > > Essentially > > UTF8SMTP-full-encapsulation: required > > says that sender wants gatewaying operation and sender > knows that recipient is able to upgrade i18nemail. Yes. But, in the general case, the sender doesn't know and can't find out in a reliable way, at least in-band. I'd guess many potential recipients wouldn't know either, especially if this were an operation applied on the way to the message store, rather than in the MUA or POP/IMAP server. Just finding out a downgrade (alt-address) address is _lots_ easier and more reliable. >> (4) Certainly the insertion of new headers (in addition to the >> ones sent) will destroy a full-header signature. They, I >> believe obviously, should do so because otherwise there are >> wonderful opportunities for precisely the attacks that signed >> headers are typically intended to protect against. On the >> other hand, upgrading back to a signed message using >> additional ("Downgraded-...") headers for which >> responsibility is not guaranteed by a trusted party creates >> even greater risks of attacks unless one has a hash that is >> completely resistant to any possible alternate text matching >> the same signature. Recent developments suggest that the >> only way to get that involves massive good luck, not >> long-term technology. > > Also insertion of new headers happens to all mails. So > signature mechanism are somewhat selective what they sign. Yep. And that is why traditional uses of PGP and S/MIME don't sign headers at all. Whether existing signature mechanisms that do sign headers are selective enough is, I believe, an open question. >> (5) If the combination of a signed full header set and a >> requirement for downgrading are encountered, there is a strong >> case to be made for bouncing, rather than downgrading the >> message and delivering the downgraded approximation. > > Yes. Full encapsulation however is possible, although > not desired. > > If contining my suggestion, there may be > > UTF8SMTP-full-encapsulation: bounce > > header field. As you have probably gathered, I am a big fan of simplicity whenever possible and have not seen many complex things deploying, interoperating, and working on the Internet. The more complexity, and the more subtle interpretation of options, we discover that effective downgrading requires, the less I become a fan of downgrading. I think I'm in a small minority so far in believing that we should be considering the impact of a UTF8SMTP model that never downgrades in transit, but I think the number may grow as these complexities and restrictions accumulate. If we are going to have downgrading, and we are going to expect sufficient upgrading to permit signatures over the headers to function across the transformations, I think your suggestions may point the way to a workable solution ... or at least one that is more likely to be workable than anything else we have seen suggested. But I can't evaluate whether or not it is workable from email -- I need an I-D that I can sit down with and compare to 2821 and 2822, to the various signing standards and methods, etc. Any chance that you can get something written and posted before the cutoff? john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 17:07:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXlI4-0005cS-22; Wed, 11 Oct 2006 17:07:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXlI2-0005bq-HZ for ima@ietf.org; Wed, 11 Oct 2006 17:06:58 -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 1GXlI1-0000IH-7c for ima@ietf.org; Wed, 11 Oct 2006 17:06:58 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXk74-00020a-LQ for ima@ietf.org; Wed, 11 Oct 2006 21:51:34 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 21:51:34 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Oct 2006 21:51:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: 8BITMIME (Re: [EAI] Re: Comment about draft-ietf-eai-smtpext-01.txt) Date: 11 Oct 2006 22:49:43 +0300 Lines: 24 Message-ID: <5dslhubpk8.fsf@Hurtta06k.keh.iki.fi> References: <359811996.18208@cnnic.cn> <360291422.02247@cnnic.cn> <5dvemv81vy.fsf_-_@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 "Charles Lindsey" writes in gmane.ietf.ima: > OTOH, is is NOT true that bearly all servers are 8-bit clean as > regards the headers (sendmail is the most notable one that > isn't). Therefore we need to write our standard so that downgrading > (or maybe rerouting) is REQUIRED. Perhaps in 15 years time when all Yes. Sendmail drops characters 128-159 from headers. This allows ISO-8859-* on headers, but not UTF-8. / Kari Hurtta sendmail/collect.c: if (c >= 0200 && c <= 0237) { #if 0 /* causes complaints -- figure out something for 8.n+1 */ usrerr("Illegal character 0x%x in header", c); #else /* 0 */ /* EMPTY */ #endif /* 0 */ } _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 19:50:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXnqL-0004CU-JU; Wed, 11 Oct 2006 19:50:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXnqK-0004C2-4K for ima@ietf.org; Wed, 11 Oct 2006 19:50:32 -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 1GXnqI-000218-EP for ima@ietf.org; Wed, 11 Oct 2006 19:50:32 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXnp7-0006Xy-5S for ima@ietf.org; Thu, 12 Oct 2006 01:49:17 +0200 Received: from du-001-044.access.de.clara.net ([212.82.227.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 01:49:17 +0200 Received: from nobody by du-001-044.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 01:49:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Thu, 12 Oct 2006 01:39:29 +0200 Organization: Lines: 64 Message-ID: <452D80B1.2190@xyzzy.claranet.de> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-044.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [EAI] Re: Encapsulation is required (for some headers) 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: [2047] > It requires that every agent (especially agents generating encoded-words) > knows which headers are structured and which are unstructured. So if > somebody invents a new header and gets it approved by the IETF as a > Proposed Standard, then all implementations that encode or decode > RFC 2047 stuff magically become non-compliant overnight. The point of this rule is IMO that in-transit MTAs are free to ignore MIME, they still "see" what they might need to know, the (2)822 syntax of vital header fields. To some degree even the MUA of the receiver is free to ignore MIME, some header fields might look odd, some body parts might be shown as base64 garbage, but it is a syntactically valid message/rfc822, all essential operations like resend or reply still work for MIME-ignorants. I hope that you (this WG) get the same degree of backwards compatibility for message/utf8smtp. If you end up with "bounce" whenever a legacy MTA is on the route you're in trouble. >> If the syntax isn't known the default is , > No it isn't, and it cannot be. That MUSTard is in RFC 2822 3.6.8 (optional header fields), for optional header fields MIME-ignorants don't need to know the structure (if any). If the "optional header fields" in 2822 are the same as the "extension- fields" in 822, then they are covered by RFC 2047 5 (1). You can encode them as is, their structure (if any) isn't vital for MIME-ignorants. Kari pointed out that that's confusing for agents knowing the structure. But maybe that can never happen as far as utf8smtp is concerned: Either header fields are upgraded somehow again, then 2047-encodings introduced by downgrading are decoded. Or there's no opportunity to ugrade the header fields, then the MTA or MUA trying to do something with these header fields cannot handle utf8smtp, and an additionally lost structure just confirms that it cannot handle the header field, downgraded or not. That's when we started to discuss plan B (= at least change the header field name before you encode the unknown header field body), and plan C, convert the message/utf8smtp to a message/rfc822 containing the original message/utf8smtp as is. That would BTW preserve DKIM signatures, DKIM is designed to work on a complete message/rfc822, it could also handle an unmodified message/utf8smtp part whereever it is. Kari's next objection was that multipart/xyz with a text/xyz (for the original utf8smtp header) plus a second part for the original body is more friendly for UAs. That's tricky, RFC 2049 (IIRC) says that unknown message subtypes should be handled as application/octet-stream. That's not what you want for years until all MUAs can handle message/utf8smtp. OTOH the multipart + text idea might be more complex for gateways, and John apparently thinks that downgrade will never work if it's not KISS. Or maybe it's just my interpretation because I'm a KISS (and MIME) fan. I've seen the effect of message/news produced by my UA with another UA treating it as application/octet-stream, it's ugly (open with notepad and similar stunts). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 11 21:34:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXpTC-0003f1-FN; Wed, 11 Oct 2006 21:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXpTB-0003ew-6I for ima@ietf.org; Wed, 11 Oct 2006 21:34:45 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXpT7-0004UE-8e for ima@ietf.org; Wed, 11 Oct 2006 21:34:45 -0400 Received: (eyou send program); Thu, 12 Oct 2006 09:34:18 +0800 Message-ID: <360616858.28794@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Thu, 12 Oct 2006 09:34:18 +0800 Message-ID: <00df01c6ed9e$8d364e80$1206e29f@cnnicyao> From: "Yao Jiankang" To: "John C Klensin" , "Kari Hurtta" References: <200610091207.k99C7hlw031587@siilo.fmi.fi> <360396799.27082@cnnic.cn> Subject: Re: [EAI] Re: BODY=8BITMIME or BINARYMIME (was: Re: Comment about draft-ietf-eai-smtpext-01.txt) Date: Thu, 12 Oct 2006 09:34:25 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Content-Type: multipart/mixed; boundary="===============0838553066==" Errors-To: ima-bounces@ietf.org --===============0838553066== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8 a2xlbnNpbkBqY2suY29tPg0KVG86ICJLYXJpIEh1cnR0YSIgPGh1cnR0YStnbWFuZUBzaWlsby5m bWkuZmk+DQpDYzogPGltYUBpZXRmLm9yZz4NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAwOSwgMjAw NiA4OjI1IFBNDQpTdWJqZWN0OiBbRUFJXSBSZTogQk9EWT04QklUTUlNRSBvciBCSU5BUllNSU1F ICh3YXM6IFJlOiBDb21tZW50IGFib3V0IGRyYWZ0LWlldGYtZWFpLXNtdHBleHQtMDEudHh0KQ0K DQoNCj4gDQo+IA0KPiAtLU9uIE1vbmRheSwgT2N0b2JlciAwOSwgMjAwNiAxNTowNyArMDMwMCBL YXJpIEh1cnR0YSANCj4gPGh1cnR0YStnbWFuZUBzaWlsby5mbWkuZmk+IHdyb3RlOg0KPiANCj4+ Pj4+IEpvaG4gQyBLbGVuc2luDQo+Pj4gT25lIGNhbid0IGhhdmUgYm90aCBvbiB0aGUgc2FtZSBt ZXNzYWdlLiAgQnV0IEJJTkFSWU1JTUUNCj4+PiBkb2Vzbid0ICBjaGFuZ2UgdGhlIHN5bnRheCBv ciBtZWNoYW5pc21zIG9mIHRoZSBoZWFkZXJzLCBvbmx5DQo+Pj4gdGhhdCBvZiAgYm9keSBwYXJ0 cyAod2hpY2ggaXMgY2xlYXIgZnJvbSB0aGUgZGVzY3JpcHRpb24pLg0KPj4+IFNvIEkgZG9uJ3Qg IHNlZSBhbnkgY29uZmxpY3QsIGkuZS4sIHBhcmFtZXRlcnMgb2YNCj4+Pg0KPj4+ICAgIFVURjhI RUFERVJTICBpbXBsaWVzIDdCSVQgYm9keSBhbmQgOGJpdCwgbGluZS1vcmllbnRlZA0KPj4+ICAg IGhlYWRlcnMNCj4+Pg0KPj4+ICAgIFVURjhIRUFERVJTKzhCSVRNSU1FIGltcGxpZXMgbGluZS1v cmllbnRlZCA4Yml0IGJvZHkgYW5kDQo+Pj4gOGJpdCwgbGluZS1vcmllbnRlZCBoZWFkZXJzDQo+ Pj4NCj4+PiAgICBVVEY4SEVBREVSUytCSU5BUllNSU1FIGltcGxpZXMgYXJiaXRyYXJ5IGJpdHN0 cmVhbSBiaW5hcnkNCj4+PiBib2R5IGluIDhiaXQgdHJhbnNtaXNzaW9uIGZvcm0gYW5kIDhiaXQs IGxpbmUtb3JpZW50ZWQNCj4+PiBoZWFkZXJzLg0KPj4+DQo+Pj4gRG9lcyB0aGF0IHNlZW0gcGxh dXNpYmxlPw0KPj4NCj4+IFllcy4NCj4gDQo+IFlhbywgaWYgb3RoZXJzIGFncmVlLCBjYW4gd2Ug Z2V0IHRoaXMgaW50byB0aGUgc3BlYz8gICBXb3VsZCB5b3UgDQo+IGxpa2UgbWUgdG8gZHJhZnQg dGV4dCwgb3IgY2FuIHlvdSBtYW5hZ2UgdGhhdD8NCg0KWWVzLCBJIHdpbGwgdHJ5IHRvIGdldCB0 aGlzIGludG8gc210cGV4dCBzcGVjLiANCnRoYW5rcy4NCg0KWWFvIEppYW5ha25nDQpDTk5JQw0K DQoNCj4gDQo+ICAgICAgam9obg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEgbWFpbGluZyBsaXN0DQo+IElNQUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWE= --===============0838553066== 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 --===============0838553066==-- From ima-bounces@ietf.org Thu Oct 12 01:27:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXt5q-0002sN-AJ; Thu, 12 Oct 2006 01:26:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXt5p-0002s9-4R for ima@ietf.org; Thu, 12 Oct 2006 01:26:53 -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 1GXt5n-0008Dz-KG for ima@ietf.org; Thu, 12 Oct 2006 01:26:53 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GXt5b-00019w-Ej for ima@ietf.org; Thu, 12 Oct 2006 07:26:39 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 07:26:39 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 07:26:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Re: Encapsulation is required (for some headers) Date: 12 Oct 2006 08:26:02 +0300 Lines: 119 Message-ID: <5dy7rmgl5h.fsf@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <452D80B1.2190@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Charles Lindsey wrote: > > [2047] > > It requires that every agent (especially agents generating encoded-words) > > knows which headers are structured and which are unstructured. So if > > somebody invents a new header and gets it approved by the IETF as a > > Proposed Standard, then all implementations that encode or decode > > RFC 2047 stuff magically become non-compliant overnight. > > The point of this rule is IMO that in-transit MTAs are free to ignore > MIME, they still "see" what they might need to know, the (2)822 syntax > of vital header fields. > > To some degree even the MUA of the receiver is free to ignore MIME, some > header fields might look odd, some body parts might be shown as base64 > garbage, but it is a syntactically valid message/rfc822, all essential > operations like resend or reply still work for MIME-ignorants. > > I hope that you (this WG) get the same degree of backwards compatibility > for message/utf8smtp. If you end up with "bounce" whenever a legacy MTA > is on the route you're in trouble. > > >> If the syntax isn't known the default is , > > No it isn't, and it cannot be. > > That MUSTard is in RFC 2822 3.6.8 (optional header fields), for optional > header fields MIME-ignorants don't need to know the structure (if any). > > If the "optional header fields" in 2822 are the same as the "extension- > fields" in 822, then they are covered by RFC 2047 5 (1). You can encode > them as is, their structure (if any) isn't vital for MIME-ignorants. > > Kari pointed out that that's confusing for agents knowing the structure. That says: (1) An 'encoded-word' may replace a 'text' token (as defined by RFC 822) in any Subject or Comments header field, any extension message header field, or any MIME body part field for which the field body is defined as '*text'. An 'encoded-word' may also appear in any user-defined ("X-") message or body part header field. This gives 'default is ' for X- headers, but IMHO that is unclear for other header fields. Anyway that default can not be used (as I noted.) > But maybe that can never happen as far as utf8smtp is concerned: Either > header fields are upgraded somehow again, then 2047-encodings introduced > by downgrading are decoded. Or there's no opportunity to ugrade the > header fields, then the MTA or MUA trying to do something with these > header fields cannot handle utf8smtp, and an additionally lost structure > just confirms that it cannot handle the header field, downgraded or not. ( I think that I'm lost. ) > That's when we started to discuss plan B (= at least change the header > field name before you encode the unknown header field body), and plan C, > convert the message/utf8smtp to a message/rfc822 containing the original > message/utf8smtp as is. That would BTW preserve DKIM signatures, DKIM > is designed to work on a complete message/rfc822, it could also handle > an unmodified message/utf8smtp part whereever it is. And on someplace on suggestion I changed message/utf8smtp to application/utf8smtp if idea was to use encapsulation. That provides double encoding what on message/* is not allowed. ( Was someone trying to register application/mime on past? ) > Kari's next objection was that multipart/xyz with a text/xyz (for the > original utf8smtp header) plus a second part for the original body is > more friendly for UAs. That's tricky, RFC 2049 (IIRC) says that unknown > message subtypes should be handled as application/octet-stream. That's > not what you want for years until all MUAs can handle message/utf8smtp. text/xyz and putting unknown header fields to new header field (ie. change the header field name before encoding) are alternative methods to encapsulate individual header fields. But perhaps just putting them to new header field is simpler. I really not know which one alternative works better. It was more like analyze what is required to put unknown header fields to new body part. That new body part idea was mentioned on several articles. But perhaps I just misunderstand what was idea. Using text/* just gives 'use text/plain for unknown subparts' -rule. > OTOH the multipart + text idea might be more complex for gateways, and > John apparently thinks that downgrade will never work if it's not KISS. > Or maybe it's just my interpretation because I'm a KISS (and MIME) fan. What gateways you are thinking? That may fawor "new header field" -alternative. > I've seen the effect of message/news produced by my UA with another UA > treating it as application/octet-stream, it's ugly (open with notepad > and similar stunts). I think that message/* do not fly. > Frank I think that there is now some aggreement what is required mail header (as whole) handling. I think John Klensin was also suggesting that unknown mail header fields should be dropped instead (if that is route, then there is my suggestion about "UTF8SMTP-required-headers" header field. ) Then there is mime header part's of mail. And signed mail issue, which John Klensin mentioned. ( There I suggested "UTF8SMTP-full-encapsulation: required" and application/utf8smtp for encapsulation. That is little radical. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 02:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXuHf-0005qW-6I; Thu, 12 Oct 2006 02:43:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXuHd-0005pl-Dc for ima@ietf.org; Thu, 12 Oct 2006 02:43:09 -0400 Received: from smtp2gate.fmi.fi ([193.166.223.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXuHb-0000WT-Vy for ima@ietf.org; Thu, 12 Oct 2006 02:43:09 -0400 Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@siilo.fmi.fi) by smtp2gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20041007) with ESMTP id k9C6h3rn028632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Oct 2006 09:43:03 +0300 Received: from siilo.fmi.fi by torkku.fmi.fi with ESMTP id k9C6h3V1028732 ; Thu, 12 Oct 2006 09:43:03 +0300 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id k9C6h203024893 ; Thu, 12 Oct 2006 09:43:02 +0300 Received: by siilo.fmi.fi id k9C6h2OB024890; Thu, 12 Oct 2006 09:43:02 +0300 Message-Id: <200610120643.k9C6h2OB024890@siilo.fmi.fi> Subject: Re: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) In-Reply-To: <50ECE5CFA15AA7519414B57B@p3.JCK.COM> To: John C Klensin Date: Thu, 12 Oct 2006 09:43:01 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123d (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 20061012/15289/01 X-Filter: smtp2gate: ID 15288/01, 1 parts scanned for known viruses X-Filter: torkku: ID 1977/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp2gate: ID 15288/01) report=BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 >>> John C Klensin > >> (3) If one had a signature over the entire message body (not > >> one body part at a time), any attempt to encapsulate the > >> headers and incorporate them as a new body part (or > >> multipart/ part) will probably destroy that signature unless > >> it is very carefully defined and interpreted in a way that is > >> sensitive to the downgrade process. > > > > This prevent encapsulation of headers to new bydy part. > > > This does NOT prevent encapsulation of whole mail to > > application/utf8smtp -part. > > But I have yet to see a serious/complete proposal that provides > whole-message encapsulation without a potential violation of the > multiple encoding rule. Remember that the fact that I've got > UTF8SMTP headers, and even 8BITMIME transport specified, does > not prevent having a body part that is in Base64 or Q-P encoding. > > There are some other issues about using application/ for this, > but maybe they aren't important in comparison. Effectively application/utf8smtp WILL violate the multiple encoding rule. However, it no violate letter of that rule (on MIME standard.) Someone was trying to get application/mime on some other working group for same purpose on past? I think that if that is forbidden, only what can do is provide signal 'bounce if conversion is required'. (That is UTF8SMTP-full-encapsulation: bounce in my previous article, but it also can be ESMTP parameter to MAIL -command. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 04:32:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXvyx-0008N7-LE; Thu, 12 Oct 2006 04:31:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXvyw-0008N2-MC for ima@ietf.org; Thu, 12 Oct 2006 04:31:58 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXvyv-0008RG-D4 for ima@ietf.org; Thu, 12 Oct 2006 04:31:58 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6C10F2596EF; Thu, 12 Oct 2006 10:29:23 +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 21117-04; Thu, 12 Oct 2006 10:29:16 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 718F72596F0; Thu, 12 Oct 2006 10:29:16 +0200 (CEST) Message-ID: <452DFD75.5040201@alvestrand.no> Date: Thu, 12 Oct 2006 01:31:49 -0700 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Structured vs unstructured (Re: [EAI] Re: Encapsulation is required (for some headers)) References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <452D80B1.2190@xyzzy.claranet.de> In-Reply-To: <452D80B1.2190@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ima@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 I wonder if my memory is fooling me.... A rather surprising result of some analysis we did in the work on the MIXER specification was that in order for an implementation to be robust, it had to treat all unknown header fields as *structured* header fields, not unstructured ones. There is a difference between structured and unstructured in folding; structured header field bodie (RFC 2822 section 2.2.2) can only be split at existing/allowed whitespace, while unstructured field bodies can, in theory, be split anywhere, since spaces are legal anywhere in their content. So if you assume that a field is unstructured, you may split it somewhere it causes damage; if you assume that it's structured, you'll do no harm even when it's unstructured. Surprising, but consistent. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 06:07:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxSq-0002Pe-5a; Thu, 12 Oct 2006 06:06:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxSp-0002PZ-CJ for ima@ietf.org; Thu, 12 Oct 2006 06:06:55 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXxSf-0007ZT-LI for ima@ietf.org; Thu, 12 Oct 2006 06:06: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-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id 452e1397.f84f.8d for ima@ietf.org; Thu, 12 Oct 2006 11:06: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 k9CA5wrp026067 for ; Thu, 12 Oct 2006 11:05:59 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] Re: Encapsulation is required (for some headers) References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <5dpscyq4b4.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Thu, 12 Oct 2006 11:05: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: <5dpscyq4b4.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 11 Oct 2006 16:07:27 +0100, Kari Hurtta wrote: > "Charles Lindsey" writes in gmane.ietf.ima: >> It requires that every agent (especially agents generating >> encoded-words) knows which headers are structured and which are >> unstructured. So if somebody invents a new header and gets it >> approved by the IETF as a Proposed Standard, then all implementations >> that encode or decode RFC 2047 stuff magically become non-compliant >> overnight. > > Well, if MUA does not implement some standard, it either do not generate > headers of that standard. So I do not think that this happends on MUAs > which are generating encoded-words. (or what I are missed?) No, that is not correct. A decent NUA (which excludes quite a lot of them) will allow the sender to add any headers that he fancies. Let us suppose that the sender knows about this new Foobar: header (and that he understands the correct way to use it). So he writes in the new header (and it happens to contain some utf-8). And then he expects the existing MUA to send it, and he expects the far end (which he happens to know has been upgraded) to recognise it and take the appropriate protocol action. So his MUA has to decide whether to assume the unknown header is unstructured (it then just uses RFC 2047) or not (it then replaces it with a Downgraded: Foobar: <2047 encoding of utf-8 stuff> ) if it guesses wrong, the far end may not understand it (though the 2nd alternative is probably the best guess, if guess it must). It seems the nice thing about the Downgraded: header is that it will work for both structured and unstructured headers, provided only that the far end is utf8smtp-compliant, and knows that is must upgrade any Downgraded headers before it does anything else (or its friendly neighbourhood POP3 or IMAP does it for him). -- 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 Oct 12 06:10:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxW1-0003Cc-NY; Thu, 12 Oct 2006 06:10:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxW0-0003Bq-FW for ima@ietf.org; Thu, 12 Oct 2006 06:10:12 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXxVv-0007vR-N1 for ima@ietf.org; Thu, 12 Oct 2006 06:10:12 -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.231) id 452e147c.1018d.84 for ima@ietf.org; Thu, 12 Oct 2006 11:10:04 +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 k9CAA2x9026319 for ; Thu, 12 Oct 2006 11:10:03 +0100 (BST) To: ima@ietf.org Subject: Re: [EAI] Re: Encapsulation is required (for some headers) References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <452D80B1.2190@xyzzy.claranet.de> Message-ID: Date: Thu, 12 Oct 2006 11:10:02 +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: <452D80B1.2190@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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, 12 Oct 2006 00:39:29 +0100, Frank Ellermann wrote: > Charles Lindsey wrote: > > [2047] >> It requires that every agent (especially agents generating >> encoded-words) >> knows which headers are structured and which are unstructured. So if >> somebody invents a new header and gets it approved by the IETF as a >> Proposed Standard, then all implementations that encode or decode >> RFC 2047 stuff magically become non-compliant overnight. > > The point of this rule is IMO that in-transit MTAs are free to ignore > MIME, they still "see" what they might need to know, the (2)822 syntax > of vital header fields. Sure, but we are concerned with the end-points, which cannot ignore MIME. > > To some degree even the MUA of the receiver is free to ignore MIME, some > header fields might look odd, some body parts might be shown as base64 > garbage, but it is a syntactically valid message/rfc822, all essential > operations like resend or reply still work for MIME-ignorants. Yes, if push comes to shove, the recipient MUA can display 2047 stuff (and even Downgraded: headers) exactly as received, and let the reader figure out what to do with it. Messy and inconvenient, but not illegal, and no information has been lost. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 06:13:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxYn-0005Ry-2P; Thu, 12 Oct 2006 06:13:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxYl-0005Rl-4l for ima@ietf.org; Thu, 12 Oct 2006 06:13:03 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXxYj-0008HB-Jz for ima@ietf.org; Thu, 12 Oct 2006 06: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-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id 452e152c.f865.75; Thu, 12 Oct 2006 11:13:00 +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 k9CACwlW026499; Thu, 12 Oct 2006 11:12:59 +0100 (BST) To: "Kari Hurtta" , ima@ietf.org Subject: Re: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <452C98F0.4040802@alvestrand.no> <5diriqq3pr.fsf_-_@Hurtta06k.keh.iki.fi> Message-ID: Date: Thu, 12 Oct 2006 11: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: <5diriqq3pr.fsf_-_@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) 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 On Wed, 11 Oct 2006 16:20:16 +0100, Kari Hurtta wrote: > A, an i18mail user, sends to X, an ascii user. > > Message contains protocol elements for which converting gateway is not > aware. > > Encapsulation does not require knowing these protocol elements. And neither does use of the Downgraded: header. So that is no argument for building complete message encapsulation into the protocol. Whatever one can achieve, so can the other. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 06:27:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxmU-00042W-OC; Thu, 12 Oct 2006 06:27:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXxmS-0003qK-LS for ima@ietf.org; Thu, 12 Oct 2006 06:27:12 -0400 Received: from smtp1gate.fmi.fi ([193.166.223.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXxmR-0001gA-7C for ima@ietf.org; Thu, 12 Oct 2006 06:27:12 -0400 Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@siilo.fmi.fi) by smtp1gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20041007) with ESMTP id k9CAR8NU020600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Oct 2006 13:27:08 +0300 Received: from siilo.fmi.fi by torkku.fmi.fi with ESMTP id k9CAR7U6032176 ; Thu, 12 Oct 2006 13:27:07 +0300 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id k9CAR7Y4027152 ; Thu, 12 Oct 2006 13:27:07 +0300 Received: by siilo.fmi.fi id k9CAR7Rj027149; Thu, 12 Oct 2006 13:27:07 +0300 Message-Id: <200610121027.k9CAR7Rj027149@siilo.fmi.fi> Subject: Re: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) In-Reply-To: To: Charles Lindsey Date: Thu, 12 Oct 2006 13:27:07 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123d (25)] MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Filter: smtp1gate: 3 received headers rewritten with id 20061012/18564/01 X-Filter: smtp1gate: ID 18563/01, 1 parts scanned for known viruses X-Filter: torkku: ID 2202/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp1gate: ID 18563/01) report=BAYES_00,FORGED_RCVD_HELO Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp1gate.fmi.fi id k9CAR8NU020600 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 >>> Charles Lindsey > On Wed, 11 Oct 2006 16:20:16 +0100, Kari Hurtta =20 > wrote: >=20 > > A, an i18mail user, sends to X, an ascii user. > > > > Message contains protocol elements for which converting gateway is n= ot > > aware. > > > > Encapsulation does not require knowing these protocol elements. >=20 > And neither does use of the Downgraded: header. So that is no argument = for =20 > building complete message encapsulation into the protocol. Whatever one= =20 > can achieve, so can the other. Downgraded: header is encapsulation, but there is cases where that mini encapsulation do not handle, I think. =20 These cases however may require something like application/utf8smtp and s= eems=20 that it is not acceptable.=20 =20 > --=20 > Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own=A0thing= ------------------------ > Tel:=A0+44=A0161=A0436=A06131=A0 =20 > =A0=A0=A0Web:=A0http://www.cs.man.ac.uk/~chl > Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewood=A0= Ave,=A0CHEADLE,=A0SK8=A03JU,=A0U.K. > PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051=A093=A0= A0=A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0A5 / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 06:43:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXy1q-0005Gn-Ev; Thu, 12 Oct 2006 06:43:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXy1p-0005Gi-Ow for ima@ietf.org; Thu, 12 Oct 2006 06:43:05 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXy1n-0004Aq-PY for ima@ietf.org; Thu, 12 Oct 2006 06:43:05 -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.231) id 452e1c2d.352b.217 for ima@ietf.org; Thu, 12 Oct 2006 11:42:53 +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 k9CAgmdp028321 for ; Thu, 12 Oct 2006 11:42:48 +0100 (BST) To: "ima@ietf.org" Subject: Re: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <452C98F0.4040802@alvestrand.no> <5diriqq3pr.fsf_-_@Hurtta06k.keh.iki.fi> Message-ID: Date: Thu, 12 Oct 2006 11:42:47 +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: 1.1 (+) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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, 11 Oct 2006 18:01:52 +0100, John C Klensin wrote: > For example, assume that a plain-ASCII (821/822 conformant) user > sends a message to A, a plain-ASCII (2821/2822 conformant) user. > Somewhere between the two there is a protective relay or gateway > -- a spam filter, an applications-level firewall trying to keep > malware out of a LAN, a gateway into some other transport > environment, or something else. Now that intermediate system is > faced with the following sorts of headers: But I don't wee why such a filter should be trying to introduce utf8smtp stuff (and hence a necessity to downgrade) where there was none before). So the situation (and problem, if any) you describe already exists on the present network, and I am not aware that present systems have to worry about it. You need to discuss an example where at leats one of the endpoints is trying to use utf8smtp. > > (i) Those that it understands by virtue of their being > required by 2822 > > (ii) Those that it thinks it understands. Note that it > could be wrong about this, because there is no required > /standard definition of the content of any header field > other than those in 2822 and updating standards and, > more important, no way to know the properties of any > header developed subsequent to the implementation base > of the intermediary. > > (iii) Those that it does not understand but that might, > in the mind of the sender, be required for understanding > or properly processing the message. In other words, the > sender would prefer that the message be bounced if the > receiver (or an intermediate system) cannot properly > interpret that field as intended. I think the number of readers taking that attitude will be relatively small - a plausible example with some existing but rarely used header might help - maybe one of those headers which requests that an acknowledgement receipt be ruturned. > > (iv) Those that it does not understand but that are, in > the mind of the sender, simply additional information > associated about the message. In other words, the > sender would like the message delivered regardless of > whether this information can be delivered or not. > > There is no possible way for the intermediate system to > distinguish between (iii) and (iv). There is actually no way to > distinguish (ii) from either of them either, but the belief that > one understands the field might be worth the risk. > > Now, what is the intermediate to do? If it has a security > motivation and fears malware triggers or inappropriate > information disclosure, it should probably either bounce the > message or discard all headers that are not in the first > category or maybe the first two. "Discard" is more common than > "bounce" today, but neither is unheard of. I would regard discarding of any header by intermediaries as a gross violation of the protocols, and if you tell me it is commenly done, then I am dismayed. Anyway, suppose we want a mechanism for the sender to be able to say "if you cannot transmit the Foobar header, then please bounce rather than munge/discard it. Ok, that may be a need, and it is a good example of a feature that might require one o those s to the Header-Type header (or whatever we finally call it) which Harald was asking about. So the sender writes: Header-Type: UTF8SMTP; headers-not-to-be-discarded="Foobar,Barfoo" or something like that (and maybe another parameter for headers you actively wish to be bounced). > Unfortunately, if a > signature has been computed across the full set of headers and > some are discarded, verification of the signature by the > receiver will fail. That is a matter of correct design of the header-signature protocol. For sure, any such signature scheme should include, with the signature, a list of the headers included within it. E.g. PGPVERIFY does that, but PGPMOOSE doesn't. Designing such a scheme is hard work to get it right, but I am sure it is doable (and I have some experience of trying to do it). > (4) Certainly the insertion of new headers (in addition to the > ones sent) will destroy a full-header signature. No, that certainly should not be so (and is not so with either of the schemes I mentioned above). > They, I > believe obviously, should do so because otherwise there are > wonderful opportunities for precisely the attacks that signed > headers are typically intended to protect against. The headers you should sign are exactly those necessary to prevent the scam you are trying to stop - no more, no less. -- 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 Oct 12 10:50:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1t1-0006AD-Ob; Thu, 12 Oct 2006 10:50:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1t0-0006A6-CH for ima@ietf.org; Thu, 12 Oct 2006 10:50:14 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY1su-0002T9-M9 for ima@ietf.org; Thu, 12 Oct 2006 10:50: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-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id 452e5614.16636.68; Thu, 12 Oct 2006 15:49: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 k9CEnrOO014172; Thu, 12 Oct 2006 15:49:54 +0100 (BST) To: "John C Klensin" , ima@ietf.org Subject: Re: [EAI] text for eai-framework re: 2047+S/MIME References: Message-ID: Date: Thu, 12 Oct 2006 15:49:52 +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: 8f374d0786b25a451ef87d82c076f593 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 Wed, 11 Oct 2006 16:10:07 +0100, John C Klensin wrote: > But signed messages are sensitive enough to any changes at all > in whatever the signature was calculated over that "sign, > downgrade, upgrade, check signature" is almost guaranteed to > fail (again, assuming signature over what is being upgraded or > downgraded). > > I see only a few ways out of this: > > (1) Sign only body parts, one at a time, not headers. Gee, that > is what S/MIME and PGP usually do. Almost, but not quite. Suppose the body of the message is just plain text. After signing, it _might_ look like this: Header-Type: UTF8SMTP From: } which might or might not have utf-8 To: } in them Mime-Version: 1.0 Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; protocol="application/pgp-signature" --bar & Content-Type: text/plain; (utf8-comment) charset=iso-8859-1; name="utf8-name" & Content-Transfer-Encoding: quoted-printable & & =A1Hola! & & Did you know that talking to yourself is a sign of senility? --bar Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 ...................................... -----END PGP MESSAGE----- --bar-- Just to be awkward, I included some utf-8 in the Content-Type header of the text/plain. I am sure no existsting signature program would do such a stupid thing, but it is legal. So, it it comes to some non-utf8smtp MTA, it has to be downgraded (using RFC 2047 for the and RFC 2231 for the ,)and the signature is now broken unless a subsequent upgrade can mend it. But why does it need to be downgraded? A. because the MTA might not support 8BITMIME either, and you cannot fix utf-8 in those headers by providing a CTE. OK, an exceedingly rare case, but not impossible. We might regard it as an accecptable risk, with a warning not to do those awkward things. Things get more interesting if the body of the message is some message/rfc822. Then you get: Header-Type: UTF8SMTP From: } which might or might not have utf-8 To: } in them Mime-Version: 1.0 Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; protocol="application/pgp-signature" --bar & Content-Type: message/rfc822 (utf8-comment) charset=iso-8859-1; & name="utf8-name" & & Header-Type: UTF8SMTP & From: } which might or might not have utf-8 & To: } in them & Subject: uft8-subject & Content-Transfer-Encoding: quoted-printable & & =A1Hola! & & Did you know that talking to yourself is a sign of senility? --bar Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 ...................................... -----END PGP MESSAGE----- --bar-- Now, in addition to the two 'awkward' cases in the Content-Type (which were totally stupid and useless) we have a Subject header to downgrade (with RFC 2047), and that is not stupid at all. But, again, if it is subsequently upgraded, it should be OK EXCEPT in the case where it had already been RFC 2047 encoded by the original MUA (unnecessary if UTF8SMTP was supported, but not disallowed). Now the upgrading agent does not know whether or not it is to be decoded before checking the signature. And THAT is the real case we have to worry about - everything else in pgp-signed should work fine. To make things still more interesting, suppose the thing we are trying to sign is some complete multipart/mixed. RFC is totally silent on hos to cope with that case, or even whether it is allowed. I someone will explain to me what is _supposed_ to happen in that case (even with no utf-8 in sight), then I would have a look at it. > > (2) Encapsulate the signed message, signature and all. This > will require some very careful de-encapsulation but should, in > principle, work. Yes, but that introduces all sorts of other complications, and there should be a clear demonstration of its necessity before we build it into the main protocol. (No prob;em it it is offered as an additiional feature, which the user can call upon manually when all else fails.) > (3) Prohibit downgrading of signed messages. I note that we > have no mechanism for doing that today. One can prohibit > automatic and general downgrading by leaving off the ALT-ADDRESS > parameter, but cannot now prohibit a number of other possible > strategies, especially those performed by a Submission MTA using > out of band information. I hope that can be avoided at least with pgp-signed etc. Sure there is a problem with a mechanism which signs the headers, but there is no such mechanism standardized as yet. It should be no problem PROVIDED this is taken into account when any such standard is written (but that may be difficult to bring about. -- 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 Oct 12 10:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1v3-0008HQ-C5; Thu, 12 Oct 2006 10:52:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY1v2-0008CC-C6 for ima@ietf.org; Thu, 12 Oct 2006 10:52:20 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY1uy-00036H-RP for ima@ietf.org; Thu, 12 Oct 2006 10:52: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-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id 452e569f.11aed.164; Thu, 12 Oct 2006 15:52: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 k9CEqD0A014319; Thu, 12 Oct 2006 15:52:14 +0100 (BST) To: "Kari Hurtta" Subject: Re: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) References: <200610121027.k9CAR7Rj027149@siilo.fmi.fi> Message-ID: Date: Thu, 12 Oct 2006 15:52:12 +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: <200610121027.k9CAR7Rj027149@siilo.fmi.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 12 Oct 2006 11:27:07 +0100, Kari Hurtta wrote: >>>> Charles Lindsey >> building complete message encapsulation into the protocol. Whatever one >> can achieve, so can the other. > > Downgraded: header is encapsulation, but there is cases where that > mini encapsulation do not handle, I think. Then please show us such a case, and we can look at 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 Thu Oct 12 14:01:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY4r0-0004fQ-NG; Thu, 12 Oct 2006 14:00:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY4qy-0004fK-LF for ima@ietf.org; Thu, 12 Oct 2006 14:00:20 -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 1GY4qs-0000GI-1C for ima@ietf.org; Thu, 12 Oct 2006 14:00:20 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GY4by-0004kr-GY for ima@ietf.org; Thu, 12 Oct 2006 19:44:50 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 19:44:50 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 19:44:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Re: Encapsulation is required (for some headers) Date: 12 Oct 2006 20:40:00 +0300 Lines: 27 Message-ID: <5dwt75juvj.fsf@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <452D80B1.2190@xyzzy.claranet.de> <5dy7rmgl5h.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes in gmane.ietf.ima: > Frank Ellermann writes in gmane.ietf.ima: > <...> > > But maybe that can never happen as far as utf8smtp is concerned: Either > > header fields are upgraded somehow again, then 2047-encodings introduced > > by downgrading are decoded. Or there's no opportunity to ugrade the > > header fields, then the MTA or MUA trying to do something with these > > header fields cannot handle utf8smtp, and an additionally lost structure > > just confirms that it cannot handle the header field, downgraded or not. > > ( I think that I'm lost. ) > <...> > I think John Klensin was also suggesting that unknown mail header fields > should be dropped instead (if that is route, then there is my suggestion > about "UTF8SMTP-required-headers" header field. ) > > Then there is mime header part's of mail. Hmm. It occurs to me that encapsulation to Downgraded: -header field is equivalent of removing header field if recipient is not i18nmail-aware. So maybe there also on need of "UTF8SMTP-required-headers" header field (or equivalent) also on that case? / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 14:08:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY4z6-0000sh-6s; Thu, 12 Oct 2006 14:08:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY4z5-0000sR-3p for ima@ietf.org; Thu, 12 Oct 2006 14:08:43 -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 1GY4z2-00045Y-QN for ima@ietf.org; Thu, 12 Oct 2006 14:08:43 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GY4qf-00013h-TQ for ima@ietf.org; Thu, 12 Oct 2006 20:00:03 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 20:00:01 +0200 Received: from hurtta+ietf by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 20:00:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) Date: 12 Oct 2006 20:25:48 +0300 Lines: 89 Message-ID: <5d1wpdla3n.fsf_-_@Hurtta06k.keh.iki.fi> References: <200610121027.k9CAR7Rj027149@siilo.fmi.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 Thu, 12 Oct 2006 11:27:07 +0100, Kari Hurtta > wrote: > > >>>> Charles Lindsey > > >> building complete message encapsulation into the protocol. Whatever one > >> can achieve, so can the other. > > > > Downgraded: header is encapsulation, but there is cases where that > > mini encapsulation do not handle, I think. > > Then please show us such a case, and we can look at it. NOTE: One soluntion is to forbid data on i18nmail if Downgraded: -header field can not handle it. But let assume that data is allowed. Case #1: Almost anything what counts signature over (some) header fields or whole header blocks. If Downgrade header field does not hide signature, then i18mail unaware MUA and also any MTA before upgrading agent may note that signature fails. There is S/MIME, domainkeys and so on .... Some of these are likely to be checked on border MTAs. Some of these failures are likely cause mail to be rejected or moved to spam folder. Even when signature is on one header field, it is unlikely that it includes utf-8 characters and therefore is is not moved to Downgrade: -header (and that way hiden.) Encapsulation to application/utf8smtp prevent signature verification before it is undone, because signature is not seen when message (or message part) is downgraded. And there is problems even when mail is upgraded. Succeed of signature requires that upgrade is able exactly return correct header fields with same order and even whitespaces. Also extra headers must not be added. - If syntax of some header field is known, it is converted. Therefore there was no reason for downgrading component to add Downgraded: -header field. In general from downgraded header it is not possible to return orignal header field exactly (whitespace differences and other differences which do not alter semantic.) Conversion tries just preserve semantic. That is not enough to return original header so that signature verification counts same signature. - Even when downgrading agent is added Downgraded: -header field with converted header. Upgrading process must known to remove converted header and pick data only from Downgraded: -header field. - And there may be some headers, which are not downgraded, but was originally using RFC 2231 or RFC 2047. Upgrading process may still convert them to UTF-8. That also changes signature. Case #2: I'm not sure about that case. This depends on what protocol elements is UTF-8 allowed on Content-Type -header. It is posisble to add Downgraded: header -field, but actual problem is that Content-Type must always to able to be converted also. If there is UTF-8 on protocol elements of Content-Type, for which there is no conversion available (ie. RFC 2231 or RFC 2047 do not ably), it may be that that converted Content-Type header field can not be formed. that does not prevent putting mime header block and mime subpart inside of application/utf8smtp. Of course there is problem when put some message or mime subpart inside of application/utf8smtp. I addressed that only partially on one my other article. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 14:26:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY5GZ-0004ZG-Kt; Thu, 12 Oct 2006 14:26:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY5GY-0004YW-0B for ima@ietf.org; Thu, 12 Oct 2006 14:26:46 -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 1GY5GW-0007fc-H1 for ima@ietf.org; Thu, 12 Oct 2006 14:26:45 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GY4t0-0001oi-HP for ima@ietf.org; Thu, 12 Oct 2006 20:02:27 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 20:02:26 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 20:02:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) Date: 12 Oct 2006 20:44:07 +0300 Lines: 89 Message-ID: <5du029juoo.fsf_-_@Hurtta06k.keh.iki.fi> References: <200610121027.k9CAR7Rj027149@siilo.fmi.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 Thu, 12 Oct 2006 11:27:07 +0100, Kari Hurtta > wrote: > > >>>> Charles Lindsey > > >> building complete message encapsulation into the protocol. Whatever one > >> can achieve, so can the other. > > > > Downgraded: header is encapsulation, but there is cases where that > > mini encapsulation do not handle, I think. > > Then please show us such a case, and we can look at it. NOTE: One soluntion is to forbid data on i18nmail if Downgraded: -header field can not handle it. But let assume that data is allowed. Case #1: Almost anything what counts signature over (some) header fields or whole header blocks. If Downgrade header field does not hide signature, then i18mail unaware MUA and also any MTA before upgrading agent may note that signature fails. There is S/MIME, domainkeys and so on .... Some of these are likely to be checked on border MTAs. Some of these failures are likely cause mail to be rejected or moved to spam folder. Even when signature is on one header field, it is unlikely that it includes utf-8 characters and therefore is is not moved to Downgrade: -header (and that way hiden.) Encapsulation to application/utf8smtp prevent signature verification before it is undone, because signature is not seen when message (or message part) is downgraded. And there is problems even when mail is upgraded. Succeed of signature requires that upgrade is able exactly return correct header fields with same order and even whitespaces. Also extra headers must not be added. - If syntax of some header field is known, it is converted. Therefore there was no reason for downgrading component to add Downgraded: -header field. In general from downgraded header it is not possible to return orignal header field exactly (whitespace differences and other differences which do not alter semantic.) Conversion tries just preserve semantic. That is not enough to return original header so that signature verification counts same signature. - Even when downgrading agent is added Downgraded: -header field with converted header. Upgrading process must known to remove converted header and pick data only from Downgraded: -header field. - And there may be some headers, which are not downgraded, but was originally using RFC 2231 or RFC 2047. Upgrading process may still convert them to UTF-8. That also changes signature. Case #2: I'm not sure about that case. This depends on what protocol elements is UTF-8 allowed on Content-Type -header. It is posisble to add Downgraded: header -field, but actual problem is that Content-Type must always to able to be converted also. If there is UTF-8 on protocol elements of Content-Type, for which there is no conversion available (ie. RFC 2231 or RFC 2047 do not ably), it may be that that converted Content-Type header field can not be formed. that does not prevent putting mime header block and mime subpart inside of application/utf8smtp. Of course there is problem when put some message or mime subpart inside of application/utf8smtp. I addressed that only partially on one my other article. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 14:27:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY5HV-0004gm-4h; Thu, 12 Oct 2006 14:27:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY5HU-0004gf-Au for ima@ietf.org; Thu, 12 Oct 2006 14:27:44 -0400 Received: from smtp2gate.fmi.fi ([193.166.223.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY5HR-0007oU-Ku for ima@ietf.org; Thu, 12 Oct 2006 14:27:44 -0400 Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@siilo.fmi.fi) by smtp2gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20041007) with ESMTP id k9CIRDE4019710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Oct 2006 21:27:13 +0300 Received: from siilo.fmi.fi by torkku.fmi.fi with ESMTP id k9CIRDgZ006482 ; Thu, 12 Oct 2006 21:27:13 +0300 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id k9CIRDAq027021 ; Thu, 12 Oct 2006 21:27:13 +0300 Received: by siilo.fmi.fi id k9CIRDxX027018; Thu, 12 Oct 2006 21:27:13 +0300 Message-Id: <200610121827.k9CIRDxX027018@siilo.fmi.fi> Subject: Re: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) In-Reply-To: To: Charles Lindsey Date: Thu, 12 Oct 2006 21:27:13 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123d (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 20061012/17914/01 X-Filter: smtp2gate: ID 17913/01, 1 parts scanned for known viruses X-Filter: torkku: ID 2559/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.2 required=5 (smtp2gate: ID 17913/01) report=AWL,BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Kari Hurtta , 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 ( I think that my answer get lost, so I try recreate it. I'm sorry if this is duplicate. ) >>> Charles Lindsey > On Thu, 12 Oct 2006 11:27:07 +0100, Kari Hurtta > wrote: > > >>>> Charles Lindsey > > >> building complete message encapsulation into the protocol. Whatever one > >> can achieve, so can the other. > > > > Downgraded: header is encapsulation, but there is cases where that > > mini encapsulation do not handle, I think. > > Then please show us such a case, and we can look at it. NOTE: There is always(?) option to to forbid data which Downgraded: header field can not handle. Let's assume that is is not forbidded. Case #1: Almost any case where signature is calculated over header fields or over whole header block. There is S/MIME, domainkeys and so on ... If recipeint MUA is not i18nmail aware it will calculate signature over downgraded header. That will cause failure of signature. Also signature will fail if some MTA calculates it before mail is upgraded. It is likely that some border MTAs calculates signatures. This may cause mail to be rejected or moved to spam folder. Encapsulation with application/utf8smtp do not fail, because signature is not seen before encapsulation is undone. Even when signature is on header field, it normally do not include utf-8 characters, so downgarding routine is not reason move it to Downgraded: -header field and that way hide signature. There is also problems after mail is upgraded: - If downgarding routine knows synta of header filed, it have no reason to add Downgraded: header field. Instead header field is just converted. It is not possibile recover original header field from converted header field so that signature calculation succeed. Conversion tries preserve semantic of data, it does not preserve other aspects of data which affect signature (such as whitespace differences for example.) - Even when downgarding routine adds Downgraded: header field with converted header field, upgrading routine must the known remove converted header field and pick data only from Downgraded: -header field. - There may be some header field which are not converted at all. However upgrading routine may able to upgrade them to use UTF-8. That also may cause signature to fail. Case #2: I'm not sure about that. That depends what protocol elements are allowed to include UTF-8 on Content-type header field. It is possible to put Content-type header field to Downgraded: header field. But problem is that there must be also converted Content-Type header field. If there is UTF-8 data on elements where conversion is not available ( for example RFC 2231 or 2047 do not apply), then it maybe is not possible to generate converted Content-Type header field. However it is possible to put whole mime header block and that mime part inside of application/utf8smtp encapsulation. Of course there is problem that when to use application/utf8smtp for encapsulation. That I have only partially addressed on some other my mail or article. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 15:50:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY6ZU-0006XW-4b; Thu, 12 Oct 2006 15:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY6ZA-0005u3-5J; Thu, 12 Oct 2006 15:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY6Z8-0005v8-Hq; Thu, 12 Oct 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 7F75826E27; Thu, 12 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GY6Z8-0003hZ-By; Thu, 12 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 12 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-framework-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Overview and Framework for Internationalized Email Author(s) : J. Klensin, Y. Ko Filename : draft-ietf-eai-framework-02.txt Pages : 20 Date : 2006-10-12 Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-framework-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-framework-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-12144002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-12144002.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Thu Oct 12 17:42:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY8Jo-0000jM-1b; Thu, 12 Oct 2006 17:42:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY8Jm-0000iy-Sd for ima@ietf.org; Thu, 12 Oct 2006 17:42:18 -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 1GY8Jj-00085r-AQ for ima@ietf.org; Thu, 12 Oct 2006 17:42:18 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GY7kx-0005N9-BE for ima@ietf.org; Thu, 12 Oct 2006 23:06:19 +0200 Received: from pd9fba8ae.dip0.t-ipconnect.de ([217.251.168.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 23:06:19 +0200 Received: from nobody by pd9fba8ae.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Oct 2006 23:06:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] text for eai-framework re: 2047+S/MIME Date: Thu, 12 Oct 2006 22:50:12 +0200 Organization: Lines: 20 Message-ID: <452EAA84.21A2@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8ae.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: > to be awkward, I included some utf-8 in the Content-Type header of > the text/plain. I am sure no existsting signature program would do > such a stupid thing, but it is legal Raw UTF-8 in a MIME part Content-* header field, is that necessary ? >& Content-Type: message/rfc822 (utf8-comment) charset=iso-8859-1; >& name="utf8-name" >& >& Header-Type: UTF8SMTP >& From: } which might or might not have utf-8 >& To: } in them Wait a moment, message/rfc822 has no charset, and message/rfc822 is by definition no message/utf8smtp, or do I miss something here ? Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 18:32:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY96p-0006Tx-RL; Thu, 12 Oct 2006 18:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY96o-0006Sn-8U for ima@ietf.org; Thu, 12 Oct 2006 18:32:58 -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 1GY96m-0001Bb-Mu for ima@ietf.org; Thu, 12 Oct 2006 18:32:58 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GY8ub-0001XR-0Z for ima@ietf.org; Fri, 13 Oct 2006 00:20:21 +0200 Received: from pd9fba8ae.dip0.t-ipconnect.de ([217.251.168.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 00:20:21 +0200 Received: from nobody by pd9fba8ae.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 00:20:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Thu, 12 Oct 2006 23:53:23 +0200 Organization: Lines: 17 Message-ID: <452EB953.3C20@xyzzy.claranet.de> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <452D80B1.2190@xyzzy.claranet.de> <452DFD75.5040201@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: pd9fba8ae.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [EAI] Re: Structured vs unstructured 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: > A rather surprising result of some analysis we did in the work on the > MIXER specification was that in order for an implementation to be > robust, it had to treat all unknown header fields as *structured* header > fields, not unstructured ones. What does that mean if you don't know the structure ? Some lexical analysis as defined in 822, comments, white space, etc. ? With gateways one hard part is to get the terminology right, if things appear to be similar on both sides. I'll never forget the day when I finally understood that a Usenet Message-ID is the essence, and a Path only secondary - exactly the opposite of Fido. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 19:07:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY9e2-0004z9-5d; Thu, 12 Oct 2006 19:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY9dO-0004d0-0I for ima@ietf.org; Thu, 12 Oct 2006 19:06:38 -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 1GY9OF-0004k4-Io for ima@ietf.org; Thu, 12 Oct 2006 18:51:00 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GY9Ba-0008JS-6D for ima@ietf.org; Fri, 13 Oct 2006 00:37:55 +0200 Received: from pd9fba8ae.dip0.t-ipconnect.de ([217.251.168.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 00:37:54 +0200 Received: from nobody by pd9fba8ae.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 00:37:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 13 Oct 2006 00:22:15 +0200 Organization: Lines: 39 Message-ID: <452EC017.5E92@xyzzy.claranet.de> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <452D80B1.2190@xyzzy.claranet.de> <5dy7rmgl5h.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8ae.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [EAI] Re: Encapsulation is required (for some headers) 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: > ( I think that I'm lost. ) Sorry, I try it again. One important scenario is S -> D -> U -> R, sender S, downgrading gateway D, upgrading gateway U, receiver R. What D and U exactly do, how they encode and decode header fields, is irrelevant for R as long as it gets anything as sent by S. For S it's more interesting if the downgraded message is bounced by a hop between D and U, but S knows what it sent, it's not critical. Another scenario is S -> D -> L, where L is a "legacy" system, any agent that doesn't support utf8smtp. Let's say L supports a structured header field Y, a Jabber-ID or an Archived-At or similar. And let's assume that D does NOT know this structure. Then we have three cases: S didn't use Y => no issue S used Y as specified (ASCII+2231) => no issue, D won't touch it S used the Y structure with UTF-8 => D doesn't know it and encodes or encapsulates it as good as it can. If that procedure "destroys" (from L's POV) the structure of Y it's again no issue, because L cannot handle the UTF-8 header field Y as sent by S. What D does is irrelevant from L's POV. L is only interested in the "known" downgraded header fields (From, To, CC, etc.), that's covered in the downgrade draft. It's not the same situation as for R in the first scenario, where R of course wants to get the original header field Y as sent by S. In the 1st scenario it's also okay if D doesn't know the structure of Y and encodes it beyond recognition. Only U needs to know how to decode it, structured or unstructured. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 19:25:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY9vh-0000Jw-KP; Thu, 12 Oct 2006 19:25:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY9vd-0000BM-87 for ima@ietf.org; Thu, 12 Oct 2006 19:25:29 -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 1GY9oO-0003Ja-La for ima@ietf.org; Thu, 12 Oct 2006 19:18:02 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GY9oO-000Ky8-2Z; Thu, 12 Oct 2006 19:18:00 -0400 Date: Thu, 12 Oct 2006 19:17:59 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] text for eai-framework re: 2047+S/MIME Message-ID: <0513BBE71C7E446C005B04B0@p3.JCK.COM> In-Reply-To: <452EAA84.21A2@xyzzy.claranet.de> References: <452EAA84.21A2@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (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: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 12 October, 2006 22:50 +0200 Frank Ellermann wrote: > Charles Lindsey wrote: > >> to be awkward, I included some utf-8 in the Content-Type >> header of the text/plain. I am sure no existsting signature >> program would do such a stupid thing, but it is legal > > Raw UTF-8 in a MIME part Content-* header field, is that > necessary ? It is not necessary. 2822, 4288, and 4829 and their predecessors do not permit it, at least intentionally, and nothing in the proposed EAI specs permit it either. One might infer that, with i18nemail, a filename that uses non-ASCII characters should be permitted, but I think it would require a separate proposal, one carefully enough written to cover operating systems in which non-ASCII file names are in some charset and coding other than Unicode expressed in UTF-8. If the UTF-8 headers spec permits UTF-8 comments in embedded MIME Content-type and similar headers, we might need to review that issue for just this reason. They certainly are not necessary to support i18nemail address transport and then do introduce extra complications and edge cases. >> & Content-Type: message/rfc822 (utf8-comment) >> charset=iso-8859-1; & name="utf8-name" >> & >> & Header-Type: UTF8SMTP >> & From: } which might or might not have utf-8 >> & To: } in them > > Wait a moment, message/rfc822 has no charset, and > message/rfc822 is by definition no message/utf8smtp, or do I > miss something here ? No, you don't, at least as far as I can tell. And the message/utf8smtp construct, which I wish we would stop discussing as if it were real without any sort of I-D on the table that describes its structure, should not need (or permit) a charset either, since any non-ASCII characters should (actually MUST) be in UTF-8 by definition. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 22:06:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYCR6-0003vh-5i; Thu, 12 Oct 2006 22:06:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYCR4-0003vZ-Lr for ima@ietf.org; Thu, 12 Oct 2006 22:06:06 -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 1GYCR1-0003fU-Lm for ima@ietf.org; Thu, 12 Oct 2006 22:06:06 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYCP3-0003aR-Ew for ima@ietf.org; Fri, 13 Oct 2006 04:04:02 +0200 Received: from pd9fba8db.dip0.t-ipconnect.de ([217.251.168.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 04:04:01 +0200 Received: from nobody by pd9fba8db.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 04:04:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] text for eai-framework re: 2047+S/MIME Date: Fri, 13 Oct 2006 03:44:17 +0200 Organization: Lines: 45 Message-ID: <452EEF71.172F@xyzzy.claranet.de> References: <452EAA84.21A2@xyzzy.claranet.de> <0513BBE71C7E446C005B04B0@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8db.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > the message/utf8smtp construct, which I wish we would stop > discussing as if it were real without any sort of I-D on the > table that describes its structure, should not need (or permit) > a charset either Yes, message/* and multipart/* have no charset. And my naive definition of message/utf8smtp is "same as message/rfc822, but adding UTF8-xtra-char as specified in the utf8headers I-D". Maybe that's far too much, adding UTF8-xtra-char only for the of the in is the minimum, i.e. in the utf8headers I-D. For the RHS I pass, that's your and Martin's territory. > non-ASCII characters should (actually MUST) be in UTF-8 by > definition. Yes, but 2047 / 2231 encodings still work for (Subject etc., anything unstructured) and (comments), it's not strictly required to augment these conctructs by raw UTF-8. Apparently is only used in , and it's not strictly necessary to allow backslashes before UTF8-xtra-char. A is used in , where doesn't allow UTF8-xtra-char, that could be inconsistent, better leave as is, no UTF8-xtra-char. The last case is used by . For most fields the complete can be replaced by a 2047- encoded word. For a minimal solution only one needs UTF8-xtra-char, the case of . Allowing UTF8-xtra-char in but not + is pointless, you either get a maximal solution as in the I-D, or a minimal solution affecting only . And message/utf8smtp is my name for the resulting MIME message. IMO it's no message/rfc822 and needs its own message subtype. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 12 23:54:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYE8A-0004wV-Pu; Thu, 12 Oct 2006 23:54:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYE89-0004wQ-Li for ima@ietf.org; Thu, 12 Oct 2006 23:54: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 1GYE88-0008Uj-CS for ima@ietf.org; Thu, 12 Oct 2006 23:54:41 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYE84-00063l-9e for ima@ietf.org; Fri, 13 Oct 2006 05:54:36 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 05:54:36 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 05:54:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] text for eai-framework re: 2047+S/MIME Date: 13 Oct 2006 06:54:24 +0300 Lines: 23 Message-ID: <5dk634x43z.fsf@Hurtta06k.keh.iki.fi> References: <452EAA84.21A2@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima > Wait a moment, message/rfc822 has no charset, and message/rfc822 > is by definition no message/utf8smtp, or do I miss something here ? Uhh. Message/rfc822 mime-type referes also to any successor of it. RFC 2822 did not introduced message/rfc2822 mime-type. I think that message/rfc822 can be utf8smtp / i18nmail message. / Kari Hurtta RFC 2046 quote: 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. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 13 00:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYEIa-00034T-9W; Fri, 13 Oct 2006 00:05:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYEIY-0002yt-TW for ima@ietf.org; Fri, 13 Oct 2006 00:05: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 1GYEIX-0001bU-Fm for ima@ietf.org; Fri, 13 Oct 2006 00:05:26 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYEIO-0007Qu-PK for ima@ietf.org; Fri, 13 Oct 2006 06:05:16 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 06:05:16 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 06:05:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Re: Encapsulation is required (for some headers) Date: 13 Oct 2006 07:05:08 +0300 Lines: 53 Message-ID: <5dac40x3m3.fsf@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <452D80B1.2190@xyzzy.claranet.de> <5dy7rmgl5h.fsf@Hurtta06k.keh.iki.fi> <452EC017.5E92@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Kari Hurtta wrote: > > > ( I think that I'm lost. ) > > Sorry, I try it again. One important scenario is S -> D -> U -> R, > sender S, downgrading gateway D, upgrading gateway U, receiver R. > > What D and U exactly do, how they encode and decode header fields, > is irrelevant for R as long as it gets anything as sent by S. > > For S it's more interesting if the downgraded message is bounced by > a hop between D and U, but S knows what it sent, it's not critical. > > Another scenario is S -> D -> L, where L is a "legacy" system, any > agent that doesn't support utf8smtp. > > Let's say L supports a structured header field Y, a Jabber-ID or an > Archived-At or similar. And let's assume that D does NOT know this > structure. Then we have three cases: > > S didn't use Y => no issue > S used Y as specified (ASCII+2231) => no issue, D won't touch it > S used the Y structure with UTF-8 => D doesn't know it and encodes > or encapsulates it as good as it can. If that procedure "destroys" > (from L's POV) the structure of Y it's again no issue, because L > cannot handle the UTF-8 header field Y as sent by S. What D does > is irrelevant from L's POV. S -> D -> L header field Y is maybe some protocol action what sender may want. sender should have realized that it must not use utf-8 on that header field Y. However sender prefers that it get's bounce on that case so that error is fixed. > L is only interested in the "known" downgraded header fields (From, > To, CC, etc.), that's covered in the downgrade draft. It's not the > same situation as for R in the first scenario, where R of course > wants to get the original header field Y as sent by S. > > In the 1st scenario it's also okay if D doesn't know the structure > of Y and encodes it beyond recognition. Only U needs to know how > to decode it, structured or unstructured. > Frank Thank you. Now I see what you mean. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 13 00:13:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYEPv-0000Gv-D5; Fri, 13 Oct 2006 00:13:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYEPu-0000Ga-2r for ima@ietf.org; Fri, 13 Oct 2006 00:13:02 -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 1GYEPr-0002m7-OO for ima@ietf.org; Fri, 13 Oct 2006 00:13:02 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYEPd-0008Pc-QP for ima@ietf.org; Fri, 13 Oct 2006 06:12:45 +0200 Received: from pd9fba8db.dip0.t-ipconnect.de ([217.251.168.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 06:12:45 +0200 Received: from nobody by pd9fba8db.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 06:12:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] I-D ACTION:draft-ietf-eai-framework-02.txt Date: Fri, 13 Oct 2006 06:09:07 +0200 Organization: Lines: 34 Message-ID: <452F1163.326E@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8db.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Internet-Drafts@ietf.org wrote: > http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-02.txt 1.3: | it is not possible to tell from the address that an email sender or | recipient is an i18mail user. s/i18mail/ASCII/ If it's an ASCII address the user might also have non-ASCII addresses, and is an i18mail user. And if it's a non-ASCII address the user is obviously an i18mail user. An "ASCII user" isn't obvious. 4.1: /ditto for POP.???/ Should that be /ditto for [I18Nemail-pop]/ ? 13.2: s/[DKIM-Charter]/[draft-ietf-dkim-base] + [draft-ietf-dkim-overview]/ The DKIM-threats, SSP-requirements, and SSP-proper texts are not directly affected (unless SSP tries "per user policies", unclear). 7: For chapter 7 I propose to add a new subsection about any "local part transformation" schemes like SES, SRS, BATV, or SPF per-user-policies (or other uses of its %{l} macro as domain label, %{l} = "local part") For SPF I'm almost sure that it should work, its is not specified, it can contain any octet as found in %{l}. Almost, the test suite folks found a case foo...bar (with adjacent dots), that's putting it mildly "underspecified", but of course no EAI issue. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 13 01:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYFNO-0002PK-QB; Fri, 13 Oct 2006 01:14:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYFNM-0002LQ-Rc for ima@ietf.org; Fri, 13 Oct 2006 01:14:28 -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 1GYFNL-0001oD-Dj for ima@ietf.org; Fri, 13 Oct 2006 01:14:28 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYFN8-0008Lo-I7 for ima@ietf.org; Fri, 13 Oct 2006 07:14:14 +0200 Received: from pd9fba8db.dip0.t-ipconnect.de ([217.251.168.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 07:14:14 +0200 Received: from nobody by pd9fba8db.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 07:14:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: message/rfc822 (was: [EAI] text for eai-framework re: 2047+S/MIME) Date: Fri, 13 Oct 2006 07:11:20 +0200 Organization: Lines: 41 Message-ID: <452F1FF8.64E5@xyzzy.claranet.de> References: <452EAA84.21A2@xyzzy.claranet.de> <5dk634x43z.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8db.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > I think that message/rfc822 can be utf8smtp / i18nmail message. > RFC 2046 quote: > 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. Other quotes (same source) | The "rfc822" subtype is used when the encapsulated content is itself | an RFC 822 message. | A media type of "message/rfc822" indicates that the body contains an | encapsulated message, with the syntax of an RFC 822 message. | No encoding other than "7bit", "8bit", or "binary" is permitted for | the body of a "message/rfc822" entity. The message header fields are | always US-ASCII in any case ^^^^^^^^^^^^^^^^^^^^^^^^^^^ [RFC 2822, "internet message format", 2.1] | A message that is conformant with this standard is comprised of | characters with values in the range 1 through 127 and interpreted as | US-ASCII characters [ASCII]. The "isn't restricted to material in strict conformance" note in 2046 offers some wiggle room for message/rfc822, and it claims to encompass message/news (where an 8bit CTE is okay), but even in netnews a header is pure US-ASCII: | The character set for header fields is US-ASCII. Where the use of | non-ASCII characters is required, they MUST be encoded using the | MIME mechanisms defined in [RFC2047] and [RFC2231]. The draft-ietf-usefor-usefor-10 last call ends in a few hours... Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 13 01:31:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYFdg-0003fN-Qz; Fri, 13 Oct 2006 01:31:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYFde-0003er-Sv for ima@ietf.org; Fri, 13 Oct 2006 01:31:18 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GYFdZ-0006YC-70 for ima@ietf.org; Fri, 13 Oct 2006 01:31:18 -0400 Received: (snipe 30488 invoked by uid 0); 13 Oct 2006 14:32:05 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.021054 secs); Received: from unknown (HELO ?192.168.10.175?) (Z???own@210.107.250.150) by unknown with SMTP; 13 Oct 2006 14:32:05 +0900 X-RCPTTO: nobody@xyzzy.claranet.de, ima@ietf.org Message-ID: <452F2494.5010807@icu.ac.kr> Date: Fri, 13 Oct 2006 14:31:00 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] I-D ACTION:draft-ietf-eai-framework-02.txt References: <452F1163.326E@xyzzy.claranet.de> In-Reply-To: <452F1163.326E@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: > Internet-Drafts@ietf.org wrote: > >> http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-02.txt > > 1.3: > | it is not possible to tell from the address that an email sender or > | recipient is an i18mail user. > > s/i18mail/ASCII/ If it's an ASCII address the user might also have > non-ASCII addresses, and is an i18mail user. And if it's a non-ASCII > address the user is obviously an i18mail user. An "ASCII user" isn't > obvious. Let me see 2x2 matrix. (1) An i18mail user using non-ASCII address is obviously identified. (2) An i18mail user using ASCII address is NOT obviously identified. (3) An ASCII user using non-ASCII address is just error somewhere. (4) An ASCII user using ASCII address is NOT obviously identified. Yes. Problem arises when a given address is all ASCII. In that case, we cannot tell whether the user is i18mail or ASCII user. My proposal is that; ... it is not possible to tell from an ASCII address that an email sender or recipient is an i18mail user or an ASCII user. Too redundant? > > 4.1: > /ditto for POP.???/ Should that be /ditto for [I18Nemail-pop]/ ? > > 13.2: > s/[DKIM-Charter]/[draft-ietf-dkim-base] + [draft-ietf-dkim-overview]/ > > The DKIM-threats, SSP-requirements, and SSP-proper texts are not > directly affected (unless SSP tries "per user policies", unclear). > > 7: > For chapter 7 I propose to add a new subsection about any "local part > transformation" schemes like SES, SRS, BATV, or SPF per-user-policies > (or other uses of its %{l} macro as domain label, %{l} = "local part") > > For SPF I'm almost sure that it should work, its is not > specified, it can contain any octet as found in %{l}. Almost, the > test suite folks found a case foo...bar (with adjacent dots), that's > putting it mildly "underspecified", but of course no EAI issue. > > 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 Fri Oct 13 04:13:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYIAQ-00012b-Vy; Fri, 13 Oct 2006 04:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYIAQ-00011x-DE for ima@ietf.org; Fri, 13 Oct 2006 04:13:18 -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 1GYIAB-00005g-Mm for ima@ietf.org; Fri, 13 Oct 2006 04:13:04 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYIA3-00088K-Ez for ima@ietf.org; Fri, 13 Oct 2006 10:12:55 +0200 Received: from pd9fba926.dip0.t-ipconnect.de ([217.251.169.38]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 10:12:55 +0200 Received: from nobody by pd9fba926.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 10:12:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] I-D ACTION:draft-ietf-eai-framework-02.txt Date: Fri, 13 Oct 2006 10:11:54 +0200 Organization: Lines: 11 Message-ID: <452F4A4A.646D@xyzzy.claranet.de> References: <452F1163.326E@xyzzy.claranet.de> <452F2494.5010807@icu.ac.kr> 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: pd9fba926.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Yangwoo Ko wrote: > ... it is not possible to tell from an ASCII address that an email > sender or recipient is an i18mail user or an ASCII user. > Too redundant? No, it's clearer and better than only s/i18mail/ASCII/. Thanks. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 13 06:59:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYKkr-0003Pr-6d; Fri, 13 Oct 2006 06:59:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYKkp-0003MZ-Or for ima@ietf.org; Fri, 13 Oct 2006 06:59: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 1GYKkl-0005IA-BJ for ima@ietf.org; Fri, 13 Oct 2006 06:59:03 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYKkU-0008Fc-QN for ima@ietf.org; Fri, 13 Oct 2006 12:58:42 +0200 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 12:58:42 +0200 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 12:58:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] text for eai-framework re: 2047+S/MIME Date: 13 Oct 2006 13:58:20 +0300 Lines: 29 Message-ID: <5dpscwwkhf.fsf@leija.fmi.fi> References: <452EAA84.21A2@xyzzy.claranet.de> <0513BBE71C7E446C005B04B0@p3.JCK.COM> <452EEF71.172F@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes gmane.ietf.ima: > Yes, message/* and multipart/* have no charset. And my naive > definition of message/utf8smtp is "same as message/rfc822, but > adding UTF8-xtra-char as specified in the utf8headers I-D". <...> > And message/utf8smtp is my name for the resulting MIME message. > IMO it's no message/rfc822 and needs its own message subtype. > > Frank Hmm, yes. When it turns out that message/rfc822 can not be expanded, there is need for message/utf8smtp which serves same purpose as message/rfc822. That message/utf8smtp need to be downgraded same way that i18mail on general. It is not encapsulation. Downgrading have some details. In practise it can not be allowed exists outside of i18mail environment (that means that 8BITMIME is not enough.) So that needs draft. That is not critical, but if it is not written, message/rfc822 will be used for that purpose even when it is not allowed. (IMHO using message/rfc822 for that breaks nothing. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 13 08:52:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYMWD-0004Vd-9V; Fri, 13 Oct 2006 08:52:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYMWB-0004S2-5f for ima@ietf.org; Fri, 13 Oct 2006 08:52: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 1GYMNr-0002ZA-7D for ima@ietf.org; Fri, 13 Oct 2006 08:43:31 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYMNX-0007ih-Tc for ima@ietf.org; Fri, 13 Oct 2006 14:43:08 +0200 Received: from pd9fba926.dip0.t-ipconnect.de ([217.251.169.38]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 14:43:07 +0200 Received: from nobody by pd9fba926.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 14:43:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] text for eai-framework re: 2047+S/MIME Date: Fri, 13 Oct 2006 14:41:48 +0200 Organization: Lines: 77 Message-ID: <452F898C.2C49@xyzzy.claranet.de> References: <452EAA84.21A2@xyzzy.claranet.de> <0513BBE71C7E446C005B04B0@p3.JCK.COM> <452EEF71.172F@xyzzy.claranet.de> <5dpscwwkhf.fsf@leija.fmi.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba926.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > That message/utf8smtp need to be downgraded same way that i18mail > on general. It is not encapsulation. What arrives at the downgrade-gateway is something like that: To: From: Date: Message-ID: Subject: <2231-subject> x-more-header-fields: yes MIME-Version: 1.0 Contect-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Body Because it arrived via utf8smtp it's by definition message/utf8smtp. The downgraded 8bit version would be: Received: from downgrad-in@example by downgrade-out@example with smtp for To: From: Date: Message-ID: Subject: <2231-subject> MIME-Version: 1.0 Contect-Type: message/utf8smtp Content-Transfer-Encoding: 8bit Received: from utf8smt-sender by downgrade-in@example with utf8smtp for To: From: Date: Message-ID: Subject: <2231-subject> x-more-header-fields: yes MIME-Version: 1.0 Contect-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Body The x-more-header-fields only copied to the downgraded header as far as they are clean for message/rfc822. The 2231-subject can support language tags. With a raw UTF-8 subject (and Content-language header field) it's almost identical, just use 2047 to downgrade a raw UTF-8 subject (maybe copy the Content-Language, UTF-8 comments stripped or encoded). > that needs draft. In essence the utf8headers I-D is it. The 4288 registration would violate a "should" (lower case) in 2046 5,2.4. > That is not critical, but if it is not written, message/rfc822 > will be used for that purpose even when it is not allowed. A new subsection 9.1 in "utf8headers" with the RFC 4288 registration template. Review by the ietf-types list. Consensus here to go that way. IESG appoval for the I-D. > (IMHO using message/rfc822 for that breaks nothing. ) Legacy applications expecting that a message/rfc822 has an US-ASCII header could include virus checkers etc., I've no idea what they do if they're confronted with raw non-ASCII in a wannabe message/rfc822. It could break RFC 4155 application/mbox; format=default (I'm not sure about this, see appendix A). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 13 09:40:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYNH0-0002RT-Ei; Fri, 13 Oct 2006 09:40:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYNGz-0002RO-Ci for ima@ietf.org; Fri, 13 Oct 2006 09:40:25 -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 1GYNGq-0003ye-IQ for ima@ietf.org; Fri, 13 Oct 2006 09:40:25 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYNGZ-0005fm-CL for ima@ietf.org; Fri, 13 Oct 2006 15:39:59 +0200 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 15:39:59 +0200 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 15:39:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: hurtta+gmane@siilo.fmi.fi Subject: Re: [EAI] text for eai-framework re: 2047+S/MIME Date: 13 Oct 2006 16:39:42 +0300 Lines: 122 Message-ID: <5dslhswd0h.fsf@leija.fmi.fi> References: <452EAA84.21A2@xyzzy.claranet.de> <0513BBE71C7E446C005B04B0@p3.JCK.COM> <452EEF71.172F@xyzzy.claranet.de> <5dpscwwkhf.fsf@leija.fmi.fi> <452F898C.2C49@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 X-Spam-Score: 0.2 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Kari Hurtta wrote: > > > That message/utf8smtp need to be downgraded same way that i18mail > > on general. It is not encapsulation. > > What arrives at the downgrade-gateway is something like that: > > To: > From: > Date: > Message-ID: > Subject: <2231-subject> > x-more-header-fields: yes > MIME-Version: 1.0 > Contect-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: 8bit > > Body > > Because it arrived via utf8smtp it's by definition message/utf8smtp. > The downgraded 8bit version would be: > > Received: from downgrad-in@example by downgrade-out@example with smtp > for > To: > From: > Date: > Message-ID: > Subject: <2231-subject> > MIME-Version: 1.0 > Contect-Type: message/utf8smtp > Content-Transfer-Encoding: 8bit > > Received: from utf8smt-sender by downgrade-in@example with utf8smtp > for > To: > From: > Date: > Message-ID: > Subject: <2231-subject> > x-more-header-fields: yes > MIME-Version: 1.0 > Contect-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: 8bit > > Body > Uhh. Here you are using message/utf8smtp as encapsulation ( IMHO it will _not_ work as I stated earlier -- for encapsulation is needed something like application/utf8smtp ) I was meaning something like: MAIL FROM:<....> BODY=8BITMIME RCPT TO:<....> DATA UTF8SMTP: UTF8 From: xxx To: ccc Subject: Tässä viesti MIME-Version: 1.0 Content-Type: message/multipart=xx Content-Transfer-Encoding: 8bit --xx See attached message --xx Content-Type: message/utf8smtp Content-Transfer-Encoding: 8bit UTF8SMTP: UTF8 From: To: vvvv Contect-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit xxxxx --xx-- When this is downgraded result is something like MAIL FROM:<....> BODY=8BITMIME RCPT TO:<....> DATA UTF8SMTP: Downgraded From: xxx To: ccc Subject: {mime-encoded word encoded} MIME-Version: 1.0 Content-Type: message/multipart=xx Content-Transfer-Encoding: 8bit --xx See attached message --xx Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit UTF8SMTP: Downgraded From: support@example.com To: vvvv Contect-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit xxxxx --xx-- / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 13 14:15:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRYp-0001M5-N2; Fri, 13 Oct 2006 14:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRYp-0001LD-00 for ima@ietf.org; Fri, 13 Oct 2006 14:15:07 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYRYh-0000RF-A9 for ima@ietf.org; Fri, 13 Oct 2006 14:15:06 -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.231) id 452fd79d.101a9.84c; Fri, 13 Oct 2006 19:14:53 +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 k9DIEpDC011872; Fri, 13 Oct 2006 19:14:52 +0100 (BST) Date: Fri, 13 Oct 2006 19:14:51 +0100 To: "Kari Hurtta" , ima@ietf.org Subject: Re: encapsulation / conversion bounce (Re: [EAI] Proposal for decision, approach for downgrading in UTF8SMTP) References: <200610121027.k9CAR7Rj027149@siilo.fmi.fi> <5d1wpdla3n.fsf_-_@Hurtta06k.keh.iki.fi> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <5d1wpdla3n.fsf_-_@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Thu, 12 Oct 2006 18:25:48 +0100, Kari Hurtta wrote: > "Charles Lindsey" writes in gmane.ietf.ima: >> Then please show us such a case, and we can look at it. > > Case #1: > > Almost anything what counts signature over (some) header fields or > whole header blocks. Sure. Any scheme that includes header fields withiun a signature is going to have problems. But there are no such standardized schemes yet in existence. If, when they come, there are badly designed, they are going to fail badly on the present network, let alone on a network with UTF-8. But if they are sensibly designed, so that they are proof agains the mungings commonly encountered (and that means a good canonicalization algorithm), they should be OK. But we cannpt discuss such schemes unless we have specific examples top look at. So All I am claiming for now is that there need be no serious problems with pgp-mime and the like, since they do not sign headers (except for the particular cases I discussed with John, which we can probably get by with a little care. > And there is problems even when mail is upgraded. > > Succeed of signature requires that upgrade is able exactly return > correct header fields with same order and even whitespaces. Also > extra headers must not be added. On the contrary, those are just the sort of things that a well-desinged header signature field should be designed to work with, It can be done (because I once did it). > Case #2: > > I'm not sure about that case. This depends on what protocol elements > is UTF-8 allowed on Content-Type -header. Comments (which will be rare, but not forbidden) and s (downgraded by RFC 2231). > > It is posisble to add Downgraded: header -field, but > actual problem is that Content-Type must always to able > to be converted also. Yes, Content-Type should be one of the cases that the dwngrade document knows how to do. It may well involve providing a Downgraded header _as_well_, buts as it fom with From: To: etc. If there is UTF-8 on protocol elements > of Content-Type, for which there is no conversion available > (ie. RFC 2231 or RFC 2047 do not ably), There aren't any. -- 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 Oct 13 14:28:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRle-0001Or-2G; Fri, 13 Oct 2006 14:28:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYRlc-0001NP-Ur for ima@ietf.org; Fri, 13 Oct 2006 14:28:20 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYRlb-0002Xk-Bt for ima@ietf.org; Fri, 13 Oct 2006 14:28: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-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id 452fdac2.be58.81 for ima@ietf.org; Fri, 13 Oct 2006 19:28:18 +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 k9DISHHV012694 for ; Fri, 13 Oct 2006 19:28:17 +0100 (BST) Date: Fri, 13 Oct 2006 19:28:16 +0100 To: "ima@ietf.org" Subject: Re: [EAI] text for eai-framework re: 2047+S/MIME References: <452EAA84.21A2@xyzzy.claranet.de> <0513BBE71C7E446C005B04B0@p3.JCK.COM> 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: <0513BBE71C7E446C005B04B0@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) 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 Fri, 13 Oct 2006 00:17:59 +0100, John C Klensin wrote: > --On Thursday, 12 October, 2006 22:50 +0200 Frank Ellermann > wrote: > >> Charles Lindsey wrote: >> >>> to be awkward, I included some utf-8 in the Content-Type >>> header of the text/plain. I am sure no existsting signature >>> program would do such a stupid thing, but it is legal >> >> Raw UTF-8 in a MIME part Content-* header field, is that >> necessary ? No it is not, but it is not illegal. All it needs is a warning in the framework not to do it if pgp-mime is to be used. > > It is not necessary. 2822, 4288, and 4829 and their > predecessors do not permit it, at least intentionally, and > nothing in the proposed EAI specs permit it either. One might > infer that, with i18nemail, a filename that uses non-ASCII > characters should be permitted, but I think it would require a > separate proposal, one carefully enough written to cover > operating systems in which non-ASCII file names are in some > charset and coding other than Unicode expressed in UTF-8. No, I think our documents should allow utf-8 in s (although the only realistic case mentioned so far is filenames). I don't see why the operating system comes into it; these filenames, on the wire, will be either utf-8 os an RFC 2231 downgrading thereof. >>> & Content-Type: message/rfc822 (utf8-comment) >>> charset=iso-8859-1; & name="utf8-name" >>> & >>> & Header-Type: UTF8SMTP >>> & From: } which might or might not have utf-8 >>> & To: } in them >> >> Wait a moment, message/rfc822 has no charset, and >> message/rfc822 is by definition no message/utf8smtp, or do I >> miss something here ? In the UTF8SMTP universe, the charset in message/rfc822 objects will be extended to utf-8. But they will then need a Header-Type: UTF8SMTP (whatever), both in the message/rfc822 _and_ in the main message headers, and the downgrade document must tell you to downgrade them. > > No, you don't, at least as far as I can tell. And the > message/utf8smtp construct, which I wish we would stop > discussing as if it were real without any sort of I-D on the > table that describes its structure, should not need (or permit) > a charset either, since any non-ASCII characters should > (actually MUST) be in UTF-8 by definition. Yes, I agree. If we need to design an encapsulation mechanism for complete messages, then it will be called application/utf8smtp rather than message/utf8smtp, and its semantics will be exact;y the same as application/news-transmission - i.e. you encapsulate the whole object, ignoring its structurem and using a CTE of Q-P or Base84. That ensures it can be reconstructed exactly. But I would rather not design such a mechanism at all, if we can avoid it for now. -- 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 Oct 13 14:44:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYS0o-00031q-3F; Fri, 13 Oct 2006 14:44:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYS0n-00031l-8t for ima@ietf.org; Fri, 13 Oct 2006 14:44:01 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYS0l-0004x1-Mc for ima@ietf.org; Fri, 13 Oct 2006 14:44: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-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id 452fde6e.fd45.ae5; Fri, 13 Oct 2006 19:43: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 k9DIhvVl013654; Fri, 13 Oct 2006 19:43:58 +0100 (BST) Date: Fri, 13 Oct 2006 19:43:56 +0100 To: "Frank Ellermann" , ima@ietf.org Subject: Re: message/rfc822 (was: [EAI] text for eai-framework re: 2047+S/MIME) References: <452EAA84.21A2@xyzzy.claranet.de> <5dk634x43z.fsf@Hurtta06k.keh.iki.fi> <452F1FF8.64E5@xyzzy.claranet.de> 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: <452F1FF8.64E5@xyzzy.claranet.de> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Fri, 13 Oct 2006 06:11:20 +0100, Frank Ellermann wrote: > Other quotes (same source) > | The "rfc822" subtype is used when the encapsulated content is itself > | an RFC 822 message. Which everybody understands as now extended to RFC 2822, and which will be extended to UTF8SMTP, and which is also in process of being extended to news articles. > | No encoding other than "7bit", "8bit", or "binary" is permitted for > | the body of a "message/rfc822" entity. Whatever is the reason for that? And what if you want to send a message/rfc822 in some charset other than ASCII, and your MTA doesn't do 8BITMIME? Is this restriction observed in practice? > The message header fields are > | always US-ASCII in any case > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Which will no longer be true in the UTF8SMTP universe, so downgrading or bouncing will be required. -- 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 Oct 13 17:05:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYUDe-0000pv-CS; Fri, 13 Oct 2006 17:05:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYUDd-0000pq-30 for ima@ietf.org; Fri, 13 Oct 2006 17:05:25 -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 1GYUDX-0002mw-LP for ima@ietf.org; Fri, 13 Oct 2006 17:05:25 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYTAI-0004OB-OV for ima@ietf.org; Fri, 13 Oct 2006 21:57:54 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 21:57:54 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Oct 2006 21:57:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: message/rfc822 (was: [EAI] text for eai-framework re: 2047+S/MIME) Date: 13 Oct 2006 22:57:42 +0300 Lines: 50 Message-ID: <5dlknkrnt5.fsf@Hurtta06k.keh.iki.fi> References: <452EAA84.21A2@xyzzy.claranet.de> <5dk634x43z.fsf@Hurtta06k.keh.iki.fi> <452F1FF8.64E5@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: > > | No encoding other than "7bit", "8bit", or "binary" is permitted for > > | the body of a "message/rfc822" entity. > > Whatever is the reason for that? And what if you want to send a > message/rfc822 in some charset other than ASCII, and your MTA doesn't > do 8BITMIME? Is this restriction observed in practice? Practice seems that when MIME message is processed recursively, Content-Transfer-Encoding: -header is ignored on all other types than leaf types. This causes that following kind protocol violations often works: Content-type: multipart/mixed; boundary=XXX Content-Transfer-Enconding: quoted-printable --XXX Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Enconding: quoted-printable Some quoted-printable encoded text I'm seen these quite often. Same parsers which handles multipart that way, will also look message/rfc822 that way. After all message/rfc822 is essentially processed recursively as is multipart/* -- differences between these two classes of types are quite little. These are just my observations. Number of MIME parser codes which I have familiar is quite small. Looking Content-Transfer-Encoding: only on leaf types is quite common on them. Because only "7bit", "8bit", or "binary" are allowed on non-leaf types, parsers takes advantage of that fact. It is not restricted to using Content-Transfer-Enconding: quoted-printable for message/rfc822 but I claim that this Content-Transfer-Enconding -header will be ignored, when message is viewed :-) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 13 17:37:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYUiq-0005eA-ND; Fri, 13 Oct 2006 17:37:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYUiq-0005Wl-0q for ima@ietf.org; Fri, 13 Oct 2006 17:37:40 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYUc7-0001Md-Tn for ima@ietf.org; Fri, 13 Oct 2006 17:30:45 -0400 Received: from [10.201.0.58] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id k9DLTPAi015291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Oct 2006 14:29:27 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k9DLTPAi015291 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1160774969; bh=VFQ8jv+GJew4xH0mVdm38xgloo0=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=WhZpCqno52Go2hav z+Po2LbrEjW6A6IWBhz9qZL4gszS7pF0yypbwcoHlkAf0hHG1ATPSMueYkQTaLpN5Nf A547Xt2Phe5GIcK98mlcet/wj1wD2uVRg9dkJM/LCxdg/KUI53xOw1jB8jN0uZiE80Q 7aXXjAafGj14j3dlrsjVo= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k9DLTPAi015291 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=Vk5fWNpoIDlLqXYMXSKpadoVoxPpejY+J9/lgEhu8Hc0+czmaBIK34GpTCOLwF3c8 3suQshPmb28hA6l/jug5olXuYiFSPGX83Z6CIaeuSVtmMB/Sfigq8S/5JSEGs0dEhDU mC7lWPmZVLhzN+wITTYn1drc/nhNtud8H8nmEYQ= Date: Fri, 13 Oct 2006 15:29:22 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Charles Lindsey Subject: Re: message/rfc822 (was: [EAI] text for eai-framework re: 2047+S/MIME) In-Reply-To: Message-ID: References: <452EAA84.21A2@xyzzy.claranet.de> <5dk634x43z.fsf@Hurtta06k.keh.iki.fi> <452F1FF8.64E5@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 13 Oct 2006, Charles Lindsey wrote: > On Fri, 13 Oct 2006 06:11:20 +0100, Frank Ellermann > wrote: ... >> | No encoding other than "7bit", "8bit", or "binary" is permitted for >> | the body of a "message/rfc822" entity. > > Whatever is the reason for that? RFC 2045, page 17, final paragraph: NOTE ON ENCODING RESTRICTIONS: Though the prohibition against using content-transfer-encodings on composite body data may seem overly restrictive, it is necessary to prevent nested encodings, in which data are passed through an encoding algorithm multiple times, and must be decoded multiple times in order to be properly viewed. Nested encodings add considerable complexity to user agents: Aside from the obvious efficiency problems with such multiple encodings, they can obscure the basic structure of a message. In particular, they can imply that several decoding operations are necessary simply to find out what types of bodies a message contains. Banning nested encodings may complicate the job of certain mail gateways, but this seems less of a problem than the effect of nested encodings on user agents. > And what if you want to send a message/rfc822 in some charset other than > ASCII, and your MTA doesn't do 8BITMIME? The body of the message/rfc822 can have its own content-transfer-encoding, which is set by that header field in the header of the message/rfc822 part itself (as opposed to the MIME header that wraps the message/rfc822 itself). For an example, please see RFC 2049, Appendix A ("A Complex Multipart Example"). > Is this restriction observed in practice? Yes. For example, the IMAP servers I know of won't do any CTE decoding of the header of message/rfc822 part when performing searches and would not treat a header field with the name "Content-T=79pe" as giving the content-type of the nested body part. Philip Guenther _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 14 03:17:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYdlX-00047s-3S; Sat, 14 Oct 2006 03:17:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYdlV-00047m-Ij for ima@ietf.org; Sat, 14 Oct 2006 03:17:01 -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 1GYdlU-000140-32 for ima@ietf.org; Sat, 14 Oct 2006 03:17:01 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYdlR-0006hP-QK for ima@ietf.org; Sat, 14 Oct 2006 09:16:57 +0200 Received: from pd9fbadc0.dip0.t-ipconnect.de ([217.251.173.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 09:16:57 +0200 Received: from nobody by pd9fbadc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 09:16:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] text for eai-framework re: 2047+S/MIME Date: Sat, 14 Oct 2006 09:07:54 +0200 Organization: Lines: 141 Message-ID: <45308CCA.5222@xyzzy.claranet.de> References: <452EAA84.21A2@xyzzy.claranet.de> <0513BBE71C7E446C005B04B0@p3.JCK.COM> <452EEF71.172F@xyzzy.claranet.de> <5dpscwwkhf.fsf@leija.fmi.fi> <452F898C.2C49@xyzzy.claranet.de> <5dslhswd0h.fsf@leija.fmi.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 hurtta+gmane@siilo.fmi.fi wrote: > Here you are using message/utf8smtp as encapsulation Yes, the proposed "UTF8SMTP" header field is IMO not good enough to manage this. It labels the message _within_ its header, a bit like the meta-content-type element for HTML documents. Or like the "guess which charset I'm in" XML-game. With message/TBD (something different from message/rfc822) it's possible to label it also outside of the message (no guesswork). It's mostly relevant for MIME parts, but it could be also used for files (with filesystems supporting MIME types, or mapped to an extension, *.eml for rfc822, *.uml for utf8smtp, or similar). > IMHO it will _not_ work as I stated earlier -- for > encapsulation is needed something like application/utf8smtp A message/TBD 8bit won't work with a 7bit-MTA at the next hop, but it's okay for an 8BITMIME-MTA. For 8bit to 7bit RFC 1652 apparently says that this is left as an exercise for gateway operators. If you have 8TO7 (8bit to 7bit) and U2D8 (utf8smtp downgraded with encapsulated message/TBD 8bit), then 8TO7( U2D8( x )) does the trick. On the far end of this time travel thru 7bit-land a simple gateway could undo 8TO7 resulting in a message/TBD again, and an upgrade gateway could undo both 8TO7 and U2D8. With some traps and pitfalls like trace header fields added on the downgraded route. A radical approach would be to remove them: How the downgrade and the upgrade gateways communicate, via avian carrier, Fido, xmpp, mms, news, multihop 7bit SMTP, or what else, is their private business. =46rom the POV of the "utf8smtp universe" anything else is just "other-land", nobody cares what it is as long as it's no black hole. That's the responsibility of the downgrade gateway, it is free to reject the mail if it doesn't like this. Same idea as chapter 3.2 in RFC 821 (real SPF fans know this by heart :-) > I was meaning something like: [...truncated....] > UTF8SMTP: UTF8 [...] > Content-Type: message/multipart=3Dxx > Content-Transfer-Encoding: 8bit > > --xx > > See attached message > > --xx > Content-Type: message/utf8smtp > Content-Transfer-Encoding: 8bit > > UTF8SMTP: UTF8 > From: [...] Okay, that's the input. Why so complex with a message/utf8smtp within "multipart/mixed; boundary=3Dxx" ? I guess you didn't want "message/multipart=3Dxx", and with my interpretation your input is in esssence the same as: ~~~ cut ~~~ MAIL FROM:<....> BODY=3D8BITMIME RCPT TO:<....> DATA UTF8SMTP: UTF8 From: To: vvvv Subject: T=E4ss=E4 viesti MIME-Version: 1.0 Contect-Type: text/plain; charset=3Dutf-8 Content-Transfer-Encoding: 8bit xxxxx ~~~ end ~~~ > When this is downgraded result is something like [...truncated...] = > UTF8SMTP: Downgraded [...] > Content-Type: message/multipart=3Dxx > Content-Transfer-Encoding: 8bit > > --xx > > See attached message > > --xx > Content-Type: message/rfc822 > Content-Transfer-Encoding: 8bit > > UTF8SMTP: Downgraded > From: support@example.com > To: vvvv > Contect-Type: text/plain; charset=3Dutf-8 > Content-Transfer-Encoding: 8bit > > xxxxx > > --xx-- You've apparently lost all info necessary to upgrade it again. With CTE 8bit it's clear that you're talking with an 8BITMIME MTA, and for that why not simply send this: ~~~ cut ~~~ MAIL FROM:<....> BODY=3D8BITMIME RCPT TO:<....> DATA UTF8SMTP: Downgraded From: support@example.com To: vvvv Subject: =3D?latin-1?Q?T=3DE4ss=3DE4_viesti?=3D MIME-Version: 1.0 Contect-Type: message/utf8smtp Content-Transfer-Encoding: 8bit UTF8SMTP: UTF8 From: To: vvvv Subject: T=E4ss=E4 viesti MIME-Version: 1.0 Contect-Type: text/plain; charset=3Dutf-8 Content-Transfer-Encoding: 8bit xxxxx ~~~ end ~~~ For my variant the "UTF8SMTP: UTF8" header field in a top-level header is merely a "please downgrade if you must / can" indicator. Similarly "UTF8SMTP: downgraded" is "please upgrade if you can", the actual process is a no-brainer over an 8BITMIME route. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 14 04:11:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYebi-0003GU-E9; Sat, 14 Oct 2006 04:10:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYebh-0003GO-IV for ima@ietf.org; Sat, 14 Oct 2006 04:10:57 -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 1GYebg-0007np-8M for ima@ietf.org; Sat, 14 Oct 2006 04:10:57 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYebT-000604-7t for ima@ietf.org; Sat, 14 Oct 2006 10:10:43 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 10:10:43 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 10:10:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Sendmail message/TBD handling (Re: [EAI] text for eai-framework re: 2047+S/MIME) Date: 14 Oct 2006 11:10:27 +0300 Lines: 28 Message-ID: <5dpscvtj0s.fsf_-_@Hurtta06k.keh.iki.fi> References: <452EAA84.21A2@xyzzy.claranet.de> <0513BBE71C7E446C005B04B0@p3.JCK.COM> <452EEF71.172F@xyzzy.claranet.de> <5dpscwwkhf.fsf@leija.fmi.fi> <452F898C.2C49@xyzzy.claranet.de> <5dslhswd0h.fsf@leija.fmi.fi> <45308CCA.5222@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Frank Ellermann writes in gmane.ietf.ima: > hurtta+gmane@siilo.fmi.fi wrote: > > > IMHO it will _not_ work as I stated earlier -- for > > encapsulation is needed something like application/utf8smtp > > A message/TBD 8bit won't work with a 7bit-MTA at the next hop, > but it's okay for an 8BITMIME-MTA. For 8bit to 7bit RFC 1652 > apparently says that this is left as an exercise for gateway > operators. Yes, but in practise there is problems. Sendmail will strip message/TBD to 7-bit if next host do not announce 8BITMIME. ( I have already mentioned that. ) That hapens with sendmail 8.7 (1995/09/16) or any newer version. (Yes. I'm perhaps somewhat quilty about that. (*) ) / Kari Hurtta (*) Well, I suggested that mail should be bounced, but it is not implemented. However, I may have some difficultions to found my over 10 year old mail archives... So on some details my memory may fail. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 14 04:13:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYeeT-0004pA-Hu; Sat, 14 Oct 2006 04:13:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYeeT-0004nW-0U for ima@ietf.org; Sat, 14 Oct 2006 04:13:49 -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 1GYeeQ-0008JE-HR for ima@ietf.org; Sat, 14 Oct 2006 04:13:48 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GYeeP-000C24-P4; Sat, 14 Oct 2006 04:13:46 -0400 Date: Sat, 14 Oct 2006 04:13:44 -0400 From: John C Klensin To: Charles Lindsey , ima@ietf.org Message-ID: <9F58D1A172065CF237D0A9FA@p3.JCK.COM> In-Reply-To: References: <452EAA84.21A2@xyzzy.claranet.de> <0513BBE71C7E446C005B04B0@p3.JCK.COM> X-Mailer: Mulberry/4.0.6 (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: 0fa76816851382eb71b0a882ccdc29ac Cc: Subject: [EAI] Encapsulation again (was: Re: text for eai-framework re: 2047+S/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 Friday, 13 October, 2006 19:28 +0100 Charles Lindsey wrote: >... > In the UTF8SMTP universe, the charset in message/rfc822 > objects will beextended to utf-8. But they will then need a > Header-Type: UTF8SMTP(whatever), both in the message/rfc822 > _and_ in the main message headers,and the downgrade document > must tell you to downgrade them. I don't see any possible way to retroactively change the definition of message/rfc822 "in the UTF8SMTP universe" or otherwise. To be able to do so without causing strange behavior and problems in existing MUAs requires that one assume that headers never get lost, that portions of messages never leak from one environment to another, or otherwise. >> No, you don't, at least as far as I can tell. And the >> message/utf8smtp construct, which I wish we would stop >> discussing as if it were real without any sort of I-D on the >> table that describes its structure, should not need (or >> permit) a charset either, since any non-ASCII characters >> should (actually MUST) be in UTF-8 by definition. > > Yes, I agree. If we need to design an encapsulation mechanism > for completemessages, then it will be called > application/utf8smtp rather thanmessage/utf8smtp, and its > semantics will be exact;y the same > asapplication/news-transmission - i.e. you encapsulate the > whole object,ignoring its structurem and using a CTE of Q-P or > Base84. That ensures itcan be reconstructed exactly. Yes, but, as has been pointed out several times already, you can't do that without either breaking the nested encoding rule or needing to decode and re-code encoded body parts. The latter is likely to be inconsistent with "reconstructed exactly". This is _not_ a proposal and several details would need to be worked out to turn it into one (again, for those who believe an encapsulation model is necessary, the I-D posting deadline is 0900 US ET on Monday), but I think that, if one wants to encapsulate this stuff, one needs to have something very much like Content-type: multipart/i18nmessage boundary="--xyz" --xyz Content-type: text/utf8smtp-header charset=UTF-8 (required, no other options) Content-transfer-encoding: Base64 (probably, although "8bit" with 8BITMIME might work) [[headers, and only the headers, of the original message]] --xyz Content-type: (content-type of original message body which, could, in principle, be a multipart) [[original body, encoded if needed according to usual rules of, e.g., message/rfc822] --xyz-- Now that can be reconstructed exactly, modulo knowing how many blank lines separate the original header from the body and assuming that the body ends in an unambiguous CRLF. Any signing algorithm that is sensitive to the first, and probably the second, is probably broken in practice anyway. But that is, I think, it -- shortcuts are just not going to work well. > But I would rather not design such a mechanism at all, if we > can avoid itfor now. Agreed. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 14 05:37:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYfwj-0004JT-CC; Sat, 14 Oct 2006 05:36:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYfwh-0004Iz-KF for ima@ietf.org; Sat, 14 Oct 2006 05:36:43 -0400 Received: from smtp6.pp.htv.fi ([213.243.153.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYfwg-0007ae-5y for ima@ietf.org; Sat, 14 Oct 2006 05:36:43 -0400 Received: from Hurtta06k.keh.iki.fi (cs181108174.pp.htv.fi [82.181.108.174]) by smtp6.pp.htv.fi (Postfix) with ESMTP id 081A85BC02B; Sat, 14 Oct 2006 12:36:31 +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 k9E9aUUV012887; Sat, 14 Oct 2006 12:36:30 +0300 Received: (from hurtta@localhost) by Hurtta06k.keh.iki.fi (8.13.4/8.13.4/Submit) id k9E9aUKl012886; Sat, 14 Oct 2006 12:36:30 +0300 Message-Id: <200610140936.k9E9aUKl012886@Hurtta06k.keh.iki.fi> To: EAI mailing list Date: Sat, 14 Oct 2006 12:36:30 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version ME+ 2.5 PLalpha11+] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Kari Hurtta Subject: [EAI] draft-ietf-eai-utf8headers-01.txt question X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org draft-ietf-eai-utf8headers-01.txt: angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] alt-address = "{" [CFWS] addr-spec [CFWS] "}" RFC 2822: addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part domain = dot-atom / domain-literal / obs-domain atext = ALPHA / DIGIT / ; Any character except controls, "!" / "#" / ; SP, and specials. "$" / "%" / ; Used for atoms "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" atom = [CFWS] 1*atext [CFWS] dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom-text = 1*atext *("." 1*atext) draft-ietf-eai-utf8headers-01.txt: utf8-addr-spec = utf8-local-part "@" utf8-domain utf8-local-part= utf8-dot-atom / quoted-string / obs-local-part utf8-domain = utf8-dot-atom / domain-literal / obs-domain utf8-atext = ALPHA / DIGIT / "!" / "#" / ; Any character except "$" / "%" / ; controls, SP, and specials. "&" / "'" / ; Used for atoms "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / UTF8-xtra-char utf8-atom = [CFWS] 1*utf8-atext [CFWS] utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS] utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext) "{" adn "}" are on utf8-addr-spec and addr-spec because they are on atext and utf8-atext. How is is possible to parse this if CFWS is optional around "{" and "}" characters (alt-address) ? Seems that this requires parser which tries all possible parsing trees (with backtracking) and still it can got be several different interpretations. To parse that "{" and "}" are needed to remove from dot-atom and utf8-dot-atom. Alternatively "{" need to be changed to " { " and "}" to " } ". Then there is not pissble for several parsing trees (because between utf8-atext elemens and between atext elements "." character is required -- backtracking may be still needed on parser however.) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 14 07:48:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYi00-0007py-8x; Sat, 14 Oct 2006 07:48:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYhzz-0007pt-G5 for ima@ietf.org; Sat, 14 Oct 2006 07:48:15 -0400 Received: from smtp6.pp.htv.fi ([213.243.153.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYhzx-0005FN-V2 for ima@ietf.org; Sat, 14 Oct 2006 07:48:15 -0400 Received: from Hurtta06k.keh.iki.fi (cs181108174.pp.htv.fi [82.181.108.174]) by smtp6.pp.htv.fi (Postfix) with ESMTP id 413825BC032; Sat, 14 Oct 2006 14:48:13 +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 k9EBm72n013168; Sat, 14 Oct 2006 14:48:07 +0300 Received: (from hurtta@localhost) by Hurtta06k.keh.iki.fi (8.13.4/8.13.4/Submit) id k9EBm7BU013167; Sat, 14 Oct 2006 14:48:07 +0300 Message-Id: <200610141148.k9EBm7BU013167@Hurtta06k.keh.iki.fi> To: EAI mailing list Date: Sat, 14 Oct 2006 14:48:07 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version ME+ 2.5 PLalpha11+] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Kari Hurtta Subject: [EAI] draft-ietf-eai-utf8headers-01.txt / draft-ietf-eai-downgrade-02.txt suggestion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org draft-ietf-eai-utf8headers-01.txt: header-content = "UTF8SMTP:" [FWS] content-code [FWS] *( ";" parameter ) CRLF content-code = "UTF8" / "ASCII" / "Downgraded" parameter = "Header-Language:" [FWS] Language-List Language-List = Language-Tag [FWS] *("," [FWS] Language-Tag [FWS]) following was suggested: header-content = "Header-Type:" [FWS] content-code [FWS] *( ";" parameter ) CRLF ; parameter is defined on RFC 2045 content-code = "UTF8SMTP" / "ASCII" / "Downgraded" The "header-language" parameter is defined for "Header-Type" header-field. Value of "header-language" parameter is defined as following (after possible quotation of quoted-string is decode): header-language-value = Language-Tag [FWS] *("," [FWS] Language-Tag [FWS]) I also suggest following (almost same was also suggested): The "required-fields" parameter is defined for "Header-Type" header-field. Value of "required-fields" parameter is defined as following (after possible quotation of quoted-string is decode): required-fields-value = field-name [FWS] *("," [FWS] field-name [FWS]) ; field-name is defined on RFC 2822 draft-ietf-eai-downgrade-02.txt: Downgrading: * Check if the mail has 'UTF8SMTP' header and its value is "UTF8". Otherwise, downgrading is not required. * Check each header whether it contains UTF-8 characters or not. If the header contains UTF-8 characters, + If the header is an address header which is described in Section 5.1.1, - Preserve the header in 'Downgraded' header. - Downgrade the header defined in Section 5.1.1. + The other header case, encode the header by [RFC2047] with UTF-8 tag. * Change 'UTF8SMTP' header value to "Downgraded". Suggested changes: Downgrading: * Check if the mail has 'Header-Type' header field and its value is "UTF8SMTP". Otherwise, downgrading is not required. * Check each header field whether it contains UTF-8 characters or not. If the header field contains UTF-8 characters, + If the header field is an address header field which is described in Section 5.1.1, - Preserve the header in 'Downgraded' header field. - Downgrade the header field defined in Section 5.1.1. + Otherwise if syntax of header field is known: - Encode header elements according of [RFC2047] and [RFC2231] - If encoding is not possible, preserve the header in 'Downgraded' header field and remove original header field. - If syntax of header field is not known - Preserve the header in 'Downgraded' header field and remove original header field. * If some header field was removed, which is mentioned on "required-fields" parameter on 'Header-Type' header field, downgrading fails. * Change 'Header-Type' header field value to "Downgraded". NOTE: Address header downgrading in Section 5.1.1 may also remove header field. If that header field is mentioned on "required-fields" parameter on 'Header-Type' header field, downgrading fails. draft-ietf-eai-downgrade-02.txt: Upgrading: * Check if the mail has 'UTF8SMTP' header and its value is "Downgraded". Otherwise, upgrading is not required. * Decode all 'Downgraded' headers. + Decode header value field string which is [RFC2047] encoded. + If the header is address header described in Section 5.1.1, - Apply address header downgrading to the decoded header. - Remove the header line which is the same with the downgraded line. + Remove the 'Downgraded' header. + Add decoded header to mail header. * If each mail header has [RFC2047] encoded part and which encoding is "UTF-8", it is a downgraded header, so decode it. * Change 'UTF8SMTP' header value to "UTF8". Suggested changes: * Check if the mail has 'Header-Type' header field and its value is "Downgraded". Otherwise, upgrading is not required. + Decode header value field string which is [RFC2047] encoded. + If the header is address header field described in Section 5.1.1, - Apply address header field downgrading to the decoded header. - Remove the header field line which is the same with the downgraded line. + Remove the 'Downgraded' header field. + Add decoded header to mail header field. * For every mail header field, which syntax is known + If each mail header field has [RFC2047] or [RFC2231] encoded part and which encoding is "UTF-8", it is a downgraded header field, so decode it. * Change 'Header-Type' header value to "UTF8SMTP". / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 14 09:14:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYjLU-0000vE-Tu; Sat, 14 Oct 2006 09:14:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYjLT-0000v9-HD for ima@ietf.org; Sat, 14 Oct 2006 09:14: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 1GYjLR-0005pn-73 for ima@ietf.org; Sat, 14 Oct 2006 09:14:31 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYjLC-0005wS-K2 for ima@ietf.org; Sat, 14 Oct 2006 15:14:14 +0200 Received: from pd9fba8de.dip0.t-ipconnect.de ([217.251.168.222]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 15:14:14 +0200 Received: from nobody by pd9fba8de.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 15:14:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Encapsulation again Date: Sat, 14 Oct 2006 14:45:36 +0200 Organization: Lines: 35 Message-ID: <4530DBF0.5999@xyzzy.claranet.de> References: <452EAA84.21A2@xyzzy.claranet.de> <0513BBE71C7E446C005B04B0@p3.JCK.COM> <9F58D1A172065CF237D0A9FA@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8de.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) 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 John C Klensin wrote: > I think that, if one wants to encapsulate this stuff, one needs > to have something very much like > Content-type: multipart/i18nmessage boundary="--xyz" > > --xyz > Content-type: text/utf8smtp-header > charset=UTF-8 (required, no other options) > Content-transfer-encoding: Base64 > (probably, although "8bit" with 8BITMIME might work) > > [[headers, and only the headers, of the original message]] > --xyz > Content-type: (content-type of original message body > which, could, in principle, be a multipart) > > [[original body, encoded if needed according to usual > rules of, e.g., message/rfc822] > --xyz-- > Now that can be reconstructed exactly, modulo knowing how many > blank lines separate the original header from the body and > assuming that the body ends in an unambiguous CRLF. Similar to message/TBD, but working in one step from utf8smtp down to 7bit. So that idea (multipart/TBB + text/header-TBD) is probably better. DKIM offers two ways of "canonicalization", I missed that part of the discussion, but I hope it's okay. And the DKIM draft proposes a IANA registry for canonicalization algorithms. We can check if it's good enough in the last call. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 14 09:47:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYjr9-0003St-LW; Sat, 14 Oct 2006 09:47:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYjr8-0003Sn-Iw for ima@ietf.org; Sat, 14 Oct 2006 09:47:14 -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 1GYjr7-0004QQ-8u for ima@ietf.org; Sat, 14 Oct 2006 09:47:14 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYjqx-0003hx-NP for ima@ietf.org; Sat, 14 Oct 2006 15:47:03 +0200 Received: from pd9fba8de.dip0.t-ipconnect.de ([217.251.168.222]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 15:47:03 +0200 Received: from nobody by pd9fba8de.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 15:47:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-utf8headers-01.txt / draft-ietf-eai-downgrade-02.txt suggestion Date: Sat, 14 Oct 2006 15:29:22 +0200 Organization: Lines: 51 Message-ID: <4530E632.3949@xyzzy.claranet.de> References: <200610141148.k9EBm7BU013167@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8de.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: > draft-ietf-eai-utf8headers-01.txt: > header-content = "UTF8SMTP:" [FWS] content-code [FWS] > *( ";" parameter ) CRLF > content-code = "UTF8" / "ASCII" / "Downgraded" > parameter = "Header-Language:" [FWS] Language-List > Language-List = Language-Tag [FWS] > *("," [FWS] Language-Tag [FWS]) > following was suggested: > header-content = "Header-Type:" [FWS] content-code [FWS] > *( ";" parameter ) CRLF "Header-Type" is good. > ; parameter is defined on RFC 2045 It's now in RFC 2231 (don't ask), and a MIME parameter uses "=" to separate name and value, not ":". The "parameter" in the utf8headers I-D is apparently no MIME parameter, it's a simpler construct (?). Or it's a typo. is now defined in RFC 4646. And for a MIME parameter a with more than one would need to be a because the comma belongs to . > content-code = "UTF8SMTP" / "ASCII" / "Downgraded" Why not "UTF8" as is ? > header-language-value = Language-Tag [FWS] > *("," [FWS] Language-Tag [FWS]) The xyz-List style is used in 2822 (and in "grandson-of-1036" now in state "waiting for writeup"). > required-fields-value = field-name [FWS] > *("," [FWS] field-name [FWS]) > ; field-name is defined on RFC 2822 That could be misinterpreted to cover only the field names defined in 2822, maybe say: | ; the term is defined in RFC 2822 Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 14 11:09:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYl7x-0008Ql-0v; Sat, 14 Oct 2006 11:08:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYl7w-0008Op-Aq for ima@ietf.org; Sat, 14 Oct 2006 11:08:40 -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 1GYl7u-000869-0o for ima@ietf.org; Sat, 14 Oct 2006 11:08:40 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYl7l-0003SC-RD for ima@ietf.org; Sat, 14 Oct 2006 17:08:29 +0200 Received: from pd9fba8de.dip0.t-ipconnect.de ([217.251.168.222]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 17:08:29 +0200 Received: from nobody by pd9fba8de.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 17:08:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 14 Oct 2006 17:07:30 +0200 Organization: Lines: 31 Message-ID: <4530FD32.3B83@xyzzy.claranet.de> References: <452EAA84.21A2@xyzzy.claranet.de> <0513BBE71C7E446C005B04B0@p3.JCK.COM> <452EEF71.172F@xyzzy.claranet.de> <5dpscwwkhf.fsf@leija.fmi.fi> <452F898C.2C49@xyzzy.claranet.de> <5dslhswd0h.fsf@leija.fmi.fi> <45308CCA.5222@xyzzy.claranet.de> <5dpscvtj0s.fsf_-_@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8de.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [EAI] Re: Sendmail message/TBD handling X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > Sendmail will strip message/TBD to 7-bit if next host do not > announce 8BITMIME. Odd, does it try that stunt with any 8bit content ? 1652 says "it must cause no loss of information; MIME transport encodings must be employed as needed to insure this is the case". Losing one of eight bits is FUBAR. > I suggested that mail should be bounced, but it is not > implemented. We can't freeze this WG until sendmail is upgraded to support RFC 1652 published more than 12 years ago. Maybe all poor old pre-1652 MTAs (are forced to) duck behind non-sendmail MXs. Are you really saying that sendmail announces 8BITMIME support, and then forwards 8bit mails to non-8BITMIME hops by stripping this bit ? [2821 2.4] An originating SMTP client which has not successfully | negotiated an appropriate extension with a particular server | MUST NOT transmit messages with information in the high-order | bit of octets. That certainly doesn't mean "just strip the 8th bit on the side of the client if the server doesn't offer 8BITMIME". Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 14 11:15:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYlEA-0003vM-5F; Sat, 14 Oct 2006 11:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYlE9-0003vC-MP for ima@ietf.org; Sat, 14 Oct 2006 11:15:05 -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 1GYlE7-00010A-7W for ima@ietf.org; Sat, 14 Oct 2006 11:15:05 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYlDz-0004ca-EA for ima@ietf.org; Sat, 14 Oct 2006 17:14:55 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 17:14:55 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 17:14:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-01.txt / draft-ietf-eai-downgrade-02.txt suggestion Date: 14 Oct 2006 18:14:44 +0300 Lines: 83 Message-ID: <5d4pu7c4kb.fsf@Hurtta06k.keh.iki.fi> References: <200610141148.k9EBm7BU013167@Hurtta06k.keh.iki.fi> <4530E632.3949@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Kari Hurtta wrote: > > > draft-ietf-eai-utf8headers-01.txt: > > > header-content = "UTF8SMTP:" [FWS] content-code [FWS] > > *( ";" parameter ) CRLF > > content-code = "UTF8" / "ASCII" / "Downgraded" > > parameter = "Header-Language:" [FWS] Language-List > > Language-List = Language-Tag [FWS] > > *("," [FWS] Language-Tag [FWS]) > > > following was suggested: > > > header-content = "Header-Type:" [FWS] content-code [FWS] > > *( ";" parameter ) CRLF > > "Header-Type" is good. ( Charles Lindsey suggested "Header-Content", I was not mean invent new, but seems that I remembered wrongly :-) Anyway "Header-Type" is now suggested. ) > > ; parameter is defined on RFC 2045 > > It's now in RFC 2231 (don't ask), and a MIME parameter uses "=" ( Well, I have implemented RFC 2231 once -- not need to ask :-) Also I referenced RFC 2231 on that my suggestions downgrade -part. ) > to separate name and value, not ":". The "parameter" in the > utf8headers I-D is apparently no MIME parameter, it's a simpler > construct (?). Or it's a typo. is now defined > in RFC 4646. I assumed that ":" was typo. Anyway I objected earlier that it is not good to introduce yet another syntax for parameters when MUAs and MTAs already implement parser for MIME parameters. > And for a MIME parameter a with more than one > would need to be a because the > comma belongs to . Yes. I was taken account on that my suggestion that quoted-string is needed. Maybe it was not clear enough? > > > content-code = "UTF8SMTP" / "ASCII" / "Downgraded" > > Why not "UTF8" as is ? ( Charles Lindsey also suggested "Utf8smtp". But actually "UTF8" is also ok. ) > > header-language-value = Language-Tag [FWS] > > *("," [FWS] Language-Tag [FWS]) > > The xyz-List style is used in 2822 (and in "grandson-of-1036" > now in state "waiting for writeup"). So that may be also header-language-value = Language-List Language-List = Language-Tag [FWS] *("," [FWS] Language-Tag [FWS]) > > required-fields-value = field-name [FWS] > > *("," [FWS] field-name [FWS]) > > ; field-name is defined on RFC 2822 > > That could be misinterpreted to cover only the field names > defined in 2822, maybe say: > > | ; the term is defined in RFC 2822 Yes. > Frank / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 14 12:02:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYlxi-00066m-5o; Sat, 14 Oct 2006 12:02:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYlxg-00066C-Qm for ima@ietf.org; Sat, 14 Oct 2006 12:02:08 -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 1GYluB-0008Gv-Ur for ima@ietf.org; Sat, 14 Oct 2006 11:58:33 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYltz-0005hc-Di for ima@ietf.org; Sat, 14 Oct 2006 17:58:19 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 17:58:19 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 14 Oct 2006 17:58:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Re: Sendmail message/TBD handling Date: 14 Oct 2006 18:58:04 +0300 Lines: 77 Message-ID: <5dzmbyc2k3.fsf@Hurtta06k.keh.iki.fi> References: <452EAA84.21A2@xyzzy.claranet.de> <0513BBE71C7E446C005B04B0@p3.JCK.COM> <452EEF71.172F@xyzzy.claranet.de> <5dpscwwkhf.fsf@leija.fmi.fi> <452F898C.2C49@xyzzy.claranet.de> <5dslhswd0h.fsf@leija.fmi.fi> <45308CCA.5222@xyzzy.claranet.de> <5dpscvtj0s.fsf_-_@Hurtta06k.keh.iki.fi> <4530FD32.3B83@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Kari Hurtta wrote: > > > Sendmail will strip message/TBD to 7-bit if next host do not > > announce 8BITMIME. > > Odd, does it try that stunt with any 8bit content ? 1652 says > "it must cause no loss of information; MIME transport encodings > must be employed as needed to insure this is the case". Losing > one of eight bits is FUBAR. > > > I suggested that mail should be bounced, but it is not > > implemented. > > We can't freeze this WG until sendmail is upgraded to support > RFC 1652 published more than 12 years ago. Maybe all poor old > pre-1652 MTAs (are forced to) duck behind non-sendmail MXs. I just warn :-) > Are you really saying that sendmail announces 8BITMIME support, > and then forwards 8bit mails to non-8BITMIME hops by stripping > this bit ? Only for types where quoted-printable or base64 is not allowed and type can not handled recursively. That means message/* other that message/rfc822 ( 8bit is also stripped from multipart preamble, I think. But that 8bit on multipart preamble is more or less undefined area. ) quoted-printable or base64 are applied to leaf mime types, where these encodings are allowed. > [2821 2.4] An originating SMTP client which has not successfully > | negotiated an appropriate extension with a particular server > | MUST NOT transmit messages with information in the high-order > | bit of octets. > > That certainly doesn't mean "just strip the 8th bit on the side > of the client if the server doesn't offer 8BITMIME". > > Frank / Kari Hurtta KNOWNBUGS file from sendmail distribution: * 8->7 bit MIME conversion When sendmail is doing 8->7 bit MIME conversions, and the message contains certain MIME body types that cannot be converted to 7-bit, sendmail will strip the message to 7-bit. doc/op/op.me from sendmail distribution: $=s contains the set of subtypes of message that can be treated recursively. By default it contains only "rfc822". Other "message/*" types cannot be 8->7 bit encoded. If a message containing eight bit data is sent to a seven bit host, and that message cannot be encoded into seven bits, it will be stripped to 7 bits. So at least documentation say so. 8BITMIME downgrade happens on sendmail/mime.c but it is difficult to give meaningfull quote. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 14 18:23:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYruV-0005df-J5; Sat, 14 Oct 2006 18:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYruU-0005dY-CC for ima@ietf.org; Sat, 14 Oct 2006 18:23:14 -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 1GYruT-0002Kp-2l for ima@ietf.org; Sat, 14 Oct 2006 18:23:14 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GYru1-0000dM-Gb for ima@ietf.org; Sun, 15 Oct 2006 00:22:47 +0200 Received: from pd9fba8de.dip0.t-ipconnect.de ([217.251.168.222]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Oct 2006 00:22:45 +0200 Received: from nobody by pd9fba8de.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Oct 2006 00:22:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-utf8headers-01.txt / draft-ietf-eai-downgrade-02.txt suggestion Date: Sun, 15 Oct 2006 00:21:45 +0200 Organization: Lines: 27 Message-ID: <453162F9.B7F@xyzzy.claranet.de> References: <200610141148.k9EBm7BU013167@Hurtta06k.keh.iki.fi> <4530E632.3949@xyzzy.claranet.de> <5d4pu7c4kb.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8de.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > Well, I have implemented RFC 2231 once -- not need to ask :-) So far for my wild theory that only Bruce Lilly tried this. > I assumed that ":" was typo. Anyway I objected earlier that > it is not good to introduce yet another syntax for parameters > when MUAs and MTAs already implement parser for MIME parameters. ACK, if you want or need RFC 2231 somewhere you can stick to it. > I was taken account on that my suggestion that quoted-string > is needed. Maybe it was not clear enough? Your is clear, I wasn't sure about the value, confused by that ":" vs. "=" issue. > header-language-value = Language-List > Language-List = Language-Tag [FWS] > *("," [FWS] Language-Tag [FWS]) One term's enough, *-value or *-List. It's not important, I like the shorter Language-List better, matter of taste. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 14 18:25:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYrwI-00063z-Cx; Sat, 14 Oct 2006 18:25:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYrwH-00063t-1A for ima@ietf.org; Sat, 14 Oct 2006 18:25:05 -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 1GYrwF-00030U-OK for ima@ietf.org; Sat, 14 Oct 2006 18:25:05 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GYrwE-00012S-Js for ima@ietf.org; Sun, 15 Oct 2006 00:25:02 +0200 Received: from pd9fba8de.dip0.t-ipconnect.de ([217.251.168.222]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Oct 2006 00:25:02 +0200 Received: from nobody by pd9fba8de.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Oct 2006 00:25:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Re: Sendmail message/TBD handling Date: Sun, 15 Oct 2006 00:01:36 +0200 Organization: Lines: 21 Message-ID: <45315E40.2B4B@xyzzy.claranet.de> References: <452EAA84.21A2@xyzzy.claranet.de> <0513BBE71C7E446C005B04B0@p3.JCK.COM> <452EEF71.172F@xyzzy.claranet.de> <5dpscwwkhf.fsf@leija.fmi.fi> <452F898C.2C49@xyzzy.claranet.de> <5dslhswd0h.fsf@leija.fmi.fi> <45308CCA.5222@xyzzy.claranet.de> <5dpscvtj0s.fsf_-_@Hurtta06k.keh.iki.fi> <4530FD32.3B83@xyzzy.claranet.de> <5dzmbyc2k3.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8de.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > Only for types where quoted-printable or base64 is not allowed > and type can not handled recursively. > That means message/* other that message/rfc822 That sounds less dangerous, ignoring message/news and a few others like message/http for the moment... > 8bit is also stripped from multipart preamble, I think. ...and that too, maybe theoretically interesting for DKIM. 2046 says *text as defined in 822, modulo CTL details that's US-ASCII, if senders try something else and the illegal bits are stripped it's their problem. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 16 06:02:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPIM-0002Nx-1Y; Mon, 16 Oct 2006 06:02:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPIK-0002I7-Ae for ima@ietf.org; Mon, 16 Oct 2006 06:02:04 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZPID-0000Jh-IR for ima@ietf.org; Mon, 16 Oct 2006 06:02:04 -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.232) id 45335880.c471.a for ima@ietf.org; Mon, 16 Oct 2006 11:01:36 +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 k9GA1XfZ026327 for ; Mon, 16 Oct 2006 11:01:34 +0100 (BST) To: "ima@ietf.org" Subject: Re: [EAI] Re: Sendmail message/TBD handling References: <452EAA84.21A2@xyzzy.claranet.de> <0513BBE71C7E446C005B04B0@p3.JCK.COM> <452EEF71.172F@xyzzy.claranet.de> <5dpscwwkhf.fsf@leija.fmi.fi> <452F898C.2C49@xyzzy.claranet.de> <5dslhswd0h.fsf@leija.fmi.fi> <45308CCA.5222@xyzzy.claranet.de> <5dpscvtj0s.fsf_-_@Hurtta06k.keh.iki.fi> <4530FD32.3B83@xyzzy.claranet.de> <5dzmbyc2k3.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Mon, 16 Oct 2006 11:01:32 +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: <5dzmbyc2k3.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) 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 Sat, 14 Oct 2006 16:58:04 +0100, Kari Hurtta wrote: > Frank Ellermann writes in gmane.ietf.ima: >> Are you really saying that sendmail announces 8BITMIME support, >> and then forwards 8bit mails to non-8BITMIME hops by stripping >> this bit ? > > Only for types where quoted-printable or base64 is not allowed > and type can not handled recursively. Which might just about make it legal. I have been looiing carefully at RFC 1652, and I think I could argue convincingly either way. But it does include the words: 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. It is certainly most illiberal, and an example of extra code inserted into an implementation with the express intent of making it less liberal, without providing the slightest benefit elsewhere. Jon Postel should be turning in his grave. -- 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 Oct 16 06:40:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPtE-0007iB-H2; Mon, 16 Oct 2006 06:40:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPtD-0007eA-Ia for ima@ietf.org; Mon, 16 Oct 2006 06:40:11 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZPtA-0006Pq-8I for ima@ietf.org; Mon, 16 Oct 2006 06:40:11 -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.232) id 45336186.c449.12 for ima@ietf.org; Mon, 16 Oct 2006 11:40:06 +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 k9GAe47Y028682 for ; Mon, 16 Oct 2006 11:40:05 +0100 (BST) To: "ima@ietf.org" Subject: Re: [EAI] Encapsulation again (was: Re: text for eai-framework re: 2047+S/MIME) References: <452EAA84.21A2@xyzzy.claranet.de> <0513BBE71C7E446C005B04B0@p3.JCK.COM> <9F58D1A172065CF237D0A9FA@p3.JCK.COM> Message-ID: Date: Mon, 16 Oct 2006 11:40:03 +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: <9F58D1A172065CF237D0A9FA@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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, 14 Oct 2006 09:13:44 +0100, John C Klensin wrote: > --On Friday, 13 October, 2006 19:28 +0100 Charles Lindsey > wrote: > >> ... >> In the UTF8SMTP universe, the charset in message/rfc822 >> objects will beextended to utf-8. But they will then need a >> Header-Type: UTF8SMTP(whatever), both in the message/rfc822 >> _and_ in the main message headers,and the downgrade document >> must tell you to downgrade them. > > I don't see any possible way to retroactively change the > definition of message/rfc822 "in the UTF8SMTP universe" or > otherwise. To be able to do so without causing strange behavior > and problems in existing MUAs requires that one assume that > headers never get lost, that portions of messages never leak > from one environment to another, or otherwise. And there I disagree with you entirely. It is esential that we allow utf8smtp messages to be transmitted in a message/rfc822 (within the utf8smtp universe, that is). It is just too hard to persuade the world to implement new message types. Currently, the concept of a correctly constructed object compliant with RFC 2822 and the MIME standards is well understood, as is the concept of a message/rfc822 object. This WG is in the business of defing various extensions to such objeccts. We are defining extensions to RFC 2822, and we can define extensions to other standards as needed. Thus we define a new class of objects known as "utf8smtp messages" and define how they may be transported. If we define an "extended message/rfc822 object", then clearly we must say that it may only be contained within an "utf8smtp message", in which case if you have occasion to downgrade the one, you must at the same time downgrade the other (or bounce the lot if that is too much trouble). >> Yes, I agree. If we need to design an encapsulation mechanism >> for completemessages, then it will be called >> application/utf8smtp rather thanmessage/utf8smtp, and its >> semantics will be exact;y the same >> asapplication/news-transmission - i.e. you encapsulate the >> whole object,ignoring its structurem and using a CTE of Q-P or >> Base84. That ensures itcan be reconstructed exactly. > > Yes, but, as has been pointed out several times already, you > can't do that without either breaking the nested encoding rule > or needing to decode and re-code encoded body parts. The latter > is likely to be inconsistent with "reconstructed exactly". I think there is a possible exception to the "nested encoded rule" when the inside encoding is absolutely nothing to do with the email protocols. That was the case with the media type news/transmission, whose prime purpose was to prevent any mail agent from getting inside it and tinkering with any internal structure that just happened to look like a mail structure. The object encapsulated inside was a news article, and if it chose to use some CTE within itself for whatever reason, then it was for the Netnews protocols to take it apart or put it together again. I think the same argument could infact be applied to any application type - to the mail protocols they are just streams of octets to be preserved intact (by applying CTEs as necessary) and then served up to the intended application at the far end. I agree, however, that it might be taking that principle a little bit too far to invent an application/utf8smtp whose purpose was to preserve the internal structure of a utf8smtp email message against the machinations of present day transports. -- 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 Oct 16 07:27:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZQcc-0007ci-PR; Mon, 16 Oct 2006 07:27:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZQcb-0007XH-2J for ima@ietf.org; Mon, 16 Oct 2006 07:27:05 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZQcU-0007m9-AF for ima@ietf.org; Mon, 16 Oct 2006 07:27:04 -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.231) id 45336c80.15e06.14 for ima@ietf.org; Mon, 16 Oct 2006 12:26: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 k9GBQsw9001851 for ; Mon, 16 Oct 2006 12:26:55 +0100 (BST) Date: Mon, 16 Oct 2006 12:26:52 +0100 To: "ima@ietf.org" Subject: Re: [EAI] draft-ietf-eai-utf8headers-01.txt / draft-ietf-eai-downgrade-02.txt suggestion References: <200610141148.k9EBm7BU013167@Hurtta06k.keh.iki.fi> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <200610141148.k9EBm7BU013167@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 14 Oct 2006 12:48:07 +0100, Kari Hurtta wrote: > draft-ietf-eai-utf8headers-01.txt: > > header-content = "UTF8SMTP:" [FWS] content-code [FWS] > *( ";" parameter ) CRLF > content-code = "UTF8" / "ASCII" / "Downgraded" > parameter = "Header-Language:" [FWS] Language-List > Language-List = Language-Tag [FWS] > *("," [FWS] Language-Tag [FWS]) > > > following was suggested: > > header-content = "Header-Type:" [FWS] content-code [FWS] > *( ";" parameter ) CRLF > > ; parameter is defined on RFC 2045 > > content-code = "UTF8SMTP" / "ASCII" / "Downgraded" Yes, that was my suggestion, posted here on 31st August when commenting on eai-utf8headers-01. It looks like you, myself, and Frank now prefer the new header to be called "Header-Type". The reason the content-code is "UTF8SMTP" rather than "UTF8" was to make it the same as the capability to be returned by the EHLO command (no point in inventing more than one keyword for the same concept). Not that I particularly like "UTF8SMTP" (because these new messages might also be handled by other transports such as UUCP and NNTP), but that is a separate issue. As an aside, there has been no other response to my comments on eai-utf8headers-01 on 31st August, so I don't know whether the authors have accepted them or not. Certainly I also drew attention to the "{alt-address}" problem which you have also mentioned recently. > > > The "header-language" parameter is defined for "Header-Type" > header-field. Value of "header-language" parameter is defined > as following (after possible quotation of quoted-string is decode): No, read further in my proposal and you will see that I wanted to abolish that "header-language" parameter and substitute instead a new header "Header-Language" defined in the same way as the "Content-Language" in RFC 3282. > draft-ietf-eai-downgrade-02.txt: > Suggested changes: > > Downgrading: Yes, I also suggested similar changes in my separate comments on eai-downgrade-02 on 31st August, but there has been no response from the authors yet. -- 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 Oct 16 10:37:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZTau-00038m-R1; Mon, 16 Oct 2006 10:37:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZTau-00038h-CN for ima@ietf.org; Mon, 16 Oct 2006 10:37:32 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZTar-0004Ce-Un for ima@ietf.org; Mon, 16 Oct 2006 10:37:32 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C13D325973B for ; Mon, 16 Oct 2006 16:34:52 +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 04005-10 for ; Mon, 16 Oct 2006 16:34:47 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BA3FC2596C9 for ; Mon, 16 Oct 2006 16:34:47 +0200 (CEST) Message-ID: <45339923.8030900@alvestrand.no> Date: Mon, 16 Oct 2006 07:37:23 -0700 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: "ima@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [EAI] WG LAST CALL: draft-ietf-eai-framework-02 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 Greetings, the WG chairs believe that the just released draft-ietf-eai-framework-02 is "just about ready to go" - that is, there are no big outstanding issues, and the WG is better served declaring this stable and working out the details of the other documents. We are therefore starting a WG Last Call on this document - of 2 weeks, which will expire on October 30, just one week prior to the San Diego IETF. This should allow us to get all open issues on the document on the table, and if any of them need face-to-face discussion in order to propose a good resolution, we can do that in San Diego. Practical details: - If you want to raise an issue, send a message to the mailing list with a subject line that starts with "ISSUE: framework
- short description of issue" The WG chairs will track open issues by the start message of the thread, and may assign numbers to issues eventually. - If you want to comment on an issue raised, reply to the message. The subject line will then be "Re: ISSUE: ....." - If you want to reply to a message and make a general comment, rather than a comment germane to the issue raised, CHANGE THE SUBJECT LINE to NOT start with "Re: ISSUE". - If you want to reply to a message calling attention to a NEW issue, do NOT do so. Post another message raising the new issue, with a new ISSUE subject line instead. THIS IS VERY IMPORTANT. Many times, people have raised issues and seen them forgotten because they were buried in the long thread of discussion on a different topic. RAISE ANOTHER ISSUE. We will not attempt to extract currently open issues from the mailing list. The people who raised them can most easily check the -02 framework document to see if they are addressed or not. We will attempt to occasionally post a list of currently open issues during the Last Call, and Harald, for the chairs _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 16 21:55:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZeAh-0003JB-JQ; Mon, 16 Oct 2006 21:55:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZeAf-00037H-OW for ima@ietf.org; Mon, 16 Oct 2006 21:55:09 -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 1GZeAd-0007tm-Dq for ima@ietf.org; Mon, 16 Oct 2006 21:55:09 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GZe8S-00011S-OV for ima@ietf.org; Tue, 17 Oct 2006 03:52:53 +0200 Received: from pd9fbacc0.dip0.t-ipconnect.de ([217.251.172.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 03:52:52 +0200 Received: from nobody by pd9fbacc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 03:52:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 17 Oct 2006 03:46:27 +0200 Organization: Lines: 13 Message-ID: <453435F3.7988@xyzzy.claranet.de> References: <45339923.8030900@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: pd9fbacc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [EAI] ISSUE: framework 1.3 - i18mail user clarification 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 Copied from JFTR: Yangwoo Ko wrote: > ... it is not possible to tell from an ASCII address that an email > sender or recipient is an i18mail user or an ASCII user. > Too redundant? No, it's clearer and better than only s/i18mail/ASCII/. Thanks. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 16 22:08:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZeNP-0004Yp-B9; Mon, 16 Oct 2006 22:08:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZeNN-0004Yg-IV for ima@ietf.org; Mon, 16 Oct 2006 22:08:17 -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 1GZeNM-0001zB-9L for ima@ietf.org; Mon, 16 Oct 2006 22:08:17 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GZeNJ-0005TS-75 for ima@ietf.org; Tue, 17 Oct 2006 04:08:13 +0200 Received: from pd9fbacc0.dip0.t-ipconnect.de ([217.251.172.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 04:08:13 +0200 Received: from nobody by pd9fbacc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 04:08:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 17 Oct 2006 04:07:29 +0200 Organization: Lines: 13 Message-ID: <45343AE1.5F1C@xyzzy.claranet.de> References: <45339923.8030900@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: pd9fbacc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [EAI] ISSUE: framework -3 - missing MIME considerations 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 "document plan" in chapter 3 tries to get away with updating 2822 in the utf8headers I-D. That's not good enough for some darker corners of MIME like UTF-8 in comments in Content-* header fields or preambles. The utf8headers I-D must explain why a new message subtype (different from rfc822) isn't desirable, why using message/rfc822 with UTF-8 headers won't cause havoc, and how it might affect application/mbox. The "document plan" should note this - a separate draft for MIME issues (separated from the utf8headers I-D) would be too confusing. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 16 22:24:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZedH-0000QS-9V; Mon, 16 Oct 2006 22:24:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZedF-0000QG-Jg for ima@ietf.org; Mon, 16 Oct 2006 22:24: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 1GZedE-0004Qc-B1 for ima@ietf.org; Mon, 16 Oct 2006 22:24:41 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GZed8-0007kl-VY for ima@ietf.org; Tue, 17 Oct 2006 04:24:34 +0200 Received: from pd9fbacc0.dip0.t-ipconnect.de ([217.251.172.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 04:24:34 +0200 Received: from nobody by pd9fbacc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 04:24:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 17 Oct 2006 04:22:39 +0200 Organization: Lines: 3 Message-ID: <45343E6F.6AC4@xyzzy.claranet.de> References: <45339923.8030900@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: pd9fbacc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [EAI] ISSUE: framework 4.1 - reject 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 s/bounce/reject/g A "bounce" is commonly understood as sending spam (unsolicited NDRs) to innocent bystanders as part of a DDoS. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 16 22:30:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZeiX-0003NI-Ii; Mon, 16 Oct 2006 22:30:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZeiW-0003ND-R2 for ima@ietf.org; Mon, 16 Oct 2006 22:30:08 -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 1GZeiV-0005CB-HI for ima@ietf.org; Mon, 16 Oct 2006 22:30:08 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GZeiQ-0008W8-Kp for ima@ietf.org; Tue, 17 Oct 2006 04:30:02 +0200 Received: from pd9fbacc0.dip0.t-ipconnect.de ([217.251.172.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 04:30:02 +0200 Received: from nobody by pd9fbacc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 04:30:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 17 Oct 2006 04:28:36 +0200 Organization: Lines: 4 Message-ID: <45343FD4.3D1@xyzzy.claranet.de> References: <45339923.8030900@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: pd9fbacc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [EAI] ISSUE: framework 4.1 - POP.??? 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 Copied from : /ditto for POP.???/ Should that be /ditto for [I18Nemail-pop]/ ? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 16 22:47:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZez0-0006Kn-BE; Mon, 16 Oct 2006 22:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZeyy-0006KE-VK for ima@ietf.org; Mon, 16 Oct 2006 22:47:08 -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 1GZeyx-0008BG-MB for ima@ietf.org; Mon, 16 Oct 2006 22:47:08 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GZeyw-0002b0-KK for ima@ietf.org; Tue, 17 Oct 2006 04:47:06 +0200 Received: from pd9fbacc0.dip0.t-ipconnect.de ([217.251.172.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 04:47:06 +0200 Received: from nobody by pd9fbacc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 04:47:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 17 Oct 2006 04:46:20 +0200 Organization: Lines: 8 Message-ID: <453443FC.4A2F@xyzzy.claranet.de> References: <45339923.8030900@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: pd9fbacc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [EAI] ISSUE: framework 5 - delivery to final delivery MTA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org A "delivery to the final delivery MTA" is confusing, should that be a "delivery by the final delivery MTA", or a "forward to the" MDA ? Maybe replace "or after delivery to the final delivery MTA" by "or at final delivery by the MDA" (acronym introduced in section 3). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 16 22:54:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZf68-0003vS-6J; Mon, 16 Oct 2006 22:54:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZf67-0003vN-6m for ima@ietf.org; Mon, 16 Oct 2006 22:54: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 1GZf65-0002UU-6H for ima@ietf.org; Mon, 16 Oct 2006 22:54:31 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GZf60-0003Oz-7A for ima@ietf.org; Tue, 17 Oct 2006 04:54:24 +0200 Received: from pd9fbacc0.dip0.t-ipconnect.de ([217.251.172.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 04:54:24 +0200 Received: from nobody by pd9fbacc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 04:54:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 17 Oct 2006 04:54:04 +0200 Organization: Lines: 2 Message-ID: <453445CC.7F86@xyzzy.claranet.de> References: <45339923.8030900@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: pd9fbacc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [EAI] ISSUE: framework 6 - delete section 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 complete I-D is about I18N, it doesn't need this redundant section. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 16 23:00:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZfBW-0006w0-TM; Mon, 16 Oct 2006 23:00:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZfBV-0006qA-U6 for ima@ietf.org; Mon, 16 Oct 2006 23:00:05 -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 1GZfBS-0004GW-KA for ima@ietf.org; Mon, 16 Oct 2006 23:00:05 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GZfBR-0003yS-Sc for ima@ietf.org; Tue, 17 Oct 2006 05:00:01 +0200 Received: from pd9fbacc0.dip0.t-ipconnect.de ([217.251.172.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 05:00:01 +0200 Received: from nobody by pd9fbacc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 05:00:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 17 Oct 2006 04:57:46 +0200 Organization: Lines: 8 Message-ID: <453446AA.739F@xyzzy.claranet.de> References: <45339923.8030900@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: pd9fbacc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [EAI] ISSUE: framework 7 - missing local part (ab)uses as label 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 As noted in : For chapter 7 I propose to add a new subsection about any "local part transformation" schemes like SES, SRS, BATV, or SPF per-user-policies (or other uses of its %{l} macro as domain label, %{l} = "local part") Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 16 23:20:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZfVL-0007A5-LR; Mon, 16 Oct 2006 23:20:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZfVK-00079O-K2 for ima@ietf.org; Mon, 16 Oct 2006 23:20:34 -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 1GZfVJ-0001jo-Au for ima@ietf.org; Mon, 16 Oct 2006 23:20:34 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GZfVB-0006Ws-Ge for ima@ietf.org; Tue, 17 Oct 2006 05:20:25 +0200 Received: from pd9fbacc0.dip0.t-ipconnect.de ([217.251.172.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 05:20:25 +0200 Received: from nobody by pd9fbacc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 05:20:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 17 Oct 2006 05:19:00 +0200 Organization: Lines: 10 Message-ID: <45344BA4.3A73@xyzzy.claranet.de> References: <45339923.8030900@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: pd9fbacc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [EAI] ISSUE: framework 10 - too long 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 IMO a pointer to IDN (especially 4690) is good enough, there's nothing special to say about confusable characters in local parts. The reference to [Net-Unicode] should be deleted, that I-D is rather unclear at the moment, apparently it talks about telnet and not SMTP, discussing the merits of various ASCII control characters like TAB. "impact any systems or mechanisms that is dependent" - should that be "are dependent" or "depend" ? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 16 23:30:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZfei-0007Sz-W7; Mon, 16 Oct 2006 23:30:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZfeh-0007Su-N0 for ima@ietf.org; Mon, 16 Oct 2006 23:30:15 -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 1GZfeg-0003bK-Cs for ima@ietf.org; Mon, 16 Oct 2006 23:30:15 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GZfec-0007lv-I8 for ima@ietf.org; Tue, 17 Oct 2006 05:30:10 +0200 Received: from pd9fbacc0.dip0.t-ipconnect.de ([217.251.172.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 05:30:10 +0200 Received: from nobody by pd9fbacc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 05:30:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Tue, 17 Oct 2006 05:29:33 +0200 Organization: Lines: 13 Message-ID: <45344E1D.160@xyzzy.claranet.de> References: <45339923.8030900@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: pd9fbacc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [EAI] ISSUE: framework 13 - nits 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 An old one in ~~~cut ~~~ s/[DKIM-Charter]/[draft-ietf-dkim-base] + [draft-ietf-dkim-overview]/ The DKIM-threats, SSP-requirements, and SSP-proper texts are not directly affected (unless SSP tries "per user policies", unclear). ~~~ end ~~~ I've changed my mind, [DKIM Charter] is okay, the details are not relevant. But please replace [RFC2663] by [RFC2633] or better by [RFC3851] ;-) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 17 00:31:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZgb9-0003qH-Az; Tue, 17 Oct 2006 00:30:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZgYK-0002oZ-O3 for ima@ietf.org; Tue, 17 Oct 2006 00:27:45 -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 1GZgKm-0006P5-Hp for ima@ietf.org; Tue, 17 Oct 2006 00:13:49 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GZgKY-0006nA-8X for ima@ietf.org; Tue, 17 Oct 2006 06:13:30 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 06:13:30 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 06:13:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Kari Hurtta" Subject: Re: [EAI] ISSUE: framework 4.1 - reject Date: 17 Oct 2006 07:13:23 +0300 Lines: 32 Message-ID: <5d3b9n4m1o.fsf@Hurtta06k.keh.iki.fi> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Frank Ellermann writes in gmane.ietf.ima: > s/bounce/reject/g A "bounce" is commonly understood as sending spam > (unsolicited NDRs) to innocent bystanders as part of a DDoS. It was 2. An SMTP relay must <...> * Bounce the message so that the sender can make another plan. If the message cannot be forwarded because the next-hop system cannot accept the extension and insufficient information is available to reliably downgrade it, it MUST be bounced. On generally smtp level reject is not possible on here. SMTP level reject is possible only when message is not yet accepted. And a SMTP connection to next-hop system happens after message is accepted. Therefore bounce (NDR) is option, reject is not option. SMTP is store and forward protocol. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 17 01:52:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZhsR-0004N2-VI; Tue, 17 Oct 2006 01:52:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZhsP-0004Ms-Ss for ima@ietf.org; Tue, 17 Oct 2006 01:52:33 -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 1GZhsN-0007fH-Ij for ima@ietf.org; Tue, 17 Oct 2006 01:52:33 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GZhsK-0003G0-4O for ima@ietf.org; Tue, 17 Oct 2006 07:52:28 +0200 Received: from pd9fbacc0.dip0.t-ipconnect.de ([217.251.172.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 07:52:28 +0200 Received: from nobody by pd9fbacc0.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Oct 2006 07:52:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 4.1 - reject Date: Tue, 17 Oct 2006 07:51:42 +0200 Organization: Lines: 24 Message-ID: <45346F6E.752C@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <5d3b9n4m1o.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbacc0.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) 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 Kari Hurtta wrote: > SMTP level reject is possible only when message is not yet accepted. Yes, you can't accept mail unless you know how to report errors later, or you're confident that there won't be any issues with the delivery. > a SMTP connection to next-hop system happens after message is accepted Then you're obviously sure that you can report errors to the originator, e.g. because you have an SPF PASS on the Return-Path, or you're an MSA enforcing submission rights, and similar cases. You cannot accept the message if you don't know the originator. > SMTP is store and forward protocol. And return, that's why it has reverse paths, and stuff like 551 for any mildly dubious cases. It can't work if you accept a mail from:<> and decide to bounce it later (just an example). The environment is about 80% spam plus about 10% misdirected bounces, EAI has no business to make that worse. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 17 02:12:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiBT-0001eP-Il; Tue, 17 Oct 2006 02:12:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiBR-0001dh-Mt for ima@ietf.org; Tue, 17 Oct 2006 02:12:13 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZiA9-00011H-6F for ima@ietf.org; Tue, 17 Oct 2006 02:10:55 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k9H6AdRn029004 for ; Tue, 17 Oct 2006 15:10:39 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 1ac9_3668ebf8_5da6_11db_9438_0014221fa3c9; Tue, 17 Oct 2006 15:10:39 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:59110) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 17 Oct 2006 15:10:24 +0900 Message-Id: <6.0.0.20.2.20061017134156.09d2b7e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 17 Oct 2006 14:02:58 +0900 To: ima@ietf.org From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [EAI] ISSUE: framework 7.1 - change title 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 title of section 7.1 currently reads "Impact on IRIs". This title should be changed to "Impart on URIs" or "Impact on URIs and IRIs". The reason for this is that URIs and IRIs are intricately linked, and that the mailto: URI scheme, not the mailto: IRI scheme (there are not intrinsic IRI schemes) has to be updated. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 17 04:09:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZk0C-0001gK-6b; Tue, 17 Oct 2006 04:08:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZk0A-0001fg-U4 for ima@ietf.org; Tue, 17 Oct 2006 04:08:42 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZjuf-0001iU-Jy for ima@ietf.org; Tue, 17 Oct 2006 04:03:02 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0623D2596C7; Tue, 17 Oct 2006 10:00:24 +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 02907-03; Tue, 17 Oct 2006 10:00:18 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E89E22596EB; Tue, 17 Oct 2006 10:00:17 +0200 (CEST) Message-ID: <45348E2E.1060703@alvestrand.no> Date: Tue, 17 Oct 2006 01:02:54 -0700 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 4.1 - reject References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> In-Reply-To: <45343E6F.6AC4@xyzzy.claranet.de> 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: 856eb5f76e7a34990d1d457d8e8e5b7f 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: > s/bounce/reject/g A "bounce" is commonly understood as sending spam > (unsolicited NDRs) to innocent bystanders as part of a DDoS. while we sometimes bow to "common" usage, I think we should refer to existing RFCs for our terminology in this field. RFC 2821 uses "bounce" a few places, but does not formally define it - it seems to be used as a synonym for the (SMTP-level) "reject"; it refers to a "notification message" for the DSN notification (section 3.7 of 2821). Consistent use of "reject" when SMTP-level reject is intended seems like a good idea to me. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 17 10:00:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUd-000099-50; Tue, 17 Oct 2006 10:00:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpUb-0008W2-Rd for ima@ietf.org; Tue, 17 Oct 2006 10:00:29 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpMT-0002ID-Sf for ima@ietf.org; Tue, 17 Oct 2006 09:52:15 -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.231) id 4534dff1.509e.3bb for ima@ietf.org; Tue, 17 Oct 2006 14:51:45 +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 k9HDpaC2012669 for ; Tue, 17 Oct 2006 14:51:38 +0100 (BST) To: "ima@ietf.org" Subject: Re: message/rfc822 (was: [EAI] text for eai-framework re: 2047+S/MIME) References: <452EAA84.21A2@xyzzy.claranet.de> <5dk634x43z.fsf@Hurtta06k.keh.iki.fi> <452F1FF8.64E5@xyzzy.claranet.de> Message-ID: Date: Tue, 17 Oct 2006 14:51:36 +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.5 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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, 13 Oct 2006 22:29:22 +0100, Philip Guenther wrote: > On Fri, 13 Oct 2006, Charles Lindsey wrote: >> On Fri, 13 Oct 2006 06:11:20 +0100, Frank Ellermann >> wrote: > ... >>> | No encoding other than "7bit", "8bit", or "binary" is permitted for >>> | the body of a "message/rfc822" entity. >> >> Whatever is the reason for that? > > RFC 2045, page 17, final paragraph: > NOTE ON ENCODING RESTRICTIONS: Though the prohibition against using > content-transfer-encodings on composite body data may seem overly > restrictive, it is necessary to prevent nested encodings,... Yes, I agree that nested encodings are to be avoided, certainly in these circumstances. My problem was that I had understood (wrongly as it seems) that ANY CTE was forbidden on composite media types, on the grounds that Q-P and Bas64 were clearly inappropriate, and the other three would produce no semantic effect, even if you wrote them (because you could only write ASCII in those places anyway - but of course we are about to change that). > >> And what if you want to send a message/rfc822 in some charset other >> than ASCII, and your MTA doesn't do 8BITMIME? > > The body of the message/rfc822 can have its own > content-transfer-encoding, which is set by that header field in the > header of the message/rfc822 part itself (as opposed to the MIME header > that wraps the message/rfc822 itself). Yes, I knew that, but I had interpreted the words >>> | No encoding other than "7bit", "8bit", or "binary" is permitted for >>> | the body of a "message/rfc822" entity. as forbidding Q-P and Base64 even in the CTE field of the encapsulated email message itself. Which is clearly stupid. But on re-reading those words, and on reading your paragraph above, I still do not see how I am supposed to read your meaining into what RFC 2046 actually says. -- 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 Oct 17 10:29:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpwI-0001vN-Cg; Tue, 17 Oct 2006 10:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZpwH-0001tW-LE for ima@ietf.org; Tue, 17 Oct 2006 10:29:05 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZpvo-0006ZT-FG for ima@ietf.org; Tue, 17 Oct 2006 10:29:05 -0400 Received: from [10.201.0.58] (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id k9HESIok003439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Oct 2006 07:28:21 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k9HESIok003439 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1161095302; bh=OA3nTRzr6NazkOU3rjS7iQJL1Yo=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=NvdG6FdT2b2okN/3 Qr/IZvfmbMW3JLyHrQ4RPFhXPigulRaP1zMEZJkvVTgVsdD5uLyebC2lZ0bAo225a4h zhequPbTI4Pm399nEImZ9ennPfisfJJ4wgAAYVCS7fqc9+CpSIWfAQqfc+4Esi2VEKi /Rb7OMelaC4LsZAJZcaWk= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k9HESIok003439 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=EwpmtS1dxikMYXdEj5VlG2KSmwBJCZ2M2gOsiBlj3HB198vx5F1T0DIB4w9SlhbdQ Vx/3TcUjdTOeqT5fCiTMy3VP+0v7C1aOi1bmIDVaKmG8FZHMSLOzQoM45I/lbOoy/cT Y24k0V6Zl9d4ZqSyCn/HndEeCPoQ6Znc5ih4RKE= Date: Tue, 17 Oct 2006 08:28:17 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Charles Lindsey Subject: Re: message/rfc822 (was: [EAI] text for eai-framework re: 2047+S/MIME) In-Reply-To: Message-ID: References: <452EAA84.21A2@xyzzy.claranet.de> <5dk634x43z.fsf@Hurtta06k.keh.iki.fi> <452F1FF8.64E5@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "ima@ietf.org" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 17 Oct 2006, Charles Lindsey wrote: > On Fri, 13 Oct 2006 22:29:22 +0100, Philip Guenther > wrote: ... >> The body of the message/rfc822 can have its own content-transfer-encoding, >> which is set by that header field in the header of the message/rfc822 part >> itself (as opposed to the MIME header that wraps the message/rfc822 >> itself). > > Yes, I knew that, but I had interpreted the words > >>>> | No encoding other than "7bit", "8bit", or "binary" is permitted for >>>> | the body of a "message/rfc822" entity. > > as forbidding Q-P and Base64 even in the CTE field of the encapsulated email > message itself. Which is clearly stupid. > > But on re-reading those words, and on reading your paragraph above, I still > do not see how I am supposed to read your meaining into what RFC 2046 > actually says. The phrase <> must be read in the context of the definitions in section 2 of RFC 2045. Looking there we see: 2.4. Entity The term "entity", refers specifically to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity. The specification of such entities is the essence of MIME. Since the contents of an entity are often called the "body", it makes sense to speak about the body of an entity. <...> So, in that phase, "the body" refers to the entire embedded message/rfc822 message and not just the embedded message's body. Okay, so we don't have to do any decoding to obtain access to the embedded message as a whole. However, to interpret that embedded message we have to whip out our handy rfc822 message parser, which may quite naturally notice fields in that message that themselves mark this as a MIME message whose body has some sort of transfer encoding, etc. (I think this is a good example of why examples are important. This confused the heck out of me when I first read RFC 1521...until I saw the examples, at which point the words in my mind stopped tumbling and started dancing.) Philip Guenther _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 04:33:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6rh-0001pZ-6X; Wed, 18 Oct 2006 04:33:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6rg-0001pU-MW for ima@ietf.org; Wed, 18 Oct 2006 04:33:28 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ga6ra-00086N-IV for ima@ietf.org; Wed, 18 Oct 2006 04:33:28 -0400 Received: (snipe 1048 invoked by uid 0); 18 Oct 2006 17:34:19 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.266095 secs); Received: from unknown (HELO ?192.168.10.175?) (ZC/?own@210.107.250.150) by unknown with SMTP; 18 Oct 2006 17:34:19 +0900 X-RCPTTO: nobody@xyzzy.claranet.de, ima@ietf.org Message-ID: <4535E6D9.4040201@icu.ac.kr> Date: Wed, 18 Oct 2006 17:33:29 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 5 - delivery to final delivery MTA References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> In-Reply-To: <453443FC.4A2F@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: > A "delivery to the final delivery MTA" is confusing, should that be > a "delivery by the final delivery MTA", or a "forward to the" MDA ? > > Maybe replace "or after delivery to the final delivery MTA" by > "or at final delivery by the MDA" (acronym introduced in section 3). In this context, "delivery" is read, at least by me, as the transmission of data using SMTP. Then, the final delivery MTA do *NOT* deliver messages any more. It just does something else such as saving to storage that is not defined in SMTP. If "delivery" includes "something else", we need to define what are included in delivery and what not. > > 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 Oct 18 06:08:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga8LA-0005jh-L8; Wed, 18 Oct 2006 06:08:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga8L8-0005ja-N0 for ima@ietf.org; Wed, 18 Oct 2006 06:07:58 -0400 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga8L7-00026j-2X for ima@ietf.org; Wed, 18 Oct 2006 06:07:58 -0400 Received: from [211.72.211.94] (pc094.twnic.net.tw [211.72.211.94]) (authenticated bits=0) by twnic.net.tw (8.13.8/8.13.8) with ESMTP id k9IA7Yal028006; Wed, 18 Oct 2006 18:07:35 +0800 Message-ID: <4535FF81.8080305@twnic.net.tw> Date: Wed, 18 Oct 2006 18:18:41 +0800 From: Jeff User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] draft-ietf-eai-utf8headers-01.txt / draft-ietf-eai-downgrade-02.txt suggestion References: <200610141148.k9EBm7BU013167@Hurtta06k.keh.iki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Thanks for your comment Charles. I was fail to catch up with the mailing list. I'll fix those editorial update that you mentioned on the previous post ("Comments on draft-ietf-eai-utf8headers-01.txt"). Sorry for late reply. If I miss something, please do remind me. Thank you. Charles Lindsey wrote: > On Sat, 14 Oct 2006 12:48:07 +0100, Kari Hurtta > wrote: > >> draft-ietf-eai-utf8headers-01.txt: >> >> header-content = "UTF8SMTP:" [FWS] content-code [FWS] >> *( ";" parameter ) CRLF >> content-code = "UTF8" / "ASCII" / "Downgraded" >> parameter = "Header-Language:" [FWS] Language-List >> Language-List = Language-Tag [FWS] >> *("," [FWS] Language-Tag [FWS]) >> >> >> following was suggested: >> >> header-content = "Header-Type:" [FWS] content-code [FWS] >> *( ";" parameter ) CRLF >> >> ; parameter is defined on RFC 2045 >> >> content-code = "UTF8SMTP" / "ASCII" / "Downgraded" > > Yes, that was my suggestion, posted here on 31st August when > commenting on eai-utf8headers-01. It looks like you, myself, and Frank > now prefer the new header to be called "Header-Type". The reason the > content-code is "UTF8SMTP" rather than "UTF8" was to make it the same > as the capability to be returned by the EHLO command (no point in > inventing more than one keyword for the same concept). Not that I > particularly like "UTF8SMTP" (because these new messages might also be > handled by other transports such as UUCP and NNTP), but that is a > separate issue. I'm good with this propose. Will put like following. header-content = "Header-Type:" [FWS] content-code [FWS] *( ";" parameter ) CRLF ; parameter is defined on RFC 2045 content-code = "UTF8" / "ASCII" / "Downgraded" header-language-value = DQUOTE Language-Tag [FWS] *("," [FWS] Language-Tag [FWS]) DQUOTE ; Language-Tag is defined in RFC4646 required-fields-value = field-name [FWS] *("," [FWS] field-name [FWS]) ; the term is defined in RFC 2822 Hopefully can get a updated version out before the cut-off date. Jeff -TWNIC _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 06:26:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga8cu-0000TH-Fe; Wed, 18 Oct 2006 06:26:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga8c6-0008Kz-75 for ima@ietf.org; Wed, 18 Oct 2006 06:25:30 -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 1Ga8NH-0002Fk-3p for ima@ietf.org; Wed, 18 Oct 2006 06:10:14 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ga8N2-0000Z0-Rx for ima@ietf.org; Wed, 18 Oct 2006 12:09:56 +0200 Received: from pd9fba942.dip0.t-ipconnect.de ([217.251.169.66]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Oct 2006 12:09:56 +0200 Received: from nobody by pd9fba942.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Oct 2006 12:09:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 5 - delivery to final delivery MTA Date: Wed, 18 Oct 2006 12:08:25 +0200 Organization: Lines: 30 Message-ID: <4535FD19.169A@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4535E6D9.4040201@icu.ac.kr> 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: pd9fba942.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) 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 Yangwoo Ko wrote: > In this context, "delivery" is read, at least by me, as the > transmission of data using SMTP. Then, the final delivery > MTA do *NOT* deliver messages any more. It just does something > else such as saving to storage that is not defined in SMTP. > If "delivery" includes "something else", we need to define > what are included in delivery and what not. I read it like you said. But I thought that "deliver" actually is "something else", whatever MDAs do, excluding forward / reject. Apparently RFC 4496 uses it this way: | In the destination email server, a mail delivery agent (MDA) may | deliver the email to the recipient's mailbox. The email client | program of the recipient might use a different protocol (such as the | Post Office Protocol version 3 (POP3) or IMAP) to access the mailbox | and retrieve/read the messages. RFC 2821 apparently uses "deliver" depending on the context, sometimes it's "whatever happens between MX and message store", and sometimes it is about the final "delivery" MTA (still getting a chance to reject or forward instead of "deliver"). Maybe it's not important, but this "delivery to final delivery MTA" confused me, it's about input to an MDA, not about output from an MDA. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 06:26:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga8cw-0000Uw-UB; Wed, 18 Oct 2006 06:26:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga8c3-0008Gp-9b for ima@ietf.org; Wed, 18 Oct 2006 06:25:27 -0400 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga8QE-0002Vi-2q for ima@ietf.org; Wed, 18 Oct 2006 06:13:15 -0400 Received: from [211.72.211.94] (pc094.twnic.net.tw [211.72.211.94]) (authenticated bits=0) by twnic.net.tw (8.13.8/8.13.8) with ESMTP id k9IADBHu000346; Wed, 18 Oct 2006 18:13:12 +0800 Message-ID: <453600D2.3040105@twnic.net.tw> Date: Wed, 18 Oct 2006 18:24:18 +0800 From: Jeff User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-01.txt question References: <200610140936.k9E9aUKl012886@Hurtta06k.keh.iki.fi> In-Reply-To: <200610140936.k9E9aUKl012886@Hurtta06k.keh.iki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: EAI mailing list 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: > draft-ietf-eai-utf8headers-01.txt: > > angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] > > alt-address = "{" [CFWS] addr-spec [CFWS] "}" > > > "{" adn "}" are on utf8-addr-spec and addr-spec because they > are on atext and utf8-atext. > > Alternatively "{" need to be changed to " { " and "}" to " } ". Thanks for your comment. How about use "[" and "]" as the bracket? This was discussed before. (Thanks Charles and Tony.) That is : alt-address = "[" [CFWS] addr-spec [CFWS] "]" Jeff -TWNIC _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 11:37:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDTC-0001uM-SN; Wed, 18 Oct 2006 11:36:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDTB-0001uG-G3 for ima@ietf.org; Wed, 18 Oct 2006 11:36: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 1GaDT6-00067y-RK for ima@ietf.org; Wed, 18 Oct 2006 11:36:37 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GaDT5-000DxC-Pz; Wed, 18 Oct 2006 11:36:32 -0400 Date: Wed, 18 Oct 2006 11:36:30 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] ISSUE: framework 5 - delivery to final delivery MTA Message-ID: In-Reply-To: <4535FD19.169A@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4535E6D9.4040201@icu.ac.kr> <4535FD19.169A@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 18 October, 2006 12:08 +0200 Frank Ellermann wrote: > Yangwoo Ko wrote: > >> In this context, "delivery" is read, at least by me, as the >> transmission of data using SMTP. Then, the final delivery >> MTA do *NOT* deliver messages any more. It just does something >> else such as saving to storage that is not defined in SMTP. > >> If "delivery" includes "something else", we need to define >> what are included in delivery and what not. > > I read it like you said. But I thought that "deliver" > actually is "something else", whatever MDAs do, excluding > forward / reject. Apparently RFC 4496 uses it this way: > > | In the destination email server, a mail delivery agent (MDA) > may | deliver the email to the recipient's mailbox. The email > client | program of the recipient might use a different > protocol (such as the | Post Office Protocol version 3 (POP3) > or IMAP) to access the mailbox | and retrieve/read the > messages. Let's be a little careful here. Informational documents don't count in this context and 4496 is particularly problematic. You need to pull definitions from either local materials or from 2821. > RFC 2821 apparently uses "deliver" depending on the context, > sometimes it's "whatever happens between MX and message > store", and sometimes it is about the final "delivery" MTA > (still getting a chance to reject or forward instead of > "deliver"). The intent was to be very consistent: the "final delivery MTA" is the one that does not relay or gateway further, which (important for our purposes) is also the host that controls and interprets local-parts of addresses. It may still, as you note, bounce -- the most obvious case is the only in which it discovers that the address (which, again, only it can interpret) does not exist. "Delivery" is what that MTA does (assuming it does not bounce or otherwise reject the message). If that is not clear in 2821, clarifying text would be welcomed as a contribution to my file of things to do if I can ever open 2821bis again without being overwhelmed by people who feel a need to make basic changes to the protocol and its requirements. > Maybe it's not important, but this "delivery to final delivery > MTA" confused me, it's about input to an MDA, not about output > from an MDA. I think that is the language 2821 uses, which doesn't necessarily make it clear (see above). Consider A X B Message from ---> SMTP ----> Whatever else network Server/MTA happens "Delivery to the final delivery MTA" refers to the SMTP transaction at A, with X acting as an SMTP server. B is not normally an SMTP transaction. If it is, then X is probably not the "final delivery MTA". If there is such a thing as an MDA (remember, 2821 doesn't use that term), then it is part of "whatever else happens" and the mechanism for getting things to it, B, is, as far as the SMTP final delivery operation is concerned, just part of "whatever else". Again, if that isn't clear, then the framework doc isn't where it needs to be fixed. It needs to be fixed by an update (or at least errata) to 2821. Text welcome. Drawing from your earlier note... > Maybe replace "or after delivery to the final delivery MTA" by > "or at final delivery by the MDA" (acronym introduced in > section 3). No. That change -- moving the delivery point from the A -> MTA transaction to the MTA-> B or B-> whatever-else transactions-- would, IMO, make things worse and cause other complications. We should adjust that non-definition ("sometimes called" is not a definition as far as I'm concerned) and "after... successfully received" is important, and consistent with the comments above, but it doesn't change things. Keep in mind that a final delivery MTA may, in practice, simply store the message somewhere without additional processing and without invoking anything that could properly be called another agent. Proposed substitute text for section 3, bullet 3... old: or after the mail has successfully been received by a final delivery SMTP server (sometimes called an "MDA") involve different... Section 5, below. new: or after the mail has successfully been received by a final delivery SMTP server involve different... Section 5, below. Processing that occurs after such final delivery, primarily that involved with the delivery to a mailbox or message store is sometimes called "Message Delivery" processing and the conceptual process that performs it is sometimes called an "MDA". Improvements welcome. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 12:00:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDq0-0002V5-Oy; Wed, 18 Oct 2006 12:00:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDpa-0001HB-8Q for ima@ietf.org; Wed, 18 Oct 2006 11:59:46 -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 1GaDiQ-0001dF-7u for ima@ietf.org; Wed, 18 Oct 2006 11:52:24 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GaDiP-000E5k-Dy; Wed, 18 Oct 2006 11:52:21 -0400 Date: Wed, 18 Oct 2006 11:52:20 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] ISSUE: framework -3 - missing MIME considerations Message-ID: In-Reply-To: <45343AE1.5F1C@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (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: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 17 October, 2006 04:07 +0200 Frank Ellermann wrote: > The "document plan" in chapter 3 tries to get away with > updating 2822 in the utf8headers I-D. That's not good enough > for some darker corners of MIME like UTF-8 in comments in > Content-* header fields or preambles. It was not the intent to "get away with" anything, but to localize _all_ of those issues into the utf8headers document. Suggestions for better wording would be appreciated. > The utf8headers I-D must explain why a new message subtype > (different from rfc822) isn't desirable, why using > message/rfc822 with UTF-8 headers won't cause havoc, and how > it might affect application/mbox. Agreed to all but the last. Application/mbox is an Informational RFC; taking on the job of explaining the impact on non-standard headers makes the job of this WG impossible. If you think application/mbox needs to be considered explicitly, please initiate an effort to get it onto the standards track (start with a conversation with the author). Of course, it such an effort were initiated now, I assume the ADs would refer it to this WG for comment about its impact on our work :-(. My impression, incidentally, is that there is growing consensus that message/rfc822 cannot be used to encapsulate messages with UTF-* headers. I hope that the UTF8Headers document will say that and explain why. I'm trying to get a separate draft written (by someone else -- the lucky party is free to identify himself) to describe/propose a header structure that would be suitable for such encapsulation, but it is not, at present, in this WG's charter or critical path. > The "document plan" should note this - a separate draft for > MIME issues (separated from the utf8headers I-D) would be too > confusing. Interesting. Certainly we have different documents for 2822 and for "MIME issues" in the existing, ASCII-header, world. But I would be interested in seeing the sort of note that you propose. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 12:31:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEJk-00028G-7q; Wed, 18 Oct 2006 12:30:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEJi-00024B-Kq for ima@ietf.org; Wed, 18 Oct 2006 12:30:54 -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 1GaEJ3-0002Wg-Hp for ima@ietf.org; Wed, 18 Oct 2006 12:30:54 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GaEJ2-000EW7-0d; Wed, 18 Oct 2006 12:30:12 -0400 Date: Wed, 18 Oct 2006 12:30:11 -0400 From: John C Klensin To: Harald Alvestrand , Frank Ellermann Subject: Re: [EAI] ISSUE: framework 4.1 - reject Message-ID: <6C50875B746DB0E507B47392@p3.JCK.COM> In-Reply-To: <45348E2E.1060703@alvestrand.no> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> X-Mailer: Mulberry/4.0.6 (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: 287c806b254c6353fcb09ee0e53bbc5e 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 Tuesday, 17 October, 2006 01:02 -0700 Harald Alvestrand wrote: > Frank Ellermann wrote: >> s/bounce/reject/g A "bounce" is commonly understood as >> sending spam (unsolicited NDRs) to innocent bystanders as >> part of a DDoS. > while we sometimes bow to "common" usage, I think we should > refer to existing RFCs for our terminology in this field. > > RFC 2821 uses "bounce" a few places, but does not formally > define it - it seems to be used as a synonym for the > (SMTP-level) "reject"; it refers to a "notification message" > for the DSN notification (section 3.7 of 2821). > > Consistent use of "reject" when SMTP-level reject is intended > seems like a good idea to me. The intent of "bounce" in 2821 was to include both an SMTP transaction-time rejection (which, by the way, includes rejection after receiving DATA, giving the intermediate go-ahead, and receiving the closing CRLF.CRLF) _and_ generation of a notification message. That is consistent with usage in place long before 2821 was written, usage that way partially driven by the fact that, if A, B, and C are SMTP servers, such that the message travels SubmissionMUA -> A -> B -> C under normal circumstances (see below), if C rejects the message coming from B (e.g., issues a 5yz response to a MAIL or RCPT command), B is going to need to generate a notification message to A: C has no control over whether A, or for that matter the user of the SubmissionMUA, sees an SMTP rejection or a notification message. The use of the term "bounce" for the case Frank describes is a recent innovation and, while it may be commonly understood in some communities, it is not the [only] common usage. Extending Frank's suggestion slightly to imply that NDNs are obsolete and should be generally considered spam would change the whole Internet mail model from "delivery is assumed unless notified" to "delivery should not be assumed unless explicitly confirmed". That would be a major step; I don't see the community as being willing to accept it, at least yet, but, in any event, these documents are not the right place for that debate, IMO. Clarifying in "framework" that the 2821 usage (i.e., both rejections and notifications) is intended would be reasonable. Text welcome. In the same thread, Kari wrote... (quoting from "framework") >> If the message cannot be forwarded because the next-hop >> system cannot accept the extension and insufficient >> information is available to reliably downgrade it, it >> MUST be bounced. Note that knowing whether the next-hop system can "accept the extension" does not require that anyone accept the message. One knows that the extension is not acceptable as soon as the next-hop host responds to EHLO. > On generally smtp level reject is not possible on here. SMTP > level reject is possible only when message is not yet accepted. Yes. > And a SMTP connection to next-hop system happens after message > is accepted. Therefore bounce (NDR) is option, reject is not > option. Actually, this is the normal case, but is not required. In principle, the following model is consistent with SMTP. Given servers A, B, and C, the following sequence of events is possible and permitted: A opens connection to B A->B: EHLO [...] B->A: (response) A->B: MAIL FROM: [...] B->A: 220 ok A->B: RCPT TO: B opens connection to C B->C: EHLO [...] C->B: (response) B->C: MAIL FROM: [...] C->B: 220 ok B->C: RCPT TO: C->B: 550 Not here, please go away and don't come back B->A: 550 user not at C A->B: QUIT B->C: QUIT and so on. There have actually been proposals that would require doing things this way. They haven't gone anywhere for reasons that should be obvious, but the sequence is permitted by all of the relevant protocol specifications. > SMTP is store and forward protocol. Yes. But while overlapping receipt and forwarding is rare, it is not prohibited. john john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 12:33:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaELr-0004F3-PL; Wed, 18 Oct 2006 12:33:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaELq-0004Eq-CD for ima@ietf.org; Wed, 18 Oct 2006 12:33:06 -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 1GaELH-00035t-MB for ima@ietf.org; Wed, 18 Oct 2006 12:33:06 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GaELH-000EXJ-6v; Wed, 18 Oct 2006 12:32:31 -0400 Date: Wed, 18 Oct 2006 12:32:30 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] ISSUE: framework 6 - delete section Message-ID: <682A932E049D20A39E8D1B2F@p3.JCK.COM> In-Reply-To: <453445CC.7F86@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <453445CC.7F86@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (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: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 17 October, 2006 04:54 +0200 Frank Ellermann wrote: > The complete I-D is about I18N, it doesn't need this redundant > section. This section is an IESG requirement. Take it up with the rule-makers and nit-pickers. Perhaps it can be made to disappear when/if the document goes to the RFC Editor. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 12:53:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEfT-0006VZ-Hg; Wed, 18 Oct 2006 12:53:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEfS-0006T3-Fy for ima@ietf.org; Wed, 18 Oct 2006 12:53:22 -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 1GaEfR-00082O-1O for ima@ietf.org; Wed, 18 Oct 2006 12:53:22 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GaEfQ-000Eky-EZ; Wed, 18 Oct 2006 12:53:20 -0400 Date: Wed, 18 Oct 2006 12:53:19 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] ISSUE: framework 10 - too long Message-ID: <5347C4027E5AB2D2736FE2E2@p3.JCK.COM> In-Reply-To: <45344BA4.3A73@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45344BA4.3A73@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (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: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 17 October, 2006 05:19 +0200 Frank Ellermann wrote: > IMO a pointer to IDN (especially 4690) is good enough, there's > nothing special to say about confusable characters in local > parts. An additional pointer to 4690 has been inserted in the Security Considerations section. See below. > The reference to [Net-Unicode] should be deleted, that I-D is > rather unclear at the moment, apparently it talks about telnet > and not SMTP, discussing the merits of various ASCII control > characters like TAB. RFC 3552 requires a fairly comprehensive security analysis. Since there have been particular concerns raised about whether these extensions are possible without introducing new security surprises, a fairly extensive analysis seems to be in order. These references are informative and intended to be present in a "for additional reading" context, not to force the user to chase back and forth through a large collection of documents to gain an understanding of the security issues (a practice that 3552 essentially prohibits, at least as I read it). There actually are confusable character issues here that are different from the IDNA ones: IDNA essentially operates in lower case: even though upper case characters can be mapped to lower ones, there seems to be general agreement that it is better to always display characters in lower case since, in general, the lower-case forms are more often distinguishable. But email local parts are case-sensitive, so that particular beneficial trick doesn't work. As far as Net-Unicode is concerned, I share your unease about referencing it. But SMTP, classically, is defined in terms of a Telnet transport, so that document is not completely irrelevant. More important, before the appearance of draft-klensin-idnabis-issues-00 and draft-alvestrand-idnabis-bidi-00 this week, Net-Unicode was the only document in the IETF space that even attempted to discuss the string handling issues relevant to i18nemail... and the two or three draft-...-idnabis-... documents are _very_ IDN-specific. In case it is relevant, Net-Unicode has not been abandoned and won't be. I've put it on hold until some of the issues with Unicode, and particularly NFC (which it requires) are resolved. And, while it falls belong the level of detail in "framework" (i.e., any discussion probably belongs in "smtpext") and I have argued against it before, issues involving transformations by operating systems or intermediate-level transport that SMTP and MUA implementations can't control may require use to require, or make some very strong suggestions about, normalized local-parts on much the same basis that we make special provisions for blank-padded lines in messages. On the other hand, if the Net-Unicode draft is actually unclear, I'd appreciate pointers to specific text that needs to be clarified. > "impact any systems or mechanisms that is dependent" - should > that be "are dependent" or "depend" ? Fixed. Thanks. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 12:54:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEga-0007Bz-Td; Wed, 18 Oct 2006 12:54:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEgZ-0007AX-Il for ima@ietf.org; Wed, 18 Oct 2006 12:54:31 -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 1GaEgY-0008EL-AW for ima@ietf.org; Wed, 18 Oct 2006 12:54:31 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GaEgX-000Elb-4p; Wed, 18 Oct 2006 12:54:29 -0400 Date: Wed, 18 Oct 2006 12:54:28 -0400 From: John C Klensin To: Martin Duerst , ima@ietf.org Subject: Re: [EAI] ISSUE: framework 7.1 - change title Message-ID: <0327B69AA5387EA94FE08D4F@p3.JCK.COM> In-Reply-To: <6.0.0.20.2.20061017134156.09d2b7e0@localhost> References: <6.0.0.20.2.20061017134156.09d2b7e0@localhost> X-Mailer: Mulberry/4.0.6 (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: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 17 October, 2006 14:02 +0900 Martin Duerst wrote: > The title of section 7.1 currently reads "Impact on IRIs". > This title should be changed to "Impart on URIs" or > "Impact on URIs and IRIs". The reason for this is that > URIs and IRIs are intricately linked, and that the mailto: > URI scheme, not the mailto: IRI scheme (there are not > intrinsic IRI schemes) has to be updated. Good catch. Sorry. It has been fixed in -03. thanks, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 12:59:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaElK-0000ik-Nk; Wed, 18 Oct 2006 12:59:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaElI-0000ib-Vu for ima@ietf.org; Wed, 18 Oct 2006 12:59:24 -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 1GaElG-0000aW-MJ for ima@ietf.org; Wed, 18 Oct 2006 12:59:24 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GaElG-000Eom-87; Wed, 18 Oct 2006 12:59:22 -0400 Date: Wed, 18 Oct 2006 12:59:21 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] ISSUE: framework 13 - nits Message-ID: In-Reply-To: <45344E1D.160@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45344E1D.160@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (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 Tuesday, 17 October, 2006 05:29 +0200 Frank Ellermann wrote: > s/[DKIM-Charter]/[draft-ietf-dkim-base] + > [draft-ietf-dkim-overview]/ > > The DKIM-threats, SSP-requirements, and SSP-proper texts are > not directly affected (unless SSP tries "per user policies", > unclear). ~~~ end ~~~ > > I've changed my mind, [DKIM Charter] is okay, the details are > not relevant. The reason for referencing the charter was to avoid getting involved in race conditions between the two WGs. Adds nothing and makes things hard. So I'm glad you changed your mind. > But please replace [RFC2663] by [RFC2633] or > better by [RFC3851] ;-) Sorry -- don't know how that got by us, unless we copied a typo out of a message or I was suffering from late-night stupidity. Reference corrected to 3851. thanks, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 13:08:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEuX-0006B8-Iu; Wed, 18 Oct 2006 13:08:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEuW-0006Ay-Q5 for ima@ietf.org; Wed, 18 Oct 2006 13:08:56 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaEuL-0002l6-1K for ima@ietf.org; Wed, 18 Oct 2006 13:08:56 -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.232) id 45365f9b.87c1.10 for ima@ietf.org; Wed, 18 Oct 2006 18:08:43 +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 k9IH8caF007636 for ; Wed, 18 Oct 2006 18:08:39 +0100 (BST) To: "ima@ietf.org" Subject: Re: [EAI] ISSUE: framework -3 - missing MIME considerations References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> Message-ID: Date: Wed, 18 Oct 2006 18:08:38 +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.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 18 Oct 2006 16:52:20 +0100, John C Klensin wrote: > My impression, incidentally, is that there is growing consensus > that message/rfc822 cannot be used to encapsulate messages with > UTF-* headers. Well I see no such growing consensus, and if there is, then you can count me out of it. I have always assumed (and have often posted comments implying that assumption) that (an extended) message/rfc822 was indeed the right tool to encapsulate messages with UTF-* headers, most likely with the restriction that any email containing it would have to be designated a UTF8SMTP object itself (by inclusion of Header-Type: UTF8SMTP), with a consequent obligation to downgrade the contained message/rfc822 (or else bounce). -- 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 Oct 18 13:12:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaExt-0007sJ-Fd; Wed, 18 Oct 2006 13:12:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaExs-0007sE-I9 for ima@ietf.org; Wed, 18 Oct 2006 13:12:24 -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 1GaExr-0003aa-9T for ima@ietf.org; Wed, 18 Oct 2006 13:12:24 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GaExq-000Euu-Sw; Wed, 18 Oct 2006 13:12:23 -0400 Date: Wed, 18 Oct 2006 13:12:22 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] ISSUE: framework 7 - missing local part (ab)uses as label Message-ID: <5DAAD30D180E1A4125249F98@p3.JCK.COM> In-Reply-To: <453446AA.739F@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <453446AA.739F@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (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: 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 --On Tuesday, 17 October, 2006 04:57 +0200 Frank Ellermann wrote: > For chapter 7 I propose to add a new subsection about any > "local part transformation" schemes like SES, SRS, BATV, or > SPF per-user-policies (or other uses of its %{l} macro as > domain label, %{l} = "local part") Frank, I don't see any way to do this without opening the same set of problems as trying to describe, in specific terms, what to do with non-standard headers. But I don't know what you have in mind, so please supply specific draft text so that the WG can look at it. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 13:37:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFLb-00045P-El; Wed, 18 Oct 2006 13:36:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFLa-00045E-7s for ima@ietf.org; Wed, 18 Oct 2006 13:36:54 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GaFLS-0000cC-M9 for ima@ietf.org; Wed, 18 Oct 2006 13:36:54 -0400 Received: (qmail invoked by alias); 18 Oct 2006 17:36:44 -0000 Received: from dslb-088-064-166-024.pools.arcor-ip.net (EHLO hive) [88.64.166.24] by mail.gmx.net (mp015) with SMTP; 18 Oct 2006 19:36:44 +0200 X-Authenticated: #723575 From: Bjoern Hoehrmann To: ima@ietf.org Date: Wed, 18 Oct 2006 19:36:45 +0200 Message-ID: <1bpcj2tv0qfiolnk4l38dlbfusdbsm6blr@hive.bjoern.hoehrmann.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [EAI] ISSUE: framework 10 - "UTF-8 canonicalization" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hi, Section 10 has "... and, potentially, some issues with UTF-8 canonicalization, discussed in [RFC3629]." RFC 3629 does not use the term "canonicalization" and I am not sure what that would be. I could imagine this refers to Unicode Normalization, or handling of malformed UTF-8 sequences, or something else, and technically the term does not really make sense to me. regards, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 13:44:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFSW-00060p-EI; Wed, 18 Oct 2006 13:44:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFSV-00060j-Db for ima@ietf.org; Wed, 18 Oct 2006 13:44:03 -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 1GaFSU-0001zm-4p for ima@ietf.org; Wed, 18 Oct 2006 13:44:03 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GaFST-000FFv-G5; Wed, 18 Oct 2006 13:44:01 -0400 Date: Wed, 18 Oct 2006 13:44:00 -0400 From: John C Klensin To: Bjoern Hoehrmann , ima@ietf.org Subject: Re: [EAI] ISSUE: framework 10 - "UTF-8 canonicalization" Message-ID: <40D430B2EFC0BA1A6B79D7DA@p3.JCK.COM> In-Reply-To: <1bpcj2tv0qfiolnk4l38dlbfusdbsm6blr@hive.bjoern.hoehrmann.de> References: <1bpcj2tv0qfiolnk4l38dlbfusdbsm6blr@hive.bjoern.hoehrmann.de> X-Mailer: Mulberry/4.0.6 (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: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 18 October, 2006 19:36 +0200 Bjoern Hoehrmann wrote: > Hi, > > Section 10 has "... and, potentially, some issues with UTF-8 > canonicalization, discussed in [RFC3629]." RFC 3629 does not > use the term "canonicalization" and I am not sure what that > would be. I could imagine this refers to Unicode > Normalization, or handling of malformed UTF-8 sequences, or > something else, and technically the term does not really make > sense to me. It should have been "normalization and other transformations" or words to that effect, but I've rewritten those sentences to make them more clear and more precise. thanks. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 14:05:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFmx-0001y7-C1; Wed, 18 Oct 2006 14:05:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFmv-0001vf-JZ for ima@ietf.org; Wed, 18 Oct 2006 14:05:09 -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 1GaFmm-00069s-Ji for ima@ietf.org; Wed, 18 Oct 2006 14:05:09 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GaFmX-0008Dn-5a for ima@ietf.org; Wed, 18 Oct 2006 20:04:45 +0200 Received: from 212.82.251.28 ([212.82.251.28]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Oct 2006 20:04:45 +0200 Received: from nobody by 212.82.251.28 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Oct 2006 20:04:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 5 - delivery to final delivery MTA Date: Wed, 18 Oct 2006 20:00:58 +0200 Organization: Lines: 95 Message-ID: <45366BDA.63B2@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4535E6D9.4040201@icu.ac.kr> <4535FD19.169A@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.28 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > You need to pull definitions from either local materials or > from 2821. We could try this one: | When the receiver-SMTP makes the "final delivery" of a | message it inserts at the beginning of the mail data a | return path line. The return path line preserves the | information in the from the MAIL command. | Here, final delivery means the message leaves the SMTP | world. Normally, this would mean it has been delivered to | the destination user, but in some cases it may be further | processed and transmitted by another mail system. > If that is not clear in 2821 It's in parts verbatim the same as in a paragraph on page 50 of that PS, starting with "when the delivery-SMTP server"... and later "final delivery means the message has left the SMTP environment. Normally, this would mean it had been" etc. > if I can ever open 2821bis again without being overwhelmed > by people who feel a need to make basic changes to the > protocol and its requirements. The original protocol design and its requirements are fine - no decent system could accept any mail for forwarding without a plan how to return possible error reports later. Do you want some text clarifying that fundamental point, maybe some MUSTard that "as indicated by the reverse-Path" actually means "at this point you're almost sure or almost dead", with blow by blow quotes from 821 ? > A X B > Message from ---> SMTP ----> Whatever else > network Server/MTA happens > "Delivery to the final delivery MTA" refers to the SMTP > transaction at A, with X acting as an SMTP server. Yes, but it's IMO unusual to say "delivery" for this last hop, if the word "delivery" is often used for "X decides to try B", i.e. note the reverse-path in a Return-Path and call mailx or whatever else happens. > If there is such a thing as an MDA (remember, 2821 doesn't > use that term), then it is part of "whatever else happens" I'd say the X in your figure is the MDA. And also an MX, it is talking with unknown strangers ("from network"). That's too simple, all kinds of ugly problems can be avoided if MX and MDA are the same MTA, we need one hop more to make that obvious: smtp smtp not smtp Message from -----> MX -----> MDA ---------> Message store network (MTA) (MTA) (MTA) (or whatever) The rightmost MTA is the final delivery MTA, and that beast is known as MDA. With issues like "reject unknown address", forcing the MX to send an error report if it already accepted this mail. Or "decide that downgrade won't work and reject", with the same outcome. > if that isn't clear, then the framework doc isn't where it > needs to be fixed. It needs to be fixed by an update (or > at least errata) to 2821 Actually I think it's clear in the text, but I arrive at a slightly different picture, more like the RFC 4496 figure 2. > a final delivery MTA may, in practice, simply store the > message somewhere without additional processing Yes, I see MDA as synonym / shorthand for final delivery MTA, apparently you think it's some later agent. > new: > or after the mail has successfully been received by a > final delivery SMTP server involve different... Section > 5, below. Processing that occurs after such final > delivery, primarily that involved with the delivery to a > mailbox or message store is sometimes called "Message > Delivery" processing and the conceptual process that > performs it is sometimes called an "MDA". I think the old text is correct, not this version. We can just delete the "MDA" acronym, using your text up to "below", without the "Processing that" etc. If anything goes wrong after the final delivery it's too late for UTF8SMTP and a job for RFC 3834. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 14:08:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFq0-0004LP-99; Wed, 18 Oct 2006 14:08:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFpz-0004K7-26 for ima@ietf.org; Wed, 18 Oct 2006 14:08:19 -0400 Received: from ppsw-4.csi.cam.ac.uk ([131.111.8.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaFpv-0006v6-OU for ima@ietf.org; Wed, 18 Oct 2006 14:08:19 -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]:44059) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1GaFph-0004pS-E3 (Exim 4.63) (return-path ); Wed, 18 Oct 2006 19:08:01 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1GaFph-0005Vj-9r (Exim 4.54) (return-path ); Wed, 18 Oct 2006 19:08:01 +0100 Date: Wed, 18 Oct 2006 19:08:01 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin Subject: Re: [EAI] ISSUE: framework 5 - delivery to final delivery MTA In-Reply-To: Message-ID: References: <45339923.8030900@alvestrand.no> <453443FC.4A2F@xyzzy.claranet.de> <4535E6D9.4040201@icu.ac.kr> <4535FD19.169A@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Wed, 18 Oct 2006, John C Klensin wrote: > > The intent was to be very consistent: the "final delivery MTA" > is the one that does not relay or gateway further, which > (important for our purposes) is also the host that controls and > interprets local-parts of addresses. Other preceding relays may also control and interpret local parts, e.g. an incoming border gateway MTA that knows which users are on different internal email servers. Otherwise I agree with your message. Tony. -- f.a.n.finch http://dotat.at/ FORTIES CROMARTY FORTH: SOUTHERLY 6 TO GALE 8, DECREASING 5 OR 6 LATER. RAIN OR SHOWERS. MODERATE OR GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 14:09:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFql-0004QL-N7; Wed, 18 Oct 2006 14:09:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaFqk-0004QG-Mp for ima@ietf.org; Wed, 18 Oct 2006 14:09:06 -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 1GaFqj-00073V-4B for ima@ietf.org; Wed, 18 Oct 2006 14:09:06 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GaFqe-000FWa-W6; Wed, 18 Oct 2006 14:09:01 -0400 Date: Wed, 18 Oct 2006 14:09:00 -0400 From: John C Klensin To: Jeff , Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-01.txt question Message-ID: In-Reply-To: <453600D2.3040105@twnic.net.tw> References: <200610140936.k9E9aUKl012886@Hurtta06k.keh.iki.fi> <453600D2.3040105@twnic.net.tw> X-Mailer: Mulberry/4.0.6 (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: cab78e1e39c4b328567edb48482b6a69 Cc: EAI mailing list X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 18 October, 2006 18:24 +0800 Jeff wrote: > > > Kari Hurtta wrote: >> draft-ietf-eai-utf8headers-01.txt: >> >> angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] >> ">" [CFWS] >> >> alt-address = "{" [CFWS] addr-spec [CFWS] "}" >> >> >> "{" adn "}" are on utf8-addr-spec and addr-spec because they >> are on atext and utf8-atext. >> >> Alternatively "{" need to be changed to " { " and "}" to " >> } ". > Thanks for your comment. > How about use "[" and "]" as the bracket? > This was discussed before. (Thanks Charles and Tony.) > That is : > alt-address = "[" [CFWS] addr-spec [CFWS] "]" Hi. Maybe it is no longer relevant today, but "[" and "]" were excluded from the original characters permitted in email addresses (and lots of other places) because it is in a national-use position in ISO 646 BV. Should it displayed by an ISO 646 rendering engine in a country that uses those positions, the output could be very strange indeed (the UTF-8 showing up as boxes or question-marks and the brackets and nationally-selected characters). It may still be a good choice, but we should understand the implications of what we are doing. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 14:57:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaGbh-0005ol-Ao; Wed, 18 Oct 2006 14:57:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaGbg-0005og-35 for ima@ietf.org; Wed, 18 Oct 2006 14:57:36 -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 1GaGbe-0007AM-An for ima@ietf.org; Wed, 18 Oct 2006 14:57:36 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GaGbY-000G20-VO; Wed, 18 Oct 2006 14:57:29 -0400 Date: Wed, 18 Oct 2006 14:57:28 -0400 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [EAI] ISSUE: framework -3 - missing MIME considerations Message-ID: In-Reply-To: References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (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: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 18 October, 2006 18:08 +0100 Charles Lindsey wrote: > On Wed, 18 Oct 2006 16:52:20 +0100, John C Klensin > wrote: > > >> My impression, incidentally, is that there is growing >> consensus that message/rfc822 cannot be used to encapsulate >> messages with UTF-* headers. > > Well I see no such growing consensus, and if there is, then > you can countme out of it. > > I have always assumed (and have often posted comments implying > thatassumption) that (an extended) message/rfc822 was indeed > the right tool toencapsulate messages with UTF-* headers, most > likely with the restrictionthat any email containing it would > have to be designated a UTF8SMTP objectitself (by inclusion of > Header-Type: UTF8SMTP), with a consequentobligation to > downgrade the contained message/rfc822 (or else bounce). The content, and in particular the headers, of a message/rfc822 body part is expected to be strictly conformant to RFC 822 (not even 2822). That is a strong ASCII constraint. The way I read that spec, one can't even have a body part inside of one with "content-transfer-encoding: 8bit", regardless of what the transport might transmit. If I correctly understand what you are suggesting above, you would expect a legacy MUA or other application that can handle message/rfc822, but that has never heard of the "Header-Type:" header, to scan through the entire header set looking for it (remember that header ordering is, in general, not guaranteed) and then to take some action on that basis. We have generally considered the idea of having to scan all of the headers to find one that is necessary to the interpretation of headers that might come earlier -- forcing a multi-pass procedure over the headers-- as a non-starter. MIME-Version does not violate that rule only because it is used to verify that Content-type and Content-transfer-encoding are correctly understood. Header-type is closer to the line and, if used as I think you are suggesting above, is over it: the parser in a legacy MUA might have done very nasty things to UTF-8 addresses and other things long before encountering that header (which it wouldn't understand) telling it to apply a 7bit interpretation. Of course, if a message has already been downgraded to the point that it is entirely ASCII and 822-conformant, then message/rfc822 is a reasonable way to handle or represent it. But that isn't the case that most people are thinking about when they talk about encapsulation. There are also some issues with the nested encoding rule... discussed below. In the hope of being less abstract, let's walk through the one case for which it is absolutely clear that encapsulation is needed (there is still debate about the downgrade case, although I think we are getting closer). Suppose I'm on a fully internationalized email system -- the MTAs and MUAs, and everything in between support the SMTP extension, UTF-8 headers, 8BITMIME, charset=utf8 in text/plain, and so on. I receive a UTF8SMTP message that contains forward and backward-pointing UTF8 addresses, some non-address UTF-8 headers, and (to make the problem a little easier but still clear), one body part which has Content-type: text/plain charset=utf8 and C-T-E: base64. Suppose I want to forward that message to a colleague whom I know is on a legacy system (no UTF-8 headers or addresses accepted or understood) but that does support, say, charset="iso-8859-1". Assume I know that from out of band information sources, such as having prior messages bounced. And suppose I want to forward the message with a few comments of my own... in German. In the classical case (no UTF-8 addresses or headers anywhere), I would forward the message by using a structure of: From: ascii-mailbox1 To: ascii-mailbox2 ... Content-type: multipart/mixed; boundary="--xyz" --xyz Content-type: text/plain charset=iso-8859-1 My note to her, in German and 8859-1 --xyz Content-type: message/rfc822 --xyz-- But, in the example given, I've got UTF-8 header stuff in the original message. The outside headers and first body part have to be the same as the example above, because the receiving legacy system can't handle anything else. So now I come to the second body part. I have, I think, the following options: (1) Associate a Content-transfer-encoding with the "Content-type: message/rfc822" and put the entire original message, headers and all, into Base64. Whoops, its internal body part was already in Base64, so I've broken the nested encoding rule. (2) I downgrade the headers of the forwarded message, doing whatever the downgrade drafts says and making up new addresses so that the thing is all-ASCII and 822-conformant. Whoops, the Alt-Address is probably gone by now, there is no envelope in which it might be found, and, because this is a MUA-level message forwarding case, there is no equivalent of rejection or sending a non-delivery notification... unless you are going to tell me that such messages cannot be forwarded. If it is downgraded, the odds are that the original cannot be exactly reconstructed, so, whatever this is, it isn't encapsulation. (3) I construe message/rfc822 as "really" being 8bit clean and permitted UTF8 headers, adding a "Header-type" field to reinforce that. Whoops, I can't transmit this message at all without 8BITMIME (reducing the problem to Case 2) or, if the otherwise-legacy server can handle 8BITMIME and my submission server tries to handle it that way, the header parser in the receiving MUA (or, worse, the receiving IMAP server or other header canonicalization agent) discards all of the high-order bits in the headers of that message/rfc822 object, ignoring Header-Type because it has never heard of it. If you have another analysis, I'm very interested in hearing it, because I'd be really happy if we could use message/rfc822. But I believe, based on the analysis above and several other efforts to work through this, that "message/rfc822" means "ASCII, 822-conformant, headers and message" and that we get ourselves into big trouble by trying to bend that or encourage sender systems to lie to recipient systems about it. Remember that one gets away with some transformations in netnews by assuming that the entire transport and reader environment if 8bit clean or better. We have explicitly not made that assumption with SMTP/MIME-based email and, given the behavior of a number of popular and widely deployed MTAs and MUAs, that assumption would simply not be sustainable. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 18 23:19:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaORA-0003eZ-Fd; Wed, 18 Oct 2006 23:19:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaOR9-0003bl-ML for ima@ietf.org; Wed, 18 Oct 2006 23:19:15 -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 1GaOK3-0002L1-GH for ima@ietf.org; Wed, 18 Oct 2006 23:11:59 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GaOK0-0001EW-86 for ima@ietf.org; Thu, 19 Oct 2006 05:11:52 +0200 Received: from pd9fbad02.dip0.t-ipconnect.de ([217.251.173.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 Oct 2006 05:11:52 +0200 Received: from nobody by pd9fbad02.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 Oct 2006 05:11:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 4.1 - reject Date: Thu, 19 Oct 2006 05:09:26 +0200 Organization: Lines: 58 Message-ID: <4536EC66.3A14@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad02.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > The intent of "bounce" in 2821 was to include both an SMTP > transaction-time rejection (which, by the way, includes > rejection after receiving DATA, giving the intermediate > go-ahead, and receiving the closing CRLF.CRLF) _and_ generation > of a notification message. Yes, and that vagueness is not more state of the art, "accept and maybe bounce later" is considered as net abuse unless that bounce goes to the originator. On the other hand "reject" is a simple decision, it's then the problem of the client how to report an error to the originator. If an MTA isn't sure about "downgrade", with a possible result of "no idea", it can't accept the mail unless it's almost sure that it can report this issue to the originator. If the route forward is clear all is fine, if the route backward is clear it's also okay, if both are clear it's ideal, and if both are unclear "accept" isn't possible. That leaves "reject" as a neutral statement in 4.1 covering all cases. > the message travels > SubmissionMUA -> A -> B -> C > under normal circumstances (see below), if C rejects the message > coming from B (e.g., issues a 5yz response to a MAIL or RCPT > command), B is going to need to generate a notification message > to A IOW B is supposed to know how to inform A if C rejects the mail. > C has no control over whether A, or for that matter the user of > the SubmissionMUA, sees an SMTP rejection or a notification > message. That's B's problem, it accepted the mail and the responsibility, C can't get into trouble if it rejects it. > Extending Frank's suggestion slightly to imply that NDNs are > obsolete and should be generally considered spam That would be an odd "extension", there are complete protocols helping B out with its decision "accept" or "reject", with an outcome of PASS meaning "yes, I can bounce this message later, therefore I can accept it and see what C decides". NDNs are not obsolete, they're essential. But of course they must go to the originator. How B manages that, e.g. by using "enforced submission rights" if it's an MSA, isn't C's problem. > these documents are not the right place for that debate, IMO. ACK, let's just use unambiguous terms like "reject", that's what we're interested in wrt C. B's problems are not caused by EAI. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 19 00:06:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaPAO-0006b9-40; Thu, 19 Oct 2006 00:06:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaPAN-0006b3-3C for ima@ietf.org; Thu, 19 Oct 2006 00:05:59 -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 1GaPAK-0005Aj-OL for ima@ietf.org; Thu, 19 Oct 2006 00:05:59 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GaPA2-0004A0-Bl for ima@ietf.org; Thu, 19 Oct 2006 06:05:38 +0200 Received: from pd9fbad02.dip0.t-ipconnect.de ([217.251.173.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 Oct 2006 06:05:38 +0200 Received: from nobody by pd9fbad02.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 Oct 2006 06:05:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework -3 - missing MIME considerations Date: Thu, 19 Oct 2006 06:04:09 +0200 Organization: Lines: 37 Message-ID: <4536F939.573F@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@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: pd9fbad02.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) 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 John C Klensin wrote: > Application/mbox is an Informational RFC; taking on the job of > explaining the impact on non-standard headers makes the job of > this WG impossible. If you think application/mbox needs to be > considered explicitly, please initiate an effort to get it onto > the standards track I'm not exactly interested to improve this spec., it could be as simple as registering a new format=i18mail, or maybe not. For the framework I-D it's a known case where existing applications might not work as expected, if that's documented it's okay. I'm mildly interested because I know one mail service provider offering a Webmail interface, where users can download two or more mails at once, encapsulated as x-download/rfc822 mbox (they picked the MIME type before application/mbox existed, and I can't tell if they renamed it later). Maybe some mailing lists use application/mbox for their digests - all we have to do is to say that there might be a problem, we're not forced to investigate or solve it. Maybe in a new 7.6 section: | 7.6 application/mbox | Some applications use formats similar to the application/mbox | format defined in [RFC 4155] instead of message/digest to store | messages. As far as such applications assume that all stored | messages use the message/rfc822 format with US-ASCII headers | they're not ready for [I18Nemail-UTF8]. Or something in that direction, an "additional issue", reserving 7.5 for wild and wonderful (ab)uses of local parts not addressed in 7.3. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 19 01:27:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaQQn-0006ts-H0; Thu, 19 Oct 2006 01:27:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaQQm-0006oT-4z for ima@ietf.org; Thu, 19 Oct 2006 01:27:00 -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 1GaQQk-0004vE-MG for ima@ietf.org; Thu, 19 Oct 2006 01:27:00 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GaQQc-00062w-AS for ima@ietf.org; Thu, 19 Oct 2006 07:26:50 +0200 Received: from pd9fbad02.dip0.t-ipconnect.de ([217.251.173.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 Oct 2006 07:26:50 +0200 Received: from nobody by pd9fbad02.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 Oct 2006 07:26:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 10 - too long Date: Thu, 19 Oct 2006 07:25:24 +0200 Organization: Lines: 46 Message-ID: <45370C44.50ED@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45344BA4.3A73@xyzzy.claranet.de> <5347C4027E5AB2D2736FE2E2@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad02.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > RFC 3552 requires a fairly comprehensive security analysis. It starts to worry me if the "real" specific issues are hidden within tons of general security considerations, some of them "well-known". As an example, the UTF-8 issues are fascinating, RFC 3629 explains all details, it's a STD, and implementors are supposed to read it if there's a normative reference. > More important, before the appearance of > draft-klensin-idnabis-issues-00 and > draft-alvestrand-idnabis-bidi-00 this week, Net-Unicode was the > only document in the IETF space that even attempted to discuss > the string handling issues relevant to i18nemail I've seen (and read, once) the idna-bidi draft: http://tools.ietf.org/html/draft-alvestrand-idna-bidi But I don't find an idna-issues I-D, is that still somewhere in the pipeline ? > if the Net-Unicode draft is actually unclear, I'd appreciate > pointers to specific text that needs to be clarified. Some questions in: | Message-ID: <44CB0126.2AE3@xyzzy.claranet.de> | Date: Sat, 29 Jul 2006 08:33:10 +0200 | To: John C Klensin | Subject: Re: First comments on draft-klensin-net-utf8-oo.txt | References: <617FA4967C5A4F8E551B3BE8@p3.JCK.COM> | Content-Length: 3742 A shorter form could be "what's the idea of a SHOULD NOT for BEL, BS, HT, VT, and FF" ? It mentions RFC 854, and there I found commands starting at 0xF0, I've no clue how that could work with UTF-8 (needing 0xF0..0xF4 for its own purposes). In section 4 you have the same paragraph "The NFC tables"... twice. In 5.2 there's a "vfersion", and the claim that "UTF-8 is tied to Unicode Version 4" makes no sense for me. Frank -- don't try s/8/4/ ;-) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 19 01:46:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaQjh-0002S5-0e; Thu, 19 Oct 2006 01:46:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaQjf-0002RO-A4 for ima@ietf.org; Thu, 19 Oct 2006 01:46: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 1GaQje-0002R2-0O for ima@ietf.org; Thu, 19 Oct 2006 01:46:31 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GaQjN-0000MJ-TG for ima@ietf.org; Thu, 19 Oct 2006 07:46:14 +0200 Received: from pd9fbad02.dip0.t-ipconnect.de ([217.251.173.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 Oct 2006 07:46:13 +0200 Received: from nobody by pd9fbad02.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 19 Oct 2006 07:46:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 6 - delete section Date: Thu, 19 Oct 2006 07:44:21 +0200 Organization: Lines: 16 Message-ID: <453710B5.3B0E@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <453445CC.7F86@xyzzy.claranet.de> <682A932E049D20A39E8D1B2F@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad02.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: >> The complete I-D is about I18N, it doesn't need this >> redundant section. > This section is an IESG requirement. Take it up with > the rule-makers and nit-pickers. Harald would tell us if we violate this rule without a good reason, he has invented it, it is a SHOULD, not a MUST. In a document with I18N in its title following that rule literally with a dummy section is pointless - AFAIK the nit-picking tools don't try to enforce this. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 19 09:27:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXvk-0005LH-Po; Thu, 19 Oct 2006 09:27:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXvi-0005Kx-N7 for ima@ietf.org; Thu, 19 Oct 2006 09:27:26 -0400 Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXve-0004fK-Ch for ima@ietf.org; Thu, 19 Oct 2006 09:27:26 -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]:56164) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1GaXvO-0007S6-6R (Exim 4.63) (return-path ); Thu, 19 Oct 2006 14:27:07 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1GaXvO-0001Os-UX (Exim 4.54) (return-path ); Thu, 19 Oct 2006 14:27:06 +0100 Date: Thu, 19 Oct 2006 14:27:06 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 4.1 - reject In-Reply-To: <4536EC66.3A14@xyzzy.claranet.de> Message-ID: References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 19 Oct 2006, Frank Ellermann wrote: > > If an MTA isn't sure about "downgrade", with a possible result > of "no idea", it can't accept the mail unless it's almost sure > that it can report this issue to the originator. If the route > forward is clear all is fine, if the route backward is clear > it's also okay, if both are clear it's ideal, and if both are > unclear "accept" isn't possible. That leaves "reject" as a > neutral statement in 4.1 covering all cases. Are you proposing that a server must keep a cache of all destination host capability lists, so that it can reject non-downgradable messages as early as possible? I think that is too large a change to existing practise to make it part of the EAI work. Tony. -- f.a.n.finch http://dotat.at/ FORTIES CROMARTY FORTH: SOUTHERLY 6 TO GALE 8, DECREASING 5 OR 6 LATER. RAIN OR SHOWERS. MODERATE OR GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 19 09:48:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYFb-0008Tk-Mg; Thu, 19 Oct 2006 09:47:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYFa-0008Tc-FU for ima@ietf.org; Thu, 19 Oct 2006 09:47:58 -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 1GaYFY-0008AQ-VG for ima@ietf.org; Thu, 19 Oct 2006 09:47:58 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GaYFU-0004xr-Dr; Thu, 19 Oct 2006 09:47:52 -0400 Date: Thu, 19 Oct 2006 09:47:51 -0400 From: John C Klensin To: Tony Finch , Frank Ellermann Subject: Re: [EAI] ISSUE: framework 4.1 - reject Message-ID: <4F787BD08DE791C0806D3134@p3.JCK.COM> In-Reply-To: References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (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: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 19 October, 2006 14:27 +0100 Tony Finch wrote: > On Thu, 19 Oct 2006, Frank Ellermann wrote: >> >> If an MTA isn't sure about "downgrade", with a possible result >> of "no idea", it can't accept the mail unless it's almost sure >> that it can report this issue to the originator. If the route >> forward is clear all is fine, if the route backward is clear >> it's also okay, if both are clear it's ideal, and if both are >> unclear "accept" isn't possible. That leaves "reject" as a >> neutral statement in 4.1 covering all cases. > > Are you proposing that a server must keep a cache of all > destination host capability lists, so that it can reject > non-downgradable messages as early as possible? I think that > is too large a change to existing practise to make it part of > the EAI work. I think it is more than that. That ideal case requires that it know that both the forward and reverse addresses are both authentic and deliverable, and that it know those things in advance of receiving a message between the sending system and the receiving one. That would require some pre-seeding at best. Remembering that there are transient conditions in the mail system -- "full mailbox" being the most common-- it gets even more difficult. Note that even a real-time rejection at the first hop doesn't _guarantee_ that the report will get through to the originator: the submission MTA might have validated a source but not an address, the address could have been one-time-use (stupid, but possible), and so on. One could sensibly argue that those cases are marginal or even irrelevant -- the responsibility has been successfully transferred and that is all the rejecting server cares about -- and would probably be right, but it emphasizes how fragile a notion of "almost sure it can deliver or report" becomes. As I have tried to suggest, it is perfectly possible to design an email system so that anything that is not deliverable as expected (or within some reasonable delta of "as expected") is simply dropped and the only way to determine whether a message got through involves some sort of end-to-end ACK. Some would claim that X.400 worked that way; some proprietary systems in the past certainly did. One can also try to shift the preference from "accept, then interpret and process, then send NDN if needed" (which has been the trend and preference for years) to "reject as early as possible, ideally as part of the SMTP transaction". I've certainly got my servers to reject, e.g., bad forward-pointing addresses, as early as possible and that was not the case a decade ago. But it seems to me that one can't turn it into a requirement, especially given the implications of a generic MX backup or relay, which knows the hosts for which it is holding and forwarding mail but not the mailbox list or syntax on that host, getting a rejection from the target host. In that case, there is almost no choice but to generate an NDN (or to discard the message, which I guess Frank prefers). More generally and more important, the Internet mail system is not designed that way. It is designed around the assumption that a mail message, once sent, is delivered unless a negative message (not distinguishing between an NDN and a real-time rejection) comes back. In principle, one could change that, but it clearly isn't within scope for this WG (or for any other effort designed to codify existing, mainstream, practices). john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 19 17:17:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GafFv-0005Kv-Bw; Thu, 19 Oct 2006 17:16:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GafFu-0005E0-2v for ima@ietf.org; Thu, 19 Oct 2006 17:16:46 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GafFl-0003wW-7j for ima@ietf.org; Thu, 19 Oct 2006 17:16:45 -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.232) id 4537eb28.13d82.58 for ima@ietf.org; Thu, 19 Oct 2006 22:16:24 +0100 (envelope-sender ) Received: (from root@localhost) by clerew.man.ac.uk (8.13.7/8.13.7) id k9JLGNqS028830; Thu, 19 Oct 2006 22:16:23 +0100 (BST) Date: Thu, 19 Oct 2006 15:16:16 +0100 To: "ima@ietf.org" Subject: Re: [EAI] ISSUE: framework -3 - missing MIME considerations References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> 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.7 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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, 18 Oct 2006 19:57:28 +0100, John C Klensin wrote: > --On Wednesday, 18 October, 2006 18:08 +0100 Charles Lindsey > wrote: >> I have always assumed (and have often posted comments implying >> thatassumption) that (an extended) message/rfc822 was indeed >> the right tool toencapsulate messages with UTF-* headers, most >> likely with the restrictionthat any email containing it would >> have to be designated a UTF8SMTP objectitself (by inclusion of >> Header-Type: UTF8SMTP), with a consequentobligation to >> downgrade the contained message/rfc822 (or else bounce). > > The content, and in particular the headers, of a message/rfc822 > body part is expected to be strictly conformant to RFC 822 (not > even 2822). That is a strong ASCII constraint. But it is always in order to define extensions to existing standards, provided you put in place transitional arrangements so that existing implementations do not break (indeed, we are currently in the process of extending 2822, at the same time trying to ensure that existing implementations do not see the new stuff). > The way I read > that spec, one can't even have a body part inside of one with > "content-transfer-encoding: 8bit", regardless of what the > transport might transmit. That may well be true, but not if the message/rfc822 itself (not the thing inside it) says CTE 8bit. The real question is whether RFC 1652 tells you to change the CTE of the contained email when you hit a non-8BITMIME server (as clearly needs to be done). RFC 1652 seems somewhat reticent to tell you that :-( . > > If I correctly understand what you are suggesting above, you > would expect a legacy MUA or other application that can handle > message/rfc822, but that has never heard of the "Header-Type:" > header, to scan through the entire header set looking for it > (remember that header ordering is, in general, not guaranteed) > and then to take some action on that basis. I would expect that situation to be no different than when a legacy MUA is suddenly confronted with a UTF8SMTP message with UTF-8 addresses in its headers. In both cases, I believe, the answer is that the legacy MUA should never have been allowed to see the message in the first place, and if it did it implies that some prior MTA had advertised the UTF8SMTP capability and then failed in its obligation to ensure that the message was subsequently handled accordingly. > Of course, if a message has already been downgraded to the point > that it is entirely ASCII and 822-conformant, then > message/rfc822 is a reasonable way to handle or represent it. > But that isn't the case that most people are thinking about when > they talk about encapsulation. Please note that I am in no way suggesting message/rfc822 (or even message/utf8smtp) as a means of encapsulating a message for subsequent restoration to its original pristine state. > In the hope of being less abstract, let's walk through the one > case for which it is absolutely clear that encapsulation is > needed (there is still debate about the downgrade case, although > I think we are getting closer). > > Suppose I'm on a fully internationalized email system -- the > MTAs and MUAs, and everything in between support the SMTP > extension, UTF-8 headers, 8BITMIME, charset=utf8 in text/plain, > and so on. I receive a UTF8SMTP message that contains forward > and backward-pointing UTF8 addresses, some non-address UTF-8 > headers, and (to make the problem a little easier but still > clear), one body part which has Content-type: text/plain > charset=utf8 and C-T-E: base64. > > Suppose I want to forward that message to a colleague whom I > know is on a legacy system (no UTF-8 headers or addresses > accepted or understood)... OK. You are John. You received the message from Ålice and you want to forward it to Bob. Essentially, you cannot expect to convey any more to Bob than he would have seen if Ålice had sent it direct to Bob (e.g. he might possibly have some diffficulty in sending a reply to Ålice - he might be able to send it to an alternate Alice, though). > > In the classical case (no UTF-8 addresses or headers anywhere), > I would forward the message by using a structure of: > > From: ascii-mailbox1 > To: ascii-mailbox2 > ... > Content-type: multipart/mixed; boundary="--xyz" > > --xyz > Content-type: text/plain charset=iso-8859-1 > > My note to her, in German and 8859-1 > > --xyz > Content-type: message/rfc822 > > including headers and the > Base64 encoded UTF-8 body part. This is what > "encapsulation" is all about.> > --xyz-- > > But, in the example given, I've got UTF-8 header stuff in the > original message. The outside headers and first body part have > to be the same as the example above, because the receiving > legacy system can't handle anything else. No, the headers right at the top need to include Header-Type: UTF8SMTP because the message is going to contain something that is not allowed in legacy emails. > ... So now I come to the > second body part. I have, I think, the following options: > (2) I downgrade the headers of the forwarded message, doing > whatever the downgrade drafts says and making up new addresses > so that the thing is all-ASCII and 822-conformant. Yes. More or less. Your MUA (or possibly your local MSA) enquires whether Bob's local MTA does UTF8SMTP (it doesn't), so it either tells you "Sorry! I cannot send a message with that atachment" (a bounce), or it sets about downgrading it. It spots that the attached message/rfc822 needs to be downgraded, at which point it does exactly what Ålice's MUA would have done if she had tried to send it directly to Bob. Let us consider Ålice's From header. If that provided an , then it becomes the only remaining address. > Whoops, the > Alt-Address is probably gone by now, there is no envelope in > which it might be found, and, because this is a MUA-level > message forwarding case, ... Ah! You want to use that bit in 5.1.1 of the downgrade document which says to use the envelope-from in that case. I always thought that was a bit iffy, and said so whenb I commented on that draft on Sept 4th. Indeed, it has never been clear to me how the originating MUA was able to provide an in the envelope-from if it did not find/put one in the header From: at the same time. Once upon a time, we had an ATOMIC parameter (more likely "DOWNGRADABLE") which allowed you to apply an algorithmic transformation. But discussion on that suddenly stopped and it disappeared from the various drafts, apparently without any consensus to do so. So the best thing to do is to omit the From header entirely (which it is in fact legal to do in a message/rfc822). But all is not yet lost, because the downgrade process will also have created Downgraded: From: and (unless his MUA is being excessively obstinate, or has not the fonts to display it), Bob should be able to see that (though whether it gives him enough to reply to Ålice is less certain). > there is no equivalent of rejection or > sending a non-delivery notification... unless you are going to > tell me that such messages cannot be forwarded. Yes. You yourself have often said that, even if downgrading gets too complicated for implementors to bother with, a system which always bounces rather than downgrades would still be preferable to the present situation. Your best strategy if that happens, and you really want to be sure that Bob sees it, is to do some cutting and pasting and send it as a text/plain. > ... If it is > downgraded, the odds are that the original cannot be exactly > reconstructed, so, whatever this is, it isn't encapsulation. And I do not claim it is encapsulation in that sense. If you DO want encapsulation in that sense then, on further thought, I have come to the conlusion that the only way to make it work reliably will be to let that double encoding happen (by using an application type, even application/octet-stream if all else fails). But I would not like to write that into a formal standard if we can avoid it, and I do not think we yet need to contemplate that. -- 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 Oct 20 03:32:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaorV-0008E7-HJ; Fri, 20 Oct 2006 03:32:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaomy-0004pd-51 for ima@ietf.org; Fri, 20 Oct 2006 03:27:32 -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 1Gaodd-0003hC-0N for ima@ietf.org; Fri, 20 Oct 2006 03:17:54 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GaodQ-0002Zl-Rf for ima@ietf.org; Fri, 20 Oct 2006 09:17:40 +0200 Received: from pd9fba921.dip0.t-ipconnect.de ([217.251.169.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Oct 2006 09:17:40 +0200 Received: from nobody by pd9fba921.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Oct 2006 09:17:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 4.1 - reject Date: Fri, 20 Oct 2006 08:22:12 +0200 Organization: Lines: 74 Message-ID: <45386B14.C0D@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@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: pd9fba921.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Tony Finch wrote: > Are you proposing that a server must keep a cache of all destination > host capability lists, so that it can reject non-downgradable messages > as early as possible? That's not limited to EAI, it's a general consequence of the "report errors to the originator" design. For the purpose of the "framework" I-D we're only concerned with this: | When MUA/MTA is transferring mail and finding its envelope contains | Non-ASCII addresses, it MUST decide to bounce or downgrade if | receiving MTA is EAI incompliant. If it's an MX it's (today) expected to know which addresses are valid or not, and to reject mails to invalid addresses. Ideally it would also know which in theory valid mailboxes are over quota, trying hard to accept only mails where it can do what it must after it accepted them, deliver or report an error to the originator. "Cannot downgrade for address X" (otherwise a valid ASCII address X) is "simply" an additional piece of information it needs for its job, otherwise almost the same situation "X is no mailbox here" or "X is over quota". In all these "undeliverable" situations it better rejects mails to X. If it has a good idea how to report errors found later it can accept the mail without knowing the state of X. There must be a way forward or a way backward, ideally both. Otherwise the MX could be in an unholdable position forced to violate STD 10 in some way or another - "frivolous", as the PS written by a "dude or not" "(while popping or otherwise)" puts it. > I think that is too large a change to existing practise to make it > part of the EAI work. It's no change at all, it's just the word "reject", because "bounce" is a mine-field on bright days. John C Klensin wrote: > there are transient conditions in the mail system -- "full mailbox" > being the most common-- it gets even more difficult. Yes, I've given up to discuss this on the SpamCop list with folks who claim that receivers can always solve this without any help from the senders. Maybe - if most obvious cases, where that works without the help of the senders, are eliminated by upgrading or blocking abusive receivers - it's again possible to discuss the more interesting cases. > I've certainly got my servers to reject, e.g., bad forward-pointing > addresses, as early as possible and that was not the case a decade > ago. The flood of forged Return-Paths started about 5 years ago as far as I can judge it - I recall a mail-abuse-FAQ written about 2002, where it was still discussed as "social problem", not as "protocol design flaw" (introduced between 821 and 2821) > In that case, there is almost no choice but to generate an NDN (or > to discard the message, which I guess Frank prefers). No, unless my mail provider manages to make its service unusable - I just deleted 27,000 spams received in less than 15 hours, and that took me 6 hours - the MX should get a PASS clearly indicating "please send NDNs as needed" or a FAIL clearly indicating "please reject". Of course it can decide it by other means, block lists, crystal balls, DKIM signatures, or whatever it takes. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 20 04:40:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GapvU-0003ZJ-0m; Fri, 20 Oct 2006 04:40:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GapvS-0003Ys-9n for ima@ietf.org; Fri, 20 Oct 2006 04:40:22 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GapvN-0004hR-Ly for ima@ietf.org; Fri, 20 Oct 2006 04:40:22 -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.232) id 45388b6f.17e6c.110 for ima@ietf.org; Fri, 20 Oct 2006 09:40: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 k9K8eD3M008848 for ; Fri, 20 Oct 2006 09:40:14 +0100 (BST) To: "ima@ietf.org" Subject: Re: [EAI] ISSUE: framework -3 - missing MIME considerations References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> Message-ID: Date: Fri, 20 Oct 2006 09:40:13 +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.5 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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, 19 Oct 2006 15:16:16 +0100, Charles Lindsey wrote: > On Wed, 18 Oct 2006 19:57:28 +0100, John C Klensin > wrote: >> (2) I downgrade the headers of the forwarded message, doing >> whatever the downgrade drafts says and making up new addresses >> so that the thing is all-ASCII and 822-conformant. > Let us consider Ålice's From header. If that provided an , > then it becomes the only remaining address. > >> Whoops, the >> Alt-Address is probably gone by now, there is no envelope in >> which it might be found, and, because this is a MUA-level >> message forwarding case, ... > > Ah! You want to use that bit in 5.1.1 of the downgrade document which > says to use the envelope-from in that case. I always thought that was a > bit iffy, and said so whenb I commented on that draft on Sept 4th. > Indeed, it has never been clear to me how the originating MUA was able > to provide an in the envelope-from if it did not find/put > one in the header From: at the same time. But, on further thoughts, that envelope-from of Ålice's original message IS available if you want to transfer it into the From header during the downgrade. You will find it in the Return-Path of her message. -- 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 Oct 20 06:02:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GarCg-0007px-2v; Fri, 20 Oct 2006 06:02:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GarCe-0007pr-SG for ima@ietf.org; Fri, 20 Oct 2006 06:02:12 -0400 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GarCX-0001OB-S2 for ima@ietf.org; Fri, 20 Oct 2006 06:02:11 -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]:33683) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1GarCM-0002YQ-Nt (Exim 4.63) (return-path ); Fri, 20 Oct 2006 11:01:54 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1GarCM-0007Nz-CA (Exim 4.54) (return-path ); Fri, 20 Oct 2006 11:01:54 +0100 Date: Fri, 20 Oct 2006 11:01:54 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 4.1 - reject In-Reply-To: <45386B14.C0D@xyzzy.claranet.de> Message-ID: References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 20 Oct 2006, Frank Ellermann wrote: > > If it's an MX it's (today) expected to know which addresses are valid > or not, and to reject mails to invalid addresses. Ideally it would > also know which in theory valid mailboxes are over quota, trying hard > to accept only mails where it can do what it must after it accepted > them, deliver or report an error to the originator. > > "Cannot downgrade for address X" (otherwise a valid ASCII address X) > is "simply" an additional piece of information it needs for its job, > otherwise almost the same situation "X is no mailbox here" or "X is > over quota". > > In all these "undeliverable" situations it better rejects mails to X. Agreed, but many SMTP servers are not MXs. You can't expect an outgoing relay to know which destination addresses can cope with EAI messages at SMTP time, so you can't require them to reject instead of bounce. Tony. -- f.a.n.finch http://dotat.at/ FORTIES CROMARTY FORTH: SOUTHERLY 6 TO GALE 8, DECREASING 5 OR 6 LATER. RAIN OR SHOWERS. MODERATE OR GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 20 08:00:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gat2k-0004Eh-4k; Fri, 20 Oct 2006 08:00:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gat2h-00040r-Jr for ima@ietf.org; Fri, 20 Oct 2006 08:00:04 -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 1Gat2g-0000zu-A1 for ima@ietf.org; Fri, 20 Oct 2006 08:00:03 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gat2X-0000XO-4k for ima@ietf.org; Fri, 20 Oct 2006 13:59:53 +0200 Received: from pd9fba921.dip0.t-ipconnect.de ([217.251.169.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Oct 2006 13:59:53 +0200 Received: from nobody by pd9fba921.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Oct 2006 13:59:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 4.1 - reject Date: Fri, 20 Oct 2006 13:57:29 +0200 Organization: Lines: 28 Message-ID: <4538B9A9.6101@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@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: pd9fba921.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) 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 Tony Finch wrote: >> In all these "undeliverable" situations it better rejects mails to X. > Agreed, but many SMTP servers are not MXs. If we agree on the MX case we're ready, anything else is simple. BTW, I tried to find your 2004 article where you informed me that RFC 821 can't beat RFC 1123 5.3.6(a) because RFC 1123 is also a part of a STD, but I haven't found it. > You can't expect an outgoing relay to know which destination addresses > can cope with EAI messages at SMTP time, so you can't require them to > reject instead of bounce. Yes, but that mailout probably is an MSA, or sends on behalf of an MSA, it knows how to report errors to the originator - by mail if necessary, there's no problem with bounces sent to the originator. The complete sending side (or MON, Mail Originating Network, in Keith's terminology) should have no problems. Ignoring open relays because they're hopeless. An MX talking with unknown strangers is the critical hop: It shouldn't accept UTF8SMTP if a later MTA on the receiving side (MRN) could decide that it cannot downgrade. If s/bounce/reject/ doesn't express this in 4.1, then maybe we need an extra-bullet for such "border MTAs" in 4.1 ? Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 20 09:09:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gau7B-0000nO-0O; Fri, 20 Oct 2006 09:08:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gau79-0000my-43 for ima@ietf.org; Fri, 20 Oct 2006 09:08:43 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gau78-0003Q9-81 for ima@ietf.org; Fri, 20 Oct 2006 09:08:43 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id k9KD8PR9005835; Fri, 20 Oct 2006 22:08:26 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006102022082507471 ; Fri, 20 Oct 2006 22:08:25 +0900 Date: Fri, 20 Oct 2006 22:08:25 +0900 (JST) Message-Id: <20061020.220825.68136113.fujiwara@jprs.co.jp> To: chl@clerew.man.ac.uk Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 From: fujiwara@jprs.co.jp In-Reply-To: References: X-Mailer: Mew version 5.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 3dc828214e948ff35b815af10e94a823 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 Thanks for your comment Charles. I'm sorry for this late reply. I was read, but then, missed this. I try to update the draft before cut-off, if possible. > From: "Charles Lindsey" > Date: Mon, 04 Sep 2006 20:21:38 +0100 > > s/EAI/UTF8SMTP/ throughout the document, including in the title. I'm hesitating EAI or UTF8SMTP. framework document is 'EAI Framework'. Which is this protocol set name, EAI or UTF8SMTP ? > 1. Introduction > > Traditional mail systems which are defined by [RFC2821] and [RFC2822] > allow US-ASCII characters in SMTP envelope and mail headers in body > part. The EAI proposal [I-D.ietf-eai-framework], > [I-D.ietf-eai-utf8headers] and [I-D.ietf-eai-smtpext] allows UTF-8 > characters in SMTP envelope and mail headers in body part. > > s/mail headers in body part/mail header field bodies/ (twice) agreed and updated. > otherwise, people will think you are talking about headers inside the > s of mail messages. "field body" is the term RFC 2822 uses for a > header field without its header name. > > ... Not only > SMTP envelope, but also UTF-8 characters in mail headers MUST be > converted to US-ASCII. > > s/mail headers/mail header fields/ here and in lots of other places, to > accord with the terminology of RFC 2822. agreed and updated. > And then s/mail header fields/mail header fields and in the headers fields > of MIME multipart and message types/. > > Otherwise, an already downgraded message will get munged if it then > encounters a non-8BITMIME server. not agreed. An already downgraded message is a normal rfc2822/rfc822 message and it may contain 8bit(non-ascii) characters in the message body. RFC 1652 capable SMTP agent treats it correctly. > In this document, requirements for downgrading is described in > section Section 3, SMTP Downgrading is described in Section 4, and > SMTP DATA/Header Downgrading is described in Section 5. > > s/is described/are described/ updated. > I don't like the use of the term "SMTP DATA/header" to describe the mail > messages that are transported. We are speaking of objects that conform to > RFC 2822 as modified by our utf8headers document, but these objects are > going to turn up in all sorts of places apart from within SMTP, such as > within other transports (e.g. UUCP), in gateways from other media (e.g. > News), within mailing list expanders, and within POP3, IMAP and other > storage agents, and they are likely to have to be downgraded (or upgraded) > according to your rules in Section 5 in all sorts of situations (e.g. > various gateways). Of course, your Section 4 is SMTP-specific, but not > your Section 5. > > So a better term would be "Email header downgrading". agreed. > 3. Downgrade Requirements > > 3.1. Timing and conditions of downgrading > > Note: If the UTF8SMTP header exists, downgrading will be performed. > If UTF-8 characters exist in mail headers without the UTF8SMTP > header, this is a protocol error, ... > > No, only if that header exists with the parameter "UTF8", not when its > parameter is "downgraded" or "ASCII". agreed. > Note also that I have suggested renaming this header as something like > "Header-Content", and using "UTF8SMTP" as the parameter. to make uniform with utf8header document change, Header name changed to "Header-Type" and the parameter value to "UTF8". > 3.2. Requirements > > Followings are requirements of downgrading. > > I think that is more a list of hoped-for properties rather than a list of > requirements. I doubt we are going to succeed in realizing them all (e.g. > an upgrade may not always be an exact inverse of the original downgrade). changed some items' "must" to "should". > 4. SMTP Downgrading > > Downgrading in SMTP envelope uses ALT-ADDRESS parameter proposed in > [I-D.ietf-eai-smtpext]. An address is downgradable if the address is > all-ASCII address or the address has all-ASCII address specified by > ALT-ADDRESS parameter. > > But what about punycode downgraded (possibly under the control of an > "atomic" or "downgradable" keyword)? It is clear that such a downgrade is > achievable, given the offficial definition or punycode. We discussed that, > but we never agreed to remove it from the draft AKAIR. At the Vancouver discussion, MUA or submission server computes or specifies ALT-ADDRESS parameter if necessary. > One SMTP session may contain multiple recipients. Downgrading SHOULD > be performed for each SMTP recipient address. ... > > s/for each SMTP recipient address/for each SMTP recipient address > individually/ updated > EAI-Downgraded-From: > EAI-Downgraded-To: > > You need to give a syntax for these new header fields. Also, they should > be regarded as Trace fields, so that they come in the middle of the > sequence of Received headers, to indicate whereabouts in the sequence of > MTAs the downgrading was done. > > Also, we need a name not involving "EAI-", and I would suggest something > involving "Envelope-". So we would get something like: > > trace = [return] > 1*( received / envelope-down ) > envelope-down = "Envelope-Downgraded-From:" downchange CRLF / > "Envelope-Downgraded-To:" downchange CRLF > downchange = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] > "<" [CFWS] addr-spec [CFWS ">" [CFWS] agreed. I will try to add this. > ESMTP ORCPT parameter is used for Delivery Status Notifications > (DSNs) [RFC3461]. ... ORCPT > parameter downgrading should be defined here. > > Then please let us have a specific proposal for the next draft. It depends on ORCPT extension document. > 5. SMTP DATA/Header Downgrading > > As I said earlier, this needs a title that does not confine it to things > that appear in an SMTP DATA command. > > Originator address(es): ... > Destination address(es): ... > IDs: IDs such as Message-ID:, Date:, In-Reply-To: and References: ... > Trace headers: ... > > You need to add Content-Type, Content-Disposition, etc. to your list, > and also List-*. In my opinion, Content-Type, Content-Disposition headers are not expanded and do not contain UTF-8 characters. So it is included in other headers and they are not target of downgrading. I considered that List-* headers as normal unstructured headers. It needs more considerations. > Headers (Content-*) containing s will be downgraded according > to RFC 2231, and headers containing IRIs (List-*) according to RFC 3987. It's hard to define all headers' downgrading method. but it is necessary... Hmm... Are IRIs required to use IRI specific downgrading? Is encapsulating in Downgraded header allowed? In my previous opinion, to ease to implement, conversion target headers should be minimized, such as: From, Sender, Reply-To, To, CC, .... Previously I considered another headers are simply encoded in RFC 2047 or encapsulated to Downgraded header. Subject header or some unstructured headers are encoded in RFC 2047, but most other headers are not...... It requires more consideration. > 5.1. Header conversion > > To preserve all header information, define generic encapsulation > header: "Downgraded: HeaderName: HeaderValue". The header value is > encoded by [RFC2047] with UTF-8 tag. > > Again, some syntax is needed. I would suggest: > > fields =/ downgraded > downgraded = "Downgraded:" [CFWS] field-name ":" unstructured CRLF > field-name = 1*ftext > ftext = %d33-57 / %d59-126 ; printable ASCII except ":" I will add this. > Downgrading: > * Check if the mail has 'UTF8SMTP' header and its value is > "UTF8". Otherwise, downgrading is not required. > * Check each header whether it contains UTF-8 characters or not. > > You need to deal with the RFC 2047 stuff here: OK, > | If the header contains any , or any s > | or es > | + encode them according to RFC 2047 > | If the header contains UTF-8 characters, > | ^ > | still > + If the header is an address header which is described in > Section 5.1.1, > - Preserve the header in 'Downgraded' header. > No, that comes a little later > - Downgrade the header defined in Section 5.1.1. > | + If the header field contains any ... Section 5.1.2 > ... > | + If the header contains any IRI ... Section 5.1.3 ... > + Preserve the header in 'Downgraded' header. > > + The other header case, encode the header by [RFC2047] with > UTF-8 tag. > But NO!!! You cannot just apply RFC 2047 to any other header which just > happens to contain UTF-8. So far, nobody has defined any UTF-8 headers not > already covered above, but for sure they will appear in the future. The > only thing you can do with them (though maybe the guy who invented such a > header also invented a downgrade for it) is to create a Dowwgraded header > for it (which of course can then contain RFC 2047). agreed, but too many changes.... if possible, ... And we need to write complete downgradable structured/unstructured header list. Other headers should be encapsulated in "Downgraded" header, I think. > * Change 'UTF8SMTP' header value to "Downgraded". > > And point out that you don't need to create a Downgraded header field if > the only thing you did was to apply RFC 2047 to s, > s and s. agreed. > Upgrading: > > + If the header is address header described in Section 5.1.1, > - Apply address header downgrading to the decoded header. > Add "using the Downgraded header field" > - Remove the header line which is the same with the > downgraded line. > > What do you mean by "same"? Suppose the folding if different. Suppose > extra whitespace has appeared/disappeared? Suppose some RFC 2047 encoding > has been done differently, or with a different character set? > And what if there isn't any matdhing header? Surely that is a protocol > error? Do we want to define what happens in that case (e.g. leave the > header in place, in which case you may have two From (or To) headers, > which is a breach of RFC 2822)? This part needs detailed procedures: folding and whitespaces normalizations, error handlings, ... > + Remove the 'Downgraded' header. > + Add decoded header to mail header. > * If each mail header has [RFC2047] encoded part and which > encoding is "UTF-8", it is a downgraded header, so decode it. > And of course that is one possible cause why the upgraded header may not > be identical to the pre-downgraded header. I agree. > * Change 'UTF8SMTP' header value to "UTF8". > > Pros: > * EAI incompliant MUA displays the downgraded mail body except > > s/mail body/header field bodies/ updated. > Cons: > ... Also, restoration order of the > downgraded headers is not guaranteed. ... > > I think you ought to define exactly where the Downgraded headers and > modified headers are to be put (e.g. at the same place in the message as > the old version). This should be a "SHOULD". Ok, it is reasonable, I will add. > 5.1.1. Downgrading address headers > > The header value is composed of single or multiple mailbox/angle-addr > fields defined in [I-D.ietf-eai-utf8headers]. > > s/header value/header field body/ updated. > The next bit would need to be adapted to the changes I have suggested for > 5.1 above. I will update this part. > 2. By mailbox/angle-addr downgrading, if the field became empty, the > field should be removed. > 3. If all header field is removed, remove the header. > > But suppose the header was > From: "Joe Doe" > You will get > From: "Joe Doe" > which makes it Non-RFC 2822-compliant, but you cannot remove it because it > is not empty. Yes, I will consider this problem. > 4. If From header is removed, generate new From: header from > envelope-from address. > > Ugh! Though I cannot think of anything better. This part need more careful consideration. > 2. > Non-ASCII mail address without ALT-ADDRESS parameter case, > remove this angle-addr. > > No, that is not right. If the is > > then you should be able to translate the utf8-domain with punycode and > carry on. Agreed, but it may need more considerations. Without ALT-ADDRESS, US-ASCII user-part and UTF-8 domain-part address may be downgraded in SMTP Downgrading. May I consider the address which has ascii user-part and utf8 domain-part is US-ASCII mail address and mechanically transformable ? > And, as I have already said, I would still like to be able to translate > the using punycode, possible restricted by an > atomic/downgradable parameter. > > 8. IANA Considerations > > IANA is requested to add the "EAI-Downgraded-From:", > "EAI-Downgraded-To:" and "Downgraded:" new headers to the registry > with the entries pointing to this specification for its definition. > > No, you have to provide templates for all your new headers, as I explained > when commenting on the utf8headers draft. Ok, > Appendix A. Examples > > Some nice esamples here, but it would be better to show them as a > continuous series in one Appendix. As it is, each Appendix starts by > repeating where the previous Appendix left off, which is wasteful as well > as confusing. > > Message-Id: MESSAGE_ID > > s/MESSAGE_ID// in all the examples. > > From: > To: > CC: > > Please can we include some s and some cases of multiple > s in the same header in the examples? Ok, I will update. Thank you. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 20 15:06:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gazga-0007hr-Gi; Fri, 20 Oct 2006 15:05:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GazgZ-0007hh-IT for ima@ietf.org; Fri, 20 Oct 2006 15:05:39 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GazgP-0001Ec-VU for ima@ietf.org; Fri, 20 Oct 2006 15:05:39 -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.232) id 45391ded.65b0.7a2 for ima@ietf.org; Fri, 20 Oct 2006 20:05:18 +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 k9KJ57um019169 for ; Fri, 20 Oct 2006 20:05:08 +0100 (BST) To: "ima@ietf.org" Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 References: <20061020.220825.68136113.fujiwara@jprs.co.jp> Message-ID: Date: Fri, 20 Oct 2006 20:05:06 +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: <20061020.220825.68136113.fujiwara@jprs.co.jp> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de 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, 20 Oct 2006 14:08:25 +0100, wrote: >> From: "Charles Lindsey" >> Date: Mon, 04 Sep 2006 20:21:38 +0100 >> >> s/EAI/UTF8SMTP/ throughout the document, including in the title. > > I'm hesitating EAI or UTF8SMTP. > framework document is 'EAI Framework'. > Which is this protocol set name, EAI or UTF8SMTP ? I think some gathering at an IETF agreed that the visible name of our endeavour should have "UTF8" in it, and the provisional choice was "UTF8SMTP" (I would have preferred "UTF8-Headers" myself). I don't think the world out there is going to accept the term "EAI" (they will have enough trouble remembering what it stands for :-( ). >> And then s/mail header fields/mail header fields and in the headers >> fields >> of MIME multipart and message types/. >> >> Otherwise, an already downgraded message will get munged if it then >> encounters a non-8BITMIME server. > > not agreed. An already downgraded message is a normal rfc2822/rfc822 > message and it may contain 8bit(non-ascii) characters in the message > body. RFC 1652 capable SMTP agent treats it correctly. No it doesn't. A part of a multipart mixed has some headers (usually Content-Type and Content-Transfer-Encoding) before the body of that part. Now, those headers can contain UTF-8 (in comments at least, but also in s) and RFC 1652 does not know they have to be downgraded. Likewise the mail headers in message/rfc822. I am arguing with John about this one at the moment, so let us see how that goes. >> ESMTP ORCPT parameter is used for Delivery Status Notifications >> (DSNs) [RFC3461]. ... ORCPT >> parameter downgrading should be defined here. >> >> Then please let us have a specific proposal for the next draft. > > It depends on ORCPT extension document. OK, so long as it doesn't get forgotten. > >> 5. SMTP DATA/Header Downgrading >> You need to add Content-Type, Content-Disposition, etc. to your list, >> and also List-*. > > In my opinion, Content-Type, Content-Disposition headers are not > expanded and do not contain UTF-8 characters. So it is included in > other headers and they are not target of downgrading. They can certainly contain UTF8 in comments (they never do, of course, but it is allowed). The more realistic case is when a Content-Disposition contains a filename parameter in UTF-8. RFC 2231 is the proper downgrade there (ugly, but it works). > > I considered that List-* headers as normal unstructured headers. No, they are structured. There is ABNF for them, and they mostly contain URLs. >> Headers (Content-*) containing s will be downgraded according >> to RFC 2231, and headers containing IRIs (List-*) according to RFC 3987. > > It's hard to define all headers' downgrading method. but it is > necessary... > Hmm... > > Are IRIs required to use IRI specific downgrading? There is a standard downgrade to URI, described in RFC 3987. So you just have to tell people to use that. But isn't someone in this WG supposed to be writing a draft on mailing lists which would cover those headers? One would certainly wish IRIs/URIs to be readable by speakers of the relevant language. At the moment, a lot of them (URIs) can get horribly opaque, even to English speakers. > Is encapsulating in Downgraded header allowed? If it were done as an addition (like we are proposing even for address headers) it would be fine. You might get away with it as the sole mechanism if you assume that these IRIs don't need to be seen until the message has been upgraded at the far end. There, people will expect to be able to click on them, but they are not of much use during transport. > > In my previous opinion, to ease to implement, conversion target > headers should be minimized, such as: From, Sender, Reply-To, To, CC, > .... > > Previously I considered another headers are simply encoded in RFC 2047 > or encapsulated to Downgraded header. Agreed that all headers we do not recognise (and if they contain more than comments to be downgraded) will produce the Downgraded header only. That works well enough for headers that don't have to be looked at until after upgrading at the far end. I am not sure whether that is good enough for Content-Disposition, though. >> Upgrading: >> >> + If the header is address header described in Section 5.1.1, >> - Apply address header downgrading to the decoded header. >> Add "using the Downgraded header field" >> - Remove the header line which is the same with the >> downgraded line. >> >> What do you mean by "same"? Suppose the folding if different. Suppose >> extra whitespace has appeared/disappeared? Suppose some RFC 2047 >> encoding >> has been done differently, or with a different character set? >> And what if there isn't any matdhing header? Surely that is a protocol >> error? Do we want to define what happens in that case (e.g. leave the >> header in place, in which case you may have two From (or To) headers, >> which is a breach of RFC 2822)? > > This part needs detailed procedures: folding and whitespaces > normalizations, error handlings, ... I think, if you cannot identify the header that was downgraded in order to remove it, then you just have to leave it alone. In any case, some scammers are going to make them deliberately different, and that needs to be mentioned as a Security Issue >> 5.1.1. Downgrading address headers >> 4. If From header is removed, generate new From: header from >> envelope-from address. >> >> Ugh! Though I cannot think of anything better. > > This part need more careful consideration. >> > Without ALT-ADDRESS, US-ASCII user-part and UTF-8 domain-part address > may be downgraded in SMTP Downgrading. Correct. It is when there is a utf-8 local-part and no alt-address that we have problems. But I suspect that will be the common case for people who never expect to be mailing to pure-ascii-users. >> And, as I have already said, I would still like to be able to translate >> the using punycode, possible restricted by an >> atomic/downgradable parameter. -- 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 Sat Oct 21 00:10:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb89z-0006zP-Ma; Sat, 21 Oct 2006 00:08:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb89x-0006hr-Sb for ima@ietf.org; Sat, 21 Oct 2006 00:08:33 -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 1Gb7uy-0000nN-8p for ima@ietf.org; Fri, 20 Oct 2006 23:53:06 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Gb7uu-00043u-Ui; Fri, 20 Oct 2006 23:53:01 -0400 Date: Fri, 20 Oct 2006 23:52:59 -0400 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 Message-ID: <69395EF545F2B2B08A3B7A1A@p3.JCK.COM> In-Reply-To: References: <20061020.220825.68136113.fujiwara@jprs.co.jp> X-Mailer: Mulberry/4.0.6 (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: 5d7a7e767f20255fce80fa0b77fb2433 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, 20 October, 2006 20:05 +0100 Charles Lindsey wrote: > On Fri, 20 Oct 2006 14:08:25 +0100, > wrote: >... >>> And then s/mail header fields/mail header fields and in the >>> headers fields >>> of MIME multipart and message types/. >>> >>> Otherwise, an already downgraded message will get munged if >>> it then encounters a non-8BITMIME server. >> >> not agreed. An already downgraded message is a normal >> rfc2822/rfc822 message and it may contain 8bit(non-ascii) >> characters in the message body. RFC 1652 capable SMTP agent >> treats it correctly. > > No it doesn't. A part of a multipart mixed has some headers > (usuallyContent-Type and Content-Transfer-Encoding) before the > body of that part.Now, those headers can contain UTF-8 (in > comments at least, but also ins) and RFC 1652 does > not know they have to be downgraded.Likewise the mail headers > in message/rfc822. I am arguing with John aboutthis one at the > moment, so let us see how that goes. We don't have much of an argument. You are assuming that those attached MIME headers (C-T and C-T-E) can (and, I assume, should) be permitted to contain non-ASCII characters). I am assuming that is reasonable iff (i) the utf8headers document is explicit about it (which it had better be, one way or the other) and (ii) if there is a plan for downgrading those headers that is clear and reversible without loss of information. Clearly, RFC 1652 downgrading cannot apply to such headers -- it (as you point out) doesn't know and can't be expected to know. This is _not_ a proposal, and I hope we don't need to go in this direction. However, it occurs to me that one way out of many of these problems would be to require that the host proposing to downgrade a message check each header for the presence of 8bit characters. Then, if it recognizes each one --knows the header name and the syntax rules for that header-- it can downgrade the message. If not (i.e., if there are any headers containing 8bit characters that are not explicitly known to the MTA), then the message must be rejected or an NDN issued. >... >>> 5. SMTP DATA/Header Downgrading > >>> You need to add Content-Type, Content-Disposition, etc. to >>> your list, and also List-*. >> >> In my opinion, Content-Type, Content-Disposition headers are >> not expanded and do not contain UTF-8 characters. So it is >> included in other headers and they are not target of >> downgrading. > > They can certainly contain UTF8 in comments (they never do, of > course, butit is allowed). Again, it seems to me that it is allowed only if we decide to allow it. Certainly it is not allowed under 2822, which restricts all headers and all fields, including comments, to ASCII. > The more realistic case is when a > Content-Dispositioncontains a filename parameter in UTF-8. RFC > 2231 is the proper downgradethere (ugly, but it works). Actually, it doesn't work. In the general case, the downgrading MTA can't possibly know anything about the syntax of a filename on the system containing the delivery MUA (not just MTA) -- that filename is interpreted on the far side of POP or IMAP servers if they are used. In particular, as far as it knows, the encoded word form is a valid filename on the target system _and_ that system supports non-ASCII file names as well (not necessarily UTF-8 ones). My guess is that the only possible downgrade mechanism for a Content-disposition header containing 8bit information is to discard it -- or at least to discard any parameters with 8bit values. >... >>> Headers (Content-*) containing s will be >>> downgraded according to RFC 2231, and headers containing >>> IRIs (List-*) according to RFC 3987. >> >> It's hard to define all headers' downgrading method. but it >> is necessary... >> Hmm... >> >> Are IRIs required to use IRI specific downgrading? > > There is a standard downgrade to URI, described in RFC 3987. > So you justhave to tell people to use that. But isn't someone > in this WG supposed tobe writing a draft on mailing lists > which would cover those headers? Onewould certainly wish > IRIs/URIs to be readable by speakers of the relevantlanguage. > At the moment, a lot of them (URIs) can get horribly > opaque,even to English speakers. But even knowing that something is an IRI or URI requires either heuristics (bad news) of knowledge of a particular header and its syntax. I don't see how one applies IRI-> URI downgrading to a string in an arbitrary unknown field. >... >>> And, as I have already said, I would still like to be able >>> to translate the using punycode, possible >>> restricted by an atomic/downgradable parameter. But that idea was already rejected by the WG. More important, whatever you do, you can't use punycode, which is case-insensitive. You would need a different ACE. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 21 01:45:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb9fh-0003Y6-At; Sat, 21 Oct 2006 01:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gb9fg-0003W0-5J for ima@ietf.org; Sat, 21 Oct 2006 01:45:24 -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 1Gb9fY-000598-KO for ima@ietf.org; Sat, 21 Oct 2006 01:45:24 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gb9fG-0000DL-NH for ima@ietf.org; Sat, 21 Oct 2006 07:44:59 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Oct 2006 07:44:58 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Oct 2006 07:44:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 Date: 21 Oct 2006 08:44:45 +0300 Lines: 65 Message-ID: <5dvemegr3m.fsf@Hurtta06k.keh.iki.fi> References: <20061020.220825.68136113.fujiwara@jprs.co.jp> <69395EF545F2B2B08A3B7A1A@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin writes gmane.ietf.ima: > --On Friday, 20 October, 2006 20:05 +0100 Charles Lindsey > wrote: > > > On Fri, 20 Oct 2006 14:08:25 +0100, > > wrote: > >... > > > The more realistic case is when a > > Content-Dispositioncontains a filename parameter in UTF-8. RFC > > 2231 is the proper downgradethere (ugly, but it works). > > Actually, it doesn't work. In the general case, the downgrading > MTA can't possibly know anything about the syntax of a filename > on the system containing the delivery MUA (not just MTA) -- that > filename is interpreted on the far side of POP or IMAP servers > if they are used. In particular, as far as it knows, the > encoded word form is a valid filename on the target system _and_ > that system supports non-ASCII file names as well (not > necessarily UTF-8 ones). My guess is that the only possible > downgrade mechanism for a Content-disposition header containing > 8bit information is to discard it -- or at least to discard any > parameters with 8bit values. I think that there is little disagreement :-) If there is Content-Type: text/plain Content-Disposition: attachment; filename="Ääkkösiä nimessä.txt" downgrade can produce something like Content-Type: text/plain Content-Disposition: attachment; filename*0*=UTF-8''%C3%84%C3%A4kk%C3%B6si%C3%A4%20nimess; filename*1*=%C3%A4%2Etxt If MUA does not understand RFC 2231, MUA does not see filename parameter here (it looks like thare is parameters "filename*0*" and "filename*1*"). If MUA undrestands RFC 2231, there is charset given on parameter. Sure it is then prepared to convert charset to locally used character set/encoding. And MUA must be prepared to check syntax of filename also when RFC 2231 is not used (adn there is ASCII only filename). In general MUA which may allow saving attachments, need anyway (prepared to) adjust given filename. Converting MTA does not know syntax for filenames used on recipient's MUA, but sending system either does not know syntax for filenames used on recipient's MUA -- this same happens also with ASCII only filenames. / Kari Hurtta I exactly do not follow RFC 2231 by default here. My MUA produces also ASCII only filename: Content-Type: text/plain Content-Disposition: attachment; filename*0*=UTF-8''%C3%84%C3%A4kk%C3%B6si%C3%A4%20nimess; filename*1*=%C3%A4%2Etxt; filename="____kk__si__ nimess__.txt" _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 21 02:14:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbA7h-0000uM-V2; Sat, 21 Oct 2006 02:14:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbA7g-0000u4-Hz for ima@ietf.org; Sat, 21 Oct 2006 02:14:20 -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 1GbA7f-0001Sa-0t for ima@ietf.org; Sat, 21 Oct 2006 02:14:20 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GbA7S-0003lu-BM for ima@ietf.org; Sat, 21 Oct 2006 08:14:06 +0200 Received: from pd9fbadac.dip0.t-ipconnect.de ([217.251.173.172]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Oct 2006 08:14:06 +0200 Received: from nobody by pd9fbadac.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Oct 2006 08:14:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 Date: Sat, 21 Oct 2006 08:11:34 +0200 Organization: Lines: 52 Message-ID: <4539BA16.273F@xyzzy.claranet.de> References: <20061020.220825.68136113.fujiwara@jprs.co.jp> <69395EF545F2B2B08A3B7A1A@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadac.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: >>>> You need to add Content-Type, Content-Disposition, etc. to >>>> your list, and also List-*. >>> In my opinion, Content-Type, Content-Disposition headers are >>> not expanded and do not contain UTF-8 characters. So it is >>> included in other headers and they are not target of >>> downgrading. >> They can certainly contain UTF8 in comments (they never do, of >> course, butit is allowed). > Again, it seems to me that it is allowed only if we decide to > allow it. Certainly it is not allowed under 2822, which > restricts all headers and all fields, including comments, to > ASCII. RFC 2046 is already at DS (unlike 2822), and screwing with MIME is dangerous. The WG charter explicitly mentions mailing lists, that _could_ cover List-*. > I don't see how one applies IRI-> URI downgrading to a string > in an arbitrary unknown field. Until 2368bis exists let's ignore this as too difficult, folks can use URLs in header fields, and translate any IRI to an URL. >>>> I would still like to be able to translate the >>>> using punycode, possible restricted by an atomic/downgradable >>>> parameter. > But that idea was already rejected by the WG. When was that ? I vaguely recall a statement posted by Harald, and a debate about consensus on the list or elsewhere, with an outcome of "elsewhere is irrelevant" (?) > you can't use punycode, which is case-insensitive. You would > need a different ACE. The author told us that it's not necessarily case-insensitive: || the underlying Punycode algorithm will copy case-sensitively || perfectly satisfactorily (even using their model implementation | | Right. I designed Punycode to work for case-sensitive text, | case-insensitive text, and case-insensitive case-preserving text. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 21 14:37:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbLiO-0002mH-2p; Sat, 21 Oct 2006 14:37:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbLiM-0002lt-Ox for ima@ietf.org; Sat, 21 Oct 2006 14:36:58 -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 1GbLiL-00067C-F2 for ima@ietf.org; Sat, 21 Oct 2006 14:36:58 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GbLiJ-0005Qf-1P for ima@ietf.org; Sat, 21 Oct 2006 20:36:55 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Oct 2006 20:36:55 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Oct 2006 20:36:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: [OT] SMTP (Re: [EAI] ISSUE: framework 4.1 - reject) Date: 21 Oct 2006 21:36:48 +0300 Lines: 50 Message-ID: <5diridwm67.fsf_-_@Hurtta06k.keh.iki.fi> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: > Actually, this is the normal case, but is not required. In > principle, the following model is consistent with SMTP. Given > servers A, B, and C, the following sequence of events is > possible and permitted: > > A opens connection to B > A->B: EHLO [...] > B->A: (response) > A->B: MAIL FROM: [...] > B->A: 220 ok > A->B: RCPT TO: > B opens connection to C > B->C: EHLO [...] > C->B: (response) > B->C: MAIL FROM: [...] > C->B: 220 ok > B->C: RCPT TO: > C->B: 550 Not here, please go away and don't come back > B->A: 550 user not at C > A->B: QUIT > B->C: QUIT > > and so on. There have actually been proposals that would > require doing things this way. They haven't gone anywhere for > reasons that should be obvious, but the sequence is permitted by > all of the relevant protocol specifications. > > > SMTP is store and forward protocol. > > Yes. But while overlapping receipt and forwarding is rare, it > is not prohibited. Well, on one point there is problem. With final '.' you need store mail, if there is more than one recipient for different @domain part. B can not act as proxy in that case (assuming that it does not tempfail some recipients so that all recipients left point to same MX) LMTP avoids that problem. So SMTP is a store and forward protocol on general case. > john > > > john / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 21 14:53:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbLyR-0008Ac-Mz; Sat, 21 Oct 2006 14:53:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbLyQ-0008AN-Ss for ima@ietf.org; Sat, 21 Oct 2006 14:53:34 -0400 Received: from smtp2gate.fmi.fi ([193.166.223.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbLyP-0000Id-Ek for ima@ietf.org; Sat, 21 Oct 2006 14:53:34 -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-20041007) with ESMTP id k9LIrQvC009080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 21 Oct 2006 21:53:26 +0300 Received: from siilo.fmi.fi by virkku.fmi.fi with ESMTP id k9LIrQX9010155 ; Sat, 21 Oct 2006 21:53:26 +0300 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id k9LIrQAb019837 ; Sat, 21 Oct 2006 21:53:26 +0300 Received: by siilo.fmi.fi id k9LIrOhi019834; Sat, 21 Oct 2006 21:53:24 +0300 Message-Id: <200610211853.k9LIrOhi019834@siilo.fmi.fi> Subject: Re: [EAI] draft-ietf-eai-utf8headers-01.txt question In-Reply-To: To: John C Klensin Date: Sat, 21 Oct 2006 21:53:24 +0300 (EEST) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123d (25)] MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Filter: smtp2gate: 3 received headers rewritten with id 20061021/26708/01 X-Filter: smtp2gate: ID 26703/01, 1 parts scanned for known viruses X-Filter: virkku: ID 18606/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.4 required=5 (smtp2gate: ID 26703/01) report=AWL,BAYES_00,FORGED_RCVD_HELO Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by smtp2gate.fmi.fi id k9LIrQvC009080 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Kari Hurtta , EAI mailing list 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 >=20 >=20 > --On Wednesday, 18 October, 2006 18:24 +0800 Jeff > wrote: >=20 > >=20 > >=20 > > Kari Hurtta wrote: > >> draft-ietf-eai-utf8headers-01.txt: > >>=20 > >> angle-addr =3D [CFWS] "<" utf8-addr-spec [alt-address] > >> ">" [CFWS] > >>=20 > >> alt-address =3D "{" [CFWS] addr-spec [CFWS] "}" > >>=20 > > How about use "[" and "]" as the bracket? > > This was discussed before. (Thanks Charles and Tony.) > > That is : > > alt-address =3D "[" [CFWS] addr-spec [CFWS] "]" >=20 > Hi. >=20 > Maybe it is no longer relevant today, but "[" and "]" were > excluded from the original characters permitted in email > addresses (and lots of other places) because it is in a > national-use position in ISO 646 BV. Should it displayed by an > ISO 646 rendering engine in a country that uses those positions, > the output could be very strange indeed (the UTF-8 showing up as > boxes or question-marks and the brackets and nationally-selected > characters). >=20 > It may still be a good choice, but we should understand the > implications of what we are doing. >=20 > john I'm not sure that I understand. [ ] are definately used on e-mail address. RFC 2822: addr-spec =3D local-part "@" domain domain =3D dot-atom / domain-literal / obs-domain domain-literal =3D [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS] These are rare, but seen. / Kari Hurtta PS. If I remember correctly, in Finnish/Swedish ISO 646 variation these= was [ =3D> =C4 ] =3D> =C5 \ =3D> =D6 or something like that. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 21 15:32:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbMa5-0004wH-M0; Sat, 21 Oct 2006 15:32:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbMZs-0004oA-PK for ima@ietf.org; Sat, 21 Oct 2006 15:32:17 -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 1GbMZr-0006VG-4t for ima@ietf.org; Sat, 21 Oct 2006 15:32:16 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GbMZm-000D0k-HX; Sat, 21 Oct 2006 15:32:10 -0400 Date: Sat, 21 Oct 2006 15:32:09 -0400 From: John C Klensin To: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-utf8headers-01.txt question Message-ID: <8E9970438FF9B1DE95711D3E@p3.JCK.COM> In-Reply-To: <200610211853.k9LIrOhi019834@siilo.fmi.fi> References: <200610211853.k9LIrOhi019834@siilo.fmi.fi> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: EAI mailing list 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, 21 October, 2006 21:53 +0300 Kari Hurtta wrote: >>>> John C Klensin >>=20 >>=20 >> --On Wednesday, 18 October, 2006 18:24 +0800 Jeff >> wrote: >>=20 >> >=20 >> >=20 >> > Kari Hurtta wrote: >> >> draft-ietf-eai-utf8headers-01.txt: >> >>=20 >> >> angle-addr =3D [CFWS] "<" utf8-addr-spec >> >> [alt-address] ">" [CFWS] >> >>=20 >> >> alt-address =3D "{" [CFWS] addr-spec [CFWS] "}" >> >>=20 >=20 >> > How about use "[" and "]" as the bracket? >> > This was discussed before. (Thanks Charles and Tony.) >> > That is : >> > alt-address =3D "[" [CFWS] addr-spec [CFWS] "]" >>=20 >> Hi. >>=20 >> Maybe it is no longer relevant today, but "[" and "]" were >> excluded from the original characters permitted in email >> addresses (and lots of other places) because it is in a >> national-use position in ISO 646 BV. Should it displayed by >> an ISO 646 rendering engine in a country that uses those >> positions, the output could be very strange indeed (the UTF-8 >> showing up as boxes or question-marks and the brackets and >> nationally-selected characters). >>=20 >> It may still be a good choice, but we should understand the >> implications of what we are doing. >>=20 >> john >=20 > I'm not sure that I understand. [ ] are definately used on > e-mail address. >=20 > RFC 2822: >=20 > addr-spec =3D local-part "@" domain >=20 > domain =3D dot-atom / domain-literal / = obs-domain >=20 > domain-literal =3D [CFWS] "[" *([FWS] dcontent) [FWS] = "]" > [CFWS] Yes. But we strongly discourage domain literals, and that doesn't make it a good idea. I want to stress that I don't consider it a showstopper either, but we should not walk into this without consideration of the implications. > These are rare, but seen. Less rare than one might like. > PS. If I remember correctly, in Finnish/Swedish ISO 646 > variation these was [ =3D> =C3=84 > ] =3D> =C3=85 > \ =3D> =C3=96 > or something like that. That sounds about right. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 21 15:33:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbMZn-0004nU-Ne; Sat, 21 Oct 2006 15:32:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbMZm-0004Uk-Eg for ima@ietf.org; Sat, 21 Oct 2006 15:32:10 -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 1GbMOH-000406-HG for ima@ietf.org; Sat, 21 Oct 2006 15:20:18 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GbMOB-0003QY-U1 for ima@ietf.org; Sat, 21 Oct 2006 21:20:11 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Oct 2006 21:20:11 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Oct 2006 21:20:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: message/TBD and RFC 2046 (Re: [EAI] Re: MIME subpart) Date: 21 Oct 2006 22:20:02 +0300 Lines: 45 Message-ID: <5dd58lwk65.fsf_-_@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <5dmz846l83.fsf@Hurtta06k.keh.iki.fi> <452C0BF6.6F6@xyzzy.claranet.de> <5dzmc3h5nn.fsf@Hurtta06k.keh.iki.fi> <5dvemrh4hu.fsf_-_@Hurtta06k.keh.iki.fi> <5dr6xfh4by.fsf@Hurtta06k.keh.iki.fi> <452CAD7E.6BBE@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > Kari Hurtta wrote: > > >> Content-Type: message/utf8message; | > >> boundary="{new-boundary}" | > > > this is mistake. "message/utf8message" should be > > "multipart/utf8message" > > Yes, you want a boundary. > > Okay, RFC 2045 says EXPRESSLY FORBIDDEN about base64 for message/*. > But it does allow 8bit as needed by a hypothetical message/utf8smtp. > With that you'd get... > > =============================== > converted-header-fields > MIME-Version: 1.0 > Content-Transfer-Encoding: 8bit > Content-Type: message/utf8smtp > > original-utf-8 header-fields > > original body > =============================== Then there is RFC 2046 which writes: | 5.2.4. Other Message Subtypes | | MIME implementations must in general treat unrecognized subtypes of | "message" as being equivalent to "application/octet-stream". | | Future subtypes of "message" intended for use with email should be | restricted to "7bit" encoding. A type other than "message" should be | used if restriction to "7bit" is not possible. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 21 15:39:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbMgq-0000wR-PL; Sat, 21 Oct 2006 15:39:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbMgq-0000wM-2V for ima@ietf.org; Sat, 21 Oct 2006 15:39:28 -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 1GbMgo-0007yf-Mf for ima@ietf.org; Sat, 21 Oct 2006 15:39:28 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GbMgo-000D4M-AN; Sat, 21 Oct 2006 15:39:26 -0400 Date: Sat, 21 Oct 2006 15:39:25 -0400 From: John C Klensin To: Kari Hurtta , ima@ietf.org Subject: Re: message/TBD and RFC 2046 (Re: [EAI] Re: MIME subpart) Message-ID: <6E301C1766F7C2E9F1AD3366@p3.JCK.COM> In-Reply-To: <5dd58lwk65.fsf_-_@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <5dmz846l83.fsf@Hurtta06k.keh.iki.fi> <452C0BF6.6F6@xyzzy.claranet.de> <5dzmc3h5nn.fsf@Hurtta06k.keh.iki.fi> <5dvemrh4hu.fsf_-_@Hurtta06k.keh.iki.fi> <5dr6xfh4by.fsf@Hurtta06k.keh.iki.fi> <452CAD7E.6BBE@xyzzy.claranet.de> <5dd58lwk65.fsf_-_@Hurtta06k.keh.iki.fi> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Saturday, 21 October, 2006 22:20 +0300 Kari Hurtta wrote: > Frank Ellermann writes in > gmane.ietf.ima: > >> Kari Hurtta wrote: >> >> >> Content-Type: message/utf8message; | >> >> boundary="{new-boundary}" | >> >> > this is mistake. "message/utf8message" should be >> > "multipart/utf8message" >> >> Yes, you want a boundary. >> >> Okay, RFC 2045 says EXPRESSLY FORBIDDEN about base64 for >> message/*. But it does allow 8bit as needed by a hypothetical >> message/utf8smtp. With that you'd get... >> >> =============================== >> converted-header-fields >> MIME-Version: 1.0 >> Content-Transfer-Encoding: 8bit >> Content-Type: message/utf8smtp >> >> original-utf-8 header-fields >> >> original body >> =============================== > > > Then there is RFC 2046 which writes: > > > | 5.2.4. Other Message Subtypes > | > | MIME implementations must in general treat unrecognized > subtypes of | "message" as being equivalent to > "application/octet-stream". | Note that this means that, if I am a legacy MUA or MTA, and I receive a message/utf8smtp body part and, being a legacy implementation, don't understand it, then I must treat it as completely opaque, with no chance of displaying it or trying to decode it. > | Future subtypes of "message" intended for use with email > should be | restricted to "7bit" encoding. A type other > than "message" should be | used if restriction to "7bit" is > not possible. Are we creeping toward either an amendment to that text in 2046 or a new top-level type for, e.g., "message8/" ? john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 21 16:00:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbN0p-00055X-Q0; Sat, 21 Oct 2006 16:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbN0o-000542-5n for ima@ietf.org; Sat, 21 Oct 2006 16:00:06 -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 1GbMq9-0000v4-JG for ima@ietf.org; Sat, 21 Oct 2006 15:49:06 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GbMq9-000DAN-5o; Sat, 21 Oct 2006 15:49:05 -0400 Date: Sat, 21 Oct 2006 15:49:04 -0400 From: John C Klensin To: Kari Hurtta , ima@ietf.org Subject: Re: [OT] SMTP (Re: [EAI] ISSUE: framework 4.1 - reject) Message-ID: <68D99A8832AFDE2885A98F09@p3.JCK.COM> In-Reply-To: <5diridwm67.fsf_-_@Hurtta06k.keh.iki.fi> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <5diridwm67.fsf_-_@Hurtta06k.keh.iki.fi> X-Mailer: Mulberry/4.0.6 (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: c0bedb65cce30976f0bf60a0a39edea4 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 Saturday, 21 October, 2006 21:36 +0300 Kari Hurtta wrote: > John C Klensin writes in gmane.ietf.ima: > >> Actually, this is the normal case, but is not required. In >> principle, the following model is consistent with SMTP. Given >> servers A, B, and C, the following sequence of events is >> possible and permitted: >> >> A opens connection to B >> A->B: EHLO [...] >> B->A: (response) >> A->B: MAIL FROM: [...] >> B->A: 220 ok >> A->B: RCPT TO: >> B opens connection to C >>... >> and so on. There have actually been proposals that would >> require doing things this way. They haven't gone anywhere for >> reasons that should be obvious, but the sequence is permitted >> by all of the relevant protocol specifications. >> >> > SMTP is store and forward protocol. >> >> Yes. But while overlapping receipt and forwarding is rare, it >> is not prohibited. > > Well, on one point there is problem. With final '.' you need > store mail, if there is more than one recipient for different > @domain part. Nope. B can, in principle, have connections open to each destination domain, can do the needed verification in parallel, etc. The odds of A getting a clear and unambiguous SMTP-time rejection if one of the recipient hosts accepts the message after DATA and the message body and others do not are not high, but they are not high any time a failure reply code is returned after the body data are transmitted with a multiple-recipient message, whether the recipients are in the same or different domains. That is at least one reason why, in practice, NDNs, and not failure reply codes, are almost always returned if a problem is encountered after the 354 code is returned in response to DATA. I grant this is getting increasingly unlikely. > B can not act as proxy in that case > (assuming that it does not tempfail some recipients so that > all recipients left point to same MX) > > LMTP avoids that problem. Sure. So does anything whose batching model is strong enough that NDNs are just about the only way to report most errors. But, if I correctly understand his position, Frank would like to ban the lot of those things as encouraging spammers and/or DoS attacks, at least barring strongly authenticated senders. > So SMTP is a store and forward protocol on general case. In the general, and common, cases, no question about it. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 21 16:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbNOp-0003P1-95; Sat, 21 Oct 2006 16:24:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbNOo-0003Oo-28 for ima@ietf.org; Sat, 21 Oct 2006 16:24:54 -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 1GbNOm-00088r-L6 for ima@ietf.org; Sat, 21 Oct 2006 16:24:54 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GbNOa-0005aP-Fm for ima@ietf.org; Sat, 21 Oct 2006 22:24:40 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Oct 2006 22:24:40 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Oct 2006 22:24:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: message/TBD and RFC 2046 (Re: [EAI] Re: MIME subpart) Date: 21 Oct 2006 23:24:32 +0300 Lines: 56 Message-ID: <5d8xj9wh6n.fsf@Hurtta06k.keh.iki.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <5dmz846l83.fsf@Hurtta06k.keh.iki.fi> <452C0BF6.6F6@xyzzy.claranet.de> <5dzmc3h5nn.fsf@Hurtta06k.keh.iki.fi> <5dvemrh4hu.fsf_-_@Hurtta06k.keh.iki.fi> <5dr6xfh4by.fsf@Hurtta06k.keh.iki.fi> <452CAD7E.6BBE@xyzzy.claranet.de> <5dd58lwk65.fsf_-_@Hurtta06k.keh.iki.fi> <6E301C1766F7C2E9F1AD3366@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: <...> > Are we creeping toward either an amendment to that text in 2046 > or a new top-level type for, e.g., "message8/" ? > > john ( summary: I do not know answer. ) Uhh. Any unknown (as not know how to parse) composite types have same problems. message/TBD and TBD/* are equal bad, If TBD/* is considered to be composite. But these really do not matter if EAI documents allow these only on UTF8SMTP environment. Then can say "not for mail" == "not for EAI-incompliant mail" If type is restricted of UTF8SMTP environment then any of message/rfc822 with UTF-8 header fields message/utf8smtp message8/mail will work. Any of these are on problems if they are allowed to see by EAI-incompliant MTA or MUA (or if they leaked). Any of these needs some kind downgrading when leaving UTF8SMTP. Unkwnown discrete types are OK on MIME. ( For new top level types there is MTAs and MUAs also problem that they do not know is they composite or discrete. I suspect that 'discrete' is assumed by default. This means that double encoding can not avoided. ) Hmm. Perhaps message8/* works best, because it will most likely to be treated as discrete (and therefore base64 or quoted-printable encoded for example on 8BITMIME downgrading. ) This of course requires that double encoding rules must be lifted for message8/* / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Oct 22 00:27:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbUut-0005W1-EV; Sun, 22 Oct 2006 00:26:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbUus-0005Vu-3J for ima@ietf.org; Sun, 22 Oct 2006 00:26:30 -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 1GbUul-0000JQ-PH for ima@ietf.org; Sun, 22 Oct 2006 00:26:30 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GbUuR-0007wE-DK for ima@ietf.org; Sun, 22 Oct 2006 06:26:14 +0200 Received: from pd9fba954.dip0.t-ipconnect.de ([217.251.169.84]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Oct 2006 06:26:03 +0200 Received: from nobody by pd9fba954.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Oct 2006 06:26:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-utf8headers-01.txt question Date: Sun, 22 Oct 2006 06:23:51 +0200 Organization: Lines: 24 Message-ID: <453AF257.661C@xyzzy.claranet.de> References: <200610211853.k9LIrOhi019834@siilo.fmi.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba954.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) 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 Kari Hurtta wrote: [John wrote] >> Maybe it is no longer relevant today, but "[" and "]" were >> excluded from the original characters permitted in email >> addresses (and lots of other places) because it is in a >> national-use position in ISO 646 BV. Should it displayed by an >> ISO 646 rendering engine in a country that uses those positions, >> the output could be very strange indeed Why would a box in a museum try to display raw UTF-8 header fields with an optional enclosed in curly braces or square brackets ? The historical issue is the same, in C it got us ??(, ??<, ??), ??> among others. Here's the German version (ISO 646-DE or DIN 66003): http://www.mi.uni-koeln.de/c/mirror/www.kostis.net/charsets/iso646.de.html I've never seen it anywhere in practice. I don't see how it could affect UTF-8 headers, but if it does then [\] aren't worse than {|}. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Oct 22 15:00:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbiYE-0008Ix-By; Sun, 22 Oct 2006 15:00:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbiYD-0008IP-Cl for ima@ietf.org; Sun, 22 Oct 2006 15:00:01 -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 1GbiXC-0003ax-Gu for ima@ietf.org; Sun, 22 Oct 2006 14:59:03 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GbiX6-0000ok-NM for ima@ietf.org; Sun, 22 Oct 2006 20:58:52 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Oct 2006 20:58:52 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Oct 2006 20:58:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: [OT] RFC 2047 decoding (Re: [EAI] ISSUE: framework -3 - missing MIME considerations) Date: 22 Oct 2006 21:58:43 +0300 Lines: 28 Message-ID: <5dac3o9nz0.fsf_-_@Hurtta06k.keh.iki.fi> References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 "Charles Lindsey" writes in gmane.ietf.ima: > So the best thing to do is to omit the From header entirely (which it > is in fact legal to do in a message/rfc822). > > But all is not yet lost, because the downgrade process will also have > created > > Downgraded: From: From header> > > and (unless his MUA is being excessively obstinate, or has not the > fonts to display it), Bob should be able to see that (though whether > it gives him enough to reply to Ã…lice is less certain). Yes. Obstinate is perhaps correct word :-) I do not decode RFC2047 encoding on headers, which I do not know syntax (syntax "*text" is assumed only for X- headers. ) Most MUAs probaly do not show randow headers (if not something like "All headers" toggle is pressed.) / Kari Hurtta ( yes, I checked 'obstinate' from dictionary. ) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Oct 22 15:10:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbii1-0000L8-Uj; Sun, 22 Oct 2006 15:10:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbii0-0000JP-M9 for ima@ietf.org; Sun, 22 Oct 2006 15:10:08 -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 1Gbihz-0005t2-8y for ima@ietf.org; Sun, 22 Oct 2006 15:10:08 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gbihx-0002kx-TZ for ima@ietf.org; Sun, 22 Oct 2006 21:10:05 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Oct 2006 21:10:05 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Oct 2006 21:10:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Return-Path and draft-ietf-eai-utf8headers-01.txt (Re: [EAI] ISSUE: framework -3 - missing MIME considerations) Date: 22 Oct 2006 22:09:55 +0300 Lines: 45 Message-ID: <5d64ec9ngc.fsf_-_@Hurtta06k.keh.iki.fi> References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > > Ah! You want to use that bit in 5.1.1 of the downgrade document > > which says to use the envelope-from in that case. I always thought > > that was a bit iffy, and said so whenb I commented on that draft on > > Sept 4th. Indeed, it has never been clear to me how the originating > > MUA was able to provide an in the envelope-from if it > > did not find/put one in the header From: at the same time. > > But, on further thoughts, that envelope-from of Ã…lice's original > message IS available if you want to transfer it into the From header > during the downgrade. You will find it in the Return-Path of her > message. draft-ietf-eai-utf8headers-01.txt: angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] utf8-addr-spec = utf8-local-part "@" utf8-domain utf8-local-part= utf8-dot-atom / quoted-string / obs-local-part utf8-domain = utf8-dot-atom / domain-literal / obs-domain alt-address = "{" [CFWS] addr-spec [CFWS] "}" RFC 2822: return = "Return-Path:" path CRLF path = ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) / obs-path >From that reading of syntax Return-Path seems allow only ASCII addresses. So yes, downgraded envelope address as found from Return-Path. (Original UTF8 address from MAIL FROM seems not be available however. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 23 05:23:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbw17-0005LM-Gz; Mon, 23 Oct 2006 05:22:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbw16-0005Kv-0W for ima@ietf.org; Mon, 23 Oct 2006 05:22:44 -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 1Gbw14-0003jf-Jz for ima@ietf.org; Mon, 23 Oct 2006 05:22:43 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gbw0w-0001Ej-Aq for ima@ietf.org; Mon, 23 Oct 2006 11:22:34 +0200 Received: from pd9fbad2a.dip0.t-ipconnect.de ([217.251.173.42]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Oct 2006 11:22:34 +0200 Received: from nobody by pd9fbad2a.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Oct 2006 11:22:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 7 - missing local part (ab)uses as label Date: Mon, 23 Oct 2006 11:21:34 +0200 Organization: Lines: 24 Message-ID: <453C899E.124F@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <453446AA.739F@xyzzy.claranet.de> <5DAAD30D180E1A4125249F98@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad2a.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) 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 John C Klensin wrote: > I don't know what you have in mind, so please supply specific > draft text so that the WG can look at it. Something like that: | 7.5 Other uses of local parts | | Local parts are sometimes used to construct domain labels, e.g. | the local part "user" in the address user@domain.example could | be converted into a vanity host user.domain.example with Web | space at and catchall addresses | any.thing.goes@user.domain.example. | | Such schemes are obviously limited by among others the LDH rule, | and won't work for other local parts like the | specified in [I-D.ietf-eai-utf8headers]. So far it's obvious, but I've no idea which wild and wonderful uses of local parts might exist in addition to this simple case. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 23 05:32:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbwAy-00006Z-Lg; Mon, 23 Oct 2006 05:32:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbwAx-0008W3-Bz for ima@ietf.org; Mon, 23 Oct 2006 05:32:55 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbwAq-0006HG-0A for ima@ietf.org; Mon, 23 Oct 2006 05:32: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-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 453c8c3b.4c6f.96 for ima@ietf.org; Mon, 23 Oct 2006 10:32:43 +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 k9N9WfmL023063 for ; Mon, 23 Oct 2006 10:32:42 +0100 (BST) To: "ima@ietf.org" Subject: Re: Return-Path and draft-ietf-eai-utf8headers-01.txt (Re: [EAI] ISSUE: framework -3 - missing MIME considerations) References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> <5d64ec9ngc.fsf_-_@Hurtta06k.keh.iki.fi> Message-ID: Date: Mon, 23 Oct 2006 10:32:39 +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: <5d64ec9ngc.fsf_-_@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, 22 Oct 2006 20:09:55 +0100, Kari Hurtta wrote: > "Charles Lindsey" writes in gmane.ietf.ima: >> But, on further thoughts, that envelope-from of Ålice's original >> message IS available if you want to transfer it into the From header >> during the downgrade. You will find it in the Return-Path of her >> message. > > draft-ietf-eai-utf8headers-01.txt: > > angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] > > RFC 2822: > > return = "Return-Path:" path CRLF > > path = ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) / > obs-path I think the intention was that utf8hdrs should permit utf8-addr-spec everywhere that addr-spec was allowed, except inside an alt-address, obviously. So it looks like that case got forgotten. Actually, I think what utf8hdrs needs to say about Return-Path is return = "Return-Path:" path CRLF path = ([CFWS] ( angle-addr / "<" ([CFWS] ">") [CFWS]) / obs-path Then, if a compliant MDA still has a MAIL FROM with both primary and alt addresses intact, it can put them both into the Return-Path (and the smtpext doc should say that). -- 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 Oct 23 06:31:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbx5W-0002vG-Dx; Mon, 23 Oct 2006 06:31:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbx5W-0002v4-3E for ima@ietf.org; Mon, 23 Oct 2006 06:31:22 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gbx5P-00028N-D2 for ima@ietf.org; Mon, 23 Oct 2006 06:31:22 -0400 Received: (snipe 24099 invoked by uid 0); 23 Oct 2006 19:32:12 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.035968 secs); Received: from unknown (HELO ?192.168.10.175?) (Z???own@210.107.250.150) by unknown with SMTP; 23 Oct 2006 19:32:12 +0900 X-RCPTTO: nobody@xyzzy.claranet.de, ima@ietf.org Message-ID: <453C99E2.3020307@icu.ac.kr> Date: Mon, 23 Oct 2006 19:30:58 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 7 - missing local part (ab)uses as label References: <45339923.8030900@alvestrand.no> <453446AA.739F@xyzzy.claranet.de> <5DAAD30D180E1A4125249F98@p3.JCK.COM> <453C899E.124F@xyzzy.claranet.de> In-Reply-To: <453C899E.124F@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: > John C Klensin wrote: > >> I don't know what you have in mind, so please supply specific >> draft text so that the WG can look at it. > > Something like that: > > | 7.5 Other uses of local parts > | > | Local parts are sometimes used to construct domain labels, e.g. > | the local part "user" in the address user@domain.example could > | be converted into a vanity host user.domain.example with Web > | space at and catchall addresses > | any.thing.goes@user.domain.example. > | > | Such schemes are obviously limited by among others the LDH rule, > | and won't work for other local parts like the > | specified in [I-D.ietf-eai-utf8headers]. For these cases, i18n local parts are parts of IDNs and they should follow rules defined by IDNA. For example, they can be in UTF-8 native(???) form when used in IDN-aware domain name slots. > > So far it's obvious, but I've no idea which wild and wonderful > uses of local parts might exist in addition to this simple case. > > 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 Mon Oct 23 06:58:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbxVE-0006Ht-BO; Mon, 23 Oct 2006 06:57:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbxVD-0006GS-2m for ima@ietf.org; Mon, 23 Oct 2006 06:57:55 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GbxT2-0006LI-CP for ima@ietf.org; Mon, 23 Oct 2006 06:55:42 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id k9NAt9R9022789; Mon, 23 Oct 2006 19:55:09 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006102319550814897 ; Mon, 23 Oct 2006 19:55:08 +0900 Date: Mon, 23 Oct 2006 19:55:08 +0900 (JST) Message-Id: <20061023.195508.48376602.fujiwara@jprs.co.jp> To: chl@clerew.man.ac.uk Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 From: fujiwara@jprs.co.jp In-Reply-To: References: <20061020.220825.68136113.fujiwara@jprs.co.jp> X-Mailer: Mew version 5.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > From: "Charles Lindsey" > >> s/EAI/UTF8SMTP/ throughout the document, including in the title. > > > > I'm hesitating EAI or UTF8SMTP. > > framework document is 'EAI Framework'. > > Which is this protocol set name, EAI or UTF8SMTP ? > > I think some gathering at an IETF agreed that the visible name of our > endeavour should have "UTF8" in it, and the provisional choice was > "UTF8SMTP" (I would have preferred "UTF8-Headers" myself). I don't think > the world out there is going to accept the term "EAI" (they will have > enough trouble remembering what it stands for :-( ). I agree that "EAI" is not good. It may be "UTF8SMTP". Working group name is "EAI" and protocol/document set name is "UTF8SMTP", is it right? > >> And then s/mail header fields/mail header fields and in the headers > >> fields > >> of MIME multipart and message types/. > >> > >> Otherwise, an already downgraded message will get munged if it then > >> encounters a non-8BITMIME server. > > > > not agreed. An already downgraded message is a normal rfc2822/rfc822 > > message and it may contain 8bit(non-ascii) characters in the message > > body. RFC 1652 capable SMTP agent treats it correctly. > > No it doesn't. A part of a multipart mixed has some headers (usually > Content-Type and Content-Transfer-Encoding) before the body of that part. > Now, those headers can contain UTF-8 (in comments at least, but also in > s) and RFC 1652 does not know they have to be downgraded. > Likewise the mail headers in message/rfc822. I am arguing with John about > this one at the moment, so let us see how that goes. I understand. It is hard problem. # I don't like rewriting the body of a message. As John commented, these MIME headers needs further duscussion and describing in utf8header document. > > > >> 5. SMTP DATA/Header Downgrading > > >> You need to add Content-Type, Content-Disposition, etc. to your list, > >> and also List-*. > > > > In my opinion, Content-Type, Content-Disposition headers are not > > expanded and do not contain UTF-8 characters. So it is included in > > other headers and they are not target of downgrading. > > They can certainly contain UTF8 in comments (they never do, of course, but > it is allowed). The more realistic case is when a Content-Disposition > contains a filename parameter in UTF-8. RFC 2231 is the proper downgrade > there (ugly, but it works). > > > > I considered that List-* headers as normal unstructured headers. > > No, they are structured. There is ABNF for them, and they mostly contain > URLs. Ok, downgrading methods are different for each headers. We need to list up target header list and arrange them, and define downgrading methods for each headers. Some headers which contains IRI only should be downgraded with IRI specific downgrading method. Some headers like 'Subject' are simply encoded by RFC 2047. > > Is encapsulating in Downgraded header allowed? > > If it were done as an addition (like we are proposing even for address > headers) it would be fine. You might get away with it as the sole > mechanism if you assume that these IRIs don't need to be seen until the > message has been upgraded at the far end. There, people will expect to be > able to click on them, but they are not of much use during transport. I'll add that headers which is not in downgradable header list are encapsulated in Downgraded header. > >> Upgrading: > > This part needs detailed procedures: folding and whitespaces > > normalizations, error handlings, ... > > I think, if you cannot identify the header that was downgraded in order to > remove it, then you just have to leave it alone. In any case, some > scammers are going to make them deliberately different, and that needs to > be mentioned as a Security Issue Ok, to add some lines about: If hard to identify to erase, leaving original Downgraded header is one solution. (decoding RFC 2047 encoding increases user's readability.) > >> 5.1.1. Downgrading address headers > > > >> 4. If From header is removed, generate new From: header from > >> envelope-from address. > >> > >> Ugh! Though I cannot think of anything better. > > > > This part need more careful consideration. > > >> > > > Without ALT-ADDRESS, US-ASCII user-part and UTF-8 domain-part address > > may be downgraded in SMTP Downgrading. > > Correct. It is when there is a utf-8 local-part and no alt-address that we > have problems. But I suspect that will be the common case for people who > never expect to be mailing to pure-ascii-users. I'll add. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 23 07:22:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbxt3-0000iq-2a; Mon, 23 Oct 2006 07:22:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbxt2-0000il-BH for ima@ietf.org; Mon, 23 Oct 2006 07:22:32 -0400 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbxt0-0004FO-QW for ima@ietf.org; Mon, 23 Oct 2006 07:22:32 -0400 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id k9NBMTR9022881 for ; Mon, 23 Oct 2006 20:22:29 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2006102320222814952 for ; Mon, 23 Oct 2006 20:22:28 +0900 Date: Mon, 23 Oct 2006 20:22:28 +0900 (JST) Message-Id: <20061023.202228.94578453.fujiwara@jprs.co.jp> To: ima@ietf.org Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 From: fujiwara@jprs.co.jp In-Reply-To: <20061020.220825.68136113.fujiwara@jprs.co.jp> References: <20061020.220825.68136113.fujiwara@jprs.co.jp> X-Mailer: Mew version 5.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > From: fujiwara@jprs.co.jp > I try to update the draft before cut-off, if possible. Modifications are many and there are many considerations, it is hard to submit before today's cut-off. I'll list considerations and next version's draft to this list next week. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 23 08:16:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbyjF-0007xC-1K; Mon, 23 Oct 2006 08:16:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbyjD-0007wE-Li for ima@ietf.org; Mon, 23 Oct 2006 08:16:27 -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 1Gbyfc-0006Sq-Ha for ima@ietf.org; Mon, 23 Oct 2006 08:12:45 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GbyfH-0007cQ-VJ for ima@ietf.org; Mon, 23 Oct 2006 14:12:24 +0200 Received: from pd9fbad57.dip0.t-ipconnect.de ([217.251.173.87]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Oct 2006 14:12:23 +0200 Received: from nobody by pd9fbad57.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Oct 2006 14:12:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 7 - missing local part (ab)uses as label Date: Mon, 23 Oct 2006 14:10:55 +0200 Organization: Lines: 40 Message-ID: <453CB14F.2A21@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <453446AA.739F@xyzzy.claranet.de> <5DAAD30D180E1A4125249F98@p3.JCK.COM> <453C899E.124F@xyzzy.claranet.de> <453C99E2.3020307@icu.ac.kr> 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: pd9fbad57.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yangwoo Ko wrote: > For these cases, i18n local parts are parts of IDNs and they > should follow rules defined by IDNA. For example, they can be > in UTF-8 native(???) form when used in IDN-aware domain name > slots. On the bottom (DNS) that's get's us back to Charles proposal of using punycode. The idea shouldn't be dismissed without some considerations: - "old" users have already ASCII addresses, they'd only wish to get an additional new UTF-8-address, without any obscure punycode-downgrade variant. - therefore it's pointless to invent special procedures and syntax only to support a wannabe-standard-downgrade variant within the EAI framework - "new" users have no address at all, they start with a fresh UTF-8-address, and probably need also a downgrade fallback, if they want to communicate with ASCII-users - for that case (new user) their service provider could use a standard way to determine and offer a derived ASCII-address, and that could be an IDNA xn-- local part Of course they could also B32-encode the UTF-8 local part for this purpose, or use other ad hoc solutions, but the xn-- way could be better for e.g. derived vanity host names. It could also help to determine "allowed" UTF-8 local parts, if the xn-- version clashes with another user, then the UTF-8 local part might be not "different enough" from this other user wrt confusable addresses. That's pure speculation, and possibly it's plain nonsense, but I'd still like to know why it's a stupid idea... :-) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 23 10:52:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc19h-0006yR-Q2; Mon, 23 Oct 2006 10:51:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc19g-0006xy-Ft for ima@ietf.org; Mon, 23 Oct 2006 10:51:56 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc19Z-0000rg-UD for ima@ietf.org; Mon, 23 Oct 2006 10:51:56 -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.231) id 453cd703.31e7.331 for ima@ietf.org; Mon, 23 Oct 2006 15:51:47 +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 k9NEpid7013453 for ; Mon, 23 Oct 2006 15:51:46 +0100 (BST) Subject: Fwd: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 References: <20061020.220825.68136113.fujiwara@jprs.co.jp> <69395EF545F2B2B08A3B7A1A@p3.JCK.COM> Message-ID: To: "ima@ietf.org" 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, 23 Oct 2006 15:51:44 +0100 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 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, 21 Oct 2006 04:52:59 +0100, John C Klensin wrote: > --On Friday, 20 October, 2006 20:05 +0100 Charles Lindsey > wrote: >> No it doesn't. A part of a multipart mixed has some headers >> (usuallyContent-Type and Content-Transfer-Encoding) before the >> body of that part.Now, those headers can contain UTF-8 (in >> comments at least, but also ins) and RFC 1652 does >> not know they have to be downgraded.Likewise the mail headers >> in message/rfc822. I am arguing with John aboutthis one at the >> moment, so let us see how that goes. > > We don't have much of an argument. You are assuming that those > attached MIME headers (C-T and C-T-E) can (and, I assume, > should) be permitted to contain non-ASCII characters). I am > assuming that is reasonable iff (i) the utf8headers document is > explicit about it (which it had better be, one way or the other) > and (ii) if there is a plan for downgrading those headers that > is clear and reversible without loss of information. My reading of our utf8hdrs document is that UTF8 can be used in any header described as in s wherever they are allowed to occur in any header in s wherever they are allowed to occur in any header and wherever else explicitly allowed, as in s. As to which headers s may appear in, RFC 822 has some very liberal rules which any header defined in RFC 822 terms (and that certainly includes C-T and C-T-E) is free to apply. RFC 2822 is more explicit, but in general confirms what RFC 822 says. Some more recent drafts based on RFC 2822 (notably USEFOR and DKIM) have restricted the places where s may appear (by using [FWS] rather than [CFWS]). It is pretty easy for MUAs to detect where comments are allowed under the RFC 822 rules, without knowing the exact syntax of individual headers, and I suspect most current MUAs simply detect them on that basis and display stuff accordingly (e.g. by recognising encoded-words there). > This is _not_ a proposal, and I hope we don't need to go in this > direction. However, it occurs to me that one way out of many of > these problems would be to require that the host proposing to > downgrade a message check each header for the presence of 8bit > characters. I think that if a downgrader sees a Header-Type: UTF8SMTP at the top level, and if the C-T is some kind of multipart, then it has to decend (recursively if necessary) through the multipart structure looking for Content-* headers with s or s with UTF-8 in them. And at the same time it needs to look at the headers of any message/rfc822 it encounters (though checking for the presence/absence of Header-Type: UTF8SMTP in there should suffice). You might even insist on a Header-Type header in the introductory heading of such parts (though RFC 2045/6 currently allows only headers starting with "Content-" there). >>>> 5. SMTP DATA/Header Downgrading >> The more realistic case is when a >> Content-Disposition contains a filename parameter in UTF-8. RFC >> 2231 is the proper downgradethere (ugly, but it works). > > Actually, it doesn't work. In the general case, the downgrading > MTA can't possibly know anything about the syntax of a filename > on the system containing the delivery MUA (not just MTA) -- that > filename is interpreted on the far side of POP or IMAP servers > if they are used. There is no requirement in RFC 2183 for the sending MUA or any intermediate MTA to avoid filnames which might not be syntactically acceptable at the receiving end. The 'filename' parameter is just a 'suggestion', and it clearly states that it is up to the receiving MUA to decide whether it is fit to be used as it stands. Moreover, RFC 2183 clearly states that, although filenames would be expected to be in ASCII at the time of writing, it was to be expected that future enhancements would make provision for Non-ASCII filenames. It might be argued that RFC 2231 had already provided that possibility, but if not, then it is clearly the case that our present UTF8SMTP has now provided precisely the opportunity envisaged. So it is not a question of _whether_ we permit ASCII filenames, but _how_. And a downgrade via RFC 2231 is the obvious mechanism (though we might encourage some normalization, probably NFKC, while we are about it). And whatever provision we make should apply to s in general. Naturally, s will remain in ASCII, as well as values that are keywords (such as the IANA-registered charsets). Non-ASCII boundaries, anyone? >>>> Headers (Content-*) containing s will be >>>> downgraded according to RFC 2231, and headers containing >>>> IRIs (List-*) according to RFC 3987. > But even knowing that something is an IRI or URI requires either > heuristics (bad news) of knowledge of a particular header and > its syntax. It would only apply to headers explicitly extended to permit it. But we are supposed to be writing a draft to deal with mailing lists, and that would be a proper place to define such extensions (for use within the UTF8SMTP universe). Mailto: URIs for Chinese email addresses will be entirely incomprehensible, either to a Chinaman or to anyone else, and yet people will be expected to click on them (e.g. to unsubscribe from the list). This is precisely the sort of situation which, according to the framework document, we are trying to avoid, both within MUAs and, wherever possible, on the wire also. >>>> And, as I have already said, I would still like to be able >>>> to translate the using punycode, possible >>>> restricted by an atomic/downgradable parameter. > > But that idea was already rejected by the WG. When and where? Can you point me to a message on this list which states that? > More important, > whatever you do, you can't use punycode, which is > case-insensitive. I don't know how you can say that. Punycode is defined in RFC 3492, which states that case-sensitivity is REQUIRED for the basic Punycode algorithm. One of the authors of that document has explicitly confirmed that on this list. I will grant you that it is possible to write a wrapper around punycode which will arrange for case folding, and the model implementation provided in RFC 3492 provides an option which effectively does just that (and it may be a sensible option to use when coding domain-names). Naturally, we would need to point out, in a NOTE, that that option should not be used when encoding local-parts. -- 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 Oct 23 10:52:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1A6-0007A0-5G; Mon, 23 Oct 2006 10:52:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1A5-00079v-Dx for ima@ietf.org; Mon, 23 Oct 2006 10:52:21 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc1A3-0000wC-Lg for ima@ietf.org; Mon, 23 Oct 2006 10:52:21 -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.231) id 453cd722.7aa4.1e27 for ima@ietf.org; Mon, 23 Oct 2006 15:52:18 +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 k9NEqGf9013488 for ; Mon, 23 Oct 2006 15:52:17 +0100 (BST) Subject: Re: message/TBD and RFC 2046 (Re: [EAI] Re: MIME subpart) References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <5dmz846l83.fsf@Hurtta06k.keh.iki.fi> <452C0BF6.6F6@xyzzy.claranet.de> <5dzmc3h5nn.fsf@Hurtta06k.keh.iki.fi> <5dvemrh4hu.fsf_-_@Hurtta06k.keh.iki.fi> <5dr6xfh4by.fsf@Hurtta06k.keh.iki.fi> <452CAD7E.6BBE@xyzzy.claranet.de> <5dd58lwk65.fsf_-_@Hurtta06k.keh.iki.fi> Message-ID: To: "ima@ietf.org" 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, 23 Oct 2006 15:52:15 +0100 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) 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 Sat, 21 Oct 2006 20:20:02 +0100, Kari Hurtta wrote: > Then there is RFC 2046 which writes: > > > | 5.2.4. Other Message Subtypes > | > | MIME implementations must in general treat unrecognized subtypes of > | "message" as being equivalent to "application/octet-stream". > | > | Future subtypes of "message" intended for use with email should be > | restricted to "7bit" encoding. A type other than "message" should be > | used if restriction to "7bit" is not possible. > And yet RFC 2046 also writes, in 5.2.1: | No encoding other than "7bit", "8bit", or "binary" is permitted for | the body of a "message/rfc822 entity. which seems to contradict what it says in 5.2.4 (we also discussed the meaning of that sentence in another thread a few days ago). -- 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 Oct 23 10:55:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1Cr-0001JA-RV; Mon, 23 Oct 2006 10:55:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1Cr-0001J4-0Y for ima@ietf.org; Mon, 23 Oct 2006 10:55:13 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc1Cp-0001J4-0x for ima@ietf.org; Mon, 23 Oct 2006 10:55:12 -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.231) id 453cd7cd.f9da.650 for ima@ietf.org; Mon, 23 Oct 2006 15:55:09 +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 k9NEt8dm013667 for ; Mon, 23 Oct 2006 15:55:08 +0100 (BST) Date: Mon, 23 Oct 2006 15:55:07 +0100 To: "ima@ietf.org" Subject: Re: message/TBD and RFC 2046 (Re: [EAI] Re: MIME subpart) References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <5dmz846l83.fsf@Hurtta06k.keh.iki.fi> <452C0BF6.6F6@xyzzy.claranet.de> <5dzmc3h5nn.fsf@Hurtta06k.keh.iki.fi> <5dvemrh4hu.fsf_-_@Hurtta06k.keh.iki.fi> <5dr6xfh4by.fsf@Hurtta06k.keh.iki.fi> <452CAD7E.6BBE@xyzzy.claranet.de> <5dd58lwk65.fsf_-_@Hurtta06k.keh.iki.fi> <6E301C1766F7C2E9F1AD3366@p3.JCK.COM> <5d8xj9wh6n.fsf@Hurtta06k.keh.iki.fi> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <5d8xj9wh6n.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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, 21 Oct 2006 21:24:32 +0100, Kari Hurtta wrote: > John C Klensin writes in gmane.ietf.ima: > > <...> >> Are we creeping toward either an amendment to that text in 2046 >> or a new top-level type for, e.g., "message8/" ? >> >> john I think we are creeping toward an ammendment to RFC 2046. > > ( summary: I do not know answer. ) > But these really do not matter if EAI documents allow these only on > UTF8SMTP environment. Yes, they must be kept away from all old-style implementations. > Any of these needs some kind downgrading when leaving UTF8SMTP. Exactly, or bouncing. -- 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 Oct 23 11:12:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1Tf-0006Gm-3J; Mon, 23 Oct 2006 11:12:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1Te-0006Gg-Qa for ima@ietf.org; Mon, 23 Oct 2006 11:12:34 -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 1Gc1TW-0004PA-QY for ima@ietf.org; Mon, 23 Oct 2006 11:12:34 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Gc1TR-000C9s-KE; Mon, 23 Oct 2006 11:12:21 -0400 Date: Mon, 23 Oct 2006 11:12:20 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] ISSUE: framework 7 - missing local part (ab)uses as label Message-ID: <6E1EBC5B4E9473014387D9A7@p3.JCK.COM> In-Reply-To: <453CB14F.2A21@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <453446AA.739F@xyzzy.claranet.de> <5DAAD30D180E1A4125249F98@p3.JCK.COM> <453C899E.124F@xyzzy.claranet.de> <453C99E2.3020307@icu.ac.kr> <453CB14F.2A21@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (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: 10d3e4e3c32e363f129e380e644649be 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 Monday, 23 October, 2006 14:10 +0200 Frank Ellermann wrote: > Yangwoo Ko wrote: > >> For these cases, i18n local parts are parts of IDNs and they >> should follow rules defined by IDNA. For example, they can be >> in UTF-8 native(???) form when used in IDN-aware domain name >> slots. > > On the bottom (DNS) that's get's us back to Charles proposal of > using punycode. The idea shouldn't be dismissed without some > considerations: > > - "old" users have already ASCII addresses, they'd only wish > to get an additional new UTF-8-address, without any obscure > punycode-downgrade variant. > > - therefore it's pointless to invent special procedures and > syntax only to support a wannabe-standard-downgrade variant > within the EAI framework > > - "new" users have no address at all, they start with a fresh > UTF-8-address, and probably need also a downgrade fallback, > if they want to communicate with ASCII-users > > - for that case (new user) their service provider could use a > standard way to determine and offer a derived ASCII-address, > and that could be an IDNA xn-- local part I feel like I'm repeating myself. (1) Punycode will not work for email local parts because it is case-sensitive. Adam Costello proposed a variant a while back that would be case-preserving, but it wouldn't be IDNA-punycode any more. (2) One could, of course, ban case-sensitive i18n local parts, but no one has suggested that yet and I can imagine its not being completely popular. Popular or not, it would violate the principle that, to the extent possible, we don't want to have a different set of restrictions for UTF8SMTP addresses than we have for ASCII addresses. (3) If your new users wants to use, e.g., subaddresses, and the associated delivery SMTP uses early dispatching and late decoding, the use of almost any encoding system on the wire is a serious problem. Vis-a-vis the trick DNS name convention you describe in your proposed subsection, two of the more common subaddress delimiter characters -- "+" and "/" -- would be prohibited since they cannot appear in LDH domain names. But hyphens would not be intrinsically prohibited, nor would subaddress systems that don't use explicit delimiters. > Of course they could also B32-encode the UTF-8 local part for > this purpose, or use other ad hoc solutions, but the xn-- way > could be better for e.g. derived vanity host names. Indeed, if all or part of a local-part is going to be mapped to or from a domain name label, and your expectation is that nothing other than mail-retrieval software will ever see the string in a local-part, then a punycode string would be reasonable. But that is a very special case, certainly too special to justify a general rule although, if a particular system decides to configure things that way (for use with Alt-Address if needed), I can't see how anyone could object. > It could also help to determine "allowed" UTF-8 local parts, > if the xn-- version clashes with another user, then the UTF-8 > local part might be not "different enough" from this other > user wrt confusable addresses. That's pure speculation, and > possibly it's plain nonsense, but I'd still like to know why > it's a stupid idea... :-) The normalizations performed in IDNA (and nameprep/stringprep) aren't good enough to provide any significant protection against confusable characters. The new 'idnabis' work may be a little better, but mostly by eliminating characters that IDNA maps to other through compatibility mappings. And the present IDNA excludes some strings that one would almost certainly want in local-parts. See draft-klensin-idnabis-issues-00, draft-alvestrand-idnabis-bidi-00, and draft-faltstrom-idnabis-tables. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 23 11:14:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1Vj-0007oo-GO; Mon, 23 Oct 2006 11:14:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc1Vi-0007ka-Ap for ima@ietf.org; Mon, 23 Oct 2006 11:14:42 -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 1Gc1Vb-0004kV-Kp for ima@ietf.org; Mon, 23 Oct 2006 11:14:42 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gc1Ur-0007LP-Sj for ima@ietf.org; Mon, 23 Oct 2006 17:13:49 +0200 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Oct 2006 17:13:49 +0200 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Oct 2006 17:13:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: message/TBD and RFC 2046 (Re: [EAI] Re: MIME subpart) Date: 23 Oct 2006 18:13:14 +0300 Lines: 48 Message-ID: <5dlkn7f4l1.fsf@leija.fmi.fi> References: <0DB08D0582395ACFD523BB3E@7AD4D3FB4841A5E367CCF211> <5d3b9wkb4o.fsf@Hurtta06k.keh.iki.fi> <5dzmc4d6s9.fsf_-_@leija.fmi.fi> <5dbqokma43.fsf_-_@Hurtta06k.keh.iki.fi> <452BD58F.87C@xyzzy.claranet.de> <5dmz846l83.fsf@Hurtta06k.keh.iki.fi> <452C0BF6.6F6@xyzzy.claranet.de> <5dzmc3h5nn.fsf@Hurtta06k.keh.iki.fi> <5dvemrh4hu.fsf_-_@Hurtta06k.keh.iki.fi> <5dr6xfh4by.fsf@Hurtta06k.keh.iki.fi> <452CAD7E.6BBE@xyzzy.claranet.de> <5dd58lwk65.fsf_-_@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > On Sat, 21 Oct 2006 20:20:02 +0100, Kari Hurtta > wrote: > > > > Then there is RFC 2046 which writes: > > > > > > | 5.2.4. Other Message Subtypes > > | > > | MIME implementations must in general treat unrecognized subtypes of > > | "message" as being equivalent to "application/octet-stream". > > | > > | Future subtypes of "message" intended for use with email should be > > | restricted to "7bit" encoding. A type other than "message" should be > > | used if restriction to "7bit" is not possible. > > > And yet RFC 2046 also writes, in 5.2.1: > > | No encoding other than "7bit", "8bit", or "binary" is permitted for > | the body of a "message/rfc822 entity. > > which seems to contradict what it says in 5.2.4 (we also discussed the > meaning of that sentence in another thread a few days ago). I read that 5.2.4 is instruction what kind subtypes of message should be registered. In other words on what limitations should be on that particular new subtype registeration. And anyway message/rfc822 is not future subtype of "message". Message/rfc822 is one of subtypes what is specified on MIME standard itself. Instruction on 5.2.4 is probably because of 8BITMIME downgrade problems. if particular new subtype of message includes some other data than "7bit", 8BITMIME requires to bounce message on downgrading ... As I mentioned earlier, new composite types (either new top level types or new subtypes of message) are pain on MIME. That is where is breaks. If type is "discrete", there is no problems... / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 23 11:54:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc27n-0000HH-FI; Mon, 23 Oct 2006 11:54:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc27m-0000HA-2i for ima@ietf.org; Mon, 23 Oct 2006 11:54:02 -0400 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc27h-0003Jx-K2 for ima@ietf.org; Mon, 23 Oct 2006 11:54:02 -0400 Received: from vanye.mho.net (adsl-64-58-1-252.mho.net [64.58.1.252] (may be forged)) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id k9NFrgZK010190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Oct 2006 08:53:44 -0700 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com k9NFrgZK010190 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1161618826; bh=uCA22lQ99xC9xy150y1sFoM2pf0=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=J82g3X7vA6KLWy0F ZhNvlsONia22IftJI5hEkpeToq+76gt09KTmWpEQLz/bkh+xy+B0z7e3iBvZaYDSV2l n857LSL2LDzom+i5rX5BhuT8sVvgT2rBBRhO9isIbTwA6UI7B2ZdwLtJYfewz4cQKEW lu+ISB5mpcibZs1MktyU8= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com k9NFrgZK010190 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=Q67OWQsjt8Km3rc+RH3SE+WcB4AnOljd4TcFW8adPc73uj5C3+IepYCVlhj3RzPRR 6bbssqVYHI9KHasKwwpGsD9Hv+5WV5mrcCv8WSGY+wpxxMbjkDgrYZMIHnGCp2IuJlU oSkGbQ3ji1hyW26keHjLgYo0KJX8WHvxPBjMzoE= Date: Mon, 23 Oct 2006 09:53:41 -0600 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: John C Klensin Subject: Re: [EAI] ISSUE: framework -3 - missing MIME considerations In-Reply-To: Message-ID: References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 18 Oct 2006, John C Klensin wrote: > --On Wednesday, 18 October, 2006 18:08 +0100 Charles Lindsey > wrote: ... > The content, and in particular the headers, of a message/rfc822 > body part is expected to be strictly conformant to RFC 822 (not > even 2822). That is a strong ASCII constraint. The way I read > that spec, one can't even have a body part inside of one with > "content-transfer-encoding: 8bit", regardless of what the > transport might transmit. That disagrees with RFC 2046, which says: 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. So conformance to RFC 822 isn't required. Furthermore, it then continues: <...> No encoding other than "7bit", "8bit", or "binary" is permitted for the body of a "message/rfc822" entity. The message header fields are always US-ASCII in any case, and data within the body can still be encoded, in which case the Content-Transfer-Encoding header field in the encapsulated message will reflect this. Non-US-ASCII text in the headers of an encapsulated message can be specified using the mechanisms described in RFC 2047. If 8bit data can't be present in a message/rfc822 part, then why permit CTE: 8bit on the part itself? Given that all other subtypes of "message" _do_ have a strict 7bit-only restriction, I can only conclude that a message/rfc822 part is permitted to contain 8bit data in its embedded body (when it recursively declares itself as being a MIME message with CTE: 8bit, of course). Such a message would require 8BITMIME transport, of course, and if that was lacking then the message/rfc822 part's contents would have to be converted from 8bit to quoted-printable or base64, just like a multipart/*. Isn't that what all the 8BITMIME SMTP clients out there do in that case? ... > Of course, if a message has already been downgraded to the point > that it is entirely ASCII and 822-conformant, then > message/rfc822 is a reasonable way to handle or represent it. > But that isn't the case that most people are thinking about when > they talk about encapsulation. Are those people referring to encapsulation-with-exact-reconstruction as distinct from the downgrade mechanism? If so, how would you know whether to encapsulate or downgrade? If exact reconstruction is necessary, it seems to me that needs to be a capability of the downgrade mechanism and not some completely separate thing, otherwise we'll have messages flying around in both forms, some which are incomprehensible to old clients, some which are imperfect representations. Philip Guenther _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 23 13:37:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc3jh-0000EP-No; Mon, 23 Oct 2006 13:37:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc3jh-0000EF-1D for ima@ietf.org; Mon, 23 Oct 2006 13:37:17 -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 1Gc3je-0002Mz-Pg for ima@ietf.org; Mon, 23 Oct 2006 13:37:17 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gc3iz-000690-D1 for ima@ietf.org; Mon, 23 Oct 2006 19:36:33 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Oct 2006 19:36:33 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Oct 2006 19:36:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 Date: 23 Oct 2006 20:36:01 +0300 Lines: 53 Message-ID: <5d1wozq6im.fsf@Hurtta06k.keh.iki.fi> References: <20061020.220825.68136113.fujiwara@jprs.co.jp> <20061023.195508.48376602.fujiwara@jprs.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org fujiwara@jprs.co.jp writes in gmane.ietf.ima: [ probably "Charles Lindsey" : ] > > They can certainly contain UTF8 in comments (they never do, of course, but > > it is allowed). The more realistic case is when a Content-Disposition > > contains a filename parameter in UTF-8. RFC 2231 is the proper downgrade > > there (ugly, but it works). > > > > > > I considered that List-* headers as normal unstructured headers. > > > > No, they are structured. There is ABNF for them, and they mostly contain > > URLs. > > Ok, downgrading methods are different for each headers. We need to > list up target header list and arrange them, and define downgrading > methods for each headers. Yes. But I think that it make sense to require conversion only for some subset of header fields. Other should be optional (ie. just encapsulate them to Downgraded: -header field, if corresponding downgrading method is not implemented. ) Minimal implementation should not be required to know long list of different downgrading methods. (IMHO for minimal implementation RFC 2047 + RFC 2231 should be enough. ) > Some headers which contains IRI only should be downgraded with IRI > specific downgrading method. > > Some headers like 'Subject' are simply encoded by RFC 2047. These header fields are from RFC 2822: subject = "Subject:" unstructured CRLF comments = "Comments:" unstructured CRLF optional-field = field-name ":" unstructured CRLF from RFC 2045: description := "Content-Description" ":" *text / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 23 13:51:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc3wy-0002HV-MC; Mon, 23 Oct 2006 13:51:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc3wx-0002F2-AQ for ima@ietf.org; Mon, 23 Oct 2006 13:50:59 -0400 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc3wt-00049Q-2l for ima@ietf.org; Mon, 23 Oct 2006 13:50:59 -0400 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id AE52A29A8A; Mon, 23 Oct 2006 13:51:16 -0400 (EDT) Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 4970087E42; Mon, 23 Oct 2006 13:51:15 -0400 (EDT) Date: Mon, 23 Oct 2006 10:50:52 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <91160974.20061023105052@pobox.com> To: IMA Discussion Subject: Re: Fwd: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 In-Reply-To: References: <20061020.220825.68136113.fujiwara@jprs.co.jp> <69395EF545F2B2B08A3B7A1A@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.2 (+) 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 =0D=0AOn Mon, 2006-10-23, Charles Lindsey wrote: > I think that if a downgrader sees a Header-Type: UTF8SMTP at the top > level, and if the C-T is some kind of multipart, then it has to decend > (recursively if necessary) through the multipart structure looking for > Content-* headers with s or s with UTF-8 in them. And > at the same time it needs to look at the headers of any message/rfc822 it > encounters (though checking for the presence/absence of Header-Type: > UTF8SMTP in there should suffice). You might even insist on a Header-Type > header in the introductory heading of such parts (though RFC 2045/6 > currently allows only headers starting with "Content-" there). A small point: MIME body part headers MAY have header fields other than Content-*. From=20RFC 2046, Sec. 5.1. para 3: The only header fields that have defined meaning for body parts are those the names of which begin with "Content-". All other header fields may be ignored in body parts. Although they should generally be retained if at all possible, they may be discarded by gateways if necessary. Such other fields are permitted to appear in body parts but must not be depended on. "X-" fields may be created for experimental or private purposes, with the recognition that the information they contain may be lost at some gateways. --=20 Bill McQuillan _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 23 17:04:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6xW-0003b5-EG; Mon, 23 Oct 2006 17:03:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6xV-0003ay-N7 for ima@ietf.org; Mon, 23 Oct 2006 17:03:45 -0400 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc6xM-0001Nh-7D for ima@ietf.org; Mon, 23 Oct 2006 17:03:45 -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]:57871) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Gc6x8-000853-Oi (Exim 4.63) (return-path ); Mon, 23 Oct 2006 22:03:22 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Gc6x8-00073r-KG (Exim 4.54) (return-path ); Mon, 23 Oct 2006 22:03:22 +0100 Date: Mon, 23 Oct 2006 22:03:22 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin Subject: Re: [EAI] ISSUE: framework 7 - missing local part (ab)uses as label In-Reply-To: <6E1EBC5B4E9473014387D9A7@p3.JCK.COM> Message-ID: References: <45339923.8030900@alvestrand.no> <453446AA.739F@xyzzy.claranet.de> <5DAAD30D180E1A4125249F98@p3.JCK.COM> <453C899E.124F@xyzzy.claranet.de> <453C99E2.3020307@icu.ac.kr> <453CB14F.2A21@xyzzy.claranet.de> <6E1EBC5B4E9473014387D9A7@p3.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Mon, 23 Oct 2006, John C Klensin wrote: > > Punycode will not work for email local parts because it is > case-sensitive. Adam Costello proposed a variant a while back > that would be case-preserving, but it wouldn't be IDNA-punycode > any more. Do you mean case-INsensitive in the second line above? Case handling is a nameprep matter, not a punycode matter. There's no reason that EAI couldn't use punycode with a differenc stringprep profile that preserves case. Tony. -- f.a.n.finch http://dotat.at/ LUNDY FASTNET: NORTHEAST BACKING SOUTHWEST 6 TO GALE 8 DECREASING 5. OCCASIONAL RAIN. MODERATE OR GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 23 17:12:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc75t-00061Y-Tn; Mon, 23 Oct 2006 17:12:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc75s-00060a-Gx for ima@ietf.org; Mon, 23 Oct 2006 17:12:24 -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 1Gc75m-0003gw-OL for ima@ietf.org; Mon, 23 Oct 2006 17:12:24 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Gc75g-000GKl-5s; Mon, 23 Oct 2006 17:12:12 -0400 Date: Mon, 23 Oct 2006 17:12:11 -0400 From: John C Klensin To: Tony Finch Subject: Re: [EAI] ISSUE: framework 7 - missing local part (ab)uses as label Message-ID: <8D2BD2C1379D72F9180C1BAC@p3.JCK.COM> In-Reply-To: References: <45339923.8030900@alvestrand.no> <453446AA.739F@xyzzy.claranet.de> <5DAAD30D180E1A4125249F98@p3.JCK.COM> <453C899E.124F@xyzzy.claranet.de> <453C99E2.3020307@icu.ac.kr> <453CB14F.2A21@xyzzy.claranet.de> <6E1EBC5B4E9473014387D9A7@p3.JCK.COM> X-Mailer: Mulberry/4.0.6 (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: 93238566e09e6e262849b4f805833007 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 Monday, 23 October, 2006 22:03 +0100 Tony Finch wrote: > On Mon, 23 Oct 2006, John C Klensin wrote: >> >> Punycode will not work for email local parts because it is >> case-sensitive. Adam Costello proposed a variant a while back >> that would be case-preserving, but it wouldn't be >> IDNA-punycode any more. > > Do you mean case-INsensitive in the second line above? Case > handling is a nameprep matter, not a punycode matter. There's > no reason that EAI couldn't use punycode with a differenc > stringprep profile that preserves case. That is correct. But it would almost certainly also require a different prefix (see earlier note) and might well require a stringprep profile that was more different from the IDNA/nameprep one than just preserving case. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 23 20:35:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcAFy-0004fM-DF; Mon, 23 Oct 2006 20:35:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcAFx-0004fG-NK for ima@ietf.org; Mon, 23 Oct 2006 20:35:01 -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 1GcAFw-0000aM-HT for ima@ietf.org; Mon, 23 Oct 2006 20:35:01 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GcAFu-000IWg-TK; Mon, 23 Oct 2006 20:34:59 -0400 Date: Mon, 23 Oct 2006 20:34:57 -0400 From: John C Klensin To: Charles Lindsey Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 Message-ID: <4E4D821B9BACE1BCDB3A03F8@p3.JCK.COM> In-Reply-To: References: <20061020.220825.68136113.fujiwara@jprs.co.jp> <69395EF545F2B2B08A3B7A1A@p3.JCK.COM> X-Mailer: Mulberry/4.0.6 (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: 249cd1efd3d5e0d09114abe826a41235 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 23 October, 2006 22:40 +0100 Charles Lindsey wrote: > On Mon, 23 Oct 2006 16:32:56 +0100, John C Klensin > wrote: > > Since John's reply didn't go to the whole list (my fault > because he wasreplying to a copy addressed only to him), I am > quoting the Whole of hisreply here. I caught it this time, and am replying to the list as well. But, out of curiosity, is there some reason why your MUA and/or MTA cannot handle a message to someone that contains a "cc" to a list, in violation of the clear intent of 821/822/2821/2822? Material below on which we agree snipped out... >... >>> My reading of our utf8hdrs document is that UTF8 can be used >>> in any header described as >>> in s wherever they are allowed to occur in any >>> header >>> in s wherever they are allowed to occur in any >>> header >>> and wherever else explicitly allowed, as in s. >> >> I believe that is a correct reading. But you and Frank are >> doing a fairly good job of convincing me that either it, or >> the text in ...eai-downgrade-... about handing those headers, >> is wrong -- not the reading, but the text. > > I certainly agree that there is a problem to be fixed one > place or theother. >... >>>> This is _not_ a proposal, and I hope we don't need to go in >>>> this direction. However, it occurs to me that one way out >>>> of many of these problems would be to require that the host >>>> proposing to downgrade a message check each header for the >>>> presence of 8bit characters. >>> >>> I think that if a downgrader sees a Header-Type: UTF8SMTP at >>> the toplevel, and if the C-T is some kind of multipart, then >>> it has to decend(recursively if necessary) through the >>> multipart structure looking forContent-* headers with >>> s or s with UTF-8 in them. Andat the same >>> time it needs to look at the headers of any message/rfc822 >>> itencounters (though checking for the presence/absence of >>> Header-Type:UTF8SMTP in there should suffice). You might even >>> insist on a Header-Typeheader in the introductory heading of >>> such parts (though RFC 2045/6currently allows only headers >>> starting with "Content-" there). >> >> In the general case, this requires looking through things it >> doesn't understand. For example, would a future >> "message/foobar" be equivalent to "message/rfc822" wrt >> interpretation of something that _might_ be a header or might >> be an example in running text? > > That would depend on the document that defined message/foobar. > Ideally,that will happen well into the future, by which time > UTF8SMTP will befamiliar to everyone and the guy writing that > document would know he hadto address the issue. Alternatively, > one might say that inventing a newmessage type and getting it > widely accepted involves so many hoops thatnobody is ever > going to do it. My prediction is that we are going to need either a new message/ subtype, some retroactive changes to the definitions of existing types, or both, in order to support a clean and reversible encapsulation for forwarding purposes. That implies "really soon", even if we conclude it isn't on the critical path for this WG. YMMD, of course. >>>>>>> 5. SMTP DATA/Header Downgrading >>> >>>>> The more realistic case is when a >>>>> Content-Disposition contains a filename parameter in UTF-8. >>>>> RFC 2231 is the proper downgradethere (ugly, but it works). >>>> >>>> Actually, it doesn't work. In the general case, the >>>> downgrading MTA can't possibly know anything about the >>>> syntax of a filename on the system containing the delivery >>>> MUA (not just MTA) -- that filename is interpreted on the >>>> far side of POP or IMAP servers if they are used. >>> >>> There is no requirement in RFC 2183 for the sending MUA or >>> anyintermediate MTA to avoid filnames which might not be >>> syntacticallyacceptable at the receiving end. The 'filename' >>> parameter is just a'suggestion', and it clearly states that >>> it is up to the receiving MUA todecide whether it is fit to >>> be used as it stands. >> >> Yes. That might be an argument for dropping the filename >> parameter if one downgrades... the principle should be, IMO, >> that a false positive is much worse than a failure. > > I don't see why. If it has been downgraded using RFC 2231, > then maybe evenexisting implementations can cope with it. If > not, then they just decidethat it is gibberish and move on to > Plan B (which would be to invent anduse an arbitrary name). The difficulty is that an existing implementation gets to look at a string that might be some encoded words and decide whether to interpret it as (i) a literal filename, (ii) a filename in 2231 encoding, (iii) something else. It may expect ASCII-ified non-ASCII filenames to be represented in HTML-like, or URI-like offset notation, not as encoded words (indeed, that interpretation might be fairly logical). If it is a legacy implementation that doesn't know about these things, the text of 2045 and 2047 --if I remember them correctly-- strongly discourage interpretation (ii) by prohibiting the use of encoded words in filenames. While 2231 mentions filename parameters in its introduction, it does not explicitly permit encoded words as the value of that parameter. More important, even if it did, there is ample reason to believe that that there are legacy implementations around that support 2045 and 2047 but not 2231 and 2183. So the conservative strategy for the downgrading system is to remove any filename parameters that contain non-ASCII characters because it is the only want that it can know that it isn't passing along trash as advice. Again, you may disagree, but that is "why". >>> Moreover, RFC 2183 clearly states that, although filenames >>> would beexpected to be in ASCII at the time of writing, it >>> was to be expected thatfuture enhancements would make >>> provision for Non-ASCII filenames. It mightbe argued that >>> RFC 2231 had already provided that possibility, but if >>> not,then it is clearly the case that our present UTF8SMTP >>> has now providedprecisely the opportunity envisaged. So it >>> is not a question of _whether_we permit ASCII filenames, but >>> _how_. And a downgrade via RFC 2231 is theobvious mechanism >>> (though we might encourage some normalization, probablyNFKC, >>> while we are about it). And whatever provision we make >>> should applyto s in general. Naturally, s >>> will remain in ASCII, aswell as values that are keywords >>> (such as the IANA-registered charsets).Non-ASCII boundaries, >>> anyone? >> I really see no problems with allowing non-ASCII filenames. >> My problem is only with how to downgrade them. And you can't >> normalize in-transit unless you know that the target system >> normalizes its file names (and how -- remember that there are >> many situations in which NFD is more useful, and certainly >> more consistent and predictable, than NFC), which you can't >> possibly know. >> >>>>>>> Headers (Content-*) containing s will be >>>>>>> downgraded according to RFC 2231, and headers containing >>>>>>> IRIs (List-*) according to RFC 3987. Again, that this is written does not make it safe or indicate that all cases have been evaluated. I think this discussion is demonstrating that the latter has not, in fact, been done. The key question, then, IMO, is whether making some retroactive changes and doing a bit of hand waving is worth the risk of botching something rather seriously. You presumably feel that is fairly safe. I actually agree with you -- if there are file systems around whose names look like encoded words, I certainly haven't see them. But my understanding of our obligation to the installed email base is that we are obligated to introduce _no_ new risks if there is any possible way to avoid them. In the examples you give above, the headers are reasonably well-specified, although I'm still concerned about what to do about ones that are not well-known and well-supported in legacy implementations. But it gives me no idea what to do about the arbitrary "foo:" header. >>>> But even knowing that something is an IRI or URI requires >>>> either heuristics (bad news) of knowledge of a particular >>>> header and its syntax. >>> >>> It would only apply to headers explicitly extended to permit >>> it. But weare supposed to be writing a draft to deal with >>> mailing lists, and thatwould be a proper place to define such >>> extensions (for use within theUTF8SMTP universe). >> >> Very possibly. But that isn't a comment on downgrade, but on >> the mailing list issue. > > Yes, but whenever we change one of the documents in our set, > then weusually have to change the downgrade document to match. > But it really istime that someone embarked on the mailing-list > draft which we arechartered to write. See draft-ietf-eai-mailinglist-00.txt. It may or may not be right, but the task has certainly been embarked upon. >>> Mailto: URIs for Chinese email addresses will be >>> entirely incomprehensible, either to a Chinaman or to anyone >>> else, and yet peoplewill be expected to click on them (e.g. >>> to unsubscribe from the list).This is precisely the sort of >>> situation which, according to the frameworkdocument, we are >>> trying to avoid, both within MUAs and, wherever possible,on >>> the wire also. >> >> I don't understand your second sentence above. > > It was an allusion to the passage, in 4.2 of your framework > draft, > > ... If non-obvious encodings, > such as protocol-specific ASCII-Compatible Encoding (ACE) > variants, > are used, the user will inevitably, if only occasionally, > see them > rather than "native" characters and will find that > discomfiting or > astonishing. Similarly, if different codings are used for > mail > transport and message bodies, the user is particularly > likely to be > surprised, if only as a consequence of the > long-established "things > leak" principle. The only practical way to avoid these > sources of > discomfort, in both the medium and the longer term, is to > have the > encodings used in transport be as nearly as possible the > same as the > encodings used in message headers and message bodies. > > Note that, from the POV of a Chinese email address, a URI is > just another"ACE". Hmm. I don't think so. But I'm not a Chinese speaker or user of systems whose primary locale is based on Chinese. >... >> One could do that, but one would then have to figure out >> whether any of the normalization, etc., issues impacted >> whatever you then mean by a punycode representation. But >> then you would be introducing problems with the law of least >> astonishment: Use of the same xn-- prefix when names were >> going to be interpreted in a case-sensitive way that was used >> for the DNS-like interpretation would be bad news. In >> addition, please remember that xn--gibberish is a value >> local-part, or part of a local-part, without any decoding and >> that, unlike the DNS, one can't sweep an appreciable fraction >> of the local parts in use to know that it doesn't exist. >> And, as I tried to point out in my note to Frank, if the >> local part consists of logical components, rather than being >> what we called "atomic" for a while, one has to choose >> between dropping the whole thing into punycode (thereby >> potentially hiding important information) and trying to >> individually code its components (thereby introducing some >> rather difficult lexical/ parsing issues). > > Normalizations and the addition of the xn-- prefix are nothing > to do withPunycode, and are not mentioned in RFC 3492. Any > normalizations we imposedon local-parts would be decided by us > (SASLPREP has been mentioned, Ibelieve), and naturally we > would not use the xn-- prefix (I have suggestedthe prefix > "yn--" for our case). > > And even if, perchance, someone has used something beginning > with yn-- ashis genuine local-part, that would be no different > from someon whogenuinely intended to to use > =?iso-8859-1?Q?RE=3A_=5BSome=A0Nonsense?= > as the Subject of his message. It is an acceptable risk. See comments above about levels of acceptable risk (although I don't expect you to agree). "Subject" (and comments) are, IMO, much less problematic that addresses and file names in that regard since, other than possibly sorting messages after [MTA]delivery, no automated actions are taken on them. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 24 00:29:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcDu7-00057Z-EW; Tue, 24 Oct 2006 00:28:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcDu6-00057T-Lv for ima@ietf.org; Tue, 24 Oct 2006 00:28:42 -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 1GcDu1-0007sT-8H for ima@ietf.org; Tue, 24 Oct 2006 00:28:42 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GcDtC-0000Eb-Lg for ima@ietf.org; Tue, 24 Oct 2006 06:27:48 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Oct 2006 06:27:46 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Oct 2006 06:27:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 Date: 24 Oct 2006 07:26:56 +0300 Lines: 39 Message-ID: <5dpsciuynj.fsf@Hurtta06k.keh.iki.fi> References: <20061020.220825.68136113.fujiwara@jprs.co.jp> <69395EF545F2B2B08A3B7A1A@p3.JCK.COM> <4E4D821B9BACE1BCDB3A03F8@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin writes in gmane.ietf.ima: > The difficulty is that an existing implementation gets to look > at a string that might be some encoded words and decide whether > to interpret it as (i) a literal filename, (ii) a filename in > 2231 encoding, (iii) something else. It may expect ASCII-ified > non-ASCII filenames to be represented in HTML-like, or URI-like > offset notation, not as encoded words (indeed, that > interpretation might be fairly logical). If it is a legacy > implementation that doesn't know about these things, the text of > 2045 and 2047 --if I remember them correctly-- strongly > discourage interpretation (ii) by prohibiting the use of encoded > words in filenames. While 2231 mentions filename parameters in > its introduction, it does not explicitly permit encoded words as > the value of that parameter. More important, even if it did, > there is ample reason to believe that that there are legacy > implementations around that support 2045 and 2047 but not 2231 > and 2183. So the conservative strategy for the downgrading > system is to remove any filename parameters that contain > non-ASCII characters because it is the only want that it can > know that it isn't passing along trash as advice. Again, you > may disagree, but that is "why". I'm unable to follow this. 1) If RFC 2231 encoding is done, it renames parameter names. Therefore there is not "filename" parameter for agents, which do not follow RFC 2231. 2) If there RFC 2047 encoded value on parameter in first place, looking for non-ASCII characters do not found it. Therefore RFC 2047 garbage is passed anyway -- even when non-ASCII parameters are removed. Can you specify on more detail on what sequence of events you are thinking? / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 24 02:03:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcFNe-0005ks-3J; Tue, 24 Oct 2006 02:03:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcFNd-0005kF-ES for ima@ietf.org; Tue, 24 Oct 2006 02:03:17 -0400 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcFNZ-0000aC-6V for ima@ietf.org; Tue, 24 Oct 2006 02:03:17 -0400 Received: from jeffnew (pc094.twnic.net.tw [211.72.211.94]) by twnic.net.tw (8.13.8/8.13.8) with SMTP id k9O63ACZ002400 for ; Tue, 24 Oct 2006 14:03:11 +0800 Message-ID: <00d201c6f733$a6a4f8a0$6dd348d3@jeffnew> From: "Jeff Yeh" To: Date: Tue, 24 Oct 2006 14:14:22 +0800 MIME-Version: 1.0 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.1807 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [EAI] utf8headers document update 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="===============0357920202==" Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --===============0357920202== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CF_01C6F776.B430DAA0" This is a multi-part message in MIME format. ------=_NextPart_000_00CF_01C6F776.B430DAA0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable I made a mistake on timezone diffent, and didn't make the cut-off date. Here is the updated I-D for discussion.=20 http://www.twnic.net.tw/jeff/draft-ietf-eai-utf8headers-02.txt Thank you. Jeff Yeh -TWNIC ------=_NextPart_000_00CF_01C6F776.B430DAA0 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
I made a mistake on timezone diffent, and didn't = make the=20 cut-off date.
Here is the updated I-D for discussion. =
h= ttp://www.twnic.net.tw/jeff/draft-ietf-eai-utf8headers-02.txt<= /DIV>
Thank you.
 
Jeff Yeh
-TWNIC
------=_NextPart_000_00CF_01C6F776.B430DAA0-- --===============0357920202== 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 --===============0357920202==-- From ima-bounces@ietf.org Tue Oct 24 05:12:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcIJx-0002xI-2D; Tue, 24 Oct 2006 05:11:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcIJv-0002xC-PO for ima@ietf.org; Tue, 24 Oct 2006 05:11:39 -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 1GcIJu-0003Zx-Fb for ima@ietf.org; Tue, 24 Oct 2006 05:11:39 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GcIJo-0007cd-EP for ima@ietf.org; Tue, 24 Oct 2006 11:11:32 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Oct 2006 11:11:32 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Oct 2006 11:11:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 Date: 24 Oct 2006 12:11:21 +0300 Lines: 31 Message-ID: <5dvemat6x2.fsf@Hurtta06k.keh.iki.fi> References: <20061020.220825.68136113.fujiwara@jprs.co.jp> <69395EF545F2B2B08A3B7A1A@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: > This is _not_ a proposal, and I hope we don't need to go in this > direction. However, it occurs to me that one way out of many of > these problems would be to require that the host proposing to > downgrade a message check each header for the presence of 8bit > characters. Then, if it recognizes each one --knows the header > name and the syntax rules for that header-- it can downgrade the > message. If not (i.e., if there are any headers containing 8bit > characters that are not explicitly known to the MTA), then the > message must be rejected or an NDN issued. Unknow headers can be encapsulated and original header can be then removed. That was on my suggestion From: Kari Hurtta Subject: [EAI] draft-ietf-eai-utf8headers-01.txt / draft-ietf-eai-downgrade-02.txt suggestion Newsgroups: gmane.ietf.ima Cc: Kari Hurtta Date: Sat, 14 Oct 2006 14:48:07 +0300 (EEST) draft-ietf-eai-utf8headers-01.txt part of that suggestion seems to have realized. I do not know draft-ietf-eai-downgrade-02.txt part of that suggestion yet. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 24 06:03:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcJ8E-0001LB-Nf; Tue, 24 Oct 2006 06:03:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcJ8D-0001L6-3W for ima@ietf.org; Tue, 24 Oct 2006 06:03:37 -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 1GcJ8B-0001V8-Q7 for ima@ietf.org; Tue, 24 Oct 2006 06:03:37 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GcJ85-0000hD-8h for ima@ietf.org; Tue, 24 Oct 2006 12:03:29 +0200 Received: from pd9fba934.dip0.t-ipconnect.de ([217.251.169.52]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Oct 2006 12:03:29 +0200 Received: from nobody by pd9fba934.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Oct 2006 12:03:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] utf8headers document update Date: Tue, 24 Oct 2006 12:02:51 +0200 Organization: Lines: 8 Message-ID: <453DE4CB.67A4@xyzzy.claranet.de> References: <00d201c6f733$a6a4f8a0$6dd348d3@jeffnew> 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: pd9fba934.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 Jeff Yeh wrote: > http://www.twnic.net.tw/jeff/draft-ietf-eai-utf8headers-02.txt See also http://tinyurl.com/y65mjb for a diff created by rfcdiff Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 24 18:44:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcV0j-0006Te-WD; Tue, 24 Oct 2006 18:44:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcV0i-0006TZ-Ll for ima@ietf.org; Tue, 24 Oct 2006 18:44:40 -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 1GcV0f-0005Aj-1P for ima@ietf.org; Tue, 24 Oct 2006 18:44:40 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GcV0L-0006Ui-8P for ima@ietf.org; Wed, 25 Oct 2006 00:44:17 +0200 Received: from pd9fbadc2.dip0.t-ipconnect.de ([217.251.173.194]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Oct 2006 00:44:17 +0200 Received: from nobody by pd9fbadc2.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Oct 2006 00:44:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] utf8headers document update Date: Wed, 25 Oct 2006 00:36:24 +0200 Organization: Lines: 150 Message-ID: <453E9568.72B3@xyzzy.claranet.de> References: <00d201c6f733$a6a4f8a0$6dd348d3@jeffnew> 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: pd9fbadc2.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 Jeff Yeh wrote: > http://www.twnic.net.tw/jeff/draft-ietf-eai-utf8headers-02.txt | Intended status: Informational That should be "experimental" | have a mechanism (such as self-label) or some indicator to identify s/as/as a/ (?) or s/such as/as/ (?) | To be able to do so, sending MUA MUST insert a new header field to s/sending/a sending/ - The new header specified as "Header-Type", and elements of the - header is the header type of i18n email. The i18n header field - syntax specified as below: + The new header field "Header-Type" is specified below for this + purpose: | "ASCII" indicates that it is in the format defined by RFC 2822 (and is | the default when this header field is absent); and "Downgraded" | indicates the same as "ASCII", but also that it was earlier downgraded | from "UTF8SMTP". Maybe add: ? Headers of type "ASCII" and "Downgraded" are compatible with the ? MIME content-type text/rfc822 as used in a multipart/report, see ? [RFC3462]. The important point is of course, that header type "UTF8" is _not_ compatible with RFC 3462. | Thus, when a i18n email is generated. How about "Ditto" or "Likewise, when i18n email is generated" | o The "UTF8SMTP" header field MUST be inserted by the originating | MUA. s/UTF8SMTP/Header-Type/ This MUST affects only type UTF8, or what's the idea here ? If a legacy MUA submits a message/rfc822 (= ASCII) at an UTF8-MSA, then that legacy MUA won't add Header-Type: ASCII. The MSA could add Header-Type: ASCII in this case. That's somewhere between MAY and MUST for the MSA, not the MUA. - o Whenever the email is downgraded, the content-code of the - "UTF8SMTP" MUST change to "Downgraded", the detail of downgrade - process will be described in [EAI-downgrading]. + o Whenever the email is downgraded, the content-code "UTF8" MUST + be changed to "Downgraded" as specified in [EAI-downgrading]. - SMTP client can send header fields in UTF-8 format, if the UTF8SMTP - extension advertised by SMTP server or as permitted by other - transport mechanisms. + An SMTP client can send header fields in UTF-8 format, if the + UTF8SMTP extension is advertised by the SMTP server. Other mechanisms (news, uucp, etc.) shouldn't talk with SMTP clients. | the rules in RFC 2822 for header names are not changed. s/header names/header field names/ | the header definition in RFC 2822 must extended to support new format. s/must extended/is extended here/ s/new/the new/ | That following ABNF is defined to substitute those definition s/That/The/ | For those syntax rules not referred in this section remains as the Incomplete sentence, please delete it, of course anything else in 2822 stays as is. - The use of UTF8 characters are defined as following. + The use of UTF8 characters is defined as follows: - UTF8-4 = %xF0 %x90-BF 2(UTF8-tail) / - %xF1-F7 3(UTF8-tail) + UTF8-4 = %xF0 %x90-BF 2(UTF8-tail) / + %xF1-F3 3(UTF8-tail) / + %xF4 %x80-8F 2(UTF8-tail) | These are taken from FRC 3629, s/FRC/RFC/ Where did you find F1-F7 ? - However, it will also lead to allow UTF8 characters, which - is not allowed due to the limitation describe in Section 6.4. + However, this would also affect the , which isn't desirable, + and also not allowed for the reasons outlined in Section 6.4. - In this specification, internationalized email address will be - presented in UTF-8. Thus, all header fields involving es + All header fields involving es Readers should have got the idea at this point in the spec. :-) - In that case, MTA may bounce the message with reply code 550 + In that case, the MTA may reject the message with reply code 550 The server rejects, the client can then create a DSN to the envelope sender address (3462) or reverse path (821) if necessary. - The downgrade process involve with a new ALT-ADDRESS parameter. - When downgrade occurs, the ALT-ADDRESS will be used for mail - delivery instead of the internationalized email address, the - detail is described in [EAI-downgrading]. + A downgrade process would require a new , for the + details see [EAI-downgrading]. - ; message will bounce if UTF8SMTP extension is not supported + ; the message has to be rejected if UTF8SMTP is unavailable | Internationalized domain names in Received fields must be transmitted | in punycode form. s/punycode form./an ASCII Compatible Encoding (ACE), see RFC 3490./ - subsequent downgrading would force violating rules in RFC 2821 - prohibiting altering existing Received fields. + subsequent downgrading would violate an RFC 2821 prohibition. - 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. More - generally, UTF-8 information of any sort MUST NOT appear in Received - fields, even in comments within those fields. + Unencoded UTF-8 information of any sort MUST NOT appear in + Received fields. - it is possible these two address go to different mailbox, + it is possible that these two addresses go to different mailboxes, | This might not be a protocol problem, It is a protocol problem. It needs fresh MUSTard in an "I18N-submit" memo (or here), RFC 4409 does not cover such situations in 6.1 / 8.1. It could undermine many anti-spam efforts on the side of the sender. I skipped chapter 7 in this review. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 25 01:04:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcaw7-0000UN-99; Wed, 25 Oct 2006 01:04:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcasL-0006My-Hu for ima@ietf.org; Wed, 25 Oct 2006 01:00:25 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GcaoK-0005Bd-Ec for ima@ietf.org; Wed, 25 Oct 2006 00:56:22 -0400 Received: (snipe 24328 invoked by uid 0); 25 Oct 2006 13:57:20 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.026136 secs); Received: from unknown (HELO ?192.168.10.175?) (Z???own@210.107.250.150) by unknown with SMTP; 25 Oct 2006 13:57:20 +0900 X-RCPTTO: jeff@twnic.net.tw, ima@ietf.org Message-ID: <453EEE65.1080203@icu.ac.kr> Date: Wed, 25 Oct 2006 13:56:05 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jeff Yeh Subject: Re: [EAI] utf8headers document update References: <00d201c6f733$a6a4f8a0$6dd348d3@jeffnew> In-Reply-To: <00d201c6f733$a6a4f8a0$6dd348d3@jeffnew> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 At the end of section 1.1, the document says; > This form is permitted in transmission, if authorized > by the SMTP extension specified in [EAI-SMTP-extension] or by other > transport mechanisms capable of processing it. It is nice to see that [utf8headers] doc is capable of supporting not only EAI's [smtp-ext] but also many other transport mechanisms. However, we have discussed the [utf8headers] doc in the context of [smtp-ext] doc. For example most of considerations focus on what should happen when UTF8SMTP-compliant SMTP client meets UTF8SMTP compliant/non-compliant SMTP server. Since I don't have any idea on what "other transport mechanisms" are and how they work, I am not convinced whether the decision to extend the [utf8headers] doc to support other mechanisms is safe. I guess that these (some of) "other transport mechanisms" do not support UTF8 headers as of today. Then they also need to be upgraded to support UTF8 headers. During the upgrade process, newly generated docs may refer to [utf8headers]. I think this is safer approach. I will be happy if somebody convinces me that "other transport mechanisms" can exploit [utf8headers] without any problem. :-) Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Oct 25 10:21:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcjco-0006EJ-Gg; Wed, 25 Oct 2006 10:20:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcjcn-0006C0-Ki for ima@ietf.org; Wed, 25 Oct 2006 10:20:57 -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 1Gcjce-000173-3k for ima@ietf.org; Wed, 25 Oct 2006 10:20:57 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GcjcJ-00011g-Qt for ima@ietf.org; Wed, 25 Oct 2006 16:20:28 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Oct 2006 16:20:27 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Oct 2006 16:20:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: encapsulation (Re: [EAI] ISSUE: framework -3 - missing MIME considerations) Date: 25 Oct 2006 17:20:18 +0300 Lines: 81 Message-ID: <5dac3kxysd.fsf_-_@Hurtta06k.keh.iki.fi> References: <45339923.8030900@alvestrand.no> <45343AE1.5F1C@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin writes in gmane.ietf.ima: > My impression, incidentally, is that there is growing consensus > that message/rfc822 cannot be used to encapsulate messages with > UTF-* headers. I hope that the UTF8Headers document will say > that and explain why. I'm trying to get a separate draft > written (by someone else -- the lucky party is free to identify > himself) to describe/propose a header structure that would be > suitable for such encapsulation, but it is not, at present, in > this WG's charter or critical path. lucky party? You didn't promise to stop whining if I don't write it :-) -rw-r--r-- 1 hurtta tek-tik 78680 2006-10-24 14:40 draft-hurtta-eai-encapsulation-00.txt -rw-r--r-- 1 hurtta tek-tik 88588 2006-10-24 14:40 draft-hurtta-eai-encapsulation-00.xml If I guess correctly RFC-Editor is open after that meeting, whatever it was ? / Kari Hurtta PS. Following is brain teaser: Received: from {idn-encoded-name} by downgrade.example.org with ESMTP id JGR17356; Wed, 13 Sep 2006 22:27:25 +0300 Header-Type: UTF8; downgrade=encapsulate From: { UTF-8 address } To: someone@example.org Date: Wed, 13 Sep 2006 22:27:25 +0300 Subject: { UTF-8 subject } X-Foobar: XvrT Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/XYZ-signature"; micalg="ABC"; boundary=12345 Content-Transfer-Encoding: 8bit --12345 Content-Description: { UTF-8 description } Content-Type: Text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit { UTF-8 text } --12345 Content-Type: application/XYZ-signature { signature data } --12345-- Lets assume that Text/plain is still readable after encapsulation even when reading MUA do not understand encapsulation (assuming that MUA supports MIME.) But perhaps hard part is that either signature should not found or signature should verify OK (on any point assuming that signature verify OK originally.) And after decoding encapsulate signature should verify. Hmm. draft-ietf-dkim-base-06.txt was on last call. Perhaps from it there can get also nice example? (brain teaser?) I also do not have example for attaching EAI mail for non UTF8 environment. ( If EAI mail is attached to new EAI/UTF8SMTP message, then I think that message/rfc822 can be used. However that draft do not assume that. ) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 26 05:39:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1h1-0007Sb-Kv; Thu, 26 Oct 2006 05:38:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd1gy-0007Qg-5h; Thu, 26 Oct 2006 05:38:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcq3y-0005MQ-RI; Wed, 25 Oct 2006 17:13:26 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gcpk0-0004o0-3k; Wed, 25 Oct 2006 16:52:48 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 1BEAF2ACC3; Wed, 25 Oct 2006 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GcolG-0004pW-QT; Wed, 25 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 25 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-smtpext-02.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : SMTP extension for internationalized email address Author(s) : J. Yao, W. Mao Filename : draft-ietf-eai-smtpext-02.txt Pages : 16 Date : 2006-10-25 Internationalized email address includes two parts, the local part and the domain part. The ways email addresses are used by protocols are different from the ways domain names are used. The most critical difference is that emails are delivered through a chain of peering clients and servers while domain names are resolved by name servers by looking up their own tables. In addition to this, email transport protocols SMTP and ESMTP provide a negotiation mechanism through which clients can make decisions for further processing. So internationalized email address is different from the internationalized domain name (IDN). It can be solved by exploiting the negotiation mechanism while IDN can not use the negotiation mechanism. So internationalized email address SHOULD be solved in the mail transport-level using the negotiation mechanism, which is an architecturally desirable approach. This document specifies the use of SMTP extension for internationalized email address delivery. It also mentions the backward compatible mechanism for downgrade procedure, as specified in an associated specification. The protocol proposed here is MTA-level solution which is feasible, architecturally more elegant, and not as difficult to deploy in relevant communities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-smtpext-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-smtpext-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-25113835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-smtpext-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-smtpext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-25113835.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Thu Oct 26 09:21:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5B0-0001Vy-KI; Thu, 26 Oct 2006 09:21:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd5Ay-0001Vh-VR for ima@ietf.org; Thu, 26 Oct 2006 09:21:40 -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 1Gd5Au-00087g-KR for ima@ietf.org; Thu, 26 Oct 2006 09:21:40 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gd5Af-0006eX-Fj for ima@ietf.org; Thu, 26 Oct 2006 15:21:21 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Oct 2006 15:21:21 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Oct 2006 15:21:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 26 Oct 2006 16:21:10 +0300 Lines: 52 Message-ID: <5dzmbjtdq1.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [EAI] draft-ietf-eai-smtpext-02.txt ( draft-ietf-eai-utf8headers-02.txt ) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org draft-ietf-eai-smtpext-02.txt: | Assuming that the server advertises UTF8SMTP and 8BITMIME, and at | least one non-ASCII address, with or without ALT-ADDRESS, the precise | interpretation of these parameters on the MAIL command is: | 1. Headers are in UTF-8, body parts are in ASCII. | 2. Headers are in UTF-8, some or all body parts contain 8-bit line- | oriented data. | 3. Headers are in UTF-8, some or all body parts contain binary data | without restriction as to line lengths or delimiters. So model is following: Indication for internationalized email is Header-Type: UTF8 header field on mail DATA. let's compare this to model of 8-bit MIME email model: Indication for 8-bit (MIME) emila is BODY=BITMIME parameter on MAIL -command However there is also Content-Transfer-Encoding: 8bit header field on mail DATA, but 8BITMIME extension did not select that for indication. So perhaps it make sense to compare what are differences on these two situations? Question is: Why 8BITMIME needed BODY=BITMIME parameter for MAIL -command when same information is available on email header fields ? Why UTF8SMTP does not need parameter for MAIL -command, but instead is relying email header field about that. I do not say that there is something wrong, but I ask reasoning of selections. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 26 11:21:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd729-000717-Sc; Thu, 26 Oct 2006 11:20:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd6zz-0004Hu-Nb for ima@ietf.org; Thu, 26 Oct 2006 11:18:27 -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 1Gd6ws-0004y4-2E for ima@ietf.org; Thu, 26 Oct 2006 11:15:22 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gd6wR-0003Oa-P4 for ima@ietf.org; Thu, 26 Oct 2006 17:14:47 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Oct 2006 17:14:47 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 Oct 2006 17:14:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 26 Oct 2006 18:14:18 +0300 Lines: 24 Message-ID: <5dr6wvkt2t.fsf@Hurtta06k.keh.iki.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [EAI] Re: I-D ACTION:draft-duerst-mailto-bis-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Following seems also refer to draft-ietf-eai-framework-02.txt / Kari Hurtta Internet-Drafts@ietf.org writes in gmane.ietf.announce: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The 'mailto' URI Scheme > Author(s) : M. Duerst, et al. > Filename : draft-duerst-mailto-bis-03.txt > Pages : 17 > Date : 2006-10-25 > > This document defines the format of Uniform Resource Identifiers > (URI) to identify resources that are reached using Internet mail. It > updates the syntax of 'mailto' URIs from [RFC2368] for better > compatibility with IRIs ([RFC3987]). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-03.txt _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Oct 26 22:41:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdHeY-0002fp-BN; Thu, 26 Oct 2006 22:41:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdHbd-0000ps-Du for ima@ietf.org; Thu, 26 Oct 2006 22:38:01 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdHPK-0003hx-Fx for ima@ietf.org; Thu, 26 Oct 2006 22:25:21 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k9R2PGb3001875 for ; Fri, 27 Oct 2006 11:25:16 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 1e02_6204c8cc_6562_11db_9caa_0014221fa3c9; Fri, 27 Oct 2006 11:25:16 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:35447) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 27 Oct 2006 11:24:53 +0900 Message-Id: <6.0.0.20.2.20061026182815.05d4a530@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 27 Oct 2006 11:25:01 +0900 To: ima@ietf.org From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: jwz@jwz.org, Larry Masinter Subject: [EAI] Fwd: I-D ACTION:draft-duerst-mailto-bis-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org As Kari has already mentioned, I have updated my mailto: URI draft (draft-duerst-mailto-bis) and it has been republished at http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-03.txt (see below if you need further details). Please provide feedback, in particular on I have added a reference to the EAI framework document in the introduction. The problem is that because mailto: is Standards Track and EAI (currently) is Experimental, that creates an undesired dependency (currently the reference is informative, but there may be a need for a normative reference to one or more of the EAI documents because of the following material dependency: EAI extends mail address formats from a single address to an UTF-8 address and a fallback address, as defined in http://www.twnic.net.tw/jeff/draft-ietf-eai-utf8headers-02.txt (see in particular the productions angle-addr and alt-address). If it is desirable to be able to represent this in a mailto: URI as something like mailto:UTF-8@example.org[ascii@example.org], then this dependency exists. Please note that there is no spec-wise dependency just because EAI introduces non-ASCII local parts. The mailto-bis draft simply says that non-ASCII local parts are represented as UTF-8 (percent-encoded for URIs). If there is a system that can create and deliver to such mail addresses, then people will start to use that part of the new mailto: spec. If not, then it's just something specificed but not yet implemented. There is also no need for mailto: and EAI to use the same encoding for local parts, as long as conversion is reasonably possible. The fact that they are both using UTF-8 makes things much easier for implementers, but isn't relevant for the specs to be able to work together. In terms of timeline, there are mainly three possible ways to move forward with mailto-bis: a) Wait for EAI to complete Experimental and then move to Standards Track. b) Publish mailto-bis without alt-address provisions, add these provisions in a later update. c) Publish mailto-bis without alt-address provisions, because we think than for mailto: URIs, alt-address doesn't make sense. As said above, your comments and advice are highly appreciated. Reards, Martin. >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : The 'mailto' URI Scheme > Author(s) : M. Duerst, et al. > Filename : draft-duerst-mailto-bis-03.txt > Pages : 17 > Date : 2006-10-25 > >This document defines the format of Uniform Resource Identifiers > (URI) to identify resources that are reached using Internet mail. It > updates the syntax of 'mailto' URIs from [RFC2368] for better > compatibility with IRIs ([RFC3987]). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-duerst-mailto-bis-03.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of >the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > >Internet-Drafts are also available by anonymous FTP. Login with the >username "anonymous" and a password of your e-mail address. After >logging in, type "cd internet-drafts" and then >"get draft-duerst-mailto-bis-03.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-duerst-mailto-bis-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <2006-10-25224504.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-duerst-mailto-bis-03.txt > > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 27 06:18:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdOme-00021y-Dr; Fri, 27 Oct 2006 06:17:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdOmd-00021q-Gl for ima@ietf.org; Fri, 27 Oct 2006 06:17: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 1GdOmb-0001se-17 for ima@ietf.org; Fri, 27 Oct 2006 06:17:51 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GdOmP-000079-Qo for ima@ietf.org; Fri, 27 Oct 2006 12:17:38 +0200 Received: from pd9fba94b.dip0.t-ipconnect.de ([217.251.169.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Oct 2006 12:17:37 +0200 Received: from nobody by pd9fba94b.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Oct 2006 12:17:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Fwd: I-D ACTION:draft-duerst-mailto-bis-03.txt Date: Fri, 27 Oct 2006 12:12:31 +0200 Organization: Lines: 71 Message-ID: <4541DB8F.5FD8@xyzzy.claranet.de> References: <6.0.0.20.2.20061026182815.05d4a530@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba94b.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Martin Duerst wrote: > EAI (currently) is Experimental, that creates an undesired dependency > (currently the reference is informative, but there may be a need for > a normative reference to one or more of the EAI documents Procedural nits - we could ask John how he managed to get a _normative_ reference to the 2821 (PS) in 4409 (DS). In 3461 (DS) that was "fixed" to 821 (STD) - so far it's as it should be, but the prose claiming to reference [1] = 821 obviously cites 2821. There's no "esmtp-value" in STD 10. The problems with 2368bis aren't procedural but substantial. It's not backwards compatible and nevertheless tries to preserve things that didn't work as expected, like the body= pseudo-header-field, or wild mixtures of and to= header fields. In a first step 2368 needs to be upgraded to 3986, removing cruft like body= or to=, and addressing the in-reply-to= feature (as RECOMMENDED). The issues of "raw" Unicode are a separate second step, minimally a completely separate chapter, starting with a Caveat that this won't work with existing software. UAs finding a mailto URL in a say Latin-1 encoded document won't get this right. Maybe they will assume some local default charset if they try to be "smart", And this could cause havoc, interpreting the raw UTF-8 as pseudo-Latin-1 (windows-1252), and if they really try to be "smart" maybe converting it to their default charset or even UTF-8, encoded with 2047 (or a CTE + Content-Type for the insane body= construct). 2368bis must be very clear, that if it allows UTF-8, then it will still take some years until this works as expected. At this time the experimental phase of EAI should be finished, and a 2368ter could remove the Caveat with SHOULD NOT MUSTard, or replace it by a historical note that some old UAs implemented before 2010 are expected to get 2368bis hopelessly wrong. Then we'll also have IDNAbis, and folks are used to work with normal IRIs, not this worst case "mailto:" (or "xmppp:", where the URI czar proposed to trash its published RFC - I was stunned, but at least I hope I've now grokked 3986. If so it took me "only" two years... ;-) > If it is desirable to be able to represent this in a mailto: > URI as something like mailto:UTF-8@example.org[ascii@example.org], > then this dependency exists. It will be of course desirable for 2368ter, but IMO not for 2368bis. 2368bis is already very tricky without this complication. > it's just something specificed but not yet implemented. Yes, like the in NNTP newsgroup names, it causes no harm as long as nobody uses it because it's not (yet) supported in the Netnews Article Format. BTW, NNTP got 3997 for 997bis, the RfC editor apparently loves it... :-) > a) Wait for EAI to complete Experimental and then move to > Standards Track. > b) Publish mailto-bis without alt-address provisions, add > these provisions in a later update. > c) Publish mailto-bis without alt-address provisions, because > we think than for mailto: URIs, alt-address doesn't make > sense. I'd prefer something between b and c. It would need a good place to discuss it, the URI list or maybe better (?) the rfc822 list. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 27 11:25:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTZp-0000px-I6; Fri, 27 Oct 2006 11:24:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdTZo-0000oC-QA for ima@ietf.org; Fri, 27 Oct 2006 11:24: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 1GdTZf-0004sy-4J for ima@ietf.org; Fri, 27 Oct 2006 11:24:56 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GdTQy-000393-M6 for ima@ietf.org; Fri, 27 Oct 2006 17:15:50 +0200 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Oct 2006 17:15:48 +0200 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Oct 2006 17:15:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] Fwd: I-D ACTION:draft-duerst-mailto-bis-03.txt Date: 27 Oct 2006 18:15:14 +0300 Lines: 48 Message-ID: <5d8xj1n62l.fsf@Hurtta06k.keh.iki.fi> References: <6.0.0.20.2.20061026182815.05d4a530@localhost> <4541DB8F.5FD8@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann writes in gmane.ietf.ima: > The issues of "raw" Unicode are a separate second step, > minimally a completely separate chapter, starting with a Caveat that > this won't work with existing software. UAs finding a mailto URL in > a say Latin-1 encoded document won't get this right. Maybe they will > assume some local default charset if they try to be "smart", > > And this could cause havoc, interpreting the raw UTF-8 > as pseudo-Latin-1 (windows-1252), and if they really try to be "smart" > maybe converting it to their default charset or even UTF-8, encoded > with 2047 (or a CTE + Content-Type for the insane body= construct). > > 2368bis must be very clear, that if it allows UTF-8, > then it will still take some years until this works as expected. Some MUAs try use UTF-8, some try use local charset. I think that my MUA tries UTF-8 for %xx encoded characters first if given on command line or on List-* -header fields. Anyway, these decisions are not bind to mailto -scheme. And RFC 2192 already requires UTF-8 (so using UTF-8 is natural also on other schemes, such as mailto) / Kari Hurtta ( changelog: - Added support for RFC 2368 mailto -urls. - It is unclear what character set is used on URLs. This especially effects subject header and body pseudo header on mailto url. Following rules are used: - If URL includes non-ascii characters, charset of (decoded) URL is implied charset of URL - If URL includes %XX encoded characters > %7F (ie. non-ascii) charset of decoded URL is UTF-8. This means that %XX encoding is assumed to be use UTF-8 character set. - Note that these two rules are on conflict if some, but not all non-ascii characters are % -encoded. ) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 27 14:30:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWTJ-00039z-1z; Fri, 27 Oct 2006 14:30:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdWTG-00037N-Nt for ima@ietf.org; Fri, 27 Oct 2006 14:30:22 -0400 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GdWTE-0000Ni-G5 for ima@ietf.org; Fri, 27 Oct 2006 14:30:22 -0400 Received: from source ([192.150.20.142]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Fri, 27 Oct 2006 11:30:16 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id k9RIUOIY018105; Fri, 27 Oct 2006 11:30:24 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id k9RITZec020049; Fri, 27 Oct 2006 11:30:04 -0700 (PDT) Received: from namail1.corp.adobe.com ([10.8.192.62]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 11:29:58 -0700 Received: from masinterlap06 ([153.32.46.158]) by namail1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 11:29:57 -0700 From: "Larry Masinter" To: "'Martin Duerst'" , Date: Fri, 27 Oct 2006 11:29:56 -0700 Message-ID: <000a01c6f9f5$e72ba9e0$9e2e2099@adobenet.global.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb5bycka3RyMLh5QbqjlakA45n9TQAhm8vw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <6.0.0.20.2.20061026182815.05d4a530@localhost> X-OriginalArrivalTime: 27 Oct 2006 18:29:57.0332 (UTC) FILETIME=[E786E940:01C6F9F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: jwz@jwz.org Subject: [EAI] RE: I-D ACTION:draft-duerst-mailto-bis-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > In terms of timeline, there are mainly three possible ways to > move forward with mailto-bis: > a) Wait for EAI to complete Experimental and then move to > Standards Track. > b) Publish mailto-bis without alt-address provisions, add > these provisions in a later update. > c) Publish mailto-bis without alt-address provisions, because > we think than for mailto: URIs, alt-address doesn't make > sense. I suggest: put alt-address provisions in an informational appendix, and suggest that when and if EAI moves to standards track, the mailto provisions should be reviewed and, if necessary, updated. Larry _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 27 15:31:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXQV-00018L-I9; Fri, 27 Oct 2006 15:31:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdXQU-00018E-00 for ima@ietf.org; Fri, 27 Oct 2006 15:31:34 -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 1GdXQS-00046V-4f for ima@ietf.org; Fri, 27 Oct 2006 15:31:33 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GdXQI-000EAu-Mk; Fri, 27 Oct 2006 15:31:22 -0400 Date: Fri, 27 Oct 2006 15:31:21 -0400 From: John C Klensin To: Larry Masinter , 'Martin Duerst' Subject: Re: [EAI] RE: I-D ACTION:draft-duerst-mailto-bis-03.txt Message-ID: <27CFBA7ED27C34B0A8D552CF@p3.JCK.COM> In-Reply-To: <000a01c6f9f5$e72ba9e0$9e2e2099@adobenet.global.adobe.com> References: <000a01c6f9f5$e72ba9e0$9e2e2099@adobenet.global.adobe.com> X-Mailer: Mulberry/4.0.6 (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: 4adaf050708fb13be3316a9eee889caa Cc: jwz@jwz.org, 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 Friday, 27 October, 2006 11:29 -0700 Larry Masinter wrote: >> In terms of timeline, there are mainly three possible ways to >> move forward with mailto-bis: >> a) Wait for EAI to complete Experimental and then move to >> Standards Track. >> b) Publish mailto-bis without alt-address provisions, add >> these provisions in a later update. >> c) Publish mailto-bis without alt-address provisions, because >> we think than for mailto: URIs, alt-address doesn't make >> sense. > > I suggest: put alt-address provisions in an informational > appendix, and suggest that when and if EAI moves to standards > track, the mailto provisions should be reviewed and, if > necessary, updated. Folks, move forward as you like on this, but note that... (1) At the request of several people around the time of the BOF from which EAI was organized, updating mailto when appropriate is an explicit work item for the WG. (2) If you submit this for standardization now, and the IESG follows precedent, the document will be referred to the EAI WG for evaluation. My own personal opinion is that, while I understand and sympathize with the motivation for this draft, introduction of a partially-internationalized mailto revision at this point would mostly cause confusion. In particular, while I hope the discussion is over, the possibility of a standardized ACE has started again in the EAI WG. Were that path to be chosen, %-encoded UTF-8 might turn out to be quite unattractive. So I don't think trying to wrap this up now is particularly helpful. Just my opinion. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 27 16:44:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYYN-0006iI-7h; Fri, 27 Oct 2006 16:43:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdYYM-0006gM-7L for ima@ietf.org; Fri, 27 Oct 2006 16:43:46 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdYYG-00061N-8i for ima@ietf.org; Fri, 27 Oct 2006 16:43:46 -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.231) id 45426f76.a579.1b4 for ima@ietf.org; Fri, 27 Oct 2006 21:43:34 +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 k9RKhWQi028301 for ; Fri, 27 Oct 2006 21:43:33 +0100 (BST) To: "ima@ietf.org" Subject: Re: [EAI] WG LAST CALL: draft-ietf-eai-framework-02 References: <45339923.8030900@alvestrand.no> Message-ID: Date: Fri, 27 Oct 2006 21:43:31 +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: <45339923.8030900@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d 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, 16 Oct 2006 15:37:23 +0100, Harald Alvestrand wrote: > We are therefore starting a WG Last Call on this document - of 2 weeks, > which will expire on October 30, just one week prior to the San Diego > IETF. Sorry for being so late replying to this. Most of the points I have raised are textual suggestions or niggles. So most of them don't amount to "Issues" (or, if they do, they are already under active discussion in the WG). > Overview and Framework for Internationalized Email > draft-ietf-eai-framework-02.txt >Abstract > Full use of electronic mail throughout the world requires that people > be able to use their own names, written correctly in their own > languages and scripts, as mailbox names in email addresses. This > document introduces a series of specifications that define mechanisms > and protocol extensions needed to fully support internationalized > email addresses. These changes include an SMTP extension and > extension of email header syntax to accommodate UTF-8 data. The >1. Introduction > In order to use internationalized email addresses, we need to > internationalize both the domain part and the local part of email > addresses. The domain part of email addresses is already > internationalized [RFC3490], while the local part is not. Without > these extensions, the mailbox name is restricted to a subset of 7-bit > ASCII [RFC2821]. Though MIME enables the transport of non-ASCII > data, it does not provide a mechanism for internationalized email > address. RFC 2047 [RFC2047] defines an encoding mechanism for some ^ es > specific message header fields to accommodate non-ASCII data. > However, it does not address the issue of email addresses that > include non-ASCII characters. Without the extensions defined here, > or some equivalent set, the only way to incorporate non-ASCII ^ at present > characters in email addresses is to use RFC2047 coding to embed them > in what RFC 2822 [RFC2822] calls the "display name" (known as a "name > phrase" or by other terms elsewhere) of the relevant headers. > Information coded into the display name is invisible in the message > envelope and would not be considered by many to be part of the > address at all. However, I think you need to say more than that. Granted that internationalizing addresses was the original motivation for this work, we have gone beyond that now, and in my view the possibility to have utf-8 in all headers where appropriate is at least as important as fixing the address problem. Moreover, this introductory section is our "shop window" to show the world what we are about (and hopefully to persuade it to buy what it sees). So I suugest that you mention the current 5 different mechanisms provided in various mail standards for squashing 8bit characters into 7bits, and point out how confusing this makes things for people who manage to see the "on the wire" format which, as you say, "leaks". Indeed, much of what you have written in 4.2 might usefully be moved here. And the Abstract also needs updating to convey the same emphasis. > 1.2. Problem statement > and behavior that is culturally friendly. One thing most of us have > almost certainly learned from the experience with email usage is that > users strongly prefer email addresses that closely resemble names or > initials to those involving meaningless strings of letters or > numbers. If the names or initials of the names in the email address > can be expressed in the native languages and writing systems of the > users, the Internet will be perceived as more natural, especially by > those whose native language is not written in a subset of a Roman- > derived script. You may as well add that the same is true of other natural language phrases that turn up in syntactically constrained contexts, such as URIs, s, etc. > .... That requirement has far-reaching implications: > collections of patches and workarounds are not adequate. Even if > they were adequate, a workaround-based approach may result in an > assortment of implementations with different sets of patches and > workarounds having been applied with consequent user confusion about > what is actually usable and supported.... Make it clear that you are talking about what appears on the wire here, not just what the user sees displayed. > 1.3. Terminology > In this document, an address is "all-ASCII", or just an "ASCII > address", if every character in the address is in the ASCII character > repertoire [ASCII]; an address is "non-ASCII", or "an i18mail > address", if any character is not in the ASCII character repertoire. > Such addresses may be restricted in other ways, but those > restrictions are not relevant here. The term "all-ASCII" is also > applied to other protocol elements when the distinction is important, > with "non-ASCII" or "internationalized" as its opposite. Yes, the concepts there are right, but I do not like the term "i18mail" for an address that actually contains Non-ASCII (not that I have any better suggestion). Note that you do not actually use the term with this meaning elsewhere in this draft (though you do use "i18mail user", which is not the same thing). > A "i18mail user" has one or more non-ASCII email addresses. Such a > user may have ASCII addresses too; if the user has more than one > email address, he or she has some method to choose which address to > use on outgoing email. Note that under this definition, it is not > possible to tell from the address that an email sender or recipient > is an i18mail user. For that last sentence, So What? And actually, you can tell one way round, but not the other. > 3. Document Plan > In addition to this document, the following documents make up this > specification and provide advice and context for it. > o SMTP extensions. This document [I18Nemail-SMTPext] provides an > SMTP extension for internationalized addresses, as provided for in > RFC 2821. Is not LMTP extended in the same way? > o Email headers in UTF-8. This document [I18Nemail-UTF8] > essentially updates RFC 2822 to permit some information in email ^ and some other standards > headers to be expressed directly by Unicode characters encoded in > UTF-8 when the SMTP extension described above is used. ^ ^^^ suitably enabled transports, such as , are RFC 2822 is carefully designed to be applicable to any transport protocol, not just SMTP. Our utfhdrs draft should be the same. > o In-transit downgrading from internationalized addressing with the > SMTP extension and UTF-8 headers to traditional email formats and > characters [I18Nemail-downgrade]. Downgrading either at the point > of message origination or after the mail has successfully been > received by a final delivery SMTP server (sometimes called an > "MDA") involve different constraints and possibilities; see > Section 4.3 and Section 5, below. I think it needs to be made clear somewhere that an MTA may not know whether it is the final MDA until it sees the actual message. For example, it may be a lower priority MX record holder which simply queues the message for later delivery to the primary MX. Or if may look at the local-part (which at last it is allowed to do) and decide that mail for that particular local-part has to be forwarded on (unchanged bar another Received) to somewhere else. > o Parallel extensions to the POP protocol [I18Nemail-pop]. s/POP/POP3/ throughout (you currently use both forms). Needs another bullet for mailing lists? > 4.1. SMTP Extension for Internationalized eMail Address > Some general principles apply to this work. > 1. Whatever encoding is used should apply to the whole address and > be directly compatible with software used at the user interface. Not clear what you are getting at there. Certainly not true after downgrading. > 2. An SMTP relay must > * Either recognize the format explicitly, agreeing to do so via > an ESMTP option, s/ESMTP/UTF8SMTP/ New bullet needed * Forward it to some other MTA known to support the format and willing to relay, > * Select and use an ASCII-only address, downgrading other ^ "for RCPT TO" and/or "MAIL FROM" > information as needed (see Section 4.3), or > * Bounce the message so that the sender can make another plan. And clearly it may also downgrade a limited set of "easy" cases, and bounce the rest. > If the message cannot be forwarded because the next-hop system > cannot accept the extension and insufficient information is > available to reliably downgrade it, it MUST be bounced. Or is is "rejected"? You can fight that one out with Frank. > 3. In the interest of interoperability, charsets other than UTF-8 > are prohibited. There is no practical way to identify them > properly with an extension similar to this without introducing > great complexity. But other charsets can still be used in bodies (and it may even be more convenient or economical to do so). > 4.2. Transmission of Email Header in UTF-8 Encoding Yes, RFC 2822 defines "header" with that meaning, but the rest of the world uses that term to mean "header field". So it is safer avoid using the term "header" if it is possible (as here) to use "header fields" instead. > There are many places in MUAs or in user presentation in which email > addresses or domain names appear. Examples include the conventional > From, To, or Cc header fields; Message-IDs; In-Reply-To fields that > may contain addresses or domain names; and in message bodies. Arrrrrgghhhhh! No! Message-IDs do NOT contain email addresses (they just look like email addresses). Moreover, we explicitly disallow UFT-8 inside them. > ... the user will inevitably, if only occasionally, see them > rather than "native" characters and will find that discomfiting or > astonishing. ... ^ or even totally incomprehensible > .... The only practical way to avoid these sources of > discomfort, in both the medium and the longer term, is to have the > encodings used in transport be as nearly as possible the same as the > encodings used in message headers and message bodies. Agree 100%. Note that "transport" == "on the wire". > .... This is done by > extending the encoding models of [RFC2045] and [RFC2231]. Point out that UTF-8 is for all sorts of headers (as utf8hdrs will indicate in detail), not just addresses (though those have the greatest potential impact). In particular, all headers and all headers beginning with "X-" can use it freely (we should mention X-headers explicitly, but that does NOT include arbitrary "optional" headers as per RFC 2822, because they will usually be structured extensions defined in other standards). > 4.3. Downgrading Mechanism for Backward Compatibility > o Figure out a way to downgrade the envelope or message body in > transit. s/message body/message header fields/ - generally (funny MIME stuff excepted) the message body can look after itself. > There is also a third case, one in which the client is I18Nemail- > capable, the server is not, but the message does not require the ^ particular > extended capabilities. ... >5.2. Downgrading or Other Processing After Final SMTP Delivery > When an email message is received by a final delivery SMTP server, it > is usually stored in some form. Then it is retrieved either by > software that reads the stored form directly or by client software > via some email retrieval mechanisms such as POP or IMAP. Point out that it may have to examine the local-part before it can determine how or where it is to be stored. > ... it MAY either downgrade internationalized > emails or specially identify messages that utilize these extensions, > or both. We have provided the Header-Type header to do that "specially identify". At the end of this paragraph, add: "Alternatively, it MAY bounce the message (even if it had previously accepted it), {Use of "bounce" and "accept" as per Frank} >7.1. Impact on IRIs > The mailto: schema defined in [RFC2368] and discussed in IRI > [RFC3987] may need to be modified when this work is completed and > standardized. Looks like Martin has this in hand. Be prepared to write something more substantial in here. As I have said, URIs involving I18N addresses are nothing more than "yet another ACE". And introducing IRIs into the List-* headers is orthogonal to what Martin is doing to Mailto. If we say they are (by extension) allowed in those headers, then they automatically become clickable. What Martin is doing is more related to IRIs that may turn up in message bodies. >7.4. Encoded-words, signed messages and downgrading > One particular characteristic of the email format is its persistency: > MUA are expected to handle messages that were originally sent decades ^^^ MUAs > ago and not just those delivered seconds ago. As such, MUAs and mail > filtering software will need to continue to accept and decode header > fields that use the "encoded word" mechanism [RFC2047] to accommodate ^ and the mechanisms of [RFC2231] > non-ASCII characters in some header fields. Not sure what "filtering software" you have in mind that might need to decode 2047 and 2231 stuff. > For example, message parts that are cryptographically signed using, > e.g., S/MIME [RFC2663] or PGP [RFC3156], cannot be upgraded from RFC > 2047 form to normal UTF-8 characters without breaking the signature. > Similarly, message parts that are encrypted encrypted) may contain, > when decrypted, header fields that use the RFC 2047 encoding; such > messages cannot be 'fully' upgraded without access to cryptographic > keys. When mentioning S/MIME and PGP, please make it clear that PGP refers to the use of multipart/encrypted rather than the more commonly used simple incorporation of a signed PGP text within a message body (or else make it clear it refers to both PGP usages). Why oh why didn't they call it "PGP/MIME" :-( ? > Similar issues may arise if signed messages are downgraded in transit > [I18Nemail-downgrade] and then an attempt is made to upgrade them to > the original form and then verify the signatures. Even the very > subtle changes that may result from algorithms to downgrade and then > upgrade again may be sufficient to invalidate the signatures if they > impact either the primary or MIME bodypart headers. When signatures > are present, downgrading must be performed with extreme care if at > all. Yes, we need to look at DKIM in more detail. >13. References > Please can we have all the references arranged in alphabetical order? -- 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 Oct 27 17:55:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZfq-00016I-BE; Fri, 27 Oct 2006 17:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZfp-00016D-7F for ima@ietf.org; Fri, 27 Oct 2006 17:55:33 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdZfk-0004Je-EE for ima@ietf.org; Fri, 27 Oct 2006 17:55: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-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 4542804d.e970.1a3 for ima@ietf.org; Fri, 27 Oct 2006 22:55: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 k9RLtLPn002794 for ; Fri, 27 Oct 2006 22:55:23 +0100 (BST) To: "ima@ietf.org" Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 References: <20061020.220825.68136113.fujiwara@jprs.co.jp> <69395EF545F2B2B08A3B7A1A@p3.JCK.COM> <4E4D821B9BACE1BCDB3A03F8@p3.JCK.COM> Message-ID: Date: Fri, 27 Oct 2006 22:55:21 +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: <4E4D821B9BACE1BCDB3A03F8@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 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, 24 Oct 2006 01:34:57 +0100, John C Klensin wrote: > --On Monday, 23 October, 2006 22:40 +0100 Charles Lindsey > wrote: > >> On Mon, 23 Oct 2006 16:32:56 +0100, John C Klensin >> wrote: > I caught it this time, and am replying to the list as well. > But, out of curiosity, is there some reason why your MUA and/or > MTA cannot handle a message to someone that contains a "cc" to a > list, in violation of the clear intent of 821/822/2821/2822? I heartily dislike receiving personal copies of messages sent to a mailing list. Hence, I always deliver my replies to the List only. Unfortunately, MUAs rarely provide a "reply to list" capability, so you have to dig around to see whether the list itself is in the Cc or the To header (both are seen), and edit things around. If you hit 'R', then you have to edit out the unwanted ones. If you hit 'r', you have to manually edit in the list address instead of the original sender. The 2nd way is easier, but more error prone. Periodically, people come up with perfect;y good and workable solutions to this problem on the ietf-822 mailing list. Mostly, these are well acccepted, but always the "old guard" on that list predict that what is proposed will inevitably lead to the premature Heat-Death of the Universe, and nothing ever comes of it. >>>>>>>> 5. SMTP DATA/Header Downgrading >>> Yes. That might be an argument for dropping the filename >>> parameter if one downgrades... the principle should be, IMO, >>> that a false positive is much worse than a failure. >> >> I don't see why. If it has been downgraded using RFC 2231, >> then maybe evenexisting implementations can cope with it. If >> not, then they just decidethat it is gibberish and move on to >> Plan B (which would be to invent anduse an arbitrary name). > > The difficulty is that an existing implementation gets to look > at a string that might be some encoded words and decide whether > to interpret it as (i) a literal filename, (ii) a filename in > 2231 encoding, (iii) something else. We are talking about filename parameters as defined in RFC 2183, although simiular considerations would apply to _any_ such in _any_ header where s are allowed. Of the three cases you discuss, (i) and (ii) can be distinguished syntactically. ... filename = "foobar" ... filename*=utf-8'fr-FR'nom%20de%20l'%e9l%e8ve case (iii) cannot arise (it would not be compliant with RFC 2183). > It may expect ASCII-ified > non-ASCII filenames to be represented in HTML-like, or URI-like > offset notation, not as encoded words (indeed, that > interpretation might be fairly logical). But not permitted by RFC 2183 (or alternatively, it is up to the operating system whether to understand filenames in some non-textual notation). > If it is a legacy > implementation that doesn't know about these things, the text of > 2045 and 2047 --if I remember them correctly-- strongly > discourage interpretation (ii) by prohibiting the use of encoded > words in filenames. "encoded-words" (in the RFC 2047 sense) are entirely forbidden in s, with or without RFC 2231. > ... More important, even if it did, > there is ample reason to believe that that there are legacy > implementations around that support 2045 and 2047 but not 2231 > and 2183. A legacy implementation that does not supports RFC 2183 will ignore Content-Distribution headers entirely. If it supports 2183 but not 2231, it will say "I see no 'filename' here. I shall ignore the 'filename*' because I know of no such in RFC 2183". Either way, it is fail-safe. >>> I really see no problems with allowing non-ASCII filenames. >>> My problem is only with how to downgrade them. And you can't >>> normalize in-transit unless you know that the target system >>> normalizes its file names Any normalization that is done will be done by the originating MUA, or not at all. > In the examples you give above, the headers are reasonably > well-specified, although I'm still concerned about what to do > about ones that are not well-known and well-supported in legacy > implementations. But it gives me no idea what to do about the > arbitrary "foo:" header. The only thing you can do with an arbutrary "foo:" header is to replace it with Downgraded: foo: The target legacy implementation will either see it as a "Downgraded:" header or as a "foo:" header. In either case, it is supposed to ignore it, except perhaps for displaying it to the recipient. > >>>>> But even knowing that something is an IRI or URI requires >>>>> either heuristics (bad news) of knowledge of a particular >>>>> header and its syntax. It requires knowledge of the particular header (hence my proposal explicitly to permit IRIs in those List-* headers). > See draft-ietf-eai-mailinglist-00.txt. It may or may not be > right, but the task has certainly been embarked upon. Ah! I must have missed that one. Thanks. >> Note that, from the POV of a Chinese email address, a URI is >> just another"ACE". > > Hmm. I don't think so. But I'm not a Chinese speaker or user > of systems whose primary locale is based on Chinese. The only way to indicate 8-bit stuff in a URI is in hexadecimal, with each octet preceded by a '%'. That is at least 6 ASCII characters per UTF-8 character (and probably more way up in the Chinese parts of Unicode). That is an ACE by any reckoning, and a singularly ugly one at that. As an IRI, it would look like Chinese. >> >> And even if, perchance, someone has used something beginning >> with yn-- ashis genuine local-part, that would be no different >> from someon whogenuinely intended to to use >> =?iso-8859-1?Q?RE=3A_=5BSome=A0Nonsense?= >> as the Subject of his message. It is an acceptable risk. > > See comments above about levels of acceptable risk (although I > don't expect you to agree). "Subject" (and comments) are, IMO, > much less problematic that addresses and file names in that > regard since, other than possibly sorting messages after > [MTA]delivery, no automated actions are taken on them. If we allow automatic downgrading of local-parts AT ALL, whatever ACE we use will have to produce a syntactically correct RFC 2822 local-part. Since that RFC 2822 local-part can always (however improbably) be a genuine ASCII local-part for some user in that domain, we can do nothing about it except ensure it is exceedingly improbable. Choosing any other ACE than punycode does not change the problem in any way. A "magic prefix" will still be required. I would suggest that the prefex "yn--" is as improbable as anything else one might come up with. -- 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 Oct 27 18:04:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZob-00029L-Br; Fri, 27 Oct 2006 18:04:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZoZ-00029F-L9 for ima@ietf.org; Fri, 27 Oct 2006 18:04:35 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdZoV-0004ix-1d for ima@ietf.org; Fri, 27 Oct 2006 18:04:35 -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.232) id 4542826d.11ec3.123 for ima@ietf.org; Fri, 27 Oct 2006 23:04: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 k9RM4SKf003351 for ; Fri, 27 Oct 2006 23:04:29 +0100 (BST) To: "ima@ietf.org" Subject: Re: [EAI] ISSUE: framework 7 - missing local part (ab)uses as label References: <45339923.8030900@alvestrand.no> <453446AA.739F@xyzzy.claranet.de> <5DAAD30D180E1A4125249F98@p3.JCK.COM> <453C899E.124F@xyzzy.claranet.de> <453C99E2.3020307@icu.ac.kr> <453CB14F.2A21@xyzzy.claranet.de> <6E1EBC5B4E9473014387D9A7@p3.JCK.COM> <8D2BD2C1379D72F9180C1BAC@p3.JCK.COM> Message-ID: Date: Fri, 27 Oct 2006 23:04: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: <8D2BD2C1379D72F9180C1BAC@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) 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 Mon, 23 Oct 2006 22:12:11 +0100, John C Klensin wrote: > --On Monday, 23 October, 2006 22:03 +0100 Tony Finch > wrote: > >> On Mon, 23 Oct 2006, John C Klensin wrote: >>> >>> Punycode will not work for email local parts because it is >>> case-sensitive. Adam Costello proposed a variant a while back >>> that would be case-preserving, but it wouldn't be >>> IDNA-punycode any more. >> >> Do you mean case-INsensitive in the second line above? Case >> handling is a nameprep matter, not a punycode matter. There's >> no reason that EAI couldn't use punycode with a differenc >> stringprep profile that preserves case. > > That is correct. But it would almost certainly also require a > different prefix (see earlier note) and might well require a > stringprep profile that was more different from the > IDNA/nameprep one than just preserving case. Are you now accepting that the use of Punycode for downgrding local-parts is now back on the agenda, subject to a suitable technical specification of exactly how to do it (and possibly in conjuction with an ATOMIC, or more likely DOWNGRADABLE, keyword)? -- 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 Oct 27 18:41:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaOK-0006V6-66; Fri, 27 Oct 2006 18:41:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaOJ-0006V1-Go for ima@ietf.org; Fri, 27 Oct 2006 18:41:31 -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 1GdaOI-0006zo-56 for ima@ietf.org; Fri, 27 Oct 2006 18:41:31 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GdaOH-000GP3-HO for ima@ietf.org; Fri, 27 Oct 2006 18:41:29 -0400 Date: Fri, 27 Oct 2006 18:41:28 -0400 From: John C Klensin To: ima@ietf.org Subject: Re: [EAI] ISSUE: framework 7 - missing local part (ab)uses as label Message-ID: In-Reply-To: References: <45339923.8030900@alvestrand.no> <453446AA.739F@xyzzy.claranet.de> <5DAAD30D180E1A4125249F98@p3.JCK.COM> <453C899E.124F@xyzzy.claranet.de> <453C99E2.3020307@icu.ac.kr> <453CB14F.2A21@xyzzy.claranet.de> <6E1EBC5B4E9473014387D9A7@p3.JCK.COM> <8D2BD2C1379D72F9180C1BAC@p3.JCK.COM> X-Mailer: Mulberry/4.0.6 (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: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 27 October, 2006 23:04 +0100 Charles Lindsey wrote: > On Mon, 23 Oct 2006 22:12:11 +0100, John C Klensin > wrote: > >> --On Monday, 23 October, 2006 22:03 +0100 Tony Finch >> wrote: >> >>> On Mon, 23 Oct 2006, John C Klensin wrote: >>>> >>>> Punycode will not work for email local parts because it is >>>> case-sensitive. Adam Costello proposed a variant a while >>>> back that would be case-preserving, but it wouldn't be >>>> IDNA-punycode any more. >>> >>> Do you mean case-INsensitive in the second line above? Case >>> handling is a nameprep matter, not a punycode matter. There's >>> no reason that EAI couldn't use punycode with a differenc >>> stringprep profile that preserves case. >> >> That is correct. But it would almost certainly also require a >> different prefix (see earlier note) and might well require a >> stringprep profile that was more different from the >> IDNA/nameprep one than just preserving case. > > Are you now accepting that the use of Punycode for downgrding > local-partsis now back on the agenda, subject to a suitable > technical specificationof exactly how to do it (and possibly > in conjuction with an ATOMIC, ormore likely DOWNGRADABLE, > keyword)? Only the co-chairs can "accept" anything onto the agenda, I'm just a participant. If you are asking my personal opinion, the answer is "no, I still believe it would be likely to have a negative impact on the installed base if it appeared in a downgraded message delivered to a legacy delivery MTA". john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 27 19:18:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxN-0007ir-W2; Fri, 27 Oct 2006 19:17:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdaxN-0007hM-AR for ima@ietf.org; Fri, 27 Oct 2006 19:17:45 -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 1Gdak8-0000IE-6d for ima@ietf.org; Fri, 27 Oct 2006 19:04:05 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gdajw-0006DC-Ck for ima@ietf.org; Sat, 28 Oct 2006 01:03:52 +0200 Received: from pd9fba8c7.dip0.t-ipconnect.de ([217.251.168.199]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 28 Oct 2006 01:03:52 +0200 Received: from nobody by pd9fba8c7.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 28 Oct 2006 01:03:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] RE: I-D ACTION:draft-duerst-mailto-bis-03.txt Date: Sat, 28 Oct 2006 00:35:44 +0200 Organization: Lines: 29 Message-ID: <454289C0.2BD9@xyzzy.claranet.de> References: <000a01c6f9f5$e72ba9e0$9e2e2099@adobenet.global.adobe.com> <27CFBA7ED27C34B0A8D552CF@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8c7.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > updating mailto when appropriate is an explicit work item for the WG. Maybe the charter needs an update then, and the mailto draft could be renamed to draft-ietf-eai-mailto-bis. For the 2368bis part trying to get in line with 3986 incl. fixes for several 2368 issues it might be better to ignore UTF-8 for the moment. Where is allowed adding UTF-8 later is no problem. > If you submit this for standardization now, and the IESG follows > precedent, the document will be referred to the EAI WG for evaluation. | Adding or removing documents outside of these deliverables will | require a charter update. Apparently the Charter says that anything on standards track follows after the evaluation of the experiment. It doesn't mention mailto or 2368. Or I read an obsolete version (2006-08-15). This URI stuff is tricky, mailto is the worst case. Today I found out that there's an obscure mailto.uri.arpa NAPTR waiting to be fixed. There are several issues in the mailto draft even without mentioning UTF-8, I18N, or IRIs. It needs a new clean decrufted 3986-compatible version as a solid base before adding new features. It's too complex to get this right in one giant jump. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Oct 27 20:10:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdbmU-000731-1i; Fri, 27 Oct 2006 20:10:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdbmT-0006vZ-20 for ima@ietf.org; Fri, 27 Oct 2006 20:10:33 -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 1GdbeY-0004w6-3L for ima@ietf.org; Fri, 27 Oct 2006 20:02:25 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GdbeM-0001eA-5s for ima@ietf.org; Sat, 28 Oct 2006 02:02:10 +0200 Received: from pd9fbaca6.dip0.t-ipconnect.de ([217.251.172.166]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 28 Oct 2006 02:02:10 +0200 Received: from nobody by pd9fbaca6.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 28 Oct 2006 02:02:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 7 - missing local part (ab)uses as label Date: Sat, 28 Oct 2006 01:58:53 +0200 Organization: Lines: 26 Message-ID: <45429D3D.54F5@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <453446AA.739F@xyzzy.claranet.de> <5DAAD30D180E1A4125249F98@p3.JCK.COM> <453C899E.124F@xyzzy.claranet.de> <453C99E2.3020307@icu.ac.kr> <453CB14F.2A21@xyzzy.claranet.de> <6E1EBC5B4E9473014387D9A7@p3.JCK.COM> <8D2BD2C1379D72F9180C1BAC@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbaca6.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) 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 Charles Lindsey wrote: > Are you now accepting that the use of Punycode for downgrding local-parts > is now back on the agenda, subject to a suitable technical specification > of exactly how to do it (and possibly in conjuction with an ATOMIC, or > more likely DOWNGRADABLE, keyword)? When I asked about it what I had in mind was a "standard" way to determine downgraded addresses if needed. With a feature to identify classes of"too similar" local parts. John said that's more like "too naive" => forget it. The other aspect was "something better than B32 if used as a domain label", that might still be interesting. But what's the point of these keywords ? The sending side knows its ASCII-address, and then it can use it directly instead of a "do it yourself" keyword. Without keyword the complete issue of "determine an ASCII address" is a local problem of the sending side, they can use whatever they like (including but not limited to a "standard" solution), nobody else needs to know how they did it. Is your keyword proposal somehow related to abuse and forged addresses, or what's the idea ? Obviously [ATOMIC] is shorter than [yn-cruft@example], but it needs far more places knowing how to "do it yourself". Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 28 02:50:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdi0S-0002mX-FT; Sat, 28 Oct 2006 02:49:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdi0R-0002mS-2O for ima@ietf.org; Sat, 28 Oct 2006 02:49:23 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gdi0M-0005P6-Sy for ima@ietf.org; Sat, 28 Oct 2006 02:49:23 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k9S6nDHt024615 for ; Sat, 28 Oct 2006 15:49:13 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 3981_6c054f92_6650_11db_8d44_0014221fa3c9; Sat, 28 Oct 2006 15:49:12 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:39034) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 28 Oct 2006 15:48:49 +0900 Message-Id: <6.0.0.20.2.20061028150624.06860370@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 28 Oct 2006 15:48:13 +0900 To: Frank Ellermann , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] RE: I-D ACTION:draft-duerst-mailto-bis-03.txt In-Reply-To: <454289C0.2BD9@xyzzy.claranet.de> References: <000a01c6f9f5$e72ba9e0$9e2e2099@adobenet.global.adobe.com> <27CFBA7ED27C34B0A8D552CF@p3.JCK.COM> <454289C0.2BD9@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 07:35 06/10/28, Frank Ellermann wrote: >John C Klensin wrote: > >> updating mailto when appropriate is an explicit work item for the WG. > >Maybe the charter needs an update then, Yes indeed. I was explicitly raising the question of whether a mailto: update should be part of the charter or not when chartering was discussed, and I seem to remember that the answers were mostly along the lines of "we may need coordination, but don't make this an item of the WG". I have just reread the WG charter (at http://www.ietf.org/html.charters/eai-charter.html), and I have not found any trace or hint of mailto: in there. Digging a bit, I found the following mail that provides some additional pointers to the discussion before chartering: http://www1.ietf.org/mail-archive/web/ima/current/msg00140.html. >and the mailto draft could be renamed to draft-ietf-eai-mailto-bis. I would be happy to do this (I can't speak about my coauthors), but I don't think it's necessary, and I think first there should be a clear expression of preference from a substantial part of the WG that we indeed want to change the character in this direction. >For the 2368bis part trying to >get in line with 3986 incl. fixes for several 2368 issues it might be >better to ignore UTF-8 for the moment. Where is allowed >adding UTF-8 later is no problem. Frank, here I have to disagree with you quite strongly. Allowing arbitrary byte salad first and then later trying to limit that to UTF-8 is a very bad idea. It has happened by accident a few times, but it would be a big failure to do that deliberately. Also, it would totally leave implementers in the dark about what to do with those octets. Take for example mailto:abc@example.com;body=abc%ab%cd%efdef How is an MUA supposed to send this body? What's the charset? >> If you submit this for standardization now, and the IESG follows >> precedent, the document will be referred to the EAI WG for evaluation. Yes, that's why I'm sending it here, for pre-evaluation. >There are several issues in the mailto draft even without mentioning >UTF-8, I18N, or IRIs. It needs a new clean decrufted 3986-compatible >version as a solid base before adding new features. Frank, if you send me a list of things that need to be fixed so that mailto: gets 3986-compatible, I'll be glad to do all these fixes. Or do you think they already have been made in draft-duerst-mailto-bis-03.txt? Then please say so, thanks. >It's too complex to get this right in one giant jump. I completely disgaree. There are already some mailers, e.g. Opera mail, that just do the right thing for %-encoding and UTF-8. There are others that are waiting for directions. A spec that allows to send email, but not a word besides US-ASCII (in the body, where this is possible since ages) is not something the IETF should approve in this day and age. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 28 05:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdkRO-000750-By; Sat, 28 Oct 2006 05:25:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdkRN-00070N-21 for ima@ietf.org; Sat, 28 Oct 2006 05:25:21 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdkRK-0003aj-UD for ima@ietf.org; Sat, 28 Oct 2006 05:25:20 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k9S9PH8k008707 for ; Sat, 28 Oct 2006 18:25:17 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 170d_39bb40f8_6666_11db_972a_0014221f2a2d; Sat, 28 Oct 2006 18:25:17 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40224) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 28 Oct 2006 18:24:55 +0900 Message-Id: <6.0.0.20.2.20061028180704.06863b60@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 28 Oct 2006 18:23:38 +0900 To: John C Klensin , Larry Masinter From: Martin Duerst Subject: Re: [EAI] RE: I-D ACTION:draft-duerst-mailto-bis-03.txt In-Reply-To: <27CFBA7ED27C34B0A8D552CF@p3.JCK.COM> References: <000a01c6f9f5$e72ba9e0$9e2e2099@adobenet.global.adobe.com> <27CFBA7ED27C34B0A8D552CF@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: jwz@jwz.org, 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 At 04:31 06/10/28, John C Klensin wrote: > > >--On Friday, 27 October, 2006 11:29 -0700 Larry Masinter > wrote: > >>> In terms of timeline, there are mainly three possible ways to >>> move forward with mailto-bis: >>> a) Wait for EAI to complete Experimental and then move to >>> Standards Track. >>> b) Publish mailto-bis without alt-address provisions, add >>> these provisions in a later update. >>> c) Publish mailto-bis without alt-address provisions, because >>> we think than for mailto: URIs, alt-address doesn't make >>> sense. >> >> I suggest: put alt-address provisions in an informational >> appendix, and suggest that when and if EAI moves to standards >> track, the mailto provisions should be reviewed and, if >> necessary, updated. Thanks for this idea, which is a mixture between a) and b). >My own personal opinion is that, while I understand and >sympathize with the motivation for this draft, introduction of a >partially-internationalized mailto revision at this point would >mostly cause confusion. In particular, while I hope the >discussion is over, the possibility of a standardized ACE has >started again in the EAI WG. Were that path to be chosen, >%-encoded UTF-8 might turn out to be quite unattractive. I don't think that %-encoded UTF-8 would be unattractive at all in that case. IDNA uses ACE in the protocol, but of course browsers accept real characters (i.e. IRIs) if they support IDNA. At least Opera also accepts %-encoding of IDNs, and that's what's expected by RFC 3986 and RFC 3987. It would be virtually impossible to convert between IRIs and URIs if such a conversion had to know all the different protocols and ACEs involved. Of course, if there is an ACE, that ACE will also work out of the box, because that's what the ACE is for, but it will look just ugly. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 28 06:15:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdlDr-0000LP-3R; Sat, 28 Oct 2006 06:15:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdlDq-0000LJ-Ae for ima@ietf.org; Sat, 28 Oct 2006 06:15: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 1GdlDm-0000VK-OK for ima@ietf.org; Sat, 28 Oct 2006 06:15:26 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GdlDb-0007db-EZ for ima@ietf.org; Sat, 28 Oct 2006 12:15:12 +0200 Received: from pd9fba94e.dip0.t-ipconnect.de ([217.251.169.78]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 28 Oct 2006 12:15:11 +0200 Received: from nobody by pd9fba94e.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 28 Oct 2006 12:15:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 28 Oct 2006 12:11:00 +0200 Organization: Lines: 93 Message-ID: <45432CB4.53AE@xyzzy.claranet.de> References: <000a01c6f9f5$e72ba9e0$9e2e2099@adobenet.global.adobe.com> <27CFBA7ED27C34B0A8D552CF@p3.JCK.COM> <454289C0.2BD9@xyzzy.claranet.de> <6.0.0.20.2.20061028150624.06860370@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba94e.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: [EAI] Re: I-D ACTION:draft-duerst-mailto-bis-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Martin Duerst wrote: > Allowing arbitrary byte salad first and then later trying > to limit that to UTF-8 is a very bad idea. Sorry, that wasn't what I meant, some %80guess_what_this_is is of course ugly. But in an overall structure of... mailto:a@b?c=d&e=f#g ...you'd have to allow anyway in a..f. For anything that's not covered by an derived from 3986, or used as delimiter @, ?, =, &, # Maybe the #g is bogus, then ignore it please. The spec. could then say that any outside of what's allowed by 2822 has to be UTF-8, and that all details about raw UTF-8 in email headers are not yet specified. If you want to preserve the mailbox-list feature of 2368 a better overall structure might be: mailto:a@b,c@d?e=f&g=h#i That would add "," to the delimiters used before the "?". And maybe you could allow ";" as common alternative for "&", adding ";" to the delimiters needed after the "?". Or use it on both sides (no comma), slowly drifting away from 2368 to a rather different 2368bis. Somewhere is a point when "nobody really implemented 2368 as specified" doesn't justify to invent new improved syntax anymore, that's one of the tricky issues. But in -03 it's: mailto:a@b%2Cc@d?e=f&g=h#i With %2C as delimiter, IMO that's unnatural. Admittedly it works with my vintage '96 UA, but is it in the spirit of 3986 ? Comma like ";", "=", and "&" belongs to the , it shouldn't be necessary to percent-encode it when it's used for precisely this purpose. > it would be a big failure to do that deliberately. Yes, this isn't the ftp-URI scheme, it's mailto, there are no serious legacy cases of UNKNOWN-8BIT. Maybe body values are an exception, but they're a very bad idea. > mailto:abc@example.com;body=abc%ab%cd%efdef > How is an MUA supposed to send this body? What's the charset? Delete body=, it's cruft. A well earned MUST NOT if you have to spell it out for a registration as "reserved" header field. > if you send me a list of things that need to be fixed so that > mailto: gets 3986-compatible, I'll be glad to do all these > fixes. You have a long list of 2822 features that are not allowed in mailto: After some years of fun with USEFOR I know exactly what that means, but I'm not confident that all readers know the 2822-details by heart. IMO you should specify what you weant. You'll end up with something like the in USEFOR, but probably not exactly the same, you dont need the concept of a "canonical address". Or in other words you get its without canonical backslash limitation. For now and for 2368bis. For EAI you'd have to add percent- encoded UTF-8, or reserve this in 2368bis for future use. The hname= is wrong, it should stick to the syntax of a 2822 header field name, even EAI doesn't plan to modify this. And the hvalue= is perfect (for your chosen set of delimiters). There are several similar open issues in -03. I could offer sytax for a no-nonsense 3986 adding an arbirary backslash if necessary. Or without if you prefer "canonical" compatibility with . Plus for future use. Which is again an issue, IIRC John intended to limit this to - i.e. no UTF-8 within and . UTF-8 in a domain literal is clearly stupid, but I'm not sure about (= local part as quoted string). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 28 06:30:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdlSC-0004Mq-6T; Sat, 28 Oct 2006 06:30:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdlSA-0004MY-OY for ima@ietf.org; Sat, 28 Oct 2006 06:30:14 -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 1GdlS9-0001ZM-Ax for ima@ietf.org; Sat, 28 Oct 2006 06:30:14 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GdlS4-0001KG-1o for ima@ietf.org; Sat, 28 Oct 2006 12:30:08 +0200 Received: from pd9fba94e.dip0.t-ipconnect.de ([217.251.169.78]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 28 Oct 2006 12:30:08 +0200 Received: from nobody by pd9fba94e.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 28 Oct 2006 12:30:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 28 Oct 2006 12:27:13 +0200 Organization: Lines: 49 Message-ID: <45433081.4DF6@xyzzy.claranet.de> References: <000a01c6f9f5$e72ba9e0$9e2e2099@adobenet.global.adobe.com> <27CFBA7ED27C34B0A8D552CF@p3.JCK.COM> <454289C0.2BD9@xyzzy.claranet.de> <6.0.0.20.2.20061028150624.06860370@localhost> <45432CB4.53AE@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: pd9fba94e.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [EAI] Re: I-D ACTION:draft-duerst-mailto-bis-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > IMO you should specify what you weant. s/we/w/ > There are several similar open issues in -03. I could offer > sytax for a no-nonsense 3986 adding an arbirary > backslash if necessary. Or without if you prefer "canonical" > compatibility with . > Plus for future use. Which is again > an issue, IIRC John intended to limit this to > - i.e. no UTF-8 within and . > UTF-8 in a domain literal is clearly stupid, but I'm not sure > about (= local part as quoted string). Here's a preliminary version for a pure construct: msg-id-uri = mid-left "@" mid-right ; mid-left = 1*( mid-atext / "." ) / ; ( "%22" mid-quote "%22" ) ; mid-quote = 1*( mid-atext / "." / ; incl. mid-special / ; '\"' / "[" / "]" "%5C%22" / "%5B" / "%5D" ) mid-right = 1*( mid-atext / "." ) / ; ( "%5B" mid-literal "%5D" ) ; mid-literal = 1*( mid-atext / "." / ; incl. mid-special / ; '"' / "\[" / "\]" "%22" / "%5C%5B" / "%5C%5D" ) mid-special = "(" / ")" / "," / ":" / ";" / "%3C" / "%40" / "%5C%5C" ; "<" / "@" / "\\" mid-atext = ALPHA / DIGIT / ; RFC 2822 "!" / "$" / "&" / "'" / ; allowed sub-delims "*" / "+" / "=" / ; allowed sub-delims "-" / "_" / "~" / ; allowed unreserved "%23" / "%25" / "%2F" / ; "#" / "%" / "/" "%3F" / "%5E" / "%60" / ; "?" / "^" / "`" "%7B" / "%7C" / "%7D" ; "{" / "|" / "}" That doesn't catch all the details of , it mainly enumerates cases where is REQUIRED. For an address you'd allow %3E, %5C (instead of %5C%5C), %20, and you'd add some at strategical places (TBD). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Oct 28 10:55:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdpZm-0003NF-10; Sat, 28 Oct 2006 10:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdpYv-0001F6-Ba for ima@ietf.org; Sat, 28 Oct 2006 10:53:29 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdpRP-0007D7-K4 for ima@ietf.org; Sat, 28 Oct 2006 10:45:44 -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.231) id 45436d0f.7e21.51 for ima@ietf.org; Sat, 28 Oct 2006 15:45:35 +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 k9SEjXDh018804 for ; Sat, 28 Oct 2006 15:45:34 +0100 (BST) To: "ima@ietf.org" Subject: Re: Fwd: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 References: <20061020.220825.68136113.fujiwara@jprs.co.jp> <69395EF545F2B2B08A3B7A1A@p3.JCK.COM> <91160974.20061023105052@pobox.com> Message-ID: Date: Sat, 28 Oct 2006 15:45:32 +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: <91160974.20061023105052@pobox.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) 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, 23 Oct 2006 18:50:52 +0100, Bill McQuillan wrote: > > On Mon, 2006-10-23, Charles Lindsey wrote: >> ... You might even insist on a Header-Type >> header in the introductory heading of such parts (though RFC 2045/6 >> currently allows only headers starting with "Content-" there). > > A small point: MIME body part headers MAY have header fields other than > Content-*. OK, I had mis-remembered the precise restriction. > > From RFC 2046, Sec. 5.1. para 3: > The only header fields that have defined meaning for body parts are > those the names of which begin with "Content-". All other header > fields may be ignored in body parts. Although they should generally > be retained if at all possible, they may be discarded by gateways if > necessary. Such other fields are permitted to appear in body parts > but must not be depended on. "X-" fields may be created for > experimental or private purposes, with the recognition that the > information they contain may be lost at some gateways. However, that seems to say that any header MAY appear as MIME body part header, but if it does not begin with Content-* then it may be ignored, and even discarded en route. Which, in effect, is much the same as what I said. So tying to introduce an extension for using a Header-Type header in there would be somewhat dangerous. -- 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 Sat Oct 28 11:06:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdplf-0003SK-Ir; Sat, 28 Oct 2006 11:06:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gdple-0003Pe-HC for ima@ietf.org; Sat, 28 Oct 2006 11:06:38 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdplZ-0002Ny-Tr for ima@ietf.org; Sat, 28 Oct 2006 11:06:38 -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.232) id 454371e8.f853.26 for ima@ietf.org; Sat, 28 Oct 2006 16:06: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 k9SF64v2020059 for ; Sat, 28 Oct 2006 16:06:04 +0100 (BST) To: "ima@ietf.org" Subject: Re: [EAI] utf8headers document update References: <00d201c6f733$a6a4f8a0$6dd348d3@jeffnew> <453EEE65.1080203@icu.ac.kr> Message-ID: Date: Sat, 28 Oct 2006 16:06:03 +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: <453EEE65.1080203@icu.ac.kr> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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, 25 Oct 2006 05:56:05 +0100, Yangwoo Ko wrote: > At the end of section 1.1, the document says; > > > This form is permitted in transmission, if authorized > > by the SMTP extension specified in [EAI-SMTP-extension] or by other > > transport mechanisms capable of processing it. > > > It is nice to see that [utf8headers] doc is capable of supporting > not only EAI's [smtp-ext] but also many other transport mechanisms. > > However, we have discussed the [utf8headers] doc in the context of > [smtp-ext] doc. For example most of considerations focus on what > should happen when UTF8SMTP-compliant SMTP client meets UTF8SMTP > compliant/non-compliant SMTP server. > > Since I don't have any idea on what "other transport mechanisms" are > and how they work, I am not convinced whether the decision to extend > the [utf8headers] doc to support other mechanisms is safe. Essentially, any transport mechanism that is 8bit (or even better, binary) clean is in principle able to transport UTF8SMTP messages. So FTP, UUCP, NNTP are in principle possible. Even carrier pigeons will work :-) . I don't know about X.400. I think the point is that we need to separate the document format (RFC 2822, and now utf8hdrs) from the transport mechanism. RFC 2822 can already be used with _any_ transport mechanism that will transport messages safely - it is not wedded to RFFC 2821. The same should apply to utf8hdrs. In both cases, it is up to the user (or rather his MUA) to choose a transport mechanism that is safe. For SMTP, it is easy because it is all laid out in RFC 2821 and smtpext. If he (or his implementor) wants to use any other mechanism, then it is up to him to look at whatever specification exists for that mechanism, and see whether it is suitable. We should, however, point out that extra care may be needed at gateways between diffferent transport mechanisms. This will usually involving looking to see whether there is a Header-Type header present before deciding whether the gatewaying is safe. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Oct 29 04:43:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge7C2-0004KQ-K0; Sun, 29 Oct 2006 04:43:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ge7C1-0004Jd-Cx for ima@ietf.org; Sun, 29 Oct 2006 04:43:01 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ge7Bz-0003WN-6I for ima@ietf.org; Sun, 29 Oct 2006 04:43:01 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k9T9gioa001612 for ; Sun, 29 Oct 2006 18:42:44 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 1705_d40eb380_6731_11db_8e85_0014221f2a2d; Sun, 29 Oct 2006 18:42:43 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:44321) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 29 Oct 2006 18:42:19 +0900 Message-Id: <6.0.0.20.2.20061029173555.04c54080@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 29 Oct 2006 18:25:00 +0900 To: Frank Ellermann , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] Fwd: I-D ACTION:draft-duerst-mailto-bis-03.txt In-Reply-To: <4541DB8F.5FD8@xyzzy.claranet.de> References: <6.0.0.20.2.20061026182815.05d4a530@localhost> <4541DB8F.5FD8@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: Larry Masinter , jwz@jwz.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 Hello Frank, At 19:12 06/10/27, Frank Ellermann wrote: >Martin Duerst wrote: > >> EAI (currently) is Experimental, that creates an undesired dependency >> (currently the reference is informative, but there may be a need for >> a normative reference to one or more of the EAI documents > >Procedural nits - we could ask John how he managed to get a _normative_ >reference to the 2821 (PS) in 4409 (DS). In 3461 (DS) that was "fixed" >to 821 (STD) - so far it's as it should be, but the prose claiming to >reference [1] = 821 obviously cites 2821. There's no "esmtp-value" in >STD 10. There is a special proceduce with which you can request an exception from the 'no downreferences' rule. If I remember correctly, it was proposed by John :-). >The problems with 2368bis aren't procedural but substantial. It's not >backwards compatible and nevertheless tries to preserve things that >didn't work as expected, like the body= pseudo-header-field, or wild >mixtures of and to= header fields. > >In a first step 2368 needs to be upgraded to 3986, removing cruft like >body= or to=, and addressing the in-reply-to= feature (as RECOMMENDED). I guess removing to= (well, it wouldn't just be removing, it would mean disallowing, or at least further discouraging) may be a good idea. I don't think removing body= makes sense, because I can immagine many different scenarios where being able to specify a (short) body text is helpful. Can you say exactly what you want to happen with In-Reply-To? (ideally some proposed text?). >The issues of "raw" Unicode are a separate second step, >minimally a completely separate chapter, Making this a separate chapter would make it rather complicated to write the draft; there would be two grammars, and so on. The motivation for updating mailto: came from the realization (expressed by Larry at or around the URI Scheme BOF in San Diego a few years back) that mailto: needs to be updated for IRIs. I agreed, and am working on it. If we can iron out a few other issues on the way, that's good, but we shouldn't loose the main purpose and motivation for this update. >starting with a Caveat that >this won't work with existing software. It won't work with all existing software, and I think this is so noted. The very short Section 6 is actually dedicated to this. If you have any ideas on how to better express things, please propose actual text, thanks. >UAs finding a mailto URL in >a say Latin-1 encoded document won't get this right. Some older UAs of course will not get this right. Newer ones, however, do get it right. >Maybe they will >assume some local default charset if they try to be "smart", Yes, older UAs do that for all URIs. This of course runs completely counter to the purpose of URIs, which are supposed to be independent of contexts such as which page they appear in. Please note that in the case of mailto:, IRIs may actually work better than percent- encoded URIs, because in the case of an IRI in a page encoded in iso-8859-1, the software would just take that iso-8859-1 and label it as iso-8859-1, e.g. in a Subject header. This is different from HTTP, which works on bytes. >And this could cause havoc, interpreting the raw UTF-8 >as pseudo-Latin-1 (windows-1252), and if they really try to be "smart" >maybe converting it to their default charset Yes, because there is no standard so far, existing UAs may do anything (including nothing). >or even UTF-8, encoded >with 2047 (or a CTE + Content-Type for the insane body= construct). What would be the issue with this? This would be the right thing to do pre-EAI, and is shown in various examples in the draft. >2368bis must be very clear, that if it allows UTF-8, >then it will still take some years until this works as expected. Have you read Section 6 of the current draft? I think it just says that, even in somewhat different words: UTF-8-based percent-encoding should only be used in actual mailto URIs once it is well deployed in software that interprets mailto URIs (such as mail user agents). >At this time the experimental phase of EAI should be finished, and a >2368ter could remove the Caveat with SHOULD NOT MUSTard, or replace >it by a historical note that some old UAs implemented before 2010 are >expected to get 2368bis hopelessly wrong. And at that time we would also add the syntax for fallback addresses, if we think it makes sense, yes? >Then we'll also have IDNAbis, and folks are used to work with normal >IRIs, not this worst case "mailto:" Can you say exactly what you are alluding to? >(or "xmppp:", where the URI czar >proposed to trash its published RFC - I was stunned, but at least I >hope I've now grokked 3986. If so it took me "only" two years... ;-) > >> If it is desirable to be able to represent this in a mailto: >> URI as something like mailto:UTF-8@example.org[ascii@example.org], >> then this dependency exists. > >It will be of course desirable for 2368ter, but IMO not for 2368bis. >2368bis is already very tricky without this complication. Ok, I guess I can agree with that. >> it's just something specificed but not yet implemented. > >Yes, like the in NNTP newsgroup names, it causes >no harm as long as nobody uses it because it's not (yet) supported >in the Netnews Article Format. BTW, NNTP got 3997 for 997bis, the >RfC editor apparently loves it... :-) > >> a) Wait for EAI to complete Experimental and then move to >> Standards Track. >> b) Publish mailto-bis without alt-address provisions, add >> these provisions in a later update. >> c) Publish mailto-bis without alt-address provisions, because >> we think than for mailto: URIs, alt-address doesn't make >> sense. > >I'd prefer something between b and c. It would need a good place >to discuss it, the URI list or maybe better (?) the rfc822 list. I think that with respect to alt-address, this list here is in the best position to discuss this. The decision really depends on the positioning of alt-address, such as whether this is supposed to kick in big time or just be an occasional fallback, and so on. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Oct 29 17:21:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeJ1G-0005Gd-V3; Sun, 29 Oct 2006 17:20:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeJ0q-0005Be-Nr for ima@ietf.org; Sun, 29 Oct 2006 17:20:17 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeJ0p-0004P1-Bb for ima@ietf.org; Sun, 29 Oct 2006 17:20:16 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GeJ0o-000MwU-Pt for ima@ietf.org; Sun, 29 Oct 2006 17:20:15 -0500 Date: Sun, 29 Oct 2006 17:20:14 -0500 From: John C Klensin To: ima@ietf.org Subject: Re: [EAI] ISSUE: framework 4.1 - reject Message-ID: In-Reply-To: <4538B9A9.6101@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (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: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hi. I'm trying to go through "framework" and do a final pre-IETF review and I'm still confused about what to do about the general issue associated with this thread. As I understand it, we seem to have two points of view represented in the WG: (1) If an MTA is not absolutely, 100%, sure that either 1.1. It will be able to deliver a message, all the way to the destination mailbox, in UTF8SMTP form, or if any intermediary that needs to do so will be able to downgrade correctly, i.e., there is no possibility of a subsequent NDN. 1.2 It has a certain, authentic, and deliverable reverse-path address then it MUST reject the message, where "reject" implies a 5yz code in the SMTP transaction flow, presumably before the DATA command is acknowledged with a 354 code. One of the consequences of this approach is that intermediate MX hosts are expected to know which addresses on the destination host are valid or not, without asking that host at message arrival time. When the MX intermediary is a boundary (e.g., firewall or LAN gateway) host, that may be a reasonable expectation. When it is a standby backup against the possibility of a service outage at or near the target host, it may be a very difficult one. (2) UTF8SMTP messages are handled as has been traditional with Internet mail, i.e., they are forwarded if possible with the understanding that, if they reach a point at which downgrading would be required, they may be rejected in a way that will lead to an NDN message. The purpose of this note is not to restart the discussion unless someone has something really new to say. I just want to be sure I have correctly stated the two points of view and, if not or if there are other points of view, get people to tell me/ us about them. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Oct 29 17:50:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeJTg-0003jQ-MA; Sun, 29 Oct 2006 17:50:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeJOt-0005Za-5S for ima@ietf.org; Sun, 29 Oct 2006 17:45:07 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeJC6-0005oE-SM for ima@ietf.org; Sun, 29 Oct 2006 17:31:56 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9TMVoUa022027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 29 Oct 2006 14:31:51 -0800 Received: from [10.0.1.4] (vpn-10-50-16-94.qualcomm.com [10.50.16.94]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9TMVl4n007120; Sun, 29 Oct 2006 14:31:49 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.0.0.20.2.20061029173555.04c54080@localhost> References: <6.0.0.20.2.20061026182815.05d4a530@localhost> <4541DB8F.5FD8@xyzzy.claranet.de> <6.0.0.20.2.20061029173555.04c54080@localhost> Date: Sun, 29 Oct 2006 14:31:42 -0800 To: Martin Duerst , Frank Ellermann , ima@ietf.org From: Ted Hardie Subject: Re: [EAI] Fwd: I-D ACTION:draft-duerst-mailto-bis-03.txt Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Larry Masinter , jwz@jwz.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 At the moment, the framework draft has this text: 7.1. Impact on IRIs The mailto: schema defined in [RFC2368] and discussed in IRI [RFC3987] may need to be modified when this work is completed and standardized. This implies that the working group will not take up work on the mailto: scheme until the core specs of the work have moved out of the experimental phase. If the working group plans to modify that, so that one or more URI/IRI schemes change prior to the email protocols changes becoming standards, I think the framework draft should say why. I'd also like to note that there are a lot of pieces of infrastructure out there that presume they can include an email address (SNMP MIBs, X.509 certificates, etc.). There are also a fair number of identifiers where there is a user expectation that the identifier can be "the same as" the email address, except for the scheme change (e.g. sip AORs). Those, in turn can trickle into other places--as SIP URIs can show up in radius or diameter. A close look at at least a few of these places to determine whether the proposed changes need to be fed back into further protocol changes seems in order before making the updates. I am tempted to suggest that the investigation of changes to the mailto: uri should take place in a second working group, as I suspect that the group of people is overlapping but not completely so. Putting on my AD hat for a moment, I will say that the IESG has not recently liked to approve changes to a charter in advance of the working group emitting one of its existing chartered items. In this case, I'd suggest the working group discuss what the framework document (which is an early deliverable here) needs to say as a way of framing the discussion of when the mailto URI needs to be tackled. regards, Ted Hardie _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Oct 29 18:30:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeK6l-0002TN-4V; Sun, 29 Oct 2006 18:30:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeK68-0001zZ-Nh for ima@ietf.org; Sun, 29 Oct 2006 18:29:48 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeK66-0004Xh-6o for ima@ietf.org; Sun, 29 Oct 2006 18:29:48 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GeK5v-000Na1-EG; Sun, 29 Oct 2006 18:29:35 -0500 Date: Sun, 29 Oct 2006 18:29:33 -0500 From: John C Klensin To: Ted Hardie , Martin Duerst , Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Fwd: I-D ACTION:draft-duerst-mailto-bis-03.txt Message-ID: <59E6ED57897555FC9AFD8155@p3.JCK.COM> In-Reply-To: References: <6.0.0.20.2.20061026182815.05d4a530@localhost> <4541DB8F.5FD8@xyzzy.claranet.de> <6.0.0.20.2.20061029173555.04c54080@localhost> X-Mailer: Mulberry/4.0.6 (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: 73734d43604d52d23b3eba644a169745 Cc: Larry Masinter , jwz@jwz.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 Ted, Speaking for myself only... I would be quite disappointed if the WG got distracted by taking up mailto, or other IRI issues, at this time. I think it would be premature and distracting and that the reasons for "finish first, see what the experimental use of the protocols tells us, and then look at mailto along with standards-track efforts on the protocols" still stand. My concern with the "mailto" draft at this particular time is that I fear interactions among whatever we are doing with IDNA, the efforts on i18nemail, and changes to make mailto more internationalization-friendly. In a perfect world, I'd like to see both of those development/revision efforts stabilize before mailto is changed or extended. Several email exchanges with Martin over the last couple of days have left me less concerned about changes we might have to back away from than I was a few days ago, but I'm still not completely convinced that the need for the proposed changes is great enough to justify the risk. best, john --On Sunday, 29 October, 2006 14:31 -0800 Ted Hardie wrote: > At the moment, the framework draft has this text: > > 7.1. Impact on IRIs > > The mailto: schema defined in [RFC2368] and discussed in IRI > [RFC3987] may need to be modified when this work is > completed and standardized. > > > This implies that the working group will not take up work on > the mailto: scheme until the core specs of the work have moved > out of the experimental phase. If the working group plans to > modify that, so that one or more URI/IRI schemes change prior > to the email protocols changes becoming standards, I think the > framework draft should say why. > > I'd also like to note that there are a lot of pieces of > infrastructure out there that presume they can include an > email address (SNMP MIBs, X.509 certificates, etc.). There > are also a fair number of identifiers where there is a user > expectation that the identifier can be "the same as" the email > address, except for the scheme change (e.g. sip AORs). > Those, in turn can trickle into other places--as SIP URIs can > show up in radius or diameter. A close look at at least a > few of these places to determine whether the proposed changes > need to be fed back into further protocol changes seems in > order before making the updates. > > I am tempted to suggest that the investigation of changes to > the mailto: uri should take place in a second working group, > as I suspect that the group of people is overlapping but not > completely so. > > Putting on my AD hat for a moment, I will say that the IESG > has not recently liked to approve changes to a charter in > advance of the working group emitting one of its existing > chartered items. In this case, I'd suggest the working group > discuss what the framework document (which is an early > deliverable here) needs to say as a way of framing the > discussion of when the mailto URI needs to be tackled. > regards, > Ted Hardie > > > > > > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 30 04:49:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeTkx-0005hY-TW; Mon, 30 Oct 2006 04:48:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeTbH-0006oM-HU for ima@ietf.org; Mon, 30 Oct 2006 04:38:35 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GeTbD-0004E2-Fk for ima@ietf.org; Mon, 30 Oct 2006 04:38:35 -0500 Received: (eyou send program); Mon, 30 Oct 2006 17:38:22 +0800 Message-ID: <362201102.28532@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Mon, 30 Oct 2006 17:38:22 +0800 Message-ID: <00c801c6fc07$25366410$1206e29f@cnnicyao> From: "Yao Jiankang" To: , "Kari Hurtta" References: <361868929.22352@cnnic.cn> Subject: Re: [EAI] draft-ietf-eai-smtpext-02.txt (draft-ietf-eai-utf8headers-02.txt ) Date: Mon, 30 Oct 2006 17:38:24 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1235678646==" Errors-To: ima-bounces@ietf.org --===============1235678646== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkthcmkgSHVydHRhIiA8aHVy dHRhK2dtYW5lQHNpaWxvLmZtaS5maT4NClRvOiA8aW1hQGlldGYub3JnPg0KU2VudDogVGh1cnNk YXksIE9jdG9iZXIgMjYsIDIwMDYgOToyMSBQTQ0KU3ViamVjdDogW0VBSV0gZHJhZnQtaWV0Zi1l YWktc210cGV4dC0wMi50eHQgKGRyYWZ0LWlldGYtZWFpLXV0ZjhoZWFkZXJzLTAyLnR4dCApDQoN Cg0KPiANCj4gZHJhZnQtaWV0Zi1lYWktc210cGV4dC0wMi50eHQ6DQo+IA0KPiB8ICBBc3N1bWlu ZyB0aGF0IHRoZSBzZXJ2ZXIgYWR2ZXJ0aXNlcyBVVEY4U01UUCBhbmQgOEJJVE1JTUUsIGFuZCBh dA0KPiB8ICAgbGVhc3Qgb25lIG5vbi1BU0NJSSBhZGRyZXNzLCB3aXRoIG9yIHdpdGhvdXQgQUxU LUFERFJFU1MsIHRoZSBwcmVjaXNlDQo+IHwgICBpbnRlcnByZXRhdGlvbiBvZiB0aGVzZSBwYXJh bWV0ZXJzIG9uIHRoZSBNQUlMIGNvbW1hbmQgaXM6DQo+IHwgICAxLiAgSGVhZGVycyBhcmUgaW4g VVRGLTgsIGJvZHkgcGFydHMgYXJlIGluIEFTQ0lJLg0KPiB8ICAgMi4gIEhlYWRlcnMgYXJlIGlu IFVURi04LCBzb21lIG9yIGFsbCBib2R5IHBhcnRzIGNvbnRhaW4gOC1iaXQgbGluZS0NCj4gfCAg ICAgICBvcmllbnRlZCBkYXRhLg0KPiB8ICAgMy4gIEhlYWRlcnMgYXJlIGluIFVURi04LCBzb21l IG9yIGFsbCBib2R5IHBhcnRzIGNvbnRhaW4gYmluYXJ5IGRhdGENCj4gfCAgICAgICB3aXRob3V0 IHJlc3RyaWN0aW9uIGFzIHRvIGxpbmUgbGVuZ3RocyBvciBkZWxpbWl0ZXJzLg0KPiANCj4gU28g bW9kZWwgaXMgZm9sbG93aW5nOg0KPiANCj4gICBJbmRpY2F0aW9uIGZvciBpbnRlcm5hdGlvbmFs aXplZCBlbWFpbCBpcw0KPiAgICAgIEhlYWRlci1UeXBlOiBVVEY4DQo+IA0KPiAgIGhlYWRlciBm aWVsZCBvbiBtYWlsIERBVEEuDQo+IA0KPiBsZXQncyBjb21wYXJlIHRoaXMgdG8gbW9kZWwgb2Yg OC1iaXQgTUlNRSBlbWFpbCBtb2RlbDoNCj4gDQo+ICAgSW5kaWNhdGlvbiBmb3IgOC1iaXQgKE1J TUUpICBlbWlsYSBpcw0KPiAgICAgIEJPRFk9QklUTUlNRQ0KPiANCj4gICBwYXJhbWV0ZXIgb24g TUFJTCAtY29tbWFuZA0KPiANCj4gICBIb3dldmVyIHRoZXJlIGlzIGFsc28NCj4gICAgICBDb250 ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA4Yml0DQo+IA0KPiAgIGhlYWRlciBmaWVsZCBvbiBtYWls IERBVEEsICBidXQgOEJJVE1JTUUgZXh0ZW5zaW9uIGRpZA0KPiAgIG5vdCBzZWxlY3QgdGhhdCBm b3IgaW5kaWNhdGlvbi4NCj4gDQo+IA0KPiANCj4gU28gcGVyaGFwcyBpdCBtYWtlIHNlbnNlIHRv IGNvbXBhcmUgd2hhdCBhcmUgZGlmZmVyZW5jZXMNCj4gb24gdGhlc2UgdHdvIHNpdHVhdGlvbnM/ DQo+IA0KPiBRdWVzdGlvbiBpczogDQo+IA0KPiAgIFdoeSA4QklUTUlNRSBuZWVkZWQgQk9EWT1C SVRNSU1FIHBhcmFtZXRlciBmb3IgTUFJTCAtY29tbWFuZA0KPiAgIHdoZW4gc2FtZSBpbmZvcm1h dGlvbiBpcyBhdmFpbGFibGUgb24gZW1haWwgaGVhZGVyDQo+ICAgZmllbGRzID8NCj4gDQo+ICAg V2h5IFVURjhTTVRQIGRvZXMgbm90IG5lZWQgcGFyYW1ldGVyIGZvciBNQUlMIC1jb21tYW5kLA0K PiAgIGJ1dCBpbnN0ZWFkIGlzIHJlbHlpbmcgZW1haWwgaGVhZGVyIGZpZWxkIGFib3V0IHRoYXQu DQoNCg0KT24gbXkgdmlldywgb25lIHJlYXNvbiBpcyB0aGF0IHdlIGRvIG5vdCB3YW50IHRvbyBt YW55IHBhcmFtZXRlcnMgb24gTUFJTC1jb21tYW5kcy4NClRvbyBtYW55IHBhcmFtZXRlcnMgbWF5 ICBpbXBvc2UgYWRkdGlvbmFsIGJ1cmRlbnMgb24gU01UUCAgIHByb2Nlc3NvcnMuDQpTbyBmZXcg cGFyYW1ldGVycyBhcmUgcHJlZmVyZWQgYnkgU01UUC4gU28gVVRGOFNNVFAgZG9lcyBkZXNpZ24g dG8gaGF2ZSAgZmV3IHBhcmFtZXRlcnMgZm9yIE1BSUwgLWNvbW1hbmQNCg0KWUFPIEppYW5rYW5n DQpDTk5JQw0KDQo+IA0KPiANCj4gDQo+IEkgZG8gbm90IHNheSB0aGF0IHRoZXJlIGlzIHNvbWV0 aGluZyB3cm9uZywNCj4gYnV0IEkgYXNrIHJlYXNvbmluZyBvZiBzZWxlY3Rpb25zLg0KDQpzZWUg YWJvdmUuDQoNCj4gDQo+IC8gS2FyaSBIdXJ0dGENCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEgbWFpbGluZyBsaXN0DQo+IElN QUBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWE= --===============1235678646== 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 --===============1235678646==-- From ima-bounces@ietf.org Mon Oct 30 05:07:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeU3U-0001Ak-I4; Mon, 30 Oct 2006 05:07:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeU0H-0006I9-SK for ima@ietf.org; Mon, 30 Oct 2006 05:04:25 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeTnA-0005yx-Ob for ima@ietf.org; Mon, 30 Oct 2006 04:50:57 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3^clerew$man*ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id 4545cafa.17b6.ad for ima@ietf.org; Mon, 30 Oct 2006 09:50:50 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k9U9omgl011520 for ; Mon, 30 Oct 2006 09:50:49 GMT To: "ima@ietf.org" Subject: Re: [EAI] ISSUE: framework 4.1 - reject References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> Message-ID: Date: Mon, 30 Oct 2006 09:50:47 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) 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 Sun, 29 Oct 2006 22:20:14 -0000, John C Klensin wrote: > (1) If an MTA is not absolutely, 100%, sure that either > > 1.1. It will be able to deliver a message, all the way > to the destination mailbox, in UTF8SMTP form, or if any > intermediary that needs to do so will be able to > downgrade correctly, i.e., there is no possibility of a > subsequent NDN. > > 1.2 It has a certain, authentic, and deliverable > reverse-path address I would understand here that the Return-Path "<>" is considered "deliverable", in the sense that every MTA knows the route to the bit-bucket. > (2) UTF8SMTP messages are handled as has been traditional with > Internet mail, i.e., they are forwarded if possible with the > understanding that, if they reach a point at which downgrading > would be required, they may be rejected in a way that will lead > to an NDN message. But I am not clear what the precise difference is from (1). What is an "understanding" other than what you get from (1)? I assume (2) is meant to be more liberal than (1), but it is not clear how. I agree that (1) seems a little draconian, but if senders cannot ensure that a decent Return-Path is made available, they have only themselves to blame if NDNs get lost. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 30 11:55:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeaPc-0000Mx-Dm; Mon, 30 Oct 2006 11:55:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeaPa-0000MM-Or for ima@ietf.org; Mon, 30 Oct 2006 11:54:58 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeaPW-0001cB-9x for ima@ietf.org; Mon, 30 Oct 2006 11:54:58 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GeaPV-0006XP-3T; Mon, 30 Oct 2006 11:54:53 -0500 Date: Mon, 30 Oct 2006 11:54:52 -0500 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [EAI] ISSUE: framework 4.1 - reject Message-ID: In-Reply-To: References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: 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, 30 October, 2006 09:50 +0000 Charles Lindsey wrote: > On Sun, 29 Oct 2006 22:20:14 -0000, John C Klensin > wrote: > > >> (1) If an MTA is not absolutely, 100%, sure that either >> >> 1.1. It will be able to deliver a message, all the way >> to the destination mailbox, in UTF8SMTP form, or if any >> intermediary that needs to do so will be able to >> downgrade correctly, i.e., there is no possibility of a >> subsequent NDN. >> >> 1.2 It has a certain, authentic, and deliverable >> reverse-path address > > I would understand here that the Return-Path "<>" is > considered"deliverable", in the sense that every MTA knows the > route to thebit-bucket. Yes, of course. >> (2) UTF8SMTP messages are handled as has been traditional with >> Internet mail, i.e., they are forwarded if possible with the >> understanding that, if they reach a point at which downgrading >> would be required, they may be rejected in a way that will >> lead to an NDN message. > > But I am not clear what the precise difference is from (1). > What is an"understanding" other than what you get from (1)? I > assume (2) is meant tobe more liberal than (1), but it is not > clear how. I agree that (1) seemsa little draconian, but if > senders cannot ensure that a decent Return-Pathis made > available, they have only themselves to blame if NDNs get lost. Two differences. The first is that Frank is worried about faked reverse paths being used to either spread spam or mount DoS attacks. So a key part of (1) is "authentic", not merely deliverable. Second, if one is concerned about the use of bounce messages as attacks of one sort or another, "getting lost" is not the problem. (2) is basically our existing model: if SMTP-time rejection is not possible or not convenient, NDNs get sent out if the address appears valid, i.e., if there is a valid DNS entry for the host listed in the reverse path and an SMTP connection can be established. If those conditions are not met (or if the reverse path is "<>"), then the NDN is dropped. And, since the NDN contains a <> reverse path, if the NDN message cannot be delivered at the destination host, it is dropped there. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 30 15:04:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GedMW-0006sI-Gq; Mon, 30 Oct 2006 15:04:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GedMV-0006sD-3C for ima@ietf.org; Mon, 30 Oct 2006 15:03:59 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GedMS-0002IT-NU for ima@ietf.org; Mon, 30 Oct 2006 15:03:59 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 30 Oct 2006 20:03:45 +0000 Message-ID: <45465A95.1090108@isode.com> Date: Mon, 30 Oct 2006 20:03:33 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "ima@ietf.org" Subject: Re: [EAI] WG LAST CALL: draft-ietf-eai-framework-02 References: <45339923.8030900@alvestrand.no> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Some minor comments: >4.1. SMTP Extension for Internationalized eMail Address [...] > Some general principles apply to this work. > > 1. Whatever encoding is used should apply to the whole address and > be directly compatible with software used at the user interface. Why? Can it be applied to LHS and RHS separately? >7.4. Encoded-words, signed messages and downgrading [...] > For example, message parts that are cryptographically signed using, > e.g., S/MIME [RFC2663] or PGP [RFC3156], cannot be upgraded from RFC > 2047 form to normal UTF-8 characters without breaking the signature. > Similarly, message parts that are encrypted encrypted) may contain, Repeated word "encrypted" Regards, Alexey _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 30 15:21:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geddk-0003O3-6w; Mon, 30 Oct 2006 15:21:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geddi-0003No-EL for ima@ietf.org; Mon, 30 Oct 2006 15:21:46 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geddf-0003v5-3T for ima@ietf.org; Mon, 30 Oct 2006 15:21:46 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Geddc-00089i-N3; Mon, 30 Oct 2006 15:21:40 -0500 Date: Mon, 30 Oct 2006 15:21:39 -0500 From: John C Klensin To: Alexey Melnikov , ima@ietf.org Subject: Re: [EAI] WG LAST CALL: draft-ietf-eai-framework-02 Message-ID: <1F37E1194DB5C5DD7DFEB16C@p3.JCK.COM> In-Reply-To: <45465A95.1090108@isode.com> References: <45339923.8030900@alvestrand.no> <45465A95.1090108@isode.com> X-Mailer: Mulberry/4.0.6 (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: e1e48a527f609d1be2bc8d8a70eb76cb 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 Monday, 30 October, 2006 20:03 +0000 Alexey Melnikov wrote: > Some minor comments: > > >4.1. SMTP Extension for Internationalized eMail Address > [...] > > Some general principles apply to this work. > > > > 1. Whatever encoding is used should apply to the whole > address and > > be directly compatible with software used at the user > interface. > > Why? Can it be applied to LHS and RHS separately? This was an attempt to explain, in short form, why it would not be reasonable to, e.g., require that the local part be in UTF-8 while the domain part was in punycode. If you can think of better wording, or think it needs to be made more explicit, please send text. > >7.4. Encoded-words, signed messages and downgrading > [...] > > For example, message parts that are cryptographically > signed using, > > e.g., S/MIME [RFC2663] or PGP [RFC3156], cannot be > upgraded from RFC > > 2047 form to normal UTF-8 characters without breaking the > signature. > > Similarly, message parts that are encrypted encrypted) > may contain, > > Repeated word "encrypted" fixed. thanks and regards, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 30 15:36:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gedrw-0006DT-4N; Mon, 30 Oct 2006 15:36:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gedru-0006DM-GR for ima@ietf.org; Mon, 30 Oct 2006 15:36:26 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gedrt-0005TX-2g for ima@ietf.org; Mon, 30 Oct 2006 15:36:26 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 30 Oct 2006 20:36:24 +0000 Message-ID: <4546623A.9070709@isode.com> Date: Mon, 30 Oct 2006 20:36:10 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Charles Lindsey Subject: Re: [EAI] WG LAST CALL: draft-ietf-eai-framework-02 References: <45339923.8030900@alvestrand.no> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Charles Lindsey wrote: >> 3. Document Plan >> In addition to this document, the following documents make up this >> specification and provide advice and context for it. >> o SMTP extensions. This document [I18Nemail-SMTPext] provides an >> SMTP extension for internationalized addresses, as provided for in >> RFC 2821. > > Is not LMTP extended in the same way? Good point. [...] >> 3. In the interest of interoperability, charsets other than UTF-8 >> are prohibited. There is no practical way to identify them >> properly with an extension similar to this without introducing >> great complexity. > > But other charsets can still be used in bodies (and it may even be more > convenient or economical to do so). You are right, but I think John was only talking about message headers here. >> 4.2. Transmission of Email Header in UTF-8 Encoding > > Yes, RFC 2822 defines "header" with that meaning, but the rest of the > world > uses that term to mean "header field". So it is safer avoid using the > term > "header" if it is possible (as here) to use "header fields" instead. > >> There are many places in MUAs or in user presentation in which email >> addresses or domain names appear. Examples include the conventional >> From, To, or Cc header fields; Message-IDs; In-Reply-To fields that >> may contain addresses or domain names; and in message bodies. > > Arrrrrgghhhhh! No! Message-IDs do NOT contain email addresses (they > just look > like email addresses). Yes, I've stumbled on this text as well. I think Message-ID/In-Reply-To are examples of the "or domain names" part. > Moreover, we explicitly disallow UFT-8 inside them. [...] >> 7.4. Encoded-words, signed messages and downgrading >> One particular characteristic of the email format is its persistency: >> MUA are expected to handle messages that were originally sent decades > > ^^^ > MUAs > >> ago and not just those delivered seconds ago. As such, MUAs and mail >> filtering software will need to continue to accept and decode header >> fields that use the "encoded word" mechanism [RFC2047] to accommodate > > ^ > and the mechanisms of > [RFC2231] > >> non-ASCII characters in some header fields. > > Not sure what "filtering software" you have in mind that might need > to decode > 2047 and 2231 stuff. E.g. Sieve mail filtering, which can run inside MTAs or MDAs. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 30 16:37:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeoP-0002tz-PP; Mon, 30 Oct 2006 16:36:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeeoO-0002tk-2y for ima@ietf.org; Mon, 30 Oct 2006 16:36:52 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeeoF-0002yE-CB for ima@ietf.org; Mon, 30 Oct 2006 16:36:52 -0500 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 30 Oct 2006 21:36:42 +0000 Message-ID: <45467059.5030707@isode.com> Date: Mon, 30 Oct 2006 21:36:25 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] ISSUE: framework 4.1 - reject References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: >The purpose of this note is not to restart the discussion unless >someone has something really new to say. I just want to be sure >I have correctly stated the two points of view and, > Your description looks correct to me. I just want to add "+1" for the (2) choice. It would be very nice to have (1), but I just don't think it is very practical for many existing deployments. >if not or if there are other points of view, get people to tell me/ us about >them. > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 30 17:00:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GefBG-0004TF-02; Mon, 30 Oct 2006 17:00:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GefBE-0004St-VG for ima@ietf.org; Mon, 30 Oct 2006 17:00:28 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GefB0-0006qv-KG for ima@ietf.org; Mon, 30 Oct 2006 17:00:28 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3^clerew&man*ac^uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 454675ea.161c2.5e for ima@ietf.org; Mon, 30 Oct 2006 22:00:10 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k9UM0544026955 for ; Mon, 30 Oct 2006 22:00:06 GMT To: "ima@ietf.org" Subject: Re: [EAI] draft-ietf-eai-smtpext-02.txt (draft-ietf-eai-utf8headers-02.txt ) References: <361868929.22352@cnnic.cn> <00c801c6fc07$25366410$1206e29f@cnnicyao> Message-ID: Date: Mon, 30 Oct 2006 22:00:05 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <00c801c6fc07$25366410$1206e29f@cnnicyao> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 30 Oct 2006 09:38:24 -0000, Yao Jiankang wrote: > > ----- Original Message ----- > From: "Kari Hurtta" > To: > Sent: Thursday, October 26, 2006 9:21 PM > Subject: [EAI] draft-ietf-eai-smtpext-02.txt > (draft-ietf-eai-utf8headers-02.txt ) >> >> So perhaps it make sense to compare what are differences >> on these two situations? >> >> Question is: >> >> Why 8BITMIME needed BODY=BITMIME parameter for MAIL -command >> when same information is available on email header >> fields ? >> >> Why UTF8SMTP does not need parameter for MAIL -command, >> but instead is relying email header field about that. > > > On my view, one reason is that we do not want too many parameters on > MAIL-commands. In my view, the difference is that, if 8BITMIME wants to be sure that the message is already 7bit-safe, then if has to examine the whole body (including all the multiparts) looking for a CTE: 8bit. So instead it requires a BODY=8BITMIME parameter, and if that is absent it can omit the search. In the case of UTF8SMTP, we shall arrange things so that if any deeply buried multipart has some UTF8SMTP-sensitive stuff in it, then all the parent multiparts, and in particular the top-level headers, will have Header-Type: UTF8. So the MTA needs only to examine the top-level headers, and if it detects no such header there, it need look no further. -- 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 Oct 30 17:19:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GefT0-0000io-Es; Mon, 30 Oct 2006 17:18:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GefSz-0000ii-Bd for ima@ietf.org; Mon, 30 Oct 2006 17:18:49 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GefSu-0002Sl-RM for ima@ietf.org; Mon, 30 Oct 2006 17:18:49 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GefSk-00092S-58; Mon, 30 Oct 2006 17:18:34 -0500 Date: Mon, 30 Oct 2006 17:18:33 -0500 From: John C Klensin To: Alexey Melnikov , Charles Lindsey Subject: Re: [EAI] WG LAST CALL: draft-ietf-eai-framework-02 Message-ID: In-Reply-To: <4546623A.9070709@isode.com> References: <45339923.8030900@alvestrand.no> <4546623A.9070709@isode.com> X-Mailer: Mulberry/4.0.6 (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: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 30 October, 2006 20:36 +0000 Alexey Melnikov wrote: > Charles Lindsey wrote: > >>> 3. Document Plan >>> In addition to this document, the following documents make >>> up this specification and provide advice and context for >>> it. o SMTP extensions. This document >>> [I18Nemail-SMTPext] provides an SMTP extension for >>> internationalized addresses, as provided for in RFC >>> 2821. >> >> Is not LMTP extended in the same way? > > Good point. Not in the charter. In other words, one thing at a time. If we can get this right for SMTP and then move toward standards-track specs, certainly an LMTP upgrade should be part of that effort. > [...] > >>> 3. In the interest of interoperability, charsets other >>> than UTF-8 are prohibited. There is no practical way to >>> identify them properly with an extension similar to >>> this without introducing great complexity. >> >> But other charsets can still be used in bodies (and it may >> even be more convenient or economical to do so). > > You are right, but I think John was only talking about message > headers here. Yes. But I will clarify the text. >>> 4.2. Transmission of Email Header in UTF-8 Encoding >> >> Yes, RFC 2822 defines "header" with that meaning, but the >> rest of the world >> uses that term to mean "header field". So it is safer avoid >> using the term >> "header" if it is possible (as here) to use "header fields" >> instead. Done >>> There are many places in MUAs or in user presentation in >>> which email addresses or domain names appear. Examples >>> include the conventional From, To, or Cc header fields; >>> Message-IDs; In-Reply-To fields that may contain >>> addresses or domain names; and in message bodies. >> >> Arrrrrgghhhhh! No! Message-IDs do NOT contain email addresses >> (they just look >> like email addresses). > > Yes, I've stumbled on this text as well. > > I think Message-ID/In-Reply-To are examples of the "or domain > names" part. Yes. But I have restructured the sentence to clarify this and noted that Message-IDs may be a special case. >> Moreover, we explicitly disallow UFT-8 inside them. > > [...] > >>> 7.4. Encoded-words, signed messages and downgrading >>> One particular characteristic of the email format is its >>> persistency: MUA are expected to handle messages that were >>> originally sent decades >> >> ^^^ >> MUAs fixed >>> ago and not just those delivered seconds ago. As such, >>> MUAs and mail filtering software will need to continue to >>> accept and decode header fields that use the "encoded >>> word" mechanism [RFC2047] to accommodate >> >> ^ >> and the >> mechanisms of >> [RFC2231] >> >>> non-ASCII characters in some header fields. >> >> Not sure what "filtering software" you have in mind that >> might need to decode >> 2047 and 2231 stuff. > > E.g. Sieve mail filtering, which can run inside MTAs or MDAs. Yes, that is what we had in mind along with some non-standard techniques. Do you think Sieve should be explicitly referenced as an example and, if so, should the reference be to 3028 or to something else? john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Oct 30 21:01:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geiw3-0008Sw-7E; Mon, 30 Oct 2006 21:01:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Geitw-0006wo-Mg for ima@ietf.org; Mon, 30 Oct 2006 20:58:52 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Geiiu-0003Zk-Nj for ima@ietf.org; Mon, 30 Oct 2006 20:47:34 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GeiiK-0004Ms-1C for ima@ietf.org; Tue, 31 Oct 2006 02:46:52 +0100 Received: from pd9fbace7.dip0.t-ipconnect.de ([217.251.172.231]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Oct 2006 02:46:52 +0100 Received: from nobody by pd9fbace7.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Oct 2006 02:46:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 4.1 - reject Date: Tue, 31 Oct 2006 02:44:58 +0100 Organization: Lines: 13 Message-ID: <4546AA9A.16B@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@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: pd9fbace7.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: (1) > When it is a standby backup against the possibility of a service > outage at or near the target host, it may be a very difficult one. Especially at times where it's needed, when all "call forward" or similar approaches cannot work. But that's a "normal" situation for the backup MX (= no special considerations wrt EAI), it should tempfail / reject very radically, independent of the address syntax. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 31 00:43:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GemOx-0006dk-Fi; Tue, 31 Oct 2006 00:43:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GemOw-0006da-FL for ima@ietf.org; Tue, 31 Oct 2006 00:43:06 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GemOp-0001Oi-Td for ima@ietf.org; Tue, 31 Oct 2006 00:43:06 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GemOk-0005E1-LK for ima@ietf.org; Tue, 31 Oct 2006 06:42:54 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Oct 2006 06:42:54 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Oct 2006 06:42:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] draft-ietf-eai-smtpext-02.txt (draft-ietf-eai-utf8headers-02.txt ) Date: 31 Oct 2006 07:42:43 +0200 Lines: 72 Message-ID: <5dzmbdm46k.fsf@Hurtta06k.keh.iki.fi> References: <361868929.22352@cnnic.cn> <00c801c6fc07$25366410$1206e29f@cnnicyao> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes: > On Mon, 30 Oct 2006 09:38:24 -0000, Yao Jiankang wrote: > > > > > ----- Original Message ----- > > From: "Kari Hurtta" > > To: > > Sent: Thursday, October 26, 2006 9:21 PM > > Subject: [EAI] draft-ietf-eai-smtpext-02.txt > > (draft-ietf-eai-utf8headers-02.txt ) > > >> > >> So perhaps it make sense to compare what are differences > >> on these two situations? > >> > >> Question is: > >> > >> Why 8BITMIME needed BODY=BITMIME parameter for MAIL -command > >> when same information is available on email header > >> fields ? > >> > >> Why UTF8SMTP does not need parameter for MAIL -command, > >> but instead is relying email header field about that. > > > > > > On my view, one reason is that we do not want too many parameters on > > MAIL-commands. > > In my view, the difference is that, if 8BITMIME wants to be sure that > the message is already 7bit-safe, then if has to examine the whole > body (including all the multiparts) looking for a CTE: 8bit. So > instead it requires a BODY=8BITMIME parameter, and if that is absent > it can omit the search. No. If one of subparts of multipart have content-transfer-encoding: 8bit then it means that here must be also content-transfer-encoding: 8bit on multipart itself. You image that difference. If there is 8bit data on somewhere on mail body and top level content-transfer-encoding do not say it, then it is protocol violation. RFC 2045: | The proper Content-Transfer-Encoding label must always be used. | Labelling unencoded data containing 8bit characters as "7bit" is not | allowed, nor is labelling unencoded non-line-oriented data as | anything other than "binary" allowed. > In the case of UTF8SMTP, we shall arrange things so that if any deeply > buried multipart has some UTF8SMTP-sensitive stuff in it, then all the > parent multiparts, and in particular the top-level headers, will have > Header-Type: UTF8. > > So the MTA needs only to examine the top-level headers, and if it > detects no such header there, it need look no further. > > -- > Charles H. Lindsey ---------At Home, doing my own thing------------------------ > Tel: +44 161 436 6131  >    Web: http://www.cs.man.ac.uk/~chl > Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. > PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 31 03:11:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeoiK-0001AA-Hk; Tue, 31 Oct 2006 03:11:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeoiJ-00019c-T0 for ima@ietf.org; Tue, 31 Oct 2006 03:11:15 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GeoiG-0002V4-QR for ima@ietf.org; Tue, 31 Oct 2006 03:11:15 -0500 Received: (eyou send program); Tue, 31 Oct 2006 16:11:03 +0800 Message-ID: <362282263.13735@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Tue, 31 Oct 2006 16:11:03 +0800 Message-ID: <00bf01c6fcc4$1def4f10$1206e29f@cnnicyao> From: "Yao Jiankang" To: , "Frank Ellermann" References: <20061020.220825.68136113.fujiwara@jprs.co.jp><69395EF545F2B2B08A3B7A1A@p3.JCK.COM> <361411286.17040@cnnic.cn> Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 Date: Tue, 31 Oct 2006 16:11:01 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0931266335==" Errors-To: ima-bounces@ietf.org --===============0931266335== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkZyYW5rIEVsbGVybWFubiIg PG5vYm9keUB4eXp6eS5jbGFyYW5ldC5kZT4NClRvOiA8aW1hQGlldGYub3JnPg0KU2VudDogU2F0 dXJkYXksIE9jdG9iZXIgMjEsIDIwMDYgMjoxMSBQTQ0KU3ViamVjdDogUmU6IFtFQUldIENvbW1l bnRzIG9uIGRyYWZ0LWlldGYtZWFpLWRvd25ncmFkZS0wMg0KDQoNCj4gSm9obiBDIEtsZW5zaW4g d3JvdGU6DQo+IA0KPj4+Pj4gWW91IG5lZWQgdG8gYWRkIENvbnRlbnQtVHlwZSwgQ29udGVudC1E aXNwb3NpdGlvbiwgZXRjLiB0bw0KPj4+Pj4geW91ciBsaXN0LCBhbmQgYWxzbyBMaXN0LSouDQo+ IA0KPj4+PiBJbiBteSBvcGluaW9uLCBDb250ZW50LVR5cGUsIENvbnRlbnQtRGlzcG9zaXRpb24g aGVhZGVycyBhcmUNCj4+Pj4gbm90IGV4cGFuZGVkIGFuZCBkbyBub3QgY29udGFpbiBVVEYtOCBj aGFyYWN0ZXJzLiAgU28gaXQgaXMNCj4+Pj4gaW5jbHVkZWQgaW4gb3RoZXIgaGVhZGVycyBhbmQg dGhleSBhcmUgbm90IHRhcmdldCBvZg0KPj4+PiBkb3duZ3JhZGluZy4NCj4gDQo+Pj4gVGhleSBj YW4gY2VydGFpbmx5IGNvbnRhaW4gVVRGOCBpbiBjb21tZW50cyAodGhleSBuZXZlciBkbywgb2YN Cj4+PiBjb3Vyc2UsIGJ1dGl0IGlzIGFsbG93ZWQpLg0KPiANCj4+IEFnYWluLCBpdCBzZWVtcyB0 byBtZSB0aGF0IGl0IGlzIGFsbG93ZWQgb25seSBpZiB3ZSBkZWNpZGUgdG8NCj4+IGFsbG93IGl0 LiAgQ2VydGFpbmx5IGl0IGlzIG5vdCBhbGxvd2VkIHVuZGVyIDI4MjIsIHdoaWNoDQo+PiByZXN0 cmljdHMgYWxsIGhlYWRlcnMgYW5kIGFsbCBmaWVsZHMsIGluY2x1ZGluZyBjb21tZW50cywgdG8N Cj4+IEFTQ0lJLg0KPiANCj4gUkZDIDIwNDYgaXMgYWxyZWFkeSBhdCBEUyAodW5saWtlIDI4MjIp LCBhbmQgc2NyZXdpbmcgd2l0aCBNSU1FIA0KPiBpcyBkYW5nZXJvdXMuICBUaGUgV0cgY2hhcnRl ciBleHBsaWNpdGx5IG1lbnRpb25zIG1haWxpbmcgbGlzdHMsDQo+IHRoYXQgX2NvdWxkXyBjb3Zl ciBMaXN0LSouDQo+IA0KPj4gSSBkb24ndCBzZWUgaG93IG9uZSBhcHBsaWVzIElSSS0+IFVSSSBk b3duZ3JhZGluZyB0byBhIHN0cmluZw0KPj4gaW4gYW4gYXJiaXRyYXJ5IHVua25vd24gZmllbGQu DQo+IA0KPiBVbnRpbCAyMzY4YmlzIGV4aXN0cyBsZXQncyBpZ25vcmUgdGhpcyBhcyB0b28gZGlm ZmljdWx0LCBmb2xrcw0KPiBjYW4gdXNlIFVSTHMgaW4gaGVhZGVyIGZpZWxkcywgYW5kIHRyYW5z bGF0ZSBhbnkgSVJJIHRvIGFuIFVSTC4NCj4gDQo+Pj4+PiBJIHdvdWxkIHN0aWxsIGxpa2UgdG8g YmUgYWJsZSB0byB0cmFuc2xhdGUgdGhlIDxsb2NhbC1wYXJ0Pg0KPj4+Pj4gdXNpbmcgcHVueWNv ZGUsIHBvc3NpYmxlIHJlc3RyaWN0ZWQgYnkgYW4gYXRvbWljL2Rvd25ncmFkYWJsZQ0KPj4+Pj4g cGFyYW1ldGVyLg0KPiANCj4+IEJ1dCB0aGF0IGlkZWEgd2FzIGFscmVhZHkgcmVqZWN0ZWQgYnkg dGhlIFdHLg0KPiANCj4gV2hlbiB3YXMgdGhhdCA/ICBJIHZhZ3VlbHkgcmVjYWxsIGEgc3RhdGVt ZW50IHBvc3RlZCBieSBIYXJhbGQsDQo+IGFuZCBhIGRlYmF0ZSBhYm91dCBjb25zZW5zdXMgb24g dGhlIGxpc3Qgb3IgZWxzZXdoZXJlLCB3aXRoIGFuDQo+IG91dGNvbWUgb2YgImVsc2V3aGVyZSBp cyBpcnJlbGV2YW50IiAoPykNCg0KDQpJbiBsYXN0IElFVEYgTW9udHJlYWwgbWVldGluZywgdGhl IFdHIGhhcyBnb3R0ZW4gYSByb3VnaCBjb25zZW5zdXMgYWJvdXQgcmVtb3ZpbmcgdGhlIGF0b21p YyBwYXJhbWV0ZXJzLg0KV2UgbWF5IG5vdCBmdWxseSByZWplY3QgdGhlIGlkZWEgb2YgInRyYW5z bGF0aW5nIHRoZSBsb2NhbCBwYXJ0IHRvIEFDRSIuIEl0IGlzIHVwIHRvIHVzZXJzIHdobyBkZWNp ZGVzIHdoZXRoZXIgb3Igbm90ICJ0cmFuc2xhdGluZyB0aGUgbG9jYWwgcGFydCB0byBBQ0UiIGFz IHRoZSBhbHQtYWRkcmVzcy4gYnV0IHdlIHN1Z2dlc3QgIG5vdCAidHJhbnNsYXRpbmcgdGhlIGxv Y2FsIHBhcnQgdG8gQUNFIiB0byBwcmV2ZW50IHRoZSBmdXR1cmUgcG9zc2libGUgcG90ZW50aWFs IHByb2JsZW1zIGNhdXNlZCBieSBBQ0UuDQoNCg0KWWFvIEppYW5rYW5nDQpDTk5JQw0KDQoNCg0K PiANCj4+IHlvdSBjYW4ndCB1c2UgcHVueWNvZGUsIHdoaWNoIGlzIGNhc2UtaW5zZW5zaXRpdmUu ICBZb3Ugd291bGQgDQo+PiBuZWVkIGEgZGlmZmVyZW50IEFDRS4NCj4gDQo+IFRoZSBhdXRob3Ig dG9sZCB1cyB0aGF0IGl0J3Mgbm90IG5lY2Vzc2FyaWx5IGNhc2UtaW5zZW5zaXRpdmU6DQo+IA0K PiAgPGh0dHA6Ly9hcnRpY2xlLmdtYW5lLm9yZy9nbWFuZS5pZXRmLmltYS80Mzg+IA0KPiB8fCB0 aGUgdW5kZXJseWluZyBQdW55Y29kZSBhbGdvcml0aG0gd2lsbCBjb3B5IGNhc2Utc2Vuc2l0aXZl bHkNCj4gfHwgcGVyZmVjdGx5IHNhdGlzZmFjdG9yaWx5IChldmVuIHVzaW5nIHRoZWlyIG1vZGVs IGltcGxlbWVudGF0aW9uDQo+IHwNCj4gfCBSaWdodC4gIEkgZGVzaWduZWQgUHVueWNvZGUgdG8g d29yayBmb3IgY2FzZS1zZW5zaXRpdmUgdGV4dCwNCj4gfCBjYXNlLWluc2Vuc2l0aXZlIHRleHQs IGFuZCBjYXNlLWluc2Vuc2l0aXZlIGNhc2UtcHJlc2VydmluZyB0ZXh0Lg0KPiANCj4gRnJhbmsN Cj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1h --===============0931266335== 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 --===============0931266335==-- From ima-bounces@ietf.org Tue Oct 31 05:57:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GerI6-0003rE-Hc; Tue, 31 Oct 2006 05:56:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GerI5-0003q9-3n for ima@ietf.org; Tue, 31 Oct 2006 05:56:21 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GerI0-000535-Ly for ima@ietf.org; Tue, 31 Oct 2006 05:56:21 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3#clerew^man*ac#uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 45472bca.16c43.17e for ima@ietf.org; Tue, 31 Oct 2006 10:56:10 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k9VAu8sw004853 for ; Tue, 31 Oct 2006 10:56:09 GMT To: "ima@ietf.org" Subject: Re: [EAI] ISSUE: framework 4.1 - reject References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> Message-ID: Date: Tue, 31 Oct 2006 10:56:07 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) 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, 30 Oct 2006 16:54:52 -0000, John C Klensin wrote: > Two differences. The first is that Frank is worried about faked > reverse paths being used to either spread spam or mount DoS > attacks. So a key part of (1) is "authentic", not merely > deliverable. Second, if one is concerned about the use of > bounce messages as attacks of one sort or another, "getting > lost" is not the problem. Ah! I see it now. But how can some intermediate MTA tell whether an address is 'authentic' or that it is being used to commit some DOS? And aren't these attacks just as possible on non-UTF8SMTP messages, in which case it is not our job to fix them? The only difference in the case of UTF8SMTP is that such messages may create more bounces than regular messages usually do. So I think the most we can do is draw attention to these problems under Security Considerations, in which case count me as +1 for (2). -- 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 Oct 31 06:13:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GerYT-0003tV-NW; Tue, 31 Oct 2006 06:13:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GerYS-0003rt-Ma for ima@ietf.org; Tue, 31 Oct 2006 06:13:16 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GerYN-0006in-84 for ima@ietf.org; Tue, 31 Oct 2006 06:13:16 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GerY6-00024V-1B for ima@ietf.org; Tue, 31 Oct 2006 12:12:54 +0100 Received: from pd9fba970.dip0.t-ipconnect.de ([217.251.169.112]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Oct 2006 12:12:54 +0100 Received: from nobody by pd9fba970.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Oct 2006 12:12:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-smtpext-02.txt (draft-ietf-eai-utf8headers-02.txt ) Date: Tue, 31 Oct 2006 12:12:13 +0100 Organization: Lines: 17 Message-ID: <45472F8D.2BD2@xyzzy.claranet.de> References: <361868929.22352@cnnic.cn> <00c801c6fc07$25366410$1206e29f@cnnicyao> <5dzmbdm46k.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba970.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: > No. If one of subparts of multipart have > content-transfer-encoding: 8bit > then it means that here must be also > content-transfer-encoding: 8bit > on multipart itself. ACK, the part is contained in something, that must be 8bit, and recursively the complete compound multipart/* or message/* must be 8bit. Frank P.S.: Sorry for the 9"9"7 vs. 977 confusion elsewhere _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 31 06:43:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ges1j-00028Y-UK; Tue, 31 Oct 2006 06:43:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ges1i-00027o-M6 for ima@ietf.org; Tue, 31 Oct 2006 06:43:30 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ges1g-0003HN-CN for ima@ietf.org; Tue, 31 Oct 2006 06:43:30 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ges1X-0007Ug-E6 for ima@ietf.org; Tue, 31 Oct 2006 12:43:19 +0100 Received: from pd9fba970.dip0.t-ipconnect.de ([217.251.169.112]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Oct 2006 12:43:19 +0100 Received: from nobody by pd9fba970.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Oct 2006 12:43:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] draft-ietf-eai-smtpext-02.txt ( draft-ietf-eai-utf8headers-02.txt ) Date: Tue, 31 Oct 2006 12:40:59 +0100 Organization: Lines: 29 Message-ID: <4547364B.481A@xyzzy.claranet.de> References: <5dzmbjtdq1.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba970.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: > Question is: > Why 8BITMIME needed BODY=BITMIME parameter for MAIL -command > when same information is available on email header > fields ? > Why UTF8SMTP does not need parameter for MAIL -command, > but instead is relying email header field about that. > I do not say that there is something wrong, > but I ask reasoning of selections. Maybe because UTF8SMTP is a special case of 8BITMIME as far as SMTP (envelope) is concerned. Normally MTAs dont't care about what they transport as long as they can add a timestamp line to it. An MDA could remove old Return-Paths and add its own, but for that exercise it also only needs to find a header and the relevant Return-Path header fields. And of course they need to find the dot at the end of data, for that's enough if they can read lines (=> limit 998) terminated by CRLF, no matter what octets there are elsewhere, UTF-8 or other charsets, 8BITMIME works as expected. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 31 07:05:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GesMU-0002aq-Qm; Tue, 31 Oct 2006 07:04:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GesMU-0002al-31 for ima@ietf.org; Tue, 31 Oct 2006 07:04:58 -0500 Received: from lon-mail-8.gradwell.net ([193.111.200.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GesMM-0006aY-AO for ima@ietf.org; Tue, 31 Oct 2006 07:04:57 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3$clerew&man*ac^uk) by lon-mail-8.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.234) id 45473bd6.16428.3b08 for ima@ietf.org; Tue, 31 Oct 2006 12:04:38 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k9VC4TEX009036 for ; Tue, 31 Oct 2006 12:04:30 GMT To: "ima@ietf.org" Subject: Re: [EAI] RE: I-D ACTION:draft-duerst-mailto-bis-03.txt References: <000a01c6f9f5$e72ba9e0$9e2e2099@adobenet.global.adobe.com> Message-ID: Date: Tue, 31 Oct 2006 12:04:28 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <000a01c6f9f5$e72ba9e0$9e2e2099@adobenet.global.adobe.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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, 27 Oct 2006 19:29:56 +0100, Larry Masinter wrote: > I suggest: put alt-address provisions in an informational appendix, > and suggest that when and if EAI moves to standards track, the > mailto provisions should be reviewed and, if necessary, updated. That is one way. What we are looking for is a means to say "this is the mail address to send to, but if that does not work, then you can try this other one instead. But please do not try both at the same time." Now there is no reason why Martin should not define such a feature into his draft, and there is no reason why he should not (just by coincidence, of course :-) ) do it using the same syntax as we are using for UTF8SMTP. But in that case, please do not publish it until UTF8SMTP is out there as an Experimental Protocol (but that is a sensible time scale anyway). And bear in mind that a future standardized version of UTF8SMTP would then be constrained not to alter that syntax - which it would probably not want to do anyway. -- 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 Oct 31 07:12:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GesTs-0005XU-AS; Tue, 31 Oct 2006 07:12:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GesTq-0005XL-8Y for ima@ietf.org; Tue, 31 Oct 2006 07:12:34 -0500 Received: from lon-mail-8.gradwell.net ([193.111.200.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GesTh-0008QS-W8 for ima@ietf.org; Tue, 31 Oct 2006 07:12:33 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3#clerew&man#ac#uk) by lon-mail-8.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.234) id 45473da8.c9dc.fde for ima@ietf.org; Tue, 31 Oct 2006 12:12:24 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k9VCCJLl009639 for ; Tue, 31 Oct 2006 12:12:20 GMT To: "ima@ietf.org" Subject: Re: [EAI] Fwd: I-D ACTION:draft-duerst-mailto-bis-03.txt References: <6.0.0.20.2.20061026182815.05d4a530@localhost> <4541DB8F.5FD8@xyzzy.claranet.de> <6.0.0.20.2.20061029173555.04c54080@localhost> Message-ID: Date: Tue, 31 Oct 2006 12:12:18 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, 29 Oct 2006 22:31:42 -0000, Ted Hardie wrote: > > I am tempted to suggest that the investigation of changes to the mailto: > uri > should take place in a second working group, as I suspect that the > group of people is overlapping but not completely so. The proper place for such discussions is on the uri@w3.org mailing list, and most of the current discussions between Frank and Martin really belong there and should be moved there. Naturally, this WG would like to be kept informed of matters related to UTF-8, but the present proposals to allow UTF-8 either %-encoded or raw in an IRI seem fine. And this WG would certainly expect to be consulted if some proposal to include alt-addresses were to be incorporated. -- 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 Oct 31 07:16:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GesXn-0007Rc-H1; Tue, 31 Oct 2006 07:16:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GesXm-0007RS-HF for ima@ietf.org; Tue, 31 Oct 2006 07:16:38 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GesXh-0000oW-FL for ima@ietf.org; Tue, 31 Oct 2006 07:16:38 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GesXg-000FPg-LU; Tue, 31 Oct 2006 07:16:32 -0500 Date: Tue, 31 Oct 2006 07:16:31 -0500 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [EAI] ISSUE: framework 4.1 - reject Message-ID: <916243710B2640AB5B15061E@p3.JCK.COM> In-Reply-To: References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (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: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 31 October, 2006 10:56 +0000 Charles Lindsey wrote: > On Mon, 30 Oct 2006 16:54:52 -0000, John C Klensin > wrote: > >> Two differences. The first is that Frank is worried about >> faked reverse paths being used to either spread spam or mount >> DoS attacks. So a key part of (1) is "authentic", not merely >> deliverable. Second, if one is concerned about the use of >> bounce messages as attacks of one sort or another, "getting >> lost" is not the problem. > > Ah! I see it now. But how can some intermediate MTA tell > whether anaddress is 'authentic' or that it is being used to > commit some DOS? Well, that is the problem. It is clearly possible if all intermediate MTAs are clearly under the administrative control of the sender and have access to their user/address tables (for backward-pointing addresses) and all target MTAs are clearly under the administrative control of the target receiver host and have access to its user/address tables (for forward-pointing addresses). There are several "in between" cases that I consider important; I gather Frank is willing to essentially prohibit them in order to fend off spammers. But I may not have this right; see next note. > Andaren't these attacks just as possible on > non-UTF8SMTP messages, in whichcase it is not our job to fix > them? The only difference in the case ofUTF8SMTP is that such > messages may create more bounces than regularmessages usually > do. I believe that is the case. The fact that the same argument is coming up in the discussion of Dave Crocker's "email model" document on the SMTP list may support that conclusion. > So I think the most we can do is draw attention to these > problems underSecurity Considerations, in which case count me > as +1 for (2). Ack. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 31 07:29:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gesjy-0007vw-BP; Tue, 31 Oct 2006 07:29:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gesjx-0007vU-7q for ima@ietf.org; Tue, 31 Oct 2006 07:29:13 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gesjv-0002wD-Om for ima@ietf.org; Tue, 31 Oct 2006 07:29:13 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Gesjv-000FTq-2d; Tue, 31 Oct 2006 07:29:11 -0500 Date: Tue, 31 Oct 2006 07:29:10 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] ISSUE: framework 4.1 - reject Message-ID: In-Reply-To: <4546AA9A.16B@xyzzy.claranet.de> References: <45339923.8030900@alvestrand.no> <45343E6F.6AC4@xyzzy.claranet.de> <45348E2E.1060703@alvestrand.no> <6C50875B746DB0E507B47392@p3.JCK.COM> <4536EC66.3A14@xyzzy.claranet.de> <45386B14.C0D@xyzzy.claranet.de> <4538B9A9.6101@xyzzy.claranet.de> <4546AA9A.16B@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.6 (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: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 31 October, 2006 02:44 +0100 Frank Ellermann wrote: > John C Klensin wrote: > > (1) >> When it is a standby backup against the possibility of a >> service outage at or near the target host, it may be a very >> difficult one. > > Especially at times where it's needed, when all "call forward" > or similar approaches cannot work. But that's a "normal" > situation for the backup MX (= no special considerations wrt > EAI), it should tempfail / reject very radically, independent > of the address syntax. Frank, I don't understand what you are saying above. Perhaps a word is missing; perhaps I'm just confused. What I often refer to as a "backup MX" is a mail server that doesn't fate-share (with regard to either location or connectivity) with the server on which the target mailbox is located. It generally doesn't receive mail unless the target server either goes off-net or offline. When the target server is off-net or offline, the backup MX receives all traffic bound for the target server and stores it for future delivery -- either until the target server is available again or until the messages can be transmitted in some other fashion (there is, e.g., a long and important history of transferring mail queues to magnetic storage and transmitting them to target servers via automobile or airplane when the target server has suffered an extended network outage). Historically, such servers often exist as the result of reciprocal agreements ("you provide backup for my mail servers and I'll provide backup for yours"), sometimes even between entities that normally treat each other as major competitors but nonetheless trust each other's integrity. And, in the normal case, the arrangements are rarely used -- a few sequential days once a year would probably be considered a lot. For those cases, keeping up-to-date user (or valid mailbox) lists on the backup MX host would be burdensome and probably even be considered a serious breach of privacy of business information. But, as I understand it, your proposal would prohibit those kinds of arrangements entirely, since the backup MX host would not have knowledge of the authenticity of sending addresses (systems generally don't) and would have no way to know whether a target mailbox address was valid. It wouldn't have up-to-date tables of valid mailboxes for the reasons cited above, and it couldn't do real-time forward checks (VRFY?) because, by definition, the target destination host would be unreachable. I don't think that conclusion, and prohibition, is tolerable, at least without an email regime in which only trusted hosts are permitted to send mail (and global trust is somehow established), all email is authenticated wrt validity of sender and address, and all relays were required to verify the authentication and credentials. Such a regime would have many advantages, IMO, but we are nowhere near getting there. YMMD. And, as Charles has pointed out, all of these issues exist without any i18n extensions, so they are not really the province of this WG. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 31 08:11:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GetP0-0005UT-7X; Tue, 31 Oct 2006 08:11:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GetOy-0005UI-Qz for ima@ietf.org; Tue, 31 Oct 2006 08:11:36 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GetOr-0002AB-75 for ima@ietf.org; Tue, 31 Oct 2006 08:11:36 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3^clerew*man$ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 45474b7e.4988.81 for ima@ietf.org; Tue, 31 Oct 2006 13:11:26 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k9VDBNRm013558 for ; Tue, 31 Oct 2006 13:11:24 GMT To: "ima@ietf.org" References: <20061020.220825.68136113.fujiwara@jprs.co.jp> <69395EF545F2B2B08A3B7A1A@p3.JCK.COM> <361411286.17040@cnnic.cn> <00bf01c6fcc4$1def4f10$1206e29f@cnnicyao> Message-ID: Date: Tue, 31 Oct 2006 13:11:22 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <00bf01c6fcc4$1def4f10$1206e29f@cnnicyao> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.5 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [EAI] Punycode (was Comments on draft-ietf-eai-downgrade-02) 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, 31 Oct 2006 08:11:01 -0000, Yao Jiankang wrote: > > ----- Original Message ----- > From: "Frank Ellermann" > To: > Sent: Saturday, October 21, 2006 2:11 PM > Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 > >> >>> But that idea was already rejected by the WG. >> >> When was that ? I vaguely recall a statement posted by Harald, >> and a debate about consensus on the list or elsewhere, with an >> outcome of "elsewhere is irrelevant" (?) > > > In last IETF Montreal meeting, the WG has gotten a rough consensus about > removing the atomic parameters. Yes, but not all the WG was present, or able to be present, at Montreal. And no announcement was made to this list that such a consensus had been reached. Since then, that matter has been raised again and several people seem to wish to pursue the possibility further. It has now been established that punycode is NOT case-insensitive (provided you do not confuse "pure punycode" from RFC 3492 with the additional cruft contained in "IDNA" from RFC 3490). That earlier misunderstanding may have influenced the discussions at Montreal. It seems now that the only technical objection to punycode is that it may downgrade into an RFC 2822 that is already the name of some other user in the relevant domain. But if the downgraded is prefixed by something like "yn--", that is pretty unlikely, and a well-organized domain that had both UTF8 and ASCII users could easily ensure that this situation did not arise. Moreover, this problem would arise with any ACE that might be proposed. So if punycode is to be rejected for this reason, then any other ACE must also be rejected. I think we earlier agreed that if some "ATOMIC" parameter was to be associated with any such downgrade, then the keyword to be used should be "DOWNGRADABLE". I therefore request the Chairs to consider whether, in view of these recent discussions, the possibility of using some automatic downgrade of s can be put back on our Agenda. (And punycode, if its usage is carefully worded, still seems the best candidate for the purpose.) -- 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 Oct 31 09:15:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeuOd-0007sh-B6; Tue, 31 Oct 2006 09:15:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeuOM-0007lh-PP for ima@ietf.org; Tue, 31 Oct 2006 09:15:02 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeuOE-0004Dm-Oj for ima@ietf.org; Tue, 31 Oct 2006 09:15:02 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GeuN8-0004AQ-1p for ima@ietf.org; Tue, 31 Oct 2006 15:13:46 +0100 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Oct 2006 15:13:46 +0100 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 31 Oct 2006 15:13:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Side note (Re: [EAI] Punycode (was Comments on draft-ietf-eai-downgrade-02)) Date: 31 Oct 2006 16:13:30 +0200 Lines: 40 Message-ID: <5dfyd4efp1.fsf_-_@leija.fmi.fi> References: <20061020.220825.68136113.fujiwara@jprs.co.jp> <69395EF545F2B2B08A3B7A1A@p3.JCK.COM> <361411286.17040@cnnic.cn> <00bf01c6fcc4$1def4f10$1206e29f@cnnicyao> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes: <...> > I think we earlier agreed that if some "ATOMIC" parameter was to be > associated with any such downgrade, then the keyword to be used should > be "DOWNGRADABLE". Side note: I do not understand why keyword is needed (on place of alt-address). If origin host / mail domain is arranged automatic upgrading to some punycode form, it can directly put that downgraded form to alt-address. > I therefore request the Chairs to consider whether, in view of these > recent discussions, the possibility of using some automatic downgrade > of s can be put back on our Agenda. Some informational RFC may be usefull for "Automatic generation of downgraded addresses from UTF8 address" which gives recommentation for origin host how that to do. ( Origin host have also full possibility to preserver all possible special characters (such as '+') and special prefixes and suffixes on original places, when doing downgrading, if it wants do it that way. ) > (And punycode, if its usage is carefully worded, still seems the best > candidate for the purpose.) > > -- > Charles H. Lindsey ---------At Home, doing my own thing------------------------ > Tel: +44 161 436 6131  >    Web: http://www.cs.man.ac.uk/~chl > Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. > PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 31 14:00:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeypQ-0002q2-7x; Tue, 31 Oct 2006 13:59:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GeypO-0002oR-Nc for ima@ietf.org; Tue, 31 Oct 2006 13:59:14 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GeypC-0002g9-14 for ima@ietf.org; Tue, 31 Oct 2006 13:59:14 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Geyp5-000Inr-Iq; Tue, 31 Oct 2006 13:58:55 -0500 Date: Tue, 31 Oct 2006 13:58:54 -0500 From: John C Klensin To: Charles Lindsey , ima@ietf.org Subject: Re: [EAI] Punycode (was Comments on draft-ietf-eai-downgrade-02) Message-ID: <8DFD33C21BE6083EC1A9247C@p3.JCK.COM> In-Reply-To: References: <20061020.220825.68136113.fujiwara@jprs.co.jp> <69395EF545F2B2B08A3B7A1A@p3.JCK.COM> <361411286.17040@cnnic.cn> <00bf01c6fcc4$1def4f10$1206e29f@cnnicyao> X-Mailer: Mulberry/4.0.6 (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: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 31 October, 2006 13:11 +0000 Charles Lindsey wrote: > On Tue, 31 Oct 2006 08:11:01 -0000, Yao Jiankang > wrote: > >> >> ----- Original Message ----- >> From: "Frank Ellermann" >> To: >> Sent: Saturday, October 21, 2006 2:11 PM >> Subject: Re: [EAI] Comments on draft-ietf-eai-downgrade-02 >> >>> >>>> But that idea was already rejected by the WG. >>> >>> When was that ? I vaguely recall a statement posted by >>> Harald, and a debate about consensus on the list or >>> elsewhere, with an outcome of "elsewhere is irrelevant" (?) >> >> >> In last IETF Montreal meeting, the WG has gotten a rough >> consensus about removing the atomic parameters. > > Yes, but not all the WG was present, or able to be present, at > Montreal.And no announcement was made to this list that such a > consensus had beenreached. > > Since then, that matter has been raised again and several > people seem towish to pursue the possibility further. > > It has now been established that punycode is NOT > case-insensitive(provided you do not confuse "pure punycode" > from RFC 3492 with theadditional cruft contained in "IDNA" > from RFC 3490). That earliermisunderstanding may have > influenced the discussions at Montreal. > > It seems now that the only technical objection to punycode is > that it maydowngrade into an RFC 2822 that is > already the name of someother user in the relevant domain. But > if the downgraded isprefixed by something like > "yn--", that is pretty unlikely, and awell-organized domain > that had both UTF8 and ASCII users could easilyensure that > this situation did not arise. To put part of that objection slightly more precisely, there is a concern that a delivery SMTP server system might be using a coding convention for the local part that selected names with particular character sequences for special processing. For example, it would not be terribly unreasonable for a delivery system to have a rule that any string that contained two consecutive hyphens was to be routed to one system or set of systems for processing as commands while anything without that string was to be routed to a different system or subsystem for delivery (or processing) as mail. Depending on the order in which processing occurred and a few other issues, users sending to a "yn--" downgraded address might get rather confusing error messages... a problem that could not be avoided simply by the domain's choice of addresses to be used, especially if it had not been upgraded to deal with i18n email addresses, downgraded or not. The other part of that objection is the comment in "framework" about having different encodings for the local part and the domain part. That is a preference, not a firm requirement, but the reasons for the preference in terms of avoiding user confusion or astonishment should be fairly clear. > Moreover, this problem would arise with any ACE that might be > proposed. Soif punycode is to be rejected for this reason, > then any other ACE mustalso be rejected. That is, indeed, the reason why much of the discussion --and the language in "framework" and its predecessors-- focuses on explicit, destination-specified, alternate addresses (or destination-authorized use of a particular ACE via the late ATOMIC option), rather than arbitrary downgrading to a sender-selected, or standard-selected, ACE. > I think we earlier agreed that if some "ATOMIC" parameter was > to beassociated with any such downgrade, then the keyword to > be used should be"DOWNGRADABLE". My impression continues to be that we gave up on that whole model, with a preference to instead simply specify the alternate address. I'll leave the question of whether there was, or was not, consensus on that point in the hands of the co-chairs. > I therefore request the Chairs to consider whether, in view of > theserecent discussions, the possibility of using some > automatic downgrade ofs can be put back on our > Agenda. > > (And punycode, if its usage is carefully worded, still seems > the bestcandidate for the purpose.) This is certainly a request you can make. I hope they will respond in a timely fashion. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 31 17:00:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1eE-0004AW-OF; Tue, 31 Oct 2006 16:59:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1eC-00045T-EY for ima@ietf.org; Tue, 31 Oct 2006 16:59:52 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf1e9-0005sf-2t for ima@ietf.org; Tue, 31 Oct 2006 16:59:52 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 146A72580EE; Tue, 31 Oct 2006 22:57:00 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01615-04; Tue, 31 Oct 2006 22:56:54 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id BC58B2580D3; Tue, 31 Oct 2006 22:56:54 +0100 (CET) Message-ID: <4547C74E.4040509@alvestrand.no> Date: Tue, 31 Oct 2006 22:59:42 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] ISSUE: framework 6 - delete section References: <45339923.8030900@alvestrand.no> <453445CC.7F86@xyzzy.claranet.de> <682A932E049D20A39E8D1B2F@p3.JCK.COM> <453710B5.3B0E@xyzzy.claranet.de> In-Reply-To: <453710B5.3B0E@xyzzy.claranet.de> 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: 9466e0365fc95844abaf7c3f15a05c7d 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: > John C Klensin wrote: > > >>> The complete I-D is about I18N, it doesn't need this >>> redundant section. >>> > > >> This section is an IESG requirement. Take it up with >> the rule-makers and nit-pickers. >> > > Harald would tell us if we violate this rule without a > good reason, he has invented it, it is a SHOULD, not a > MUST. In a document with I18N in its title following > that rule literally with a dummy section is pointless - > AFAIK the nit-picking tools don't try to enforce this. FWIW, I've argued against a mandatory "internationalization requirements" section at every turn, arguing instead that the issues need to be discussed when we need to, in the form that's best suited for them. And I still can't see any requirement for it in , so I guess someone's been listening. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Oct 31 19:17:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf3nJ-0004EI-3a; Tue, 31 Oct 2006 19:17:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf3nE-0004DO-Fn for ima@ietf.org; Tue, 31 Oct 2006 19:17:20 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf3nD-00067H-4v for ima@ietf.org; Tue, 31 Oct 2006 19:17:20 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1Gf3nA-000LKa-HV; Tue, 31 Oct 2006 19:17:16 -0500 Date: Tue, 31 Oct 2006 19:17:15 -0500 From: John C Klensin To: Harald Alvestrand , Frank Ellermann Subject: Re: [EAI] ISSUE: framework 6 - delete section Message-ID: In-Reply-To: <4547C74E.4040509@alvestrand.no> References: <45339923.8030900@alvestrand.no> <453445CC.7F86@xyzzy.claranet.de> <682A932E049D20A39E8D1B2F@p3.JCK.COM> <453710B5.3B0E@xyzzy.claranet.de> <4547C74E.4040509@alvestrand.no> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 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 Tuesday, 31 October, 2006 22:59 +0100 Harald Alvestrand wrote: > Frank Ellermann wrote: >> John C Klensin wrote: >> >> >>>> The complete I-D is about I18N, it doesn't need this >>>> redundant section. >>>> >> >> >>> This section is an IESG requirement. Take it up with >>> the rule-makers and nit-pickers. >>> >> >> Harald would tell us if we violate this rule without a >> good reason, he has invented it, it is a SHOULD, not a >> MUST. In a document with I18N in its title following >> that rule literally with a dummy section is pointless - >> AFAIK the nit-picking tools don't try to enforce this. > FWIW, I've argued against a mandatory "internationalization > requirements" section at every turn, arguing instead that the > issues need to be discussed when we need to, in the form > that's best suited for them. > > And I still can't see any requirement for it in > , so I guess someone's > been listening. I will take that as direction to remove it from the working draft :-) john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima