From ima-bounces@ietf.org Thu Mar 01 05:12:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMiGA-0001Da-SE; Thu, 01 Mar 2007 05:11:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMi8A-0001p0-1r for ima@ietf.org; Thu, 01 Mar 2007 05:03:23 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMi87-00089s-MH for ima@ietf.org; Thu, 01 Mar 2007 05:03:22 -0500 Received: (eyou send program); Thu, 01 Mar 2007 18:03:11 +0800 Message-ID: <372743391.13410@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, 01 Mar 2007 18:03:11 +0800 Message-ID: <11c201c75be8$d2121850$1206e29f@cnnicyao> From: "YAO Jiankang" To: , "Frank Ellermann" References: <371858821.09217@cnnic.cn> Subject: Re: [EAI] Re: I-D ACTION:draft-ietf-eai-smtpext-03.txt Date: Thu, 1 Mar 2007 18:03:11 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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="===============1643831780==" Errors-To: ima-bounces@ietf.org --===============1643831780== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 VGhhbmtzIGEgbG90IGZvciB5b3VyIGdvb2QgY29tbWVudHMuDQpJIGp1c3QgcmV0dXJuIGZyb20g b3VyIGJpZyBDaGluZXMgbmV3IHllYXIgaG9saWRheS4NCnNvbWUgY29tbWVudHMgYmVsb3cuDQoN CllBTyBKaWFua2FuZw0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJGcmFu ayBFbGxlcm1hbm4iIDxub2JvZHlAeHl6enkuY2xhcmFuZXQuZGU+DQpUbzogPGltYUBpZXRmLm9y Zz4NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTksIDIwMDcgMTI6MTMgUE0NClN1YmplY3Q6IFtF QUldIFJlOiBJLUQgQUNUSU9OOmRyYWZ0LWlldGYtZWFpLXNtdHBleHQtMDMudHh0DQoNCg0KPiBJ bnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+IA0KPj4gRmlsZW5hbWUgICAgICAgIDog ZHJhZnQtaWV0Zi1lYWktc210cGV4dC0wMy50eHQNCj4gDQo+IA0KPiBTb21lIEFCTkYgbml0czoN Cj4gDQo+IDE6DQo+IFBsZWFzZSByZXBsYWNlIGFsbCA8Tm9uLUFTQ0lJPiBieSBVVEY4LTIgLyBV VEY4LTMgLyBVVEY4LTQuDQo+IDxOb24tQVNDSUk+IGlzIGFuIGFtYmlndW91cyB0ZXJtLiAgUkZD IDM5NzcgdXNlcyB0aGUgdGVybQ0KPiA8VVRGOC1ub24tYXNjaWk+IGlmIHlvdSBpbnNpc3Qgb24g c29tZSBraW5kIG9mIHNob3J0aGFuZC4NCg0Kd2lsbCB1cGRhdGUgaXQgdG8gVVRGOC1ub24tYXNj aWkNCg0KPiANCj4gMjoNCj4gLSAgOyBMZXQtZGlnIGluIHRoZSByaWdodCBvZiAnPScgaXMgZGVm aW5lZCBpbiBSRkMgMjgyMg0KPiArICA7IEF1Z21lbnQgTGV0LWRpZyBpbiBSRkMgMjgyMSwgc2Vj dGlvbiA0LjEuMw0KDQp3aWxsIHVwZGF0ZSBpdCANCg0KPiANCj4gMzoNCj4gLSAgOyBSZXBsYWNl IExkaC1zdHIgaW4gUkZDIDI4MjEsIHNlY3Rpb24gNC4xLjINCj4gKyAgOyBSZXBsYWNlIExkaC1z dHIgaW4gUkZDIDI4MjEsIHNlY3Rpb24gNC4xLjMNCj4gDQoNCndpbGwgdXBkYXRlIGl0IA0KDQo+ IERvIHdlIHJlYWxseSB3YW50IGFuIDx1QXQtZG9tYWluPiBmb3IgVVRGOFNNVFAgc291cmNlIHJv dXRpbmcgPw0KPiBJTU8gcmVsYXlzIHNob3VsZCBzaW1wbHkgdXNlIHRoZSBBU0NJSSB2ZXJzaW9u IG9mIGRvbWFpbiBuYW1lcw0KPiBpbiByZXZlcnNlIG9yIGZvcndhcmQgcGF0aHMuICBJdCdzIGFu eXdheSBkZXByZWNhdGVkLiAgV2l0aG91dA0KPiA8dUF0LWRvbWFpbj4gdGhlcmUncyBvZiBjb3Vy c2UgYWxzbyBubyA8dUEtZC1sPi4NCg0KaGVyZSwgd2UgZGVmaW5lIHVBdC1kb21haW4gZm9yIA0K DQoiTUFJTCBGUk9NOiIgU1AgPHVSZXZlcnNlLXBhdGg+IFsgU1AgPG1haWwtcGFyYW1ldGVycz4g XTxDUkxGPg0KICAgICAgICAgICAgICAgICAgICAgIHVSZXZlcnNlLXBhdGggPSB1UGF0aA0KICAg ICAgICAgICAgICAgICAgICAgIHVQYXRoID0gIjwiIFsgdUEtZC1sICI6IiBdIHVNYWlsYm94ICI+ Ig0KICAgICAgICAgICAgICAgICAgICAgIHVBLWQtbCA9IHVBdC1kb21haW4gKiggIiwiIHVBLWQt bCApDQpoZXJlIHVSZXZlcnNlLXBhdGggc2hvdWxkIGhhdmUgVVRGOCBhZGRyZXNzLg0KDQoNCg0K DQo+IA0KPiAtICBzZW5kZXIsIHRoZSBlbWFpbCBtdXN0IGJlIGJvdW5jZWQgdG8gdGhlIG9yaWdp bmFsIHNlbmRlci4gIElmIHRoZQ0KPiAtICBlbWFpbCBpcyBib3VuY2VkIGR1ZSB0byB0aGUgaW5j YXBhYmlsaXR5IG9mIHN1cHBvcnRpbmcgVVRGOFNNVFAsIHRoZQ0KPiArICBzZW5kZXIsIHRoZSBl bWFpbCBtdXN0IGJlIHJlamVjdGVkLiAgSWYgdGhlIGVtYWlsIGlzIHJlamVjdGVkIGR1ZQ0KPiAr ICB0byB0aGUgaW5jYXBhYmlsaXR5IG9mIHN1cHBvcnRpbmcgVVRGOFNNVFAsIHRoZQ0KDQoNCndp bGwgdXBkYXRlIGl0IHRvIHJlamVjdC4NCg0KPiANCj4gQmV0dGVyIGRvbid0IHRhbGsgYWJvdXQg ImJvdW5jZXMgdG8gdGhlIG9yaWdpbmFsIHNlbmRlciIsIHRoYXQncyBhDQo+IHdpbGQgYW5kIGRh bmdlcm91cyBiYXR0bGVmaWVsZCByZXNlcnZlZCBmb3IgMjgyMWJpcy4NCj4gDQo+IFRoZSBzdGFy dCBvZiBzZWN0aW9uIDIuNSBpcyByYXRoZXIgb2JzY3VyZToNCj4gDQo+ICAgVGhlICJBTFQtQURE UkVTUyIgcmVxdWlyZXMgYW4gYWxsLUFTQ0lJIGFkZHJlc3MuICBUaGVyZSBhcmUgdHdvDQo+ICAg YWx0ZXJuYXRpdmUgd2F5cyB0byBzZXQgQUxULUFERFJFU1MgdmFsdWU6IG9uZSBpcyBzZXQgYnkg dGhlIHNlbmRlcg0KPiAgIHVzaW5nIHRoZSBhbGwtQVNDSUkgYWRkcmVzcywgdGhlIG90aGVyIGlz IHNldCB1c2luZyB0aGUgdHJhbnNmb3JtZWQNCj4gICBlbWFpbCBhZGRyZXNzLg0KPiANCj4gSU1P IHRoZSBvdGhlciB3YXkgaXMgdGhhdCB0aGUgTVNBIChrbm93aW5nIHRoZSBzZW5kZXIpIGNvdWxk IHN1cHBseSBhbg0KPiBBTFQtQURSRVNTUyBmb3IgdGhlIE1BSUwgRlJPTS4gIElmIHRoYXQncyBp biBzb21lIHdheSAidHJhbnNmb3JtZWQiIG9yDQo+IG5vdCBpcyB0aGUgbG9jYWwgYnVzaW5lc3Mg b2YgdGhlIE1TQS4NCg0KSU1PLCAidHJhbnNmb3JtZWQiIGFkZHJlc3Mgc2hvdWxkIG5vdCBiZSBw cm9kdWNlZCBieSBNU0Egb3IgTVRBLiBUaGUgc2VuZGVyIHNob3VsZCBoYXZlIHNvbWUgb3RoZXIg bWV0aG9kIHRvIHByb2R1Y2UgInRyYW5zZm9ybWVkIiBhZGRyZXNzIGFzICB0aGUgDQphbHRlcm5h dGUgYWRkcmVzcy4NCg0KPiANCj4gVGhlIGZvbGxvd2luZyBkaXNjdXNzaW9uIGFib3V0ICJ0cmFu c2Zvcm1hdGlvbnMiIGNvdWxkIGJlIGRlbGV0ZWQsIHdlDQo+IGRpZG4ndCBwaWNrIHRoYXQgb3B0 aW9uLiAgSXQncyBhbHNvIHVuY2xlYXIgd2hhdCAidGhlIHByZWRlZmluZWQgd2F5Ig0KPiBpcywg KHF1b3RlKSB0aGUgc2VuZGVyIGNhbiBzcGVjaWZ5IHRoYXQgdGhlc2UgYWRkcmVzc2VzIGFyZSBz YWZlIHRvIGJlDQo+IGNvbnZlcnRlZCBpbiB0aGUgcHJlZGVmaW5lZCB3YXkgKHVucXVvdGUpLiAg Rm9yIHRoZSBSSFMgdGhlcmUgaXMgYQ0KPiBjbGVhciBwcmVkZWZpbmVkIHdheSwgYnV0IG5vdCBm b3IgdGhlIExIUy4NCg0KDQp0aGlzIGRpc2N1c3Npb24gZXhpc3RzIGJlY2F1c2Ugc29tZSBtZW1i ZXIgaXMgbm90IGNsZWFyIGFib3V0IHdoeSB3ZSBkaWQgbm90IHByZWZlciAidHJhbnNmb3JtZWQi IGFkZHJlc3MuDQoNCg0KPiANCj4gICBBc3N1bWluZyB0aGF0IHRoZSBzZXJ2ZXIgYWR2ZXJ0aXNl cyBVVEY4U01UUCBhbmQgOEJJVE1JTUUsIGFuZCBhdA0KPiBldGMuDQo+IA0KPiBJTU8gdGhhdCBw YXJhZ3JhcGggc2hvdWxkIGJlIGRlbGV0ZWQsIGl0J3Mgb2JzY3VyZSBhbmQgdW5uZWNlc3Nhcnku DQo+IE9mIGNvdXJzZSBCT0RZPThCSVRNSU1FIGFuZCBCT0RZPUJJTkFSWSBtZWFuIHdoYXQgdGhl eSBhbHdheXMgbWVhbiwNCj4gdGhhdCBkb2Vzbid0IGRlcGVuZCBvbiBVVEY4U01UUCwgYXMgZXhw bGFpbmVkIGluIHRoZSBmaXJzdCBwYXJhZ3JhcGgNCj4gaW4gMi42Lg0KDQpXZSAgaGFzIGFscmVh ZHkgZGlzY3Vzc2VkIHRoaXMgaXNzdWUgaW4gdGhlIGltYUBpZXRmLm9yZy4ga2VlcCB0aGlzIHBh cmFncmFwaCBtYXkgYmUgbW9yZSBjbGVhciBmb3IgcmVhZGVycy4NCg0KDQo+IA0KPiBJdCdzIElN TyBtaXNsZWFkaW5nIHRvIGFzc3VtZSB0aGF0IHRoZSBwcmVzZW5jZSBvZiBub24tQVNDSUkgYWRk cmVzc2VzDQo+IGluIHRoZSBlbnZlbG9wZSBfYWx3YXlzXyBhbm5vdW5jZXMgYSBtZXNzYWdlL3V0 Zi04LiAgRm9yIGEgUkNQVCBUTyBpdA0KPiBjb3VsZCBiZSBzdGlsbCBhIG1lc3NhZ2UvcmZjODIy IChkZXBlbmRpbmcgb24gdGhlIGdlbmVyYXRlZCB0aW1lc3RhbXANCj4gbGluZXMpLiAgVGhlIG9w cHBvc2l0ZSBhbHNvIGlzbid0IG5lY2Vzc2FyaWx5IHRydWUsIHRoZSBlbnZlbG9wZSBjb3VsZA0K PiBiZSBBU0NJSSwgYnV0IHRoZSBtZXNzYWdlIGhlYWRlciBjYW4gY29udGFpbiBVVEYtOC4NCj4g DQo+ICAgVGhpcyBhbHRlcm5hdGUtTVgtb3ItcmV0cnktbGF0ZXIgdGVjaG5pcXVlIFNIT1VMRCBO T1QgYmUgdXNlZCB3aGVuDQo+IA0KPiBJdCBTSE9VTEQgTk9UIGJlIGRpc2N1c3NlZCBhdCBhbGws IGl0J3MgcmVhbGx5IG9kZC4gIEVzcGVjaWFsbHkgInJldHJ5DQo+IGxhdGVyIiwgd2hhdCdzIHRo ZSBpZGVhLCB0aGUgcmVjZWl2ZXIganVzdCBoYXBwZW5zIHRvIHVwZ3JhZGUgdGhlaXIgTVgNCj4g dG9kYXkgPw0KDQogZG9uJ3QgbmVlZCB1cGdyYWRlIHRoZWlyIE1YLi4gIGJlY2F1c2Ugc29tZSBm YWlsdXJlIGlzIHRlbXAgZmFpbHVyZSwgd2UgbWF5IHRyeSBhbm9oZXIgIGhvc3QgYmFzZWQgb24g TVggcmVjb3JkLg0KDQpHZWxsZW5zIGhhcyBzb21lIGRpc3VjY3N1aW9uIGluIHRoaXMgaXNzdWUg aW4gIHRoZSBpbWEgbWFpbGluZyBsaXN0Lg0KDQo+IA0KPiAtICAgdUZvciA9ICJGT1IiIEZXUyAx KiggUGF0aCAvIHVNYWlsYm94ICkgQ0ZXUw0KPiArICAgdUZvciA9ICJGT1IiIEZXUyAxKiggdVBh dGggLyB1TWFpbGJveCApIENGV1MNCj4gDQo+IA0KDQp3aWxsIHVwZGF0ZSBpdCBhY2NvcmRpbmcg dG8geW91ciBzdWdnZXN0aW9ucy4NCg0KDQo+IDIuNy41OiAgUGxlYXNlIGRlbGV0ZSB0aGUgY29t cGxldGUgc2VjdGlvbiwgdGhlcmUncyBubyAiSGVhZGVyLVR5cGUiDQo+IGFueW1vcmUuDQoNCndp bGwgZGVsdGUgaXQuDQoNCj4gIDIuNy42IGNvdWxkIGJlIGFsc28gZGVsZXRlZCwgUE9QMyBhbmQg SU1BUCBhcmUgaW50cm9kdWNlZA0KPiBpbiB0aGUgZnJhbWV3b3JrIFJGQywgdGhleSB3aWxsIGdl dCB0aGVpciBvd24gUkZDcy4gIE5vIFNNVFAgYnVzaW5lc3MsDQo+IG5vIGNhc2UgZm9yIGEgIlNI T1VMRCIuICBPciBpcyB0aGF0IGFib3V0IHRoZSBqb2Igb2YgTURBcyA/ICBUaGVuIGl0DQo+IGRv ZXNuJ3Qgc2F5IHdoYXQgc3BlY2lhbCBhY3Rpb25zIGFuIE1EQSBpcyBleHBlY3RlZCB0byBwZXJm b3JtIChhZnRlcg0KPiBpdCBnb3QgdGhlIHVSZXR1cm4tcGF0aC1saW5lIHJpZ2h0IGFzIHNwZWNp ZmllZCBpbiAyLjcuMykuDQoNCklNTywgdGhpcyBzZWN0aW9uIGlzIGtlcHQgZm9yIGluZm9ybWF0 aW9uLiBvdGhlcnMnIHZpZXc/DQoNCg0KPiANCj4gMy4xOiAgUGxlYXNlIGRlbGV0ZSB0aGlzIHNl Y3Rpb24sIG1haWx0byBVUklzIGFyZSBubyBTTVRQIGJ1c2luZXNzLg0KDQp3aWxsIGRlbGV0ZSBp dC4NCg0KDQo+IDMuMjogIHMvMjQ3Ni80NDA5LyBldmVyeXdoZXJlLCANCg0Kd2lsbCB1c2UgNDQw OQ0KDQo+YW5kIHMvRUFJIHByb3RvY29sL1VURjhTTVRQLyAoPykNCg0KSSBzdGlsbCBwcmVmZXIg RUFJIHByb3RvY29sLiBFQUkgcHJvdG9jb2wgaW5jbHVkZXMgbWFueSByZmMuICBVVEY4U01UUCBp cyBqdXN0IG9uZSBvZiB0aGVtLg0KDQogDQo+IFRoZSBjb21wbGV0ZSBjaGFwdGVyIDMgc2hvdWxk IGdvLiAgQ2hhcHRlciA0IGlzIGFsc28gdW5uZWNlc3NhcnkuDQoNCkkgc3RpbGwgcHJlZmVyIGtl ZXBzIHNvbWUgb2YgdGhlbS4NCg0KPiBIb3cgYWJvdXQgc29tZSBuaWNlIGV4YW1wbGUgc2Vzc2lv bnMgPw0KPiANCg0KYSBnb29kIHN1Z2dlc3Rpb24uICAgIHdpbGwgY29uc2lkZXIgdG8gaGF2ZSBl eGFtcGxlIHNlc3Npb25zLg0KDQoNCg0KDQoNCj4gQW5vdGhlciBuaXQgaW4gMi4yOg0KPiANCj4g LSAgdHJhbnNtaXQgYSBtYWlsIGJvZHkgd2hpY2ggY29udGFpbnMgaW50ZXJuYXRpb25hbGl6ZWQg bWFpbCBoZWFkZXJzDQo+ICsgIHRyYW5zbWl0IGEgbWVzc2FnZSB3aGljaCBjb250YWlucyBpbnRl cm5hdGlvbmFsaXplZCBtYWlsIGhlYWRlcnMNCj4gDQo+IE1heWJlICdtYWlsIGRhdGEnLCBTTVRQ IHRyYW5zcG9ydHMgY29tcGxldGUgbWVzc2FnZXMsIGhlYWRlciArIGJvZHkuDQoNCnVwZGF0ZSBp dCB0byAibWVzc2FnZSINCg0KPiANCj4gRnJhbmsNCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0K PiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v aW1h --===============1643831780== 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 --===============1643831780==-- From ima-bounces@ietf.org Thu Mar 01 15:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsGK-0003kU-RE; Thu, 01 Mar 2007 15:52:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMsES-0000z7-Qf; Thu, 01 Mar 2007 15:50:32 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMsES-0002cd-Em; Thu, 01 Mar 2007 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 5F06E1764A; Thu, 1 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HMsDy-0002br-3R; Thu, 01 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Internationalized Email Headers Author(s) : J. Yeh Filename : draft-ietf-eai-utf8headers-03.txt Pages : 14 Date : 2007-3-1 Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-utf8headers-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-utf8headers-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-1101043.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-utf8headers-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-utf8headers-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-1101043.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 Sun Mar 04 13:28:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNvQs-0001nK-Rg; Sun, 04 Mar 2007 13:27:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNvQr-0001mq-Ts for ima@ietf.org; Sun, 04 Mar 2007 13:27:41 -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 1HNvQo-00053R-UA for ima@ietf.org; Sun, 04 Mar 2007 13:27:40 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HNvQe-00035s-0g for ima@ietf.org; Sun, 04 Mar 2007 19:27:28 +0100 Received: from du-001-055.access.de.clara.net ([212.82.227.55]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Mar 2007 19:27:28 +0100 Received: from nobody by du-001-055.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 04 Mar 2007 19:27:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sun, 04 Mar 2007 19:24:13 +0100 Organization: Lines: 127 Message-ID: <45EB0ECD.26F6@xyzzy.claranet.de> References: <371858821.09217@cnnic.cn> <372743391.13410@cnnic.cn> 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-055.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Subject: [EAI] Re: I-D ACTION:draft-ietf-eai-smtpext-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org YAO Jiankang wrote: Hi, jumping to something where we apparently don't agree yet: >> Do we really want an for UTF8SMTP source routing ? >> IMO relays should simply use the ASCII version of domain names >> in reverse or forward paths. It's anyway deprecated. Without >> there's of course also no . > here, we define uAt-domain for > "MAIL FROM:" SP [ SP ] > uReverse-path = uPath > uPath = "<" [ uA-d-l ":" ] uMailbox ">" > uA-d-l = uAt-domain *( "," uA-d-l ) > here uReverse-path should have UTF8 address. Yes, but IMO you can keep as is, without introducing an I18N format for the obsolete source routing. RFC 1123 5.2.6 + 5.2.19 and RFC 2821 appendix F.2 explain that and why that's obsolete. You also don't need an I18N then. , , and are of course needed, we want the new for UTF8SMTP. ---------------------------------------------------------------- >> The start of section 2.5 is rather obscure: >> The "ALT-ADDRESS" requires an all-ASCII address. There are two >> alternative ways to set ALT-ADDRESS value: one is set by the >> sender using the all-ASCII address, the other is set using the >> transformed email address. >> IMO the other way is that the MSA (knowing the sender) could supply >> an ALT-ADRESSS for the MAIL FROM. If that's in some way "transformed" >> or not is the local business of the MSA. > IMO, "transformed" address should not be produced by MSA or MTA. > The sender should have some other method to produce "transformed" > address as the alternate address. Then I miss a clue what "the other is set using the transformed email address" or "some other method to produce 'transformed' address" is. IIRC we discussed "standard transformations", and then decided that it's a bad idea. But there can be still "local conventions" at the "mail originating network" (Keith's MON) to derive a working local all-ASCII address for a given local UTF8SMTP address. That local convention can be known by the MSA, or for what's it worth by the MUA, and then MSA or MUA could automatically transform the local _sender_ address into an all-ASCII ALTADDRESS using this local convention. But the sender (MUA or MSA) can't do anything about the address of the receiver, the receiver has his own local convention (if any). >> The following discussion about "transformations" could be deleted, >> we didn't pick that option. It's also unclear what "the predefined >> way" is, (quote) the sender can specify that these addresses are >> safe to be converted in the predefined way (unquote). For the RHS >> there is a clear predefined way, but not for the LHS. > this discussion exists because some member is not clear about why > we did not prefer "transformed" address. Replacing "predefined way" by "local convention" I still don't see what this paragraph is about. ------------------------------------------------------------------ >> Of course BODY=8BITMIME and BODY=BINARY mean what they always >> mean, that doesn't depend on UTF8SMTP, as explained in the first >> paragraph in 2.6. > We has already discussed this issue in the ima@ietf.org. keep this > paragraph may be more clear for readers. Didn't work for me. ------------------------------------------------------------------- >> This alternate-MX-or-retry-later technique SHOULD NOT be used when >> It SHOULD NOT be discussed at all, it's really odd. Especially >> "retry later", what's the idea, the receiver just happens to upgrade >> their MX today ? > don't need upgrade their MX.. because some failure is temp failure, > we may try anoher host based on MX record. > Gellens has some disuccsuion in this issue in the ima mailing list. Yes, I've still flagged that article: "Try another MX" could make sense, but I don't get "try later", is it at the same MX ?!? [POP3 and IMAP] > IMO, this section is kept for information. others' view? IMO not relevant for the SMTP draft. Merging your draft with the DSN draft might be an idea. For POP3 and IMAP let the framework RFC (if it's finally approved) offer the links, or maybe reduce your text to references. >> s/EAI protocol/UTF8SMTP/ (?) > I still prefer EAI protocol. EAI protocol includes many rfc. > UTF8SMTP is just one of them. IIRC we don't use or explain the acronym EAI anywhere, minus the WG name and draft names of course... ;-) You'd have to expand the EAI acronym on first usage. The framework RFC says in its chapter 1.3 (terminology): | The umbrella term to describe the email address | internationalization specified by this document and its companion | documents is "UTF8SMTP". For example, an address permitted by | this specification is referred to as a "UTF8SMTP (compliant) | address". Oops, the A in EAI is an "address", for some minutes I thought that it's "architecture". Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Mar 04 21:31:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO2zH-0001PZ-QE; Sun, 04 Mar 2007 21:31:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO2zH-0001PU-D5 for ima@ietf.org; Sun, 04 Mar 2007 21:31:43 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO2zB-0008VV-LL for ima@ietf.org; Sun, 04 Mar 2007 21:31:43 -0500 Received: (snipe 15314 invoked by uid 0); 5 Mar 2007 11:31:38 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.713580 secs); Received: from unknown (HELO ?210.107.139.110?) (Z???own@210.107.139.110) by unknown with SMTP; 5 Mar 2007 11:31:37 +0900 X-SNIPER-SENDERIP: 210.107.139.110 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: nobody@xyzzy.claranet.de, ima@ietf.org, yangwooko@gmail.com Message-ID: <45EB80FD.6030704@icu.ac.kr> Date: Mon, 05 Mar 2007 11:31:25 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] Re: I-D ACTION:draft-ietf-eai-smtpext-03.txt References: <371858821.09217@cnnic.cn> <372743391.13410@cnnic.cn> <45EB0ECD.26F6@xyzzy.claranet.de> In-Reply-To: <45EB0ECD.26F6@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: 244a2fd369eaf00ce6820a760a3de2e8 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: > YAO Jiankang wrote: > ---------------------------------------------------------------- > >>> The start of section 2.5 is rather obscure: > >>> The "ALT-ADDRESS" requires an all-ASCII address. There are two >>> alternative ways to set ALT-ADDRESS value: one is set by the >>> sender using the all-ASCII address, the other is set using the >>> transformed email address. > >>> IMO the other way is that the MSA (knowing the sender) could supply >>> an ALT-ADRESSS for the MAIL FROM. If that's in some way "transformed" >>> or not is the local business of the MSA. > >> IMO, "transformed" address should not be produced by MSA or MTA. >> The sender should have some other method to produce "transformed" >> address as the alternate address. > > Then I miss a clue what "the other is set using the transformed email > address" or "some other method to produce 'transformed' address" is. > > IIRC we discussed "standard transformations", and then decided that > it's a bad idea. But there can be still "local conventions" at the > "mail originating network" (Keith's MON) to derive a working local > all-ASCII address for a given local UTF8SMTP address. > > That local convention can be known by the MSA, or for what's it > worth by the MUA, and then MSA or MUA could automatically transform > the local _sender_ address into an all-ASCII ALTADDRESS using this > local convention. > > But the sender (MUA or MSA) can't do anything about the address of > the receiver, the receiver has his own local convention (if any). > >>> The following discussion about "transformations" could be deleted, >>> we didn't pick that option. It's also unclear what "the predefined >>> way" is, (quote) the sender can specify that these addresses are >>> safe to be converted in the predefined way (unquote). For the RHS >>> there is a clear predefined way, but not for the LHS. > >> this discussion exists because some member is not clear about why >> we did not prefer "transformed" address. > > Replacing "predefined way" by "local convention" I still don't see > what this paragraph is about. > ------------------------------------------------------------------ The purpose of section 2.5 is very unclear to me. We accepted neither ACE-like "always working" transformation nor flags for "working for this case". This section can serve, with some modifications, as a short explanation behind this decision. Or, Still there surely will be cases where automatic conversions are useful. This section, with some modifications again, can explain what considerations are needed for those cases. I prefer the former one. Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Mar 05 03:42:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO8m6-0001Y4-TZ; Mon, 05 Mar 2007 03:42:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO8m5-0001Xy-JT for ima@ietf.org; Mon, 05 Mar 2007 03:42:29 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HO8m2-0005H8-W4 for ima@ietf.org; Mon, 05 Mar 2007 03:42:29 -0500 Received: (eyou send program); Mon, 05 Mar 2007 16:42:11 +0800 Message-ID: <373084131.27366@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, 05 Mar 2007 16:42:11 +0800 Message-ID: <002201c75f02$29fc91a0$1206e29f@cnnicyao> From: "YAO Jiankang" To: , "Frank Ellermann" References: <371858821.09217@cnnic.cn> <372743391.13410@cnnic.cn> <373033008.18419@cnnic.cn> Subject: Re: [EAI] Re: I-D ACTION:draft-ietf-eai-smtpext-03.txt Date: Mon, 5 Mar 2007 16:42:09 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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="===============0305430275==" Errors-To: ima-bounces@ietf.org --===============0305430275== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 VGhhbmtzIGEgbG90Lg0KY29tbWVudHMgYmVsb3cuDQoNCllBTyBKaWFua2FuZw0KQ05OSUMNCi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiRnJhbmsgRWxsZXJtYW5uIiA8bm9i b2R5QHh5enp5LmNsYXJhbmV0LmRlPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXks IE1hcmNoIDA1LCAyMDA3IDI6MjQgQU0NClN1YmplY3Q6IFtFQUldIFJlOiBJLUQgQUNUSU9OOmRy YWZ0LWlldGYtZWFpLXNtdHBleHQtMDMudHh0DQoNCg0KPiBZQU8gSmlhbmthbmcgd3JvdGU6DQo+ IA0KPiBIaSwganVtcGluZyB0byBzb21ldGhpbmcgd2hlcmUgd2UgYXBwYXJlbnRseSBkb24ndCBh Z3JlZSB5ZXQ6DQo+IA0KPj4+IERvIHdlIHJlYWxseSB3YW50IGFuIDx1QXQtZG9tYWluPiBmb3Ig VVRGOFNNVFAgc291cmNlIHJvdXRpbmcgPw0KPj4+IElNTyByZWxheXMgc2hvdWxkIHNpbXBseSB1 c2UgdGhlIEFTQ0lJIHZlcnNpb24gb2YgZG9tYWluIG5hbWVzDQo+Pj4gaW4gcmV2ZXJzZSBvciBm b3J3YXJkIHBhdGhzLiAgSXQncyBhbnl3YXkgZGVwcmVjYXRlZC4gIFdpdGhvdXQNCj4+PiA8dUF0 LWRvbWFpbj4gdGhlcmUncyBvZiBjb3Vyc2UgYWxzbyBubyA8dUEtZC1sPi4NCj4gDQo+PiBoZXJl LCB3ZSBkZWZpbmUgdUF0LWRvbWFpbiBmb3INCj4gDQo+PiAiTUFJTCBGUk9NOiIgU1AgPHVSZXZl cnNlLXBhdGg+IFsgU1AgPG1haWwtcGFyYW1ldGVycz4gXTxDUkxGPg0KPj4gICAgICAgICAgICAg ICAgICAgICAgIHVSZXZlcnNlLXBhdGggPSB1UGF0aA0KPj4gICAgICAgICAgICAgICAgICAgICAg IHVQYXRoID0gIjwiIFsgdUEtZC1sICI6IiBdIHVNYWlsYm94ICI+Ig0KPj4gICAgICAgICAgICAg ICAgICAgICAgIHVBLWQtbCA9IHVBdC1kb21haW4gKiggIiwiIHVBLWQtbCApDQo+PiBoZXJlIHVS ZXZlcnNlLXBhdGggc2hvdWxkIGhhdmUgVVRGOCBhZGRyZXNzLg0KPiANCj4gWWVzLCBidXQgSU1P IHlvdSBjYW4ga2VlcCA8QS1kLWw+IGFzIGlzLCB3aXRob3V0IGludHJvZHVjaW5nIGFuDQo+IEkx OE4gZm9ybWF0IDx1QS1kLWw+IGZvciB0aGUgb2Jzb2xldGUgc291cmNlIHJvdXRpbmcuICBSRkMg MTEyMw0KPiA1LjIuNiArIDUuMi4xOSBhbmQgUkZDIDI4MjEgYXBwZW5kaXggRi4yIGV4cGxhaW4g dGhhdCBhbmQgd2h5DQo+IHRoYXQncyBvYnNvbGV0ZS4gIFlvdSBhbHNvIGRvbid0IG5lZWQgYW4g STE4TiA8dUF0LWRvbWFpbj4gdGhlbi4NCj4gDQo+IDx1UGF0aD4sIDx1TWFpbGJveD4sIGFuZCA8 dVJldmVyc2UtcGF0aD4gYXJlIG9mIGNvdXJzZSBuZWVkZWQsDQo+IHdlIHdhbnQgdGhlIG5ldyA8 dU1haWxib3g+IGZvciBVVEY4U01UUC4NCg0Kb24gYW5vdGhlciB0aG91Z2h0LCB5ZXMsIHlvdSBh cmUgcmlnaHQuDQogSSBwcm9wb3NlIHRvIGNoYW5nZSAidVBhdGggPSAiPCIgWyB1QS1kLWwgIjoi IF0gdU1haWxib3ggIj4iDQoiICB0byB1UGF0aCA9ICI8IiBbIEEtZC1sICI6IiBdIHVNYWlsYm94 ICI+Ig0Kd2hlcmUgdU1haWxib3ggaXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LCBhbmQgQS1k LWwgaXMgZGVmaW5lZCBpbiBSRkMyODIxLg0KDQppcyBpdCBvaz8gb3IgYW55IG90aGVyIGdvb2Qg c3VnZ2VzdGlvbnM/DQoNCg0KDQoNCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPj4+IFRoZSBzdGFydCBvZiBz ZWN0aW9uIDIuNSBpcyByYXRoZXIgb2JzY3VyZToNCj4gDQo+Pj4gICBUaGUgIkFMVC1BRERSRVNT IiByZXF1aXJlcyBhbiBhbGwtQVNDSUkgYWRkcmVzcy4gIFRoZXJlIGFyZSB0d28NCj4+PiAgIGFs dGVybmF0aXZlIHdheXMgdG8gc2V0IEFMVC1BRERSRVNTIHZhbHVlOiBvbmUgaXMgc2V0IGJ5IHRo ZQ0KPj4+ICAgc2VuZGVyIHVzaW5nIHRoZSBhbGwtQVNDSUkgYWRkcmVzcywgdGhlIG90aGVyIGlz IHNldCB1c2luZyB0aGUNCj4+PiAgIHRyYW5zZm9ybWVkIGVtYWlsIGFkZHJlc3MuDQo+IA0KPj4+ IElNTyB0aGUgb3RoZXIgd2F5IGlzIHRoYXQgdGhlIE1TQSAoa25vd2luZyB0aGUgc2VuZGVyKSBj b3VsZCBzdXBwbHkNCj4+PiBhbiBBTFQtQURSRVNTUyBmb3IgdGhlIE1BSUwgRlJPTS4gIElmIHRo YXQncyBpbiBzb21lIHdheSAidHJhbnNmb3JtZWQiDQo+Pj4gb3Igbm90IGlzIHRoZSBsb2NhbCBi dXNpbmVzcyBvZiB0aGUgTVNBLg0KPiANCj4+IElNTywgInRyYW5zZm9ybWVkIiBhZGRyZXNzIHNo b3VsZCBub3QgYmUgcHJvZHVjZWQgYnkgTVNBIG9yIE1UQS4NCj4+IFRoZSBzZW5kZXIgc2hvdWxk IGhhdmUgc29tZSBvdGhlciBtZXRob2QgdG8gcHJvZHVjZSAidHJhbnNmb3JtZWQiDQo+PiBhZGRy ZXNzIGFzIHRoZSBhbHRlcm5hdGUgYWRkcmVzcy4NCj4gDQo+IFRoZW4gSSBtaXNzIGEgY2x1ZSB3 aGF0ICJ0aGUgb3RoZXIgaXMgc2V0IHVzaW5nIHRoZSB0cmFuc2Zvcm1lZCBlbWFpbA0KPiBhZGRy ZXNzIiBvciAic29tZSBvdGhlciBtZXRob2QgdG8gcHJvZHVjZSAndHJhbnNmb3JtZWQnIGFkZHJl c3MiIGlzLg0KPiANCj4gSUlSQyB3ZSBkaXNjdXNzZWQgInN0YW5kYXJkIHRyYW5zZm9ybWF0aW9u cyIsIGFuZCB0aGVuIGRlY2lkZWQgdGhhdA0KPiBpdCdzIGEgYmFkIGlkZWEuICBCdXQgdGhlcmUg Y2FuIGJlIHN0aWxsICJsb2NhbCBjb252ZW50aW9ucyIgYXQgdGhlDQo+ICJtYWlsIG9yaWdpbmF0 aW5nIG5ldHdvcmsiIChLZWl0aCdzIE1PTikgdG8gZGVyaXZlIGEgd29ya2luZyBsb2NhbA0KPiBh bGwtQVNDSUkgYWRkcmVzcyBmb3IgYSBnaXZlbiBsb2NhbCBVVEY4U01UUCBhZGRyZXNzLg0KPiAN Cj4gVGhhdCBsb2NhbCBjb252ZW50aW9uIGNhbiBiZSBrbm93biBieSB0aGUgTVNBLCBvciBmb3Ig d2hhdCdzIGl0DQo+IHdvcnRoIGJ5IHRoZSBNVUEsIGFuZCB0aGVuIE1TQSBvciBNVUEgY291bGQg YXV0b21hdGljYWxseSB0cmFuc2Zvcm0NCj4gdGhlIGxvY2FsIF9zZW5kZXJfIGFkZHJlc3MgaW50 byBhbiBhbGwtQVNDSUkgQUxUQUREUkVTUyB1c2luZyB0aGlzDQo+IGxvY2FsIGNvbnZlbnRpb24u DQo+IA0KPiBCdXQgdGhlIHNlbmRlciAoTVVBIG9yIE1TQSkgY2FuJ3QgZG8gYW55dGhpbmcgYWJv dXQgdGhlIGFkZHJlc3Mgb2YNCj4gdGhlIHJlY2VpdmVyLCB0aGUgcmVjZWl2ZXIgaGFzIGhpcyBv d24gbG9jYWwgY29udmVudGlvbiAoaWYgYW55KS4NCg0KSU1PLCBpZiB0aGUgYWx0LWFkZHJlc3Mg aXMgc2V0IHVzaW5nIHRoZSB0cmFuc2Zvcm1lZCBhZGRyZXNzLCAgdGhlIHJlY2VpdmVyIHdpbGwg bm90IChvciBub3QgbmVlZCApIGRvIGFueXRoaW5nIHRvIHRoaXMgYWx0LWFkZHJlc3MuICANCnRo ZSBpbml0aWFsIHRleHQgbWF5IGJlIG5vdCB2ZXJ5IGNsZWFyLiBzbyBJIHByb3Bvc2UgdG8gY2hh bmdlIGl0IHRvDQoiVGhlIGFsdC1hZGRlcnNzIHZhbHVlIGlzIGRpcmVjdGx5IHNldCBieSB1c2Vy cy4gVGhlIHVzZXIgY2FuIHVzZSB0aGUgZXhpc3RpbmcgQVNDSUkgZW1haWwgYWRkcmVzcyBvciB1 c2Ugc29tZSB0cmFuc2Zvcm1lZCBlbWFpbCBhZGRyZXNzDQogd2hpY2ggaXMgZ290dGVuIGZyb20g c29tZSBtZXRob2RzLiINCg0KVGhlIG1lYW5pbmcgSSB3YW50IHRvIHByZXNlbnQgaXMgdGhhdCAN CmZvciBleGFtcGxlOg0KIFRvbSBoYXMgYSBub24tQVNDSUkgYWRkcmVzczogIG5vbi1BU0NJSUBJ RE4NCiAgICAgICAgICAgICAgIGFuIEFTQ0lJIGFkZHJlc3MgOiAgIGFiY0BleGFtcGxlLmNvbQ0K ICAgICAgICAgICAgICAgYW4gdHJhbnNmb3JtZWQgYWRkcmVzczogYnEtYWJjZGVmQHhuLWlkbiAo dHJhbnNmb3JtZWQgZnJvbSBub24tQVNDSUlASUROIG9yIHVzaW5nIHNvbWUgbWFwcGluZykNCg0K bm93LCBUb20gY2FuIHNldCBhbHQtYWRkcmVzcz1hYmNAZXhhbXBsZS5jb20gb3IgYWx0LWFkZHJl c3M9YnEtYWJjZGVmQHhuLWlkbg0KDQoNCg0KDQo+IA0KPj4+IFRoZSBmb2xsb3dpbmcgZGlzY3Vz c2lvbiBhYm91dCAidHJhbnNmb3JtYXRpb25zIiBjb3VsZCBiZSBkZWxldGVkLA0KPj4+IHdlIGRp ZG4ndCBwaWNrIHRoYXQgb3B0aW9uLiAgSXQncyBhbHNvIHVuY2xlYXIgd2hhdCAidGhlIHByZWRl ZmluZWQNCj4+PiB3YXkiIGlzLCAocXVvdGUpIHRoZSBzZW5kZXIgY2FuIHNwZWNpZnkgdGhhdCB0 aGVzZSBhZGRyZXNzZXMgYXJlDQo+Pj4gc2FmZSB0byBiZSBjb252ZXJ0ZWQgaW4gdGhlIHByZWRl ZmluZWQgd2F5ICh1bnF1b3RlKS4gIEZvciB0aGUgUkhTDQo+Pj4gdGhlcmUgaXMgYSBjbGVhciBw cmVkZWZpbmVkIHdheSwgYnV0IG5vdCBmb3IgdGhlIExIUy4NCj4gDQo+PiB0aGlzIGRpc2N1c3Np b24gZXhpc3RzIGJlY2F1c2Ugc29tZSBtZW1iZXIgaXMgbm90IGNsZWFyIGFib3V0IHdoeQ0KPj4g d2UgZGlkIG5vdCBwcmVmZXIgInRyYW5zZm9ybWVkIiBhZGRyZXNzLg0KPiANCj4gUmVwbGFjaW5n ICJwcmVkZWZpbmVkIHdheSIgYnkgImxvY2FsIGNvbnZlbnRpb24iIEkgc3RpbGwgZG9uJ3Qgc2Vl DQo+IHdoYXQgdGhpcyBwYXJhZ3JhcGggaXMgYWJvdXQuDQoNCg0KSSB3aWxsIGNvbnNpZGVyIHRv IHJlZmluZSB0aGlzIHNlY3Rpb24gdG8gbWFrZSBpdCBtb3JlIGNsZWFyLg0KDQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiANCj4+PiBPZiBjb3Vyc2UgQk9EWT04QklUTUlNRSBhbmQgQk9EWT1CSU5BUlkgbWVhbiB3 aGF0IHRoZXkgYWx3YXlzDQo+Pj4gbWVhbiwgdGhhdCBkb2Vzbid0IGRlcGVuZCBvbiBVVEY4U01U UCwgYXMgZXhwbGFpbmVkIGluIHRoZSBmaXJzdA0KPj4+IHBhcmFncmFwaCBpbiAyLjYuDQo+IA0K Pj4gV2UgIGhhcyBhbHJlYWR5IGRpc2N1c3NlZCB0aGlzIGlzc3VlIGluIHRoZSBpbWFAaWV0Zi5v cmcuIGtlZXAgdGhpcw0KPj4gcGFyYWdyYXBoIG1heSBiZSBtb3JlIGNsZWFyIGZvciByZWFkZXJz Lg0KPiANCj4gRGlkbid0IHdvcmsgZm9yIG1lLg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4+PiAg IFRoaXMgYWx0ZXJuYXRlLU1YLW9yLXJldHJ5LWxhdGVyIHRlY2huaXF1ZSBTSE9VTEQgTk9UIGJl IHVzZWQgd2hlbg0KPiANCj4+PiBJdCBTSE9VTEQgTk9UIGJlIGRpc2N1c3NlZCBhdCBhbGwsIGl0 J3MgcmVhbGx5IG9kZC4gIEVzcGVjaWFsbHkNCj4+PiAicmV0cnkgbGF0ZXIiLCB3aGF0J3MgdGhl IGlkZWEsIHRoZSByZWNlaXZlciBqdXN0IGhhcHBlbnMgdG8gdXBncmFkZQ0KPj4+IHRoZWlyIE1Y IHRvZGF5ID8NCj4gDQo+PiBkb24ndCBuZWVkIHVwZ3JhZGUgdGhlaXIgTVguLiAgYmVjYXVzZSBz b21lIGZhaWx1cmUgaXMgdGVtcCBmYWlsdXJlLA0KPj4gd2UgbWF5IHRyeSBhbm9oZXIgaG9zdCBi YXNlZCBvbiBNWCByZWNvcmQuDQo+IA0KPj4gR2VsbGVucyBoYXMgc29tZSBkaXN1Y2NzdWlvbiBp biB0aGlzIGlzc3VlIGluICB0aGUgaW1hIG1haWxpbmcgbGlzdC4NCj4gDQo+IFllcywgSSd2ZSBz dGlsbCBmbGFnZ2VkIHRoYXQgYXJ0aWNsZToNCj4gPGh0dHA6Ly9wZXJtYWxpbmsuZ21hbmUub3Jn L2dtYW5lLmlldGYuaW1hLzExMTI+DQo+IA0KPiAiVHJ5IGFub3RoZXIgTVgiIGNvdWxkIG1ha2Ug c2Vuc2UsIGJ1dCBJIGRvbid0IGdldCAidHJ5IGxhdGVyIiwgaXMgaXQNCj4gYXQgdGhlIHNhbWUg TVggPyE/DQoNCg0KYmFzZWQgb24gdGhpcyBwcmVzdW1wdGlvbjogYXQgbGVhc3Qgd2hlbiB0aGUN CiAgIHJlY2lwaWVudCBhZGRyZXNzIGlzIG5vbi1BU0NJSSwgdGhhdCB0aGUgZGVsaXZlcnkgcGF0 aCBzZXJ2ZXJzDQogICBub3JtYWxseSBzdXBwb3J0IFVURjhTTVRQIChpZiB0aGUgc2VuZGVyJ3Mg Y2xpZW50IG9yIE1TQSBkaWRuJ3QNCiAgIHN1cHBvcnQgVVRGOFNNVFAsIHRoZSBtZXNzYWdlIHdv dWxkIG5vdCBoYXZlIGJlZW4gYWNjZXB0ZWQgZm9yDQogICBkZWxpdmVyeSBpbiB0aGUgZmlyc3Qg cGxhY2UpLiAgVGh1cywgYSBsYWNrIG9mIFVURjhTTVRQIHN1cHBvcnQgaXMNCiAgIGxpa2VseSB0 byBiZSBhIHRlbXBvcmFyeSBzaXR1YXRpb24sIHN1Y2ggYXMgYSBub3JtYWwgaW5ib3VuZCBzZXJ2 ZXINCiAgIGJlaW5nIGRvd24gYW5kIGEgY29vcGVyYXRpbmcgc2l0ZSBhY3RpbmcgYXMgYSBiYWNr dXAgTVguDQoNCmZyb20gdGhpcyBhc3N1bXB0aW9uOg0KICBpZiB0aGUgZG9tYWluIHBhcnQgaGFz IHR3byBNWCByZWNvcmRzLCBvbmUgaG9zdCBvZiBvbmUgTVggcmVjb3JkIG1heSBub3Qgc3VwcG9y dCBVVEY4U01UUCB3aGlsZSB0aGUgb3RoZXIgaG9zdCBvZiB0aGUgb3RoZXIgTVggcmVjb3JkIG1h eSBzdXBwb3J0IFVURjhTTVRQLiAgZm9yIHRoaXMgY2FzZSwgdHJ5IGFub3RoZXIgTVggYW5kIG1h eSBoYXZlIHNvbWUgaGVscC4NCg0KaWYgIHRoZSBkb21haW4gcGFydCBoYXMgb25seSBvbmUgTVgg cmVjb3JkLCB0aGUgc2VydmVyIG1heSB0ZW1wb3JhcnkgZG93biBvciBpbiBvdGhlciB0ZW1wb3Jh cnkgYmFkIHNpdHVhdGlvbi4gIGZvciB0aGlzIGNhc2UsIHRyeSBpdCBhZ2FpbiBhZnRlciBhIGZl dyBtaW51dGVzIGFuZCBtYXkgaGF2ZSBzb21lIGhlbHAuDQoNCg0KDQoNCj4gDQo+IFtQT1AzIGFu ZCBJTUFQXSANCj4+IElNTywgdGhpcyBzZWN0aW9uIGlzIGtlcHQgZm9yIGluZm9ybWF0aW9uLiBv dGhlcnMnIHZpZXc/DQo+IA0KPiBJTU8gbm90IHJlbGV2YW50IGZvciB0aGUgU01UUCBkcmFmdC4g IE1lcmdpbmcgeW91ciBkcmFmdCB3aXRoIHRoZSBEU04NCj4gZHJhZnQgbWlnaHQgYmUgYW4gaWRl YS4gIEZvciBQT1AzIGFuZCBJTUFQIGxldCB0aGUgZnJhbWV3b3JrIFJGQyAoaWYNCj4gaXQncyBm aW5hbGx5IGFwcHJvdmVkKSBvZmZlciB0aGUgbGlua3MsIG9yIG1heWJlIHJlZHVjZSB5b3VyIHRl eHQgdG8NCj4gcmVmZXJlbmNlcy4NCg0Kd2lsbCBjb25zaWRlciB0byByZWR1Y2UgdGhlIHRleHQu DQoNCj4gDQo+Pj4gcy9FQUkgcHJvdG9jb2wvVVRGOFNNVFAvICg/KQ0KPiANCj4+IEkgc3RpbGwg cHJlZmVyIEVBSSBwcm90b2NvbC4gRUFJIHByb3RvY29sIGluY2x1ZGVzIG1hbnkgcmZjLiAgDQo+ PiBVVEY4U01UUCBpcyBqdXN0IG9uZSBvZiB0aGVtLg0KPiANCj4gSUlSQyB3ZSBkb24ndCB1c2Ug b3IgZXhwbGFpbiB0aGUgYWNyb255bSBFQUkgYW55d2hlcmUsIG1pbnVzIHRoZSBXRw0KPiBuYW1l IGFuZCBkcmFmdCBuYW1lcyBvZiBjb3Vyc2UuLi4gOy0pICBZb3UnZCBoYXZlIHRvIGV4cGFuZCB0 aGUgRUFJDQo+IGFjcm9ueW0gb24gZmlyc3QgdXNhZ2UuICBUaGUgZnJhbWV3b3JrIFJGQyBzYXlz IGluIGl0cyBjaGFwdGVyIDEuMw0KPiAodGVybWlub2xvZ3kpOg0KDQoNCmhvdyBhYm91dCBjaGFu Z2UgIkVBSSBwcm90b2NvbCIgdG8gImludGVybmF0aW9uYWxpemVkIGVtYWlsIGFkZHJlc3MgcHJv dG9jbyIgPw0KDQoNCiANCg0KDQo+IA0KPiB8IFRoZSB1bWJyZWxsYSB0ZXJtIHRvIGRlc2NyaWJl IHRoZSBlbWFpbCBhZGRyZXNzDQo+IHwgaW50ZXJuYXRpb25hbGl6YXRpb24gc3BlY2lmaWVkIGJ5 IHRoaXMgZG9jdW1lbnQgYW5kIGl0cyBjb21wYW5pb24NCj4gfCBkb2N1bWVudHMgaXMgIlVURjhT TVRQIi4gIEZvciBleGFtcGxlLCBhbiBhZGRyZXNzIHBlcm1pdHRlZCBieQ0KPiB8IHRoaXMgc3Bl Y2lmaWNhdGlvbiBpcyByZWZlcnJlZCAgdG8gYXMgYSAiVVRGOFNNVFAgKGNvbXBsaWFudCkgDQo+ IHwgYWRkcmVzcyIuDQo+IA0KPiBPb3BzLCB0aGUgQSBpbiBFQUkgaXMgYW4gImFkZHJlc3MiLCBm b3Igc29tZSBtaW51dGVzIEkgdGhvdWdodCB0aGF0DQo+IGl0J3MgImFyY2hpdGVjdHVyZSIuDQo+ IA0KPiBGcmFuaw0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBJTUEgbWFpbGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWE= --===============0305430275== 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 --===============0305430275==-- From ima-bounces@ietf.org Mon Mar 05 04:00:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO93R-0002jw-J5; Mon, 05 Mar 2007 04:00:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO93Q-0002jr-Re for ima@ietf.org; Mon, 05 Mar 2007 04:00:24 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO93L-0008V9-8C for ima@ietf.org; Mon, 05 Mar 2007 04:00:24 -0500 Received: (snipe 16991 invoked by uid 0); 5 Mar 2007 18:00:20 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.928045 secs); Received: from unknown (HELO ?210.107.139.110?) (Z???own@210.107.139.110) by unknown with SMTP; 5 Mar 2007 18:00:19 +0900 X-SNIPER-SENDERIP: 210.107.139.110 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: yaojk@cnnic.cn, ima@ietf.org, nobody@xyzzy.claranet.de, yangwooko@gmail.com Message-ID: <45EBDC16.7010607@icu.ac.kr> Date: Mon, 05 Mar 2007 18:00:06 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: YAO Jiankang Subject: Re: [EAI] Re: I-D ACTION:draft-ietf-eai-smtpext-03.txt References: <371858821.09217@cnnic.cn> <372743391.13410@cnnic.cn> <373033008.18419@cnnic.cn> <373084131.27366@cnnic.cn> In-Reply-To: <373084131.27366@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 YAO Jiankang wrote: >>>> s/EAI protocol/UTF8SMTP/ (?) >>> I still prefer EAI protocol. EAI protocol includes many rfc. >>> UTF8SMTP is just one of them. >> IIRC we don't use or explain the acronym EAI anywhere, minus the WG >> name and draft names of course... ;-) You'd have to expand the EAI >> acronym on first usage. The framework RFC says in its chapter 1.3 >> (terminology): > > > how about change "EAI protocol" to "internationalized email address protoco" ? If you are mentioning a specific proposal considered in this working group, UTF8SMTP is proper one as Frank pointed out. If you want to make sure that you are mentioning email (address) internationalization in general, you may use email (address) internationalization if needed. Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Mar 06 15:55:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOggk-0003Hv-8A; Tue, 06 Mar 2007 15:55:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgch-0005Wh-Rh; Tue, 06 Mar 2007 15:51:03 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOgch-0000Xu-1O; Tue, 06 Mar 2007 15:51:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 9852D2ACCE; Tue, 6 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOgbj-00066N-96; Tue, 06 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 06 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-smtpext-04.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-04.txt Pages : 18 Date : 2007-3-6 Internationalized email address includes two parts, the local part and the domain part. The ways email addresses are used by protocols are different from the ways domain names are used. The most critical difference is that emails are delivered through a chain of peering clients and servers while domain names are resolved by name servers by looking up their own tables. In addition to this, email transport protocols SMTP and ESMTP provide a negotiation mechanism through which clients can make decisions for further processing. This document specifies the use of SMTP extension for internationalized email address delivery. It also mentions the backward compatible mechanism for downgrade procedure, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-04.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-04.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-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-6132904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-smtpext-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-smtpext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-6132904.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 Wed Mar 07 04:10:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsAK-0000QA-1W; Wed, 07 Mar 2007 04:10:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOoFQ-0001sB-J0 for ima@ietf.org; Tue, 06 Mar 2007 23:59:32 -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 1HOoFL-00016p-4Z for ima@ietf.org; Tue, 06 Mar 2007 23:59:32 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HOoF8-00088b-PR for ima@ietf.org; Wed, 07 Mar 2007 05:59:14 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Mar 2007 05:59:14 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Mar 2007 05:59:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 07 Mar 2007 06:59:03 +0200 Lines: 73 Message-ID: <5dabypfy3s.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: 25620135586de10c627e3628c432b04a Subject: [EAI] Rejection/downgrade is misisng (Re: I-D ACTION:draft-ietf-eai-smtpext-04.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Internet-Drafts@ietf.org writes in gmane.ietf.ima: > 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-04.txt > Pages : 18 > Date : 2007-3-6 > > Internationalized email address includes two parts, the local part > and the domain part. The ways email addresses are used by protocols > are different from the ways domain names are used. The most critical > difference is that emails are delivered through a chain of peering > clients and servers while domain names are resolved by name servers > by looking up their own tables. In addition to this, email transport > protocols SMTP and ESMTP provide a negotiation mechanism through > which clients can make decisions for further processing. This > document specifies the use of SMTP extension for internationalized > email address delivery. It also mentions the backward compatible > mechanism for downgrade procedure, as specified in an associated > specification. Hmm. "reject", "bounce" or "downgrade" is mentioned only on following places: Introduction: | which clients can make decisions for further processing. This | document specifies the use of SMTP extension for internationalized | email address delivery. It also mentions the backward compatible | mechanism for downgrade procedure, as specified in an associated | specification. | subsequent operations. If the ALT-ADDRESS value is not set by the | sender, the email must be rejected to the original sender. If the | email is rejected due to the incapability of supporting UTF8SMTP, the | relative server should issue the response error code "5.3.3" defined | situation, and the message is sent successfully after retrying, then | it was a good thing to do. Of course, if there is always an ASCII- | only SMTP server in the path, then retrying only adds delay to the | failure (reject or downgrade). | 8.5. draft-ietf-eai-smtpext: Version 04 | | o Refine some syntax. | o Delete "Message Header Label" section. | o Change "bounce" to "reject". Effectively Introduction -chapter promises that document mentions downgrade procedure, but that Introduction is only place where it is mentioned. What I have missing? Rejection is only mentioned on ALT-ADDRESS chapter. There is no chapter, which says that UTF8SMTP messages must not sent to SMTP servers which do not support UTF8SMTP. This is important requirement. This requirement must exists even when there is longer "Message Header Label", which tell that message is UTF8SMTP. It is just harder to SMTP server to determine when message is UTF8SMTP. It still need determine it. :-) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Mar 07 04:39:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOscd-0008L4-1A; Wed, 07 Mar 2007 04:39:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOscb-0008Kx-3m for ima@ietf.org; Wed, 07 Mar 2007 04:39:45 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOscZ-0002VW-Kx for ima@ietf.org; Wed, 07 Mar 2007 04:39:45 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CC1B92596EC; Wed, 7 Mar 2007 10:35:15 +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 09036-10; Wed, 7 Mar 2007 10:35:10 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 58C202596DD; Wed, 7 Mar 2007 10:35:10 +0100 (CET) Message-ID: <45EE8859.2080109@alvestrand.no> Date: Wed, 07 Mar 2007 10:39:37 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Kari Hurtta Subject: Re: [EAI] Rejection/downgrade is misisng (Re: I-D ACTION:draft-ietf-eai-smtpext-04.txt) References: <5dabypfy3s.fsf@Hurtta06k.keh.iki.fi> In-Reply-To: <5dabypfy3s.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: 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 Kari Hurtta wrote: > Internet-Drafts@ietf.org writes in gmane.ietf.ima: > > >> 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-04.txt >> Pages : 18 >> Date : 2007-3-6 >> >> Internationalized email address includes two parts, the local part >> and the domain part. The ways email addresses are used by protocols >> are different from the ways domain names are used. The most critical >> difference is that emails are delivered through a chain of peering >> clients and servers while domain names are resolved by name servers >> by looking up their own tables. In addition to this, email transport >> protocols SMTP and ESMTP provide a negotiation mechanism through >> which clients can make decisions for further processing. This >> document specifies the use of SMTP extension for internationalized >> email address delivery. It also mentions the backward compatible >> mechanism for downgrade procedure, as specified in an associated >> specification. >> > > Hmm. "reject", "bounce" or "downgrade" is mentioned only on following places: > > Introduction: > | which clients can make decisions for further processing. This > | document specifies the use of SMTP extension for internationalized > | email address delivery. It also mentions the backward compatible > | mechanism for downgrade procedure, as specified in an associated > | specification. > > > > Effectively Introduction -chapter promises that document mentions > downgrade procedure, but that Introduction is only place where it is > mentioned. > > What I have missing? > I think our attempts to elide all mention of downgrade from this document have been successful, but we missed the mention in the intro. > > Rejection is only mentioned on ALT-ADDRESS chapter. There is > no chapter, which says that UTF8SMTP messages must not > sent to SMTP servers which do not support UTF8SMTP. This > is important requirement. > Yes. If it's not obvious, it needs to be. > This requirement must exists even when there is longer > "Message Header Label", which tell that message is UTF8SMTP. > It is just harder to SMTP server to determine when message > is UTF8SMTP. It still need determine it. :-) > yes. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Mar 07 11:11:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyju-00010c-Qg; Wed, 07 Mar 2007 11:11:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOyje-0000c9-Pt; Wed, 07 Mar 2007 11:11:26 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOyjc-0006H1-Bo; Wed, 07 Mar 2007 11:11:26 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id BCF712AC98; Wed, 7 Mar 2007 15:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOyOw-0006Ty-GZ; Wed, 07 Mar 2007 10:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 10:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-imap-utf8-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 --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 : IMAP Support for UTF-8 Author(s) : P. Resnick, C. Newman Filename : draft-ietf-eai-imap-utf8-01.txt Pages : 15 Date : 2007-3-7 This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support unencoded international characters in user names, mail addresses and message headers. This is an early draft and intended as a framework for discussion. Please do not deploy implementations of this draft. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-imap-utf8-01.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-imap-utf8-01.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-imap-utf8-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-7091931.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-imap-utf8-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-imap-utf8-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7091931.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 Wed Mar 07 12:42:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP09f-0003S1-Cq; Wed, 07 Mar 2007 12:42:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP09d-0003Qc-2f for ima@ietf.org; Wed, 07 Mar 2007 12:42:21 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HP08n-0002Hd-7c for ima@ietf.org; Wed, 07 Mar 2007 12:41:32 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HP08W-00086p-JV for ima@ietf.org; Wed, 07 Mar 2007 18:41:13 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Mar 2007 18:41:12 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Mar 2007 18:41:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 07 Mar 2007 19:41:00 +0200 Lines: 46 Message-ID: <5dzm6phryr.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: c1c65599517f9ac32519d043c37c5336 Subject: [EAI] Respawn "Messages on original form" (Re: I-D ACTION:draft-ietf-eai-imap-utf8-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 Internet-Drafts@ietf.org writes in gmane.ietf.ima: > 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 : IMAP Support for UTF-8 > Author(s) : P. Resnick, C. Newman > Filename : draft-ietf-eai-imap-utf8-01.txt > Pages : 15 > Date : 2007-3-7 > > This specification extends the Internet Message Access Protocol > version 4rev1 (IMAP4rev1) to support unencoded international > characters in user names, mail addresses and message headers. This > is an early draft and intended as a framework for discussion. Please > do not deploy implementations of this draft. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-eai-imap-utf8-01.txt Just note. I'm still concernes about these things what I noted on thread, which I started with message: From: Kari Hurtta Subject: [EAI] Messages on original form (Re: I-D ACTION:draft-ietf-eai-imap-utf8-00.txt) Newsgroups: gmane.ietf.ima To: ima@ietf.org Date: 06 Feb 2007 21:29:49 +0200 In general that is concern that UTF8SMTP capable mailstore should store messages on that form what it is received them. And that form should be accessible. I see that someones disagree with me. That is not just draft-ietf-eai-imap-utf8, but also draft-ietf-eai-smtpext and draft-ietf-eai-pop. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Mar 07 15:50:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP35w-00023F-Ih; Wed, 07 Mar 2007 15:50:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP35N-0001NP-K4; Wed, 07 Mar 2007 15:50:09 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP35K-0001Pf-MG; Wed, 07 Mar 2007 15:50:09 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id EB99426EBB; Wed, 7 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP35G-0002zn-8f; Wed, 07 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-04.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 : Internationalized Email Headers Author(s) : J. Yeh Filename : draft-ietf-eai-utf8headers-04.txt Pages : 14 Date : 2007-3-7 Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-04.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-utf8headers-04.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-utf8headers-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-7111036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-utf8headers-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-utf8headers-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7111036.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 Wed Mar 07 19:19:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP6MI-0000cr-Ly; Wed, 07 Mar 2007 19:19:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP551-0006Y7-7w for ima@ietf.org; Wed, 07 Mar 2007 17:57:55 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP3Pv-0004LW-GC for ima@ietf.org; Wed, 07 Mar 2007 16:11:46 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3#clerew*man$ac#uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45ef2a6e.5c53.31c for ima@ietf.org; Wed, 7 Mar 2007 21:11: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 l27LB8dD011597 for ; Wed, 7 Mar 2007 21:11:09 GMT Date: Wed, 07 Mar 2007 21:11:07 -0000 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 Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Subject: [EAI] Comments on the DSN draft (draft-ietf-eai-dsn-00.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org There have been discussions on some aspects of this draft, but no overall review, and in particular no discussion of exactly which new media types need to be defined. I apologise for not respondig earlier. Abstract Delivery status notifications (DSNs) are critical to the correct operation of an email system. ... DSNs and mentioned here but not MDNs, which are also covered by this draft. OTOH: 1. Introduction Mentions MDNs but not DSNs. Both places should mention both, and their full text versions and RFC refs at least here. 3. UTF-8 Address Type Our documents seem divided upon whether we speak of "UTF8" or "UTF-8". Please can we have a consistent usage throughout the whole series? I don't mind which, but I note that the charset registered with IANA is "utf-8" (though it could do with "utf8" as an alias). OTOH, I think most of our present drafts tend to use "utf8", and certainly use of "utf-8" in this document has lead to a proliferation of hyphens, as in "utf-8-delivery-status". utf-8-type-addr = "utf-8;" utf-8-address utf-8-address = "<" Mailbox [ *WSP "<" Mailbox ">" ] ">" ; The first occurrence of 'Mailbox' is defined in [utf8smtp] ; The second occurrence of 'Mailbox' is defined in RFC 2821 This has already been discussed. We should always look to [utf8headers] for the syntax of bits and pieces inside messages ([utf8smtp] is for stuff that goes in the envelope - OK, some syntactic objects, as this one, can occur in both). Moreover (in RFC 2822 terminology) includes the , which I don't think we want here. So what you actually need to say is: utf-8-address = angle-addr ; as defined in [utf8headers] 4. UTF-8 Encoded Address Type We discuused this. It is unfortunate that we cannot use . I think we more-or-less agreed that a "%hex" encoding of the UTF-8 was the best solution. Sadly, this format will often turn up in message/delivery-status and in whatever/utf-8-delivery-status, and it is an open question as to whether user agents will be able to restore it to its UTF-8 form. 5. UTF-8 Delivery Status Notifications In order to discuss this, I am going to introduce various scenarios that we need to cope with. Scenario 1 ---------- Envelope contains MAIL FROM: utf-8@utf8, but with no ALT-address. If this message gets downgraded, a DSN can never be returned to the originator. Therefore the downgrade process MUST generate a "relayed" DSN, even though the next hop does advertise DSN. Scenario 2 ---------- Envelope contains MAIL FROM: utf-8@utf8 with ALT-address ascii@ascii. A DSN may then sometimes be sent to ascii@ascii, which may or may not be able to render any utf-8-enc within it (and might even not reach the smae person/site as utf8@utf8 - though that could be regarded as the Sender's fault). Scenario 3 ---------- The message gets downgraded before it reaches the Reporting MTA (which may or may not be the final delivery MTA). In this case RCPT TO: contains to-alt-ascii@to-alt-ascii ORCPT contains utf-8-enc: to-utff8@to-utf8 (%hex encoded) The Reporting MTA will now generate a DSN with a message/delivery-status containing ORCPT: utf-8-enc; to-utff8@to-utf8 (%hex encoded) ENVID: whatever. but %hex encoded Reporting-MTA: dns; r-ascii.example plus either a text/rfc822-headers containing the downgraded headers or a message/rfc822 containing the full message as downgraded. The DSN is sent to to ascii@ascii. It is an open question whether ascii@ascii can display the %hex material, or the text/rfc822-headers or message/rfc822 in an upgraded form. Scenario 4 ---------- The message arrives at a Reporting MTA which understands UTF8SMTP. I am going to intropduce several versions of this scenario. Version 4a, following the draft as currently written. ----------- The Reporting MTA will now generate a DSN with a message/utf8-delivery-status containing ORCPT: utf-8; to-utff8@to-utf8 (still as utf-8) ENVID: whatever, still in utf-8 Reporting-MTA: dns; r-utf8.example but Oops! RFC 3461 does not allow that, so instead use utf-8-dns; r-utf8.example or alternatively dns; r-utf8-in-punycode.example plus either a message/utf-8-headers containing the original headers or a message/utf-8 containing the full original message The DSN is sent to utf8@utf8 plus ALT-ascii@ascii (if an ALT return address is available). But, as we have already discussed, all that doesn't work because this DSN may go via a route which needs to downgrade it to non-8BITMIME. And sadly you cannot use a C-T-E of Q-P or Base64 on a message type. Moreover the only message type that current 8BIT downgraders know how to deal with is message/rfc822. And why use message/utf-8-headers when the obvious extension of the current DSN mechanisms would have been text/utf-8-headers. Version 4b, using the simplest fixes, as already dicussed. ----------- The Reporting MTA will now generate a DSN with an application/utf8-delivery-status containing exactly the same as above plus either a text/utf-8-headers containing the original headers, and specifying charset=utf-8 or an application/utf-8 containing the full original message and delivered as before. The two application types are opaque as far as current agents are concerned (being treatable as application/octet-stream), but may be unwrapped by UTF8SMTP-capable agents (and in particular displayed sensibly by UTF8-capable user agents). The text/utf-8-headers will come to no harm since existing agents will treat it as text/plain (and could even display ir correctly as such). But can we do better than this? Version 4c. ----------- Recall that there will be two types of email message in future: "ASCII" messages as defined in RFC 2822 plus the MIME standards "UTF8SMTP" messages, as defined in [utf8headers] which _extends_ RFC 2822, and could as easily extend the MIME standards BUT there is a strict requirement that UTF8SMTP messages are allowed ONLY in the UTF8SMTP Universe, and MUST NOT be seen in the current ASCII Universe. So at the boundary between those Universes there must be either downgrading or bouncing. I think we are already agreed that the only way to detect that a given message is or is not a UTF8SMTP one is to recursively descend through its MIME structure looking for UTF-8 headers, and that downgrading will involve such a (and probably the same) recursive descent. Also that mesasage/utf8 objects (as extended) will contain UTF8SMTP messages (that is going to happen whether we like it or not, so we may as well ensure that it works, and is covered in the downgrading rules). So let us take that principle a little further, and try to extend the existing DSN media types. There are three of them to consider, and we may or may not be able to fix them all. The Reporting MTA will now generate a DSN with 4c(i) a message/delivery-status (extended) containing ORCPT: utf-8; to-utff8@to-utf8 ENVID: whatever. in utf-8 Reporting-MTA: dns; r-utf8.example (we seen to have extended "dns" as well, or else we use "utf-8-dns") PROVIDED a downgrade of message/delivery-status to what you saw in Scenario 3 is defined; plus either 4c(ii) a text/rfc822-headers (extended to allow a charset=utf-8 parameter and using C-T-E: 8bit) containing the downgraded headers HMMMMM! Can we get away without a downgrade there? It would almost certainly pass unscathed through the existing network, though existing user agents might baulk at displaying it. For sure, existing 8BITMIME downgraders would handle it correctly. or 4c(iii) a message/rfc822 (extended) containing the full original message PROVIDED a downgrading is defined. But we are almost certainly going to define that downgrading anyway. So, of those three cases, I think (iii) is the easiest to achieve (and also the most desirable to achieve) and (i) is the hardest. But they should all be thought about. Scenarion 5 ----------- The message arrives at a Reporting MTA which understands UTF8SMTP which generates a DSN as in (some version of) Scenario 4 above. Subsequently (perhaps even at that same Reporting-MTA) it needs to be downgraded (because the Return-Path may follow a different sequence of MTAs than simply the reverse of the original path). What happens here has largely bee discussed already under Scenario 4. But there still remains the open question of whether it can all be displayed neatly when it gets back to the original sender. 6. UTF-8 Message Disposition Notifications I have not considered this is detail, but whatever we do regarding the scenarios for the DSN cases could equally well be applied here. -- 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 Mar 07 22:18:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP99F-0001hX-1B; Wed, 07 Mar 2007 22:18:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP99D-0001dF-Fx for ima@ietf.org; Wed, 07 Mar 2007 22:18:31 -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 1HP99C-0001jF-J4 for ima@ietf.org; Wed, 07 Mar 2007 22:18:31 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HP999-000N8Y-93; Wed, 07 Mar 2007 22:18:27 -0500 Date: Wed, 07 Mar 2007 22:18:26 -0500 From: John C Klensin To: Harald Tveit Alvestrand , Jari Arkko Message-ID: <87F2B237E36CE025B401921E@p3.JCK.COM> In-Reply-To: <85DC516BD31D919531CC0463@[192.168.1.108]> References: <85DC516BD31D919531CC0463@[192.168.1.108]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: ima@ietf.org Subject: [EAI] Re: From Jari: Re: Your DISCUSS on draft-ietf-eai-framework-05 (fwd) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Jari, As I assume you know by now, your message to the WG of 14 February got stuck somewhere and was apparently never circulated to the WG until now. Again with the understanding that this is a personal note/ explanation that may or may not represent a WG position... --On Wednesday, 07 March, 2007 23:46 +0100 Harald Tveit Alvestrand wrote: > ------------ Forwarded Message ------------ > Date: 14. februar 2007 14:33 +0200 > From: Jari Arkko > To: Harald Alvestrand > Cc: iesg@ietf.org, EAI WG > Subject: Re: Your DISCUSS on draft-ietf-eai-framework-05 > >>> > Since the final delivery SMTP server (or, to be more >>> > specific, its corresponding mail storage agent) cannot >>> > safely assume that agents accessing email storage will >>> > always be capable of handling the extensions proposed >>> > here, it MAY either downgrade internationalized emails or >>> > specially identify messages that utilize these extensions, >>> > or both. If this done, the final delivery SMTP server >>> > SHOULD include a mechanism to preserve or recover the >>> > original internationalized forms without information loss >>> > to support access by UTF8SMTP-aware agents. >>> >>> Does this suggest that the final server downgrades mails >>> without knowing that the client is uncapable of reading >>> them in the internationalized form? This seems surprising. >>> Can you elaborate why? And what is the identification >>> mechanism, and how does it affect POP/IMAP access to the >>> messages? >> Since this is an issue with a bit of substance, I'm CCing the >> WG on this note. >> The issue with POP and IMAP servers is that there is no >> knowing what kind of client software the user will use to >> connect to the mail store the *next* time it connects. >> >> Especially in the case of IMAP, it is not uncommon to connect >> to a single mailbox using multiple clients (often including a >> Web client) - at the same time, serially, or switching >> randomly between them. >> > > Right. > >> So not only is the final delvery agent incapable of knowing >> the client's capabilities, it wouldn't help if it knew at the >> time of delivery, because the capabilities might change at >> any time. And messages in mailstores last for years, unline >> messages in transit, which generally expire after days at >> most, so it is very possible that a client's capabilities >> will change over the lifetime of the message in the mailstore. > Exactly. That is why it is important that we do not downgrade > mail permanently if we can avoid it. I reacted to the text > because it seemed to be saying that. Specifically, it says the > storage agent may downgrade i18n e-mail. Does that mean that > it would actually downgrade it in the storage, or just for the > purpose of serving it to this particular client at this one > time? Actually, it doesn't say a thing about the storage agent because, as far as 2821 is concerned, there is no such thing as a storage agent. More specifically, while there might be one, its properties and interfaces are not defined at all. Certainly, if one can avoid loss of information, one should do that. We can say that in the document, but it seems too self-evident to be worth much discussion. But suppose that (i) the interface to the mail store, or the store itself, cannot support messages with any non-ASCII content and (ii) at the time the message is received, the POP and IMAP servers associate with the mail store are known to the person implementing or configuring the delivery SMTP server to have no mechanisms or conventions for converting from mail-store format back to UTF8SMTP and header format. Storing the information in UTF-8 form is simply not a possibility here, nor is storing it in some form from which the UTF-8 form can be reconstructed. That leaves two options/theories: (a) The delivery MTA has no business offering the UTF8SMTP option if the situation downstream is that weak. There is an additional complication with this, involving different mail stores for different addresses: see below. (b) It is desirable to deliver the mail if at all possible, even if it is somewhat damaged. That language and the "MAY" provision were intended to allow for the second case since "deliver something if at all possible" is often chosen in practice. >> What is knowable is whether or not the *mailbox server* is >> capable of supporting UTF8SMTP; in the case of delivery via >> SMTP or LMTP, the "UTF8SMTP" extension is a good way of >> signalling such support. >> >> The issues in the specific context of IMAP and POP, including >> identification mechanisms, are addressed in the drafts >> specific to these protocols; however, I think it would not be >> appropriate to go into details on those protocols in an >> overview document - also because those proposals are still >> under discussion by the WG, and might change considerably >> before they are finished. > > Fair enough. >> I don't know if this is enough clarification of why the text >> is the way it is - do you need more information to clear your >> DISCUSS? > > Let me suggest a small reformulation: This really doesn't work any better than the original and it ignores some important cases. Dissection below. > Since the final delivery SMTP server (or, to be more specific, > its corresponding mail storage agent) As mentioned above, "mail storage agent" is not well-defined or formally part of the model > cannot safely assume that agents accessing email storage It is a little worse than that. It may use some protocol -- either LMTP or something that is not standardized in the IETF -- to deliver to the mail store. If the mail store, or the path to it, doesn't have UTF8SMTP capability, the delivery SMTP server is stuck. Worse, it may deliver messages to different addresses (mailboxes) into different message stores using different protocols. If some of them are fully capable of handling UTF-8 headers and message content, and some are not, it should probably advertise the options but it is not clear what it should do in the cases in which, e.g., someone has assigned a non-ASCII address to a UTF-8-incapable mail store. That case is arguably a configuration error, but some others, including those involving backward-pointing addresses might not be. > will always be capable of handling the extensions proposed > here, it MAY either provide a downgraded version of the > internationalized email to these agents, or specially identify > messages that utilize these extensions, or both. In any case, > the final delivery SMTP server SHOULD allow the original > internationalized forms to be accessed by UTF8SMTP-aware > agents without information loss, even if they are also > accessed in downgraded form by other agents. And, of course, the final delivery SMTP server isn't doing any allowing because, in general, it doesn't talk to the servers or access methods that support the "other agents" you posit. I am sure the vocabulary and concepts her could be straightened out but strongly suspect that the result would not be substantively different from what is in the text now. The problems here reflect both the history and context of email work in the IETF (e.g., POP and IMAP assume the existence of a mail store, but SMTP does not) and some implementation options and flexibilities that are 2821/2822-conforming. best, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 08 01:47:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPCPi-0004ff-Ab; Thu, 08 Mar 2007 01:47:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPCPh-0004fa-24 for ima@ietf.org; Thu, 08 Mar 2007 01:47:45 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPCPf-00008A-Da for ima@ietf.org; Thu, 08 Mar 2007 01:47:45 -0500 Received: from aabbeell (pc093.twnic.net.tw [211.72.211.93]) by twnic.net.tw (8.13.8/8.13.8) with SMTP id l286le0E022521 for ; Thu, 8 Mar 2007 14:47:41 +0800 Message-ID: <03f301c7614d$e918a130$c7d348d3@aabbeell> From: "abel" To: References: Date: Thu, 8 Mar 2007 14:49:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [EAI] SPF and DKIM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Do we discuss those more ? 1. As I know in SPF SPF TXT record listed where my email come from list in this domain , A example in downgrading : >>ehlo twnic.net.tw >>mail from: ALT-ADDRESS=ASCII@gmail.com # EAI-aware >>rcpt to: # non-EAI-aware when the downgraded mail transmits , if other.domain run SPF check, we can pass in SPF helo check ,but fail in SPF sender check (ascii@gmail.com) if gmail.com SPF records with -all unless gmail.com adds SPF for us, but it seems impossilbe to do that. Fujiwara's downgrade-03 draft said 'more detailed consideration is required' in Section 5, But I think that SPF sender check will break ALT-ADDRESS without restriction. 2. DKIM Header change (downgraded / drop ) maybe break the signatures, a downgraded mail keeps the original header can follow DKIM, but DKIM should know how to verify and reduction. 2.1 Downgrading after DKIM, some header value has changed by downgrading procedue when transmits, DKIM verifier should restores 'Downgraded:' header to verify, and all 'Downgraded:' headers are above 'DomainKey-Signature' header. 2.2 Downgrading before DKIM, DKIM signs the downgraded headers, it's possible to include 'h=Downgraded:' in 'DomainKey-Signature', all 'Downgraded:' headers are under DomainKey-Signature header, DKIM verifier should verify all 'Downgraded:' headers if there are 'Downgraded' in tags 'h=' And we still need to more consideration about the downgrading impact in DomainKey-Signature tags 'd=' (domain) 'i=' (sender) 'z=' (header name and header values in quoted-printable) or more. If we drops header values (such as uFor or others ) and the headers are signed in 'DomainKey-Signature' will cause Domain Key verifier treats as a bad signature if they do not appear ,especially in trace field, that's fine in trace filed rule and DKIM siner/verifier issue. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 08 02:34:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPD8g-0000tl-Mf; Thu, 08 Mar 2007 02:34:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPD8f-0000tf-8F for ima@ietf.org; Thu, 08 Mar 2007 02:34:13 -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 1HPD8Z-0006ZW-Je for ima@ietf.org; Thu, 08 Mar 2007 02:34:13 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HPD8C-0008Je-E9 for ima@ietf.org; Thu, 08 Mar 2007 08:33:44 +0100 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Mar 2007 08:33:44 +0100 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Mar 2007 08:33:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 08 Mar 2007 09:33:39 +0200 Lines: 123 Message-ID: <5dirdcchpo.fsf@Hurtta06k.keh.iki.fi> References: <03f301c7614d$e918a130$c7d348d3@aabbeell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Subject: [EAI] Re: SPF and DKIM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "abel" writes in gmane.ietf.ima: > Do we discuss those more ? I think that we should. > 1. As I know in SPF > SPF TXT record listed where my email come from list in this domain , > > A example in downgrading : > >>ehlo twnic.net.tw > >>mail from: ALT-ADDRESS=ASCII@gmail.com # EAI-aware > >>rcpt to: # non-EAI-aware > > when the downgraded mail transmits , if other.domain run SPF check, we can > pass in SPF helo check ,but fail in SPF sender check (ascii@gmail.com) if > gmail.com SPF records with -all unless gmail.com adds SPF for us, > but it seems impossilbe to do that. Yes, but that do not much differ from ehlo twnic.net.tw mail from: I think that there is no new restrictions. On general if you have ehlo twnic.net.tw mail from: ALT-ADDRESS=forwarder@gateway.example if gateway.example ia providing forwarding service, it practically can not provide SPF records -- not providing SPF records is part of service. > Fujiwara's downgrade-03 draft said 'more detailed consideration is required' > in Section 5, But I think that SPF sender check will break ALT-ADDRESS > without > restriction. > > 2. DKIM > Header change (downgraded / drop ) maybe break the signatures, Also header change ( conversion to UTF-8 by IMAP/POP server) may break signatures. This also need to be discussed. > a downgraded mail keeps the original header can follow DKIM, but DKIM > should know how to verify and reduction. > > 2.1 Downgrading after DKIM, some header value has changed by downgrading > procedue when transmits, DKIM verifier should restores 'Downgraded:' > header to verify, and all 'Downgraded:' headers are above > 'DomainKey-Signature' > header. A) That requires that Donwgrading -undo algorithm ('upgrade') in draft-ietf-eai-downgrade really returns original header fields. Currently there is: * If each mail header has [RFC2047] encoded part and which encoding is "UTF-8", it is a downgraded header, so decode it. This does NOT fill these requirements. Currently 'downgrade' part of algorihm even do not preserve original header fields (except address header fields) to 'Downgraded:' -header fields. If algorithm is modified and original header fields are preserved on Downgraded: -header field, on Donwgrading -undo algorithm there is little problem -- it needs to know which one header fields must discard -- it must discard correspond downgraded header field, when restoring data from Downgraded: -header field -- otherwise more header fields with same name is generated than on original message. B) DKIM signature verify may accur on agent which do not know about UTF8SMTP protocol -- therefore it will not know how to upgrade header fields. That also causes that DKIM signature verify fails. To prevent that downgrading need to move DomainKey- -header fields to Downgraded: -header fields and destroy original header fields. ... problem there is that downgrade procedure needs know every signing protocol ... ( You may want compare how I proecess exatcly this same promlem on my draft-hurtta-eai-encapsulation-00.txt draft. ) > 2.2 Downgrading before DKIM, DKIM signs the downgraded headers, it's > possible > to include 'h=Downgraded:' in 'DomainKey-Signature', all 'Downgraded:' > headers are under DomainKey-Signature header, DKIM verifier should verify > all 'Downgraded:' headers if there are 'Downgraded' in tags 'h=' > > And we still need to more consideration about the downgrading impact in > DomainKey-Signature tags 'd=' (domain) 'i=' (sender) 'z=' (header name > and header values in quoted-printable) or more. > > > > If we drops header values (such as uFor or others ) and the headers are > signed in > 'DomainKey-Signature' will cause Domain Key verifier treats as a bad > signature > if they do not appear ,especially in trace field, that's fine in trace filed > rule > and DKIM siner/verifier issue. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 08 03:25:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPDvx-00025n-0n; Thu, 08 Mar 2007 03:25:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPDvv-00025f-PZ for ima@ietf.org; Thu, 08 Mar 2007 03:25:07 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPDvt-0007xK-4W for ima@ietf.org; Thu, 08 Mar 2007 03:25:07 -0500 Received: from aabbeell (pc093.twnic.net.tw [211.72.211.93]) by twnic.net.tw (8.13.8/8.13.8) with SMTP id l288P0N6031024; Thu, 8 Mar 2007 16:25:02 +0800 Message-ID: <049401c7615b$835ae980$c7d348d3@aabbeell> From: "abel" To: , "Kari Hurtta" References: <03f301c7614d$e918a130$c7d348d3@aabbeell> <5dirdcchpo.fsf@Hurtta06k.keh.iki.fi> Subject: Re: [EAI] Re: SPF and DKIM Date: Thu, 8 Mar 2007 16:26:44 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Thanks for Kari comments, These remind us to pay attention to more details in SPF and DKIM > On general if you have > ehlo twnic.net.tw > mail from: ALT-ADDRESS=forwarder@gateway.example > > > if gateway.example ia providing forwarding service, it practically > can not provide SPF records -- not providing SPF records is part > of service. Yes, but users/clients dont know whether their provider has SPF record in their ALT-ADDRESS, If there are SPF in thoes domain include '-all' , that maybe cause their mail to be rejected. Mail adminstrator is hard to explains those issue to their clients. > > 2. DKIM > > Header change (downgraded / drop ) maybe break the signatures, > > Also header change ( conversion to UTF-8 by IMAP/POP server) may > break signatures. This also need to be discussed. Agree! we miss. > > Currently 'downgrade' part of algorihm even do not preserve > original header fields (except address header fields) to > 'Downgraded:' -header fields. I 'm not sure what headers information we lose, but 'change' is a issue in DKIM > If algorithm is modified and original header fields are preserved > on Downgraded: -header field, on Donwgrading -undo algorithm there > is little problem -- it needs to know which one header fields must > discard -- it must discard correspond downgraded header field, > when restoring data from Downgraded: -header field -- otherwise > more header fields with same name is generated than on original message. yes, agree! > B) > > DKIM signature verify may accur on agent which do not know about > UTF8SMTP protocol -- therefore it will not know how to upgrade header fields. > > That also causes that DKIM signature verify fails. > > To prevent that downgrading need to move DomainKey- -header fields > to Downgraded: -header fields and destroy original header fields. > > ... problem there is that downgrade procedure needs know every signing > protocol ... > > > ( You may want compare how I proecess exatcly this same promlem > on my draft-hurtta-eai-encapsulation-00.txt draft. ) yes, DKIM dose not know how to -undo header fields in 'Downgraded', and our Drafts does not memtion those more details. Abel _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 08 07:22:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPHdK-0002k0-Ml; Thu, 08 Mar 2007 07:22:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPHdJ-0002jr-94 for ima@ietf.org; Thu, 08 Mar 2007 07:22:09 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPHd9-0005fo-MQ for ima@ietf.org; Thu, 08 Mar 2007 07:22:09 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3&clerew#man*ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45efffe6.13a85.47 for ima@ietf.org; Thu, 8 Mar 2007 12:21:58 +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 l28CLltA022030 for ; Thu, 8 Mar 2007 12:21:48 GMT Date: Thu, 08 Mar 2007 12:21:46 -0000 To: IMA Subject: Re: [EAI] SPF and DKIM References: <03f301c7614d$e918a130$c7d348d3@aabbeell> 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: <03f301c7614d$e918a130$c7d348d3@aabbeell> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 08 Mar 2007 06:49:23 -0000, abel wrote: > Do we discuss those more ? > 2. DKIM > Header change (downgraded / drop ) maybe break the signatures, > > a downgraded mail keeps the original header can follow DKIM, but DKIM > should know how to verify and reduction. There are no simple answers to the question of EAI and DKIM, but there are some possibilities that might be worth exploring. But first some general points. The first requirement is that DKIM verifiers should be able to recognise when they are being asked to verify a downgraded message (what they do then is less certain, but without that information they are totally stuck). And the second is that you should include as few headers in the signature as will suffice to achieve the desired level of security. The more headers that are included in the signature, the less likely that any verification will be possible. > > 2.1 Downgrading after DKIM, some header value has changed by downgrading > procedue when transmits, DKIM verifier should restores 'Downgraded:' > header to verify, and all 'Downgraded:' headers are above > 'DomainKey-Signature' > header. Yes, that is one possible approach. In principle the changes specified in our 'downgrade' document should be reversible. In practice, it is not so sure how well that would work. It might be easier if DKIM included an even more relaxed canonicalization algorithm. And it is more likely to work the fewer headers covered by the signature (but, unfortunately, including the From header is a MUST). > 2.2 Downgrading before DKIM, DKIM signs the downgraded headers, it's > possible > to include 'h=Downgraded:' in 'DomainKey-Signature', all 'Downgraded:' > headers are under DomainKey-Signature header, DKIM verifier should > verify > all 'Downgraded:' headers if there are 'Downgraded' in tags 'h=' > > And we still need to more consideration about the downgrading impact > in > DomainKey-Signature tags 'd=' (domain) 'i=' (sender) 'z=' (header > name > and header values in quoted-printable) or more. Again, if the downgrade process is suffficiently well defined that all downgraders will produce exactly the same dongraded message, then signing that (even if what you send is the original utf8 form) would suffice. Even better, include two signatures, one for the original utf8 version (which should verify without problem at site that receive it in that form) and one for the downgraded version. > > > > If we drops header values (such as uFor or others ) and the headers are > signed in > 'DomainKey-Signature' will cause Domain Key verifier treats as a bad > signature > if they do not appear ,especially in trace field, that's fine in trace > filed > rule > and DKIM siner/verifier issue. Generally speaking, signing trace fields is a Bad Thing. It is doubtful whether this WG should be looking into this issue in too much detail at this stage, but it is nevertheless useful to have some idea of what the problems and possibilities might be, since the matter will have to be settled at some stage. -- 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 Mar 08 07:50:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPI4Z-00047L-Ha; Thu, 08 Mar 2007 07:50:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPI4Y-00047G-LN for ima@ietf.org; Thu, 08 Mar 2007 07:50:18 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPI4X-0000pV-3b for ima@ietf.org; Thu, 08 Mar 2007 07:50:18 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3$clerew$man$ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45f00687.11a6b.365 for ima@ietf.org; Thu, 8 Mar 2007 12:50:15 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l28CoCw0023741 for ; Thu, 8 Mar 2007 12:50:16 GMT Date: Thu, 08 Mar 2007 12:50:12 -0000 To: IMA Subject: Re: [EAI] Re: From Jari: Re: Your DISCUSS on draft-ietf-eai-framework-05 (fwd) References: <85DC516BD31D919531CC0463@[192.168.1.108]> <87F2B237E36CE025B401921E@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: <87F2B237E36CE025B401921E@p3.JCK.COM> 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 Thu, 08 Mar 2007 03:18:26 -0000, John C Klensin wrote: > > As mentioned above, "mail storage agent" is not well-defined or > formally part of the model > >> cannot safely assume that agents accessing email storage > > It is a little worse than that. It may use some protocol -- > either LMTP or something that is not standardized in the IETF -- > to deliver to the mail store. If the mail store, or the path to > it, doesn't have UTF8SMTP capability, the delivery SMTP server > is stuck. Worse, it may deliver messages to different > addresses (mailboxes) into different message stores using > different protocols. If some of them are fully capable of > handling UTF-8 headers and message content, and some are not, it > should probably advertise the options ... If a server advertises UTF8SMTP, then it is ofering a guarantee: "Either I will ensure that this messages is handed off, in exactly the form received, to some user/mailbox/store/system/whatever that is willing to offer essentially the same guarantee; OR I will downgrade it before passing it to any user/mailbox/store/system/whatever that cannot give that guarantee; OR I will send it back up the Return-Path with an explanation that it could not be delivered." This implies, to me, that even if there are internal communications (LMPT, porocmail scripts, whatever) for routeing mail for different local-parts through different channels, the MTA itself needs to be configured with basic information as to which local-parts/channels can offer the UTF8SMTP capability. Sounds like a case for a bit of sendmail.cf hacking :-( . > but it is not clear what > it should do in the cases in which, e.g., someone has assigned a > non-ASCII address to a UTF-8-incapable mail store. That case is > arguably a configuration error,... agreed. -- 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 Mar 08 10:59:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPL1h-0007qg-O7; Thu, 08 Mar 2007 10:59:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPL1g-0007qL-EW for ima@ietf.org; Thu, 08 Mar 2007 10:59:32 -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 1HPL1e-0002hf-TS for ima@ietf.org; Thu, 08 Mar 2007 10:59:32 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HPL1e-00015r-2B; Thu, 08 Mar 2007 10:59:30 -0500 Date: Thu, 08 Mar 2007 10:59:28 -0500 From: John C Klensin To: abel Subject: Re: [EAI] Re: SPF and DKIM Message-ID: <046B341675D9F7ABEEBF84C6@p3.JCK.COM> In-Reply-To: <049401c7615b$835ae980$c7d348d3@aabbeell> References: <03f301c7614d$e918a130$c7d348d3@aabbeell> <5dirdcchpo.fsf@Hurtta06k.keh.iki.fi> <049401c7615b$835ae980$c7d348d3@aabbeell> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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, 08 March, 2007 16:26 +0800 abel wrote: > Thanks for Kari comments, > These remind us to pay attention to more details in SPF and > DKIM Sorry, but let me suggest a different view, one that I think is important if anyone actually wants to finish this stage of the work. Please remember that we are many, many months behind our original schedule which was to have Experimental documents approved and in the publication queue before the end of last calendar year. The charter calls for us to worry about compatibility issues with the base email infrastructure. We originally thought about that in terms of what is covered by 2821 and 2822. It has been expanded to include DSNs, POP, IMAP, and consideration of mailing lists (the latter are covered in 2821 although very superficially). It does not specify compatibility with SPF, or DKIM, or any of several dozen activities and proposals for dealing with email or using it in unusual ways. The WG signed off on "framework". It discusses "systems or mechanisms that are dependent on digital signatures or similar integrity protection for mail headers" and mentions the need for DKIM and this work to _eventually_ consider each other" but explicitly indicates that this work will not "address or solve the issues" in Section 9 on Security Considerations. There is also a discussion of signed body parts and downgrading in Section 6.4 on "Encoded words, signed messages and downgrading" that concludes "...downgrading must be performed with extreme care if at all." I believe that, if we make smooth working of DKIM, SPF, etc., especially in systems that have not been upgraded to work with UTF8SMTP mail, a requirement for an acceptable downgrading solution that we will never find an acceptable downgrading solution. We actually know how to make systems like that work today (assuming they are upgraded to recognize our addresses) and that is to reject or bounce any message that contains their headers and would otherwise need to be downgraded. My instinct is that we are better off ignoring them, downgrading, and letting the final delivery system sort things out. Perhaps it would be wise to remove the SPF or DKIM headers entirely on downgrade instead, but advice on that option should come from those WGs --we should not be guessing here about what would cause the least damage in their various scenarios. But the bottom line, IMO, is that, if we are sincerely interested in getting this work done we ignore anything that is not in the Charter or critical to completing chartered work, at least until we get the Experimental documents finished. I believe that anyone considering bringing these issues up again on the mailing list should first ask him or herself whether the probable outcome of delaying, or even killing, this work is worth it... and whether he or she wants to take responsibility for that. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 08 11:00:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPL2k-00089t-0u; Thu, 08 Mar 2007 11:00:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPL2h-00089X-7s for ima@ietf.org; Thu, 08 Mar 2007 11:00:36 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPL2e-0002uU-PU for ima@ietf.org; Thu, 08 Mar 2007 11:00:35 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HPL2Q-0006oN-SS for ima@ietf.org; Thu, 08 Mar 2007 17:00:19 +0100 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Mar 2007 17:00:18 +0100 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Mar 2007 17:00:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 08 Mar 2007 17:59:54 +0200 Lines: 49 Message-ID: <5dmz2n7mkl.fsf@Hurtta06k.keh.iki.fi> References: <85DC516BD31D919531CC0463@[192.168.1.108]> <87F2B237E36CE025B401921E@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: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [EAI] Re: From Jari: Re: Your DISCUSS on draft-ietf-eai-framework-05 (fwd) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > On Thu, 08 Mar 2007 03:18:26 -0000, John C Klensin wrote: > > > > > As mentioned above, "mail storage agent" is not well-defined or > > formally part of the model > > > >> cannot safely assume that agents accessing email storage > > > > It is a little worse than that. It may use some protocol -- > > either LMTP or something that is not standardized in the IETF -- > > to deliver to the mail store. If the mail store, or the path to > > it, doesn't have UTF8SMTP capability, the delivery SMTP server > > is stuck. Worse, it may deliver messages to different > > addresses (mailboxes) into different message stores using > > different protocols. If some of them are fully capable of > > handling UTF-8 headers and message content, and some are not, it > > should probably advertise the options ... > > If a server advertises UTF8SMTP, then it is ofering a guarantee: > > "Either I will ensure that this messages is handed off, in exactly > the form received, to some user/mailbox/store/system/whatever that is > willing to offer essentially the same guarantee; > OR I will downgrade it before passing it to any > user/mailbox/store/system/whatever that cannot give that guarantee; > OR I will send it back up the Return-Path with an explanation that > it could not be delivered." > > This implies, to me, that even if there are internal communications > (LMPT, porocmail scripts, whatever) for routeing mail for different > local-parts through different channels, the MTA itself needs to be > configured with basic information as to which local-parts/channels > can offer the UTF8SMTP capability. Sounds like a case for a bit of > sendmail.cf hacking :-( . On stronger form that user/mailbox/store/system/whatever system is arranged that way that non UTF8SMTP agents no not see UTF8SMTP messages. For local delivery agent (LDA) that means that UTF8SMTP and ASCII messages are stored to different mailbox (files or directories or whatever). If communigation between MTA and LDA use LMTP no "sendmail.cf hacking" should be needed -- UTF8SMTP negation should work also with LMTP. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 08 11:55:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPLte-0004kC-Kf; Thu, 08 Mar 2007 11:55:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPLtc-0004hg-4R for ima@ietf.org; Thu, 08 Mar 2007 11:55:16 -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 1HPLob-0002rf-5J for ima@ietf.org; Thu, 08 Mar 2007 11:50:07 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HPLoU-0001dk-HY; Thu, 08 Mar 2007 11:49:58 -0500 Date: Thu, 08 Mar 2007 11:49:56 -0500 From: John C Klensin To: Kari Hurtta , Charles Lindsey , ima@ietf.org Subject: Re: [EAI] Re: From Jari: Re: Your DISCUSS on draft-ietf-eai-framework-05 (fwd) Message-ID: <644E4D36D257FC9403DDB139@p3.JCK.COM> In-Reply-To: <5dmz2n7mkl.fsf@Hurtta06k.keh.iki.fi> References: <85DC516BD31D919531CC0463@[192.168.1.108]> <87F2B237E36CE025B401921E@p3.JCK.COM> <5dmz2n7mkl.fsf@Hurtta06k.keh.iki.fi> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 08 March, 2007 17:59 +0200 Kari Hurtta wrote: > "Charles Lindsey" writes > in gmane.ietf.ima: > >> On Thu, 08 Mar 2007 03:18:26 -0000, John C Klensin >> wrote: >> >> > >> > As mentioned above, "mail storage agent" is not >> > well-defined or formally part of the model >> > >> >> cannot safely assume that agents accessing email storage >> > >> > It is a little worse than that. It may use some protocol -- >> > either LMTP or something that is not standardized in the >> >... >> If a server advertises UTF8SMTP, then it is ofering a >> guarantee: >> >> "Either I will ensure that this messages is handed off, >> in exactly the form received, to some >> user/mailbox/store/system/whatever that is willing to offer >> essentially the same guarantee; OR I will downgrade it before >> passing it to any >> user/mailbox/store/system/whatever that cannot give that >> guarantee; OR I will send it back up the Return-Path with an >> explanation that it could not be delivered." ok. But, for the case that Jari was concerned about, the second option is eliminated since it cannot be guaranteed that downgrading and subsequent reading by a legacy system will not lose any information. So the statement above is equivalent to "Unless I can pass the message into a mechanism or repository that guarantees full UTF8SMTP support, I must reject or return (bounce) it". For those of us who don't think highly of returning (bouncing) messages, that is in turn almost equivalent to: "If a delivery MTA cannot guarantee that it can deliver the message to an UTF8SMTP-capable system, it SHOULD NOT advertise the SMTP extension at all" I don't think one wants to go there, but they are certainly options that, if I were implementing such an MTA, I would make configurable. They are, after all, just another set of points in the tradeoffs between "deliver a message, even damaged, whenever possible" and "deliver only those messages whose integrity can be completely guaranteed". >> This implies, to me, that even if there are internal >> communications (LMPT, porocmail scripts, whatever) for >> routeing mail for different local-parts through different >> channels, the MTA itself needs to be configured with basic >> information as to which local-parts/channels can offer the >> UTF8SMTP capability. Sounds like a case for a bit of >> sendmail.cf hacking :-( . In the most general cases, the MTA can't possibly know enough. Worse, things can happen after "final delivery" over which the MTA has no control. For example, I would expect that, over time, mail stores would migrate from 7-bit-only to 8-bit-capable, not only in content and headers, but in keys, etc. I would not expect them to migrate the other way, but see no way to ban that. So, just as a given message in a mail store might be accessed by clients and user agents with a wide variety of different capabilities, there is no way for the MTA to know the behavior and capabilities, over time, of the message destination. > On stronger form that user/mailbox/store/system/whatever > system is arranged that way that non UTF8SMTP agents no not > see UTF8SMTP messages. By "not see" you mean, perhaps, "be told that they aren't there?", "be told that they are not in a readable format?". Note that we've already got provisions for the cases that do work in the IMAP and POP documents, but, if a message is delivered to a mail store or mechanism that is, itself, UTF8SMTP-capable, but that store is accessed with a legacy POP server, things may happen that are not predictable (since they depend a lot on how the mail store and POP server are implemented) or standardizable by this WG. > For local delivery agent (LDA) that means that UTF8SMTP and > ASCII messages are stored to different mailbox (files or > directories or whatever). One could implement it that way. One could also implement it in a variety of other ways. Note that, if I have a mailbox for which I have established several names (by aliasing or otherwise), some of which involve non-ASCII addresses, and that mailbox is fully UTF8SMTP-capable, I would consider the restriction implied by the above completely unacceptable. So I think you are talking about a whole series of implementation or configuration choices above. They are choices I think our specifications should permit (even when I think they would be dumb). But, unless one of you is actually suggesting standardizing something, I don't see where this discussion takes us. And, if you are suggesting standardizing something, let's see the I-D. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 08 13:17:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPNAg-0008Im-4w; Thu, 08 Mar 2007 13:16:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPNAf-0008Ig-Bp for ima@ietf.org; Thu, 08 Mar 2007 13:16:57 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPNAd-00046l-Sh for ima@ietf.org; Thu, 08 Mar 2007 13:16:57 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HPNAX-0001RV-40 for ima@ietf.org; Thu, 08 Mar 2007 19:16:49 +0100 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Mar 2007 19:16:49 +0100 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Mar 2007 19:16:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 08 Mar 2007 20:16:37 +0200 Lines: 75 Message-ID: <5dfy8fob22.fsf@Hurtta06k.keh.iki.fi> References: <85DC516BD31D919531CC0463@[192.168.1.108]> <87F2B237E36CE025B401921E@p3.JCK.COM> <5dmz2n7mkl.fsf@Hurtta06k.keh.iki.fi> <644E4D36D257FC9403DDB139@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: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [EAI] Re: From Jari: Re: Your DISCUSS on draft-ietf-eai-framework-05 (fwd) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin writes in gmane.ietf.ima: > >> This implies, to me, that even if there are internal > >> communications (LMPT, porocmail scripts, whatever) for > >> routeing mail for different local-parts through different > >> channels, the MTA itself needs to be configured with basic > >> information as to which local-parts/channels can offer the > >> UTF8SMTP capability. Sounds like a case for a bit of > >> sendmail.cf hacking :-( . > > In the most general cases, the MTA can't possibly know enough. > Worse, things can happen after "final delivery" over which the > MTA has no control. For example, I would expect that, over > time, mail stores would migrate from 7-bit-only to > 8-bit-capable, not only in content and headers, but in keys, > etc. I would not expect them to migrate the other way, but see > no way to ban that. So, just as a given message in a mail > store might be accessed by clients and user agents with a wide > variety of different capabilities, there is no way for the MTA > to know the behavior and capabilities, over time, of the message > destination. > > > On stronger form that user/mailbox/store/system/whatever > > system is arranged that way that non UTF8SMTP agents no not > > see UTF8SMTP messages. > > By "not see" you mean, perhaps, "be told that they aren't > there?", "be told that they are not in a readable format?". > Note that we've already got provisions for the cases that do > work in the IMAP and POP documents, but, if a message is > delivered to a mail store or mechanism that is, itself, > UTF8SMTP-capable, but that store is accessed with a legacy POP > server, things may happen that are not predictable (since they > depend a lot on how the mail store and POP server are > implemented) or standardizable by this WG. > > > For local delivery agent (LDA) that means that UTF8SMTP and > > ASCII messages are stored to different mailbox (files or > > directories or whatever). > > One could implement it that way. One could also implement it in > a variety of other ways. Note that, if I have a mailbox for > which I have established several names (by aliasing or > otherwise), some of which involve non-ASCII addresses, and that > mailbox is fully UTF8SMTP-capable, I would consider the > restriction implied by the above completely unacceptable. That means that when MUA is accesing directly (*) mailbox (files or directories) and do not known about UTF8SMTP, it does not not see UTF8SMTP messages, because it does not know from where to look them. UTF8SMTP cabable MAU can be programmed to look also from place where UTF8SMTP ares stored. For _user_ this is still one incoming mailbox. (*) "directly == via filesystem, not with POP or IMAP protocol" > So I think you are talking about a whole series of > implementation or configuration choices above. They are choices > I think our specifications should permit (even when I think they > would be dumb). But, unless one of you is actually suggesting > standardizing something, I don't see where this discussion takes > us. And, if you are suggesting standardizing something, let's > see the I-D. > > john Well, seems that there need something to be said about mailstores. Not actual implementation, but some requirements for them when interacting with UTF8SMTP. But I do not know yet, what these are. "Mailstore requirements for Email Address Internationalization (EAI)" ? / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 08 13:33:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPNR6-00071Q-Ms; Thu, 08 Mar 2007 13:33:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPNR5-00071L-S1 for ima@ietf.org; Thu, 08 Mar 2007 13:33:55 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPNR4-00076g-IM for ima@ietf.org; Thu, 08 Mar 2007 13:33:55 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HPNQw-0003FE-SS for ima@ietf.org; Thu, 08 Mar 2007 19:33:47 +0100 Received: from d253108.dialin.hansenet.de ([80.171.253.108]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Mar 2007 19:33:46 +0100 Received: from nobody by d253108.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Mar 2007 19:33:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Thu, 08 Mar 2007 19:32:44 +0100 Organization: Lines: 28 Message-ID: <45F056CC.30FE@xyzzy.claranet.de> References: <85DC516BD31D919531CC0463@[192.168.1.108]> <87F2B237E36CE025B401921E@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: d253108.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [EAI] Re: From Jari: Re: Your DISCUSS on draft-ietf-eai-framework-05 (fwd) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > If a server advertises UTF8SMTP, then it is ofering a guarantee: > "Either I will ensure that this messages is handed off, in exactly the > form received, to some user/mailbox/store/system/whatever that is willing > to offer essentially the same guarantee; > OR I will downgrade it before passing it to any > user/mailbox/store/system/whatever that cannot give that guarantee; > OR I will send it back up the Return-Path with an explanation that it > could not be delivered." Before picking the last exit it could also reject the mail at RCPT TO or DATA time. Bouncing to unverified Return-Paths is considered as net abuse today, the receiver would be blacklisted. Actually a tricky issue if MAIL FROM and RCPT TO are all-ASCII, and only the header indicates that the DATA is a message/utf-8. > the MTA itself needs to be configured with basic information as to which > local-parts/channels can offer the UTF8SMTP capability. Sounds like a > case for a bit of sendmail.cf hacking :-( . Really tricky. Minimally we've to explain the issue somewhere, probably in the SMTP draft. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 08 13:51:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPNha-0003Da-8Y; Thu, 08 Mar 2007 13:50:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPNhZ-0003DV-De for ima@ietf.org; Thu, 08 Mar 2007 13:50:57 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPNhY-00016n-35 for ima@ietf.org; Thu, 08 Mar 2007 13:50:57 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HPNhO-0004ta-Au for ima@ietf.org; Thu, 08 Mar 2007 19:50:46 +0100 Received: from d253108.dialin.hansenet.de ([80.171.253.108]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Mar 2007 19:50:46 +0100 Received: from nobody by d253108.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Mar 2007 19:50:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Thu, 08 Mar 2007 19:38:17 +0100 Organization: Lines: 33 Message-ID: <45F05819.129F@xyzzy.claranet.de> References: <03f301c7614d$e918a130$c7d348d3@aabbeell> 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: d253108.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [EAI] Re: SPF and DKIM X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org abel wrote: > Do we discuss those more ? For SPF I consider a separate draft. > A example in downgrading : >>>ehlo twnic.net.tw >>>mail from: ALT-ADDRESS=ASCII@gmail.com # EAI-aware >>>rcpt to: # non-EAI-aware > when the downgraded mail transmits , if other.domain run SPF check, we can > pass in SPF helo check ,but fail in SPF sender check (ascii@gmail.com) if > gmail.com SPF records with -all unless gmail.com adds SPF for us, > but it seems impossilbe to do that. Downgrading is actually the simple case. Of course using different policies for the UTF-8 address and the ALTADDRESS would be unwise (putting it mildly). A simple way to guarantee no nonsense is to use the same domain resulting in the same policy, e.g. MAIL FROM: ALT-ADDRESS=martin@xn--drst-Ora.example It starts to get more interesting without downgrading if the local part uses UTF-8, and the result has to be reported in a Received-SPF header field. And of course no SPF implementation already supports the IDNA magic to deal with internationalized domains, but in theory that's a solved problem (okay, I lurk on the IDNAbis list, s/theory/THEORY/ :-) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Mar 08 17:10:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPch-0003ss-7l; Thu, 08 Mar 2007 15:54:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPYt-0006tt-UT; Thu, 08 Mar 2007 15:50:07 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPPYt-0007cb-AH; Thu, 08 Mar 2007 15:50:07 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id D48DB26F10; Thu, 8 Mar 2007 20:50:05 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYq-0007Jh-Rs; Thu, 08 Mar 2007 15:50:04 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:04 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-downgrade-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Downgrading mechanism for Email Address Internationalization Author(s) : Y. Yoneya, K. Fujiwara Filename : draft-ietf-eai-downgrade-03.txt Pages : 18 Date : 2007-3-8 Traditional mail systems handle only US-ASCII characters in SMTP envelope and mail header fields. The Email Address Internationalization is implemented by allowing UTF-8 characters in SMTP envelope and mail header fields (UTF8SMTP). To deliver Non- ASCII mail address via UTF8SMTP non-compliant environment, some sort of converting mechanism (i.e. downgrading) is required. This document describes requirements for downgrading, SMTP downgrading, Email header downgrading and implementation consideration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-downgrade-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-downgrade-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-downgrade-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-8134705.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-downgrade-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-downgrade-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8134705.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 Fri Mar 09 04:27:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbNN-0002as-Hk; Fri, 09 Mar 2007 04:27:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPXGz-0004Yn-C5 for ima@ietf.org; Fri, 09 Mar 2007 00:04:09 -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 1HPXGw-0004Lb-3B for ima@ietf.org; Fri, 09 Mar 2007 00:04:08 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HPXGo-0003Gq-J0 for ima@ietf.org; Fri, 09 Mar 2007 06:03:58 +0100 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Mar 2007 06:03:58 +0100 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Mar 2007 06:03:58 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 09 Mar 2007 07:03:45 +0200 Lines: 33 Message-ID: <5dodn33t5a.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: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [EAI] "6. Email header Downgrading" (Re: I-D ACTION:draft-ietf-eai-downgrade-03.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Internet-Drafts@ietf.org writes in gmane.ietf.ima: > 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 : Downgrading mechanism for Email Address Internationalization > Author(s) : Y. Yoneya, K. Fujiwara > Filename : draft-ietf-eai-downgrade-03.txt > Pages : 18 > Date : 2007-3-8 > > Traditional mail systems handle only US-ASCII characters in SMTP > envelope and mail header fields. The Email Address > Internationalization is implemented by allowing UTF-8 characters in > SMTP envelope and mail header fields (UTF8SMTP). To deliver Non- > ASCII mail address via UTF8SMTP non-compliant environment, some sort > of converting mechanism (i.e. downgrading) is required. This > document describes requirements for downgrading, SMTP downgrading, > Email header downgrading and implementation consideration. | other headers: | All other headers which contains UTF-8 characters are preserved in | Downgraded: header and removed. Removing of MIME's Content-Type -header field produces incorrect result. Basically mime-type part (type/subtype) of that header-field must be preserved. Also following mime paramaters need to be preserved: charset and boundary These parameter values should be ASCII -only. Also type/subtype value should be ASCII -only. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Mar 09 04:27:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbNX-00035K-VC; Fri, 09 Mar 2007 04:27:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPXV6-0004Y3-RM for ima@ietf.org; Fri, 09 Mar 2007 00:18:44 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPXV4-0000Mn-Ga for ima@ietf.org; Fri, 09 Mar 2007 00:18:44 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HPXUz-0004by-2q for ima@ietf.org; Fri, 09 Mar 2007 06:18:37 +0100 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Mar 2007 06:18:37 +0100 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Mar 2007 06:18:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 09 Mar 2007 07:18:25 +0200 Lines: 39 Message-ID: <5dk5xr3sgu.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: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [EAI] "7. Upgrading downgraded header" (Re: I-D ACTION:draft-ietf-eai-downgrade-03.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Internet-Drafts@ietf.org writes in gmane.ietf.ima: > 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 : Downgrading mechanism for Email Address Internationalization > Author(s) : Y. Yoneya, K. Fujiwara > Filename : draft-ietf-eai-downgrade-03.txt > Pages : 18 > Date : 2007-3-8 > > Traditional mail systems handle only US-ASCII characters in SMTP > envelope and mail header fields. The Email Address > Internationalization is implemented by allowing UTF-8 characters in > SMTP envelope and mail header fields (UTF8SMTP). To deliver Non- > ASCII mail address via UTF8SMTP non-compliant environment, some sort > of converting mechanism (i.e. downgrading) is required. This > document describes requirements for downgrading, SMTP downgrading, > Email header downgrading and implementation consideration. | o If each mail header has [RFC2047] encoded part and which encoding | is "UTF-8", it may be a downgraded header, so decode it. That algorithm not necessary produce original result. But perhaps it is determined that sequence first downgrade and then upgrade does not need produce original result ? Because on downgrade only header field which was RFC2047 encodes was: | Subject: | Encode the header by [RFC2047] with UTF-8 tag and replace it. that upgrade rule can be: | o If Subject: header field has [RFC2047] encoded part and which encoding | is "UTF-8", it may be a downgraded header, so decode it. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Mar 09 04:28:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbPC-0005i6-L0; Fri, 09 Mar 2007 04:28:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPZmU-00018s-3z for ima@ietf.org; Fri, 09 Mar 2007 02:44:50 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPZmS-000796-QR for ima@ietf.org; Fri, 09 Mar 2007 02:44:50 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CEA042596C6; Fri, 9 Mar 2007 08:44:43 +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 23928-07; Fri, 9 Mar 2007 08:44:39 +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 DE09D2596C3; Fri, 9 Mar 2007 08:44:38 +0100 (CET) Message-ID: <45F11064.5070305@alvestrand.no> Date: Fri, 09 Mar 2007 08:44:36 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: abel Subject: Re: [EAI] Re: SPF and DKIM References: <03f301c7614d$e918a130$c7d348d3@aabbeell> <5dirdcchpo.fsf@Hurtta06k.keh.iki.fi> <049401c7615b$835ae980$c7d348d3@aabbeell> In-Reply-To: <049401c7615b$835ae980$c7d348d3@aabbeell> 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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 abel wrote: > Thanks for Kari comments, > These remind us to pay attention to more details in SPF and DKIM > > >> On general if you have >> ehlo twnic.net.tw >> mail from: ALT-ADDRESS=forwarder@gateway.example >> >> >> if gateway.example ia providing forwarding service, it practically >> can not provide SPF records -- not providing SPF records is part >> of service. >> > Yes, but users/clients dont know whether their provider has SPF record in > their ALT-ADDRESS, > If there are SPF in thoes domain include '-all' , that maybe cause their > mail to be rejected. > Mail adminstrator is hard to explains those issue to their clients. > I think the brutal answer is "don't do that". If you use an email address in an ALT-ADDRESS, that needs to be an email address controlled and managed by someone who's actively supporting UTF8SMTP - including mangling the SPF records (if any) to allow the gateways to send the messages as needed. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Mar 09 04:28:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbPG-0005ss-Fp; Fri, 09 Mar 2007 04:28:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPZnq-00036L-Pc for ima@ietf.org; Fri, 09 Mar 2007 02:46:14 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPZnp-0007SH-GK for ima@ietf.org; Fri, 09 Mar 2007 02:46:14 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id F21C22596C6; Fri, 9 Mar 2007 08:46:12 +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 23928-08; Fri, 9 Mar 2007 08:46:06 +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 28E072596C7; Fri, 9 Mar 2007 08:46:06 +0100 (CET) Message-ID: <45F110BB.2000705@alvestrand.no> Date: Fri, 09 Mar 2007 08:46:03 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] Re: SPF and DKIM References: <03f301c7614d$e918a130$c7d348d3@aabbeell> <45F05819.129F@xyzzy.claranet.de> In-Reply-To: <45F05819.129F@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: 08170828343bcf1325e4a0fb4584481c Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann wrote: > abel wrote: > > >> Do we discuss those more ? >> > > For SPF I consider a separate draft. > I think a separate draft is a Good Idea. As John said, consideration of such a draft isn't on the WG's agenda until the core specs are shipped for Experimental. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Mar 09 04:29:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbPO-00068H-Qc; Fri, 09 Mar 2007 04:29:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPZtC-0006tS-57 for ima@ietf.org; Fri, 09 Mar 2007 02:51:46 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPZt6-0008Hm-Ni for ima@ietf.org; Fri, 09 Mar 2007 02:51:46 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HPZsm-00037c-LZ for ima@ietf.org; Fri, 09 Mar 2007 08:51:20 +0100 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Mar 2007 08:51:20 +0100 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Mar 2007 08:51:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 09 Mar 2007 09:52:20 +0200 Lines: 65 Message-ID: <5dlki6c0qz.fsf_-_@leija.fmi.fi> References: <85DC516BD31D919531CC0463@[192.168.1.108]> <87F2B237E36CE025B401921E@p3.JCK.COM> <5dmz2n7mkl.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: b4a0a5f5992e2a4954405484e7717d8c Subject: [EAI] LMTP, mailstore (Re: From Jari: Re: Your DISCUSS on draft-ietf-eai-framework-05 (fwd)) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes in gmane.ietf.ima: <...> > > This implies, to me, that even if there are internal communications > > (LMPT, porocmail scripts, whatever) for routeing mail for different > > local-parts through different channels, the MTA itself needs to be > > configured with basic information as to which local-parts/channels > > can offer the UTF8SMTP capability. Sounds like a case for a bit of > > sendmail.cf hacking :-( . > > On stronger form that user/mailbox/store/system/whatever system > is arranged that way that non UTF8SMTP agents no not see UTF8SMTP > messages. > > For local delivery agent (LDA) that means that UTF8SMTP and ASCII messages > are stored to different mailbox (files or directories or whatever). > > If communigation between MTA and LDA use LMTP no "sendmail.cf hacking" > should be needed -- UTF8SMTP negation should work also with LMTP. I assume following model: +----------+ +----------+ | final | | | ----SMTP---> | MTA | ---LMTP----> | LDA | | | | | +----------+ +----------+ | | | | write \ / | (----------) ( mail- ) ( store ) (----------) | read MTA = Mail Transport Agent | LDA = Local Delivery Agent +----------+ MUA = Mail User Agent | | | MUA | | | +----------+ Actual there is one problem. There is no HDR=UTF8 flag on SMTP. Therefore LDA needs parse mail header fields, including mail header fields from mime parts. LDA need know which messages are UTF8SMTP, so that it can arrange them that way, that UTF8SMTP ignorant MUA do not see them. Normally LDA do not parse mail messages or header fields. Parsing of mail message on here is too much burder, I think. Therefore at least LMTP needs HDR=UTF8 paramater. ( I do not remember, have I posted message message, where I analyze when HDR=UTF8 is needed also on ESMTP. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Mar 09 08:32:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPfCD-0007yh-A3; Fri, 09 Mar 2007 08:31:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPfCC-0007yT-AA for ima@ietf.org; Fri, 09 Mar 2007 08:31:44 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPfBx-00043Q-W8 for ima@ietf.org; Fri, 09 Mar 2007 08:31:44 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 79FD12596C6 for ; Fri, 9 Mar 2007 14:31:26 +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 32632-04 for ; Fri, 9 Mar 2007 14:31:18 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E4D4D2596C3 for ; Fri, 9 Mar 2007 14:31:17 +0100 (CET) Message-ID: <45F161A5.2080404@alvestrand.no> Date: Fri, 09 Mar 2007 14:31:17 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: EAI WG 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: 4adaf050708fb13be3316a9eee889caa Subject: [EAI] DRAFT agenda, EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Due to the agenda deadline, this is already filed with the secretariat. But feel free to send suggestions for updates - the earlier we can bash the agenda, the better! Harald Date: TUESDAY, March 20, 2007 Time: 1520-1720 Afternoon Session II Place: Athens/Barcelona/Berlin room 1520: Welcome, scribe selection, agenda bashing 1530: Framework - review of IESG-response changes 1540: SMTP extension Issues: - Clarify need to not send UTF8 messages to non-UTF8SMTP hosts Draft: draft-ietf-eai-smtpext-04 1555: UTF8Headers Issues: Draft: draft-ietf-eai-utf8headers-03 1610: DSN Issues: - xtext encoding and utf8-enc encoding of addresses - application/utf8smtp vs message/utf8smtp Draft: draft-ietf-eai-dsn-00 1620: Downgrade Issues: Draft: draft-ietf-eai-downgrade-03 (not yet published) 1635: IMAP Issues: Draft: draft-ietf-eai-imap-utf8-01 1645: POP Issues: Draft: draft-ietf-eai-pop-01 1655: Mailinglist Issues: Draft: draft-ietf-eai-mailinglist-01 1710: Any Other Business draft-ietf-eai-scenarios: publish, or hold until end? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Mar 09 10:15:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPgoK-0008B9-Ps; Fri, 09 Mar 2007 10:15:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPgoI-000814-UJ for ima@ietf.org; Fri, 09 Mar 2007 10:15:11 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPgoB-0002uL-0k for ima@ietf.org; Fri, 09 Mar 2007 10:15:10 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HPgll-0007Q9-Ll for ima@ietf.org; Fri, 09 Mar 2007 16:12:34 +0100 Received: from d254164.dialin.hansenet.de ([80.171.254.164]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Mar 2007 16:12:33 +0100 Received: from nobody by d254164.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Mar 2007 16:12:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 09 Mar 2007 16:00:25 +0100 Organization: Lines: 44 Message-ID: <45F17689.1607@xyzzy.claranet.de> References: <45F161A5.2080404@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: d254164.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [EAI] Re: DRAFT agenda, EAI WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: > feel free to send suggestions for updates Are the times UTC ? > the earlier we can bash the agenda, the better! > 1610: DSN > Issues: > - xtext encoding and utf8-enc encoding of addresses > - application/utf8smtp vs message/utf8smtp > Draft: draft-ietf-eai-dsn-00 That's rather short for message/utf8. Ideally you get hold of John's "MIME experts", and let them explain how the introduction of a new message/utf8 superset of the known message/rfc822 affects the MIME 1.0 architecture for 8bit and 7bit. That includes message/rfc822 parts in a message/utf8, message/utf8 parts in a message/rfc822, and as contrast message/foo parts in a message/utf8 or message/rfc822. Each case as pure 7bit, pure 8bit, 7bit within 8bit, and the impossibilty of 8bit within 7bit - that case might be what you mean with an "application/utf8smtp". [[ I think it should also cover how to encapsulate 8bit message/foo parts by a "8to7" gateway, IMO a message/utf8 is a special case of message/foo wrt 8BITMIME to 7bit gateways. ]] Some here apparently hope to introduce UTF-8 in MIME header fields and MIME part headers. Ask the experts if that would require a MIME version 2.0 (as I think). 10 minutes, maybe five for the xtext encoding, with only five minutes you can't discuss this. And please give the invited (?) MIME experts some time to prepare for these issues. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Mar 09 11:36:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPi5L-0000yQ-NA; Fri, 09 Mar 2007 11:36:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPi5K-0000yH-Fm for ima@ietf.org; Fri, 09 Mar 2007 11:36:50 -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 1HPi52-0003O7-8A for ima@ietf.org; Fri, 09 Mar 2007 11:36:50 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HPi4w-000BZM-TN; Fri, 09 Mar 2007 11:36:27 -0500 Date: Fri, 09 Mar 2007 11:36:26 -0500 From: John C Klensin To: Harald Alvestrand , abel Subject: Re: [EAI] Re: SPF and DKIM Message-ID: <7BFFCF73400E96F6E0363E52@p3.JCK.COM> In-Reply-To: <45F11064.5070305@alvestrand.no> References: <03f301c7614d$e918a130$c7d348d3@aabbeell> <5dirdcchpo.fsf@Hurtta06k.keh.iki.fi> <049401c7615b$835ae980$c7d348d3@aabbeell> <45F11064.5070305@alvestrand.no> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Friday, 09 March, 2007 08:44 +0100 Harald Alvestrand wrote: >> Yes, but users/clients dont know whether their provider has >> SPF record in their ALT-ADDRESS, >> If there are SPF in thoes domain include '-all' , that maybe >> cause their mail to be rejected. >> Mail adminstrator is hard to explains those issue to their >> clients. >> > I think the brutal answer is "don't do that". > If you use an email address in an ALT-ADDRESS, that needs to > be an email address controlled and managed by someone who's > actively supporting UTF8SMTP - including mangling the SPF > records (if any) to allow the gateways to send the messages as > needed. I may be wrong, but I think that, in the overwhelming number of cases in which downgrade is actually plausible, Abel's analysis is going to turn out to be equivalent to "for a backward-pointing address, either (1) Use SPF without ALT-ADDRESS, thereby guaranteeing message rejection if a downgrade situation arises. (2) Use ALT-ADDRESS without SPF, thereby losing whatever benefits SPF is expected to convey but without the risk of an apparently-clear SPF rejection. (3) Use them together and just hope that, if downgrading occurs, it occurs with a domain context that is sufficiently permissive. And, again, if someone wants to put that, or other comments, into a separate document that is not on the WG's plate (or discussed on its mailing list), at least in the near term, I think that would be great. In particular it is a set of issues that such a document might usefully bring to the attention of the SPF community. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Mar 09 12:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPieU-0001z2-8S; Fri, 09 Mar 2007 12:13:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPieS-0001yx-Fw for ima@ietf.org; Fri, 09 Mar 2007 12:13:08 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPieN-00036q-UK for ima@ietf.org; Fri, 09 Mar 2007 12:13:08 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3&clerew^man&ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45f1959c.d4a6.f10 for ima@ietf.org; Fri, 9 Mar 2007 17:13:00 +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 l29HCt0V014972 for ; Fri, 9 Mar 2007 17:12:56 GMT To: IMA Subject: Re: [EAI] Re: From Jari: Re: Your DISCUSS on draft-ietf-eai-framework-05 (fwd) References: <85DC516BD31D919531CC0463@[192.168.1.108]> <87F2B237E36CE025B401921E@p3.JCK.COM> <5dmz2n7mkl.fsf@Hurtta06k.keh.iki.fi> <644E4D36D257FC9403DDB139@p3.JCK.COM> Message-ID: Date: Fri, 09 Mar 2007 17:12:55 -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: <644E4D36D257FC9403DDB139@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) 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 On Thu, 08 Mar 2007 16:49:56 -0000, John C Klensin wrote: > --On Thursday, 08 March, 2007 17:59 +0200 Kari Hurtta > wrote: > >> "Charles Lindsey" writes >> in gmane.ietf.ima: >>> If a server advertises UTF8SMTP, then it is ofering a >>> guarantee: >>> >>> "Either I will ensure that this messages is handed off, >>> in exactly the form received, to some >>> user/mailbox/store/system/whatever that is willing to offer >>> essentially the same guarantee; OR I will downgrade it before >>> passing it to any >>> user/mailbox/store/system/whatever that cannot give that >>> guarantee; OR I will send it back up the Return-Path with an >>> explanation that it could not be delivered." > > ok. But, for the case that Jari was concerned about, the second > option is eliminated since it cannot be guaranteed that > downgrading and subsequent reading by a legacy system will not > lose any information. I don't see that. We have carefully defined the downgrading process so that downgraded headers get replaced by a Downgraded: : . So we now have a valid ASCII email, but no information has actually been lost (though it might be inconvenient to extract it). So, so long as downgraders between the MDA and the actual mailboxes stick to our 'downgrade' draft, everything should be OK. -- 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 Mar 09 12:16:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPihA-0004Mo-CW; Fri, 09 Mar 2007 12:15:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPih9-0004Mc-UK for ima@ietf.org; Fri, 09 Mar 2007 12:15:55 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPih6-0003Qt-TW for ima@ietf.org; Fri, 09 Mar 2007 12:15:55 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3#clerew^man$ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45f19647.12575.65 for ima@ietf.org; Fri, 9 Mar 2007 17:15:51 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l29HFocl015310 for ; Fri, 9 Mar 2007 17:15:51 GMT To: IMA Subject: Re: [EAI] "6. Email header Downgrading" (Re: I-D ACTION:draft-ietf-eai-downgrade-03.txt) References: <5dodn33t5a.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Fri, 09 Mar 2007 17:15:49 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5dodn33t5a.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 09 Mar 2007 05:03:45 -0000, Kari Hurtta wrote: > | other headers: > | All other headers which contains UTF-8 characters are preserved in > | Downgraded: header and removed. > > Removing of MIME's Content-Type -header field produces incorrect result. > > Basically mime-type part (type/subtype) of that header-field must be > preserved. > Also following mime paramaters need to be preserved: charset and boundary > These parameter values should be ASCII -only. Also type/subtype value > should be ASCII -only. Which just leaves possible s with UTF-8 in theor s. We should define that these are to be downgraded using RFC 2231. -- 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 Mar 09 12:19:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPik9-00080I-Ki; Fri, 09 Mar 2007 12:19:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPik8-00080D-Jc for ima@ietf.org; Fri, 09 Mar 2007 12:19:00 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPik7-0004Lb-2R for ima@ietf.org; Fri, 09 Mar 2007 12:19:00 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3*clerew$man*ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45f19702.ba94.499 for ima@ietf.org; Fri, 9 Mar 2007 17:18:58 +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 l29HIv6D015497 for ; Fri, 9 Mar 2007 17:18:57 GMT Date: Fri, 09 Mar 2007 17:18:56 -0000 To: IMA Subject: Re: [EAI] "7. Upgrading downgraded header" (Re: I-D ACTION:draft-ietf-eai-downgrade-03.txt) References: <5dk5xr3sgu.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: <5dk5xr3sgu.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 09 Mar 2007 05:18:25 -0000, Kari Hurtta wrote: > Internet-Drafts@ietf.org writes in gmane.ietf.ima: > >> 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 : Downgrading mechanism for Email Address Internationalization >> Author(s) : Y. Yoneya, K. Fujiwara >> Filename : draft-ietf-eai-downgrade-03.txt >> Pages : 18 >> Date : 2007-3-8 >> >> Traditional mail systems handle only US-ASCII characters in SMTP >> envelope and mail header fields. The Email Address >> Internationalization is implemented by allowing UTF-8 characters in >> SMTP envelope and mail header fields (UTF8SMTP). To deliver Non- >> ASCII mail address via UTF8SMTP non-compliant environment, some sort >> of converting mechanism (i.e. downgrading) is required. This >> document describes requirements for downgrading, SMTP downgrading, >> Email header downgrading and implementation consideration. > > | o If each mail header has [RFC2047] encoded part and which encoding > | is "UTF-8", it may be a downgraded header, so decode it. > > That algorithm not necessary produce original result. What differences can arise? I can see that folding may get changed, and whitespace may get mucked about, but is there anything else? Changes of folding should be acceptable (and will even lead to correct DKIM signature interpretation is the 'relaxed' canonicalization is used). -- 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 Mar 09 12:36:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPj1D-0008E6-BI; Fri, 09 Mar 2007 12:36:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPj1C-0008CO-TR for ima@ietf.org; Fri, 09 Mar 2007 12:36:38 -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 1HPj17-0006V8-JO for ima@ietf.org; Fri, 09 Mar 2007 12:36:38 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HPj12-0003vp-E0 for ima@ietf.org; Fri, 09 Mar 2007 18:36:28 +0100 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Mar 2007 18:36:28 +0100 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Mar 2007 18:36:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 09 Mar 2007 19:36:10 +0200 Lines: 28 Message-ID: <5dps7inwtx.fsf@Hurtta06k.keh.iki.fi> References: <5dk5xr3sgu.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [EAI] Re: "7. Upgrading downgraded header" (Re: I-D ACTION:draft-ietf-eai-downgrade-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 "Charles Lindsey" writes in gmane.ietf.ima: > On Fri, 09 Mar 2007 05:18:25 -0000, Kari Hurtta > wrote: > > > | o If each mail header has [RFC2047] encoded part and which encoding > > | is "UTF-8", it may be a downgraded header, so decode it. > > > > That algorithm not necessary produce original result. > > What differences can arise? I can see that folding may get changed, > and whitespace may get mucked about, but is there anything else? > > Changes of folding should be acceptable (and will even lead to correct > DKIM signature interpretation is the 'relaxed' canonicalization is > used). Also header field is not necessarly downgraded header field. > -- > Charles H. Lindsey ---------At Home, doing my own thing------------------------ > Tel: +44 161 436 6131  >    Web: http://www.cs.man.ac.uk/~chl > Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. > PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Mar 09 13:22:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPjjE-0001j2-9P; Fri, 09 Mar 2007 13:22:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPjjA-0001ho-ES for ima@ietf.org; Fri, 09 Mar 2007 13:22:04 -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 1HPjj8-0006r0-OZ for ima@ietf.org; Fri, 09 Mar 2007 13:22:04 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HPjie-0003v0-KS for ima@ietf.org; Fri, 09 Mar 2007 19:21:32 +0100 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Mar 2007 19:21:32 +0100 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Mar 2007 19:21:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 09 Mar 2007 20:21:11 +0200 Lines: 48 Message-ID: <5dfy8enuqw.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: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [EAI] Message-ID (Re: I-D ACTION:draft-ietf-eai-downgrade-03.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Internet-Drafts@ietf.org writes in gmane.ietf.ima: > 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 : Downgrading mechanism for Email Address Internationalization > Author(s) : Y. Yoneya, K. Fujiwara > Filename : draft-ietf-eai-downgrade-03.txt > Pages : 18 > Date : 2007-3-8 > > Traditional mail systems handle only US-ASCII characters in SMTP > envelope and mail header fields. The Email Address > Internationalization is implemented by allowing UTF-8 characters in > SMTP envelope and mail header fields (UTF8SMTP). To deliver Non- > ASCII mail address via UTF8SMTP non-compliant environment, some sort > of converting mechanism (i.e. downgrading) is required. This > document describes requirements for downgrading, SMTP downgrading, > Email header downgrading and implementation consideration. chaprer "6. Email header Downgrading" | Message-ID:, Date:, In-Reply-To: | "ID"s and "Date"s does not contain UTF-8 characters. RFC 2822: message-id = "Message-ID:" msg-id CRLF msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] CFWS = *([FWS] comment) (([FWS] comment) / FWS) draft-ietf-eai-utf8headers-03.txt: comment = "(" *([FWS] utf8-ccontent) [FWS] ")" So I'm not completely sure that Message-ID: -header field does not contain UTF-8 characters. Same apply also to Date -header field. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Mar 09 13:25:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPjmg-0003Zs-0J; Fri, 09 Mar 2007 13:25:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPjmf-0003Zm-9a for ima@ietf.org; Fri, 09 Mar 2007 13:25:41 -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 1HPjmY-0007b4-2b for ima@ietf.org; Fri, 09 Mar 2007 13:25:41 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HPjm2-0004lJ-Vu for ima@ietf.org; Fri, 09 Mar 2007 19:25:03 +0100 Received: from cs130027.pp.htv.fi ([213.243.130.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Mar 2007 19:25:02 +0100 Received: from hurtta+gmane by cs130027.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Mar 2007 19:25:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Date: 09 Mar 2007 20:23:36 +0200 Lines: 41 Message-ID: <5dbqj2numv.fsf@Hurtta06k.keh.iki.fi> References: <5dodn33t5a.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs130027.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [EAI] Re: "6. Email header Downgrading" (Re: I-D ACTION:draft-ietf-eai-downgrade-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 "Charles Lindsey" writes in gmane.ietf.ima: > On Fri, 09 Mar 2007 05:03:45 -0000, Kari Hurtta > wrote: > > > > | other headers: > > | All other headers which contains UTF-8 characters are preserved in > > | Downgraded: header and removed. > > > > Removing of MIME's Content-Type -header field produces incorrect result. > > > > Basically mime-type part (type/subtype) of that header-field must be > > preserved. > > Also following mime paramaters need to be preserved: charset and boundary > > These parameter values should be ASCII -only. Also type/subtype value > > should be ASCII -only. > > Which just leaves possible s with UTF-8 in theor > s. We should define that these are to be downgraded using RFC > 2231. And do not forget comments. draft-ietf-eai-utf8headers-03.txt: | comment = "(" *([FWS] utf8-ccontent) [FWS] ")" | | word = utf8-atom / utf8-quoted-string | | This means that all the RFC 2822 constructs that build upon these | will permit UTF-8 characters, including comments and quoted strings. > -- > 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 Sat Mar 10 11:26:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ4Nu-0001Is-O5; Sat, 10 Mar 2007 11:25:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQ4Ns-0001If-P5 for ima@ietf.org; Sat, 10 Mar 2007 11:25:28 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQ4Nr-0002bf-Fy for ima@ietf.org; Sat, 10 Mar 2007 11:25:28 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HQ4Nc-0000YA-48 for ima@ietf.org; Sat, 10 Mar 2007 17:25:12 +0100 Received: from du-001-169.access.de.clara.net ([212.82.227.169]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Mar 2007 17:25:12 +0100 Received: from nobody by du-001-169.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Mar 2007 17:25:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 10 Mar 2007 17:21:40 +0100 Organization: Lines: 31 Message-ID: <45F2DB14.5B7A@xyzzy.claranet.de> References: <5dfy8enuqw.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-169.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [EAI] Re: Message-ID X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta wrote: > chapter "6. Email header Downgrading" > | Message-ID:, Date:, In-Reply-To: > | "ID"s and "Date"s does not contain UTF-8 characters. Yeah, there are tons of [CFWS] in 2822, and the "C" is for . Proposed fix: - Message-ID:, Date:, In-Reply-To: - "ID"s and "Date"s does not contain UTF-8 characters. + In-Reply-To:, Message-ID:, References:, Resent-Message-ID: + RFC 2822 s don't contain UTF-8 characters. + Date:, Resent-Date: + RFC 2822 , , and