From alexey.melnikov@isode.com Tue Aug 4 04:55:36 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6C0528C39A for ; Tue, 4 Aug 2009 04:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOTlQ8SGgwnh for ; Tue, 4 Aug 2009 04:55:35 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 088FF28C396 for ; Tue, 4 Aug 2009 04:55:34 -0700 (PDT) Received: from [94.197.204.149] (94.197.204.149.threembb.co.uk [94.197.204.149]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 4 Aug 2009 12:55:30 +0100 Message-ID: <4A78218E.90608@isode.com> Date: Tue, 04 Aug 2009 12:54:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "ima@ietf.org" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------020202040903000703030503" Subject: [EAI] [Fwd: AD review of draft-duerst-mailto-bis-06.txt] X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 11:55:36 -0000 This is a multi-part message in MIME format. --------------020202040903000703030503 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I believe I completed the todo item assigned to me during the Stockholm meeting. --------------020202040903000703030503 Content-Type: message/rfc822; name="AD review of draft-duerst-mailto-bis-06.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="AD review of draft-duerst-mailto-bis-06.txt" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine (Isode M-Box/14.4v1) with LMTP; Tue, 04 Aug 2009 12:50:15 +0100 (BST) Received: from [94.197.204.149] (94.197.204.149.threembb.co.uk [94.197.204.149]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 4 Aug 2009 12:50:13 +0100 Message-ID: <4A78205A.3020605@isode.com> Date: Tue, 04 Aug 2009 12:49:46 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , Larry Masinter CC: Jamie Zawinski Subject: AD review of draft-duerst-mailto-bis-06.txt MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, The EAI WG tasked me to review this document, as it seems to be blocking some EAI drafts. In Section 2: addr-spec = local-part "@" domain local-part = dot-atom / quoted-string I don't think this change goes all the way to clarify that obsolete RFC 5322 syntax and comments are disallowed. RFC 5322: domain = dot-atom / domain-literal / obs-domain domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS] dot-atom-text = 1*atext *("." 1*atext) dot-atom = [CFWS] dot-atom-text [CFWS] atom = [CFWS] 1*atext [CFWS] obs-domain = atom *("." atom) I think "obs-domain" and "domain-literal" definitions are problematic (at least). Within 'mailto' URIs, the characters "?", "=", and "&" are reserved. "Reserved" in URI sense? If yes, I think this can be made clearer. 4. Percent-encoding can be used in the part of an , in order to denote an internationalized domain name. The considerations for in [STD66] apply. In particular, non-ASCII characters must s/must/MUST ? first be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence must s/must/MUST ? be percent-encoded to be represented as URI characters. URI producing applications must not s/must not/MUST NOT ? use percent-encoding in domain names unless it is used to represent a UTF-8 character sequence. When the internationalized domain name is used to compose a message, the name must be transformed to the IDNA encoding where appropriate [RFC3490]. URI producers should provide these domain names in the IDNA encoding, rather than percent-encoded, if they wish to maximize interoperability with legacy 'mailto' URI interpreters. As per IRI bar BOF in Stockholm: this needs to be aligned with any [potential] changes to the IRI spec. 5. Percent-encoding of non-ASCII octets in the of an is reserved for the internationalization of the . Non-ASCII characters must s/must/MUST ? first be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence must s/must/MUST ? be percent-encoded to be represented as URI characters. Any other percent-encoding of non-ASCII characters is prohibited. When a containing non-ASCII characters will be used to compose a message, the must s/must/MUST ? be transformed to conform to whatever encoding may be defined in a future specification for the internationalization of email addresses. [...] Non-ASCII characters can be encoded in hfvalue as follows: [...] 2. Non-ASCII characters can be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence is percent-encoded to be represented as URI characters. When header field values encoded in this way are used to compose a message, the must s/must/MUST ? be transformed into MIME encoded words [RFC2047], except for an of a "body" , which has to be encoded according to [RFC2045]. Please note that for MIME encoded words and for bodies in composed email messages, encodings other than UTF-8 MAY be used as long as the characters are properly transcoded. [...] MIME encoded words and UTF-8-based percent-encoding SHOULD NOT both be used sequentially in the same , and MUST NOT be combined. Can you clarify what you are trying to say here? In particular I am not clear on the meaning of "sequentially" here. In Section 3: In current practice, resolving URIs such as those in the 'http' URI scheme causes an immediate interaction between client software and a host running an interactive server. The 'mailto' URI has unusual semantics because resolving such a URI does not cause an immediate interaction. Instead, the client creates a message to the designated address with the various header fields set as default. The user can edit the message, send this message unedited, or choose not to send the message. The operation of how any URI scheme is resolved is not mandated by the URI specifications. The last sentence doesn't seem to be related to the rest of the paragraph. Should it be deleted or moved to a separate paragraph? In Section 4: The creator of a 'mailto' URI cannot expect the resolver of a URI to understand more than the "subject" header field and "body". What about the "To" header field? Clients that resolve 'mailto' URIs into mail messages MUST be able to correctly create [RFC5322]-compliant mail messages using the "subject" header field and "body". In Section 8: A 'mailto' URI gives a template for a message that can be sent by mail client software. The contents of that template may be opaque or difficult to read by the user at the time of specifying the URI. Thus, a mail client should never send a message based on a 'mailto' s/should/SHOULD ? URI without first showing the full message that will be sent to the user (including all header fields that were specified by the 'mailto' URI), fully decoded, and asking the user for approval to send the message as electronic mail. The mail client should also make it s/should/SHOULD clear that the user is about to send an electronic mail message, since the user may not be aware that this is the result of a 'mailto' URI. A mail client should never send anything without complete disclosure s/should/SHOULD to the user of what will be sent; it should disclose not only the s/should/SHOULD message destination, but also any header fields. Unrecognized header fields, or header fields with values inconsistent with those the mail client would normally send should be especially suspect. MIME header fields (MIME- Version, Content-*) are most likely inappropriate, except when added by the MUA to correctly encode the text(s) being sent, as are those relating to routing (From, Apparently-To, etc.) 9. IANA Considerations This document changes the definition of the 'mailto' URI scheme; the registry of URI schemes needs to be updated to refer to this document rather than its predecessor, [RFC2368]. It doesn't look like the proper URI registration template was ever specified in this document or its predecessor. --------------020202040903000703030503-- From edainow@ca.afilias.info Tue Aug 4 08:26:11 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C747E3A68DC for ; Tue, 4 Aug 2009 08:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIhzZz7Wj2SG for ; Tue, 4 Aug 2009 08:26:10 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id CD0C328C3E9 for ; Tue, 4 Aug 2009 08:26:10 -0700 (PDT) Message-ID: <4A7852F2.6010506@ca.afilias.info> Date: Tue, 04 Aug 2009 11:25:38 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.6 (Windows/20080710) MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Subject: [EAI] Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 15:26:11 -0000 I think there are a number of things we can change to make Downgrade simpler and have less impact on existing email systems yet still provide the key backward compatibility that many people feel is important to the success of EAI. The current design of Downgrade is very comprehensive. A lot of clever things were done to provide Downgrade in every possible situation and to provide a complete audit trail through the use of new Downgraded headers that also provide the ability to reconstruct the original UTF8 address information (Downgraded display). We can greatly simplify Downgrade by limiting the design goals to support only essential cases and make clear that Downgrade is an interim feature, is not perfect and does not provide a complete audit trail. 1. As recommended in 4.2 of draft-ietf-eai-email-clients and in various emails on the EAI list, we should consider downgrade of forward-pointing (recipient) addresses as a configuration error and not something that Downgrade needs to support. Then we can remove Alternate Addresses for recipients. I think this would also allow us to redesign Downgrade without the double angle bracket syntax which seems to be the source of a lot of compatibility and security concerns. 2. Implementation of Downgrade is currently an option for MUA, POP/IMAP. Consideration of these cases in draft-ietf-eai-email-clients (3.1.1, 3.2) is that these are unusual configurations. The standard should be explicit and state that Downgrade is only done by MTAs. 3. While an audit trail and ability to display original UTF8 addresses from a Downgraded message is a nice feature, some people consider the case in which this is useful to be a configuration error (an EAI MUA, POP or IMAP behind a non-EAI MTA.). In any case, it is not an essential feature within the revised design goals outlined above. If it is dropped, then all the added "Downgraded-" headers can be dropped. 4. Alternate Addresses for the sender can be handled in the "Accounts" setting of the MUA. They can also be provided by the SMTP server, as in draft-yao-eai-deployment. Since there is no interface for the MUA to find out from the server if it needs to provide Alternate Addresses or not, this ambiguity may lead to unexpected behavior in terms of which Alternate Address gets used if it is provided by both. While the server solution offers a certain amount of transparency to the end user, the MUA solution is more general in that it supports a legacy ASCII Address that may be on a different email provider. The standard should resolve this ambiguity and specify that Alternate Address for the sender is provided by the MUA and not the server. 5. Capturing UTF8 addresses in empty groups when Downgrading should be dropped. This has numerous interoperability problems with existing mail clients (3.2.1 in draft-ietf-eai-email-clients). To make a clean line between Downgrade and the rest of the EAI standard, so that we can move ahead with standards track of the latter while continuing to work on experimental track Downgrade, all normative requirements relating to Downgrade should be pulled out of the EAI documents and moved into the Downgrade document. So for example, the ALT-ADDRESS parameter should be moved from RFC 5336 to the Downgrade document and the addr-spec for double angle brackets moved out of RFC 5335 into the Downgrade doc (or dropped if 1. above can be achieved). -Ernie Dainow From Shawn.Steele@microsoft.com Wed Aug 5 00:27:47 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281673A70D5 for ; Wed, 5 Aug 2009 00:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.994 X-Spam-Level: X-Spam-Status: No, score=-9.994 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqJnE8x2FNkU for ; Wed, 5 Aug 2009 00:27:46 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 66E023A6A1E for ; Wed, 5 Aug 2009 00:27:46 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 5 Aug 2009 00:27:49 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.232]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi; Wed, 5 Aug 2009 00:27:49 -0700 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: mailto: Thread-Index: AQHKFZ47dyC7C3nvDEyxS+cBz13q1g== Date: Wed, 5 Aug 2009 07:23:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 07:27:47 -0000 I'm out of the office and didn't have network access. Specifically I meant that I don't think the <> downgrade syntax is helpful = in mailto: since nobody's enabled by it and anyone that was updated to unde= rstand the <> in mailto: wouldn't need the downgrade for mailto:. In downgraded headers <> could be interesting, except as mentioned earlier = that there are few scenarios where downgraded headers are actually round-tr= ipped an made use of. -Shawn Message: 4 Date: Mon, 27 Jul 2009 11:47:39 +0100 From: "Charles Lindsey" Subject: Re: [EAI] mailto: was RE: Rechartering To: IMA Message-ID: Content-Type: text/plain; format=3Dflowed; delsp=3Dyes; charset=3Diso-8859-= 1 On Fri, 24 Jul 2009 05:48:35 +0100, Shawn Steele wrote: > I actually find the < > downgrade syntax fairly unlikely to be helpful. > Presumably your mail server understands the complete EAI syntax since > you're providing both addresses. Likewise my client knows about EAI if > it understands >. So pretty much the only place that > > is going to gain anything is when my mail server is > not EAI aware, but my client and your server are EAI aware. It seems > more likely to me that my server and client would both be EAI aware. > So, to me, the most likely scenarios would be when some in-between relay > wasn't EAI aware, yet any such sender or receiver side relay would > necessarily be EAI aware. Relays that aren't tightly coupled with the > sender/receiver side tend to be blacklisted anyway. > But the in-between server has no business looking at the headers inside > the message, so it should not care is they contain To: <...<...>>. The From klensin@jck.com Wed Aug 5 01:34:43 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2311C3A6F0A for ; Wed, 5 Aug 2009 01:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WzPGut8x1uc for ; Wed, 5 Aug 2009 01:34:42 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 0DE5A28C519 for ; Wed, 5 Aug 2009 01:33:48 -0700 (PDT) Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1MYbwS-0008QS-Ly; Wed, 05 Aug 2009 04:33:49 -0400 Date: Wed, 05 Aug 2009 04:33:47 -0400 From: John C Klensin To: Shawn Steele , ima@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 08:34:43 -0000 --On Wednesday, 05 August, 2009 07:23 +0000 Shawn Steele wrote: >... > Specifically I meant that I don't think the <> downgrade > syntax is helpful in mailto: since nobody's enabled by it and > anyone that was updated to understand the <> in mailto: > wouldn't need the downgrade for mailto:. I think this (your observation and that from Charles) is a corollary of some growing concern about forward-pointing addresses and downgrade... see Ernie's recent note. I also observe that, for mailto, there is an already-deployed alternative for two-address mailto. We see it all the time in messages and text, usually as mailto:foo@example.com or mailto:bar@example.org or even mailto:foo@example.com (preferred) or mailto:bar@example.org if one of them contains non-ASCII elements, e.g., mailto:non-ASCII-local-part@IDN-example.com or mailto:bar@example.org nothing is lost and some small bits are gained. That also suggests a way to do forward-pointing robustness on an individual message basis. Again, it is an extension of something common. Suppose I have two addresses for you, Shawn.Steele@microsoft.com and a hotmail address, shawnsteele3@hotmail.com (I am obviously just making up the second). I know you are taking some vacation, I want to be sure to reach you, but I don't know which one you are most likely to read and don't even know if you are still maintaining the hypothetical hotmail account. To maximize the odds of something getting through, I send the message to one address, copying the other. If one message gets through and the other bounces, no problem. The worst case is that you get two copies and I apologize later. On that model, the header syntax for forward-pointing alternate addresses (without all of the complications of downgrading) is To; Shawn.Steele@microsoft.com cc: shawnsteele3@hotmail.com The EAI alternative is obvious. What disappears is the complexity of downgrading those addresses, the security and other concerns about linked alternative addresses (the linkage here is entirely in the mind of the sender) and the need to change infrastructure -- not only the <... <...>> form, but address book formats, message store formats, etc.-- to accommodate the formal alternate addresses. > In downgraded headers <> could be interesting, except as > mentioned earlier that there are few scenarios where > downgraded headers are actually round-tripped an made use of. Yep. john From fujiwara@jprs.co.jp Wed Aug 5 02:07:36 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13E528C526 for ; Wed, 5 Aug 2009 02:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qc8wuNbxlbPy for ; Wed, 5 Aug 2009 02:07:36 -0700 (PDT) Received: from send11.jprs.co.jp (send11.jprs.co.jp [202.11.17.110]) by core3.amsl.com (Postfix) with ESMTP id 1DB493A711B for ; Wed, 5 Aug 2009 02:07:35 -0700 (PDT) Received: from sendsms11.jprs.co.jp (sendsms11.jprs.co.jp [202.11.17.111]) by send11.jprs.co.jp (8.13.8+Sun/8.13.8) with ESMTP id n7597Y0e025957; Wed, 5 Aug 2009 18:07:34 +0900 (JST) Received: from sendsms11.jprs.co.jp (unknown [127.0.0.1]) by sendsms11.jprs.co.jp (Symantec Mail Security) with ESMTP id D93BA3500; Wed, 5 Aug 2009 18:07:34 +0900 (JST) X-AuditID: ca0b116f-0000000b00004758-10-4a794bd622f1 Date: Wed, 05 Aug 2009 18:07:34 +0900 (JST) Message-Id: <20090805.180734.104051535.fujiwara@jprs.co.jp> To: klensin@jck.com From: fujiwara@jprs.co.jp In-Reply-To: References: X-Mailer: Mew version 6.1 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Shawn.Steele@microsoft.com, ima@ietf.org Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 09:07:37 -0000 > From: John C Klensin > if one of them contains non-ASCII elements, e.g., > > mailto:non-ASCII-local-part@IDN-example.com or > mailto:bar@example.org > > nothing is lost and some small bits are gained. > I think this method is easy and enough. But I have an another idea to add new option for the mailto. Regards, -- Kazunori Fujiwara, JPRS From alexey.melnikov@isode.com Wed Aug 5 02:38:17 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0D53A7196 for ; Wed, 5 Aug 2009 02:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8skU2k2+H5wW for ; Wed, 5 Aug 2009 02:38:17 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C53573A71B4 for ; Wed, 5 Aug 2009 02:38:16 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 5 Aug 2009 10:37:13 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4A7952B5.3020300@isode.com> Date: Wed, 05 Aug 2009 10:36:53 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: fujiwara@jprs.co.jp References: <20090805.180734.104051535.fujiwara@jprs.co.jp> In-Reply-To: <20090805.180734.104051535.fujiwara@jprs.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Shawn.Steele@microsoft.com, ima@ietf.org Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 09:38:17 -0000 fujiwara@jprs.co.jp wrote: >>From: John C Klensin >>if one of them contains non-ASCII elements, e.g., >> >> mailto:non-ASCII-local-part@IDN-example.com or >> mailto:bar@example.org >> >>nothing is lost and some small bits are gained. >> >> >I think this method is easy and enough. > >But I have an another idea to add new option for the mailto. > > > > That would work as well. From alexey.melnikov@isode.com Wed Aug 5 02:41:54 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F55B28C530 for ; Wed, 5 Aug 2009 02:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P02LiZU5N9dO for ; Wed, 5 Aug 2009 02:41:53 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 35E4628C551 for ; Wed, 5 Aug 2009 02:41:52 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 5 Aug 2009 10:41:41 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4A7953C6.6070005@isode.com> Date: Wed, 05 Aug 2009 10:41:26 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ima@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [EAI] Use of mailto: with EAI addresses X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 09:41:54 -0000 I vaguely remember that there was a decision last year to design a separate URI scheme (similar to mailto:) for use with EAI addresses. Is this no longer the direction the WG wants to take? From klensin@jck.com Wed Aug 5 06:31:47 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F8F3A6781 for ; Wed, 5 Aug 2009 06:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4EGxoFXAOF0 for ; Wed, 5 Aug 2009 06:31:46 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 84AE13A680B for ; Wed, 5 Aug 2009 06:31:46 -0700 (PDT) Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1MYgap-000DIz-4q; Wed, 05 Aug 2009 09:31:47 -0400 Date: Wed, 05 Aug 2009 09:31:46 -0400 From: John C Klensin To: Alexey Melnikov , ima@ietf.org Message-ID: <56ADA3078807DFBB6AC880E8@p3.int.jck.com> In-Reply-To: <4A7953C6.6070005@isode.com> References: <4A7953C6.6070005@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Use of mailto: with EAI addresses X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 13:31:47 -0000 --On Wednesday, 05 August, 2009 10:41 +0100 Alexey Melnikov wrote: > I vaguely remember that there was a decision last year to > design a separate URI scheme (similar to mailto:) for use with > EAI addresses. Is this no longer the direction the WG wants to > take? I think your recollection is correct. The advantage of that plan is that it does not result in further clutter in the syntax and the URL scheme --clutter than has to be supported forever in mail applications-- because the new form could gradually disappear as EAI deploys. Its disadvantage is that it further isolates the use of alternate addresses and makes them less attractive. >> I think this method is easy and enough. >> >> But I have an another idea to add new option for the mailto. >> >> > II@ASCII> > That would work as well. Actually, it would require some odd special-casing, which would not be recognized by systems that don't specifically support that particular syntax extension and, even then, I'm not sure it would work. Normally, that syntax would cause To: non-ASCII-local-part@IDN-example.com ALT-ADDRESS: ASCII@ASCII The only exception to ?name-value pairs being treated as headers in RFC 2368 is the special-case for "body". Now consider a message being set to two addresses via mailto URLs and remember the rule against assuming very much about ordering of headers. So we have and resulting in To: , ALT-ADDRESS: ASCII2@ASCII ALT-ADDRESS: ASCII1@ASCII And we are in big trouble. I've also seen attempts, some of them successful, at using mailto: user1@example.com?to=user2@example.com Indeed, 2368 explicitly calls out mailto:addr1%2C%20addr2 mailto:?to=addr1%2C%20addr2 and mailto:addr1?to=addr2 as legitimate examples. Consider the third example with ?ALT-ADDRESS and one gets, potentially, mailto:addr1?to=addr2?Alt-address=addr2-variant?Alt-address=addr1-variant and you see where this quickly leads. My recollection is that the WG briefly considered the use of an additional header for the alternate address(es) and gave up on it for reasons related to the above. john From alexey.melnikov@isode.com Wed Aug 5 14:12:43 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C61FC28C437 for ; Wed, 5 Aug 2009 14:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSb215ZHu-wd for ; Wed, 5 Aug 2009 14:12:43 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9A55F3A6AE0 for ; Wed, 5 Aug 2009 14:12:42 -0700 (PDT) Received: from [172.16.2.179] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 5 Aug 2009 22:12:44 +0100 Message-ID: <4A79F593.8030004@isode.com> Date: Wed, 05 Aug 2009 22:11:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: John C Klensin References: <4A7953C6.6070005@isode.com> <56ADA3078807DFBB6AC880E8@p3.int.jck.com> In-Reply-To: <56ADA3078807DFBB6AC880E8@p3.int.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] Use of mailto: with EAI addresses X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 21:12:43 -0000 John C Klensin wrote: >--On Wednesday, 05 August, 2009 10:41 +0100 Alexey Melnikov > wrote: > >>I vaguely remember that there was a decision last year to >>design a separate URI scheme (similar to mailto:) for use with >>EAI addresses. Is this no longer the direction the WG wants to >>take? >> >> > >I think your recollection is correct. The advantage of that >plan is that it does not result in further clutter in the syntax >and the URL scheme --clutter than has to be supported forever in >mail applications-- because the new form could gradually >disappear as EAI deploys. Its disadvantage is that it further >isolates the use of alternate addresses and makes them less >attractive. > > Ok. I think the WG needs to explicitly decide if it wants to design a new URI scheme or extend mailto (and possibly add some restrictions on what can be expressed). >>>I think this method is easy and enough. >>> >>>But I have an another idea to add new option for the mailto. >>> >>> >> II@ASCII> >>> >>> >>That would work as well. >> >Actually, it would require some odd special-casing, which would >not be recognized by systems that don't specifically support >that particular syntax extension and, even then, I'm not sure it >would work. Normally, that syntax would cause > > To: non-ASCII-local-part@IDN-example.com > ALT-ADDRESS: ASCII@ASCII > > >The only exception to ?name-value pairs being treated as headers >in RFC 2368 is the special-case for "body". > Right. But mailtobis explicitly advises against using values of header fields, unless they are recognized and considered safe. So assuming existing implementations ignore unrecognized header fields, this shouldn't happen. >Now consider a message being set to two addresses via mailto >URLs and remember the rule against assuming very much about >ordering of headers. So we have > > > >and > > > >resulting in > To: , > > ALT-ADDRESS: ASCII2@ASCII > ALT-ADDRESS: ASCII1@ASCII > >And we are in big trouble. I've also seen attempts, some of >them successful, at using > mailto: user1@example.com?to=user2@example.com > >Indeed, 2368 explicitly calls out > > mailto:addr1%2C%20addr2 > mailto:?to=addr1%2C%20addr2 and > mailto:addr1?to=addr2 > >as legitimate examples. Consider the third example with >?ALT-ADDRESS and one gets, potentially, > > >mailto:addr1?to=addr2?Alt-address=addr2-variant?Alt-address=addr1-variant > >and you see where this quickly leads. > > Oh. Right, we lost binding between ASCII and EAI addresses. >My recollection is that the WG briefly considered the use of an >additional header for the alternate address(es) and gave up on >it for reasons related to the above. > > From yaojk@cnnic.cn Wed Aug 5 19:35:10 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398C33A6CB4 for ; Wed, 5 Aug 2009 19:35:10 -0700 (PDT) X-Quarantine-ID: <2UNh1L9aC81l> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.365 X-Spam-Level: X-Spam-Status: No, score=0.365 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UNh1L9aC81l for ; Wed, 5 Aug 2009 19:35:09 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 444403A69B4 for ; Wed, 5 Aug 2009 19:34:42 -0700 (PDT) Received: (eyou send program); Thu, 06 Aug 2009 10:34:45 +0800 Message-ID: <449526085.20415@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 06 Aug 2009 10:34:45 +0800 Message-ID: <001701ca163e$742fe600$236ff1da@whatisfuture> From: "YAO Jiankang" To: "Ernie Dainow" , References: <449399580.17668@cnnic.cn> Date: Thu, 6 Aug 2009 10:34:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [EAI] Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 02:35:10 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVybmllIERhaW5vdyIgPGVk YWlub3dAY2EuYWZpbGlhcy5pbmZvPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5 LCBBdWd1c3QgMDQsIDIwMDkgMTE6MjUgUE0NClN1YmplY3Q6IFtFQUldIERvd25ncmFkZSBzaW1w bGlmaWNhdGlvbnMNCg0KDQo+SSB0aGluayB0aGVyZSBhcmUgYSBudW1iZXIgb2YgdGhpbmdzIHdl IGNhbiBjaGFuZ2UgdG8gbWFrZSBEb3duZ3JhZGUgDQo+IHNpbXBsZXIgYW5kIGhhdmUgbGVzcyBp bXBhY3Qgb24gZXhpc3RpbmcgZW1haWwgc3lzdGVtcyB5ZXQgc3RpbGwgcHJvdmlkZSANCj4gdGhl IGtleSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHRoYXQgbWFueSBwZW9wbGUgZmVlbCBpcyBpbXBv cnRhbnQgdG8gdGhlIA0KPiBzdWNjZXNzIG9mIEVBSS4NCj4gDQo+IFRoZSBjdXJyZW50IGRlc2ln biBvZiBEb3duZ3JhZGUgaXMgdmVyeSBjb21wcmVoZW5zaXZlLiBBIGxvdCBvZiBjbGV2ZXIgDQo+ IHRoaW5ncyB3ZXJlIGRvbmUgdG8gcHJvdmlkZSBEb3duZ3JhZGUgaW4gZXZlcnkgcG9zc2libGUg c2l0dWF0aW9uIGFuZCB0byANCj4gcHJvdmlkZSBhIGNvbXBsZXRlIGF1ZGl0IHRyYWlsIHRocm91 Z2ggdGhlIHVzZSBvZiBuZXcgRG93bmdyYWRlZCBoZWFkZXJzIA0KPiB0aGF0IGFsc28gcHJvdmlk ZSB0aGUgYWJpbGl0eSB0byByZWNvbnN0cnVjdCB0aGUgb3JpZ2luYWwgVVRGOCBhZGRyZXNzIA0K PiBpbmZvcm1hdGlvbiAoRG93bmdyYWRlZCBkaXNwbGF5KS4gV2UgY2FuIGdyZWF0bHkgc2ltcGxp ZnkgRG93bmdyYWRlIGJ5IA0KPiBsaW1pdGluZyB0aGUgZGVzaWduIGdvYWxzIHRvIHN1cHBvcnQg b25seSBlc3NlbnRpYWwgY2FzZXMgYW5kIG1ha2UgY2xlYXIgDQo+IHRoYXQgRG93bmdyYWRlIGlz IGFuIGludGVyaW0gZmVhdHVyZSwgaXMgbm90IHBlcmZlY3QgYW5kIGRvZXMgbm90IA0KPiBwcm92 aWRlIGEgY29tcGxldGUgYXVkaXQgdHJhaWwuDQo+IA0KPiAxLiBBcyByZWNvbW1lbmRlZCBpbiA0 LjIgb2YgIGRyYWZ0LWlldGYtZWFpLWVtYWlsLWNsaWVudHMgYW5kIGluIHZhcmlvdXMgDQo+IGVt YWlscyBvbiB0aGUgRUFJIGxpc3QsIHdlIHNob3VsZCBjb25zaWRlciBkb3duZ3JhZGUgb2YgZm9y d2FyZC1wb2ludGluZyANCj4gKHJlY2lwaWVudCkgYWRkcmVzc2VzIGFzIGEgY29uZmlndXJhdGlv biBlcnJvciBhbmQgbm90IHNvbWV0aGluZyB0aGF0IA0KPiBEb3duZ3JhZGUgbmVlZHMgdG8gc3Vw cG9ydC4gVGhlbiB3ZSBjYW4gcmVtb3ZlIEFsdGVybmF0ZSBBZGRyZXNzZXMgZm9yIA0KPiByZWNp cGllbnRzLiBJIHRoaW5rIHRoaXMgd291bGQgYWxzbyBhbGxvdyB1cyB0byByZWRlc2lnbiBEb3du Z3JhZGUgDQo+IHdpdGhvdXQgdGhlIGRvdWJsZSBhbmdsZSBicmFja2V0IHN5bnRheCB3aGljaCBz ZWVtcyB0byBiZSB0aGUgc291cmNlIG9mIA0KPiBhIGxvdCBvZiBjb21wYXRpYmlsaXR5IGFuZCBz ZWN1cml0eSBjb25jZXJucy4NCg0KDQp0aGlzIGlzIGEgZ29vZCBpZGVhLiBJIGFsc28gd29uZGVy IHdoZXRoZXIgd2UgbmVlZCB0aGUgZG93bmdyYWRpbmcgZm9yIHJlY2lwaWVudC4NCg0KaW4gcHJh Y3Rpc2UsIG9ubHkgImRvd25ncmFkZSBmcm9tIGFkZHJlc3MiIG1heSBiZSB1c2VmdWwuDQoNCg0K PiANCj4gMi4gSW1wbGVtZW50YXRpb24gb2YgRG93bmdyYWRlIGlzIGN1cnJlbnRseSBhbiBvcHRp b24gZm9yIE1VQSwgUE9QL0lNQVAuIA0KPiBDb25zaWRlcmF0aW9uIG9mIHRoZXNlIGNhc2VzIGlu IGRyYWZ0LWlldGYtZWFpLWVtYWlsLWNsaWVudHMgKDMuMS4xLCANCj4gMy4yKSBpcyB0aGF0IHRo ZXNlIGFyZSB1bnVzdWFsIGNvbmZpZ3VyYXRpb25zLiBUaGUgc3RhbmRhcmQgc2hvdWxkIGJlIA0K PiBleHBsaWNpdCBhbmQgc3RhdGUgdGhhdCBEb3duZ3JhZGUgaXMgb25seSBkb25lIGJ5IE1UQXMu DQoNCnRoaXMgaXNzdWUgbmVlZCBtb3JlIGRpc2N1c3Npb25zLg0KDQoNCj4gDQo+IDMuIFdoaWxl IGFuIGF1ZGl0IHRyYWlsIGFuZCBhYmlsaXR5IHRvIGRpc3BsYXkgb3JpZ2luYWwgVVRGOCBhZGRy ZXNzZXMgDQo+IGZyb20gYSBEb3duZ3JhZGVkIG1lc3NhZ2UgaXMgYSBuaWNlIGZlYXR1cmUsIHNv bWUgcGVvcGxlIGNvbnNpZGVyIHRoZSANCj4gY2FzZSBpbiB3aGljaCB0aGlzIGlzIHVzZWZ1bCB0 byBiZSBhIGNvbmZpZ3VyYXRpb24gZXJyb3IgKGFuIEVBSSBNVUEsIA0KPiBQT1Agb3IgSU1BUCBi ZWhpbmQgYSBub24tRUFJIE1UQS4pLiBJbiBhbnkgY2FzZSwgaXQgaXMgbm90IGFuIGVzc2VudGlh bCANCj4gZmVhdHVyZSB3aXRoaW4gdGhlIHJldmlzZWQgZGVzaWduIGdvYWxzIG91dGxpbmVkIGFi b3ZlLiBJZiBpdCBpcyANCj4gZHJvcHBlZCwgdGhlbiBhbGwgdGhlIGFkZGVkICJEb3duZ3JhZGVk LSIgaGVhZGVycyBjYW4gYmUgZHJvcHBlZC4NCg0KSSByZW1lYmVyIHRoYXQgdGhlIFdHIGRlY2lk ZWQgdG8gaGF2ZSBubyB1cGdyYWRpbmcgYWZ0ZXIgZG93bmdyYWRpbmcuDQoNCj4gDQo+IDQuIEFs dGVybmF0ZSBBZGRyZXNzZXMgZm9yIHRoZSBzZW5kZXIgY2FuIGJlIGhhbmRsZWQgaW4gdGhlICJB Y2NvdW50cyIgDQo+IHNldHRpbmcgb2YgdGhlIE1VQS4gVGhleSBjYW4gYWxzbyBiZSBwcm92aWRl ZCBieSB0aGUgU01UUCBzZXJ2ZXIsIGFzIGluIA0KPiBkcmFmdC15YW8tZWFpLWRlcGxveW1lbnQu IFNpbmNlIHRoZXJlIGlzIG5vIGludGVyZmFjZSBmb3IgdGhlIE1VQSB0byANCj4gZmluZCBvdXQg ZnJvbSB0aGUgc2VydmVyIGlmIGl0IG5lZWRzIHRvIHByb3ZpZGUgQWx0ZXJuYXRlIEFkZHJlc3Nl cyBvciANCj4gbm90LCB0aGlzIGFtYmlndWl0eSBtYXkgbGVhZCB0byB1bmV4cGVjdGVkIGJlaGF2 aW9yIGluIHRlcm1zIG9mIHdoaWNoIA0KPiBBbHRlcm5hdGUgQWRkcmVzcyBnZXRzIHVzZWQgaWYg aXQgaXMgcHJvdmlkZWQgYnkgYm90aC4gDQoNCisxDQoNCnRoZSBwb3NzaWJsZSBwaGlzaW5nIHdp bGwgYmUgcmVkdWNlZCBpZiB0aGUgYWx0ZXJuYXRlIGFkZHJlc3MgaXMgb25seSBwcm92aWRlZCBi eSBzbXRwIHNlcnZlci4NCmlmIHRoZSBhbHRlcm5hdGUgYWRkcmVzcyBpcyBwcm92aWRlZCBieSBN VUEsIHRoZSB1c2VyIGNhbiBwdXQgYW55IGFkZHJlc3MgdGhleSB3YW50IHN1Y2ggYXMgYWRtaW5p c3RhcnRvckBlYmF5LmNvbSBvciBwcmVzaWRlbnRAdXNhLmdvdiAuIA0KDQogDQo+V2hpbGUgdGhl IHNlcnZlciANCj4gc29sdXRpb24gb2ZmZXJzIGEgY2VydGFpbiBhbW91bnQgb2YgdHJhbnNwYXJl bmN5IHRvIHRoZSBlbmQgdXNlciwgdGhlIA0KPiBNVUEgc29sdXRpb24gaXMgbW9yZSBnZW5lcmFs IGluIHRoYXQgaXQgc3VwcG9ydHMgYSBsZWdhY3kgQVNDSUkgQWRkcmVzcyANCj4gdGhhdCBtYXkg YmUgb24gYSBkaWZmZXJlbnQgZW1haWwgcHJvdmlkZXIuIA0KDQp3aGVuIHlvdSByZWdpc3RlciBh biBlbWFpbCBhY2NvdW50LCB5b3UgY2FuIGFwcGx5IGJvdGggdGhlIGFzY2lpIGVtYWlsIGFjY291 bnQgYW5kIG5vbi1hc2NpaSBlbWFpbCBhY2NvdW50IGZyb20gdGhlIHNhbWUgY29tcGFueSBvciBv cmdhbml6YXRpb24uDQoNCj5UaGUgc3RhbmRhcmQgc2hvdWxkIHJlc29sdmUgDQo+IHRoaXMgYW1i aWd1aXR5IGFuZCBzcGVjaWZ5IHRoYXQgQWx0ZXJuYXRlIEFkZHJlc3MgZm9yIHRoZSBzZW5kZXIg aXMgDQo+IHByb3ZpZGVkIGJ5IHRoZSBNVUEgYW5kIG5vdCB0aGUgc2VydmVyLg0KDQppZiB3ZSBk ZWNpZGUgdG8gaGF2ZSBubyBkb3duZ3JhZGUgaXNzdWUgaW4gUkZDNTMzNiA1MzM1LCB0aGVuIHlv dSBhcmUgcmlnaHQuIG90aGVyd2lzZSwgd2UgbWF5IGNvbnNpZGVyIHRoYXQgb25seSBieSBzZXJ2 ZXIsIG5vdCBieSBNVUEuDQoNCg0KPiANCj4gNS4gQ2FwdHVyaW5nIFVURjggYWRkcmVzc2VzIGlu IGVtcHR5IGdyb3VwcyB3aGVuIERvd25ncmFkaW5nIHNob3VsZCBiZSANCj4gZHJvcHBlZC4gVGhp cyBoYXMgbnVtZXJvdXMgaW50ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcyB3aXRoIGV4aXN0aW5nIG1h aWwgDQo+IGNsaWVudHMgKDMuMi4xIGluIGRyYWZ0LWlldGYtZWFpLWVtYWlsLWNsaWVudHMpLg0K PiANCj4gVG8gbWFrZSBhIGNsZWFuIGxpbmUgYmV0d2VlbiBEb3duZ3JhZGUgYW5kIHRoZSByZXN0 IG9mIHRoZSBFQUkgc3RhbmRhcmQsIA0KPiBzbyB0aGF0IHdlIGNhbiBtb3ZlIGFoZWFkIHdpdGgg c3RhbmRhcmRzIHRyYWNrIG9mIHRoZSBsYXR0ZXIgd2hpbGUgDQo+IGNvbnRpbnVpbmcgdG8gd29y ayBvbiBleHBlcmltZW50YWwgdHJhY2sgRG93bmdyYWRlLCBhbGwgbm9ybWF0aXZlIA0KPiByZXF1 aXJlbWVudHMgcmVsYXRpbmcgdG8gRG93bmdyYWRlIHNob3VsZCBiZSBwdWxsZWQgb3V0IG9mIHRo ZSBFQUkgDQo+IGRvY3VtZW50cyBhbmQgbW92ZWQgaW50byB0aGUgRG93bmdyYWRlIGRvY3VtZW50 LiBTbyBmb3IgZXhhbXBsZSwgdGhlIA0KPiBBTFQtQUREUkVTUyBwYXJhbWV0ZXIgc2hvdWxkIGJl IG1vdmVkIGZyb20gUkZDIDUzMzYgdG8gdGhlIERvd25ncmFkZSANCj4gZG9jdW1lbnQgYW5kIHRo ZSBhZGRyLXNwZWMgZm9yIGRvdWJsZSBhbmdsZSBicmFja2V0cyBtb3ZlZCBvdXQgb2YgUkZDIA0K PiA1MzM1IGludG8gdGhlIERvd25ncmFkZSBkb2MgKG9yIGRyb3BwZWQgaWYgMS4gYWJvdmUgY2Fu IGJlIGFjaGlldmVkKS4NCg0KKzEuDQoNCkkgcGVyc29uYWxseSBhZ3JlZSB0aGlzIHN1Z2dlc3Rp b24uDQoNCllhbyBKaWFua2FuZw0KQ05OSUMNCg0KPiANCj4gICAtRXJuaWUgRGFpbm93DQo+IA0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g SU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pbWE= From yaojk@cnnic.cn Wed Aug 5 20:10:37 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7CE3A6A0E for ; Wed, 5 Aug 2009 20:10:37 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 1.193 X-Spam-Level: * X-Spam-Status: No, score=1.193 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_20=-0.74, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSRxjOTo7kNW for ; Wed, 5 Aug 2009 20:10:36 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 138F23A67FE for ; Wed, 5 Aug 2009 20:10:35 -0700 (PDT) Received: (eyou send program); Thu, 06 Aug 2009 11:10:38 +0800 Message-ID: <449528238.08513@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 06 Aug 2009 11:10:38 +0800 Message-ID: <003701ca1643$778a4250$236ff1da@whatisfuture> From: "YAO Jiankang" To: "Ernie Dainow" , "Stephane Bortzmeyer" , "EAI" References: <4A3FA114.3070007@ca.afilias.info><20090627195635.GA14125@laperouse.bortzmeyer.org> <447145015.02367@cnnic.cn> Date: Thu, 6 Aug 2009 11:10:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: Re: [EAI] Downgrade testing - Results X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 03:10:37 -0000 DQp3ZSBzZW5kIHRvIHRoZSBmb2xsb3dpbmcgMTAgYWRkcmVzcywgd2l0aCA8ZWFpPGFzY2lpPj4N Cj4+ICogZWNob0BnZW5lcmljLW5pYy5uZXQgDQo+PiAqIGVjaG9AbmljLmZyIA0KPj4gKiBFY2hv QFRVLUJlcmxpbi5ERSANCj4+ICogZWNob0B0dS1jaGVtbml0ei5kZSANCj4+ICogZWNob0BvdWFp bi5jb20gDQo+PiAqIHJlcG9uZHNtb2lAY3JkcC5hYy12ZXJzYWlsbGVzLmZyDQo+PiAqIGVjaG9A Y25hbS5mcg0KPj4gKiBwaW5nQHN0YW1wZXIuaXRjb25zdWx0LmNvLnVrIA0KPj4gKiBwaW5nQG9s ZWFuZS5uZXQNCj4+ICogY2hlY2stYXV0aEB2ZXJpZmllci5wb3J0MjUuY29tDQoNCg0Kd2UgZ2V0 IHRoZSBuaWNlIHJlc3BvbnNlIGZyb20gdGhlIGZvbGxvd2luZyA2IGFkZHJlc3MNCmVjaG9AZ2Vu ZXJpYy1uaWMubmV0DQplY2hvQG5pYy5mcg0KRWNob0BUVS1CZXJsaW4uREUNCmVjaG9Ab3VhaW4u Y29tDQpjaGVjay1hdXRoQHZlcmlmaWVyLnBvcnQyNS5jb20NCnJlcG9uZHNtb2lAY3JkcC5hYy12 ZXJzYWlsbGVzLmZyDQoNCg0Kd2UgZ2V0IHRoZSByZWplY3QgaW5mb3JtYXRpb24gZnJvbSAxIGFk ZHJlc3MNCmVjaG9AY29wZXJuaWMuY25hbS5mcg0KDQoNCndlIGNhbiBub3QgZ2V0IGFueSByZXNw b25zZSBmcm9tIG90aGVyIDMgYWRkcmVzc2VzLg0KDQoNCg0KWWFvIEppYW5rYW5nDQpDTk5JQw0K DQoNCg0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiRXJuaWUgRGFp bm93IiA8ZWRhaW5vd0BjYS5hZmlsaWFzLmluZm8+DQpUbzogIlN0ZXBoYW5lIEJvcnR6bWV5ZXIi IDxib3J0em1leWVyQG5pYy5mcj47ICJFQUkiIDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2Rh eSwgSnVseSAwOSwgMjAwOSA5OjA5IFBNDQpTdWJqZWN0OiBSZTogW0VBSV0gRG93bmdyYWRlIHRl c3RpbmcgLSBSZXN1bHRzDQoNCg0KPiBUaGVzZSBlY2hvIHRlc3RzIHdlcmUgYSBnb29kIHN1Z2dl c3Rpb24uIEkgcmFuIGEgYmFzZSB0ZXN0IGZyb20gYW4gQVNDSUkgDQo+IGFkZHJlc3MgYWdhaW5z dCBhbGwgZWNobyBzZXJ2ZXJzIGluIHRoZSBsaXN0LiBBbGwgcmVzcG9uZGVkIGV4Y2VwdCANCj4g ZWNob0BjbmFtLmZyLiBFbWFpbCBib3VuY2VkIHdpdGggInVua25vd24gYWRkcmVzcyIsIHNvIEkg IGVsaW1pbmF0ZWQgDQo+IHRoYXQgc2VydmVyIGZyb20gdGhlIHRlc3QsIGxlYXZpbmcgYSB0b3Rh bCBvZiA5IGVjaG8gc2VydmVycy4NCj4gDQo+IFRoZSBzdWNjZXNzIHJhdGUgZm9yIHJlY2Vpdmlu ZyBhIHJlc3BvbnNlIGZyb20gZWNobyBzZXJ2ZXJzOg0KPiAxKSBGcm9tIEFTQ0lJLCBubyBkb3du Z3JhZGUgICAgICA5LzkgICAgICAxMDAlDQo+IDIpIEZyb20gRUFJLCBkb3duZ3JhZGUgICAgICAg ICAgICAgICA3LzkgICAgICAgIDc4JQ0KPiANCj4gYXV0aC1yZXN1bHRzQHZlcmlmaWVyLnBvcnQy NS5jb20gcHJvdmlkZWQgc29tZSBTcGFtQXNzYXNzaW4gYW5hbHlzaXM6DQo+IDEpIEJPRFk6IEJh eWVzaWFuIHNwYW0gcHJvYmFiaWxpdHkgaXMgMSB0byA1JQ0KPiAyKSBCT0RZOiBCYXllc2lhbiBz cGFtIHByb2JhYmlsaXR5IGlzIDUgdG8gMjAlDQo+IA0KPiBGb3IgdGhlIGRvd25ncmFkZSB0ZXN0 IHNlbnQgdG8gaW5kaXZpZHVhbCBwYXJ0aWNpcGFudHMgdGhlIHJlc3VsdHMgd2VyZToNCj4gVG90 YWwgU2VudCAgICAxMSAgIChhbGwgb24gZGlmZmVyZW50IGVtYWlsIGRvbWFpbnMpDQo+IFJlY2Vp dmVkICAgICAgIDkgICAgODIlDQo+IEJsb2NrZWQgICAgICAgIDIgICAgMTglDQo+IA0KPiBUaGVz ZSBhcmUgbm90IGxhcmdlIHNhbXBsZXMsIGJ1dCBpdCBpcyBpbnRlcmVzdGluZyB0byBzZWUgdGhh dCB0aGUgDQo+IHN1Y2Nlc3MgcmF0ZSBpbiBib3RoIHRlc3RzIHdlcmUgc2ltaWxhciwgYW5kIHdl cmUgaW4gdGhlIFNwYW1Bc3Nhc3NpbiANCj4gcmFuZ2Ugb2YgMjAlIHByb2JhYmlsaXR5IG9mIHNw YW0uDQo+IA0KPiBJIGVuY291cmFnZSBvdGhlciBpbXBsZW1lbnRlcnMgdG8gcnVuIHRoZSBzYW1l IHNldCBvZiB0ZXN0cyBzbyB3ZSBjYW4gDQo+IGdldCBhIGxhcmdlciBzYW1wbGUgYW5kIHNlZSBp ZiB0aGVyZSBhcmUgZGlmZmVyZW5jZXMgYmV0d2VlbiBEb3duZ3JhZGUgDQo+IGltcGxlbWVudGF0 aW9ucy4NCj4gDQo+ICAgIC1Fcm5pZQ0KPiANCj4gDQo+IFN0ZXBoYW5lIEJvcnR6bWV5ZXIgd3Jv dGU6DQo+PiBPbiBNb24sIEp1biAyMiwgMjAwOSBhdCAxMToxOTo0OEFNIC0wNDAwLA0KPj4gIEVy bmllIERhaW5vdyA8ZWRhaW5vd0BjYS5hZmlsaWFzLmluZm8+IHdyb3RlIA0KPj4gIGEgbWVzc2Fn ZSBvZiA0MSBsaW5lcyB3aGljaCBzYWlkOg0KPj4NCj4+ICAgDQo+Pj4gVGhlIERvd25ncmFkZSB0 ZXN0IHJlcG9ydGVkIG9uIHRoZSB3aWtpIGJhc2ljYWxseSB0ZXN0ZWQgYWdhaW5zdCBnbWFpbC4g IA0KPj4+IEl0IHdvdWxkIGJlIHZhbHVhYmxlIHRvIGRvIG1vcmUgdGVzdGluZyAnaW4gdGhlIHdp bGQnIHRvIHNlZSBob3cgIA0KPj4+IERvd25ncmFkZSB0cmF2ZXJzZXMgdmFyaW91cyBlbWFpbCBz eXN0ZW1zIGluIG90aGVyIG9yZ2FuaXphdGlvbnMuDQo+Pj4gICAgIA0KPj4NCj4+IFlvdSBjYW4g dGVzdCBhZ2FpbnN0IHZhcmlvdXMgYXV0by1yZXNwb25kZXJzIHdoaWNoIHNlbmQgeW91IGJhY2sg eW91cg0KPj4gbWVzc2FnZSAoaWYgeW91IGtub3cgb3RoZXIgZW1haWwgYWRkcmVzc2VzIG9mIGF1 dG8tcmVzcG9uZGVycywgZG8gbm90DQo+PiBoZXNpdGF0ZSB0byBwdWJsaXNoIHRoZW0pLg0KPj4N Cj4+ICogZWNob0BnZW5lcmljLW5pYy5uZXQgDQo+PiAqIGVjaG9AbmljLmZyIA0KPj4gKiBFY2hv QFRVLUJlcmxpbi5ERSANCj4+ICogZWNob0B0dS1jaGVtbml0ei5kZSANCj4+ICogZWNob0BvdWFp bi5jb20gDQo+PiAqIHJlcG9uZHNtb2lAY3JkcC5hYy12ZXJzYWlsbGVzLmZyDQo+PiAqIGVjaG9A Y25hbS5mcg0KPj4gKiBwaW5nQHN0YW1wZXIuaXRjb25zdWx0LmNvLnVrIA0KPj4gKiBwaW5nQG9s ZWFuZS5uZXQNCj4+ICogY2hlY2stYXV0aEB2ZXJpZmllci5wb3J0MjUuY29tDQo+PiAgIA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEgbWFp bGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ltYQ== From yaojk@cnnic.cn Wed Aug 5 20:15:00 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5333A6802 for ; Wed, 5 Aug 2009 20:15:00 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 1.317 X-Spam-Level: * X-Spam-Status: No, score=1.317 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_20=-0.74, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQYP0Nge+6RK for ; Wed, 5 Aug 2009 20:14:59 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id D86AD3A6C40 for ; Wed, 5 Aug 2009 20:14:32 -0700 (PDT) Received: (eyou send program); Thu, 06 Aug 2009 11:14:35 +0800 Message-ID: <449528475.12144@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 06 Aug 2009 11:14:35 +0800 Message-ID: <004701ca1644$05237f00$236ff1da@whatisfuture> From: "YAO Jiankang" To: "YAO Jiankang" , "Ernie Dainow" , "Stephane Bortzmeyer" , "EAI" References: <4A3FA114.3070007@ca.afilias.info><20090627195635.GA14125@laperouse.bortzmeyer.org><447145015.02367@cnnic.cn> <449528245.12181@cnnic.cn> Date: Thu, 6 Aug 2009 11:14:33 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: meldin78@hotmail.com Subject: Re: [EAI] Downgrade testing - Results X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 03:15:00 -0000 YnR3LCB0aGUgaW1wbG1lbnRhdGlvbiBpcyBiYXNlZCBvbiBwb3N0Zml4Lg0KY291bGQgVFdOSUMg SlBSUyBOSURBIGRvIHRoZSBzaW1pbGFyIHRlc3RzIGFuZCByZXBvcnQgdGhlIHJlc3VsdHM/DQoN CllBTyBKaWFua2FuZw0KQ05OSUMNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZy b206ICJZQU8gSmlhbmthbmciIDx5YW9qa0Bjbm5pYy5jbj4NClRvOiAiRXJuaWUgRGFpbm93IiA8 ZWRhaW5vd0BjYS5hZmlsaWFzLmluZm8+OyAiU3RlcGhhbmUgQm9ydHptZXllciIgPGJvcnR6bWV5 ZXJAbmljLmZyPjsgIkVBSSIgPGltYUBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3Qg MDYsIDIwMDkgMTE6MTAgQU0NClN1YmplY3Q6IFJlOiBbRUFJXSBEb3duZ3JhZGUgdGVzdGluZyAt IFJlc3VsdHMNCg0KDQo+IA0KPiB3ZSBzZW5kIHRvIHRoZSBmb2xsb3dpbmcgMTAgYWRkcmVzcywg d2l0aCA8ZWFpPGFzY2lpPj4NCj4+PiAqIGVjaG9AZ2VuZXJpYy1uaWMubmV0IA0KPj4+ICogZWNo b0BuaWMuZnIgDQo+Pj4gKiBFY2hvQFRVLUJlcmxpbi5ERSANCj4+PiAqIGVjaG9AdHUtY2hlbW5p dHouZGUgDQo+Pj4gKiBlY2hvQG91YWluLmNvbSANCj4+PiAqIHJlcG9uZHNtb2lAY3JkcC5hYy12 ZXJzYWlsbGVzLmZyDQo+Pj4gKiBlY2hvQGNuYW0uZnINCj4+PiAqIHBpbmdAc3RhbXBlci5pdGNv bnN1bHQuY28udWsgDQo+Pj4gKiBwaW5nQG9sZWFuZS5uZXQNCj4+PiAqIGNoZWNrLWF1dGhAdmVy aWZpZXIucG9ydDI1LmNvbQ0KPiANCj4gDQo+IHdlIGdldCB0aGUgbmljZSByZXNwb25zZSBmcm9t IHRoZSBmb2xsb3dpbmcgNiBhZGRyZXNzDQo+IGVjaG9AZ2VuZXJpYy1uaWMubmV0DQo+IGVjaG9A bmljLmZyDQo+IEVjaG9AVFUtQmVybGluLkRFDQo+IGVjaG9Ab3VhaW4uY29tDQo+IGNoZWNrLWF1 dGhAdmVyaWZpZXIucG9ydDI1LmNvbQ0KPiByZXBvbmRzbW9pQGNyZHAuYWMtdmVyc2FpbGxlcy5m cg0KPiANCj4gDQo+IHdlIGdldCB0aGUgcmVqZWN0IGluZm9ybWF0aW9uIGZyb20gMSBhZGRyZXNz DQo+IGVjaG9AY29wZXJuaWMuY25hbS5mcg0KPiANCj4gDQo+IHdlIGNhbiBub3QgZ2V0IGFueSBy ZXNwb25zZSBmcm9tIG90aGVyIDMgYWRkcmVzc2VzLg0KPiANCj4gDQo+IA0KPiBZYW8gSmlhbmth bmcNCj4gQ05OSUMNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tIA0KPiBGcm9tOiAiRXJuaWUgRGFpbm93IiA8ZWRhaW5vd0BjYS5hZmlsaWFzLmluZm8+ DQo+IFRvOiAiU3RlcGhhbmUgQm9ydHptZXllciIgPGJvcnR6bWV5ZXJAbmljLmZyPjsgIkVBSSIg PGltYUBpZXRmLm9yZz4NCj4gU2VudDogVGh1cnNkYXksIEp1bHkgMDksIDIwMDkgOTowOSBQTQ0K PiBTdWJqZWN0OiBSZTogW0VBSV0gRG93bmdyYWRlIHRlc3RpbmcgLSBSZXN1bHRzDQo+IA0KPiAN Cj4+IFRoZXNlIGVjaG8gdGVzdHMgd2VyZSBhIGdvb2Qgc3VnZ2VzdGlvbi4gSSByYW4gYSBiYXNl IHRlc3QgZnJvbSBhbiBBU0NJSSANCj4+IGFkZHJlc3MgYWdhaW5zdCBhbGwgZWNobyBzZXJ2ZXJz IGluIHRoZSBsaXN0LiBBbGwgcmVzcG9uZGVkIGV4Y2VwdCANCj4+IGVjaG9AY25hbS5mci4gRW1h aWwgYm91bmNlZCB3aXRoICJ1bmtub3duIGFkZHJlc3MiLCBzbyBJICBlbGltaW5hdGVkIA0KPj4g dGhhdCBzZXJ2ZXIgZnJvbSB0aGUgdGVzdCwgbGVhdmluZyBhIHRvdGFsIG9mIDkgZWNobyBzZXJ2 ZXJzLg0KPj4gDQo+PiBUaGUgc3VjY2VzcyByYXRlIGZvciByZWNlaXZpbmcgYSByZXNwb25zZSBm cm9tIGVjaG8gc2VydmVyczoNCj4+IDEpIEZyb20gQVNDSUksIG5vIGRvd25ncmFkZSAgICAgIDkv OSAgICAgIDEwMCUNCj4+IDIpIEZyb20gRUFJLCBkb3duZ3JhZGUgICAgICAgICAgICAgICA3Lzkg ICAgICAgIDc4JQ0KPj4gDQo+PiBhdXRoLXJlc3VsdHNAdmVyaWZpZXIucG9ydDI1LmNvbSBwcm92 aWRlZCBzb21lIFNwYW1Bc3Nhc3NpbiBhbmFseXNpczoNCj4+IDEpIEJPRFk6IEJheWVzaWFuIHNw YW0gcHJvYmFiaWxpdHkgaXMgMSB0byA1JQ0KPj4gMikgQk9EWTogQmF5ZXNpYW4gc3BhbSBwcm9i YWJpbGl0eSBpcyA1IHRvIDIwJQ0KPj4gDQo+PiBGb3IgdGhlIGRvd25ncmFkZSB0ZXN0IHNlbnQg dG8gaW5kaXZpZHVhbCBwYXJ0aWNpcGFudHMgdGhlIHJlc3VsdHMgd2VyZToNCj4+IFRvdGFsIFNl bnQgICAgMTEgICAoYWxsIG9uIGRpZmZlcmVudCBlbWFpbCBkb21haW5zKQ0KPj4gUmVjZWl2ZWQg ICAgICAgOSAgICA4MiUNCj4+IEJsb2NrZWQgICAgICAgIDIgICAgMTglDQo+PiANCj4+IFRoZXNl IGFyZSBub3QgbGFyZ2Ugc2FtcGxlcywgYnV0IGl0IGlzIGludGVyZXN0aW5nIHRvIHNlZSB0aGF0 IHRoZSANCj4+IHN1Y2Nlc3MgcmF0ZSBpbiBib3RoIHRlc3RzIHdlcmUgc2ltaWxhciwgYW5kIHdl cmUgaW4gdGhlIFNwYW1Bc3Nhc3NpbiANCj4+IHJhbmdlIG9mIDIwJSBwcm9iYWJpbGl0eSBvZiBz cGFtLg0KPj4gDQo+PiBJIGVuY291cmFnZSBvdGhlciBpbXBsZW1lbnRlcnMgdG8gcnVuIHRoZSBz YW1lIHNldCBvZiB0ZXN0cyBzbyB3ZSBjYW4gDQo+PiBnZXQgYSBsYXJnZXIgc2FtcGxlIGFuZCBz ZWUgaWYgdGhlcmUgYXJlIGRpZmZlcmVuY2VzIGJldHdlZW4gRG93bmdyYWRlIA0KPj4gaW1wbGVt ZW50YXRpb25zLg0KPj4gDQo+PiAgICAtRXJuaWUNCj4+IA0KPj4gDQo+PiBTdGVwaGFuZSBCb3J0 em1leWVyIHdyb3RlOg0KPj4+IE9uIE1vbiwgSnVuIDIyLCAyMDA5IGF0IDExOjE5OjQ4QU0gLTA0 MDAsDQo+Pj4gIEVybmllIERhaW5vdyA8ZWRhaW5vd0BjYS5hZmlsaWFzLmluZm8+IHdyb3RlIA0K Pj4+ICBhIG1lc3NhZ2Ugb2YgNDEgbGluZXMgd2hpY2ggc2FpZDoNCj4+Pg0KPj4+ICAgDQo+Pj4+ IFRoZSBEb3duZ3JhZGUgdGVzdCByZXBvcnRlZCBvbiB0aGUgd2lraSBiYXNpY2FsbHkgdGVzdGVk IGFnYWluc3QgZ21haWwuICANCj4+Pj4gSXQgd291bGQgYmUgdmFsdWFibGUgdG8gZG8gbW9yZSB0 ZXN0aW5nICdpbiB0aGUgd2lsZCcgdG8gc2VlIGhvdyAgDQo+Pj4+IERvd25ncmFkZSB0cmF2ZXJz ZXMgdmFyaW91cyBlbWFpbCBzeXN0ZW1zIGluIG90aGVyIG9yZ2FuaXphdGlvbnMuDQo+Pj4+ICAg ICANCj4+Pg0KPj4+IFlvdSBjYW4gdGVzdCBhZ2FpbnN0IHZhcmlvdXMgYXV0by1yZXNwb25kZXJz IHdoaWNoIHNlbmQgeW91IGJhY2sgeW91cg0KPj4+IG1lc3NhZ2UgKGlmIHlvdSBrbm93IG90aGVy IGVtYWlsIGFkZHJlc3NlcyBvZiBhdXRvLXJlc3BvbmRlcnMsIGRvIG5vdA0KPj4+IGhlc2l0YXRl IHRvIHB1Ymxpc2ggdGhlbSkuDQo+Pj4NCj4+PiAqIGVjaG9AZ2VuZXJpYy1uaWMubmV0IA0KPj4+ ICogZWNob0BuaWMuZnIgDQo+Pj4gKiBFY2hvQFRVLUJlcmxpbi5ERSANCj4+PiAqIGVjaG9AdHUt Y2hlbW5pdHouZGUgDQo+Pj4gKiBlY2hvQG91YWluLmNvbSANCj4+PiAqIHJlcG9uZHNtb2lAY3Jk cC5hYy12ZXJzYWlsbGVzLmZyDQo+Pj4gKiBlY2hvQGNuYW0uZnINCj4+PiAqIHBpbmdAc3RhbXBl ci5pdGNvbnN1bHQuY28udWsgDQo+Pj4gKiBwaW5nQG9sZWFuZS5uZXQNCj4+PiAqIGNoZWNrLWF1 dGhAdmVyaWZpZXIucG9ydDI1LmNvbQ0KPj4+ICAgDQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gSU1BIG1haWxpbmcgbGlzdA0KPj4gSU1BQGll dGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJTUEgbWFp bGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ltYQ== From harald@alvestrand.no Thu Aug 6 04:15:02 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D6963A6D10 for ; Thu, 6 Aug 2009 04:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxHNkmEmyHWo for ; Thu, 6 Aug 2009 04:15:01 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 6780F3A6ADF for ; Thu, 6 Aug 2009 04:13:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C76E439E116; Thu, 6 Aug 2009 13:13:49 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no 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 gwGbNeD7SdtI; Thu, 6 Aug 2009 13:13:45 +0200 (CEST) Received: from [192.168.1.198] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 2BDA639E0BD; Thu, 6 Aug 2009 13:13:45 +0200 (CEST) Message-ID: <4A7ABAC7.2040800@alvestrand.no> Date: Thu, 06 Aug 2009 13:13:11 +0200 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ernie Dainow References: <4A7852F2.6010506@ca.afilias.info> In-Reply-To: <4A7852F2.6010506@ca.afilias.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 11:15:02 -0000 Ernie Dainow wrote: > I think there are a number of things we can change to make Downgrade > simpler and have less impact on existing email systems yet still > provide the key backward compatibility that many people feel is > important to the success of EAI. > > The current design of Downgrade is very comprehensive. A lot of clever > things were done to provide Downgrade in every possible situation and > to provide a complete audit trail through the use of new Downgraded > headers that also provide the ability to reconstruct the original UTF8 > address information (Downgraded display). We can greatly simplify > Downgrade by limiting the design goals to support only essential cases > and make clear that Downgrade is an interim feature, is not perfect > and does not provide a complete audit trail. > > 1. As recommended in 4.2 of draft-ietf-eai-email-clients and in > various emails on the EAI list, we should consider downgrade of > forward-pointing (recipient) addresses as a configuration error and > not something that Downgrade needs to support. Then we can remove > Alternate Addresses for recipients. I think this would also allow us > to redesign Downgrade without the double angle bracket syntax which > seems to be the source of a lot of compatibility and security concerns. As I said at the Stockholm meeting: I'm fine with this, as long as we're able to satisfy the triangular scenario. From the long-expired scenarios draft: > 2.5. An i18mail user sends to one ascii user and one i18mail user > > In this scenario, A sends to B and X; both reply. > > Precondition: A and B have to have valid ASCII addresses. > > Requirement: Through some series of steps, A must be able to get a > message to both B and X; through some series of steps, B and X must > be able to reply to each other and to A. X must not require > information outside of what is included in the message to get a > message to B. > > Possible non-requirements (for discussion): > > o Maybe the messages to B and X don't need to be exactly the same. > > o Maybe B doesn't need to see or use A's i18n-address when he's > replying to A and X. > > o Maybe X doesn't need to see A's address exactly the same on the > message from A and the reply from B. The way this is satisfied in the current spec is that in the headers of the message from A to X, B's address is in > form, and will be turned into at the downgrade gateway. If we drop the > form from the headers, how will X know what B's ASCII address is? Harald From duerst@it.aoyama.ac.jp Thu Aug 6 08:26:55 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD1E3A6A8C for ; Thu, 6 Aug 2009 08:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.181 X-Spam-Level: X-Spam-Status: No, score=-0.181 tagged_above=-999 required=5 tests=[AWL=-1.610, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g01BUlB4Hk0D for ; Thu, 6 Aug 2009 08:26:54 -0700 (PDT) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id 526533A6A1F for ; Thu, 6 Aug 2009 08:26:53 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id n76FQjTO028824 for ; Fri, 7 Aug 2009 00:26:45 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 5a89_8d2124aa_829d_11de_985d_001d096c566a; Fri, 07 Aug 2009 00:26:45 +0900 Received: from [IPv6:::1] ([133.2.210.1]:35315) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 7 Aug 2009 00:23:55 +0900 Message-ID: <4A7982A8.5000808@it.aoyama.ac.jp> Date: Wed, 05 Aug 2009 22:01:28 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Alexey Melnikov References: <20090805.180734.104051535.fujiwara@jprs.co.jp> <4A7952B5.3020300@isode.com> In-Reply-To: <4A7952B5.3020300@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Shawn.Steele@microsoft.com, ima@ietf.org Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 15:26:56 -0000 The problem with this is that it doesn't work for cc and bcc fields. Regards, Martin. On 2009/08/05 18:36, Alexey Melnikov wrote: > fujiwara@jprs.co.jp wrote: > >>> From: John C Klensin >>> if one of them contains non-ASCII elements, e.g., >>> mailto:non-ASCII-local-part@IDN-example.com or >>> mailto:bar@example.org >>> >>> nothing is lost and some small bits are gained. >>> >> I think this method is easy and enough. >> >> But I have an another idea to add new option for the mailto. >> >> >> >> > That would work as well. > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From klensin@jck.com Thu Aug 6 10:50:48 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDCFD3A6ADB for ; Thu, 6 Aug 2009 10:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pBFAk5MKLRY for ; Thu, 6 Aug 2009 10:50:48 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 2B9DB3A697F for ; Thu, 6 Aug 2009 10:50:48 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MZ770-000JrQ-0A; Thu, 06 Aug 2009 13:50:46 -0400 Date: Thu, 06 Aug 2009 13:50:45 -0400 From: John C Klensin To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , Alexey Melnikov Message-ID: <7BAA880B794517FABC1D6AE4@PST.JCK.COM> In-Reply-To: <4A7982A8.5000808@it.aoyama.ac.jp> References: <20090805.180734.104051535.fujiwara@jprs.co.jp> <4A7952B5.3020300@isode.com> <4A7982A8.5000808@it.aoyama.ac.jp> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Shawn.Steele@microsoft.com, ima@ietf.org Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 17:50:48 -0000 --On Wednesday, August 05, 2009 22:01 +0900 "\"Martin J. D=C3=BCrst\"" wrote: > The problem with this is that it doesn't work for cc and bcc > fields. It doesn't even work for "to:" fields with multiple entries -- see my prior note. Your observation about cc and bcc obviously makes things even worse. john From klensin@jck.com Thu Aug 6 11:01:02 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796A73A697F for ; Thu, 6 Aug 2009 11:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7W8AJv0jytB for ; Thu, 6 Aug 2009 11:01:01 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 5CAB63A698A for ; Thu, 6 Aug 2009 11:01:01 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MZ7Gt-000JwS-8a; Thu, 06 Aug 2009 14:00:59 -0400 Date: Thu, 06 Aug 2009 14:00:58 -0400 From: John C Klensin To: YAO Jiankang , Ernie Dainow , ima@ietf.org Message-ID: <078E9003777A1BC4F38A0194@PST.JCK.COM> In-Reply-To: <449526085.20415@cnnic.cn>, <001701ca163e$742fe600$236ff1da@whatisfuture> References: <449399580.17668@cnnic.cn> <449526085.20415@cnnic.cn>, <001701ca163e$742fe600$236ff1da@whatisfuture> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [EAI] Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 18:01:02 -0000 --On Thursday, August 06, 2009 10:34 +0800 YAO Jiankang wrote: >...=20 > the possible phising will be reduced if the alternate address > is only provided by smtp server. if the alternate address is > provided by MUA, the user can put any address they want such > as administartor@ebay.com or president@usa.gov.=20 Do you mean the submission server? If it is provided by a random SMTP (relay) server, I think we are in for deeper problems as well as a need to relax current requirements of 5321 about not changing messages in transit. But, even if it is the submission server, it seems to me that what you accomplish by moving responsibility there (rather than in the MUA) is to: -- Make it harder for users of many systems to provide alternate addresses, since few Submission Servers support the relevant databases for supplying alternate addresses today. At minimum, we would have to advise that RFC 4408 servers be updated to maintain databases of, and insert, that information. -- Prevent casual users and vandals from supplying alternate addresses that have nothing to do with the primary (EAI) ones but not provide a barrier higher than minor inconvenience to any serious attacker. Such an attacker could, in principle, use a compromised MSA. Of course, EAI downgrading increases an existing problem only slightly -- nothing prevents my sending out a message "From" administartor@ebay.com or president@usa.gov today.. EAI alternate addresses might serve to hide the fact that I had done that, but only with an MUA that tended to hide those addresses (and not others). >> While the server=20 >> solution offers a certain amount of transparency to the end >> user, the MUA solution is more general in that it supports a >> legacy ASCII Address that may be on a different email >> provider.=20 >=20 > when you register an email account, you can apply both the > ascii email account and non-ascii email account from the same > company or organization. We have had that conversation before. You are assuming a particular model of how MUAs, Submission Servers, and mail providers generally interact. It may be the best such model, but it isn't the only one and there is nothing, anywhere, that standardizes it or makes it a requirement for EAI implementation or deployment. There are also some useful examples of situations in which it may not be the right model. For example, assume that my Russian had not deteriorated from fluency to non-existent in the last 50 years. I might maintain a personal address of=20 =D0=B8=D0=B2=D0=B0=D0=BD@klensin.cambridge.ma.us but want to have the mail sent to a business-address mailbox if it could not be delivered there, say klensin@jck.com That would give my From: field a structure like From: <=D0=B8=D0=B2=D0=B0=D0=BD@klensin.cambridge.ma.us = > Which definitely do not reflect the same domain and might or might not reflect the same server. >... john From Shawn.Steele@microsoft.com Thu Aug 6 22:15:57 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C974D3A69A2 for ; Thu, 6 Aug 2009 22:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.911 X-Spam-Level: X-Spam-Status: No, score=-9.911 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sm9OneNpG59r for ; Thu, 6 Aug 2009 22:15:56 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 151883A67EA for ; Thu, 6 Aug 2009 22:15:56 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 6 Aug 2009 22:15:58 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.232]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Thu, 6 Aug 2009 22:15:58 -0700 From: Shawn Steele To: =?Windows-1252?Q?Martin_J=2E_D=FCrst?= , Alexey Melnikov Thread-Topic: [EAI] mailto: Thread-Index: AQHKFaeIGmPixERfJUe5n2EYugoO/5CXomAAgAAIMYCAADkpAIACLUKH Date: Fri, 7 Aug 2009 05:15:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 05:15:57 -0000 I agree, but could there be a similar approach that wouldn't break existing= mailto handling? Sent from my HTC FUZE=99, a Windows Mobile=AE smartphone from AT&T -----Original Message----- From: Martin J. D=FCrst Sent: Thursday, August 06, 2009 8:27 AM To: Alexey Melnikov Cc: fujiwara@jprs.co.jp ; Shawn Steele ; ima@ietf.org Subject: Re: [EAI] mailto: The problem with this is that it doesn't work for cc and bcc fields. Regards, Martin. On 2009/08/05 18:36, Alexey Melnikov wrote: > fujiwara@jprs.co.jp wrote: > >>> From: John C Klensin >>> if one of them contains non-ASCII elements, e.g., >>> mailto:non-ASCII-local-part@IDN-example.com or >>> mailto:bar@example.org >>> >>> nothing is lost and some small bits are gained. >>> >> I think this method is easy and enough. >> >> But I have an another idea to add new option for the mailto. >> >> >> >> > That would work as well. > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > -- #-# Martin J. D=FCrst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From yaojk@cnnic.cn Fri Aug 7 02:07:25 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04AA03A6891 for ; Fri, 7 Aug 2009 02:07:25 -0700 (PDT) X-Quarantine-ID: <1HYDggOF5Gam> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.471 X-Spam-Level: X-Spam-Status: No, score=0.471 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HYDggOF5Gam for ; Fri, 7 Aug 2009 02:07:24 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 51D823A68FE for ; Fri, 7 Aug 2009 02:07:22 -0700 (PDT) Received: (eyou send program); Fri, 07 Aug 2009 17:07:26 +0800 Message-ID: <449636046.10622@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 07 Aug 2009 17:07:26 +0800 Message-ID: <05af01ca173e$79a3f580$236ff1da@whatisfuture> From: "YAO Jiankang" To: "John C Klensin" References: <449628582.04833@cnnic.cn> Date: Fri, 7 Aug 2009 17:07:22 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: EAI WG Subject: Re: [EAI] Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 09:07:25 -0000 PiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPiBGcm9tOiAiSm9obiBDIEtsZW5zaW4i IDxrbGVuc2luQGpjay5jb20+DQo+IFRvOiAiWUFPIEppYW5rYW5nIiA8eWFvamtAY25uaWMuY24+ OyAiRXJuaWUgRGFpbm93IiA8ZWRhaW5vd0BjYS5hZmlsaWFzLmluZm8+OyA8aW1hQGlldGYub3Jn Pg0KPiBTZW50OiBGcmlkYXksIEF1Z3VzdCAwNywgMjAwOSAyOjAwIEFNDQo+IFN1YmplY3Q6IFJl OiBbRUFJXSBEb3duZ3JhZGUgc2ltcGxpZmljYXRpb25zDQo+IA0KPiANCj4gDQo+IA0KPiAtLU9u IFRodXJzZGF5LCBBdWd1c3QgMDYsIDIwMDkgMTA6MzQgKzA4MDAgWUFPIEppYW5rYW5nDQo+IDx5 YW9qa0Bjbm5pYy5jbj4gd3JvdGU6DQo+IA0KPj4uLi4gDQo+PiB0aGUgcG9zc2libGUgcGhpc2lu ZyB3aWxsIGJlIHJlZHVjZWQgaWYgdGhlIGFsdGVybmF0ZSBhZGRyZXNzDQo+PiBpcyBvbmx5IHBy b3ZpZGVkIGJ5IHNtdHAgc2VydmVyLiBpZiB0aGUgYWx0ZXJuYXRlIGFkZHJlc3MgaXMNCj4+IHBy b3ZpZGVkIGJ5IE1VQSwgdGhlIHVzZXIgY2FuIHB1dCBhbnkgYWRkcmVzcyB0aGV5IHdhbnQgc3Vj aA0KPj4gYXMgYWRtaW5pc3RhcnRvckBlYmF5LmNvbSBvciBwcmVzaWRlbnRAdXNhLmdvdi4gDQo+ IA0KPiBEbyB5b3UgbWVhbiB0aGUgc3VibWlzc2lvbiBzZXJ2ZXI/DQogIA0KeWVzLCBJIG1lYW4g dGhlIHN1Ym1pc3Npb24gc2VydmVyLg0KDQoNCj5JZiBpdCBpcyBwcm92aWRlZCBieSBhDQo+IHJh bmRvbSBTTVRQIChyZWxheSkgc2VydmVyLCBJIHRoaW5rIHdlIGFyZSBpbiBmb3IgZGVlcGVyDQo+ IHByb2JsZW1zIGFzIHdlbGwgYXMgYSBuZWVkIHRvIHJlbGF4IGN1cnJlbnQgcmVxdWlyZW1lbnRz IG9mIDUzMjENCj4gYWJvdXQgbm90IGNoYW5naW5nIG1lc3NhZ2VzIGluIHRyYW5zaXQuDQo+IA0K DQp5ZXMuDQoNCg0KPiBCdXQsIGV2ZW4gaWYgaXQgaXMgdGhlIHN1Ym1pc3Npb24gc2VydmVyLCBp dCBzZWVtcyB0byBtZSB0aGF0DQo+IHdoYXQgeW91IGFjY29tcGxpc2ggYnkgbW92aW5nIHJlc3Bv bnNpYmlsaXR5IHRoZXJlIChyYXRoZXIgdGhhbg0KPiBpbiB0aGUgTVVBKSBpcyB0bzoNCj4gDQo+ IC0tIE1ha2UgaXQgaGFyZGVyIGZvciB1c2VycyBvZiBtYW55IHN5c3RlbXMgdG8gcHJvdmlkZSBh bHRlcm5hdGUNCj4gYWRkcmVzc2VzLCBzaW5jZSBmZXcgU3VibWlzc2lvbiBTZXJ2ZXJzIHN1cHBv cnQgdGhlIHJlbGV2YW50DQo+IGRhdGFiYXNlcyBmb3Igc3VwcGx5aW5nIGFsdGVybmF0ZSBhZGRy ZXNzZXMgdG9kYXkuICBBdCBtaW5pbXVtLA0KPiB3ZSB3b3VsZCBoYXZlIHRvIGFkdmlzZSB0aGF0 IFJGQyA0NDA4IHNlcnZlcnMgYmUgdXBkYXRlZCB0bw0KPiBtYWludGFpbiBkYXRhYmFzZXMgb2Ys IGFuZCBpbnNlcnQsIHRoYXQgaW5mb3JtYXRpb24uDQoNCml0IHNlZW1zIHRoYXQgdGhlcmUgaXMg bm8gZGVmaW5pdGlvbiBhYm91dCBNVUEgZnJvbSBSRkMuIA0KDQpmcm9tIHdpa2ksICBJIGdldCB0 aGlzIGRlZmluaXRpb24gIg0KQW4gZS1tYWlsIGNsaWVudCAoYWxzbyBtYWlsIHVzZXIgYWdlbnQg KE1VQSkgb3IgZS1tYWlsIHJlYWRlcikgaXMgYSBmcm9udGVuZCBjb21wdXRlciBwcm9ncmFtIHVz ZWQgdG8gbWFuYWdlIGUtbWFpbC4NCg0KIg0KDQpub3JtYWxseSwgdGhlIHNlcnZlciB3aWxsIGtl ZXAgYWxsIHRoZSBlbWFpbCBhY2NvdW50cyBpbmZvcm1hdGlvbi4NCnRoZSBNVUEgb25seSBrZWVw cyB0aGUgcGVyc29uYWwgZW1haWwgYWNjb3VudCBpbmZvcm1hdGlvbi4NCg0Kc28gaXQgaXMgYmV0 dGVyIGlmIEkgYXNrIHRoYXQgdGhlIGFsdC1hZGRyZXNzIHNob3VsZCBiZSBrZXB0IGluIGNsaWVu dCBvciBzZXJ2ZXI/DQoNCk15IGFuc3dlciBpcyBzZXJ2ZXIuIHRoaXMgc2VydmVyIG1heSBiZSBh IHNlcnZlciB3aGljaCBydW5zIGFzIGEgbWFpbHN0b3JlLg0KDQoNCg0KPiANCj4gLS0gUHJldmVu dCBjYXN1YWwgdXNlcnMgYW5kIHZhbmRhbHMgZnJvbSBzdXBwbHlpbmcgYWx0ZXJuYXRlDQo+IGFk ZHJlc3NlcyB0aGF0IGhhdmUgbm90aGluZyB0byBkbyB3aXRoIHRoZSBwcmltYXJ5IChFQUkpIG9u ZXMNCj4gYnV0IG5vdCBwcm92aWRlIGEgYmFycmllciBoaWdoZXIgdGhhbiBtaW5vciBpbmNvbnZl bmllbmNlIHRvIGFueQ0KPiBzZXJpb3VzIGF0dGFja2VyLiAgU3VjaCBhbiBhdHRhY2tlciBjb3Vs ZCwgaW4gcHJpbmNpcGxlLCB1c2UgYQ0KPiBjb21wcm9taXNlZCBNU0EuICBPZiBjb3Vyc2UsIEVB SSBkb3duZ3JhZGluZyBpbmNyZWFzZXMgYW4NCj4gZXhpc3RpbmcgcHJvYmxlbSBvbmx5IHNsaWdo dGx5IC0tIG5vdGhpbmcgcHJldmVudHMgbXkgc2VuZGluZw0KPiBvdXQgYSBtZXNzYWdlICJGcm9t IiBhZG1pbmlzdGFydG9yQGViYXkuY29tIG9yIHByZXNpZGVudEB1c2EuZ292DQo+IHRvZGF5Li4g DQoNCnllcywgbm90aGluZyBjYW4gcHJldmVudHMgeW91ciBzZW5kaW5nIG91dCBhIG1lc3NhZ2Ug IkZyb20iIGFkbWluaXN0YXJ0b3JAZWJheS5jb20gb3IgcHJlc2lkZW50QHVzYS5nb3YgDQpiZWNh dXNlIHlvdSBhcmUgZW1haWwgZXhwZXJ0cyBhbmQga25vdyBob3cgc210cCANCnJ1bnMuIGJ1dCBt b3N0IG5vcm1hbCBlbWFpbCB1c2VycyB3aG8gZG8gbm90IGtub3cgdGhlIG1lY2hhbmlzbSBvZiB0 aGUgc210cCBoYXMgbGl0dGxlIGNoYW5jZSB0byB0cnkgIHNlbmRpbmcgb3V0IGEgbWVzc2FnZSAi RnJvbSIgYWRtaW5pc3RhcnRvckBlYmF5LmNvbSBvciBwcmVzaWRlbnRAdXNhLmdvdi4NCg0KaWYg YWx0LWFkZHJlc3MgaXMgdXNlZCBpbiBldmVyeSBlbWFpbCBjbGllbnQsIGl0IG1lYW5zIHRoYXQg ZXZlcnkgb25lIGNhbiBzZW5kIG91dCBhIG1lc3NhZ2UgIkZyb20iIGFkbWluaXN0YXJ0b3JAZWJh eS5jb20gb3IgcHJlc2lkZW50QHVzYS5nb3YgZXZlbiBoZSBpcyBhIA0KZW1haWwgYmVnaW5uZXIu DQppZiB3ZSBjYW4gYWxsb3cgdGhlIHJhbmRvbSBpbnB1dCBvZiBhbHQtYWRkcmVzcyBhdCB0aGUg ZW1haWwgY2xpZW50LCB0aGVyZSB3aWxsIGhhdmUgbW9yZSBwaGlzaW5nIHByb2JsZW1zIGluIHRo ZSBmdXR1cmUgdGhhbiBub3cuDQoNCmV2ZXJ5b25lIHdoZXRoZXIgaGUgaXMgYWR2YW5jZWQgZW1h aWwgdXNlciBvciBlbWFpbCBiaWdpbm5lciBjYW4gZG8gc29tZSBwaGlzaW5nIGlmIGhlIHdhbnRz IHRvIGRvIHNvLg0KDQpzbyBJIHByZWZlciB0aGF0IHRoZXJlIHNob3VsZCBhIG1lY2hhbmlzbSB0 byBjb250cm9sIHRoZSBhbHQtYWRkcmVzcy4NCg0KDQo+RUFJIGFsdGVybmF0ZSBhZGRyZXNzZXMg bWlnaHQgc2VydmUgdG8gaGlkZSB0aGUgZmFjdA0KPiB0aGF0IEkgaGFkIGRvbmUgdGhhdCwgYnV0 IG9ubHkgd2l0aCBhbiBNVUEgdGhhdCB0ZW5kZWQgdG8gaGlkZQ0KPiB0aG9zZSBhZGRyZXNzZXMg KGFuZCBub3Qgb3RoZXJzKS4NCj4gDQo+Pj4gV2hpbGUgdGhlIHNlcnZlciANCj4+PiBzb2x1dGlv biBvZmZlcnMgYSBjZXJ0YWluIGFtb3VudCBvZiB0cmFuc3BhcmVuY3kgdG8gdGhlIGVuZA0KPj4+ IHVzZXIsIHRoZSAgTVVBIHNvbHV0aW9uIGlzIG1vcmUgZ2VuZXJhbCBpbiB0aGF0IGl0IHN1cHBv cnRzIGENCj4+PiBsZWdhY3kgQVNDSUkgQWRkcmVzcyAgdGhhdCBtYXkgYmUgb24gYSBkaWZmZXJl bnQgZW1haWwNCj4+PiBwcm92aWRlci4gDQo+PiANCj4+IHdoZW4geW91IHJlZ2lzdGVyIGFuIGVt YWlsIGFjY291bnQsIHlvdSBjYW4gYXBwbHkgYm90aCB0aGUNCj4+IGFzY2lpIGVtYWlsIGFjY291 bnQgYW5kIG5vbi1hc2NpaSBlbWFpbCBhY2NvdW50IGZyb20gdGhlIHNhbWUNCj4+IGNvbXBhbnkg b3Igb3JnYW5pemF0aW9uLg0KPiANCj4gV2UgaGF2ZSBoYWQgdGhhdCBjb252ZXJzYXRpb24gYmVm b3JlLiAgWW91IGFyZSBhc3N1bWluZyBhDQo+IHBhcnRpY3VsYXIgbW9kZWwgb2YgaG93IE1VQXMs IFN1Ym1pc3Npb24gU2VydmVycywgYW5kIG1haWwNCj4gcHJvdmlkZXJzIGdlbmVyYWxseSBpbnRl cmFjdC4gIEl0IG1heSBiZSB0aGUgYmVzdCBzdWNoIG1vZGVsLA0KPiBidXQgaXQgaXNuJ3QgdGhl IG9ubHkgb25lIGFuZCB0aGVyZSBpcyBub3RoaW5nLCBhbnl3aGVyZSwgdGhhdA0KPiBzdGFuZGFy ZGl6ZXMgaXQgb3IgbWFrZXMgaXQgYSByZXF1aXJlbWVudCBmb3IgRUFJIGltcGxlbWVudGF0aW9u DQo+IG9yIGRlcGxveW1lbnQuICANCg0KdGhlIG1lY2hhbmlzbWUgZGVzaWduZWQgaW4gdGhlIGRy YWZ0LXlhby1lYS1kZXBsb3ltZW50IHdpbGwgaGVscCB0aGUgZGVwbG95bWVudCAgb2YgZWFpLg0K SSBtZWFuIHRoYXQgZHJhZnQteWFvLWVhLWRlcGxveW1lbnQgY2FuIHB1cnN1ZSB0byBiZSBhbiBp bmZvcm1hdGlvbmFsIG9yIGV4cGVyaW1lbnRhbCBSRkMgaW5zdGVhZCBvZiBzdGFuZGFyZGl6aW5n IGl0IG9yIG1ha2luZyBpdCBhIHJlcXVpcmVtZW50Lg0KaWYgd2UgZm9sbG93IHRoZSBtb2RlbCwg SSB0aGluayB0aGF0IGF0IGxlYXN0IHdlIGNhbiByZWR1Y2UgdGhlIHBoaXNpbmcuDQoNCg0KDQpZ YW8gSmlhbmthbmcNCkNOTklDDQoNCj5UaGVyZSBhcmUgYWxzbyBzb21lIHVzZWZ1bCBleGFtcGxl cyBvZg0KPiBzaXR1YXRpb25zIGluIHdoaWNoIGl0IG1heSBub3QgYmUgdGhlIHJpZ2h0IG1vZGVs LiAgRm9yIGV4YW1wbGUsDQo+IGFzc3VtZSB0aGF0IG15IFJ1c3NpYW4gaGFkIG5vdCBkZXRlcmlv cmF0ZWQgZnJvbSBmbHVlbmN5IHRvDQo+IG5vbi1leGlzdGVudCBpbiB0aGUgbGFzdCA1MCB5ZWFy cy4gIEkgbWlnaHQgbWFpbnRhaW4gYSBwZXJzb25hbA0KPiBhZGRyZXNzIG9mIA0KPiAgINC40LLQ sNC9QGtsZW5zaW4uY2FtYnJpZGdlLm1hLnVzDQo+IGJ1dCB3YW50IHRvIGhhdmUgdGhlIG1haWwg c2VudCB0byBhIGJ1c2luZXNzLWFkZHJlc3MgbWFpbGJveCBpZg0KPiBpdCBjb3VsZCBub3QgYmUg ZGVsaXZlcmVkIHRoZXJlLCBzYXkNCj4gICBrbGVuc2luQGpjay5jb20NCj4gVGhhdCB3b3VsZCBn aXZlIG15IEZyb206IGZpZWxkIGEgc3RydWN0dXJlIGxpa2UNCj4gICBGcm9tOiA80LjQstCw0L1A a2xlbnNpbi5jYW1icmlkZ2UubWEudXMgPGtsZW5zaW5AamNrLmNvbT4+DQo+IA0KPiBXaGljaCBk ZWZpbml0ZWx5IGRvIG5vdCByZWZsZWN0IHRoZSBzYW1lIGRvbWFpbiBhbmQgbWlnaHQgb3INCj4g bWlnaHQgbm90IHJlZmxlY3QgdGhlIHNhbWUgc2VydmVyLg0KPiANCj4+Li4uDQo+IA0KPiAgIGpv aG4NCj4= From sm@resistor.net Fri Aug 7 02:47:02 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A735428C165 for ; Fri, 7 Aug 2009 02:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0Ply1cA2XOf for ; Fri, 7 Aug 2009 02:47:01 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id C9C4E28C144 for ; Fri, 7 Aug 2009 02:47:01 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n779koBl008950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Aug 2009 02:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1249638420; x=1249724820; bh=o+fd7Zy4VnMCruyaxcvwCTiV4jZJec7McjxywtYnBf8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=1xOK/m37a14uf5dZKMwoiZGHJWjIBhVEOVqzGWI4wOMnofnC8Y60WKPA/Z3oC5vSL cnz+cyVVhqOBi3ueWQA7RPw2jlPq3wCE4gwXb/49x7o6SXXW4TYhpC17bJXXLr2MeS uF1jM5aYJSSF+HeedmcVXVkA+ELLM1V/dCvpYlLE= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=KC+bFAPFsvmRDMlcsR67zbmn4XpN8w2Gx90a//lKLf5RlcJIdy/bbGH2R6EprSplk SLolc7xOwQ2IySFBUpziZGTSIyOyVIFVMcdCQdSCB4W6578hsZwrQg+SCkA6EMMzkLe FvmHdYgD+MSmT1OZ9mJ/c9Z0SMezSqjaVlc1atQ= Message-Id: <6.2.5.6.2.20090807022223.030d76e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Aug 2009 02:46:30 -0700 To: YAO Jiankang From: SM In-Reply-To: <449636046.10622@cnnic.cn> References: <449628582.04833@cnnic.cn> <449636046.10622@cnnic.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: EAI WG Subject: Re: [EAI] Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 09:47:02 -0000 At 02:07 07-08-2009, YAO Jiankang wrote: >it seems that there is no definition about MUA from RFC. From RFC 4409: Message User Agent (MUA) A process that acts (often on behalf of a user and with a user interface) to compose and submit new messages, and process delivered messages. For delivered messages, the receiving MUA may obtain and process the message according to local conventions or, in what is commonly referred to as a split-MUA model, Post Office Protocol [POP3] or IMAP [IMAP4] is used to access delivered messages, whereas the protocol defined here (or SMTP) is used to submit messages. >so it is better if I ask that the alt-address should be kept in >client or server? A long time ago, configuration information was stored on the server. Users could override the configuration. There are advantages to having the alt-address on the server but that assumes there should be a relationship between the MUA and the MSA. Regards, -sm From klensin@jck.com Fri Aug 7 02:55:06 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB7428C183 for ; Fri, 7 Aug 2009 02:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yPLmhGGUY9U for ; Fri, 7 Aug 2009 02:55:06 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 0222F28C165 for ; Fri, 7 Aug 2009 02:53:36 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MZM8k-000Auc-9z; Fri, 07 Aug 2009 05:53:34 -0400 Date: Fri, 07 Aug 2009 05:53:33 -0400 From: John C Klensin To: Shawn Steele , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Alexey Melnikov Message-ID: <647A5AE078721CED1CDD27F1@PST.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 09:55:06 -0000 --On Friday, August 07, 2009 05:15 +0000 Shawn Steele wrote: > I agree, but could there be a similar approach that wouldn't > break existing mailto handling? >... > -----Original Message----- > From: Martin J. D=C3=BCrst > Sent: Thursday, August 06, 2009 8:27 AM >... > The problem with this is that it doesn't work for cc and bcc > fields. Shawn, The problem isn't the approach, it is the fact that mail header fields are not hierarchical and that there is no way to explicitly link two fields together as related. Any syntax that says, essentially, "this is a header field and its value, that is a header field and its value,..." is going to run into this problem. =20 What one needs is a way to link the two pieces of information --the EAI and Alternate addresses -- together as address-pairs, not separate headers (or something that has the syntax of separate headers). So, ignoring niceties of syntax, we could figure out a way to get=20 mailto:>?cc=3D> but it would cause serious problems for existing (legacy) mailto parsers and applications. Similarly, one might imagine: mailto:addr1|addr2?cc=3Daddr3|addr4 except that "|" is valid in local parts, which might imply a need for very careful parsing, probably also fouling up some existing implementations, and noting that a lot of current mailto implementations are very confused about whether=20 mailto:local-mailbox-name+subaddress@domain is valid without escaping and treat it as an invalid address; I'd expect the much-less-frequently-seen "|" to get equally bad treatment. I think this is at least part of the reason why the WG tentatively concluded that inclusion of alternate addresses would require a separate URI type rather than overloading mailto (I think incorporating a mailbox syntax that merely had UTF-8 characters in it would not be a problem -- it is, again, the alternate address syntax that is problematic). =20 john From klensin@jck.com Fri Aug 7 03:10:55 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8F853A6CAF for ; Fri, 7 Aug 2009 03:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBGjpFC0QSk3 for ; Fri, 7 Aug 2009 03:10:54 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 96C8B3A6B71 for ; Fri, 7 Aug 2009 03:10:54 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MZMPY-000BDh-GX; Fri, 07 Aug 2009 06:10:56 -0400 Date: Fri, 07 Aug 2009 06:10:55 -0400 From: John C Klensin To: YAO Jiankang Message-ID: <0FF7EAA2026743A9A143CFC2@PST.JCK.COM> In-Reply-To: <449636046.10622@cnnic.cn>, <05af01ca173e$79a3f580$236ff1da@whatisfuture> References: <449628582.04833@cnnic.cn> <449636046.10622@cnnic.cn>, <05af01ca173e$79a3f580$236ff1da@whatisfuture> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: EAI WG Subject: Re: [EAI] Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 10:10:56 -0000 --On Friday, August 07, 2009 17:07 +0800 YAO Jiankang wrote: > it seems that there is no definition about MUA from RFC. > > from wiki, I get this definition " > An e-mail client (also mail user agent (MUA) or e-mail reader) > is a frontend computer program used to manage e-mail. See RFC 5598. >.... > normally, the server will keep all the email accounts > information. the MUA only keeps the personal email account > information. > > so it is better if I ask that the alt-address should be kept > in client or server? > > My answer is server. this server may be a server which runs as > a mailstore. I think there are lots of good reasons to keep the information on the server. I think there are also lots of good reasons to keep the information on the client. The problem isn't what you ask for; it is what the standard requires. I don't think the standard can _require_, even at the level of a SHOULD, either one. If we are ever to have the information specified in the MUA, or directly by the user, then there has to be syntax for it. Now, one could remove forward-path downgrading entirely, remove the notion of in-transit downgrading (even for the backward-pointing addresses) entirely and put some language into the specs indicating that it would be perfectly reasonable (but not required) for a sending-side system (either MUA or Submission Server) to intercept an NDN that indicated non-support for the i18n extensions, modify the message by substituting all-ASCII information, and sending it back out without involving the user. That would be consistent with the principle that programs acting as agents for the user, at the user's request and presumably under the user's control, can do things for the user without explicitly involving her. That is a model that can be implemented consistent with the existing specs, so the question is whether to permit and support en-route downgrading in addition and under what circumstances to do so. >... > yes, nothing can prevents your sending out a message "From" > administartor@ebay.com or president@usa.gov because you are > email experts and know how smtp > runs. but most normal email users who do not know the > mechanism of the smtp has little chance to try sending out a > message "From" administartor@ebay.com or president@usa.gov. We have never found security by obscurity to work very well. I also note that "normal email users" are probably well-behaved people to whom the idea of faking an address would never occur. To those to whom it does occur, the knowledge is only a few keystrokes away. And the MSA-based mechanisms that are intended to prevent their doing so could be extended to MSA tests for alternate addresses as well. >... > so I prefer that there should a mechanism to control the > alt-address. Other than very aggressive measures by MSAs (e.g., permitting submission only from addresses matched to the user or that authenticate using some mechanisms), nothing is going to prevent, or even significantly reduce, abuse of alt-address other than not having alt-addresses. We've know, and discussed, that since this effort started. >... john From edainow@ca.afilias.info Fri Aug 7 04:52:55 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0597E3A67EC for ; Fri, 7 Aug 2009 04:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qfwdEFk10Fp for ; Fri, 7 Aug 2009 04:52:54 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id EBE513A6EFE for ; Fri, 7 Aug 2009 04:52:53 -0700 (PDT) Message-ID: <4A7C1585.2020904@ca.afilias.info> Date: Fri, 07 Aug 2009 07:52:37 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: YAO Jiankang References: <4A3FA114.3070007@ca.afilias.info><20090627195635.GA14125@laperouse.bortzmeyer.org><447145015.02367@cnnic.cn> <449528245.12181@cnnic.cn> <449528475.12144@cnnic.cn> In-Reply-To: <449528475.12144@cnnic.cn> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: True Cc: meldin78@hotmail.com, EAI Subject: Re: [EAI] Downgrade testing - Results X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 11:52:55 -0000 Some of your failures may be due to the environment and not the Downgrade. I ran a 'base' test by sending the email from an ASCII address to try and identify which failures are due to the environment (firewalls, network, etc.). On the Downgrade test, I received replies from all servers except these echo@nic.fr echo@tu-berlin.de echo@cnam.fr (this address does not exist and you get a reject from echo@copernic.cnam.fr) You received replies from the first two but not from three others that I did receive a reply from. This is a surprising difference. A base test might help explain it. -Ernie Dainow YAO Jiankang wrote: > btw, the implmentation is based on postfix. > could TWNIC JPRS NIDA do the similar tests and report the results? > > YAO Jiankang > CNNIC > > ----- Original Message ----- > From: "YAO Jiankang" > To: "Ernie Dainow" ; "Stephane Bortzmeyer" ; "EAI" > Sent: Thursday, August 06, 2009 11:10 AM > Subject: Re: [EAI] Downgrade testing - Results > > > >> we send to the following 10 address, with > >> >>>> * echo@generic-nic.net >>>> * echo@nic.fr >>>> * Echo@TU-Berlin.DE >>>> * echo@tu-chemnitz.de >>>> * echo@ouain.com >>>> * repondsmoi@crdp.ac-versailles.fr >>>> * echo@cnam.fr >>>> * ping@stamper.itconsult.co.uk >>>> * ping@oleane.net >>>> * check-auth@verifier.port25.com >>>> >> we get the nice response from the following 6 address >> echo@generic-nic.net >> echo@nic.fr >> Echo@TU-Berlin.DE >> echo@ouain.com >> check-auth@verifier.port25.com >> repondsmoi@crdp.ac-versailles.fr >> >> >> we get the reject information from 1 address >> echo@copernic.cnam.fr >> >> >> we can not get any response from other 3 addresses. >> >> >> >> Yao Jiankang >> CNNIC >> >> >> >> >> >> ----- Original Message ----- >> From: "Ernie Dainow" >> To: "Stephane Bortzmeyer" ; "EAI" >> Sent: Thursday, July 09, 2009 9:09 PM >> Subject: Re: [EAI] Downgrade testing - Results >> >> >> >>> These echo tests were a good suggestion. I ran a base test from an ASCII >>> address against all echo servers in the list. All responded except >>> echo@cnam.fr. Email bounced with "unknown address", so I eliminated >>> that server from the test, leaving a total of 9 echo servers. >>> >>> The success rate for receiving a response from echo servers: >>> 1) From ASCII, no downgrade 9/9 100% >>> 2) From EAI, downgrade 7/9 78% >>> >>> auth-results@verifier.port25.com provided some SpamAssassin analysis: >>> 1) BODY: Bayesian spam probability is 1 to 5% >>> 2) BODY: Bayesian spam probability is 5 to 20% >>> >>> For the downgrade test sent to individual participants the results were: >>> Total Sent 11 (all on different email domains) >>> Received 9 82% >>> Blocked 2 18% >>> >>> These are not large samples, but it is interesting to see that the >>> success rate in both tests were similar, and were in the SpamAssassin >>> range of 20% probability of spam. >>> >>> I encourage other implementers to run the same set of tests so we can >>> get a larger sample and see if there are differences between Downgrade >>> implementations. >>> >>> -Ernie >>> >>> >>> Stephane Bortzmeyer wrote: >>> >>>> On Mon, Jun 22, 2009 at 11:19:48AM -0400, >>>> Ernie Dainow wrote >>>> a message of 41 lines which said: >>>> >>>> >>>> >>>>> The Downgrade test reported on the wiki basically tested against gmail. >>>>> It would be valuable to do more testing 'in the wild' to see how >>>>> Downgrade traverses various email systems in other organizations. >>>>> >>>>> >>>> You can test against various auto-responders which send you back your >>>> message (if you know other email addresses of auto-responders, do not >>>> hesitate to publish them). >>>> >>>> * echo@generic-nic.net >>>> * echo@nic.fr >>>> * Echo@TU-Berlin.DE >>>> * echo@tu-chemnitz.de >>>> * echo@ouain.com >>>> * repondsmoi@crdp.ac-versailles.fr >>>> * echo@cnam.fr >>>> * ping@stamper.itconsult.co.uk >>>> * ping@oleane.net >>>> * check-auth@verifier.port25.com >>>> >>>> >>> _______________________________________________ >>> IMA mailing list >>> IMA@ietf.org >>> https://www.ietf.org/mailman/listinfo/ima >>> >> _______________________________________________ >> IMA mailing list >> IMA@ietf.org >> https://www.ietf.org/mailman/listinfo/ima From jyee@ca.afilias.info Fri Aug 7 05:41:24 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640FF3A6B09 for ; Fri, 7 Aug 2009 05:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBNFvBVl16tu for ; Fri, 7 Aug 2009 05:41:23 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id B80FF3A6EB3 for ; Fri, 7 Aug 2009 05:41:21 -0700 (PDT) References: <449628582.04833@cnnic.cn> <449636046.10622@cnnic.cn> <6.2.5.6.2.20090807022223.030d76e8@resistor.net> Message-Id: From: Joseph Yee To: SM In-Reply-To: <6.2.5.6.2.20090807022223.030d76e8@resistor.net> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7A400) Date: Fri, 7 Aug 2009 08:35:15 -0400 X-Mailer: iPhone Mail (7A400) X-Authenticated: True Cc: EAI WG Subject: Re: [EAI] Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 12:41:24 -0000 Sent from my iPhone On 2009-08-07, at 5:46 AM, SM wrote: > At 02:07 07-08-2009, YAO Jiankang wrote: >> it seems that there is no definition about MUA from RFC. > > From RFC 4409: > > Message User Agent (MUA) > > A process that acts (often on behalf of a user and with a user > interface) to compose and submit new messages, and process delivered > messages. > > For delivered messages, the receiving MUA may obtain and process the > message according to local conventions or, in what is commonly > referred to as a split-MUA model, Post Office Protocol [POP3] or > IMAP > [IMAP4] is used to access delivered messages, whereas the protocol > defined here (or SMTP) is used to submit messages. > >> so it is better if I ask that the alt-address should be kept in >> client or server? > > A long time ago, configuration information was stored on the > server. Users could override the configuration. There are > advantages to having the alt-address on the server but that assumes > there should be a relationship between the MUA and the MSA. Agreed with SM, this is a design decision, up to the service provider. From WG perspective we can make recommendation or write best practice. I don't think we can say it must be MUA or MSA. Personal thought: Header 'From' controlled by user in most cases today, some call it identity in MUA. I would guess no behavior change because of EAI. Regards, Joseph > > Regards, > -sm > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From klensin@jck.com Fri Aug 7 06:14:39 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A71D3A6F10 for ; Fri, 7 Aug 2009 06:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vAJhBJF5ili for ; Fri, 7 Aug 2009 06:14:38 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id ABD4228C1CA for ; Fri, 7 Aug 2009 06:14:13 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MZPGk-000F3q-II; Fri, 07 Aug 2009 09:14:02 -0400 Date: Fri, 07 Aug 2009 09:14:01 -0400 From: John C Klensin To: Joseph Yee , SM Message-ID: <3374E1CD319593F1A64EFC46@PST.JCK.COM> In-Reply-To: References: <449628582.04833@cnnic.cn> <449636046.10622@cnnic.cn> <6.2.5.6.2.20090807022223.030d76e8@resistor.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: EAI WG Subject: Re: [EAI] Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 13:14:39 -0000 --On Friday, August 07, 2009 08:35 -0400 Joseph Yee wrote: >... > Personal thought: > Header 'From' controlled by user in most cases today, some > call it identity in MUA. I would guess no behavior change > because of EAI. Unless an alternative address must be specified there, in which case all of the MUA's identity (or equivalent) mechanisms must be rewritten. Note that From: mailbox1, mailbox2 While rarely used, is perfectly valid, even though two MAIL commands for the same message (with different addresses) are not. If one assumed that a reply to one of the addresses was sufficient, then From: i18n-local-part@IDN, ascii-local-part@ascii-domain might accomplish quite a lot, without new syntax. I would assume, but don't know, that many legacy MUAs which are used to dealing with all sorts of garbage anyway would either accept the i18n address without noticing or would complain about it, drop it, and continue with the other address. As a side-effect, that would eliminate most of the claim about binding of the two addresses, but, as Yao has pointed out (and as we discussed perhaps a year ago), that claim isn't very strong anyway and might cause problems. Beyond that, I don't have any idea how that dual-From syntax would work with most MUAs or how easy the adaptation would be to make it work, but it might be useful for someone to examine the case in which we had: MAIL FROM: alt-address="ascii-local-part@ascii-domain" ... From: i18n-local-part@IDN, ascii-local-part@ascii-domain ... and all forward-pointing addresses in ASCII. That approach would clearly be wrong for forward-pointing addresses, where each address is expected to be a separate one, but the semantics of multiple From: elements have always been a little unclear... unclear enough that assuming that they loosely identify the same entity is actually not much of a stretch. Just thinking while typing here... this may be a dumb idea. john From chl@clerew.man.ac.uk Fri Aug 7 07:10:09 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3B13A6D5F for ; Fri, 7 Aug 2009 07:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDGGaIlrLGiP for ; Fri, 7 Aug 2009 07:10:07 -0700 (PDT) Received: from v-smtp-auth-relay-6.gradwell.net (v-smtp-auth-relay-6.gradwell.net [79.135.125.112]) by core3.amsl.com (Postfix) with ESMTP id 83EF428C1DE for ; Fri, 7 Aug 2009 07:08:58 -0700 (PDT) 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 v-smtp-auth-relay-6.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4a7c357d.6691.157 for ima@ietf.org; Fri, 7 Aug 2009 15:09:01 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id n77E8nZ3024577 for ; Fri, 7 Aug 2009 15:08:50 +0100 (BST) Date: Fri, 07 Aug 2009 15:08:49 +0100 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <647A5AE078721CED1CDD27F1@PST.JCK.COM> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <647A5AE078721CED1CDD27F1@PST.JCK.COM> User-Agent: Opera Mail/9.25 (SunOS) Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 14:10:09 -0000 On Fri, 07 Aug 2009 10:53:33 +0100, John C Klensin wrote: > So, ignoring niceties of syntax, we could figure out a way to > get > mailto:>?cc=> > but it would cause serious problems for existing (legacy) mailto > parsers and applications. Not necessarily. If some browser fails to parse is as a valid mailto:, it will not even highlight it, so you will not be able to click on it, so you will be forced to transcribe it to your MUA manually, which is a nuisance, but no huge Big Deal. Ditto if your browser fails to parse it when you do cliock on it. Alternatively, if the existing browser implemention is sufficiently crude, it will just pass the whole thing off to whatever MUA it has been configured to use, in which case go back to Step 1. So is there any reqlistic scenario in which some legacy implementation might actually try to send it to a non-existent address, or otherwise mistreat the message (perhaps even silently)? If not, then I think the problem/nuisance can be tolerated. -- 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 From jyee@ca.afilias.info Fri Aug 7 08:42:22 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0057228C1E8 for ; Fri, 7 Aug 2009 08:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyYU0Vf6-3u9 for ; Fri, 7 Aug 2009 08:42:20 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 828843A6F56 for ; Fri, 7 Aug 2009 08:42:11 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1MZRa9-0004ZO-7v; Fri, 07 Aug 2009 15:42:13 +0000 Received: from [207.219.45.45] (helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MZRa9-000121-42; Fri, 07 Aug 2009 15:42:13 +0000 From: Joseph Yee To: Charles Lindsey In-Reply-To: References: <647A5AE078721CED1CDD27F1@PST.JCK.COM> Message-Id: <1EE7EBC0-CB1A-4429-85E7-0B736774DBA2@ca.afilias.info> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 7 Aug 2009 11:42:12 -0400 X-Mailer: Apple Mail (2.935.3) Cc: IMA Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 15:42:22 -0000 mailto also used by mailing list, which reaches many desktop based MUA, so it's not only browsers. -joseph On 7-Aug-09, at 10:08 AM, Charles Lindsey wrote: > On Fri, 07 Aug 2009 10:53:33 +0100, John C Klensin > wrote: > >> So, ignoring niceties of syntax, we could figure out a way to >> get >> mailto:>?cc=> >> but it would cause serious problems for existing (legacy) mailto >> parsers and applications. > > Not necessarily. If some browser fails to parse is as a valid > mailto:, it will not even highlight it, so you will not be able to > click on it, so you will be forced to transcribe it to your MUA > manually, which is a nuisance, but no huge Big Deal. Ditto if your > browser fails to parse it when you do cliock on it. > > Alternatively, if the existing browser implemention is sufficiently > crude, it will just pass the whole thing off to whatever MUA it has > been configured to use, in which case go back to Step 1. > > So is there any reqlistic scenario in which some legacy > implementation might actually try to send it to a non-existent > address, or otherwise mistreat the message (perhaps even silently)? > If not, then I think the problem/nuisance can be tolerated. > > -- > 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://www.ietf.org/mailman/listinfo/ima From klensin@jck.com Fri Aug 7 09:25:42 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9EA3A6BCF for ; Fri, 7 Aug 2009 09:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niBOM1Bfkr5r for ; Fri, 7 Aug 2009 09:25:41 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 6DD123A68C8 for ; Fri, 7 Aug 2009 09:25:41 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MZSG8-000JSC-Ai; Fri, 07 Aug 2009 12:25:36 -0400 Date: Fri, 07 Aug 2009 12:25:35 -0400 From: John C Klensin To: Joseph Yee , Charles Lindsey Message-ID: <083CC160C976BF6D530FAED0@PST.JCK.COM> In-Reply-To: <1EE7EBC0-CB1A-4429-85E7-0B736774DBA2@ca.afilias.info> References: <647A5AE078721CED1CDD27F1@PST.JCK.COM> <1EE7EBC0-CB1A-4429-85E7-0B736774DBA2@ca.afilias.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IMA Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 16:25:42 -0000 --On Friday, August 07, 2009 11:42 -0400 Joseph Yee wrote: > mailto also used by mailing list, which reaches many desktop > based MUA, so it's not only browsers. Yes, thanks. In addition, note that RFC 5335 appears to require the syntax > I.e., that leading FWS before the second "<" is not optional. If we transpose the address directly into a "mailto" URL, that would imply mailto:UTF8-mailbox which doesn't parse at all, leading to a requirement for either mailto:> which EAI-unaware applications would presumably treat as at least one parsing error, maybe two, or > creating an exception to the rule that URIs don't need to be surrounded by brackets or quotes. So I'm not convinced by Charles's analysis even for browsers. john > > -joseph > > On 7-Aug-09, at 10:08 AM, Charles Lindsey wrote: > >> On Fri, 07 Aug 2009 10:53:33 +0100, John C Klensin >> wrote: >> >>> So, ignoring niceties of syntax, we could figure out a way to >>> get >>> mailto:>?cc=> >>> but it would cause serious problems for existing (legacy) >>> mailto parsers and applications. >> >> Not necessarily. If some browser fails to parse is as a valid >> mailto:, it will not even highlight it, so you will not be >> able to click on it, so you will be forced to transcribe it >> to your MUA manually, which is a nuisance, but no huge Big >> Deal. Ditto if your browser fails to parse it when you do >> cliock on it. >> >> Alternatively, if the existing browser implemention is >> sufficiently crude, it will just pass the whole thing off >> to whatever MUA it has been configured to use, in which >> case go back to Step 1. >> >> So is there any reqlistic scenario in which some legacy >> implementation might actually try to send it to a >> non-existent address, or otherwise mistreat the message >> (perhaps even silently)? If not, then I think the >> problem/nuisance can be tolerated. >> >> -- >> 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://www.ietf.org/mailman/listinfo/ima > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From edainow@ca.afilias.info Sat Aug 8 08:54:30 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DE5228C20A for ; Sat, 8 Aug 2009 08:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.536 X-Spam-Level: X-Spam-Status: No, score=-5.536 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-HSN-leS1OF for ; Sat, 8 Aug 2009 08:54:29 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 44E8D28C21E for ; Sat, 8 Aug 2009 08:53:57 -0700 (PDT) Message-ID: <4A7D9F86.2070708@ca.afilias.info> Date: Sat, 08 Aug 2009 11:53:42 -0400 From: Ernie Dainow User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "ima@ietf.org" , Harald Tveit Alvestrand References: <4A7852F2.6010506@ca.afilias.info> <4A7ABAC7.2040800@alvestrand.no> In-Reply-To: <4A7ABAC7.2040800@alvestrand.no> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated: True Subject: Re: [EAI] Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 15:54:30 -0000
Harald Alvestrand wrote:
Ernie Dainow wrote:
.... We can greatly simplify Downgrade by limiting the design goals to support only essential cases and make clear that Downgrade is an interim feature, is not perfect and does not provide a complete audit trail.

1. As recommended in 4.2 of  draft-ietf-eai-email-clients and in various emails on the EAI list, we should consider downgrade of forward-pointing (recipient) addresses as a configuration error and not something that Downgrade needs to support. Then we can remove Alternate Addresses for recipients. I think this would also allow us to redesign Downgrade without the double angle bracket syntax which seems to be the source of a lot of compatibility and security concerns.
As I said at the Stockholm meeting:

I'm fine with this, as long as we're able to satisfy the triangular scenario.

>From the long-expired scenarios draft:

2.5.  An i18mail user sends to one ascii user and one i18mail user

   In this scenario, A sends to B and X; both reply.

   Precondition: A and B have to have valid ASCII addresses.

   Requirement: Through some series of steps, A must be able to get a
   message to both B and X; through some series of steps, B and X must
   be able to reply to each other and to A. X must not require
   information outside of what is included in the message to get a
   message to B.

   Possible non-requirements (for discussion):

   o  Maybe the messages to B and X don't need to be exactly the same.

   o  Maybe B doesn't need to see or use A's i18n-address when he's
      replying to A and X.

   o  Maybe X doesn't need to see A's address exactly the same on the
      message from A and the reply from B.
The way this is satisfied in the current spec is that in the headers of the message from A to X, B's address is in <unicode <ascii>> form, and will be turned into <ascii> at the downgrade gateway.

If we drop the <unicode <ascii>> form from the headers, how will X know what B's ASCII address is?

Simplifying downgrade comes at a cost. We need to identify what we lose and compare it to the gains.

For the triangular case, we lose the email path X -> B, but we have
A <-> B
A <-> X
B -> X
So we lose 1/6 connections, 17%. This is less than the failures we have seen from several Downgrade tests based on current spec (20%).

Actually, even with double angle brackets for recipients, the triangular case will fail in many cases. In practice, we have concluded that someone with a UTF8 address can generally receive EAI email, otherwise they have a configuration error. So if A has B's UTF8 address and assumes that B will be able to receive EAI email, A won't bother to enter B's alternate address and X->B will fail. This is especially true if A is in an environment where an ASCII keyboard is unfamiliar or difficult to use.

    -Ernie Dainow





 
From Shawn.Steele@microsoft.com Sat Aug 8 14:37:46 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A33728C1E3 for ; Sat, 8 Aug 2009 14:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1YcBnba6o0N for ; Sat, 8 Aug 2009 14:37:45 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 49C7928C1DD for ; Sat, 8 Aug 2009 14:37:45 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.99.4; Sat, 8 Aug 2009 14:37:48 -0700 Received: from tk5ex14mbxc105.redmond.corp.microsoft.com ([169.254.2.232]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi; Sat, 8 Aug 2009 14:37:47 -0700 From: Shawn Steele To: John C Klensin , "ima@ietf.org" Thread-Topic: [EAI] mailto: Thread-Index: AQHKFaeIGmPixERfJUe5n2EYugoO/5CctaFZ Date: Sat, 8 Aug 2009 21:37:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2009 21:37:46 -0000 I'm happy with that logic... Esp if it means skipping downgrade and getting= the rest done faster:) Sent from my HTC FUZE=99, a Windows Mobile=AE smartphone from AT&T -----Original Message----- From: John C Klensin Sent: Wednesday, August 05, 2009 1:34 AM To: Shawn Steele ; ima@ietf.org Subject: Re: [EAI] mailto: --On Wednesday, 05 August, 2009 07:23 +0000 Shawn Steele wrote: >... > Specifically I meant that I don't think the <> downgrade > syntax is helpful in mailto: since nobody's enabled by it and > anyone that was updated to understand the <> in mailto: > wouldn't need the downgrade for mailto:. I think this (your observation and that from Charles) is a corollary of some growing concern about forward-pointing addresses and downgrade... see Ernie's recent note. I also observe that, for mailto, there is an already-deployed alternative for two-address mailto. We see it all the time in messages and text, usually as mailto:foo@example.com or mailto:bar@example.org or even mailto:foo@example.com (preferred) or mailto:bar@example.org if one of them contains non-ASCII elements, e.g., mailto:non-ASCII-local-part@IDN-example.com or mailto:bar@example.org nothing is lost and some small bits are gained. That also suggests a way to do forward-pointing robustness on an individual message basis. Again, it is an extension of something common. Suppose I have two addresses for you, Shawn.Steele@microsoft.com and a hotmail address, shawnsteele3@hotmail.com (I am obviously just making up the second). I know you are taking some vacation, I want to be sure to reach you, but I don't know which one you are most likely to read and don't even know if you are still maintaining the hypothetical hotmail account. To maximize the odds of something getting through, I send the message to one address, copying the other. If one message gets through and the other bounces, no problem. The worst case is that you get two copies and I apologize later. On that model, the header syntax for forward-pointing alternate addresses (without all of the complications of downgrading) is To; Shawn.Steele@microsoft.com cc: shawnsteele3@hotmail.com The EAI alternative is obvious. What disappears is the complexity of downgrading those addresses, the security and other concerns about linked alternative addresses (the linkage here is entirely in the mind of the sender) and the need to change infrastructure -- not only the <... <...>> form, but address book formats, message store formats, etc.-- to accommodate the formal alternate addresses. > In downgraded headers <> could be interesting, except as > mentioned earlier that there are few scenarios where > downgraded headers are actually round-tripped an made use of. Yep. john From harald@alvestrand.no Sun Aug 9 07:47:42 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B869A3A6BEF for ; Sun, 9 Aug 2009 07:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfYPNC35Kxgz for ; Sun, 9 Aug 2009 07:47:41 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 946003A69D7 for ; Sun, 9 Aug 2009 07:47:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C582639E18F; Sun, 9 Aug 2009 16:47:43 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no 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 v4GKcs0Ku6QN; Sun, 9 Aug 2009 16:47:39 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id D2AA439E0B8; Sun, 9 Aug 2009 16:47:38 +0200 (CEST) Message-ID: <4A7EE188.9060202@alvestrand.no> Date: Sun, 09 Aug 2009 16:47:36 +0200 From: Harald Tveit Alvestrand User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Ernie Dainow References: <4A7852F2.6010506@ca.afilias.info> <4A7ABAC7.2040800@alvestrand.no> <4A7D9F86.2070708@ca.afilias.info> In-Reply-To: <4A7D9F86.2070708@ca.afilias.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ima@ietf.org" Subject: Re: [EAI] Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 14:47:42 -0000 Ernie Dainow skrev: > > Harald Alvestrand wrote: >> Ernie Dainow wrote: >>> .... We can greatly simplify Downgrade by limiting the design goals >>> to support only essential cases and make clear that *Downgrade is an >>> interim feature, is not perfect and does not provide a complete >>> audit trail*. >>> >>> 1. As recommended in 4.2 of draft-ietf-eai-email-clients and in >>> various emails on the EAI list, we should consider downgrade of >>> forward-pointing (recipient) addresses as a configuration error and >>> not something that Downgrade needs to support. Then we can remove >>> Alternate Addresses for recipients. I think this would also allow us >>> to redesign Downgrade without the double angle bracket syntax which >>> seems to be the source of a lot of compatibility and security concerns. >> As I said at the Stockholm meeting: >> >> I'm fine with this, as long as we're able to satisfy the triangular >> scenario. >> >> From the long-expired scenarios draft: >> >>> 2.5. An i18mail user sends to one ascii user and one i18mail user >>> >>> In this scenario, A sends to B and X; both reply. >>> >>> Precondition: A and B have to have valid ASCII addresses. >>> >>> Requirement: Through some series of steps, A must be able to get a >>> message to both B and X; through some series of steps, B and X must >>> be able to reply to each other and to A. X must not require >>> information outside of what is included in the message to get a >>> message to B. >>> >>> Possible non-requirements (for discussion): >>> >>> o Maybe the messages to B and X don't need to be exactly the same. >>> >>> o Maybe B doesn't need to see or use A's i18n-address when he's >>> replying to A and X. >>> >>> o Maybe X doesn't need to see A's address exactly the same on the >>> message from A and the reply from B. >> The way this is satisfied in the current spec is that in the headers >> of the message from A to X, B's address is in > form, >> and will be turned into at the downgrade gateway. >> >> If we drop the > form from the headers, how will X >> know what B's ASCII address is? >> > Simplifying downgrade comes at a cost. We need to identify what we > lose and compare it to the gains. > > For the triangular case, we lose the email path X -> B, but we have > A <-> B > A <-> X > B -> X > So we lose 1/6 connections, 17%. This is less than the failures we > have seen from several Downgrade tests based on current spec (20%). Any more insight into *why* those 2 out of 10 tests failed? > > Actually, even with double angle brackets for recipients, the > triangular case will fail in many cases. In practice, we have > concluded that someone with a UTF8 address can generally receive EAI > email, otherwise they have a configuration error. So if A has B's UTF8 > address and assumes that B will be able to receive EAI email, A won't > bother to enter B's alternate address and X->B will fail. This is > especially true if A is in an environment where an ASCII keyboard is > unfamiliar or difficult to use. I'm not dead set against making this scenario impossible. I'm dead set against making this scenario impossible without an explicit decision to do so. What do others think of this scenario? Harald From klensin@jck.com Sun Aug 9 16:30:12 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C9E3A6C8F for ; Sun, 9 Aug 2009 16:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8XgxyxV8hWq for ; Sun, 9 Aug 2009 16:30:11 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 47C313A6987 for ; Sun, 9 Aug 2009 16:30:11 -0700 (PDT) Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1MaHq7-0003bb-QA; Sun, 09 Aug 2009 19:30:12 -0400 Date: Sun, 09 Aug 2009 19:30:09 -0400 From: John C Klensin To: Harald Tveit Alvestrand , Ernie Dainow Message-ID: In-Reply-To: <4A7EE188.9060202@alvestrand.no> References: <4A7852F2.6010506@ca.afilias.info> <4A7ABAC7.2040800@alvestrand.no> <4A7D9F86.2070708@ca.afilias.info> <4A7EE188.9060202@alvestrand.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 23:30:12 -0000 --On Sunday, August 09, 2009 4:47 PM +0200 Harald Tveit Alvestrand wrote: > Ernie Dainow skrev: >> >> Harald Alvestrand wrote: >>> Ernie Dainow wrote: >>>> .... We can greatly simplify Downgrade by limiting the >>>> design goals to support only essential cases and make >>>> clear that *Downgrade is an interim feature, is not >>>> perfect and does not provide a complete audit trail*. >>>> >>>> 1. As recommended in 4.2 of draft-ietf-eai-email-clients >>>> and in various emails on the EAI list, we should consider >... >> Actually, even with double angle brackets for recipients, the >> triangular case will fail in many cases. In practice, we have >> concluded that someone with a UTF8 address can generally >> receive EAI email, otherwise they have a configuration >> error. So if A has B's UTF8 address and assumes that B will >> be able to receive EAI email, A won't bother to enter B's >> alternate address and X->B will fail. This is especially >> true if A is in an environment where an ASCII keyboard is >> unfamiliar or difficult to use. > I'm not dead set against making this scenario impossible. I'm > dead set against making this scenario impossible without an > explicit decision to do so. > > What do others think of this scenario? Harald, While I'm trying to keep an open mind on this, I'm increasingly coming to the conclusion that the number of cases for which full downgrade capability is going to be helpful --i.e., it will work and there is no practical alternative-- is much smaller than we believed a year or so ago. Ernie's reasoning, which I believe to be correct, further narrows that range of cases. I also believe that full Downgrade capability as now specified carries real costs -- more expensive and complex EAI implementations and therefore probably slower and fewer ones, need to carry the artifacts of a transitional facility forever, consequences to legacy implementations that could result in lost mail (not just bounces). And, of course, there are the marginal security risks and opportunities for (perhaps invitations to) bad behavior that Yao has pointed out, complications for header-signing procedures, etc. When I weigh those costs against the benefits of Downgrading with forward-pointing alternate addresses, I think we should probably be considering other alternatives. Certainly moving the scenario you identify from "unlikely" (at least for people using non-Latin-based scripts and keyboards) to "impossible" is one of those alternatives. john From chl@clerew.man.ac.uk Mon Aug 10 02:40:59 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E173A6E0D for ; Mon, 10 Aug 2009 02:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EVfMEu4og+A for ; Mon, 10 Aug 2009 02:40:53 -0700 (PDT) Received: from v-smtp-auth-relay-3.gradwell.net (v-smtp-auth-relay-3.gradwell.net [79.135.125.42]) by core3.amsl.com (Postfix) with ESMTP id A23213A6DAF for ; Mon, 10 Aug 2009 02:40:51 -0700 (PDT) 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 v-smtp-auth-relay-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4a7feb1f.b7b.93 for ima@ietf.org; Mon, 10 Aug 2009 10:40:47 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id n7A9ebsj005035 for ; Mon, 10 Aug 2009 10:40:39 +0100 (BST) Date: Mon, 10 Aug 2009 10:40:37 +0100 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <647A5AE078721CED1CDD27F1@PST.JCK.COM> <1EE7EBC0-CB1A-4429-85E7-0B736774DBA2@ca.afilias.info> <083CC160C976BF6D530FAED0@PST.JCK.COM> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <083CC160C976BF6D530FAED0@PST.JCK.COM> User-Agent: Opera Mail/9.25 (SunOS) Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 09:40:59 -0000 On Fri, 07 Aug 2009 17:25:35 +0100, John C Klensin wrote: > --On Friday, August 07, 2009 11:42 -0400 Joseph Yee > wrote: > >> mailto also used by mailing list, which reaches many desktop >> based MUA, so it's not only browsers. Indeed, but the same conditions apply. Either 1. The mailing list fails to parse the mailto, and refuses to enter the address into the mailing list. But the human get to see there is a problem and can try something else. 2. The mailing list accepts the address, and naively attempts to forware mail to it as-is. The recipient server either understands it and forwards it, of doen't and rejects it. 3. As above, but whatever bounce messages or error responses are generated (either by the mailing list, or that server) get lost silently. This is the case we want to avoid (because the human is never warned there is a problem). So how likely is this case? > > Yes, thanks. > > In addition, note that RFC 5335 appears to require the syntax > > > > I.e., that leading FWS before the second "<" is not optional. Was there a reason for that, or it is a bug in RFC 5335? > > If we transpose the address directly into a "mailto" URL, that > would imply > > mailto:UTF8-mailbox I would expect it to become mailto:UTF8-mailbox%20 Actually, life would become much simpler if mailto allowed the syntax mailto: I already find it some problem to remember which protocols expect you to type in the <...> and which don't (for example, when typing Message-IDs in NNTP - <...> is actually requied in that case, but not in the news URL -news:message@id is correct, news: is not). If there were a general relaxation to allow <...> in all comparable URI situations, life would become simpler, and generalization to more complicated forms of or ot would become much easier. > which doesn't parse at all, leading to a requirement for either > mailto:> > which EAI-unaware applications would presumably treat as at > least one parsing error, maybe two, or Yes, but I have no problem with parsing errors during changeover from legacy software, provided the error is immediately apparent to some relevant human. -- 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 From fujiwara@jprs.co.jp Mon Aug 10 03:39:59 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3513A6E47 for ; Mon, 10 Aug 2009 03:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.052 X-Spam-Level: * X-Spam-Status: No, score=1.052 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wt6bjBANQB3 for ; Mon, 10 Aug 2009 03:39:59 -0700 (PDT) Received: from g.pyon.org (unknown [164.46.243.40]) by core3.amsl.com (Postfix) with SMTP id CE56E3A6BBF for ; Mon, 10 Aug 2009 03:39:58 -0700 (PDT) Received: (qmail 20385 invoked by uid 0); 10 Aug 2009 07:53:21 -0000 Received: from 73.162.192.61.tokyo.global.alpha-net.ne.jp (HELO f.pyon.org) (61.192.162.73) by v00-040.243.046.164.fs-user.net with SMTP; 10 Aug 2009 07:53:21 -0000 Received: (qmail 81417 invoked from network); 10 Aug 2009 16:53:21 +0900 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 Aug 2009 16:53:21 +0900 Date: Mon, 10 Aug 2009 16:53:21 +0900 (JST) Message-Id: <20090810.165321.450985660335310996.fujiwara@pyon.org> To: ima@ietf.org From: fujiwara@jprs.co.jp X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [EAI] MIME Body part header fields X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 10:39:59 -0000 Dear all, The header fields downgrading is hard to implement. But I think implementing the MIME body part header fields downgrading is harder than the header field downgrading. Because all MTAs that supprt downgrading must parse whole message body and MIME structure. Result of enabing non-ASCII characters in MIME body part headers, all MTA which supports UTF8SMTP with/without downgrading must parse all MIME body part headers which contain non-ASCII characters or not if it confronts UTF8SMTP un-aware servers (even if the header fields do not contain non-ASCII characters). -- Kazunori Fujiwara, JPRS From klensin@jck.com Mon Aug 10 05:02:46 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E61C28C0F3 for ; Mon, 10 Aug 2009 05:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ml+caFFUalhv for ; Mon, 10 Aug 2009 05:02:40 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id F01393A6D25 for ; Mon, 10 Aug 2009 05:02:39 -0700 (PDT) Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1MaTaL-000HhL-Ro; Mon, 10 Aug 2009 08:02:42 -0400 Date: Mon, 10 Aug 2009 08:02:39 -0400 From: John C Klensin To: Charles Lindsey , IMA Message-ID: <89B8C9B92592D42D143000BB@[192.168.1.110]> In-Reply-To: References: <647A5AE078721CED1CDD27F1@PST.JCK.COM> <1EE7EBC0-CB1A-4429-85E7-0B736774DBA2@ca.afilias.info> <083CC160C976BF6D530FAED0@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 12:02:46 -0000 --On Monday, August 10, 2009 10:40 AM +0100 Charles Lindsey wrote: > On Fri, 07 Aug 2009 17:25:35 +0100, John C Klensin > wrote: > >> --On Friday, August 07, 2009 11:42 -0400 Joseph Yee >> wrote: >> >>> mailto also used by mailing list, which reaches many desktop >>> based MUA, so it's not only browsers. > > Indeed, but the same conditions apply. Either > 1. The mailing list fails to parse the mailto, and refuses to > enter the address into the mailing list. But the human get to > see there is a problem and can try something else. > 2. The mailing list accepts the address, and naively attempts > to forware mail to it as-is. The recipient server either > understands it and forwards it, of doen't and rejects it. > 3. As above, but whatever bounce messages or error responses > are generated (either by the mailing list, or that server) get > lost silently. This is the case we want to avoid (because the > human is never warned there is a problem). So how likely is > this case? Charles, Even in the less complicated times of long ago, the typical behavior of much mailing list software upon finding an unparseable mailbox string was to write a log entry and proceed, not do something overt and loud to warn anyone. I know of very few people who manage large lists who study the logs every day, especially for warnings about trash addresses. The place this sort of problem is most likely to be caught and noticed is in the UI by which mailbox strings are added to the mailing list. Some of those are fairly dumb, some relatively smart. The options they present differ, and some try to figure out what the user meant using heuristics that don't know anything about EAI. For example, one that I worked with for a while believed that there were only kinds of addresses: PersonalName WSP and mailbox and would leave it to delivery time to sort out deliverability because people routinely omit the quotes when required around the PersonalName (and supply them when they are not needed), > would be parsed into PersonalName = " "ascii-mailbox>" That might produce a message back to the subscribing user, or might not. It might just produce a confirming message that would look ok to someone who was used to EAI addresses and not paying a lot of attention (remember, we are talking about users here). It might produce a log entry when the software concluded that ">" was not a valid element of a xx21 domain, or might hand the string off to the mailing list software (typically by writing it into a file) which, in turn, might just drop the address containing an invalid domain from the list. So the odds of a competent human seeing and paying attention to a notification are actually not that high. john From harald@alvestrand.no Mon Aug 10 07:38:27 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9CA63A6DA9 for ; Mon, 10 Aug 2009 07:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngRON6ir1bZj for ; Mon, 10 Aug 2009 07:38:27 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id E81843A6E84 for ; Mon, 10 Aug 2009 07:38:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 60F2039E1F5; Mon, 10 Aug 2009 16:38:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no 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 1TujREdB7U2G; Mon, 10 Aug 2009 16:38:25 +0200 (CEST) Received: from [172.16.58.56] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 9C47D39E089; Mon, 10 Aug 2009 16:38:25 +0200 (CEST) Message-ID: <4A8030BB.2070502@alvestrand.no> Date: Mon, 10 Aug 2009 16:37:47 +0200 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Charles Lindsey References: <647A5AE078721CED1CDD27F1@PST.JCK.COM> <1EE7EBC0-CB1A-4429-85E7-0B736774DBA2@ca.afilias.info> <083CC160C976BF6D530FAED0@PST.JCK.COM> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IMA Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 14:38:27 -0000 Charles Lindsey wrote: > On Fri, 07 Aug 2009 17:25:35 +0100, John C Klensin > wrote: > >> --On Friday, August 07, 2009 11:42 -0400 Joseph Yee >> wrote: >> >>> mailto also used by mailing list, which reaches many desktop >>> based MUA, so it's not only browsers. > > Indeed, but the same conditions apply. Either > 1. The mailing list fails to parse the mailto, and refuses to enter > the address into the mailing list. But the human get to see there is a > problem and can try something else. Joseph was talking about MUAs using mailto: URLs set by mailing lists, not mailto: being part of the command language for mailing list servers. > 2. The mailing list accepts the address, and naively attempts to > forware mail to it as-is. The recipient server either understands it > and forwards it, of doen't and rejects it. > 3. As above, but whatever bounce messages or error responses are > generated (either by the mailing list, or that server) get lost > silently. This is the case we want to avoid (because the human is > never warned there is a problem). So how likely is this case? From McQuilWP@pobox.com Mon Aug 10 09:53:13 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B90A3A6B34 for ; Mon, 10 Aug 2009 09:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbE6MyPy9m0R for ; Mon, 10 Aug 2009 09:53:12 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id D43D63A6A99 for ; Mon, 10 Aug 2009 09:53:12 -0700 (PDT) Received: from localhost.localdomain (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id A09D924F93; Mon, 10 Aug 2009 12:53:15 -0400 (EDT) Received: from MCQWP2 (unknown [68.107.60.165]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPA id E9E6C24F92; Mon, 10 Aug 2009 12:53:12 -0400 (EDT) Date: Mon, 10 Aug 2009 09:53:05 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <34665709.20090810095305@pobox.com> To: IMA Discussion In-Reply-To: References: <647A5AE078721CED1CDD27F1@PST.JCK.COM> <1EE7EBC0-CB1A-4429-85E7-0B736774DBA2@ca.afilias.info> <083CC160C976BF6D530FAED0@PST.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 4C391284-85CE-11DE-942B-AEF1826986A2-02871704!a-pb-sasl-sd.pobox.com Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 16:53:13 -0000 On Mon, 2009-08-10, Charles Lindsey wrote: >> In addition, note that RFC 5335 appears to require the syntax >> > >> >> I.e., that leading FWS before the second "<" is not optional. > Was there a reason for that, or it is a bug in RFC 5335? Looking back through the archives, I find that I objected to this on 2007 Mar 25: http://www.ietf.org/mail-archive/web/ima/current/msg01621.html but when there was a response about vague concerns for parsing, I apparently dropped the ball and did not press the point. Mea culpa. Looking farther back, I can't quite find where this idea came from, although it might have been inherited from earlier iterations where the brackets for the were "{}" and there was concern that they were included in , but this would only have been a concern when they were outside of the . Final verdict (IMHO): bug in REFC 5335. -- Bill McQuillan From yaojk@cnnic.cn Mon Aug 10 19:20:04 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6E23A6AF7 for ; Mon, 10 Aug 2009 19:20:04 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.225 X-Spam-Level: ** X-Spam-Status: No, score=2.225 tagged_above=-999 required=5 tests=[AWL=-1.386, BAYES_40=-0.185, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO+5A-StANUy for ; Mon, 10 Aug 2009 19:20:03 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id BB8C13A6881 for ; Mon, 10 Aug 2009 19:20:01 -0700 (PDT) Received: (eyou send program); Tue, 11 Aug 2009 10:20:05 +0800 Message-ID: <449957205.06226@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 11 Aug 2009 10:20:05 +0800 Message-ID: <01b001ca1a2a$3b952860$236ff1da@whatisfuture> From: "YAO Jiankang" To: "Ernie Dainow" , References: <449399580.17668@cnnic.cn> Date: Tue, 11 Aug 2009 10:19:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: [EAI] [recharter to standard track with ] Re: Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 02:20:04 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVybmllIERhaW5vdyIgPGVk YWlub3dAY2EuYWZpbGlhcy5pbmZvPg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5 LCBBdWd1c3QgMDQsIDIwMDkgMTE6MjUgUE0NClN1YmplY3Q6IFtFQUldIERvd25ncmFkZSBzaW1w bGlmaWNhdGlvbnMNCg0KDQpzbmlwcw0KPiBUbyBtYWtlIGEgY2xlYW4gbGluZSBiZXR3ZWVuIERv d25ncmFkZSBhbmQgdGhlIHJlc3Qgb2YgdGhlIEVBSSBzdGFuZGFyZCwgDQo+IHNvIHRoYXQgd2Ug Y2FuIG1vdmUgYWhlYWQgd2l0aCBzdGFuZGFyZHMgdHJhY2sgb2YgdGhlIGxhdHRlciB3aGlsZSAN Cj4gY29udGludWluZyB0byB3b3JrIG9uIGV4cGVyaW1lbnRhbCB0cmFjayBEb3duZ3JhZGUsIGFs bCBub3JtYXRpdmUgDQo+IHJlcXVpcmVtZW50cyByZWxhdGluZyB0byBEb3duZ3JhZGUgc2hvdWxk IGJlIHB1bGxlZCBvdXQgb2YgdGhlIEVBSSANCj4gZG9jdW1lbnRzIGFuZCBtb3ZlZCBpbnRvIHRo ZSBEb3duZ3JhZGUgZG9jdW1lbnQuIFNvIGZvciBleGFtcGxlLCB0aGUgDQo+IEFMVC1BRERSRVNT IHBhcmFtZXRlciBzaG91bGQgYmUgbW92ZWQgZnJvbSBSRkMgNTMzNiB0byB0aGUgRG93bmdyYWRl IA0KPiBkb2N1bWVudCBhbmQgdGhlIGFkZHItc3BlYyBmb3IgZG91YmxlIGFuZ2xlIGJyYWNrZXRz IG1vdmVkIG91dCBvZiBSRkMgDQo+IDUzMzUgaW50byB0aGUgRG93bmdyYWRlIGRvYyAob3IgZHJv cHBlZCBpZiAxLiBhYm92ZSBjYW4gYmUgYWNoaWV2ZWQpLg0KDQpJbiB0aGlzIHdnIGxpc3QsIHdl IGhhdmUgZGlzY3Vzc2VkIGEgbG90IGFib3V0IEVBSSBkb3duZ3JhZGUgc2ltcGxpZmljYXRpb25z Lg0KSSB0b3RhbGx5IGFncmVlIHdpdGggRGFpbm93J3Mgc3VnZ2VzdGlvbiBhYm92ZS4NCg0KSW4g b3VyIG9yaWdpbmFsIGRlc2lnbiwgdGhlIGRvd25ncmFkZSBtZXRob2Qgd2l0aCBhbHQtYWRkcmVz cyBpcyBzdXBwb3NlZCB0byBiZSB0cmFuc2l0aW9uYWwuDQpJbiB0aGUgbG9uZyB0ZXJtLCB0aGUg YWx0LWFkZHJlc3Mgd2lsbCBodXJ0IHRoZSBlbWFpbCBzeXN0ZW0gYWx0aG91Z2ggdGhlIGFsdC1h ZGRyZXNzIG1heSBoZWxwIHRoZSBkZXBsb3ltZW50IG9mIEVBSSBzeXN0ZW0gaW4gdGhlIHNob3J0 IHRlcm0uDQpDb25zaWRlcmluZyB0aGUgdHJhZGVvZmYsIHdlIG1heSBzdWdnZXN0IHRoZSBmb2xs b3dpbmcgY2hhbmdlcyB0byB0aGUgb3JpZ2lubmFsIFJGQyBvZiBFQUkgV0cuIA0KDQoNClJGQyA0 OTUyYmlzIGZyYW1ld29yayBkb2N1bWVudCB1cGRhdGVzIHNvbWUgbWF0ZXJpYWwgYWJvdXQgdGhl IGRvd25ncmFkaW5nLCBzdWNoIGFzIHRoYXQgImlmIHNtdHAgc2VydmVyIGRvZXMgbm90IHN1cHBv cnQgdGhlIHV0ZjhzbXRwIGF1dGhvcml6aWVkIGJ5IFJGQzUzMzZiaXMsIHRoZSBzZW5kZXIgbWF5 ICBjb25zaWRlciB0aGUgbWV0aG9kIGRlc2NyaWJlZCBpbiB0aGUgUkZDNTUwNGJpcyIuDQogDQpS RkM1MzM2YmlzIHJlbW92ZSBBTFQtQUREUkVTUyBwYXJhbWV0ZXIgdG8gdGhlIFJGQzU1MDRiaXMg DQpSRkM1MzM1YmlzICByZW1vdmUgdGhlIGFkZHItc3BlYyBmb3IgZG91YmxlIGFuZ2xlIGJyYWNr ZXRzIGludG8gdGhlIFJGQzU1MDRiaXMuDQoNCnRoZSBzdWdnZXN0ZWQgY2F0ZWdvcnkgaXMgdGhh dA0KUkZDNDk1MmJpcyBbaW5mb3JtYXRpb25hbF0NClJGQzUzMzZiaXMgW3N0YW5kYXJkIHRyYWNr XQ0KUkZDNTMzNWJpcyBbc3RhbmRhcmQgdHJhY2tdDQpSRkM1NTA0YmlzIFtleHBlcmltZW50YWxd DQphbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCllhbyBKaWFua2FuZw0KDQoNCg0KPiANCj4g ICAtRXJuaWUgRGFpbm93DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWE= From harald@alvestrand.no Mon Aug 10 21:47:50 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 578E83A6980 for ; Mon, 10 Aug 2009 21:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7ZBdmCB45Pl for ; Mon, 10 Aug 2009 21:47:49 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 35D363A6883 for ; Mon, 10 Aug 2009 21:47:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 65D6439E1A9; Tue, 11 Aug 2009 06:47:52 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no 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 oyyjSETzENUI; Tue, 11 Aug 2009 06:47:48 +0200 (CEST) Received: from [192.168.0.12] (c83-250-103-72.bredband.comhem.se [83.250.103.72]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 684EA39E08B; Tue, 11 Aug 2009 06:47:48 +0200 (CEST) Message-ID: <4A80F7CD.7000801@alvestrand.no> Date: Tue, 11 Aug 2009 06:47:09 +0200 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Bill McQuillan References: <647A5AE078721CED1CDD27F1@PST.JCK.COM> <1EE7EBC0-CB1A-4429-85E7-0B736774DBA2@ca.afilias.info> <083CC160C976BF6D530FAED0@PST.JCK.COM> <34665709.20090810095305@pobox.com> In-Reply-To: <34665709.20090810095305@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IMA Discussion Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 04:47:50 -0000 Bill McQuillan wrote: > On Mon, 2009-08-10, Charles Lindsey wrote: > >>> In addition, note that RFC 5335 appears to require the syntax >>> > >>> >>> I.e., that leading FWS before the second "<" is not optional. >>> > > >> Was there a reason for that, or it is a bug in RFC 5335? >> > > Looking back through the archives, I find that I objected to this on 2007 > Mar 25: > > http://www.ietf.org/mail-archive/web/ima/current/msg01621.html > > but when there was a response about vague concerns for parsing, I > apparently dropped the ball and did not press the point. Mea culpa. > This was (if my faulty memory is reconstructing this correctly) based on other experience with "optional" whitespace, such as the whitespace after the colon in a header line (NetNews ignored the rule that it can be omitted for so long that it had to require it when standardization came around) or the allowed whitespace inside an email address (harald (comment) @ alvestrand . no is supposed to work); as chair, I did not see a compelling argument that not requiring the whitespace resulted in any value to the user, so it stayed required. (The <<>> format seems to have been created around February 2007, so the arguments were supposedly fresh in people's minds when your comments were discussed on the list - the headers doc went to Last Call soon after, and the issue was not re-raised there, so I don't know if we have more recorded data on this issue.) > Looking farther back, I can't quite find where this idea came from, > although it might have been inherited from earlier iterations where the > brackets for the were "{}" and there was concern that they > were included in , but this would only have been a concern when they > were outside of the . > > Final verdict (IMHO): bug in REFC 5335. > > I think it's "Working as intended". From chl@clerew.man.ac.uk Tue Aug 11 02:46:54 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9FBA3A6F9B for ; Tue, 11 Aug 2009 02:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iU5MRIi18s4 for ; Tue, 11 Aug 2009 02:46:53 -0700 (PDT) Received: from v-smtp-auth-relay-4.gradwell.net (v-smtp-auth-relay-4.gradwell.net [79.135.125.43]) by core3.amsl.com (Postfix) with ESMTP id 30D583A6D81 for ; Tue, 11 Aug 2009 02:46:52 -0700 (PDT) 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 v-smtp-auth-relay-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4a813e0f.168d.4a for ima@ietf.org; Tue, 11 Aug 2009 10:46:55 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id n7B9krTL014242 for ; Tue, 11 Aug 2009 10:46:54 +0100 (BST) Date: Tue, 11 Aug 2009 10:46:53 +0100 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <647A5AE078721CED1CDD27F1@PST.JCK.COM> <1EE7EBC0-CB1A-4429-85E7-0B736774DBA2@ca.afilias.info> <083CC160C976BF6D530FAED0@PST.JCK.COM> <34665709.20090810095305@pobox.com> <4A80F7CD.7000801@alvestrand.no> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4A80F7CD.7000801@alvestrand.no> User-Agent: Opera Mail/9.25 (SunOS) Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 09:46:54 -0000 On Tue, 11 Aug 2009 05:47:09 +0100, Harald Alvestrand wrote: > Bill McQuillan wrote: >> On Mon, 2009-08-10, Charles Lindsey wrote: >> >>>> In addition, note that RFC 5335 appears to require the syntax >>>> > >>>> >>>> I.e., that leading FWS before the second "<" is not optional. >>>> >> >> >>> Was there a reason for that, or it is a bug in RFC 5335? >> Final verdict (IMHO): bug in REFC 5335. >> >> > I think it's "Working as intended". But not if its obvious transcription into a mailto (if we decide that is desirable) is going to lead to some non-standard URI syntax). N.B., removing redundant CFWS from an when constructing a mailto may well require attention in the present setup, but implementations should not be placed in the position of having to remove _REQUIRED_ stuff from an X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7333A7065 for ; Tue, 11 Aug 2009 03:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7MeyWk2ACoH for ; Tue, 11 Aug 2009 03:07:46 -0700 (PDT) Received: from v-smtp-auth-relay-4.gradwell.net (v-smtp-auth-relay-4.gradwell.net [79.135.125.43]) by core3.amsl.com (Postfix) with ESMTP id 44E5A3A704D for ; Tue, 11 Aug 2009 03:07:45 -0700 (PDT) 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 v-smtp-auth-relay-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4a8142f1.1686.50 for ima@ietf.org; Tue, 11 Aug 2009 11:07:45 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id n7BA7iIB015502 for ; Tue, 11 Aug 2009 11:07:45 +0100 (BST) Date: Tue, 11 Aug 2009 11:07:44 +0100 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <647A5AE078721CED1CDD27F1@PST.JCK.COM> <1EE7EBC0-CB1A-4429-85E7-0B736774DBA2@ca.afilias.info> <083CC160C976BF6D530FAED0@PST.JCK.COM> <89B8C9B92592D42D143000BB@[192.168.1.110]> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <89B8C9B92592D42D143000BB@[192.168.1.110]> User-Agent: Opera Mail/9.25 (SunOS) Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 10:07:47 -0000 On Mon, 10 Aug 2009 13:02:39 +0100, John C Klensin wrote: > --On Monday, August 10, 2009 10:40 AM +0100 Charles Lindsey > wrote: > >> On Fri, 07 Aug 2009 17:25:35 +0100, John C Klensin >> wrote: >> >>> --On Friday, August 07, 2009 11:42 -0400 Joseph Yee >>> wrote: >>> >>>> mailto also used by mailing list, which reaches many desktop >>>> based MUA, so it's not only browsers. >> >> Indeed, but the same conditions apply. Either >> 1. The mailing list fails to parse the mailto, and refuses to >> enter the address into the mailing list. But the human get to >> see there is a problem and can try something else. >> 2. The mailing list accepts the address, and naively attempts >> to forware mail to it as-is. The recipient server either >> understands it and forwards it, of doen't and rejects it. >> 3. As above, but whatever bounce messages or error responses >> are generated (either by the mailing list, or that server) get >> lost silently. This is the case we want to avoid (because the >> human is never warned there is a problem). So how likely is >> this case? > > Charles, > > Even in the less complicated times of long ago, the typical behavior of > much mailing list software upon finding an unparseable mailbox string > was to write a log entry and proceed, not do something overt and loud to > warn anyone. Sure, but much existing software does stupid/unhelpful things all the time, and the sky does not fall in. So some legacy piece of software (whether for mailing lists or anything else) which is asked to process an , for whatever reason, may do any of the following 1. Silently accept and then mishandle an ASCII not conforming to RFC 5322 (e.g. a mismatched quoted-string in its local part). 2. Silently accept and then mishandle a "utf-8@utf-8" . 3. Silently accept and then mishandle a ">". Case 1 already happens. Case 2 is certainly going to happen, and we will have to live with it. So the _real_ question to ask is whether the consequences of allowing Case 3 are so horribly worse than the inevitable (and existing) consequences of the first 2 that we should seek to forbid Case 3 entirely. That is a case that has to be made, and it has not been made yet. But bear in and that legacy software is going to be around for many years to come in places where nobody ever encounters such a thing as Non-Ascii. So long after we find we no longer need to worry about all the more obscure downgradings, we may still find it essential to have alt-addresses available to us (at least in From/Reply-To headers). Or maybe not ... That is the question. Will we be wors off, or better off, without it (given that something is not going to work either way). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From klensin@jck.com Tue Aug 11 05:25:22 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E173A6B67 for ; Tue, 11 Aug 2009 05:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9CUBPZL0GHS for ; Tue, 11 Aug 2009 05:25:21 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 828833A7104 for ; Tue, 11 Aug 2009 05:25:19 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Maq3W-000LgE-Hs; Tue, 11 Aug 2009 08:02:18 -0400 Date: Tue, 11 Aug 2009 08:02:17 -0400 From: John C Klensin To: Charles Lindsey , IMA Message-ID: <6D1679BEC383FA50C7CE029A@PST.JCK.COM> In-Reply-To: References: <647A5AE078721CED1CDD27F1@PST.JCK.COM> <1EE7EBC0-CB1A-4429-85E7-0B736774DBA2@ca.afilias.info> <083CC160C976BF6D530FAED0@PST.JCK.COM> <89B8C9B92592D42D143000BB@[192.168.1.110]> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 12:25:22 -0000 --On Tuesday, August 11, 2009 11:07 +0100 Charles Lindsey wrote: >... > So the _real_ question to ask is whether the consequences of > allowing Case 3 are so horribly worse than the inevitable (and > existing) consequences of the first 2 that we should seek to > forbid Case 3 entirely. That is a case that has to be made, > and it has not been made yet. Actually, because this is a new feature and new syntax, I suggest that the case which has to be made is that it is safe and worth the trouble. In other words, those who are hesitant about it should not be obligated to prove that it will not be "horribly worse". > But bear in and that legacy software is going to be around for > many years to come in places where nobody ever encounters such > a thing as Non-Ascii. So long after we find we no longer need > to worry about all the more obscure downgradings, we may still > find it essential to have alt-addresses available to us (at > least in From/Reply-To headers). Or maybe not ... Yes, and we don't know how those legacy systems will behave when confronted with "new" syntax. We can safely predict that some will fail in a reasonable fashion and that others will behave badly. We can predict that there will be some (perhaps many) good quality implementations of in-transit downgrading and some bad quality ones. We can also predict that there will be some firewall/gateway issues with new headers and new syntax (because those systems have a different mission and because, historically, most of them have been of poor quality and very slow to follow new SMTP extensions). > That is the question. Will we be wors off, or better off, > without it (given that something is not going to work either > way). Actually, as some level, no one is disagreeing with you, depending on what you mean by "it". One version of "it" is "change the syntax, supporting downgrading with forward and backward-pointing addresses". That is beginning to feel like "worse off", both because of the cases that won't work and because it is a significant change with ripple side-effects (including the complications with "mailto:").. The other is some version of what Ernie, Yao, and I are suggesting (I won't know if our suggestions are completely consistent until someone writes an I-D). That suggestion is: (1) We drop forward-pointing downgrading on the grounds that (i) virtually all of the cases are configuration errors or general stupidity, (ii) it eliminates the complex "all of the addresses have to be downgradeable to preserve the recipient list" rules, (iii) it eliminates the interdependent header logic, which we know to be fragile. (2) We drop the > syntax as (i) too radical a change for a transition mechanism, (ii) raising excessive opportunities for security-related mischief, (iii) complicating MUA-Submission Server interactions, (iv) complicating mailto, and (v) representing a higher-than-necessary risk of "interesting" foul-ups in legacy systems as well as totally confusing lusers who haven't seen the syntax before. (3) We preserve the alt-address parameter on the SMTP MAIL command, while dropping it on RCPT (as the result of (1)). That implies that we retain a fallback to an ASCII address for NDNs and MDNs. Of course, that doesn't help with the blowback problem, and might make it a tad worse. But the problem is really not different from the single-address one -- when possible, rejections at SMTP time are probably better than sending NDN messages back and, if one is going to send an NDN, being reasonably certain that the address to which it is sent is valid for the sender is a good idea. (4) We encourage the use of From: addr1, addr2 as a representation of MAIL FROM:, ALT-ADDRESS="addr2" Doing so requires that we accept the fact that the semantics are a little different and the observation that multiple "From:" fields are not well supported. We may have to encourage better support, think about whether clarifying language in RFC 5322bis is needed about what replies to such messages means, and so on. But support for multiple From-address syntax has been specified and required for many years (so no new syntax). I note that there is, properly, no multiple-address syntax for "Sender:", but think we can live with that. Using "From:" that way really is a transition mechanism-- when it ceases to be useful, it disappears. Part of my reasoning is based on an assumption that may not be true but that is based on a certain amount of experience. That is that a legacy system that encounters From: EAI-addr, ASCII-addr is much more likely to behave reasonably --since it knows that there are two addresses, whether it "likes" them or not -- than a legacy system that encounters From: > In the first case, the EAI-addr may be rejected as trash or turned into a name phrase or comment, but either the second one will go through or there will be a comprehensible error message. It is even possible that both addresses will go through because the MUA and MSA fail to insist on ASCII addresses. In the second, there is, IMO, considerable risk of the whole address being rejected or trashed beyond recognition. And, once the patterns of "trash beyond recognition" are understood by the bad guys, there are possibilities of interesting security exploits with it. john From jyee@ca.afilias.info Tue Aug 11 06:55:43 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5453A3A70D9 for ; Tue, 11 Aug 2009 06:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.025 X-Spam-Level: X-Spam-Status: No, score=-5.025 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ue1bcGnm4bvs for ; Tue, 11 Aug 2009 06:55:42 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 5D67D3A6D9A for ; Tue, 11 Aug 2009 06:55:42 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1Maro9-00045O-8F; Tue, 11 Aug 2009 13:54:33 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=[172.16.30.193]) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Maro9-0003Ei-7Z; Tue, 11 Aug 2009 13:54:33 +0000 From: Joseph Yee To: "YAO Jiankang" In-Reply-To: <449957205.06226@cnnic.cn> X-Priority: 3 References: <449399580.17668@cnnic.cn> <449957205.06226@cnnic.cn> Message-Id: <1BC4447D-6190-48BA-9DA3-1018CFDF30AA@ca.afilias.info> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 11 Aug 2009 09:54:32 -0400 X-Mailer: Apple Mail (2.936) Cc: ima@ietf.org Subject: Re: [EAI] [recharter to standard track with ] Re: Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 13:55:43 -0000 If we took this approach, EAI will get on standard track while Downgrade may be in experimental forever. And I doubted that how many will look back to downgrade again once EAI gets on standard track. And the split approach means that we need 2 ESMTP keywords, something like UTF8SMTP and UTF8SMTP=ONLY to identify 2 different MTA behaviors. And we are creating more versions if to create downgrade capable instance afterwards. I'm not entirely against it, but I hoped we all aware (and accept) of the issues of doing so. We are facing the delivery dilemma of backward-compatible vs filtering. Emails delivery in modern day are subject (or at mercy) of firewall and content filter. Before these 2 updated for EAI, there will always be some aggressive filtering on 1. 8 bit in address and header (MIME encoding requirement gone, except binary file attachment) 2. not realized the new address format and new header type 3. considered mails in foreign languages are spams To the whole WG: 1. How valuable is backward compatible? 2. At what condition do we consider success on EAI message passing thru firewall & content filter? (Someone asked similar question during the last IETF meeting) Best Regards, Joseph Yee On 10-Aug-09, at 10:19 PM, YAO Jiankang wrote: > > ----- Original Message ----- > From: "Ernie Dainow" > To: > Sent: Tuesday, August 04, 2009 11:25 PM > Subject: [EAI] Downgrade simplifications > > > snips >> To make a clean line between Downgrade and the rest of the EAI >> standard, >> so that we can move ahead with standards track of the latter while >> continuing to work on experimental track Downgrade, all normative >> requirements relating to Downgrade should be pulled out of the EAI >> documents and moved into the Downgrade document. So for example, the >> ALT-ADDRESS parameter should be moved from RFC 5336 to the Downgrade >> document and the addr-spec for double angle brackets moved out of RFC >> 5335 into the Downgrade doc (or dropped if 1. above can be achieved). > > In this wg list, we have discussed a lot about EAI downgrade > simplifications. > I totally agree with Dainow's suggestion above. > > In our original design, the downgrade method with alt-address is > supposed to be transitional. > In the long term, the alt-address will hurt the email system > although the alt-address may help the deployment of EAI system in > the short term. > Considering the tradeoff, we may suggest the following changes to > the originnal RFC of EAI WG. > > > RFC 4952bis framework document updates some material about the > downgrading, such as that "if smtp server does not support the > utf8smtp authorizied by RFC5336bis, the sender may consider the > method described in the RFC5504bis". > > RFC5336bis remove ALT-ADDRESS parameter to the RFC5504bis > RFC5335bis remove the addr-spec for double angle brackets into the > RFC5504bis. > > the suggested category is that > RFC4952bis [informational] > RFC5336bis [standard track] > RFC5335bis [standard track] > RFC5504bis [experimental] > any comments are welcome. > > Yao Jiankang > > > >> >> -Ernie Dainow >> >> >> _______________________________________________ >> IMA mailing list >> IMA@ietf.org >> https://www.ietf.org/mailman/listinfo/ima > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From jyee@ca.afilias.info Tue Aug 11 08:36:21 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36D4F3A6925 for ; Tue, 11 Aug 2009 08:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.645 X-Spam-Level: X-Spam-Status: No, score=-5.645 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PMCMNqQkAy3 for ; Tue, 11 Aug 2009 08:36:20 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 5E2503A6B91 for ; Tue, 11 Aug 2009 08:36:20 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1MatNU-0005ny-9M; Tue, 11 Aug 2009 15:35:08 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=jyee-lt.tor.afilias-int.info) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MatNU-0002Zh-5M; Tue, 11 Aug 2009 15:35:08 +0000 From: Joseph Yee To: John C Klensin In-Reply-To: <182D800B68671682342258E6@PST.JCK.COM> References: <449399580.17668@cnnic.cn> <449957205.06226@cnnic.cn> <1BC4447D-6190-48BA-9DA3-1018CFDF30AA@ca.afilias.info> <182D800B68671682342258E6@PST.JCK.COM> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 11 Aug 2009 11:35:08 -0400 X-Mailer: Apple Mail (2.936) Cc: ima@ietf.org Subject: Re: [EAI] [recharter to standard track with ] Re: Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 15:36:21 -0000 On 11-Aug-09, at 10:57 AM, John C Klensin wrote: > > > --On Tuesday, August 11, 2009 09:54 -0400 Joseph Yee > wrote: > >> If we took this approach, EAI will get on standard track >> while Downgrade may be in experimental forever. And I doubted >> that how many will look back to downgrade again once EAI gets >> on standard track. > > Actually, I thing EAI would get on Standards Track with an > extremely narrowed-down version of Downgrade, probably also on > Standards Track. I just see no practical way to continue the > current Downgrade document (RFC5504) as experimental without > including the forward-pointing Alt-Address syntax in the base > Headers document (RFC 5335). If that syntax is in 5335bis as a > "require to recognize" (at least), then we are stuck with it > forever and, IMO, we need to demonstrate that it is not > problematic. If it isn't in 5335bis, then it is dead, > regardless of the standards-track status of 5504bis. > > As I commented in an earlier note, I don't think Yao, Ernie, and > myself disagree in any fundamental way, but we won't know until > a strawman document is produced. I definitely will not be able > to produce that document in the next couple of weeks, but > perhaps someone else will. Otherwise, I'd be happy to try to > take an active role in September. > >> And the split approach means that we need 2 ESMTP keywords, >> something like UTF8SMTP and UTF8SMTP=ONLY to identify 2 >> different MTA behaviors. And we are creating more versions if >> to create downgrade capable instance afterwards. > > Perhaps my understanding of what is being proposed really does > differ from Yao's -- or at least your reading of Yao's -- but I > don't see a need for any such thing. Remember that the current > Downgrade model permits bouncing (or rejecting) a message that > cannot be forwarded as an alternative to applying the Downgrade > ritual. We are just eliminating some of the Downgrade logic and > some of the options. I'm referring to removing downgrade entirely from all current doc and move forward to standard track. I could misinterpret what brought up by Yao. > RFC5336bis remove ALT-ADDRESS parameter to the RFC5504bis I'm in favor of simplifying downgrade and push it to standard track along with all doc, but not leaving it behind in experimental. Looking up to your first paragraph first sentence is what I hope to be the way. Joseph [remove rest of content for better read] ... From klensin@jck.com Tue Aug 11 08:49:43 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5905F3A7085 for ; Tue, 11 Aug 2009 08:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS0ec8R4j+r8 for ; Tue, 11 Aug 2009 08:49:42 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 865B03A7021 for ; Tue, 11 Aug 2009 08:49:27 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Masmw-000Ph0-Ed; Tue, 11 Aug 2009 10:57:22 -0400 Date: Tue, 11 Aug 2009 10:57:21 -0400 From: John C Klensin To: Joseph Yee , YAO Jiankang Message-ID: <182D800B68671682342258E6@PST.JCK.COM> In-Reply-To: <1BC4447D-6190-48BA-9DA3-1018CFDF30AA@ca.afilias.info> References: <449399580.17668@cnnic.cn> <449957205.06226@cnnic.cn> <1BC4447D-6190-48BA-9DA3-1018CFDF30AA@ca.afilias.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] [recharter to standard track with ] Re: Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 15:49:43 -0000 --On Tuesday, August 11, 2009 09:54 -0400 Joseph Yee wrote: > If we took this approach, EAI will get on standard track > while Downgrade may be in experimental forever. And I doubted > that how many will look back to downgrade again once EAI gets > on standard track. Actually, I thing EAI would get on Standards Track with an extremely narrowed-down version of Downgrade, probably also on Standards Track. I just see no practical way to continue the current Downgrade document (RFC5504) as experimental without including the forward-pointing Alt-Address syntax in the base Headers document (RFC 5335). If that syntax is in 5335bis as a "require to recognize" (at least), then we are stuck with it forever and, IMO, we need to demonstrate that it is not problematic. If it isn't in 5335bis, then it is dead, regardless of the standards-track status of 5504bis. As I commented in an earlier note, I don't think Yao, Ernie, and myself disagree in any fundamental way, but we won't know until a strawman document is produced. I definitely will not be able to produce that document in the next couple of weeks, but perhaps someone else will. Otherwise, I'd be happy to try to take an active role in September. > And the split approach means that we need 2 ESMTP keywords, > something like UTF8SMTP and UTF8SMTP=ONLY to identify 2 > different MTA behaviors. And we are creating more versions if > to create downgrade capable instance afterwards. Perhaps my understanding of what is being proposed really does differ from Yao's -- or at least your reading of Yao's -- but I don't see a need for any such thing. Remember that the current Downgrade model permits bouncing (or rejecting) a message that cannot be forwarded as an alternative to applying the Downgrade ritual. We are just eliminating some of the Downgrade logic and some of the options. > I'm not entirely against it, but I hoped we all aware (and > accept) of the issues of doing so. > > We are facing the delivery dilemma of backward-compatible vs > filtering. > > Emails delivery in modern day are subject (or at mercy) of > firewall and content filter. Before these 2 updated for EAI, > there will always be some aggressive filtering on > 1. 8 bit in address and header (MIME encoding requirement > gone, except binary file attachment) > 2. not realized the new address format and new header type Both true whether we have Downgrade or not. However, note that, if everything is working correctly (including configurations) those systems will never see EAI addresses or headers except, possibly, as an isolated (comma-separated) backward-pointing address that they don't know how to interpret or consider a syntax error. > 3. considered mails in foreign languages are spams I expect that filters based on "I can't read that language or script, so anything arriving in it in my mailbox is unwanted" will persist forever. Nothing this WG can do, with or without downgrading, will help with that. It is also not an EAI problem -- there are several languages written with Latin characters that I might reasonably specify filters to reject because there is no hope of my reading the text even if my machine can render all of the characters. >... > To the whole WG: > 1. How valuable is backward compatible? Speaking personally, I think extremely valuable if we can make it happen. But > is the exact opposite of backward compatibility and reliance on a collection of new headers that are at least slightly order-sensitive isn't a great deal better. > 2. At what condition do we consider success on EAI message > passing thru firewall & content filter? (Someone asked > similar question during the last IETF meeting) Please separate firewalls and content filters that have been upgraded from those that have not and note the comment about content filters above. The root of several of our comments is that, if an EAI message hits a non-upgraded one of these things, then either there is a configuration error or something is badly broken, or both and that the Internet has never needed an explicit "if this address doesn't work, try that one" capability in SMTP. john From yaojk@cnnic.cn Wed Aug 12 01:05:34 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84DCF3A6B2B for ; Wed, 12 Aug 2009 01:05:34 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 1.5 X-Spam-Level: * X-Spam-Status: No, score=1.5 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_20=-0.74, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3vzkssrrDS8 for ; Wed, 12 Aug 2009 01:05:33 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id BE8903A6A8A for ; Wed, 12 Aug 2009 01:05:32 -0700 (PDT) Received: (eyou send program); Wed, 12 Aug 2009 15:16:59 +0800 Message-ID: <450061419.30089@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 12 Aug 2009 15:16:59 +0800 Message-ID: <005101ca1b1c$e0b3e280$236ff1da@whatisfuture> From: "YAO Jiankang" To: "Ernie Dainow" References: <4A3FA114.3070007@ca.afilias.info><20090627195635.GA14125@laperouse.bortzmeyer.org><447145015.02367@cnnic.cn> <449528245.12181@cnnic.cn> <449528475.12144@cnnic.cn> <449645977.17662@cnnic.cn> Date: Wed, 12 Aug 2009 15:16:55 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: meldin78@hotmail.com, EAI Subject: Re: [EAI] Downgrade testing - Results X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 08:05:34 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVybmllIERhaW5vdyIgPGVk YWlub3dAY2EuYWZpbGlhcy5pbmZvPg0KVG86ICJZQU8gSmlhbmthbmciIDx5YW9qa0Bjbm5pYy5j bj4NCkNjOiAiU3RlcGhhbmUgQm9ydHptZXllciIgPGJvcnR6bWV5ZXJAbmljLmZyPjsgIkVBSSIg PGltYUBpZXRmLm9yZz47IDxhYmVseWFuZ0B0d25pYy5uZXQudHc+OyA8bWVsZGluNzhAaG90bWFp bC5jb20+DQpTZW50OiBGcmlkYXksIEF1Z3VzdCAwNywgMjAwOSA3OjUyIFBNDQpTdWJqZWN0OiBS ZTogW0VBSV0gRG93bmdyYWRlIHRlc3RpbmcgLSBSZXN1bHRzDQoNCg0KPiBTb21lIG9mIHlvdXIg ZmFpbHVyZXMgbWF5IGJlIGR1ZSB0byB0aGUgZW52aXJvbm1lbnQgYW5kIG5vdCB0aGUgDQo+IERv d25ncmFkZS4gSSByYW4gYSAnYmFzZScgdGVzdCBieSBzZW5kaW5nIHRoZSBlbWFpbCBmcm9tIGFu IEFTQ0lJIA0KPiBhZGRyZXNzIHRvIHRyeSBhbmQgaWRlbnRpZnkgd2hpY2ggZmFpbHVyZXMgYXJl IGR1ZSB0byB0aGUgZW52aXJvbm1lbnQgDQo+IChmaXJld2FsbHMsIG5ldHdvcmssIGV0Yy4pLiAN Cj4gDQoNCg0KdG9kYXksICB3ZSB1c2UgdGhlIGFzY2lpIGFkZHJlc3MgZnJvbSB0aGUgc2FtZSBt YWNoaW5lIHRvIHRoZXNlIDEwIGFkZHJlc3Nlcy4gYWxsIGdldCBzdWNjZXNzLg0KDQpzbywgdGhh dCBpcyB0byBzYXkgdGhhdCBpdCBpcyBub3QgdGhlIGVudmlyb25tZW50IHByb2JsZW0uIA0KDQoN CllhbyBKaWFua2FuZw0KQ05OSUMNCg0KPiBPbiB0aGUgRG93bmdyYWRlIHRlc3QsIEkgcmVjZWl2 ZWQgcmVwbGllcyBmcm9tIGFsbCBzZXJ2ZXJzIGV4Y2VwdCB0aGVzZQ0KPiBlY2hvQG5pYy5mcg0K PiBlY2hvQHR1LWJlcmxpbi5kZQ0KPiBlY2hvQGNuYW0uZnIgKHRoaXMgYWRkcmVzcyBkb2VzIG5v dCBleGlzdCBhbmQgeW91IGdldCBhIHJlamVjdCBmcm9tICANCj4gZWNob0Bjb3Blcm5pYy5jbmFt LmZyKQ0KPiANCj4gWW91IHJlY2VpdmVkIHJlcGxpZXMgZnJvbSB0aGUgZmlyc3QgdHdvIGJ1dCBu b3QgZnJvbSB0aHJlZSBvdGhlcnMgdGhhdCBJIA0KPiBkaWQgcmVjZWl2ZSBhIHJlcGx5IGZyb20u IFRoaXMgaXMgYSBzdXJwcmlzaW5nIGRpZmZlcmVuY2UuIEEgYmFzZSB0ZXN0IA0KPiBtaWdodCBo ZWxwIGV4cGxhaW4gaXQuDQo+IA0KPiAgICAtRXJuaWUgRGFpbm93DQo+IA0KPiANCj4gWUFPIEpp YW5rYW5nIHdyb3RlOg0KPj4gYnR3LCB0aGUgaW1wbG1lbnRhdGlvbiBpcyBiYXNlZCBvbiBwb3N0 Zml4Lg0KPj4gY291bGQgVFdOSUMgSlBSUyBOSURBIGRvIHRoZSBzaW1pbGFyIHRlc3RzIGFuZCBy ZXBvcnQgdGhlIHJlc3VsdHM/DQo+Pg0KPj4gWUFPIEppYW5rYW5nDQo+PiBDTk5JQw0KPj4NCj4+ IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+PiBGcm9tOiAiWUFPIEppYW5rYW5nIiA8 eWFvamtAY25uaWMuY24+DQo+PiBUbzogIkVybmllIERhaW5vdyIgPGVkYWlub3dAY2EuYWZpbGlh cy5pbmZvPjsgIlN0ZXBoYW5lIEJvcnR6bWV5ZXIiIDxib3J0em1leWVyQG5pYy5mcj47ICJFQUki IDxpbWFAaWV0Zi5vcmc+DQo+PiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDA2LCAyMDA5IDExOjEw IEFNDQo+PiBTdWJqZWN0OiBSZTogW0VBSV0gRG93bmdyYWRlIHRlc3RpbmcgLSBSZXN1bHRzDQo+ Pg0KPj4NCj4+ICAgDQo+Pj4gd2Ugc2VuZCB0byB0aGUgZm9sbG93aW5nIDEwIGFkZHJlc3MsIHdp dGggPGVhaTxhc2NpaT4+DQo+Pj4gICAgIA0KPj4+Pj4gKiBlY2hvQGdlbmVyaWMtbmljLm5ldCAN Cj4+Pj4+ICogZWNob0BuaWMuZnIgDQo+Pj4+PiAqIEVjaG9AVFUtQmVybGluLkRFIA0KPj4+Pj4g KiBlY2hvQHR1LWNoZW1uaXR6LmRlIA0KPj4+Pj4gKiBlY2hvQG91YWluLmNvbSANCj4+Pj4+ICog cmVwb25kc21vaUBjcmRwLmFjLXZlcnNhaWxsZXMuZnINCj4+Pj4+ICogZWNob0BjbmFtLmZyDQo+ Pj4+PiAqIHBpbmdAc3RhbXBlci5pdGNvbnN1bHQuY28udWsgDQo+Pj4+PiAqIHBpbmdAb2xlYW5l Lm5ldA0KPj4+Pj4gKiBjaGVjay1hdXRoQHZlcmlmaWVyLnBvcnQyNS5jb20NCj4+Pj4+ICAgICAg ICAgDQo+Pj4gd2UgZ2V0IHRoZSBuaWNlIHJlc3BvbnNlIGZyb20gdGhlIGZvbGxvd2luZyA2IGFk ZHJlc3MNCj4+PiBlY2hvQGdlbmVyaWMtbmljLm5ldA0KPj4+IGVjaG9AbmljLmZyDQo+Pj4gRWNo b0BUVS1CZXJsaW4uREUNCj4+PiBlY2hvQG91YWluLmNvbQ0KPj4+IGNoZWNrLWF1dGhAdmVyaWZp ZXIucG9ydDI1LmNvbQ0KPj4+IHJlcG9uZHNtb2lAY3JkcC5hYy12ZXJzYWlsbGVzLmZyDQo+Pj4N Cj4+Pg0KPj4+IHdlIGdldCB0aGUgcmVqZWN0IGluZm9ybWF0aW9uIGZyb20gMSBhZGRyZXNzDQo+ Pj4gZWNob0Bjb3Blcm5pYy5jbmFtLmZyDQo+Pj4NCj4+Pg0KPj4+IHdlIGNhbiBub3QgZ2V0IGFu eSByZXNwb25zZSBmcm9tIG90aGVyIDMgYWRkcmVzc2VzLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IFlh byBKaWFua2FuZw0KPj4+IENOTklDDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IC0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+Pj4gRnJvbTogIkVybmllIERhaW5vdyIgPGVkYWlu b3dAY2EuYWZpbGlhcy5pbmZvPg0KPj4+IFRvOiAiU3RlcGhhbmUgQm9ydHptZXllciIgPGJvcnR6 bWV5ZXJAbmljLmZyPjsgIkVBSSIgPGltYUBpZXRmLm9yZz4NCj4+PiBTZW50OiBUaHVyc2RheSwg SnVseSAwOSwgMjAwOSA5OjA5IFBNDQo+Pj4gU3ViamVjdDogUmU6IFtFQUldIERvd25ncmFkZSB0 ZXN0aW5nIC0gUmVzdWx0cw0KPj4+DQo+Pj4NCj4+PiAgICAgDQo+Pj4+IFRoZXNlIGVjaG8gdGVz dHMgd2VyZSBhIGdvb2Qgc3VnZ2VzdGlvbi4gSSByYW4gYSBiYXNlIHRlc3QgZnJvbSBhbiBBU0NJ SSANCj4+Pj4gYWRkcmVzcyBhZ2FpbnN0IGFsbCBlY2hvIHNlcnZlcnMgaW4gdGhlIGxpc3QuIEFs bCByZXNwb25kZWQgZXhjZXB0IA0KPj4+PiBlY2hvQGNuYW0uZnIuIEVtYWlsIGJvdW5jZWQgd2l0 aCAidW5rbm93biBhZGRyZXNzIiwgc28gSSAgZWxpbWluYXRlZCANCj4+Pj4gdGhhdCBzZXJ2ZXIg ZnJvbSB0aGUgdGVzdCwgbGVhdmluZyBhIHRvdGFsIG9mIDkgZWNobyBzZXJ2ZXJzLg0KPj4+Pg0K Pj4+PiBUaGUgc3VjY2VzcyByYXRlIGZvciByZWNlaXZpbmcgYSByZXNwb25zZSBmcm9tIGVjaG8g c2VydmVyczoNCj4+Pj4gMSkgRnJvbSBBU0NJSSwgbm8gZG93bmdyYWRlICAgICAgOS85ICAgICAg MTAwJQ0KPj4+PiAyKSBGcm9tIEVBSSwgZG93bmdyYWRlICAgICAgICAgICAgICAgNy85ICAgICAg ICA3OCUNCj4+Pj4NCj4+Pj4gYXV0aC1yZXN1bHRzQHZlcmlmaWVyLnBvcnQyNS5jb20gcHJvdmlk ZWQgc29tZSBTcGFtQXNzYXNzaW4gYW5hbHlzaXM6DQo+Pj4+IDEpIEJPRFk6IEJheWVzaWFuIHNw YW0gcHJvYmFiaWxpdHkgaXMgMSB0byA1JQ0KPj4+PiAyKSBCT0RZOiBCYXllc2lhbiBzcGFtIHBy b2JhYmlsaXR5IGlzIDUgdG8gMjAlDQo+Pj4+DQo+Pj4+IEZvciB0aGUgZG93bmdyYWRlIHRlc3Qg c2VudCB0byBpbmRpdmlkdWFsIHBhcnRpY2lwYW50cyB0aGUgcmVzdWx0cyB3ZXJlOg0KPj4+PiBU b3RhbCBTZW50ICAgIDExICAgKGFsbCBvbiBkaWZmZXJlbnQgZW1haWwgZG9tYWlucykNCj4+Pj4g UmVjZWl2ZWQgICAgICAgOSAgICA4MiUNCj4+Pj4gQmxvY2tlZCAgICAgICAgMiAgICAxOCUNCj4+ Pj4NCj4+Pj4gVGhlc2UgYXJlIG5vdCBsYXJnZSBzYW1wbGVzLCBidXQgaXQgaXMgaW50ZXJlc3Rp bmcgdG8gc2VlIHRoYXQgdGhlIA0KPj4+PiBzdWNjZXNzIHJhdGUgaW4gYm90aCB0ZXN0cyB3ZXJl IHNpbWlsYXIsIGFuZCB3ZXJlIGluIHRoZSBTcGFtQXNzYXNzaW4gDQo+Pj4+IHJhbmdlIG9mIDIw JSBwcm9iYWJpbGl0eSBvZiBzcGFtLg0KPj4+Pg0KPj4+PiBJIGVuY291cmFnZSBvdGhlciBpbXBs ZW1lbnRlcnMgdG8gcnVuIHRoZSBzYW1lIHNldCBvZiB0ZXN0cyBzbyB3ZSBjYW4gDQo+Pj4+IGdl dCBhIGxhcmdlciBzYW1wbGUgYW5kIHNlZSBpZiB0aGVyZSBhcmUgZGlmZmVyZW5jZXMgYmV0d2Vl biBEb3duZ3JhZGUgDQo+Pj4+IGltcGxlbWVudGF0aW9ucy4NCj4+Pj4NCj4+Pj4gICAgLUVybmll DQo+Pj4+DQo+Pj4+DQo+Pj4+IFN0ZXBoYW5lIEJvcnR6bWV5ZXIgd3JvdGU6DQo+Pj4+ICAgICAg IA0KPj4+Pj4gT24gTW9uLCBKdW4gMjIsIDIwMDkgYXQgMTE6MTk6NDhBTSAtMDQwMCwNCj4+Pj4+ ICBFcm5pZSBEYWlub3cgPGVkYWlub3dAY2EuYWZpbGlhcy5pbmZvPiB3cm90ZSANCj4+Pj4+ICBh IG1lc3NhZ2Ugb2YgNDEgbGluZXMgd2hpY2ggc2FpZDoNCj4+Pj4+DQo+Pj4+PiAgIA0KPj4+Pj4g ICAgICAgICANCj4+Pj4+PiBUaGUgRG93bmdyYWRlIHRlc3QgcmVwb3J0ZWQgb24gdGhlIHdpa2kg YmFzaWNhbGx5IHRlc3RlZCBhZ2FpbnN0IGdtYWlsLiAgDQo+Pj4+Pj4gSXQgd291bGQgYmUgdmFs dWFibGUgdG8gZG8gbW9yZSB0ZXN0aW5nICdpbiB0aGUgd2lsZCcgdG8gc2VlIGhvdyAgDQo+Pj4+ Pj4gRG93bmdyYWRlIHRyYXZlcnNlcyB2YXJpb3VzIGVtYWlsIHN5c3RlbXMgaW4gb3RoZXIgb3Jn YW5pemF0aW9ucy4NCj4+Pj4+PiAgICAgDQo+Pj4+Pj4gICAgICAgICAgIA0KPj4+Pj4gWW91IGNh biB0ZXN0IGFnYWluc3QgdmFyaW91cyBhdXRvLXJlc3BvbmRlcnMgd2hpY2ggc2VuZCB5b3UgYmFj ayB5b3VyDQo+Pj4+PiBtZXNzYWdlIChpZiB5b3Uga25vdyBvdGhlciBlbWFpbCBhZGRyZXNzZXMg b2YgYXV0by1yZXNwb25kZXJzLCBkbyBub3QNCj4+Pj4+IGhlc2l0YXRlIHRvIHB1Ymxpc2ggdGhl bSkuDQo+Pj4+Pg0KPj4+Pj4gKiBlY2hvQGdlbmVyaWMtbmljLm5ldCANCj4+Pj4+ICogZWNob0Bu aWMuZnIgDQo+Pj4+PiAqIEVjaG9AVFUtQmVybGluLkRFIA0KPj4+Pj4gKiBlY2hvQHR1LWNoZW1u aXR6LmRlIA0KPj4+Pj4gKiBlY2hvQG91YWluLmNvbSANCj4+Pj4+ICogcmVwb25kc21vaUBjcmRw LmFjLXZlcnNhaWxsZXMuZnINCj4+Pj4+ICogZWNob0BjbmFtLmZyDQo+Pj4+PiAqIHBpbmdAc3Rh bXBlci5pdGNvbnN1bHQuY28udWsgDQo+Pj4+PiAqIHBpbmdAb2xlYW5lLm5ldA0KPj4+Pj4gKiBj aGVjay1hdXRoQHZlcmlmaWVyLnBvcnQyNS5jb20NCj4+Pj4+ICAgDQo+Pj4+PiAgICAgICAgIA0K Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ PiBJTUEgbWFpbGluZyBsaXN0DQo+Pj4+IElNQUBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ0KPj4+PiAgICAgICANCj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IElNQSBtYWlsaW5nIGxp c3QNCj4+PiBJTUFAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ltYQ== From sm@resistor.net Wed Aug 12 02:34:27 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6AB3A6A4C for ; Wed, 12 Aug 2009 02:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSo0fK2tKd33 for ; Wed, 12 Aug 2009 02:34:26 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 97EFB3A6991 for ; Wed, 12 Aug 2009 02:33:57 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n7C8dQSV028261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Aug 2009 01:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1250066374; x=1250152774; bh=yZaIjEFSMnE2PrE6GmIGovNe8iHJHu2UwMolssGiesM=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=u1zu8efITIICWxG5dwsxqFooiDxn6qRp7ItELiI7XDEU7bMwMHEWzQteyPkaFumQv 8l9f+pe/jVOY0E0d9ZWbLMP3IUOC2EUb9ordBqn00CKVRD8WGa+RihmOCMwzS2h9Qe i52hHT1KflXXYLtQL0NUkti9tGHDQNPwlkAZeP34= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=ppjgtuhsPnqRwpqyV4uRysKfg9z4xi2849GseIsAxS4V5jSTbDw6BvWm0T95Nt/j9 Mm8inkiRSfv9bLCmbd47t1C6fqHYSRxqZA/I0JaS41bxFQe3iBcpiPhUGzPc4IbRmym msb9cBY7x62fd17qxrz4NJd5ECKx05z+M7CYCxQ= Message-Id: <6.2.5.6.2.20090812002323.0322bf50@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 12 Aug 2009 01:39:14 -0700 To: ima@ietf.org From: SM In-Reply-To: <449957205.06226@cnnic.cn> References: <449399580.17668@cnnic.cn> <449957205.06226@cnnic.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [EAI] [recharter to standard track with ] Re: Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 09:34:27 -0000 At 19:19 10-08-2009, YAO Jiankang wrote: >Considering the tradeoff, we may suggest the following changes to >the originnal RFC of EAI WG. > > >RFC 4952bis framework document updates some material about the >downgrading, such as that "if smtp server does not support the >utf8smtp authorizied by RFC5336bis, the sender may consider the >method described in the RFC5504bis". > >RFC5336bis remove ALT-ADDRESS parameter to the RFC5504bis >RFC5335bis remove the addr-spec for double angle brackets into the >RFC5504bis. > >the suggested category is that [snip] >RFC5504bis [experimental] Does the WG need more time to determine whether the experiment is a success or not? Once the other specifications are moved to Standard Track, there won't be any effort to do something about RFC5540bis. At 06:54 11-08-2009, Joseph Yee wrote: >To the whole WG: >1. How valuable is backward compatible? It's better to also consider what can be done to favor successful delivery of the message. Having backward compatibility as the constraint affects that. >2. At what condition do we consider success on EAI message passing >thru firewall & content filter? (Someone asked similar question >during the last IETF meeting) That depends on whether the receiving side has an incentive to fix the problem. At 07:57 11-08-2009, John C Klensin wrote: >Speaking personally, I think extremely valuable if we can make >it happen. But > is the exact opposite of backward >compatibility and reliance on a collection of new headers that >are at least slightly order-sensitive isn't a great deal better. In terms of backward compatibility, that syntax might be viewed as a mistake by people unfamiliar with EAI. At 05:02 11-08-2009, John C Klensin wrote: >(4) We encourage the use of > From: addr1, addr2 >as a representation of > MAIL FROM:, ALT-ADDRESS="addr2" >Doing so requires that we accept the fact that the semantics are >a little different and the observation that multiple "From:" >fields are not well supported. We may have to encourage better >support, think about whether clarifying language in RFC 5322bis >is needed about what replies to such messages means, and so on. >But support for multiple From-address syntax has been specified >and required for many years (so no new syntax). I note that >there is, properly, no multiple-address syntax for "Sender:", >but think we can live with that. Using "From:" that way really >is a transition mechanism-- when it ceases to be useful, it >disappears. There has been some discussion outside this WG about multiple "From:" addresses. In comparison, it is less problematic than the new syntax. It is worth considering the option to change the semantics. There may be some problems with the "Reply-To:" header because of the way it is used by mailing lists. There are also some MUAs which do not emphasize that it is optional. Note that "Reply-To:" has a multiple-address syntax. Regards, -sm From klensin@jck.com Wed Aug 12 05:11:32 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34EF3A68DD for ; Wed, 12 Aug 2009 05:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgg+EXNOwZ9y for ; Wed, 12 Aug 2009 05:11:29 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 66AD93A67D9 for ; Wed, 12 Aug 2009 05:11:29 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MbCez-000Nfe-LV; Wed, 12 Aug 2009 08:10:29 -0400 Date: Wed, 12 Aug 2009 08:10:29 -0400 From: John C Klensin To: SM , ima@ietf.org Message-ID: <842AEE10356F54F88C5FFBD1@PST.JCK.COM> In-Reply-To: <6.2.5.6.2.20090812002323.0322bf50@resistor.net> References: <449399580.17668@cnnic.cn> <449957205.06226@cnnic.cn> <6.2.5.6.2.20090812002323.0322bf50@resistor.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] [recharter to standard track with ] Re: Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 12:11:32 -0000 --On Wednesday, August 12, 2009 01:39 -0700 SM wrote: >... > There may be some problems with the "Reply-To:" header because > of the way it is used by mailing lists. There are also some > MUAs which do not emphasize that it is optional. Note that > "Reply-To:" has a multiple-address syntax. Could you elaborate on the first part of this? I can imagine several problem scenarios, but am wondering about which ones you have experienced and/or have in mind. As was briefly discussed in Stockholm, I think that, quite independent of these other issues, we have a big problem moving forward unless the mailing list issues are well-understood and documented. While there may be disagreement within the WG about how perfect the mailing list solution needs to be (I don't know whether there is or not), I think that clear documentation and explanations are a very important requirement. john From chl@clerew.man.ac.uk Wed Aug 12 07:37:34 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111983A6B31 for ; Wed, 12 Aug 2009 07:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ajU+Csc83Ug for ; Wed, 12 Aug 2009 07:37:32 -0700 (PDT) Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by core3.amsl.com (Postfix) with ESMTP id 5F8593A6886 for ; Wed, 12 Aug 2009 07:37:31 -0700 (PDT) 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 v-smtp-auth-relay-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4a82ad3b.62bd.db for ima@ietf.org; Wed, 12 Aug 2009 12:53:31 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id n7CBrQER002896 for ; Wed, 12 Aug 2009 12:53:28 +0100 (BST) Date: Wed, 12 Aug 2009 12:53:26 +0100 To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 References: <647A5AE078721CED1CDD27F1@PST.JCK.COM> <1EE7EBC0-CB1A-4429-85E7-0B736774DBA2@ca.afilias.info> <083CC160C976BF6D530FAED0@PST.JCK.COM> <89B8C9B92592D42D143000BB@[192.168.1.110]> <6D1679BEC383FA50C7CE029A@PST.JCK.COM> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <6D1679BEC383FA50C7CE029A@PST.JCK.COM> User-Agent: Opera Mail/9.25 (SunOS) Subject: Re: [EAI] mailto: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 14:37:34 -0000 On Tue, 11 Aug 2009 13:02:17 +0100, John C Klensin wrote: > --On Tuesday, August 11, 2009 11:07 +0100 Charles Lindsey > wrote: > >> ... > > Actually, because this is a new feature and new syntax, I > suggest that the case which has to be made is that it is safe > and worth the trouble. In other words, those who are hesitant > about it should not be obligated to prove that it will not be > "horribly worse". It should not be "horribly worse" in the case of straightforward attempts to deliver mail, since if our protocola are implemented correctly, no sample of a header containing > should ever reach a legacy server that does not advertise UTF8SMTP. The risks all arise from the umpteen pieces of ancillary software (mailing list expanders, address lists, and the like) which tend to get written with less attention to the details of the standards. But I think this thread has now established that it is really a choice between two alternatives, neither of which will be 100% perfect. But your message contains a good analysis of the possibilities, so we should work on that. My own opinion is that we should stick with what we have got, and not rush into further attempts to get it onto the standards track at this time. OTOH, we should listen carefully to the Chinese, who are about to standardize our experimental protocols for their own use. To what extent can the Chinese standards be undone if we ultimately decide to standardize something slightly less ambitious? And how bad would it be if we decided to exclude that extra header syntax whilst the Chinese standard still allowed it? > >> But bear in and that legacy software is going to be around for >> many years to come in places where nobody ever encounters such >> a thing as Non-Ascii. So long after we find we no longer need >> to worry about all the more obscure downgradings, we may still >> find it essential to have alt-addresses available to us (at >> least in From/Reply-To headers). Or maybe not ... > > Yes, and we don't know how those legacy systems will behave when > confronted with "new" syntax. We can safely predict that some > will fail in a reasonable fashion and that others will behave > badly. We can predict that there will be some (perhaps many) > good quality implementations of in-transit downgrading and some > bad quality ones. We can also predict that there will be some > firewall/gateway issues with new headers and new syntax (because > those systems have a different mission and because, > historically, most of them have been of poor quality and very > slow to follow new SMTP extensions). > >> That is the question. Will we be wors off, or better off, >> without it (given that something is not going to work either >> way). > > The other is some version of what Ernie, Yao, and I are > suggesting ... > > (1) We drop forward-pointing downgrading... Except that I doubt it is the "forward pointing" stuff that is going to break. > > (2) We drop the > syntax as (i) too radical a change > for a transition mechanism, (ii) raising excessive opportunities > for security-related mischief, (iii) complicating MUA-Submission > Server interactions, (iv) complicating mailto, and (v) > representing a higher-than-necessary risk of "interesting" > foul-ups in legacy systems as well as totally confusing lusers > who haven't seen the syntax before. Yes, that is the main change proposed. > > (3) We preserve the alt-address parameter on the SMTP MAIL > command, while dropping it on RCPT (as the result of (1)). > That implies that we retain a fallback to an ASCII address for > NDNs and MDNs. Of course, that doesn't help with the blowback > problem, and might make it a tad worse. But the problem is > really not different from the single-address one -- when > possible, rejections at SMTP time are probably better than > sending NDN messages back and, if one is going to send an NDN, > being reasonably certain that the address to which it is sent is > valid for the sender is a good idea. But I think it would be bizarre to allow an ALT parameter in MAIL, but not in RCPT. That is a recipe for confusion. > > (4) We encourage the use of > From: addr1, addr2 > as a representation of > MAIL FROM:, ALT-ADDRESS="addr2" > Doing so requires that we accept the fact that the semantics are > a little different and the observation that multiple "From:" > fields are not well supported. ... That is a messy solution, but I agree it might work. -- 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 From sm@resistor.net Wed Aug 12 16:34:43 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56D83A6900 for ; Wed, 12 Aug 2009 16:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbF0xKKYHhxn for ; Wed, 12 Aug 2009 16:34:42 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id D0CE23A6AE9 for ; Wed, 12 Aug 2009 16:34:42 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n7CNXdFD000690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Aug 2009 16:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1250120028; x=1250206428; bh=JpZQOTOYjC9YTTr1f+Tc9x5zerUvotYvvB+ihmkWCsE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=VPZVgI3alljnpWe0HoKo1RyICIlGYuqGC8SQLKQXNp0N181naawCPPbiwl9QVsGQ0 nWWD3A7fhqsacf7uDs9IlFYCom8uchVdhgzTYFHv2St97UV22+UVzyeIZ+c2q6vzfN W9qnvo/0OX190b3NxOAm164DPd/mQsLobZWY0ENg= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=It2SHQKqRFsWHBtGQ2IAsmx0mBQyGOK5QOggSSIfkPhids0uPW3mmIt2cyerUZJHC VV739mXX4NcysW3kSxemAd/0bN0XORFfPX0DpYmOYafXF/74HSbK87hX7oXr1Tp01CL XNmnFpnnhRxK+wP4OZWDhndMq1Co0E4Rsy0CK0U= Message-Id: <6.2.5.6.2.20090812135135.030b57c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 12 Aug 2009 16:28:25 -0700 To: John C Klensin From: SM In-Reply-To: <842AEE10356F54F88C5FFBD1@PST.JCK.COM> References: <449399580.17668@cnnic.cn> <449957205.06226@cnnic.cn> <6.2.5.6.2.20090812002323.0322bf50@resistor.net> <842AEE10356F54F88C5FFBD1@PST.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] [recharter to standard track with ] Re: Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 23:34:43 -0000 Hi John, At 05:10 12-08-2009, John C Klensin wrote: >Could you elaborate on the first part of this? I can imagine >several problem scenarios, but am wondering about which ones you >have experienced and/or have in mind. I'm exploring a scenario where we have a multiple-address syntax in the "From:" as follows: From: EAI-addr, ASCII-addr The above specifies the mailboxes responsible for the writing of the message. Note that for EAI purposes (this is _not_ in the existing specifications), there is only one author. We can set a preference for the reply by including a "Reply-To:" header as follows: Reply-To: EAI-addr If the EAI-addr is removed because of a downgrade, we still have an address (ASCII-addr) to reach the author of the message. When a message goes through an EAI-aware mailing list, it can happen that the "Reply-To:" header gets stripped as some mailing lists set an explicit reply to the list. We lose the preference set by the author of the original message and we may have to generate a reply to both addresses. If the mailing list is not EAI-aware, we have to downgrade by removing the EAI-addr. We end up with one email address in the "From:" (ASCII-addr) and the "Reply-To:" header is removed. The main question about mailing lists which are EAI-aware is how to handle the subscription request. Some software use the address from the (envelope) "MAIL FROM:". As we can distinguish between the address and alt-address in there, it's not an issue. However, if the "From:" is used with a multiple-address syntax, we might end up with two subscription requests. It may be possible to get around that by using the address in the "Reply-To:" header as long as it only specifies one address. We could also use the same "mechanism" to determine whether the message is from an existing subscriber if the mailing lists restricts postings to existing subscribers. That is also applicable for requests to unsubscribe from the mailing list. For List-* headers, we could use two URLs, one with a "mailto:" to an ASCII-addr and the other to an EAI-addr. Even if those headers are downgraded wiith the removal of the EAI component, there will still be a valid address. The is an off-topic comment. I came across a case where a message was sent from A to B (an automated agent) with a "Reply-To:" header containing two addresses, A and C. B generated a reply to A and C. Regards, -sm From klensin@jck.com Wed Aug 12 17:26:22 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3157D3A6874 for ; Wed, 12 Aug 2009 17:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU5xyPNTVhuZ for ; Wed, 12 Aug 2009 17:26:21 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 01B9F3A6802 for ; Wed, 12 Aug 2009 17:26:21 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MbO8I-000EkC-7E; Wed, 12 Aug 2009 20:25:30 -0400 Date: Wed, 12 Aug 2009 20:25:29 -0400 From: John C Klensin To: SM Message-ID: <975372A8D78775C5EB1782B1@PST.JCK.COM> In-Reply-To: <6.2.5.6.2.20090812135135.030b57c8@resistor.net> References: <449399580.17668@cnnic.cn> <449957205.06226@cnnic.cn> <6.2.5.6.2.20090812002323.0322bf50@resistor.net> <842AEE10356F54F88C5FFBD1@PST.JCK.COM> <6.2.5.6.2.20090812135135.030b57c8@resistor.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] [recharter to standard track with ] Re: Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 00:26:22 -0000 --On Wednesday, August 12, 2009 16:28 -0700 SM wrote: > Hi John, > At 05:10 12-08-2009, John C Klensin wrote: >> Could you elaborate on the first part of this? I can imagine >> several problem scenarios, but am wondering about which ones >> you have experienced and/or have in mind. > > I'm exploring a scenario where we have a multiple-address > syntax in the "From:" as follows: > > From: EAI-addr, ASCII-addr > > The above specifies the mailboxes responsible for the writing > of the message. Note that for EAI purposes (this is _not_ in > the existing specifications), there is only one author. To be more precise, the existing specification doesn't specify the relationship among the From: addresses at all. So it could be two addresses for one author, addresses for two authors, etc. > We can set a preference for the reply by including a > "Reply-To:" header as follows: > > Reply-To: EAI-addr > > If the EAI-addr is removed because of a downgrade, we still > have an address (ASCII-addr) to reach the author of the > message. Yes. Of course, if we had no Reply-to header field at all, most (but not all) MUAs would assume the contents of the From: field, so, at least for those MUAs, From: EAI-addr, ASCII-addr Reply-To: EAI-addr, ASCII-addr and the From: field with no Reply-to would be equivalent. > When a message goes through an EAI-aware mailing list, it can > happen that the "Reply-To:" header gets stripped as some > mailing lists set an explicit reply to the list. We lose the > preference set by the author of the original message and we > may have to generate a reply to both addresses. Yes. And now I see what you are getting at. Sorry for being slow. > If the mailing list is not EAI-aware, we have to downgrade by > removing the EAI-addr. We end up with one email address in > the "From:" (ASCII-addr) and the "Reply-To:" header is removed. > The main question about mailing lists which are EAI-aware is > how to handle the subscription request. Some software use the > address from the (envelope) "MAIL FROM:". As we can > distinguish between the address and alt-address in there, it's > not an issue. However, if the "From:" is used with a > multiple-address syntax, we might end up with two subscription > requests. If I were writing mailing list software, I'd take serious exception to the idea of subscribing the From: address if there were more than one of them. Indeed, that is exactly what I did many years ago -- multiple "From:" addresses implied that one needed to specify the address one wanted to subscribe explicitly. I assume that some mailing list packages don't do that. > It may be possible to get around that by using the > address in the "Reply-To:" header as long as it only specifies > one address. I think subscribing a Reply-to: address would be a really bad idea. One would need either a single address in the "From:" header field (ideally, one that exactly matched the address in the MAIL command), or one would need a command to the mailing list manager that specifies the relevant address. Again, this is an area in which our giving explicit advice would probably be welcome. And we need to get the mailing list document done. > We could also use the same "mechanism" to determine whether > the message is from an existing subscriber if the mailing > lists restricts postings to existing subscribers. That is > also applicable for requests to unsubscribe from the mailing > list. Modulo the above, yes. > For List-* headers, we could use two URLs, one with a > "mailto:" to an ASCII-addr and the other to an EAI-addr. Even > if those headers are downgraded wiith the removal of the EAI > component, there will still be a valid address. Yes. > The is an off-topic comment. I came across a case where a > message was sent from A to B (an automated agent) with a > "Reply-To:" header containing two addresses, A and C. B > generated a reply to A and C. Unless I'm missing something, I think that is the correct behavior... unless B is automated at the MTA level and falls under the rules that require it to generate MAIL FROM:<> in which case I think it should be using the return-path address. john From sm@resistor.net Thu Aug 13 04:34:40 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FFD53A6A71 for ; Thu, 13 Aug 2009 04:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouYMtVDt3nEA for ; Thu, 13 Aug 2009 04:34:39 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id D9F9B3A6A3C for ; Thu, 13 Aug 2009 04:34:08 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n7DAkM3k022681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 03:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1250160392; x=1250246792; bh=cRqgivabdDhf7biz0J17FqsJkmGBefqFvZDBcKiigbM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=oKR8owzTP8waImmKKGYC6IemwhasxHYNUl9Lk0/eGEL+y7vwYjnlOhbEAYUhffv7e xcuNsW0q2OKPFsKj6qsl7cDY85yckCP+RF2CdqnLKsKbneqquz31NEXNHqNxhCakcE Df6/mv1Zr0VyjgdMgYkGB+6d/IjcbqT9SePIrwgM= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=w/B9P+3PhFbdev3nOI5xxMFLfv1N26ds9Y/ap6lG5ULCpVisQmia30kDjvQLAsTLe 9cXGJa7uhRwEKHMNFIhB+9y4AyZHFMcMmRSbqdSh/Aws2k+LFMq/FmdfYRMC0WZ8HhQ 96MHknqPOFU+y1jBBYiAFWUWKnFtVsTeLZTGhm0= Message-Id: <6.2.5.6.2.20090812233830.02f605d0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Aug 2009 03:46:09 -0700 To: John C Klensin From: SM In-Reply-To: <975372A8D78775C5EB1782B1@PST.JCK.COM> References: <449399580.17668@cnnic.cn> <449957205.06226@cnnic.cn> <6.2.5.6.2.20090812002323.0322bf50@resistor.net> <842AEE10356F54F88C5FFBD1@PST.JCK.COM> <6.2.5.6.2.20090812135135.030b57c8@resistor.net> <975372A8D78775C5EB1782B1@PST.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] [recharter to standard track with ] Re: Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 11:34:40 -0000 Hi John, At 17:25 12-08-2009, John C Klensin wrote: >To be more precise, the existing specification doesn't specify >the relationship among the From: addresses at all. So it could >be two addresses for one author, addresses for two authors, etc. Yes. >Yes. Of course, if we had no Reply-to header field at all, >most (but not all) MUAs would assume the contents of the From: >field, so, at least for those MUAs, > From: EAI-addr, ASCII-addr > Reply-To: EAI-addr, ASCII-addr >and the From: field with no Reply-to would be equivalent. In the example I gave, there was only an EAI-addr in the "Reply-To:". That was to suggest to the recipient to use the EAI address instead of the two addresses from the "From:" (see above description of MUA behavior). >If I were writing mailing list software, I'd take serious >exception to the idea of subscribing the From: address if there >were more than one of them. Indeed, that is exactly what I did >many years ago -- multiple "From:" addresses implied that one >needed to specify the address one wanted to subscribe >explicitly. I assume that some mailing list packages don't do >that. I tested that case with two non-EAI addresses by sending a request to a mailing list handled by a widely used package. The reply was sent to the first email address specified in the "From:" of the original message. The message body seems to have been generated using the (envelope) "MAIL FROM:". I haven't read the source code to determine whether this is an unusual behavior due to the use of sub-addressing or if it was actually the address detail of the first "From:" address being removed when the address was parsed. >I think subscribing a Reply-to: address would be a really bad >idea. One would need either a single address in the "From:" >header field (ideally, one that exactly matched the address in >the MAIL command), or one would need a command to the mailing >list manager that specifies the relevant address. Based on the example you provided above, we would not be able to subscribe as we do usually. We can subscribe by providing the email address as a parameter to the subscribe command. If the mailing list manager is not EAI-aware, then it may require a second request if the email address provided in the first instance was an EAI one. >Again, this is an area in which our giving explicit advice would >probably be welcome. And we need to get the mailing list >document done. Agreed. >Unless I'm missing something, I think that is the correct >behavior... unless B is automated at the MTA level and falls >under the rules that require it to generate > MAIL FROM:<> >in which case I think it should be using the return-path address. B and C are automated agents operating at the MDA level. I'll categorize them as service responders. The addresses in the "Reply-To:" field should not have been used by B for the response. In this case, that caused B to generate a message for C. I'm not focusing on the correct behavior in this particular case as it may be more appropriate to discuss about that in a different forum. The point is more about understanding the response behavior when a multiple-address syntax is used. Regards, -sm From klensin@jck.com Thu Aug 13 06:47:29 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130E23A68B8 for ; Thu, 13 Aug 2009 06:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u84pApn+LSm8 for ; Thu, 13 Aug 2009 06:47:28 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id D8FF13A68B2 for ; Thu, 13 Aug 2009 06:47:27 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MbYbD-0001dj-7d; Thu, 13 Aug 2009 07:36:03 -0400 Date: Thu, 13 Aug 2009 07:36:02 -0400 From: John C Klensin To: SM Message-ID: In-Reply-To: <6.2.5.6.2.20090812233830.02f605d0@resistor.net> References: <449399580.17668@cnnic.cn> <449957205.06226@cnnic.cn> <6.2.5.6.2.20090812002323.0322bf50@resistor.net> <842AEE10356F54F88C5FFBD1@PST.JCK.COM> <6.2.5.6.2.20090812135135.030b57c8@resistor.net> <975372A8D78775C5EB1782B1@PST.JCK.COM> <6.2.5.6.2.20090812233830.02f605d0@resistor.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ima@ietf.org Subject: Re: [EAI] [recharter to standard track with ] Re: Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 13:47:29 -0000 Agree on all comments. john --On Thursday, August 13, 2009 03:46 -0700 SM wrote: > Hi John, > At 17:25 12-08-2009, John C Klensin wrote: >> To be more precise, the existing specification doesn't specify >> the relationship among the From: addresses at all. So it >> could be two addresses for one author, addresses for two >> authors, etc. > > Yes. > >> Yes. Of course, if we had no Reply-to header field at all, >> most (but not all) MUAs would assume the contents of the From: >> field, so, at least for those MUAs, >> From: EAI-addr, ASCII-addr >> Reply-To: EAI-addr, ASCII-addr >> and the From: field with no Reply-to would be equivalent. > > In the example I gave, there was only an EAI-addr in the > "Reply-To:". That was to suggest to the recipient to use the > EAI address instead of the two addresses from the "From:" (see > above description of MUA behavior). > >> If I were writing mailing list software, I'd take serious >> exception to the idea of subscribing the From: address if >> there were more than one of them. Indeed, that is exactly >> what I did many years ago -- multiple "From:" addresses >> implied that one needed to specify the address one wanted to >> subscribe explicitly. I assume that some mailing list >> packages don't do that. > > I tested that case with two non-EAI addresses by sending a > request to a mailing list handled by a widely used package. > The reply was sent to the first email address specified in the > "From:" of the original message. The message body seems to > have been generated using the (envelope) "MAIL FROM:". I > haven't read the source code to determine whether this is an > unusual behavior due to the use of sub-addressing or if it was > actually the address detail of the first "From:" address being > removed when the address was parsed. > >> I think subscribing a Reply-to: address would be a really bad >> idea. One would need either a single address in the "From:" >> header field (ideally, one that exactly matched the address in >> the MAIL command), or one would need a command to the mailing >> list manager that specifies the relevant address. > > Based on the example you provided above, we would not be able > to subscribe as we do usually. We can subscribe by providing > the email address as a parameter to the subscribe command. If > the mailing list manager is not EAI-aware, then it may require > a second request if the email address provided in the first > instance was an EAI one. > >> Again, this is an area in which our giving explicit advice >> would probably be welcome. And we need to get the mailing >> list document done. > > Agreed. > >> Unless I'm missing something, I think that is the correct >> behavior... unless B is automated at the MTA level and falls >> under the rules that require it to generate >> MAIL FROM:<> >> in which case I think it should be using the return-path >> address. > > B and C are automated agents operating at the MDA level. I'll > categorize them as service responders. The addresses in the > "Reply-To:" field should not have been used by B for the > response. In this case, that caused B to generate a message > for C. I'm not focusing on the correct behavior in this > particular case as it may be more appropriate to discuss about > that in a different forum. The point is more about > understanding the response behavior when a multiple-address > syntax is used. > > Regards, > -sm From McQuilWP@pobox.com Thu Aug 13 09:58:06 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6C43A6C4C for ; Thu, 13 Aug 2009 09:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45JTfCNiQ3j0 for ; Thu, 13 Aug 2009 09:58:05 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 7BE2C3A6A71 for ; Thu, 13 Aug 2009 09:58:04 -0700 (PDT) Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 4A7F09DF4; Thu, 13 Aug 2009 12:57:31 -0400 (EDT) Received: from [192.168.0.3] (unknown [68.107.60.165]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPA id C994B9DF3; Thu, 13 Aug 2009 12:57:29 -0400 (EDT) Date: Thu, 13 Aug 2009 09:57:28 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <601040451.20090813095728@pobox.com> To: IMA Discussion In-Reply-To: <975372A8D78775C5EB1782B1@PST.JCK.COM> References: <449399580.17668@cnnic.cn> <449957205.06226@cnnic.cn> <6.2.5.6.2.20090812002323.0322bf50@resistor.net> <842AEE10356F54F88C5FFBD1@PST.JCK.COM> <6.2.5.6.2.20090812135135.030b57c8@resistor.net> <975372A8D78775C5EB1782B1@PST.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 63D9A364-882A-11DE-B84E-EAC21EFB4A78-02871704!a-pb-sasl-quonix.pobox.com Subject: Re: [EAI] [recharter to standard track with ] Re: Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 16:58:06 -0000 On Wed, 2009-08-12, John C Klensin wrote: > --On Wednesday, August 12, 2009 16:28 -0700 SM > wrote: >> I'm exploring a scenario where we have a multiple-address >> syntax in the "From:" as follows: >> >> From: EAI-addr, ASCII-addr >> >> The above specifies the mailboxes responsible for the writing >> of the message. Note that for EAI purposes (this is _not_ in >> the existing specifications), there is only one author. > To be more precise, the existing specification doesn't specify > the relationship among the From: addresses at all. So it could > be two addresses for one author, addresses for two authors, etc. -- Bill McQuillan From klensin@jck.com Thu Aug 13 10:25:44 2009 Return-Path: X-Original-To: ima@core3.amsl.com Delivered-To: ima@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0AC43A693C for ; Thu, 13 Aug 2009 10:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3SNHBEl3hLG for ; Thu, 13 Aug 2009 10:25:44 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id CE5FF3A6C3A for ; Thu, 13 Aug 2009 10:25:43 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Mbe2s-0009L1-85; Thu, 13 Aug 2009 13:24:58 -0400 Date: Thu, 13 Aug 2009 13:24:57 -0400 From: John C Klensin To: Bill McQuillan , IMA Discussion Message-ID: <1691189DC42BDE85297DEB0F@PST.JCK.COM> In-Reply-To: <601040451.20090813095728@pobox.com> References: <449399580.17668@cnnic.cn> <449957205.06226@cnnic.cn> <6.2.5.6.2.20090812002323.0322bf50@resistor.net> <842AEE10356F54F88C5FFBD1@PST.JCK.COM> <6.2.5.6.2.20090812135135.030b57c8@resistor.net> <975372A8D78775C5EB1782B1@PST.JCK.COM> <601040451.20090813095728@pobox.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] [recharter to standard track with ] Re: Downgrade simplifications X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 17:25:44 -0000 --On Thursday, August 13, 2009 09:57 -0700 Bill McQuillan wrote: >... >