From ima-bounces@ietf.org Tue Jan 09 02:46:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Bfo-0000QV-ST; Tue, 09 Jan 2007 02:45:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Bfo-0000QQ-2U for ima@ietf.org; Tue, 09 Jan 2007 02:45:32 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Bfk-0004AK-AR for ima@ietf.org; Tue, 09 Jan 2007 02:45:32 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l097jMiT013662 for ; Tue, 9 Jan 2007 16:45:22 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 5b6a_5c834af8_9fb5_11db_8e10_0014221fa3c9; Tue, 09 Jan 2007 16:45:22 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:33590) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 9 Jan 2007 16:44:37 +0900 Message-Id: <6.0.0.20.2.20070109164320.07dab180@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 09 Jan 2007 16:44:59 +0900 To: Harald Tveit Alvestrand From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ima@ietf.org Subject: [EAI] status of Scenarios draft X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hello Harald, It seems that the scenarios draft has expired. Do you plan to resubmit it, or not? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 09 03:02:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4BwA-0008Vp-Eb; Tue, 09 Jan 2007 03:02:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4BwA-0008Uh-27 for ima@ietf.org; Tue, 09 Jan 2007 03:02:26 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Bw8-0007xv-OA for ima@ietf.org; Tue, 09 Jan 2007 03:02:26 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AF3932596AF; Tue, 9 Jan 2007 08:58:39 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04501-06; Tue, 9 Jan 2007 08:58:34 +0100 (CET) Received: from [192.168.1.108] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id E5ABA258100; Tue, 9 Jan 2007 08:58:33 +0100 (CET) Date: Tue, 09 Jan 2007 09:02:14 +0100 From: Harald Alvestrand To: Martin Duerst Message-ID: <7BBF9F3744FAE70317D65F0C@[192.168.1.108]> In-Reply-To: <6.0.0.20.2.20070109164320.07dab180@localhost> References: <6.0.0.20.2.20070109164320.07dab180@localhost> X-Mailer: Mulberry/4.0.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ima@ietf.org Subject: [EAI] Re: status of Scenarios draft X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I plan to resubmit it as soon as I have verified consistency with the framework draft. But getting the framework draft to the IESG is more important - and also requires me to do some homework. Harald --On 9. januar 2007 16:44 +0900 Martin Duerst wrote: > Hello Harald, > > It seems that the scenarios draft has expired. Do you plan to resubmit > it, or not? > > Regards, Martin. > > ># -#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University ># -#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp ># > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 11 03:24:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4vDk-0002NN-MY; Thu, 11 Jan 2007 03:23:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4vDj-0002Lj-5m for ima@ietf.org; Thu, 11 Jan 2007 03:23:35 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4vDi-0002x7-Fw for ima@ietf.org; Thu, 11 Jan 2007 03:23:35 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DECCE2596CA; Thu, 11 Jan 2007 09:19:49 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20803-08; Thu, 11 Jan 2007 09:19:42 +0100 (CET) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 81FB72596C9; Thu, 11 Jan 2007 09:19:42 +0100 (CET) Message-ID: <45A5F3FE.5080106@alvestrand.no> Date: Thu, 11 Jan 2007 09:23:26 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.8 (X11/20061117) MIME-Version: 1.0 To: Ted Hardie Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: EAI WG Subject: [EAI] Request for publication for draft-ietf-eai-framework-04 as INFORMATIONAL X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org The EAI WG hereby requests publication of draft-ietf-eai-framework-04 as an Informational document. The EAI WG further requests that an IETF Last Call be performed on the document prior to approval. The writeup below is based on draft-ietf-proto-wgchair-doc-shepherding-08. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Harald Alvestrand is Document Shepherd. He has reviewed the document. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The review in the WG has been thorough, and many people who are not WG members are aware of the document. We think that the IETF would benefit from having its attention called to the document, so that people are aware that the EAI experiment is being tried, and so that any issues with the general approach taken can be raised before the WG settles on final specifications for the technical components of the proposal; this is the reason for asking for publication of this document before the technical specifications are finished. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. The format of email addresses is embedded in a lot of other specifications, and these need to evaluate whether their specifications will be affected by this work, but that is a review of their documents, not a review of this document. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are some sections in the document that might not reflect a solid informed consensus in the WG - notably sections 6.5 and 6.6. However, the WG has elected not to have further discussion on these in WG Last Call, so we can assume that the WG will not object to the text as given - the text mostly serves to point out areas where further work might be needed, and has limited immediate technical impact. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? As far as concern has been expressed, the WG seems satisfied with this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. Online id-nits checker complains that the domain name "any.thing.goes" does not end in "example"; this is a left-hand side of an email address, so does not constitute a break with the I-D checklist. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. All normative references are published. The document lists the actual technical specifications it is a framework for as informative references. This is believed to be factually correct - it is not necessary to have the specifications to interpret the framework, and since it is a framework, it cannot be implemented. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the Yes. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes, there are no such sections. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. Working Group Summary The decision to not provide any means of "automatic encapsulation" of UTF-8 email addresses, but instead insist that the sender specify an alternate address for downgrading purposes, was controversial, but was definitely the decision of the working group. Document Quality This document has helped guide the development of the technical specification. Having the document stable will facilitate finishing the rest. Personnel The Document Shepherd is Harald Alvestrand. The responsible AD is Ted Hardie. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 12 10:31:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5OMb-0005CV-WD; Fri, 12 Jan 2007 10:30:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5OMY-0005BQ-U3; Fri, 12 Jan 2007 10:30:38 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H5OMY-0005Lo-L0; Fri, 12 Jan 2007 10:30:38 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 9443E2AD11; Fri, 12 Jan 2007 15:30:08 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H5OM4-0004il-C6; Fri, 12 Jan 2007 10:30:08 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 12 Jan 2007 10:30:08 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ima@ietf.org Subject: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'Overview and Framework for Internationalized Email ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-01-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-eai-framework-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14701&rfc_flag=0 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 16 21:46:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H70oH-0003Bj-UD; Tue, 16 Jan 2007 21:45:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H70oG-0003BS-7D; Tue, 16 Jan 2007 21:45:56 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H70oE-0007Py-Re; Tue, 16 Jan 2007 21:45:56 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0H2jrTr022173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Jan 2007 18:45:53 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0H2jpiJ005336; Tue, 16 Jan 2007 18:45:51 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 16 Jan 2007 18:44:56 -0800 To: ietf@ietf.org, ima@ietf.org, john+ietf@jck.com From: Randall Gellens Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org (1) This version still has some editor's notes. Are these intended for publication? (2) In section 1.3: An "i18mail user" has one or more non-ASCII email addresses. Such a user may have ASCII addresses too; if the user has more than one email account and corresponding address, or more than one alias for the same address, he or she has some method to choose which address to use on outgoing email. Note that under this definition, it is not possible to tell from the address that an email sender or recipient is an i18mail user. There is no such thing as an "i18mail message"; the term applies only to users and their agents and capabilities. Does the second-to-last sentence refer to an ASCII address, or any address? The wording implies any address, but if an address is non-ASCII, surely that is a good sign that the owner of that address is an i18mail user? (3) In section 4.3: the risk should be minimized by the fact that the selection of submission servers are presumably under the control of the sender's client and the selection of potential intermediate relays is under the control of the administration of the final delivery server. [snip] For situations in which a client encounters a server that does not support UTF8SMTP, there are basically two possibilities: o Reject the message or generate and send a non-delivery message, [snip] o Figure out a way to downgrade the envelope or message body in I apologize if this has already been discussed, but in light of the first quoted sentence, the two possible actions can be augmented by another approach: try an alternate MX host and/or requeue the message and try later. That is, because the mail path is normally under administrative control of the end points or their organizations, it may be reasonable to conclude that UTF8SMTP is normally supported along this path, and if a system is encountered which doesn't support it, this may be a temporary failure. Obviously, if this is tried but persistently fails, one of the other two methods must be used. (This could also be mentioned in the smtpext document.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Truth resides in every human heart, and one has to search for it there, and to be guided by truth as one sees it. But no one has a right to coerce others to act according to his own view of the truth. --Gandhi _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 09:45:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7C2T-00038r-3b; Wed, 17 Jan 2007 09:45:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7C2Q-00038X-Go; Wed, 17 Jan 2007 09:45:18 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7C2P-0005qs-8i; Wed, 17 Jan 2007 09:45:18 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H7C2L-000BXn-Hb; Wed, 17 Jan 2007 09:45:13 -0500 Date: Wed, 17 Jan 2007 09:45:12 -0500 From: John C Klensin To: Randall Gellens Subject: Re: [EAI] Last Call: draft-ietf-eai-framework -- editor's notes Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ietf@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 16 January, 2007 18:44 -0800 Randall Gellens wrote: > (1) This version still has some editor's notes. Are these > intended for publication? No. I had intended to change the xml2rfc parameters to shut them off when I submitted the draft and forgot. My apologies. If they are significantly confusing to anyone, let me know and I'll post a new version of the draft. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 12:47:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7EsB-0002nS-MT; Wed, 17 Jan 2007 12:46:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Es9-0002n4-Gn; Wed, 17 Jan 2007 12:46:53 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Es8-00082u-6A; Wed, 17 Jan 2007 12:46:53 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0HHknTw029932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2007 09:46:49 -0800 Received: from [[192.168.1.13]] (vpn-10-50-0-9.qualcomm.com [10.50.0.9]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0HHkkUr001072; Wed, 17 Jan 2007 09:46:47 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 17 Jan 2007 09:42:02 -0800 To: John C Klensin From: Randall Gellens Subject: Re: [EAI] Last Call: draft-ietf-eai-framework -- editor's notes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 9:45 AM -0500 1/17/07, John C Klensin wrote: > --On Tuesday, 16 January, 2007 18:44 -0800 Randall Gellens > wrote: > >> (1) This version still has some editor's notes. Are these >> intended for publication? > > No. I had intended to change the xml2rfc parameters to shut > them off when I submitted the draft and forgot. My apologies. > If they are significantly confusing to anyone, let me know and > I'll post a new version of the draft. I don't think they're confusing, but some of them suggest unresolved issues. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The curse of all Art is that the devotee or disciple is always more certain than the Priest. --Rudyard Kipling _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 14:44:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7GiO-0004UF-RO; Wed, 17 Jan 2007 14:44:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7GiM-0004Tt-Sn; Wed, 17 Jan 2007 14:44:54 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Gi7-0001iB-IH; Wed, 17 Jan 2007 14:44:54 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BEBDF2596D8; Wed, 17 Jan 2007 20:40:47 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17694-01; Wed, 17 Jan 2007 20:40:39 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 04C9B2596D1; Wed, 17 Jan 2007 20:40:38 +0100 (CET) Message-ID: <45AE7C9B.6010100@alvestrand.no> Date: Wed, 17 Jan 2007 20:44:27 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Randall Gellens Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: john+ietf@jck.com, ietf@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Randall Gellens wrote: > (1) This version still has some editor's notes. Are these intended > for publication? No. The writeup didn't get copied into the Last Call, but as WG chair, I believe that the document is complete if all the editor's notes are deleted. Some of them point to areas that might be improved, but, in my opinion, such improvements are not a requirement for publication. > > > (2) In section 1.3: > An "i18mail user" has one or more non-ASCII email addresses. Such a > user may have ASCII addresses too; if the user has more than one > email account and corresponding address, or more than one alias for > the same address, he or she has some method to choose which address > to use on outgoing email. Note that under this definition, it is not > possible to tell from the address that an email sender or recipient > is an i18mail user. There is no such thing as an "i18mail message"; > the term applies only to users and their agents and capabilities. > > Does the second-to-last sentence refer to an ASCII address, or any > address? The wording implies any address, but if an address is > non-ASCII, surely that is a good sign that the owner of that address > is an i18mail user? Right. The situation that is being warned against is taking an ASCII address as a clear sign that the address owner is not an i18mail user. > > > (3) In section 4.3: > the risk should be > minimized by the fact that the selection of submission servers are > presumably under the control of the sender's client and the selection > of potential intermediate relays is under the control of the > administration of the final delivery server. > > [snip] > > For situations in which a client encounters a server that does not > support UTF8SMTP, there are basically two possibilities: > > o Reject the message or generate and send a non-delivery message, > > [snip] > > o Figure out a way to downgrade the envelope or message body in > > I apologize if this has already been discussed, but in light of the > first quoted sentence, the two possible actions can be augmented by > another approach: try an alternate MX host and/or requeue the message > and try later. That is, because the mail path is normally under > administrative control of the end points or their organizations, it > may be reasonable to conclude that UTF8SMTP is normally supported > along this path, and if a system is encountered which doesn't support > it, this may be a temporary failure. Obviously, if this is tried but > persistently fails, one of the other two methods must be used. > > (This could also be mentioned in the smtpext document.) > I haven't seen that possibility raised. I'm somewhat skeptical that it would be an improvement (it makes the delay before error reporting variable), but it's worth a discussion. WG? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 15:21:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7HHQ-0006Jp-IE; Wed, 17 Jan 2007 15:21:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7HHO-0006JR-VS; Wed, 17 Jan 2007 15:21:06 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7HHN-0007NH-Iz; Wed, 17 Jan 2007 15:21:06 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0HKL1BF024502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2007 12:21:01 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0HKL0Al028062; Wed, 17 Jan 2007 12:21:00 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <45AE7C9B.6010100@alvestrand.no> References: <45AE7C9B.6010100@alvestrand.no> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 17 Jan 2007 12:12:05 -0800 To: Harald Alvestrand From: Randall Gellens Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: john+ietf@jck.com, ietf@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 8:44 PM +0100 1/17/07, Harald Alvestrand wrote: >> (2) In section 1.3: >> An "i18mail user" has one or more non-ASCII email addresses. Such a >> user may have ASCII addresses too; if the user has more than one >> email account and corresponding address, or more than one alias for >> the same address, he or she has some method to choose which address >> to use on outgoing email. Note that under this definition, it is not >> possible to tell from the address that an email sender or recipient >> is an i18mail user. There is no such thing as an "i18mail message"; >> the term applies only to users and their agents and capabilities. >> >> Does the second-to-last sentence refer to an ASCII address, or any >> address? The wording implies any address, but if an address is >> non-ASCII, surely that is a good sign that the owner of that >> address is an i18mail user? > Right. The situation that is being warned against is taking an > ASCII address as a clear sign that the address owner is not an > i18mail user. I'd like to see the text improved to make this more clear. As a suggestion, replace: Note that under this definition, it is not possible to tell from the address that an email sender or recipient is an i18mail user. with: Note that under this definition, it is not possible to tell from an ASCII address if an email sender or recipient is an i18mail user or not. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- We have met the enemy, and he is us. --Walt Kelly _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 15:33:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7HT4-0002Et-G2; Wed, 17 Jan 2007 15:33:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7HT2-0002Ef-9x; Wed, 17 Jan 2007 15:33:08 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7HSz-0000s5-TC; Wed, 17 Jan 2007 15:33:08 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0HKX1Bt026195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2007 12:33:01 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0HKWxA0031346; Wed, 17 Jan 2007 12:33:00 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <45AE7C9B.6010100@alvestrand.no> References: <45AE7C9B.6010100@alvestrand.no> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 17 Jan 2007 12:25:29 -0800 To: Harald Alvestrand From: Randall Gellens Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.6 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: john+ietf@jck.com, ietf@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 8:44 PM +0100 1/17/07, Harald Alvestrand wrote: >> (3) In section 4.3: >> the risk should be >> minimized by the fact that the selection of submission servers are >> presumably under the control of the sender's client and the selection >> of potential intermediate relays is under the control of the >> administration of the final delivery server. >> >> [snip] >> >> For situations in which a client encounters a server that does not >> support UTF8SMTP, there are basically two possibilities: >> >> o Reject the message or generate and send a non-delivery message, >> >> [snip] >> >> o Figure out a way to downgrade the envelope or message body in >> >> I apologize if this has already been discussed, but in light of >> the first quoted sentence, the two possible actions can be >> augmented by another approach: try an alternate MX host and/or >> requeue the message and try later. That is, because the mail path >> is normally under administrative control of the end points or >> their organizations, it may be reasonable to conclude that >> UTF8SMTP is normally supported along this path, and if a system is >> encountered which doesn't support it, this may be a temporary >> failure. Obviously, if this is tried but persistently fails, one >> of the other two methods must be used. >> >> (This could also be mentioned in the smtpext document.) >> > I haven't seen that possibility raised. I'm somewhat skeptical that > it would be an improvement (it makes the delay before error > reporting variable), but it's worth a discussion. WG? If it is a temporary failure, and the message is sent successfully after retrying, then it was a good thing to do. If there is always an ASCII-only SMTP server in the path, then retrying only adds delay to the failure. So: is it advisable for a system to be optimistic that the message will be able to be sent? I think so, as the document says: the fact that the selection of submission servers are presumably under the control of the sender's client and the selection of potential intermediate relays is under the control of the administration of the final delivery server. This makes the most sense when sending non-ASCII to non-ASCII, I think. It also makes sense when sending ASCII to non-ASCII and the sender's submission server is UT8SMTP compliant. I'd probably not do it when sending non-ASCII to ASCII. In any event, I think this is a quality-of-implementation thing: it should be suggested by the documents but certainly not required for compliance. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Arguments are to be avoided; they are always vulgar and often convincing. --Oscar Wilde _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 15:59:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Hsr-00062h-AW; Wed, 17 Jan 2007 15:59:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Hsp-00062H-Db; Wed, 17 Jan 2007 15:59:47 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Hsn-0004lX-5N; Wed, 17 Jan 2007 15:59:47 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H7Hsk-000Dzb-Q6; Wed, 17 Jan 2007 15:59:42 -0500 Date: Wed, 17 Jan 2007 15:59:41 -0500 From: John C Klensin To: Randall Gellens , Harald Alvestrand Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC Message-ID: In-Reply-To: References: <45AE7C9B.6010100@alvestrand.no> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ietf@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 17 January, 2007 12:12 -0800 Randall Gellens wrote: >>> Does the second-to-last sentence refer to an ASCII address, >>> or any address? The wording implies any address, but if >>> an address is non-ASCII, surely that is a good sign that >>> the owner of that address is an i18mail user? >> Right. The situation that is being warned against is taking >> an ASCII address as a clear sign that the address owner is >> not an i18mail user. > > I'd like to see the text improved to make this more clear. As > a suggestion, replace: > > Note that under this definition, it is not possible to > tell from > the address that an email sender or recipient is an > i18mail user. > > with: > > Note that under this definition, it is not possible to > tell from > an ASCII address if an email sender or recipient is an > i18mail > user or not. Hmm. One still can't tell from a non-ASCII address that the recipient is an i18mail user or not, one can only tell that the sender thinks that user is. I'm happy to make the change Randy suggests unless others object (I think it improves things). But, if we are going to do so, let's figure out text to be sure things are completely right. In that context, it seems to me as if the suggested replacement sentence needs an additional few words. Suggestions welcome. john (editor) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 16:14:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7I7J-0005ZY-57; Wed, 17 Jan 2007 16:14:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Hvq-0000vx-Gb; Wed, 17 Jan 2007 16:02:55 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7HvP-0005HX-QM; Wed, 17 Jan 2007 16:02:53 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H7HvN-000E0V-OM; Wed, 17 Jan 2007 16:02:25 -0500 Date: Wed, 17 Jan 2007 16:02:24 -0500 From: John C Klensin To: Randall Gellens , Harald Alvestrand Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC Message-ID: In-Reply-To: References: <45AE7C9B.6010100@alvestrand.no> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.6 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ietf@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 17 January, 2007 12:25 -0800 Randall Gellens wrote: >.... >>> (This could also be mentioned in the smtpext document.) >>> >> I haven't seen that possibility raised. I'm somewhat >> skeptical that it would be an improvement (it makes the >> delay before error reporting variable), but it's worth a >> discussion. WG? > > If it is a temporary failure, and the message is sent > successfully after retrying, then it was a good thing to do. > If there is always an ASCII-only SMTP server in the path, then > retrying only adds delay to the failure. So: is it advisable > for a system to be optimistic that the message will be able to > be sent? I think so, as the document says: > > the fact that the selection of submission servers are > presumably under the control of the sender's client and > the selection > of potential intermediate relays is under the control of > the > administration of the final delivery server. > > This makes the most sense when sending non-ASCII to non-ASCII, > I think. It also makes sense when sending ASCII to non-ASCII > and the sender's submission server is UT8SMTP compliant. I'd > probably not do it when sending non-ASCII to ASCII. > > In any event, I think this is a quality-of-implementation > thing: it should be suggested by the documents but certainly > not required for compliance. Speaking for myself only, I'd prefer to see this mentioned in the downgrade document, and maybe in the SMTPext one, but not in Framework. In any event, I'd recommend/request that you specify text and where it should go. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 17:35:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JMq-0000T8-Jd; Wed, 17 Jan 2007 17:34:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JMn-0000Sn-Vb; Wed, 17 Jan 2007 17:34:49 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7JMm-0007bd-K0; Wed, 17 Jan 2007 17:34:49 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0HMYhL2018860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2007 14:34:44 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0HMYfb8021544; Wed, 17 Jan 2007 14:34:42 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <45AE7C9B.6010100@alvestrand.no> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 17 Jan 2007 14:31:31 -0800 To: John C Klensin , Harald Alvestrand From: Randall Gellens Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.6 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ietf@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 3:59 PM -0500 1/17/07, John C Klensin wrote: > --On Wednesday, 17 January, 2007 12:12 -0800 Randall Gellens > wrote: > >>>> Does the second-to-last sentence refer to an ASCII address, >>>> or any address? The wording implies any address, but if >>>> an address is non-ASCII, surely that is a good sign that >>>> the owner of that address is an i18mail user? >>> Right. The situation that is being warned against is taking >>> an ASCII address as a clear sign that the address owner is >>> not an i18mail user. >> >> I'd like to see the text improved to make this more clear. As >> a suggestion, replace: >> >> Note that under this definition, it is not possible to >> tell from >> the address that an email sender or recipient is an >> i18mail user. >> >> with: >> >> Note that under this definition, it is not possible to >> tell from >> an ASCII address if an email sender or recipient is an >> i18mail >> user or not. > > Hmm. One still can't tell from a non-ASCII address that the > recipient is an i18mail user or not, one can only tell that the > sender thinks that user is. > > I'm happy to make the change Randy suggests unless others object > (I think it improves things). But, if we are going to do so, > let's figure out text to be sure things are completely right. > In that context, it seems to me as if the suggested replacement > sentence needs an additional few words. Suggestions welcome. How about: Replace: Note that under this definition, it is not possible to tell from the address that an email sender or recipient is an i18mail user. with: Note that under this definition, it is not possible to tell from an ASCII address if an email sender or recipient is an i18mail user or not. (A non-ASCII address implies that the owner of that address is an i18mail user.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There is no human problem which could not be solved if people would simply do as I advise. -- Gore Vidal _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 17:40:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JS7-0001vZ-Np; Wed, 17 Jan 2007 17:40:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JS5-0001vJ-MC; Wed, 17 Jan 2007 17:40:17 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7JS4-0008AH-CW; Wed, 17 Jan 2007 17:40:17 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H7JS1-000EZl-UE; Wed, 17 Jan 2007 17:40:14 -0500 Date: Wed, 17 Jan 2007 17:40:12 -0500 From: John C Klensin To: Randall Gellens , Harald Alvestrand Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC Message-ID: <54B0385D19E6029AB26948EE@p3.JCK.COM> In-Reply-To: References: <45AE7C9B.6010100@alvestrand.no> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ietf@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 17 January, 2007 14:31 -0800 Randall Gellens wrote: > How about: > > Replace: > > Note that under this definition, it is not possible to > tell from > the address that an email sender or recipient is an > i18mail user. > > with: > > Note that under this definition, it is not possible to > tell from > an ASCII address if an email sender or recipient is an > i18mail > user or not. (A non-ASCII address implies that the > owner of > that address is an i18mail user.) Hmm. Because of my concern that some of the non-ASCII addresses we will see floating around will result from guessing, how about ... (A non-ASCII address implies a belief that the... if you can live with that, and no one else objects strenuously, I'll make the substitution. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 17:46:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JXy-00066m-Kw; Wed, 17 Jan 2007 17:46:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JXw-000659-Lw; Wed, 17 Jan 2007 17:46:20 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7JXv-0000TC-AY; Wed, 17 Jan 2007 17:46:20 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0HMkEst015185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2007 14:46:15 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0HMkClg026000; Wed, 17 Jan 2007 14:46:13 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <54B0385D19E6029AB26948EE@p3.JCK.COM> References: <45AE7C9B.6010100@alvestrand.no> <54B0385D19E6029AB26948EE@p3.JCK.COM> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 17 Jan 2007 14:46:10 -0800 To: John C Klensin , Harald Alvestrand From: Randall Gellens Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.6 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ietf@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 5:40 PM -0500 1/17/07, John C Klensin wrote: > Hmm. Because of my concern that some of the non-ASCII > addresses we will see floating around will result from guessing, > how about > > ... (A non-ASCII address implies a belief that the... > > if you can live with that, and no one else objects strenuously, > I'll make the substitution. Sounds good to me. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Newton's Fourth Law: Every action has an equal and opposite satisfaction. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 17:46:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JXx-00066Y-SS; Wed, 17 Jan 2007 17:46:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JXv-00061q-2n; Wed, 17 Jan 2007 17:46:19 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7JXt-0000Sz-Ng; Wed, 17 Jan 2007 17:46:19 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0HMkDfb015177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2007 14:46:14 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0HMkCle026000; Wed, 17 Jan 2007 14:46:12 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <45AE7C9B.6010100@alvestrand.no> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 17 Jan 2007 14:44:39 -0800 To: John C Klensin , Harald Alvestrand From: Randall Gellens Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.6 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ietf@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 4:02 PM -0500 1/17/07, John C Klensin wrote: > In any event, I'd recommend/request that you specify > text and where it should go. I'm thinking a brief mention in the Framework document, with more discussion in the SMTP extension document, and maybe a mention in the downgrade document. I'll suggest text for those documents later, but for the Frameworks document, immediately following the two bullets in Section 4.3, add a new paragraph: ----------------------- (The client can also try an alternate next-hop host or requeue the message and try later, on the assumption that the lack of UTF8SMTP is a transient failure; since this ultimately resolves to success or failure, it doesn't change the discussion here.) ----------------------- -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Seduced, shaggy Samson snored. She scissored short. Sorely shorn, Soon shackled slave, Samson sighed, Silently scheming, Sightlessly seeking Some savage, spectacular suicide. --Stanislaw Lem _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 19:54:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7LXf-0001En-NJ; Wed, 17 Jan 2007 19:54:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7LXd-0001Dx-HP for ima@ietf.org; Wed, 17 Jan 2007 19:54:09 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7LXZ-0001jK-LX for ima@ietf.org; Wed, 17 Jan 2007 19:54:09 -0500 Received: (snipe 2240 invoked by uid 0); 18 Jan 2007 09:56:13 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.023968 secs); Received: from unknown (HELO ?210.107.250.66?) (Z???own@210.107.250.66) by unknown with SMTP; 18 Jan 2007 09:56:13 +0900 X-SNIPER-SENDERIP: 210.107.250.66 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: randy@qualcomm.com, john-ietf@jck.com, harald@alvestrand.no, ietf@ietf.org, ima@ietf.org, yangwooko@gmail.com Message-ID: <45AEC525.9060707@icu.ac.kr> Date: Thu, 18 Jan 2007 09:53:57 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Randall Gellens Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC References: <45AE7C9B.6010100@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: John C Klensin , ietf@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Randall Gellens wrote: > > At 3:59 PM -0500 1/17/07, John C Klensin wrote: > >> --On Wednesday, 17 January, 2007 12:12 -0800 Randall Gellens >> wrote: >> >>>>> Does the second-to-last sentence refer to an ASCII address, >>>>> or any address? The wording implies any address, but if >>>>> an address is non-ASCII, surely that is a good sign that >>>>> the owner of that address is an i18mail user? >>>> Right. The situation that is being warned against is taking >>>> an ASCII address as a clear sign that the address owner is >>>> not an i18mail user. >>> >>> I'd like to see the text improved to make this more clear. As >>> a suggestion, replace: >>> >>> Note that under this definition, it is not possible to >>> tell from >>> the address that an email sender or recipient is an >>> i18mail user. >>> >>> with: >>> >>> Note that under this definition, it is not possible to >>> tell from >>> an ASCII address if an email sender or recipient is an >>> i18mail >>> user or not. >> >> Hmm. One still can't tell from a non-ASCII address that the >> recipient is an i18mail user or not, one can only tell that the >> sender thinks that user is. >> >> I'm happy to make the change Randy suggests unless others object >> (I think it improves things). But, if we are going to do so, >> let's figure out text to be sure things are completely right. >> In that context, it seems to me as if the suggested replacement >> sentence needs an additional few words. Suggestions welcome. > > How about: > > Replace: > > Note that under this definition, it is not possible to tell from > the address that an email sender or recipient is an i18mail user. > > with: > > Note that under this definition, it is not possible to tell from > an ASCII address if an email sender or recipient is an i18mail > user or not. (A non-ASCII address implies that the owner of > that address is an i18mail user.) Replaced text looks a lot better, I am a little bit concerned that the relation between "an ASCII address" and "an sender / recipient" is looser than I want it be. /* As a non-native, I feel always nervous when word-smithing */ Can we me make the relation clearer if we changed it a little bit? For instance; Note that under this definition, it is not possible to tell whether an email sender or recipient is an i18mail user or not if his/her address is an ASCII address. Regards _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 20:33:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7M9I-0007xb-Jw; Wed, 17 Jan 2007 20:33:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7M9G-0007wg-SR; Wed, 17 Jan 2007 20:33:02 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7M4M-0007PJ-7t; Wed, 17 Jan 2007 20:28:00 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0I1RpUY009492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2007 17:27:52 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0I1Rn7V011345; Wed, 17 Jan 2007 17:27:50 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <45AEC525.9060707@icu.ac.kr> References: <45AE7C9B.6010100@alvestrand.no> <45AEC525.9060707@icu.ac.kr> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 17 Jan 2007 17:23:56 -0800 To: Yangwoo Ko From: Randall Gellens Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.6 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: John C Klensin , ietf@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 9:53 AM +0900 1/18/07, Yangwoo Ko wrote: >> How about: >> >> Replace: >> >> Note that under this definition, it is not possible to tell from >> the address that an email sender or recipient is an i18mail user. >> >> with: >> >> Note that under this definition, it is not possible to tell from >> an ASCII address if an email sender or recipient is an i18mail >> user or not. (A non-ASCII address implies that the owner of >> that address is an i18mail user.) > > Replaced text looks a lot better, I am a little bit concerned that > the relation between "an ASCII address" and "an sender / recipient" > is looser than I want it be. /* As a non-native, I feel always > nervous when word-smithing */ > > Can we me make the relation clearer if we changed it a little bit? > For instance; > > Note that under this definition, it is not possible to tell > whether an email sender or recipient is an i18mail user or not > if his/her address is an ASCII address. How about: Note that under this definition, it is not possible to tell from an ASCII address if the owner of that address is an i18mail user or not. (A non-ASCII address implies a belief that the owner of that address is an i18mail user.) This incorporates John's change ("a belief") as well as your desire to tighten the link between the address and the owner. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There is so much to be said in favor of modern journalism. By giving us the opinions of the uneducated, it keeps us in touch with the ignorance of the community. --Oscar Wilde _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 20:46:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7MLu-00063Z-FH; Wed, 17 Jan 2007 20:46:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7MLt-00062x-7u for ima@ietf.org; Wed, 17 Jan 2007 20:46:05 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7MLr-0000lY-9f for ima@ietf.org; Wed, 17 Jan 2007 20:46:05 -0500 Received: (eyou send program); Thu, 18 Jan 2007 09:46:00 +0800 Message-ID: <369084760.29707@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Thu, 18 Jan 2007 09:46:00 +0800 Message-ID: <03d501c73aa2$6679a6b0$1206e29f@cnnicyao> From: "Yao Jiankang" To: "John C Klensin" , "Harald Alvestrand" , "Randall Gellens" References: <45AE7C9B.6010100@alvestrand.no> <369073998.21105@cnnic.cn> Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC Date: Thu, 18 Jan 2007 09:45:58 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ietf@ietf.org, ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0841741861==" Errors-To: ima-bounces@ietf.org --===============0841741861== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlJhbmRhbGwgR2VsbGVucyIg PHJhbmR5QHF1YWxjb21tLmNvbT4NClRvOiAiSm9obiBDIEtsZW5zaW4iIDxqb2huLWlldGZAamNr LmNvbT47ICJIYXJhbGQgQWx2ZXN0cmFuZCIgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPg0KQ2M6IDxp ZXRmQGlldGYub3JnPjsgPGltYUBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDE4 LCAyMDA3IDY6NDQgQU0NClN1YmplY3Q6IFJlOiBbRUFJXSBMYXN0IENhbGw6IGRyYWZ0LWlldGYt ZWFpLWZyYW1ld29yayAoT3ZlcnZpZXcgYW5kIEZyYW1ld29yayBmb3IgSW50ZXJuYXRpb25hbGl6 ZWQgRW1haWwpIHRvIEluZm9ybWF0aW9uYWwgUkZDDQoNCg0KPiBBdCA0OjAyIFBNIC0wNTAwIDEv MTcvMDcsIEpvaG4gQyBLbGVuc2luIHdyb3RlOg0KPiANCj4+ICBJbiBhbnkgZXZlbnQsIEknZCBy ZWNvbW1lbmQvcmVxdWVzdCB0aGF0IHlvdSBzcGVjaWZ5DQo+PiAgdGV4dCBhbmQgd2hlcmUgaXQg c2hvdWxkIGdvLg0KPiANCj4gSSdtIHRoaW5raW5nIGEgYnJpZWYgbWVudGlvbiBpbiB0aGUgRnJh bWV3b3JrIGRvY3VtZW50LCB3aXRoIG1vcmUgDQo+IGRpc2N1c3Npb24gaW4gdGhlIFNNVFAgZXh0 ZW5zaW9uIGRvY3VtZW50LCBhbmQgbWF5YmUgYSBtZW50aW9uIGluIHRoZSANCj4gZG93bmdyYWRl IGRvY3VtZW50LiAgSSdsbCBzdWdnZXN0IHRleHQgZm9yIHRob3NlIGRvY3VtZW50cyBsYXRlciwg YnV0IA0KPiBmb3IgdGhlIEZyYW1ld29ya3MgZG9jdW1lbnQsIGltbWVkaWF0ZWx5IGZvbGxvd2lu ZyB0aGUgdHdvIGJ1bGxldHMgaW4gDQo+IFNlY3Rpb24gNC4zLCBhZGQgYSBuZXcgcGFyYWdyYXBo Og0KDQoNCklmIG5vIG9uZSBlbHNlIG9iamVjdHMgaXQsICBJIHdpbGwgdXBkYXRlIGl0IGluIFNN VFBleHQgZG9jdW1lbnQgYWNjb3JkaW5nIHRvIHlvdXIgc3VnZ2VzdGlvbnMuDQoNClRoYW5rcy4N Cg0KWUFPIEppYW5rYW5nDQpDTk5JQw0KDQoNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IChUaGUgY2xpZW50IGNhbiBhbHNvIHRyeSBhbiBhbHRlcm5hdGUgbmV4dC1ob3AgaG9zdCBv ciByZXF1ZXVlIHRoZSANCj4gbWVzc2FnZSBhbmQgdHJ5IGxhdGVyLCBvbiB0aGUgYXNzdW1wdGlv biB0aGF0IHRoZSBsYWNrIG9mIFVURjhTTVRQIGlzIA0KPiBhIHRyYW5zaWVudCBmYWlsdXJlOyBz aW5jZSB0aGlzIHVsdGltYXRlbHkgcmVzb2x2ZXMgdG8gc3VjY2VzcyBvciANCj4gZmFpbHVyZSwg aXQgZG9lc24ndCBjaGFuZ2UgdGhlIGRpc2N1c3Npb24gaGVyZS4pDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IA0KPiANCj4gLS0gDQo+IFJhbmRhbGwgR2VsbGVucw0KPiBPcGluaW9ucyBh cmUgcGVyc29uYWw7ICAgIGZhY3RzIGFyZSBzdXNwZWN0OyAgICBJIHNwZWFrIGZvciBteXNlbGYg b25seQ0KPiAtLS0tLS0tLS0tLS0tLSBSYW5kb21seS1zZWxlY3RlZCB0YWc6IC0tLS0tLS0tLS0t LS0tLQ0KPiBTZWR1Y2VkLCBzaGFnZ3kgU2Ftc29uIHNub3JlZC4NCj4gU2hlIHNjaXNzb3JlZCBz aG9ydC4gIFNvcmVseSBzaG9ybiwNCj4gU29vbiBzaGFja2xlZCBzbGF2ZSwgU2Ftc29uIHNpZ2hl ZCwNCj4gU2lsZW50bHkgc2NoZW1pbmcsDQo+IFNpZ2h0bGVzc2x5IHNlZWtpbmcNCj4gU29tZSBz YXZhZ2UsIHNwZWN0YWN1bGFyIHN1aWNpZGUuDQo+ICAgICAgICAgICAgICAgICAtLVN0YW5pc2xh dyBMZW0NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IElldGYgbWFpbGluZyBsaXN0DQo+IElldGZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zg== --===============0841741861== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============0841741861==-- From ima-bounces@ietf.org Wed Jan 17 21:19:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7MsG-0001Ha-LJ; Wed, 17 Jan 2007 21:19:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7MsD-0001HI-Sh for ima@ietf.org; Wed, 17 Jan 2007 21:19:30 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7MsC-0004mv-Fn for ima@ietf.org; Wed, 17 Jan 2007 21:19:29 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0I2JQAa016510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Jan 2007 18:19:26 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0I2JO6H009543; Wed, 17 Jan 2007 18:19:25 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <458A154A.4090707@twnic.net.tw> References: <458A154A.4090707@twnic.net.tw> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 17 Jan 2007 18:14:20 -0800 To: Jeff Yeh , "ima@ietf.org" From: Randall Gellens Subject: Re: [EAI] Status of utf8header draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 1:02 PM +0800 12/21/06, Jeff Yeh wrote: > Hi all: > > While I'm trying to update the header draft, there comes some > issues (solved/un-solved). Listed below: > > * Removing the "Header-Type" header (was UTF8SMTP) > The basic idea to have a "Header-Type" new header is for > identifying a email is EAI or non-EAI. And the new header could > also carry some useful information like downgrade > information/language tag. However, this kind of self-labeling > mechanism was found useless as the history of "MIME-Version" > header. For the robustness of email software, programmers usually > ignore the "MIME-Version" header, directly check the presents of > MIME headers and the MIME encoded stuff. This is also happened in > TWNIC's implementation on EAI testbed, "Header-Type" header is > ignored, we check the presents of UTF8 instead. Thus, the demand of > the "Header-Type" is being raise up again. > Although we already have consensus about this point on San Diego > meeting, it's still necessary to bring on the mailing list for > everyone's opinion. > > --harald offers choices: > a) leave UTF8SMTP header field in:one vote > b) take it out: 10 votes > c) mime-version 2.0: none > d) can't decide: 5 votes > --harald: will take proposal to list to take it out > Defining the header introduces a silly state where the header doesn't match reality. (1) If the header says "ASCII" or isn't present, the message could still contain UTF8. (2) If the header says "UTF8" the message might be all ASCII. The effect of (1) would potentially be bad. The effect of (2) is either harmless, or in the worst case, results in a message being bounced that could have been delivered. Because of (1), receiving systems MUST NOT trust a a label of "Header-Type: ASCII". If a message is received that claims to be ASCII, or isn't labelled, the receiver still needs to examine the message for non-ASCII characters, as well as other conditions that make the message invalid. So, I'd be OK with leaving the header, provided we add text saying that a value of "ASCII" mustn't be trusted (and even with a value of "UTF8" the message should still be checked to be sure it is otherwise valid). > * The alt-addr syntax > There is a roughly consensus on >, but still some > concern on parser updating effort. By TWNIC's EAI implementation > experience, working just fine with a little bit > change on parser. Though there is a possible conflict to > domain-literal, but the use of domain-literal is quite few, I think. I'd prefer the embedded angle-brackets: ">". > > * Trace Field > Solved, will update in the upcoming version. > "Received" must put in ASCII, "for" could ignore (optional). > "Return-Path" syntax need to update to allow UTF8 characters. It would be a shame to throw away information containing in "for" (even though it is generally only used when a message has a single recipient, this is a very common case). Did we discuss something like "for8" that would contain an encoded version of the address? (Using one of the array of encodings, such as base64 or 2047.) -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- One should always be a little improbable. --Oscar Wilde _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 17 22:25:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7NtD-00039q-6X; Wed, 17 Jan 2007 22:24:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7NtB-00039k-9r for ima@ietf.org; Wed, 17 Jan 2007 22:24:33 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Nt9-0003h2-LZ for ima@ietf.org; Wed, 17 Jan 2007 22:24:33 -0500 Received: from [211.72.211.109] (pc109.twnic.net.tw [211.72.211.109]) (authenticated bits=0) by twnic.net.tw (8.13.8/8.13.8) with ESMTP id l0I3OQ6q009767; Thu, 18 Jan 2007 11:24:27 +0800 Message-ID: <45AEEB62.6010606@twnic.net.tw> Date: Thu, 18 Jan 2007 11:37:06 +0800 From: Jeff Yeh User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Randall Gellens Subject: Re: [EAI] Status of utf8header draft References: <458A154A.4090707@twnic.net.tw> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "ima@ietf.org" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Randall Gellens wrote: > Defining the header introduces a silly state where the header doesn't > match reality. > > (1) If the header says "ASCII" or isn't present, the message could > still contain UTF8. > > (2) If the header says "UTF8" the message might be all ASCII. > > The effect of (1) would potentially be bad. The effect of (2) is > either harmless, or in the worst case, results in a message being > bounced that could have been delivered. > > Because of (1), receiving systems MUST NOT trust a a label of > "Header-Type: ASCII". If a message is received that claims to be > ASCII, or isn't labelled, the receiver still needs to examine the > message for non-ASCII characters, as well as other conditions that > make the message invalid. > > So, I'd be OK with leaving the header, provided we add text saying > that a value of "ASCII" mustn't be trusted (and even with a value of > "UTF8" the message should still be checked to be sure it is otherwise > valid). I'm kind of agree to Randall. You have to scan over the headers for UTF8 anyway, no matter the "Header-Type: UTF8" exists or not. >> * Trace Field >> Solved, will update in the upcoming version. >> "Received" must put in ASCII, "for" could ignore (optional). >> "Return-Path" syntax need to update to allow UTF8 characters. > > It would be a shame to throw away information containing in "for" > (even though it is generally only used when a message has a single > recipient, this is a very common case). Did we discuss something like > "for8" that would contain an encoded version of the address? (Using > one of the array of encodings, such as base64 or 2047.) This idea is first introduced, I like it, it makes the whole solution more complete. However, if this is adopted, there will be another encoding (even it use 2047). I'm wandering this will make the solution more complicate. And also, lots of mail server implementation does not insert "for" on trace fields, since it is optional in 2822 definition. Jeff Yeh -TWNIC _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 18 02:45:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Rx4-0007Ak-Cg; Thu, 18 Jan 2007 02:44:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Rx1-00077z-3D for ima@ietf.org; Thu, 18 Jan 2007 02:44:47 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Rsq-0002uS-5O for ima@ietf.org; Thu, 18 Jan 2007 02:40:29 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 52BC42596E8; Thu, 18 Jan 2007 08:36:38 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06589-10; Thu, 18 Jan 2007 08:36:33 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 13D292596E6; Thu, 18 Jan 2007 08:36:33 +0100 (CET) Message-ID: <45AF2466.5040005@alvestrand.no> Date: Thu, 18 Jan 2007 08:40:22 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Jeff Yeh Subject: Re: [EAI] Status of utf8header draft References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> In-Reply-To: <45AEEB62.6010606@twnic.net.tw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Randall Gellens , "ima@ietf.org" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Jeff Yeh wrote: > > Randall Gellens wrote: >> Defining the header introduces a silly state where the header doesn't >> match reality. >> >> (1) If the header says "ASCII" or isn't present, the message could >> still contain UTF8. >> >> (2) If the header says "UTF8" the message might be all ASCII. >> >> The effect of (1) would potentially be bad. The effect of (2) is >> either harmless, or in the worst case, results in a message being >> bounced that could have been delivered. >> >> Because of (1), receiving systems MUST NOT trust a a label of >> "Header-Type: ASCII". If a message is received that claims to be >> ASCII, or isn't labelled, the receiver still needs to examine the >> message for non-ASCII characters, as well as other conditions that >> make the message invalid. >> >> So, I'd be OK with leaving the header, provided we add text saying >> that a value of "ASCII" mustn't be trusted (and even with a value of >> "UTF8" the message should still be checked to be sure it is otherwise >> valid). > I'm kind of agree to Randall. You have to scan over the headers for > UTF8 anyway, no matter the "Header-Type: UTF8" exists or not. I'm more happy with dropping it. Adding more header cruft that we know to be useless is a Bad Thing. >>> * Trace Field >>> Solved, will update in the upcoming version. >>> "Received" must put in ASCII, "for" could ignore (optional). >>> "Return-Path" syntax need to update to allow UTF8 characters. >> >> It would be a shame to throw away information containing in "for" >> (even though it is generally only used when a message has a single >> recipient, this is a very common case). Did we discuss something >> like "for8" that would contain an encoded version of the address? >> (Using one of the array of encodings, such as base64 or 2047.) > This idea is first introduced, I like it, it makes the whole solution > more complete. However, if this is adopted, there will be another > encoding (even it use 2047). I'm wandering this will make the solution > more complicate. And also, lots of mail server implementation does > not insert "for" on trace fields, since it is optional in 2822 > definition. The RFC 2822 Received: format isn't extensible. (for 2047-encoding) is a perfectly valid comment, but that's the only trouble-free way of preserving the information I see - we shouldn't (I think) try to mandate the content of comments, but might suggest it. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 18 10:28:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ZAq-0007JT-B5; Thu, 18 Jan 2007 10:27:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ZAo-0007Ib-KA for ima@ietf.org; Thu, 18 Jan 2007 10:27:30 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ZAi-000062-UZ for ima@ietf.org; Thu, 18 Jan 2007 10:27:30 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3&clerew#man#ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45af91d7.155d.477 for ima@ietf.org; Thu, 18 Jan 2007 15:27:19 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0IFRJw0025577 for ; Thu, 18 Jan 2007 15:27:20 GMT To: IMA Subject: Re: [EAI] Status of utf8header draft References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> Message-ID: Date: Thu, 18 Jan 2007 15:27:18 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <45AF2466.5040005@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 18 Jan 2007 07:40:22 -0000, Harald Alvestrand wrote: > Jeff Yeh wrote: >> >> Randall Gellens wrote: >>> Defining the header introduces a silly state where the header doesn't >>> match reality. >>> >>> (1) If the header says "ASCII" or isn't present, the message could >>> still contain UTF8. But whoever put the header there would be lying and deserves what he gets. One of the reasons for having this header is to relieve agents from the burden of having to check the whole document for 8bit stuff that, if that header says "ASCII", is 99.99% unlikely to be there. Note that you have to check the body as well, if it is a MIME message, because there might be internal headers that really ought to be checked as well. Much better to let "ASCII" be treated as ASCII, and if that causes the message to be munged/lost, then what's new? Garbage in - Garbage out. >>> >>> (2) If the header says "UTF8" the message might be all ASCII. A waste of resources, and hence to be discouraged, but no harm arises. >>> So, I'd be OK with leaving the header, provided we add text saying >>> that a value of "ASCII" mustn't be trusted (and even with a value of >>> "UTF8" the message should still be checked to be sure it is otherwise >>> valid). -1 -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 18 10:49:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ZW7-0007Lf-Hm; Thu, 18 Jan 2007 10:49:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ZW6-0007LZ-1A for ima@ietf.org; Thu, 18 Jan 2007 10:49:30 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ZW4-0004d3-Gd for ima@ietf.org; Thu, 18 Jan 2007 10:49:30 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H7ZW1-000Mnj-9r; Thu, 18 Jan 2007 10:49:25 -0500 Date: Thu, 18 Jan 2007 10:49:24 -0500 From: John C Klensin To: Charles Lindsey , IMA Message-ID: In-Reply-To: References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Subject: [EAI] The Header-Type header (was: Re: Status of utf8header draft) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 18 January, 2007 15:27 +0000 Charles Lindsey wrote: > On Thu, 18 Jan 2007 07:40:22 -0000, Harald Alvestrand > wrote: > >> Jeff Yeh wrote: >>> >>> Randall Gellens wrote: >>>> Defining the header introduces a silly state where the >>>> header doesn't match reality. >>>> >>>> (1) If the header says "ASCII" or isn't present, the >>>> message could still contain UTF8. > > But whoever put the header there would be lying and deserves > what he gets. If "he" would "get" the consequences of his lies, that would be fine. Unfortunately, he lies and the receiving user pays the penalty. > One of the reasons for having this header is to relieve agents > from the burden of having to check the whole document for 8bit > stuff that, if that header says "ASCII", is 99.99% unlikely to > be there. Note that you have to check the body as well, if it > is a MIME message, because there might be internal headers > that really ought to be checked as well. Yep. Because the robustness principle doesn't permit the receiver to assume that the sender followed the rules if doing so causes the receiver to exhibit severely bad behavior. Again, this isn't "sender pays the penalty for bad behavior" but "bad behavior by the sender inflicts pain on the recipient". The recipient system needs to check --and check whatever needs to be checked-- at least to the extent necessary to avoid consequent bad behavior. > Much better to let "ASCII" be treated as ASCII, and if that > causes the message to be munged/lost, then what's new? Garbage > in - Garbage out. Munged doesn't bother me very much, although message corruption without notice to the user is very bad news. Lost does. And having the receiving MUA get into unrecoverable trouble as the result of a badly-formatted incoming message is a terrible situation. Receiving MUAs have to protect themselves against attacks. If someone says "ASCII", the necessary protection will almost always require scanning the entire message (perhaps incrementally). In that context, the only thing that having the header permits will be the generation of a message that said "sender lied, message was supposed to be all-ASCII and wasn't". But common practice says that message won't be generated: 8bit-capable receiving systems will just make the corrections and go on because, if the corrections can be made, the user won't care what came in. >>>> (2) If the header says "UTF8" the message might be all >>>> ASCII. > > A waste of resources, and hence to be discouraged, but no harm > arises. But it is further evidence that the header is nearly useless. >>>> So, I'd be OK with leaving the header, provided we add text >>>> saying that a value of "ASCII" mustn't be trusted (and >>>> even with a value of "UTF8" the message should still be >>>> checked to be sure it is otherwise valid). Adding headers has a cost, sometimes a significant one. If we care about those headers getting through filters, institutional-boundary firewalls, the IMAP (and lemonade?) header abstraction, and so on, we have to persuade all sorts of folks to revise their implementations, data structures, and abstractions. If we don't care enough (and maybe even if we do), they every receiving implementation has to be prepared to deal with the no-header case because the header may have been trashed, making the value of the header even more marginal. I don't see that a persuasive case has been made that the header has enough value to justify that cost. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 18 15:03:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dTO-0003cn-Ns; Thu, 18 Jan 2007 15:02:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dTN-0003ci-Ti for ima@ietf.org; Thu, 18 Jan 2007 15:02:57 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7dTL-0004zC-GE for ima@ietf.org; Thu, 18 Jan 2007 15:02:57 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0IK2oYB029961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Jan 2007 12:02:50 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0IK2iAl007806; Thu, 18 Jan 2007 12:02:46 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <45AF2466.5040005@alvestrand.no> References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 18 Jan 2007 12:02:30 -0800 To: Harald Alvestrand , Jeff Yeh From: Randall Gellens Subject: Re: [EAI] Status of utf8header draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "ima@ietf.org" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 8:40 AM +0100 1/18/07, Harald Alvestrand wrote: > Jeff Yeh wrote: >> >> Randall Gellens wrote: >>> Defining the header introduces a silly state where the header >>> doesn't match reality. >>> >>> (1) If the header says "ASCII" or isn't present, the message >>> could still contain UTF8. >>> >>> (2) If the header says "UTF8" the message might be all ASCII. >>> >>> The effect of (1) would potentially be bad. The effect of (2) is >>> either harmless, or in the worst case, results in a message being >>> bounced that could have been delivered. >>> >>> Because of (1), receiving systems MUST NOT trust a a label of >>> "Header-Type: ASCII". If a message is received that claims to be >>> ASCII, or isn't labelled, the receiver still needs to examine the >>> message for non-ASCII characters, as well as other conditions >>> that make the message invalid. >>> >>> So, I'd be OK with leaving the header, provided we add text >>> saying that a value of "ASCII" mustn't be trusted (and even with >>> a value of "UTF8" the message should still be checked to be sure >>> it is otherwise valid). >> I'm kind of agree to Randall. You have to scan over the headers >> for UTF8 anyway, no matter the "Header-Type: UTF8" exists or not. > I'm more happy with dropping it. Adding more header cruft that we > know to be useless is a Bad Thing. I'm fine with dropping it, but there was an objection posted to the list stating that without this header, downgrade information is lost. If we want to keep it, we need to be clear what it means. >>>> * Trace Field >>>> Solved, will update in the upcoming version. >>>> "Received" must put in ASCII, "for" could ignore (optional). >>>> "Return-Path" syntax need to update to allow UTF8 characters. >>> >>> It would be a shame to throw away information containing in "for" >>> (even though it is generally only used when a message has a >>> single recipient, this is a very common case). Did we discuss >>> something like "for8" that would contain an encoded version of >>> the address? (Using one of the array of encodings, such as base64 >>> or 2047.) >> This idea is first introduced, I like it, it makes the whole >> solution more complete. However, if this is adopted, there will be >> another encoding (even it use 2047). I'm wandering this will make >> the solution more complicate. And also, lots of mail server >> implementation does not insert "for" on trace fields, since it is >> optional in 2822 definition. > The RFC 2822 Received: format isn't extensible. (for 2047-encoding) > is a perfectly valid comment, but that's the only trouble-free way > of preserving the information I see - we shouldn't (I think) try to > mandate the content of comments, but might suggest it. RFC 2822 defers to 2821 for the format. 2821 doesn't include an extension mechanism for new arbitrary fields, but presumably one could be added by a document which extended 2821. I'm not sure that would be justified in this case, though. The "protocol" field is extensible per 2821, but we already have a problem with an explosion of new protocol atoms defined for combinations of SMTP extensions. It would be good to define a structured "protocol" value that could indicate which relevant SMTP extensions were negotiated. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- We like because, we love although. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 18 20:38:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ihY-0002BR-3b; Thu, 18 Jan 2007 20:37:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ihW-0002BL-Pq for ima@ietf.org; Thu, 18 Jan 2007 20:37:54 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ihV-000230-G1 for ima@ietf.org; Thu, 18 Jan 2007 20:37:54 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H7ifU-00042D-3s for ima@ietf.org; Fri, 19 Jan 2007 02:35:48 +0100 Received: from 212.82.251.44 ([212.82.251.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 02:35:48 +0100 Received: from nobody by 212.82.251.44 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 02:35:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Last Call: draft-ietf-eai-framework (Overview and Framework for Internationalized Email) to Informational RFC Date: Fri, 19 Jan 2007 02:34:37 +0100 Organization: Lines: 33 Message-ID: <45B0202D.316@xyzzy.claranet.de> References: <45AE7C9B.6010100@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.44 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 2.2 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Randall Gellens wrote: [TempError] >> I haven't seen that possibility raised. I'm somewhat skeptical that >> it would be an improvement (it makes the delay before error >> reporting variable), but it's worth a discussion. WG? > If it is a temporary failure, and the message is sent successfully > after retrying, then it was a good thing to do. If there is always > an ASCII-only SMTP server in the path, then retrying only adds delay > to the failure. So: is it advisable for a system to be optimistic > that the message will be able to be sent? I think so, as the > document says: > the fact that the selection of submission servers are > presumably under the control of the sender's client and the selection > of potential intermediate relays is under the control of the > administration of the final delivery server. I'd think that a mixed setup - some routes work with UTF8SMTP as is, others don't - is a bug that has to be fixed manually. And "manual intervention needed" is more like PermError than TempError. > In any event, I think this is a quality-of-implementation thing: it > should be suggested by the documents but certainly not required for > compliance. Yes. Normally I'd prefer a consistent behaviour, but in that case it's impossible, getting the "wrong" route is an intermittent issue, some non-UTF8SMTP secondary MX or similar. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 18 20:55:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7iyp-0008KA-BS; Thu, 18 Jan 2007 20:55:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7iyo-0008K5-4V for ima@ietf.org; Thu, 18 Jan 2007 20:55:46 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7iyl-0004RO-RP for ima@ietf.org; Thu, 18 Jan 2007 20:55:46 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H7iyS-00070W-20 for ima@ietf.org; Fri, 19 Jan 2007 02:55:24 +0100 Received: from 212.82.251.44 ([212.82.251.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 02:55:24 +0100 Received: from nobody by 212.82.251.44 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 02:55:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: for8 (was: [EAI] Status of utf8header draft) Date: Fri, 19 Jan 2007 02:53:09 +0100 Organization: Lines: 20 Message-ID: <45B02485.296F@xyzzy.claranet.de> References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.44 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Jeff Yeh wrote: > I'm kind of agree to Randall. You have to scan over the headers > for UTF8 anyway, no matter the "Header-Type: UTF8" exists or not. As long as the deduced result is NOT message/rfc822 for raw UTF-8 header fields I also feel safe without a Header-Type: header field. But we still need an explicit "downgraded" indicator, or don't we ? >> Did we discuss something like "for8" that would contain an >> encoded version of the address? (Using one of the array of >> encodings, such as base64 or 2047.) > This idea is first introduced, I like it +1 Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 18 21:28:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7jUH-00058D-P0; Thu, 18 Jan 2007 21:28:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7jUH-00056g-Er for ima@ietf.org; Thu, 18 Jan 2007 21:28:17 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7jUF-0000YS-5a for ima@ietf.org; Thu, 18 Jan 2007 21:28:17 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H7jU7-0002Fv-SV for ima@ietf.org; Fri, 19 Jan 2007 03:28:07 +0100 Received: from 212.82.251.44 ([212.82.251.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 03:28:07 +0100 Received: from nobody by 212.82.251.44 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 03:28:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: for8 (was: [EAI] Status of utf8header draft) Date: Fri, 19 Jan 2007 03:27:34 +0100 Organization: Lines: 16 Message-ID: <45B02C96.70EC@xyzzy.claranet.de> References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.44 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Randall Gellens wrote: > 2821 doesn't include an extension mechanism for new arbitrary > fields, but presumably one could be added by a document which > extended 2821. There's an IANA registry for VIA and WITH types, but nothing about new clauses, tough. If UTF8SMTP updates the 821-syntax for the -clause would inherit this updated syntax. And smtpext-02 in fact updates (or rather its 2821 counterpart), what am I missing here ? Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 18 22:12:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7kAj-0005YQ-7h; Thu, 18 Jan 2007 22:12:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7kAi-0005VM-Ev for ima@ietf.org; Thu, 18 Jan 2007 22:12:08 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7kAh-0000Nl-4Z for ima@ietf.org; Thu, 18 Jan 2007 22:12:08 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H7kAg-00015S-DA; Thu, 18 Jan 2007 22:12:06 -0500 Date: Thu, 18 Jan 2007 22:12:05 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: for8 (was: [EAI] Status of utf8header draft) Message-ID: <508873A35B1352D6B909CA0C@p3.JCK.COM> In-Reply-To: <45B02C96.70EC@xyzzy.claranet.de> References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <45B02C96.70EC@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 19 January, 2007 03:27 +0100 Frank Ellermann wrote: > Randall Gellens wrote: > >> 2821 doesn't include an extension mechanism for new arbitrary >> fields, but presumably one could be added by a document which >> extended 2821. > > There's an IANA registry for VIA and WITH types, but nothing > about new clauses, tough. That was, if I recall, discussed and decided against during the DRUMS process. Part of the problem (but only part) is that the four Opt-info components use keywords that are really delimiters. Had it been defined, long ago, so that Opt-info = ["," Via] ["," With] ["," ID] ["," For] but it wasn't, and adding extra fields would risk rather seriously fouling up existing conforming implementations. > If UTF8SMTP updates the > 821-syntax for the -clause would inherit this > updated syntax. As long as, and only as long as, the message was being past to something that had accepted the use of the extended syntax via the SMTPEXT option. > And smtpext-02 in fact updates (or rather its 2821 > counterpart), what am I missing here ? Legacy implementations of 2821. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 19 02:52:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7oXc-0006cc-MU; Fri, 19 Jan 2007 02:52:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7oXa-0006b2-Ij for ima@ietf.org; Fri, 19 Jan 2007 02:52:02 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7oXX-0007lj-7h for ima@ietf.org; Fri, 19 Jan 2007 02:52:02 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 91A5E2596D9; Fri, 19 Jan 2007 08:48:08 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12955-09; Fri, 19 Jan 2007 08:48:03 +0100 (CET) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 813B12596CB; Fri, 19 Jan 2007 08:48:03 +0100 (CET) Message-ID: <45B07899.2010407@alvestrand.no> Date: Fri, 19 Jan 2007 08:51:53 +0100 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Frank Ellermann References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <45B02C96.70EC@xyzzy.claranet.de> In-Reply-To: <45B02C96.70EC@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ima@ietf.org Subject: [EAI] Re: for8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann wrote: > Randall Gellens wrote: > > >> 2821 doesn't include an extension mechanism for new arbitrary >> fields, but presumably one could be added by a document which >> extended 2821. >> > > There's an IANA registry for VIA and WITH types, but nothing > about new clauses, tough. If UTF8SMTP updates the > 821-syntax for the -clause would inherit this > updated syntax. > > And smtpext-02 in fact updates (or rather its 2821 > counterpart), what am I missing here ? The fact that downgraded UTF8SMTP messages will expect to be RFC2822 (no extensions) compatible. And the fact that altering trace headers is considered a Very Bad Thing. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 19 09:28:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ujY-0000QX-L3; Fri, 19 Jan 2007 09:28:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ujY-0000QR-0f for ima@ietf.org; Fri, 19 Jan 2007 09:28:48 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ujT-0000Gr-CD for ima@ietf.org; Fri, 19 Jan 2007 09:28:47 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3&clerew$man^ac*uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45b0d596.1828b.a0 for ima@ietf.org; Fri, 19 Jan 2007 14:28:38 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0JESZ7D007227 for ; Fri, 19 Jan 2007 14:28:36 GMT Date: Fri, 19 Jan 2007 14:28:33 -0000 To: IMA Subject: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft) References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 18 Jan 2007 15:49:24 -0000, John C Klensin wrote: > --On Thursday, 18 January, 2007 15:27 +0000 Charles Lindsey > wrote: >> One of the reasons for having this header is to relieve agents >> from the burden of having to check the whole document for 8bit >> stuff that, if that header says "ASCII", is 99.99% unlikely to >> be there. Note that you have to check the body as well, if it >> is a MIME message, because there might be internal headers >> that really ought to be checked as well. > > Yep. Because the robustness principle doesn't permit the > receiver to assume that the sender followed the rules if doing > so causes the receiver to exhibit severely bad behavior. ... Well robustness is a fine thing, but if it comes at a price you have to decide whether the benefit is worth the price. Let us look at a comparable example - 8BITMIME. Suppose some message announces Content-Transfer-Encoding: 7bit, and then proceeds to include 8bit stuff further down. Or suppose it omits the 8BITMIME parameter in the MAIL FROM command and nevertheless sends 8bit stuff. Is current practice for agents that support 8BITMIME to check through the whole body looking for 8bit stuff before passing the message on to an agent which does not support 8BITMIME? That would be robust, but I doubt current agents go to that trouble. But if 8BITMIME agents DO go to that trouble, then I accept your point. But if not, then how do you justify such a check in this case? >> Much better to let "ASCII" be treated as ASCII, and if that >> causes the message to be munged/lost, then what's new? Garbage >> in - Garbage out. > > Munged doesn't bother me very much, although message corruption > without notice to the user is very bad news. Lost does. Actually, I think complete loss is less likely than munging, since an MTA is likely to reject if it is not given a RCPT TO that looks like something it knows where to send to. Unless it is storage agents (IMAP/POP3) that canot tell where to put it just by looking at the To header. >> A waste of resources, and hence to be discouraged, but no harm >> arises. > > But it is further evidence that the header is nearly useless. No worse that writing Content-Transfer-Encoding: 8bit when 7bit would have done. But this header was never intended to guide MTAs in how to process messages, since our smtpext has got that well covered. I wrote on 21st December giving 7 reasons why this header was needed, and they were all related to situations where the transprt mechanism was not smtp, or where the message was being processed after it has left the smtp enviroment (and hence the envelope information was no longer available). If you believe this head is useless, then please reply, point by point, to that message. > >>>>> So, I'd be OK with leaving the header, provided we add text >>>>> saying that a value of "ASCII" mustn't be trusted (and >>>>> even with a value of "UTF8" the message should still be >>>>> checked to be sure it is otherwise valid). > > Adding headers has a cost, sometimes a significant one. If we > care about those headers getting through filters, > institutional-boundary firewalls, the IMAP (and lemonade?) > header abstraction, and so on, we have to persuade all sorts of > folks to revise their implementations, data structures, and > abstractions. If the message is beiong processed by UTF8SMTP-upgraded agents, then we can assume that they will be aware of this header, and will either make use of it, or at least ensure it is passed on to other agents that process the message. It is only when the message passes into a non-UTF8SMTP environment that this header might get lost, but at that point the message is supposed to be ASCII-safe anyway and that header will certainly not say "UTF8", so the opnly real loss is that some "downgraded" may get lost, and that may be a nuisamce but is not a show stopper. > If we don't care enough (and maybe even if we > do), they every receiving implementation has to be prepared to > deal with the no-header case because the header may have been > trashed, making the value of the header even more marginal. But if it has been trashed, then the message has already been downgraded, so it does not matter. The use of the header is in environments which DO understand it, and have to decide whether further processing of it (e.g. forwarding it to some alias) has to be done in a UTF8-safe manner. Remember that even UTF8SMTP-capable agents will still have a lot of pure ASCII messages to handle as well. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 19 10:42:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vtD-0005N9-5L; Fri, 19 Jan 2007 10:42:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7vtB-0005N4-5B for ima@ietf.org; Fri, 19 Jan 2007 10:42:49 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7vt9-000252-St for ima@ietf.org; Fri, 19 Jan 2007 10:42:49 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H7vt9-00068j-Ed; Fri, 19 Jan 2007 10:42:47 -0500 Date: Fri, 19 Jan 2007 10:42:46 -0500 From: John C Klensin To: ima@ietf.org, idna-update@alvestrand.no Message-ID: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [EAI] ASCII escapes for Unicode characters X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hi. At the Apps Area meeting at the last IETF, there was a discussion of ways of referring to or escaping a Unicode character in an ASCII protocol or context. I took an action to write a short I-D that explicitly recommended the use of form that reference Unicode code points directly rather than, e.g., encoding the octets of UTF-8. Because people on these two lists are deeply involved with internationalization issues, it seemed desirable to call your attention to this draft. Those on the EAI list should also note its small interaction with the DSN draft. The document has been posted as draft-klensin-unicode-escapes-00.txt. With the concurrence of the ADs, discussion has been directed to the discuss@apps.ietf.org list. If you have comments, please direct them to that list and _not_ to either of these two lists. thanks, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 19 15:11:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H805U-0002Jc-Da; Fri, 19 Jan 2007 15:11:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H805S-0002Hp-Ek for ima@ietf.org; Fri, 19 Jan 2007 15:11:46 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H804F-00082V-13 for ima@ietf.org; Fri, 19 Jan 2007 15:10:32 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1H803m-0001cc-8A for ima@ietf.org; Fri, 19 Jan 2007 21:10:02 +0100 Received: from du-001-148.access.de.clara.net ([212.82.227.148]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 21:10:02 +0100 Received: from nobody by du-001-148.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 21:10:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 19 Jan 2007 21:06:58 +0100 Organization: Lines: 16 Message-ID: <45B124E2.2F16@xyzzy.claranet.de> References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <45B02C96.70EC@xyzzy.claranet.de> <508873A35B1352D6B909CA0C@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-148.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [EAI] Re: for8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > the four Opt-info components use keywords that are really > delimiters Yes, we better don't touch this set. >> what am I missing here ? > Legacy implementations of 2821. That could be reduced to a relatively simple MUST in the downgrading instructions. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 19 15:12:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H805j-0002SD-0a; Fri, 19 Jan 2007 15:12:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H805U-0002Hp-Ao for ima@ietf.org; Fri, 19 Jan 2007 15:11:48 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8026-0007gk-Ao for ima@ietf.org; Fri, 19 Jan 2007 15:08:21 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H801Z-00016E-Ak for ima@ietf.org; Fri, 19 Jan 2007 21:07:45 +0100 Received: from du-001-148.access.de.clara.net ([212.82.227.148]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 21:07:45 +0100 Received: from nobody by du-001-148.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Jan 2007 21:07:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 19 Jan 2007 21:00:37 +0100 Organization: Lines: 25 Message-ID: <45B12365.2847@xyzzy.claranet.de> References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <45B02C96.70EC@xyzzy.claranet.de> <45B07899.2010407@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-148.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [EAI] Re: for8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Alvestrand wrote: [ inherits ] >> And smtpext-02 in fact updates (or rather its 2821 >> counterpart), what am I missing here ? > The fact that downgraded UTF8SMTP messages will expect to be > RFC2822 (no extensions) compatible. That limits the "for8" problem to removing the optional clause in the downgrade procedure. > And the fact that altering trace headers is considered a > Very Bad Thing. Forbidding everywhere in UTF8SMTP is also very bad. One of the UTF8SMTP axioms is that downgrading will rarely happen. I've my doubts about this axiom. But if we use it for some decisions we can as well use it consistently whenever it helps: "remove the optional if necessary" is no rocket science. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 19 20:18:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H84sT-0008QG-05; Fri, 19 Jan 2007 20:18:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H84sR-0008QB-Fy for ima@ietf.org; Fri, 19 Jan 2007 20:18:39 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H84sP-0004Qy-DR for ima@ietf.org; Fri, 19 Jan 2007 20:18:38 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H84sF-0009iU-HS; Fri, 19 Jan 2007 20:18:27 -0500 Date: Fri, 19 Jan 2007 20:18:24 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: for8 Message-ID: <566E2A7DE35A00124B3805FD@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 19 January, 2007 21:00 +0100 Frank Ellermann wrote: > Harald Alvestrand wrote: > > [ inherits ] >>> And smtpext-02 in fact updates (or rather its 2821 >>> counterpart), what am I missing here ? > >> The fact that downgraded UTF8SMTP messages will expect to be >> RFC2822 (no extensions) compatible. > > That limits the "for8" problem to removing the optional > clause in the downgrade procedure. But, as Harald mentions, we've got a fairly firm rule against a given server tampering with trace fields inserted by other servers. That rule is based on long and hard experience. One could declare this to be the exception and go back and remove earlier "for" fields, but, speaking personally, I'm not convinced that the value of the "for" field and the importance of this case are sufficient to justify breaking that rule. It also introduces the requirement that systems be able to parse earlier trace fields, which we have never before required. There is actually a reason for that -- while trace fields inserted by SMTP servers have a predictable format and syntax, it is not possible to know much about fields inserted by gateways and it is even less feasible to be able to predict the exact format of trace fields inserted before a message crosses the gateway. Again, we could make a whole series of assumptions and the depart from those rules, but it is both harder and riskier than it might appear on first glance. >> And the fact that altering trace headers is considered a >> Very Bad Thing. > > Forbidding everywhere in UTF8SMTP is also very bad. One > of the UTF8SMTP axioms is that downgrading will rarely happen. > > I've my doubts about this axiom. But if we use it for some > decisions we can as well use it consistently whenever it helps: > "remove the optional if necessary" is no rocket science. Actually, given all of the gateway constraints, it might require magic, which is often much harder than rocket science. See above. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 19 22:15:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H86hP-0002vS-Ge; Fri, 19 Jan 2007 22:15:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H86hN-0002tP-KC for ima@ietf.org; Fri, 19 Jan 2007 22:15:21 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H86hM-0003SD-B5 for ima@ietf.org; Fri, 19 Jan 2007 22:15:21 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H86hE-0000k0-GX for ima@ietf.org; Sat, 20 Jan 2007 04:15:12 +0100 Received: from du-001-147.access.de.clara.net ([212.82.227.147]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 20 Jan 2007 04:15:12 +0100 Received: from nobody by du-001-147.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 20 Jan 2007 04:15:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 20 Jan 2007 04:13:44 +0100 Organization: Lines: 19 Message-ID: <45B188E8.1496@xyzzy.claranet.de> References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-147.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [EAI] Re: for8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > as Harald mentions, we've got a fairly firm rule against a > given server tampering with trace fields inserted by other > servers. That rule is based on long and hard experience. A downgrading MTA is expected to parse the complete header for its job, stripping offending clauses while it's at it would be a rather simple part of this task. > It also introduces the requirement that systems be able to > parse earlier trace fields, which we have never before required. I understand your reasons, but downgrading MTAs are forced to parse the complete header anyway when they try to create an ASCII message/rfc822 surrogate of the message/utf8smtp header. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jan 21 01:14:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Vxg-00073K-4z; Sun, 21 Jan 2007 01:13:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8Vxe-000739-Ep for ima@ietf.org; Sun, 21 Jan 2007 01:13:50 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8Vxc-0008H6-VY for ima@ietf.org; Sun, 21 Jan 2007 01:13:50 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H8VxT-0004D5-U0 for ima@ietf.org; Sun, 21 Jan 2007 07:13:39 +0100 Received: from 212.82.251.18 ([212.82.251.18]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Jan 2007 07:13:39 +0100 Received: from nobody by 212.82.251.18 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Jan 2007 07:13:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ASCII escapes for Unicode characters Date: Sun, 21 Jan 2007 06:50:36 +0100 Organization: Lines: 17 Message-ID: <45B2FF2C.51E9@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.18 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@lists.ietf.org, cosmogol@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: [http://tools.ietf.org/html/draft-klensin-unicode-escapes] > With the concurrence of the ADs, discussion has been directed > to the discuss@apps.ietf.org list. If you have comments, > please direct them to that list and _not_ to either of these > two lists. Please propose an _unmoderated_ list for the discussion of this draft. The topic is also interesting for COSMOGOL because it was recently discussed there, for LTRU because we intentionally picked the 􂍅 style there, and maybe it's also relevant for I-D.phillips-record-jar Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jan 21 01:35:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8WIF-0007cC-6d; Sun, 21 Jan 2007 01:35:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8WIE-0007c7-6N for ima@ietf.org; Sun, 21 Jan 2007 01:35:06 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8WIC-0002JU-Qg for ima@ietf.org; Sun, 21 Jan 2007 01:35:06 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1H8WI9-0005ud-QL for ima@ietf.org; Sun, 21 Jan 2007 07:35:01 +0100 Received: from 212.82.251.18 ([212.82.251.18]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Jan 2007 07:35:01 +0100 Received: from nobody by 212.82.251.18 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 21 Jan 2007 07:35:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] ASCII escapes for Unicode characters Date: Sun, 21 Jan 2007 06:50:36 +0100 Organization: Lines: 17 Message-ID: <45B2FF2C.51E9@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.18 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@lists.ietf.org, cosmogol@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: [http://tools.ietf.org/html/draft-klensin-unicode-escapes] > With the concurrence of the ADs, discussion has been directed > to the discuss@apps.ietf.org list. If you have comments, > please direct them to that list and _not_ to either of these > two lists. Please propose an _unmoderated_ list for the discussion of this draft. The topic is also interesting for COSMOGOL because it was recently discussed there, for LTRU because we intentionally picked the 􂍅 style there, and maybe it's also relevant for I-D.phillips-record-jar Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 22 15:42:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H95zs-00043O-JI; Mon, 22 Jan 2007 15:42:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H95zr-00041g-2r for ima@ietf.org; Mon, 22 Jan 2007 15:42:31 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H95zp-0006D9-Nj for ima@ietf.org; Mon, 22 Jan 2007 15:42:31 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0MKgRTV009555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Jan 2007 12:42:28 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0MKgPVH016330; Mon, 22 Jan 2007 12:42:26 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <566E2A7DE35A00124B3805FD@p3.JCK.COM> References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Mon, 22 Jan 2007 12:41:36 -0800 To: John C Klensin , Frank Ellermann , ima@ietf.org From: Randall Gellens Subject: Re: [EAI] Re: for8 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 8:18 PM -0500 1/19/07, John C Klensin wrote: > But, as Harald mentions, we've got a fairly firm rule against a > given server tampering with trace fields inserted by other > servers. That rule is based on long and hard experience. One > could declare this to be the exception and go back and remove > earlier "for" fields, but, speaking personally, I'm not > convinced that the value of the "for" field and the importance > of this case are sufficient to justify breaking that rule. It seems we have two unpleasant choices: 1: Prohibit "for" clauses when the address is non-ASCII. 2: Alter trace headers when downgrading. The basic direction of the group, as I understand it, assumes that mail systems will fairly rapidly be upgraded to handle UTF8, and tries to avoid creating short-term kludges which will inevitably live on long after everyone has upgraded. We may be better off with choice 2. Choice 1 means that as systems are upgraded, "for" clauses vanish. I've found these clauses to be very helpful when debugging things. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Democracy is a form of government that substitutes election by the incompetent many for appointment by the corrupt few. --G. B. Shaw _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 22 15:50:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H967v-0007iS-7p; Mon, 22 Jan 2007 15:50:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H967d-0007YF-Li; Mon, 22 Jan 2007 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H967d-0000Cb-4F; Mon, 22 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 95B1A2ACB3; Mon, 22 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H9678-00082c-AG; Mon, 22 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 22 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-mailinglist-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Mailing Lists and Internationalized Email Addresses Author(s) : R. Gellens, E. Chung Filename : draft-ietf-eai-mailinglist-01.txt Pages : 10 Date : 2007-1-22 This document describes considerations for mailing lists with the introduction of internationalized email addressing capabilities. Different scenarios involving interaction between mailing lists and internationalized email addresses are examined. Furthermore, mailing list header fields are discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-mailinglist-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-mailinglist-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-mailinglist-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-22142732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-mailinglist-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-mailinglist-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-22142732.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Mon Jan 22 20:08:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9A9E-0005XU-97; Mon, 22 Jan 2007 20:08:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9A9C-0005XI-GG for ima@ietf.org; Mon, 22 Jan 2007 20:08:26 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9A9A-0006wF-1s for ima@ietf.org; Mon, 22 Jan 2007 20:08:26 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H9A8m-0009TC-FQ; Mon, 22 Jan 2007 20:08:00 -0500 Date: Mon, 22 Jan 2007 20:07:59 -0500 From: John C Klensin To: Randall Gellens , Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: for8 Message-ID: In-Reply-To: References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 22 January, 2007 12:41 -0800 Randall Gellens wrote: > At 8:18 PM -0500 1/19/07, John C Klensin wrote: > >> But, as Harald mentions, we've got a fairly firm rule >> against a given server tampering with trace fields inserted >> by other servers. That rule is based on long and hard >> experience. One could declare this to be the exception and >> go back and remove earlier "for" fields, but, speaking >> personally, I'm not convinced that the value of the "for" >> field and the importance of this case are sufficient to >> justify breaking that rule. > > It seems we have two unpleasant choices: > > 1: Prohibit "for" clauses when the address is non-ASCII. > 2: Alter trace headers when downgrading. Yes, I think that summarizes the problem. > The basic direction of the group, as I understand it, assumes > that mail systems will fairly rapidly be upgraded to handle > UTF8, and tries to avoid creating short-term kludges which > will inevitably live on long after everyone has upgraded. > > We may be better off with choice 2. Choice 1 means that as > systems are upgraded, "for" clauses vanish. I've found these > clauses to be very helpful when debugging things. Yes, although less useful than they were before security issues and the text of 2821 discouraged using them except under very restricted conditions. That conclusion makes me very, very nervous --as does every step we take that moves downgrading closer to requiring the category of activities that 2821 permits only for gateways-- but I can live with it if that is the group's decision. Since I am working on the I-D for 2821bis concurrently with the EAI effort --and with a target date of getting 2821bis-01 posted really soon now-- if there is text there that I need to fine-tune, suggestions would be welcome. Even then, the concerns that drive the nervousness suggest that, if we are going to alter earlier trace fields on downgrading, (i) It might be better to just drop "for" clauses that contain non-ASCII material rather than figure out some creative way to encode them.... possibly replacing them with a comment whose semantics are closer to "non-ASCII for clause dropped on downgrading" than to an attempted encoding of the prior address. (ii) we might want to require the MTA that does the downgrading to insert a very specific trace header that explains the damage it did. Any comments that contain encodings of prior addresses should probably be on that trace header, not retrofitted into headers that did not contain information in that form. Or maybe not... it could be that I'm unhappy enough about this to not be thinking clearly enough. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 22 22:06:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9BzT-0000Ec-8H; Mon, 22 Jan 2007 22:06:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9BzR-0000ER-B8 for ima@ietf.org; Mon, 22 Jan 2007 22:06:29 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9BzP-00051X-6k for ima@ietf.org; Mon, 22 Jan 2007 22:06:29 -0500 Received: (eyou send program); Tue, 23 Jan 2007 11:06:17 +0800 Message-ID: <369521577.20632@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Tue, 23 Jan 2007 11:06:17 +0800 Message-ID: <0eb801c73e9b$72a334e0$1206e29f@cnnicyao> From: "Yao Jiankang" To: "John C Klensin" , "Randall Gellens" , "Frank Ellermann" , References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <369514556.17665@cnnic.cn> Subject: Re: [EAI] Re: for8 Date: Tue, 23 Jan 2007 11:06:16 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0336765454==" Errors-To: ima-bounces@ietf.org --===============0336765454== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvaG4gQyBLbGVuc2luIiA8 a2xlbnNpbkBqY2suY29tPg0KVG86ICJSYW5kYWxsIEdlbGxlbnMiIDxyYW5keUBxdWFsY29tbS5j b20+OyAiRnJhbmsgRWxsZXJtYW5uIiA8bm9ib2R5QHh5enp5LmNsYXJhbmV0LmRlPjsgPGltYUBp ZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjMsIDIwMDcgOTowNyBBTQ0KU3ViamVj dDogUmU6IFtFQUldIFJlOiBmb3I4DQoNCg0KPiANCj4gDQo+IC0tT24gTW9uZGF5LCAyMiBKYW51 YXJ5LCAyMDA3IDEyOjQxIC0wODAwIFJhbmRhbGwgR2VsbGVucw0KPiA8cmFuZHlAcXVhbGNvbW0u Y29tPiB3cm90ZToNCj4gDQo+PiBBdCA4OjE4IFBNIC0wNTAwIDEvMTkvMDcsIEpvaG4gQyBLbGVu c2luIHdyb3RlOg0KPj4gDQo+Pj4gIEJ1dCwgYXMgSGFyYWxkIG1lbnRpb25zLCB3ZSd2ZSBnb3Qg YSBmYWlybHkgZmlybSBydWxlDQo+Pj4gIGFnYWluc3QgYSBnaXZlbiBzZXJ2ZXIgdGFtcGVyaW5n IHdpdGggdHJhY2UgZmllbGRzIGluc2VydGVkDQo+Pj4gIGJ5IG90aGVyIHNlcnZlcnMuICBUaGF0 IHJ1bGUgaXMgYmFzZWQgb24gbG9uZyBhbmQgaGFyZA0KPj4+ICBleHBlcmllbmNlLiAgT25lIGNv dWxkIGRlY2xhcmUgdGhpcyB0byBiZSB0aGUgZXhjZXB0aW9uIGFuZA0KPj4+ICBnbyBiYWNrIGFu ZCByZW1vdmUgZWFybGllciAiZm9yIiBmaWVsZHMsIGJ1dCwgc3BlYWtpbmcNCj4+PiAgcGVyc29u YWxseSwgSSdtIG5vdCBjb252aW5jZWQgdGhhdCB0aGUgdmFsdWUgb2YgdGhlICJmb3IiDQo+Pj4g IGZpZWxkIGFuZCB0aGUgaW1wb3J0YW5jZSBvZiB0aGlzIGNhc2UgYXJlIHN1ZmZpY2llbnQgdG8N Cj4+PiAganVzdGlmeSBicmVha2luZyB0aGF0IHJ1bGUuDQo+PiANCj4+IEl0IHNlZW1zIHdlIGhh dmUgdHdvIHVucGxlYXNhbnQgY2hvaWNlczoNCj4+IA0KPj4gMTogUHJvaGliaXQgImZvciIgY2xh dXNlcyB3aGVuIHRoZSBhZGRyZXNzIGlzIG5vbi1BU0NJSS4NCj4+IDI6IEFsdGVyIHRyYWNlIGhl YWRlcnMgd2hlbiBkb3duZ3JhZGluZy4NCj4gDQo+IFllcywgSSB0aGluayB0aGF0IHN1bW1hcml6 ZXMgdGhlIHByb2JsZW0uDQo+IA0KPj4gVGhlIGJhc2ljIGRpcmVjdGlvbiBvZiB0aGUgZ3JvdXAs IGFzIEkgdW5kZXJzdGFuZCBpdCwgYXNzdW1lcw0KPj4gdGhhdCBtYWlsIHN5c3RlbXMgd2lsbCBm YWlybHkgcmFwaWRseSBiZSB1cGdyYWRlZCB0byBoYW5kbGUNCj4+IFVURjgsIGFuZCB0cmllcyB0 byBhdm9pZCBjcmVhdGluZyBzaG9ydC10ZXJtIGtsdWRnZXMgd2hpY2gNCj4+IHdpbGwgaW5ldml0 YWJseSBsaXZlIG9uIGxvbmcgYWZ0ZXIgZXZlcnlvbmUgaGFzIHVwZ3JhZGVkLg0KPj4gDQo+PiBX ZSBtYXkgYmUgYmV0dGVyIG9mZiB3aXRoIGNob2ljZSAyLiAgQ2hvaWNlIDEgbWVhbnMgdGhhdCBh cw0KPj4gc3lzdGVtcyBhcmUgdXBncmFkZWQsICJmb3IiIGNsYXVzZXMgdmFuaXNoLiAgSSd2ZSBm b3VuZCB0aGVzZQ0KPj4gY2xhdXNlcyB0byBiZSB2ZXJ5IGhlbHBmdWwgd2hlbiBkZWJ1Z2dpbmcg dGhpbmdzLg0KPiANCj4gWWVzLCBhbHRob3VnaCBsZXNzIHVzZWZ1bCB0aGFuIHRoZXkgd2VyZSBi ZWZvcmUgc2VjdXJpdHkgaXNzdWVzDQo+IGFuZCB0aGUgdGV4dCBvZiAyODIxIGRpc2NvdXJhZ2Vk IHVzaW5nIHRoZW0gZXhjZXB0IHVuZGVyIHZlcnkNCj4gcmVzdHJpY3RlZCBjb25kaXRpb25zLg0K PiANCj4gVGhhdCBjb25jbHVzaW9uIG1ha2VzIG1lIHZlcnksIHZlcnkgbmVydm91cyAtLWFzIGRv ZXMgZXZlcnkgc3RlcA0KPiB3ZSB0YWtlIHRoYXQgbW92ZXMgZG93bmdyYWRpbmcgY2xvc2VyIHRv IHJlcXVpcmluZyB0aGUgY2F0ZWdvcnkNCj4gb2YgYWN0aXZpdGllcyB0aGF0IDI4MjEgcGVybWl0 cyBvbmx5IGZvciBnYXRld2F5cy0tIGJ1dCBJIGNhbg0KPiBsaXZlIHdpdGggaXQgaWYgdGhhdCBp cyB0aGUgZ3JvdXAncyBkZWNpc2lvbi4gIFNpbmNlIEkgYW0NCj4gd29ya2luZyBvbiB0aGUgSS1E IGZvciAyODIxYmlzIGNvbmN1cnJlbnRseSB3aXRoIHRoZSBFQUkgZWZmb3J0DQo+IC0tYW5kIHdp dGggYSB0YXJnZXQgZGF0ZSBvZiBnZXR0aW5nIDI4MjFiaXMtMDEgcG9zdGVkIHJlYWxseQ0KPiBz b29uIG5vdy0tIGlmIHRoZXJlIGlzIHRleHQgdGhlcmUgdGhhdCBJIG5lZWQgdG8gZmluZS10dW5l LA0KPiBzdWdnZXN0aW9ucyB3b3VsZCBiZSB3ZWxjb21lLg0KPiANCj4gRXZlbiB0aGVuLCB0aGUg Y29uY2VybnMgdGhhdCBkcml2ZSB0aGUgbmVydm91c25lc3Mgc3VnZ2VzdCB0aGF0LA0KPiBpZiB3 ZSBhcmUgZ29pbmcgdG8gYWx0ZXIgZWFybGllciB0cmFjZSBmaWVsZHMgb24gZG93bmdyYWRpbmcs DQo+IA0KPiAoaSkgSXQgbWlnaHQgYmUgYmV0dGVyIHRvIGp1c3QgZHJvcCAiZm9yIiBjbGF1c2Vz IHRoYXQgY29udGFpbg0KPiBub24tQVNDSUkgbWF0ZXJpYWwgcmF0aGVyIHRoYW4gZmlndXJlIG91 dCBzb21lIGNyZWF0aXZlIHdheSB0bw0KPiBlbmNvZGUgdGhlbS4uLi4gcG9zc2libHkgcmVwbGFj aW5nIHRoZW0gd2l0aCBhIGNvbW1lbnQgd2hvc2UNCj4gc2VtYW50aWNzIGFyZSBjbG9zZXIgdG8g Im5vbi1BU0NJSSBmb3IgY2xhdXNlIGRyb3BwZWQgb24NCj4gZG93bmdyYWRpbmciIHRoYW4gdG8g YW4gYXR0ZW1wdGVkIGVuY29kaW5nIG9mIHRoZSBwcmlvciBhZGRyZXNzLg0KDQpGaWd1cmluZyBv dXQgc29tZSBjcmVhdGl2ZSB3YXkgdG8gZW5jb2RlIHRoZW0gaXMgbm90IGdvb2QuIEl0IHNlZW1z IHRoYXQgZHJvcHBpbmcgdGhlbSBpcyBhbHNvIHVucGxlYXNhbnQgY2hvaWNlLg0KSXMgaXQgcG9z c2libGUgdG8gdXNlIEFTQ0lJIGVzY2FwZXMgZm9yIFVuaWNvZGUgY2hhcmFjdGVycyB0byByZXBy ZXNlbnQgaXQgaWYgbm9uLUFTQ0lJIG1hdGVyaWFsIGlzIGluY2x1ZGVkIGluIHRoZSAiZm9yIiBj bGF1c2VzPw0KDQoNCllBTyBKaWFua2FuZw0KQ05OSUMNCg0KDQoNCj4gDQo+IChpaSkgd2UgbWln aHQgd2FudCB0byByZXF1aXJlIHRoZSBNVEEgdGhhdCBkb2VzIHRoZSBkb3duZ3JhZGluZw0KPiB0 byBpbnNlcnQgYSB2ZXJ5IHNwZWNpZmljIHRyYWNlIGhlYWRlciB0aGF0IGV4cGxhaW5zIHRoZSBk YW1hZ2UNCj4gaXQgZGlkLiAgQW55IGNvbW1lbnRzIHRoYXQgY29udGFpbiBlbmNvZGluZ3Mgb2Yg cHJpb3IgYWRkcmVzc2VzDQo+IHNob3VsZCBwcm9iYWJseSBiZSBvbiB0aGF0IHRyYWNlIGhlYWRl ciwgbm90IHJldHJvZml0dGVkIGludG8NCj4gaGVhZGVycyB0aGF0IGRpZCBub3QgY29udGFpbiBp bmZvcm1hdGlvbiBpbiB0aGF0IGZvcm0uDQo+IA0KPiBPciBtYXliZSBub3QuLi4gaXQgY291bGQg YmUgdGhhdCBJJ20gdW5oYXBweSBlbm91Z2ggYWJvdXQgdGhpcw0KPiB0byBub3QgYmUgdGhpbmtp bmcgY2xlYXJseSBlbm91Z2guDQo+IA0KPiAgICAgam9obg0KPiANCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QN Cj4gSU1BQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ltYQ== --===============0336765454== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============0336765454==-- From ima-bounces@ietf.org Tue Jan 23 07:59:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9LF9-0007sn-KI; Tue, 23 Jan 2007 07:59:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9LF8-0007qf-DN for ima@ietf.org; Tue, 23 Jan 2007 07:59:18 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9LF6-0002Ib-SC for ima@ietf.org; Tue, 23 Jan 2007 07:59:18 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1H9LEq-000EJ6-J5; Tue, 23 Jan 2007 07:59:00 -0500 Date: Tue, 23 Jan 2007 07:59:01 -0500 From: John C Klensin To: Yao Jiankang , Randall Gellens , Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: for8 Message-ID: In-Reply-To: <369521577.20632@cnnic.cn>, <0eb801c73e9b$72a334e0$1206e29f@cnnicyao> References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <369514556.17665@cnnic.cn> <369521577.20632@cnnic.cn>, <0eb801c73e9b$72a334e0$1206e29f@cnnicyao> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 23 January, 2007 11:06 +0800 Yao Jiankang wrote: >> (i) It might be better to just drop "for" clauses that contain >> non-ASCII material rather than figure out some creative way to >> encode them.... possibly replacing them with a comment whose >> semantics are closer to "non-ASCII for clause dropped on >> downgrading" than to an attempted encoding of the prior >> address. > > Figuring out some creative way to encode them is not good. It > seems that dropping them is also unpleasant choice. Is it > possible to use ASCII escapes for Unicode characters to > represent it if non-ASCII material is included in the "for" > clauses? ASCII escapes for Unicode characters are nothing more than a different "creative way to encode..." john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 23 13:30:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9QPr-0005ZI-Vs; Tue, 23 Jan 2007 13:30:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9QPo-0005TE-1d for ima@ietf.org; Tue, 23 Jan 2007 13:30:40 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9QNC-00089F-QH for ima@ietf.org; Tue, 23 Jan 2007 13:28:01 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0NIRvaY022955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 Jan 2007 10:27:57 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0NIRtV1003366; Tue, 23 Jan 2007 10:27:56 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 23 Jan 2007 10:27:54 -0800 To: John C Klensin , Frank Ellermann , ima@ietf.org From: Randall Gellens Subject: Re: [EAI] Re: for8 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 8:07 PM -0500 1/22/07, John C Klensin wrote: > --On Monday, 22 January, 2007 12:41 -0800 Randall Gellens > wrote: > >> At 8:18 PM -0500 1/19/07, John C Klensin wrote: >> >>> But, as Harald mentions, we've got a fairly firm rule >>> against a given server tampering with trace fields inserted >>> by other servers. That rule is based on long and hard >>> experience. One could declare this to be the exception and >>> go back and remove earlier "for" fields, but, speaking >>> personally, I'm not convinced that the value of the "for" >>> field and the importance of this case are sufficient to >>> justify breaking that rule. >> >> It seems we have two unpleasant choices: >> >> 1: Prohibit "for" clauses when the address is non-ASCII. >> 2: Alter trace headers when downgrading. > > Yes, I think that summarizes the problem. > >> The basic direction of the group, as I understand it, assumes >> that mail systems will fairly rapidly be upgraded to handle >> UTF8, and tries to avoid creating short-term kludges which >> will inevitably live on long after everyone has upgraded. >> >> We may be better off with choice 2. Choice 1 means that as >> systems are upgraded, "for" clauses vanish. I've found these >> clauses to be very helpful when debugging things. > > Yes, although less useful than they were before security issues > and the text of 2821 discouraged using them except under very > restricted conditions. > > That conclusion makes me very, very nervous --as does every step > we take that moves downgrading closer to requiring the category > of activities that 2821 permits only for gateways-- but I can > live with it if that is the group's decision. There is one good thing about this approach: as downgrading becomes less common, the unpleasant behavior also becomes less common. In an environment where UTF8SMTP messages either successfully go through or are bounced and resent as all-ASCII, there won't be any of this mucking around with messages. > Even then, the concerns that drive the nervousness suggest that, > if we are going to alter earlier trace fields on downgrading, > > (i) It might be better to just drop "for" clauses that contain > non-ASCII material rather than figure out some creative way to > encode them.... possibly replacing them with a comment whose > semantics are closer to "non-ASCII for clause dropped on > downgrading" than to an attempted encoding of the prior address. I agree: deleting the "for" clause is safer than encoding just the "for" clause. It might be good to both delete the "for" clause and put the entire header inside a downgrade-* header (as per downgraded draft). > > (ii) we might want to require the MTA that does the downgrading > to insert a very specific trace header that explains the damage > it did. Any comments that contain encodings of prior addresses > should probably be on that trace header, not retrofitted into > headers that did not contain information in that form. I agree -- this is an excellent requirement and should help debug the inevitable problems. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Premature optimization is the root of all evil --C. A. R. Hoare _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 25 01:47:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9yOB-0000Ad-4e; Thu, 25 Jan 2007 01:47:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9yO9-0000AQ-Q7 for ima@ietf.org; Thu, 25 Jan 2007 01:47:13 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9yO7-0003D5-7O for ima@ietf.org; Thu, 25 Jan 2007 01:47:13 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H9yO0-0000Yd-Gm for ima@ietf.org; Thu, 25 Jan 2007 07:47:04 +0100 Received: from etuovi.fmi.fi ([193.166.207.129]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Jan 2007 07:47:04 +0100 Received: from hurtta+gmane by etuovi.fmi.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Jan 2007 07:47:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Header-Type, Mime-Version (Re: [EAI] Status of utf8header draft) Date: 25 Jan 2007 08:46:54 +0200 Lines: 121 Message-ID: <5dmz47bo2p.fsf_-_@leija.fmi.fi> References: <458A154A.4090707@twnic.net.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: etuovi.fmi.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Randall Gellens writes in gmane.ietf.ima: > At 1:02 PM +0800 12/21/06, Jeff Yeh wrote: > > > Hi all: > > > > While I'm trying to update the header draft, there comes some > > issues (solved/un-solved). Listed below: > > > > * Removing the "Header-Type" header (was UTF8SMTP) > > The basic idea to have a "Header-Type" new header is for > > identifying a email is EAI or non-EAI. And the new header could also > > carry some useful information like downgrade information/language > > tag. However, this kind of self-labeling mechanism was found useless > > as the history of "MIME-Version" header. For the robustness of email > > software, programmers usually ignore the "MIME-Version" header, > > directly check the presents of MIME headers and the MIME encoded > > stuff. This is also happened in TWNIC's implementation on EAI > > testbed, "Header-Type" header is ignored, we check the presents of > > UTF8 instead. Thus, the demand of the "Header-Type" is being raise > > up again. > > Although we already have consensus about this point on San Diego > > meeting, it's still necessary to bring on the mailing list for > > everyone's opinion. > > > > --harald offers choices: > > a) leave UTF8SMTP header field in:one vote > > b) take it out: 10 votes > > c) mime-version 2.0: none > > d) can't decide: 5 votes > > --harald: will take proposal to list to take it out > > > > Defining the header introduces a silly state where the header doesn't > match reality. > > (1) If the header says "ASCII" or isn't present, the message could > still contain UTF8. > > (2) If the header says "UTF8" the message might be all ASCII. > > The effect of (1) would potentially be bad. The effect of (2) is > either harmless, or in the worst case, results in a message being > bounced that could have been delivered. > > Because of (1), receiving systems MUST NOT trust a a label of > "Header-Type: ASCII". If a message is received that claims to be > ASCII, or isn't labelled, the receiver still needs to examine the > message for non-ASCII characters, as well as other conditions that > make the message invalid. > > So, I'd be OK with leaving the header, provided we add text saying > that a value of "ASCII" mustn't be trusted (and even with a value of > "UTF8" the message should still be checked to be sure it is otherwise > valid). > IMHO Header-Type: UTF8 may be replaced with ESMTP option HDR=UTF8 But Header-Type: Downgraded may be still needed. Yes, Header-Type: ASCII is not needed. There may be HDR=ASCII for UTF8SMTP capable MTAs. I do not think that silly state is more problem than on case BODY=7BIT When only Header-Type: Downgraded is needed, perhaps it need to be renamed. Various parameters from Header-Type header field can be put to own header fields. Only question what class Header-Type: UTF8 may need to answer, that is headers of mime subparts UTF8. And Header-Type: UTF8 do not answer that. In here case c Mime-Version: 2.0 may make some sense :-) I do not think that MTAs scan whole mail and parse MIME structure on general. Only exception is that if BODY=8BITMIME processiing tirggers it. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 25 06:43:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA30d-0003uh-6e; Thu, 25 Jan 2007 06:43:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA30c-0003ub-Pi for ima@ietf.org; Thu, 25 Jan 2007 06:43:14 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA30b-0006fN-7W for ima@ietf.org; Thu, 25 Jan 2007 06:43:14 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3$clerew^man^ac#uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45b897cb.16ff8.409 for ima@ietf.org; Thu, 25 Jan 2007 11:43:07 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0PBh6od021760 for ; Thu, 25 Jan 2007 11:43:07 GMT To: IMA Subject: Re: Header-Type, Mime-Version (Re: [EAI] Status of utf8header draft) References: <458A154A.4090707@twnic.net.tw> <5dmz47bo2p.fsf_-_@leija.fmi.fi> Message-ID: Date: Thu, 25 Jan 2007 11:43:06 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5dmz47bo2p.fsf_-_@leija.fmi.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 25 Jan 2007 06:46:54 -0000, Kari Hurtta wrote: > IMHO > > Header-Type: UTF8 > > may be replaced with ESMTP option > > HDR=UTF8 Except when the message is being sent by non-SMTP mechanisms. > > > But > Header-Type: Downgraded > > may be still needed. > > > Yes, > > Header-Type: ASCII > > is not needed. It is only there for the sake of tidiness, and would not usually appear. But omitting Header-Type entirely means the same thing, and carries the same risks, if any. > There may be > HDR=ASCII > for UTF8SMTP capable MTAs. I do not > think that silly state is more problem > than on case > BODY=7BIT Exactly. That would only ever be used for tidiness, and has no semantic effect. > > > When only > > Header-Type: Downgraded > > is needed, perhaps it need to be renamed. But no, you still need the UTF8 form for non-SMTP, and for messages that have left the SMTP environment (for reading, storage, gatewaying to other media, whatever else). > > > Various parameters from Header-Type header field > can be put to own header fields. > > > Only question what class > Header-Type: UTF8 > > may need to answer, that is headers of > mime subparts UTF8. And Yes. An encapsulated message/rfc822 might need to be downgraded, and the presence of that header would indicate that (or, rather, its absence would indicate a malformed message if there was 8bit stuff in it, and "garbage in - garbage out" would be justified). > > Header-Type: UTF8 > > do not answer that. In here case c > > Mime-Version: 2.0 > > may make some sense :-) [Smiley noted] > > > I do not think that MTAs scan whole > mail and parse MIME structure on general. Exactly. If they want to be excessively liberal, they can do it, but maybe the price of liberality is too much wastge of machine cycles. > > Only exception is that if BODY=8BITMIME > processiing tirggers it. And nobody has yet answered my question as to whether current 8BITMIME downgraders bother to scan the whole message if that BODY=8BITMIME is absent. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 25 09:58:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA633-0003Wu-BG; Thu, 25 Jan 2007 09:57:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA631-0003Wi-RA for ima@ietf.org; Thu, 25 Jan 2007 09:57:55 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA62t-0007Uw-CF for ima@ietf.org; Thu, 25 Jan 2007 09:57:55 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HA62n-0006vh-H0 for ima@ietf.org; Thu, 25 Jan 2007 15:57:41 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Jan 2007 15:57:41 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Jan 2007 15:57:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: Header-Type, Mime-Version (Re: [EAI] Status of utf8header draft) Date: 25 Jan 2007 16:57:30 +0200 Lines: 60 Message-ID: <5d4pqfkvc5.fsf@Hurtta06k.keh.iki.fi> References: <458A154A.4090707@twnic.net.tw> <5dmz47bo2p.fsf_-_@leija.fmi.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > And nobody has yet answered my question as to whether current 8BITMIME > downgraders bother to scan the whole message if that BODY=8BITMIME is > absent. I can only say about sendmail. Sendmail detects if on mail there is some bytes with 8-bit set. That is done on receiving of mail. That does not mean that mime structure is parsed. But if there is 8-bit bytes and Mime-Version header field, then following triggers (headers.c) /* check to see if this is a MIME message */ if ((e->e_bodytype != NULL && sm_strcasecmp(e->e_bodytype, "8BITMIME") == 0) || hvalue("MIME-Version", e->e_header) != NULL) { e->e_flags |= EF_IS_MIME; if (HasEightBits) e->e_bodytype = "8BITMIME"; } This does not depend is mail receibed via SMTP or is sendmail invoked directly and mail is received from standard input of sendmail. If next hop does not support 8BITMIME, that means normal 8BITMIME processing, so on that situation mime structure is parsed (because of downgrading). [1] / Kari Hurtta > -- > Charles H. Lindsey ---------At Home, doing my own thing------------------------ > Tel: +44 161 436 6131  >    Web: http://www.cs.man.ac.uk/~chl > Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. > PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 [1] Actually this is not completely true. If MaxMimeHeaderLength or MaxMimeFieldLength is set, MMME structure is always parsed. These options are set by default starting from sendmail 8.11.7 Quote from RELEASE_NOTES 8.11.7/8.11.7 2003/03/29 <...> To provide partial protection for internal, unpatched MTAs that may be performing 7->8 or 8->7 bit MIME conversions, the default for MaxMimeHeaderLength has been changed to 2048/1024. Note: this does have a performance impact, and it only protects against frontal attacks from the outside. To disable the checks and return to pre-8.11.7 defaults, set MaxMimeHeaderLength to 0/0. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 25 22:30:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAHnG-00073v-GZ; Thu, 25 Jan 2007 22:30:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAHnF-00073A-AG for ima@ietf.org; Thu, 25 Jan 2007 22:30:25 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAHnD-0004ux-EZ for ima@ietf.org; Thu, 25 Jan 2007 22:30:24 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0Q3ULec024961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Jan 2007 19:30:22 -0800 Received: from [[192.168.1.13]] (vpn-10-50-16-166.qualcomm.com [10.50.16.166]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0Q3UILN007941; Thu, 25 Jan 2007 19:30:20 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <5dmz47bo2p.fsf_-_@leija.fmi.fi> References: <458A154A.4090707@twnic.net.tw> <5dmz47bo2p.fsf_-_@leija.fmi.fi> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 25 Jan 2007 19:27:43 -0800 To: Kari Hurtta , ima@ietf.org From: Randall Gellens Subject: Re: Header-Type, Mime-Version (Re: [EAI] Status of utf8header draft) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 8:46 AM +0200 1/25/07, Kari Hurtta wrote: > IMHO > > Header-Type: UTF8 > > may be replaced with ESMTP option > > HDR=UTF8 It seems to me that a HDR=UTF8 SMTP extension could only be used in the presence of UTF8SMTP, and isn't needed in that case, so I think I must be missing the intent of such an extension. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The attention span of a computer is only as long as its electrical cord. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 25 23:39:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAIrm-0003E1-R5; Thu, 25 Jan 2007 23:39:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAIrl-0003Ds-4V for ima@ietf.org; Thu, 25 Jan 2007 23:39:09 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAIrj-00010N-Qv for ima@ietf.org; Thu, 25 Jan 2007 23:39:09 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAIrM-0002Ch-M7 for ima@ietf.org; Fri, 26 Jan 2007 05:38:44 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 05:38:44 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 05:38:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: Header-Type, Mime-Version (Re: [EAI] Status of utf8header draft) Date: 26 Jan 2007 06:38:39 +0200 Lines: 55 Message-ID: <5direuh06o.fsf@Hurtta06k.keh.iki.fi> References: <458A154A.4090707@twnic.net.tw> <5dmz47bo2p.fsf_-_@leija.fmi.fi> <18502.8610438623$1169782253@news.gmane.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Randall Gellens writes in gmane.ietf.ima: > At 8:46 AM +0200 1/25/07, Kari Hurtta wrote: > > > IMHO > > > > Header-Type: UTF8 > > > > may be replaced with ESMTP option > > > > HDR=UTF8 > > It seems to me that a HDR=UTF8 SMTP extension could only be used in > the presence of UTF8SMTP, and isn't needed in that case, so I think I > must be missing the intent of such an extension. You missed earlier discussions. Server announces UTF8SMTP. SMTP client can send plain ASCII message still althoug server announces UTF8SMTP. 1) Client tells with HDR=UTF8 that it will use UTF8SMTP for mail headers. 2) UTF8SMTP extension is needed when MAIL FROM or RCPT TO is utf-8, but headers are ascii. Therefore you can be MAIL FROM: ALT-ADDRESS=JannaOsoite@example.com RCPT TO: DATA Received: by mta.example.com id k8DJRPxc015650; Wed, 13 Sep 2006 22:27:25 +0300 Date: Wed, 13 Sep 2006 22:27:25 +0300 From: JannaOsoite@example.com To: Jotakin@example.net Subject: Esimerkki posti jotain. . Precense of ALT-ADDRESS does not indicate that headers are UTF-8. So I disagreed with "isn't needed in that case" part with you. > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly-selected tag: --------------- > The attention span of a computer is only as long as its electrical cord. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Jan 25 23:39:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAIs8-0003Fb-0l; Thu, 25 Jan 2007 23:39:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAIs6-0003FW-0B for ima@ietf.org; Thu, 25 Jan 2007 23:39:30 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAIs4-00016z-KK for ima@ietf.org; Thu, 25 Jan 2007 23:39:29 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0Q4dNVj000369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Jan 2007 20:39:23 -0800 Received: from [[192.168.1.13]] (vpn-10-50-16-166.qualcomm.com [10.50.16.166]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0Q4dKQx022872; Thu, 25 Jan 2007 20:39:22 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <369084760.29707@cnnic.cn> References: <45AE7C9B.6010100@alvestrand.no> <369073998.21105@cnnic.cn> <369084760.29707@cnnic.cn> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 25 Jan 2007 20:33:58 -0800 To: ima@ietf.org, "Yao Jiankang" From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Subject: [EAI] SMTP Extension Draft Text on Requeuing Versus Downgrade/Bounce X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Section 2.2 of the smtpext draft says: If the UTF8SMTP SMTP extension is not offered by the Server, the SMTP Client MUST NOT transmit an internationalized address and MUST NOT transmit a mail body which contains internationalized mail headers [EAI-utf8header]. Instead, it MUST either return the message to the user as undeliverable or replace it with the alternate ASCII address. If it is replaced, the replacement MUST be the ASCII-only address specified with the ALT-ADDRESS parameter.[EAI-downgrading]. I think there should be a mention of requeuing here. I'd like to add new text following paragraph above: -------------------------------- When an MSA or MTA encounters a server that doesn't support UTF8SMTP while relaying a message that requires such support (because either the forward or reverse paths lack an ALT-ADDRESS), it is RECOMMENDED that an alternate MX be tried, and/or the message is requeued for a later attempt, rather than immediately downgrading or bouncing. If the message is requeued, the total elapsed time before bouncing or downgrading SHOULD be smaller than the value used for other SMTP error conditions such as host unreachable or persistent 4xx response codes. This alternate-MX-or-retry-later technique SHOULD NOT be used when the message's return path is a non-ASCII address and the specific forward path being attempted is an ASCII address. The technique also SHOULD NOT be used when both the forward and reverse paths contain an ALT-ADDRESS. The selection of submission servers is presumably under the control of the sender's client, while the selection of potential intermediate relays is under the control of the administration of the final delivery server. Hence, there is a presumption, at least when the recipient address is non-ASCII, that the delivery path servers normally support UTF8SMTP (if the sender's client or MSA didn't support UTF8SMTP, the message would not have been accepted for delivery in the first place). Thus, a lack of UTF8SMTP support is likely to be a temporary situation, such as a normal inbound server being down and a cooperating site acting as a backup MX. -------------------------------- (Sorry for the run-on sentence in the first new paragraph. This can be cleaned up later.) If the lack of UTF8SMTP in the delivery path of a message is a temporary situation, and the message is sent successfully after retrying, then it was a good thing to do. Of course, if there is always an ASCII-only SMTP server in the path, then retrying only adds delay to the failure (bounce or downgrade). As I understand the assumptions and goals of this group, we're trying to avoid making downgrading a normal action, and planning for an environment where UTF8SMTP has wide deployment. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- It is much easier to suggest solutions when you know nothing about the problem. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 00:10:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJLe-0002J5-5f; Fri, 26 Jan 2007 00:10:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJLc-0002Ik-QI for ima@ietf.org; Fri, 26 Jan 2007 00:10:00 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAJLa-0006Ly-GM for ima@ietf.org; Fri, 26 Jan 2007 00:10:00 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAJLP-0005j8-4D for ima@ietf.org; Fri, 26 Jan 2007 06:09:47 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 06:09:47 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 06:09:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: Header-Type, Mime-Version (Re: [EAI] Status of utf8header draft) Date: 26 Jan 2007 07:09:27 +0200 Lines: 41 Message-ID: <5dejpigyrc.fsf@Hurtta06k.keh.iki.fi> References: <458A154A.4090707@twnic.net.tw> <5dmz47bo2p.fsf_-_@leija.fmi.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > On Thu, 25 Jan 2007 06:46:54 -0000, Kari Hurtta > wrote: > > > > IMHO > > > > Header-Type: UTF8 > > > > may be replaced with ESMTP option > > > > HDR=UTF8 > > Except when the message is being sent by non-SMTP mechanisms. That does not prevent these non-SMTP mechanisms to have some own indication. Of course thay need some. But there is also need that UTF8SMTP messages are not given to non-UTF8SMTP aware agents. Header-Type: UTF8 does not imply that kind negation, so something other is needed anyway on non-SMTP mechanisms. Then there is problem that if UTF8SMTP messages are stored on /var/mail/{user} -- they are not supposed to be seen on non-UTF8SMTP aware mail user agents. That storage to /var/mail/{user} or equivalent is one of these non-SMTP mechanisms. Then there is POP and IMAP mechanism. Yes, they need also some indication, but they also need some negation that UTF8SMTP messages are not seen by non-UTF8SMTP aware mail user agents. If header field Header-Type: UTF8 is dropped, then draft-ietf-eai-imap-utf8 and draft-ietf-eai-pop need invent some other mechanism :-) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 00:27:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJcV-0004Jx-WE; Fri, 26 Jan 2007 00:27:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAJcU-0004Jr-OE for ima@ietf.org; Fri, 26 Jan 2007 00:27:26 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAJcS-0000h2-RJ for ima@ietf.org; Fri, 26 Jan 2007 00:27:26 -0500 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0Q5ROPw016728 for ; Thu, 25 Jan 2007 22:27:24 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCG00D01M9TV400@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Thu, 25 Jan 2007 22:27:24 -0700 (MST) Received: from [10.0.1.3] (216-165-225-246.championbroadband.com [216.165.225.246]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCG003HMN5HUM10@mail-amer.sun.com>; Thu, 25 Jan 2007 22:27:24 -0700 (MST) Date: Thu, 25 Jan 2007 21:27:30 -0800 From: Chris Newman Subject: Re: [EAI] Re: for8 In-reply-to: To: John C Klensin , Randall Gellens , Frank Ellermann , ima@ietf.org Message-id: <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote on 1/22/07 20:07 -0500: > (i) It might be better to just drop "for" clauses that contain > non-ASCII material rather than figure out some creative way to > encode them.... possibly replacing them with a comment whose > semantics are closer to "non-ASCII for clause dropped on > downgrading" than to an attempted encoding of the prior address. > > (ii) we might want to require the MTA that does the downgrading > to insert a very specific trace header that explains the damage > it did. Any comments that contain encodings of prior addresses > should probably be on that trace header, not retrofitted into > headers that did not contain information in that form. The robustness gained by never altering Received headers greatly exceeds the value of the "for" clause (for is a convenience -- the relevant MTA logs are the only place where the canonical data can be found). However, regardless of what the specification says, we can't usefully stop email originators from putting a UTF-8 address in the "for" clause of Received. A robust MTA has to deal with that case anyway. So I'd say three things about this issue: 1. SHOULD NOT generate for clause with UTF-8 address: forcing systems to alter received headers is bad 2. MUST remove a Received for clause with a UTF-8 address on downgrade: to avoid breaking systems further down the line 3. MUST NOT include an encoded version of the UTF-8 address in the existing Received header but MAY include it in a Downgraded-details trace field to minimize risk of damage to Received headers. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 05:05:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HANxh-0006OG-D3; Fri, 26 Jan 2007 05:05:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HANxg-0006OB-4d for ima@ietf.org; Fri, 26 Jan 2007 05:05:36 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HANxe-0003B9-RS for ima@ietf.org; Fri, 26 Jan 2007 05:05:36 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 92B7F2596C9 for ; Fri, 26 Jan 2007 11:01:38 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15285-03 for ; Fri, 26 Jan 2007 11:01:33 +0100 (CET) Received: from htat43p-no.corp.google.com (host180-186-static.123-81-b.business.telecomitalia.it [81.123.186.180]) by eikenes.alvestrand.no (Postfix) with ESMTP id 83C112596C6 for ; Fri, 26 Jan 2007 11:01:33 +0100 (CET) Date: Fri, 26 Jan 2007 11:05:28 +0100 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [EAI] CONSENSUS CALL: Header format for alt-addr X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I think it's time we settled the issue of the format of email addresses in UTF8SMTP headers for this round. PROPOSED RESOLUTION: The representation of an internationalized email address with an alternate ASCII address in an UTF8SMTP message is > A pure EAI address and a pure ASCII address are both encoded without the extra field: as . Details of ABNF to be worked out after a draft with this syntax has been emitted. POSSIBLE RESPONSES: 1. I agree with this resolution 2. I disagree with this resolution, for the following technical reason: 3: I have another opinion, which is: RESPOND: - To the list, if you want to present an argument or just want to make your position visible at once - To the chairs, if you don't want to respond on-list. The deadline for responses is THURSDAY, FEBRUARY 1, 23:59 GMT The chairs will prepare a summary, with names listed for each position, hopefully on Friday, Feb 2. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 05:13:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAO5n-0002Jy-Ot; Fri, 26 Jan 2007 05:13:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAO5m-0002G7-Sx for ima@ietf.org; Fri, 26 Jan 2007 05:13:58 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAO5l-0004R5-JL for ima@ietf.org; Fri, 26 Jan 2007 05:13:58 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 660CB2596C9 for ; Fri, 26 Jan 2007 11:10:01 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15438-06 for ; Fri, 26 Jan 2007 11:09:54 +0100 (CET) Received: from htat43p-no.corp.google.com (host180-186-static.123-81-b.business.telecomitalia.it [81.123.186.180]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4FD2C2596C6 for ; Fri, 26 Jan 2007 11:09:54 +0100 (CET) Date: Fri, 26 Jan 2007 11:13:49 +0100 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [EAI] CONSENSUS CALL: Removal of Header-Format: marker X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org The discussion of whether or not we need a header marker for marking UTF8SMTP messages that actually use UTF-8 characters has reached a point where it seems that no new technical information is being provided. At this point, the chairs wish to see if the group is near a possible consensus on the issue. PROPOSED RESOLUTOIN: There is no significant operational or implementation benefit in having a marker in the headers of UTF8SMTP messages, and significant additional complexity. Therefore, the proposed "Header-Type" section, draft-ietf-eai-utf8headers-02 section 5, will be removed. Note that this is not a call on the proposal to have a similar marker in the SMTP protocol; that's a separate issue. POSSIBLE RESPONSES: 1. I agree with this resolution 2. I disagree with this resolution, for the following technical reasons: 3. I have another opinion, which is: RESPOND: - To the list, if you want to present an argument or just want to make your position visible at once - To the chairs, if you don't want to respond on-list. The deadline for responses is THURSDAY, FEBRUARY 1, 23:59 GMT The chairs will prepare a summary, with names listed for each position, hopefully on Friday, Feb 2. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 05:54:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAOiU-0007lN-0S; Fri, 26 Jan 2007 05:53:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAOiS-0007lH-JW for ima@ietf.org; Fri, 26 Jan 2007 05:53:56 -0500 Received: from ppsw-2.csi.cam.ac.uk ([131.111.8.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAOiQ-0002jq-Ak for ima@ietf.org; Fri, 26 Jan 2007 05:53:56 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:53090) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1HAOiI-0004yl-6X (Exim 4.63) (return-path ); Fri, 26 Jan 2007 10:53:46 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HAOiH-0005H5-Sx (Exim 4.54) (return-path ); Fri, 26 Jan 2007 10:53:45 +0000 Date: Fri, 26 Jan 2007 10:53:45 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Harald Tveit Alvestrand Subject: Re: [EAI] CONSENSUS CALL: Header format for alt-addr In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 26 Jan 2007, Harald Tveit Alvestrand wrote: > > The representation of an internationalized email address with an alternate > ASCII address in an UTF8SMTP message is > > > > > A pure EAI address and a pure ASCII address are both encoded without the extra > field: as . 1. I agree with this resolution Nice and uncluttered and does not use non-special characters for syntactic delimiters like some previous suggestions. Tony. -- f.a.n.finch http://dotat.at/ FAIR ISLE: NORTHWEST 6 TO GALE 8, DECREASING 5 OR 6. ROUGH OR VERY ROUGH. ISOLATED SHOWERS. GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 05:55:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAOk6-00088H-Ly; Fri, 26 Jan 2007 05:55:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAOk5-00088A-9T for ima@ietf.org; Fri, 26 Jan 2007 05:55:37 -0500 Received: from ppsw-2.csi.cam.ac.uk ([131.111.8.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAOk4-0002sL-0h for ima@ietf.org; Fri, 26 Jan 2007 05:55:37 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:53658) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1HAOjP-0005JO-93 (Exim 4.63) (return-path ); Fri, 26 Jan 2007 10:54:58 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HAOjP-0005TQ-PA (Exim 4.54) (return-path ); Fri, 26 Jan 2007 10:54:55 +0000 Date: Fri, 26 Jan 2007 10:54:55 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Harald Tveit Alvestrand Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker In-Reply-To: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> Message-ID: References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 26 Jan 2007, Harald Tveit Alvestrand wrote: > > There is no significant operational or implementation benefit in having a > marker in the headers of UTF8SMTP messages, and significant additional > complexity. Therefore, the proposed "Header-Type" section, > draft-ietf-eai-utf8headers-02 section 5, will be removed. 1. I agree with this resolution Tony. -- f.a.n.finch http://dotat.at/ DOGGER: NORTHWESTERLY 5 TO 7. ROUGH OCCASIONALLY VERY ROUGH. ISOLATED SHOWERS. GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 07:19:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQ3M-00038R-OW; Fri, 26 Jan 2007 07:19:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQ3L-00038M-Vh for ima@ietf.org; Fri, 26 Jan 2007 07:19:35 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAQ3K-0000LD-N3 for ima@ietf.org; Fri, 26 Jan 2007 07:19:35 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAQ36-0001ka-6r for ima@ietf.org; Fri, 26 Jan 2007 13:19:20 +0100 Received: from d254130.dialin.hansenet.de ([80.171.254.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 13:19:20 +0100 Received: from nobody by d254130.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 13:19:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] CONSENSUS CALL: Header format for alt-addr Date: Fri, 26 Jan 2007 13:18:56 +0100 Organization: Lines: 9 Message-ID: <45B9F1B0.AA8@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254130.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: > 1. I agree with this resolution It doesn't introduce new delimiters, and it's not worse than square backets wrt future mailto URLs. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 07:34:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQHQ-0002Ui-3H; Fri, 26 Jan 2007 07:34:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQHO-0002UZ-AB for ima@ietf.org; Fri, 26 Jan 2007 07:34:06 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAQHN-0002uI-0P for ima@ietf.org; Fri, 26 Jan 2007 07:34:06 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAQHG-0003tw-Au for ima@ietf.org; Fri, 26 Jan 2007 13:33:58 +0100 Received: from d254130.dialin.hansenet.de ([80.171.254.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 13:33:58 +0100 Received: from nobody by d254130.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 13:33:58 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 26 Jan 2007 13:32:43 +0100 Organization: Lines: 29 Message-ID: <45B9F4EB.76F3@xyzzy.claranet.de> References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254130.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [EAI] Re: for8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Newman wrote: > 1. SHOULD NOT generate for clause with UTF-8 address: forcing systems > to alter received headers is bad You could as well say "sending UTF8SMTP to MTAs not supporting it forces them to try some 'downgrade' magic, and therefore the senders SHOULD NOT use UTF8SMTP in the first place". But that's obviously not the idea of this experiment... > 2. MUST remove a Received for clause with a UTF-8 address on downgrade: > to avoid breaking systems further down the line ...yes. Downgrade is such a complex procedure that adding this minor detail as MUST won't make it worse. > 3. MUST NOT include an encoded version of the UTF-8 address in the > existing Received header but MAY include it in a Downgraded-details > trace field to minimize risk of damage to Received headers. The "MUST NOT" part is already covered by your second point, the draft could still state why that probably won't work: The encoding would have to guarantee that it can't be confused (syntactically) with a real ASCII addresss. In theory that's possible, e.g. Google Groups use "..." in a munged local part. In practice it fails because spammers and some MTAs don't care about any IETF fine print declaring adjacent dots as illegal. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 07:46:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQSx-0000tg-Om; Fri, 26 Jan 2007 07:46:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAQSw-0000tJ-5R for ima@ietf.org; Fri, 26 Jan 2007 07:46:02 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAQSu-0004zK-Si for ima@ietf.org; Fri, 26 Jan 2007 07:46:02 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAQSn-0005Sq-Uq for ima@ietf.org; Fri, 26 Jan 2007 13:45:53 +0100 Received: from d254130.dialin.hansenet.de ([80.171.254.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 13:45:53 +0100 Received: from nobody by d254130.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 13:45:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Date: Fri, 26 Jan 2007 13:45:11 +0100 Organization: Lines: 17 Message-ID: <45B9F7D7.6B46@xyzzy.claranet.de> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254130.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: > 3. I have another opinion, which is: I can't judge it at the moment. If the next draft tries to get away without it, okay, but maybe we'll find later that an explicit header field helps in some cases. I'd feel far more confident that the WG is on the right track if we nail the message/rfc822 vs. message/utf8smtp (or similar) question. A redefinition of message/rfc822 to "who knows, you're free to scan the header for non-ASCII octets and check if that happens to be UTF-8" IMO can't work. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 08:36:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HARFL-0003Z6-ME; Fri, 26 Jan 2007 08:36:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HARFK-0003XB-D5 for ima@ietf.org; Fri, 26 Jan 2007 08:36:02 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HARFI-0005CI-Vm for ima@ietf.org; Fri, 26 Jan 2007 08:36:02 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HARF5-000KNr-RJ; Fri, 26 Jan 2007 08:35:48 -0500 Date: Fri, 26 Jan 2007 08:35:47 -0500 From: John C Klensin To: Chris Newman , Randall Gellens , Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: for8 Message-ID: <928640D60C755353E508511D@p3.JCK.COM> In-Reply-To: <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Thursday, 25 January, 2007 21:27 -0800 Chris Newman wrote: > John C Klensin wrote on 1/22/07 20:07 -0500: >> (i) It might be better to just drop "for" clauses that contain >> non-ASCII material rather than figure out some creative way to >> encode them.... possibly replacing them with a comment whose >> semantics are closer to "non-ASCII for clause dropped on >> downgrading" than to an attempted encoding of the prior >> address. >> >> (ii) we might want to require the MTA that does the >> downgrading to insert a very specific trace header that >> explains the damage it did. Any comments that contain >> encodings of prior addresses should probably be on that trace >> header, not retrofitted into headers that did not contain >> information in that form. > > The robustness gained by never altering Received headers > greatly exceeds the value of the "for" clause (for is a > convenience -- the relevant MTA logs are the only place where > the canonical data can be found). However, regardless of what > the specification says, we can't usefully stop email > originators from putting a UTF-8 address in the "for" clause > of Received. A robust MTA has to deal with that case anyway. > So I'd say three things about this issue: > > 1. SHOULD NOT generate for clause with UTF-8 address: forcing > systems to alter > received headers is bad > 2. MUST remove a Received for clause with a UTF-8 address on > downgrade: to avoid > breaking systems further down the line > 3. MUST NOT include an encoded version of the UTF-8 address in > the > existing Received header but MAY include it in a > Downgraded-details trace > field to minimize risk of damage to Received headers. This seems about right to me. FWIW, if I recall, the text in 2821 was rather carefully written to permit additional trace header types to be added. So, while it is hard to extend Received and its subfields, adding a Downgraded-details (or equivalent) trace field is fairly easy from a syntax and definitional standpoint. The bad news is that I believe that there are a lot of spam filters out there that treat messages in which anything but Received headers appears between the first Received header and the last one as suspicious. The contents of those filters are completely outside the EAI scope or the 821/2821/ 2821bis specs, but they may be significant in practice. To paraphrase a comment I made in another note, adding new headers (at the specification level) is never free, or even cheap. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 09:02:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAReZ-00080V-Lr; Fri, 26 Jan 2007 09:02:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAReY-0007zs-CE for ima@ietf.org; Fri, 26 Jan 2007 09:02:06 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAReX-0000VE-1Y for ima@ietf.org; Fri, 26 Jan 2007 09:02:06 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HAReW-000KUI-JW; Fri, 26 Jan 2007 09:02:04 -0500 Date: Fri, 26 Jan 2007 09:02:03 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: for8 Message-ID: In-Reply-To: <45B9F4EB.76F3@xyzzy.claranet.de> References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> <45B9F4EB.76F3@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 26 January, 2007 13:32 +0100 Frank Ellermann wrote: > Chris Newman wrote: > >> 1. SHOULD NOT generate for clause with UTF-8 address: forcing >> systems to alter received headers is bad > > You could as well say "sending UTF8SMTP to MTAs not supporting > it forces them to try some 'downgrade' magic, and therefore > the senders SHOULD NOT use UTF8SMTP in the first place". But > that's obviously not the idea of this experiment... Frank, I don't understand this comment. I can't even parse it completely, i.e., I don't know whether "them" refers to the sending or receiving server. If it means what I think it might, you are suggesting that, if one cannot have "for" with a UTF-8 address, then the whole idea of UTF8SMTP is useless. I don't believe that. I suspect you don't either. Another interpretation is that downgrading is hopeless and, if one encounters a legacy server while trying to transport UTF8SMTP mail, one should simply deal with the message as undeliverable. I've made not secret that I've got some growing sympathy for that position, but I think you are among the vast majority who believe that downgrading is a good (and necessary) mechanism, so you presumably don't mean that either. If the comment is hyperbole, hyperbole does not help us make progress here. >... john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 11:47:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUE3-0004ZK-3q; Fri, 26 Jan 2007 11:46:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUE0-0004Wg-9D for ima@ietf.org; Fri, 26 Jan 2007 11:46:53 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAUDx-0002aZ-2C for ima@ietf.org; Fri, 26 Jan 2007 11:46:52 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HAUDu-000Lqq-Pq; Fri, 26 Jan 2007 11:46:47 -0500 Date: Fri, 26 Jan 2007 11:46:45 -0500 From: John C Klensin To: Charles Lindsey , IMA Subject: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft)) Message-ID: <66B5502F24092DF658DA31DF@p3.JCK.COM> In-Reply-To: References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 19 January, 2007 14:28 +0000 Charles Lindsey wrote: > On Thu, 18 Jan 2007 15:49:24 -0000, John C Klensin > wrote: >... > Let us look at a comparable example - 8BITMIME. Suppose some > message announces Content-Transfer-Encoding: 7bit, and then > proceeds to include 8bit stuff further down. Or suppose it > omits the 8BITMIME parameter in the MAIL FROM command and > nevertheless sends 8bit stuff. Is current practice for agents > that support 8BITMIME to check through the whole body looking > for 8bit stuff before passing the message on to an agent which > does not support 8BITMIME? That would be robust, but I doubt > current agents go to that trouble. Actually several do make that check, but not necessarily where you think they do. Others implement 8BITMIME as a variation on "just send 8" and basically ignore the parameter, treating all incoming messages as if they were 8bit and forwarding them to the next-hop relay regardless of whether it advertises the capability or not. Of course, they are in violation of the spec. When the check is made, it is at least as often made by scanning the input data stream as it arrives, looking for characters with the high-order bit set, as it is made as part of an analysis of the body of a received message. >... >>> Much better to let "ASCII" be treated as ASCII, and if that >>> causes the message to be munged/lost, then what's new? >>> Garbage in - Garbage out. >> >> Munged doesn't bother me very much, although message >> corruption without notice to the user is very bad news. Lost >> does. > > Actually, I think complete loss is less likely than munging, > since an MTA is likely to reject if it is not given a RCPT TO > that looks like something it knows where to send to. Unless it > is storage agents (IMAP/POP3) that canot tell where to put it > just by looking at the To header. Any "storage agent" that figures out where to put mail by looking at the To header is seriously and fatally broken. Storage locations and other delivery actions have to be determined by envelope processing and nothing else. >>> A waste of resources, and hence to be discouraged, but no >>> harm arises. >> >> But it is further evidence that the header is nearly useless. > > No worse that writing Content-Transfer-Encoding: 8bit when > 7bit would have done. I disagree, and this is, IMO, fairly fundamental. Content-Transfer-Encoding must exist as a header. The reasons for that are well established -- MIME doesn't work without it and systems that process MIME must be prepared for it and to process it. What is being proposed here is to _add_ a new header. Creating a new header, standardizing it, getting it implemented and deployed -- all have costs, and those costs are significant. > But this header was never intended to guide MTAs in how to > process messages, since our smtpext has got that well covered. > I wrote on 21st December giving 7 reasons why this header was > needed, and they were all related to situations where the > transprt mechanism was not smtp, or where the message was > being processed after it has left the smtp enviroment (and > hence the envelope information was no longer available). If > you believe this head is useless, then please reply, point by > point, to that message. In the hope that we can move beyond this, let me try to do that. I believe that all, or almost all, of this has been said before. But, maybe by drawing things together into one place, we can make progress or at least avoid revisiting the topics about which Harald has just issued a consensus call. --On Thursday, 21 December, 2006 17:41 +0000 Charles Lindsey wrote: > AFAIAC, the Header-Type header field is VITAL, for the > following reasons: > > 1. It is the only way to tell that a message is UTF8SMTP in > the case where the transport mechanism is _not_ SMTP (a > situation which the draft now claims to allow). Allowing a non-SMTP transport is different from an assertion that all of the possible real or imaginary needs of non-SMTP transports are satisfied. We have a long history of saying that, if we are carrying information in the SMTP envelope that some other transport environment needs to have in headers (or elsewhere), perhaps because it doesn't have an envelope, then it is the responsibility of the protocol specification for the other transport system to specify where to put the information and how to get it there. The fact that some other mail system might require this header, or a header specifying the location of the nearest Chinese restaurant, does not make it a requirement for this specification or document. > 2. Even when the transport mechanism _is_ SMTP, you cannot > tell in the case where all the addresses are in pure ASCII; > there could still be Subject and other headers with UTF8 in > them, and there could be embedded MIME objects with UTF8 in > their headers (e.g. message/rfc822 or filenames in > Content-Disposition). It would need an SMTP parameter such as > BODY-UTF8SMTP to indicate that. It is fundamental to SMTP that accepting a message involves accepting responsibility for that message on behalf of all downstream systems. The strongest manifestation of that principle is the rule that message-acceptance must be taken seriously with messages thereafter being either delivered or rejected in some way, not accidentally or deliberately lost. In essence, the SMTP extension model simply extends the principle to say that, if one accepts, or agrees to accept, a message with a certain set of capabilities, one is taking the same responsibilities as one had under 821 (and earlier) for accepting the message itself. The EAI model essentially provides that, if one offers the UTF8SMTP option, one is willing to accept, and take responsibility for, _any_ UTF-8 header information permitted by the spec. So one doesn't need additional headers to specify that some other header might contain UTF-8 information in an SMTP environment, even if they would "work". For a non-SMTP environment, see (1), above. Also please remember that 2822 and its predecessors have a strong bias against needing headers to be in a specific order. If header reordering causes the "header-type" to show up after the fields that it is supposed to protect one from, then one needs to be able to parse, and possibly process, those fields without whatever information "header-type" would provide. One could avoid that problem by scanning all headers for "header-type" before doing anything else, but that does considerable violence to both 2822 and to the way many contemporary MUA and delivery MTA implementations are written. > 3. Once a message has passed "final delivery" (whatever that > is), the SMTP information is no longer available, but you may > still need to know whether it is a UTF8SMTP message. Even if > IMAP and POP3 contrive to keep this information somehow, they > are not the only storage mechanisms in use; for example, good > ol' mbox format is still around, and has no other way to store > that information. There is a long history of special headers, flags, and similar information being kept with the stored form of a message. We have never tried to standardize that information or how it is stored, much less required that a placeholder header be passed around the network to accommodate it on storage. Note that this information includes things as simple (and common) as a "seen" flag. If we were to decide to standardize a way to handle that information, or the deliveryMTA-> messageStore interface more generally, it wouldn't be a task for this WG. > 4. You NEED that information before you can gateway the > message to some other medium (gatewaying is always dificult in > the general case, and the other medium may or may not require > some downgrade, and even if it doesn't it may need to know so > that it in turn can gateway it on to something else). You have not demonstrated that the information in the envelope and the associated constraints are insufficient. Nothing in the work of this WG prevents you from creating a header (or equivalent) in the gateway to the other environment. This is not a separate issue; it is just a different way to restart (1). So are some of the others, but they are better disguised. > 5. You NEED that information before you can Resend the message > (or maybe even forward it, or encapsulate it as a > message/rfc822 within something else). MUA problem, outside the scope of these specs or this WG. If the MUA doesn't know what it is handling before trying to do some of those things, it is in bad trouble. Encapsulation is a tricky case, as as been discussed many times before, but you have offered no evidence that having a Header-type, especially an unreliable one, floating around helps with that problem. If the MUA needs a reliable Header-type, then it needs to parse the message to be sure it isn't being lied to. > 6. Your MUA may NEED that information before it can display it > (e.g. does it need to upgrade it first?), or else you NEED it > in order to determine whether it requires to be downgraded > before submission to the MUA, or even whether it needs to be > upgraded first. This appears to me to be just a variation on (3). I'm not going to repeat myself. > 7. You NEED that information if the message has been > DKIM-Signed, so you can either upgrade it before checking the > signature, or else report "Sorry! This signature cannot be > verified because of downgrading". Anything that changes the format or content of the headers of a message is going to pose a challenge for DKIM and anything else that depends on integrity validation of headers. If I were inclined to depend on DKIM to get a message some kind of preferential treatment, I'd probably be very sure that I didn't supply an ALT-Address and would be checking the various pieces of text to make the conditions under which a UTF8SMTP system MUST NOT mess with headers in any way, i.e., that, if it hit a barrier, it needed to reject the message rather than getting creative. Then I would go to the DKIM WG and say "look, there are going to be messages with UTF-8-containing envelopes and headers floating around the Internet, and some of it may involve downgrading, do we need to adjust the DKIM machinery to deal better with that situation?". And, yes, there are reason why the work should be done there, rather than here. At least two of them are: (i) They know the constraints and exceptions they need to have to make a DKIM signature work, and are capable of changing them if needed. We don't and can't. (ii) EAI is an effort to expand and enhance the basic Internet email fabric to accommodate address i18n and a number of things that seem to go with it. DKIM is an overlay, additional, service to carry information to help establish prioritization or preferences for email messages but to carry the needed information in-band. That makes it _their_ problem to deal with our extensions... or to prove that we have somehow made their problem impossible and then force an IETF consensus decision about priorities. > Note that there is a feature in DKIM whereby you can say, in > the signature, "here is how such-and-such a header was at the > point where it was signed". You might use that feature to > record the original From, etc, but more importantly if you > used it on the Header-Type (which itself MUST NOT be included > in the signed hash, because it can change en route) then you > could detect that the Header-Type was "UTF8" when it was > signed but it now shows as "downgraded", and so you know > exactly where you stand. I think this proves the point I am trying to make above. Specifying the interactions between DKIM and downgraded i18n messages is a DKIM problem. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 12:22:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUmE-0006pf-VQ; Fri, 26 Jan 2007 12:22:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUmE-0006pZ-4V for ima@ietf.org; Fri, 26 Jan 2007 12:22:14 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAUmB-0006mn-QU for ima@ietf.org; Fri, 26 Jan 2007 12:22:14 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAUm0-0000iZ-RG for ima@ietf.org; Fri, 26 Jan 2007 18:22:01 +0100 Received: from d254130.dialin.hansenet.de ([80.171.254.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 18:22:00 +0100 Received: from nobody by d254130.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 18:22:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 26 Jan 2007 18:20:48 +0100 Organization: Lines: 37 Message-ID: <45BA3870.1646@xyzzy.claranet.de> References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> <45B9F4EB.76F3@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254130.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [EAI] Re: for8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: >> You could as well say "sending UTF8SMTP to MTAs not supporting >> it forces them to try some 'downgrade' magic, and therefore >> the senders SHOULD NOT use UTF8SMTP in the first place". But >> that's obviously not the idea of this experiment... [...] > I don't know whether "them" refers to the sending or receiving > server. I meant "them" downgrade gateways. > Another interpretation is that downgrading is hopeless Now "hopeless" is a bit strong, let's say "difficult" with a chance to screw up something (not limited to DKIM signatures). > I think you are among the vast majority who believe that > downgrading is a good (and necessary) mechanism, so you > presumably don't mean that either. That's why I think a "SHOULD NOT use for8" like a "SHOULD NOT use UTF8SMTP" makes no sense: Either the downgrade works as expected (1), or the mail is rejected (2), or the complete route is UTF8SMTP-ready (3), or for a few remaining cases the downgrade somehow fails miserably (4). For (1), (2), and (3) there's no "for8" problem justifying a SHOULD NOT. And in the hopefully rare (4) cases it's anyway hopeless, the presence or absence of a "for8" won't change the outcome. If a downgrade fails only because the required removal of "for8" didn't work, then I propose to fix the MTA, instead of a "SHOULD NOT use for8" for everybody in (1)..(4). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 12:25:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUph-0000Zl-9X; Fri, 26 Jan 2007 12:25:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUpg-0000Yx-Rd for ima@ietf.org; Fri, 26 Jan 2007 12:25:48 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAUpb-000794-A3 for ima@ietf.org; Fri, 26 Jan 2007 12:25:48 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3*clerew^man#ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45ba3985.15508.44 for ima@ietf.org; Fri, 26 Jan 2007 17:25:25 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0QHPOXR011883 for ; Fri, 26 Jan 2007 17:25:25 GMT To: IMA Subject: Re: [EAI] CONSENSUS CALL: Header format for alt-addr References: Message-ID: Date: Fri, 26 Jan 2007 17:25:23 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 26 Jan 2007 10:05:28 -0000, Harald Tveit Alvestrand wrote: > I think it's time we settled the issue of the format of email addresses > in UTF8SMTP headers for this round. > > PROPOSED RESOLUTION: > > The representation of an internationalized email address with an > alternate ASCII address in an UTF8SMTP message is > > > > > A pure EAI address and a pure ASCII address are both encoded without the > extra field: as . > Details of ABNF to be worked out after a draft with this syntax has been > emitted. > > POSSIBLE RESPONSES: > > 1. I agree with this resolution > 2. I disagree with this resolution, for the following technical reason: > 3: I have another opinion, which is: 1. I agree with this resolution Note that if some technical reason why '[...]' is superior to '<...>' should subsequently appear, it could easily be changed to that. But no such technical reason has appeared to date, hence '<....>' is preferred as a matter of appearance. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 12:31:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUur-000486-Hu; Fri, 26 Jan 2007 12:31:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAUup-00043E-TF for ima@ietf.org; Fri, 26 Jan 2007 12:31:07 -0500 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAUuo-0007te-NI for ima@ietf.org; Fri, 26 Jan 2007 12:31:07 -0500 Received: from sceptre.pobox.com (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 327CE79F; Fri, 26 Jan 2007 12:31:26 -0500 (EST) Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id D28FA218A9; Fri, 26 Jan 2007 12:31:24 -0500 (EST) Date: Fri, 26 Jan 2007 09:31:01 -0800 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <581354014.20070126093101@pobox.com> To: IMA Discussion Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker In-Reply-To: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 2007-01-26, Harald Tveit Alvestrand wrote: > PROPOSED RESOLUTOIN: > There is no significant operational or implementation benefit in having a > marker in the headers of UTF8SMTP messages, and significant additional > complexity. Therefore, the proposed "Header-Type" section, > draft-ietf-eai-utf8headers-02 section 5, will be removed. I agree with this resolution -- Bill McQuillan _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 12:44:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAV7p-0002U8-BA; Fri, 26 Jan 2007 12:44:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAV7o-0002U0-96 for ima@ietf.org; Fri, 26 Jan 2007 12:44:32 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAV7m-0001J5-KO for ima@ietf.org; Fri, 26 Jan 2007 12:44:32 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3^clerew#man*ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45ba3dfd.1676.567 for ima@ietf.org; Fri, 26 Jan 2007 17:44:29 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0QHiRLn013272 for ; Fri, 26 Jan 2007 17:44:28 GMT Date: Fri, 26 Jan 2007 17:44:27 -0000 To: IMA Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 26 Jan 2007 10:13:49 -0000, Harald Tveit Alvestrand wrote: > PROPOSED RESOLUTOIN: > > There is no significant operational or implementation benefit in having > a marker in the headers of UTF8SMTP messages, and significant additional > complexity. Therefore, the proposed "Header-Type" section, > draft-ietf-eai-utf8headers-02 section 5, will be removed. > > Note that this is not a call on the proposal to have a similar marker in > the SMTP protocol; that's a separate issue. > > POSSIBLE RESPONSES: > > 1. I agree with this resolution > 2. I disagree with this resolution, for the following technical reasons: > 3. I have another opinion, which is: I disagree with this resolution, for the following technical reasons: I gave these reasons on December 21st, and nobody has commented on my objections. I repeat below what I wrote then: AFAIAC, the Header-Type header field is VITAL, for the following reasons: 1. It is the only way to tell that a message is UTF8SMTP in the case where the transport mechanism is _not_ SMTP (a situation which the draft now claims to allow). 2. Even when the transport mechanism _is_ SMTP, you cannot tell in the case where all the addresses are in pure ASCII; there could still be Subject and other headers with UTF8 in them, and there could be embedded MIME objects with UTF8 in their headers (e.g. message/rfc822 or filenames in Content- Disposition). It would need an SMTP parameter such as BODY-UTF8SMTP to indicate that. 3. Once a message has passed "final delivery" (whatever that is), the SMTP information is no longer available, but you may still need to know whether it is a UTF8SMTP message. Even if IMAP and POP3 contrive to keep this information somehow, they are not the only storage mechanisms in use; for example, good ol' mbox format is still around, and has no other way to store that information. 4. You NEED that information before you can gateway the message to some other medium (gatewaying is always dificult in the general case, and the other medium may or may not require some downgrade, and even if it doesn't it may need to know so that it in turn can gateway it on to something else). 5. You NEED that information before you can Resend the message (or maybe even forward it, or encapsulate it as a message/rfc822 within something else). 6. Your MUA may NEED that information before it can display it (e.g. does it need to upgrade it first?), or else you NEED it in order to determine whether it requires to be downgraded before submission to the MUA, or even whether it needs to be upgraded first. 7. You NEED that information if the message has been DKIM-Signed, so you can either upgrade it before checking the signature, or else report "Sorry! This signature cannot be verified because of downgrading". Note that there is a feature in DKIM whereby you can say, in the signature, "here is how such-and-such a header was at the point where it was signed". You might use that feature to record the original From, etc, but more importantly if you used it on the Header-Type (which itself MUST NOT be included in the signed hash, because it can change en route) then you could detect that the Header-Type was "UTF8" when it was signed but it now shows as "downgraded", and so you know exactly where you stand. OK, there may still be lots of problems with DKIM-Signatures on UTF8SMTP messages, and we will need to look at them later on; but in the meantime let us not do anything that would make those propblems worse. And, on top of all those reasons, I would add: 8. It will not be possible to extend this scheme to Netnews (Usenet) without this header, because there will be no way to know whether special attention is needed when gatewaying an article into email (a special case of point #4. Indeed, you would have the same problem it you tried to send email via NNTP (which has been suggested, though I do not see how it would work myself). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 12:51:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVEM-0005cE-4E; Fri, 26 Jan 2007 12:51:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVEL-0005be-5m for ima@ietf.org; Fri, 26 Jan 2007 12:51:17 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAVEF-00028K-SX for ima@ietf.org; Fri, 26 Jan 2007 12:51:17 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAVE7-0004ps-K0 for ima@ietf.org; Fri, 26 Jan 2007 18:51:03 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 18:51:03 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 18:51:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] CONSENSUS CALL: Header format for alt-addr Date: 26 Jan 2007 19:50:55 +0200 Lines: 20 Message-ID: <5dac057k3k.fsf@Hurtta06k.keh.iki.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand writes in gmane.ietf.ima: > I think it's time we settled the issue of the format of email > addresses in UTF8SMTP headers for this round. > > PROPOSED RESOLUTION: > > The representation of an internationalized email address with an > alternate ASCII address in an UTF8SMTP message is > > > > > A pure EAI address and a pure ASCII address are both encoded without > the extra field: as . > Details of ABNF to be worked out after a draft with this syntax has > been emitted. > 1. I agree with this resolution _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 13:06:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVTP-0005m4-Vl; Fri, 26 Jan 2007 13:06:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAVTO-0005ly-QN for ima@ietf.org; Fri, 26 Jan 2007 13:06:50 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAVTN-0004BT-H9 for ima@ietf.org; Fri, 26 Jan 2007 13:06:50 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAVTI-0006VT-UE for ima@ietf.org; Fri, 26 Jan 2007 19:06:44 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 19:06:44 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 19:06:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Date: 26 Jan 2007 20:06:32 +0200 Lines: 33 Message-ID: <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand writes in gmane.ietf.ima: > The discussion of whether or not we need a header marker for marking > UTF8SMTP messages that actually use UTF-8 characters has reached a > point where it seems that no new technical information is being > provided. > > At this point, the chairs wish to see if the group is near a possible > consensus on the issue. > > PROPOSED RESOLUTOIN: > > There is no significant operational or implementation benefit in > having a marker in the headers of UTF8SMTP messages, and significant > additional complexity. Therefore, the proposed "Header-Type" section, > draft-ietf-eai-utf8headers-02 section 5, will be removed. > > Note that this is not a call on the proposal to have a similar marker > in the SMTP protocol; that's a separate issue. I can not decide yet. Specially removal of Header-Format: Downgraded marker. For Header-Format: UTF8 I prefer marker on outside of headers. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 14:00:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWJD-00085M-DR; Fri, 26 Jan 2007 14:00:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWJB-00085E-BJ for ima@ietf.org; Fri, 26 Jan 2007 14:00:21 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWIr-0004GJ-D9 for ima@ietf.org; Fri, 26 Jan 2007 14:00:21 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HAWIq-000N0R-F4; Fri, 26 Jan 2007 14:00:00 -0500 Date: Fri, 26 Jan 2007 13:59:59 -0500 From: John C Klensin To: Charles Lindsey , IMA Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Message-ID: <218EF4FA0A1BFDB033AF0651@p3.JCK.COM> In-Reply-To: References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 26 January, 2007 17:44 +0000 Charles Lindsey wrote: >... > 8. It will not be possible to extend this scheme to Netnews > (Usenet) without this header, because there will be no way to > know whether special attention is needed when gatewaying an > article into email (a special case of point #4. Indeed, you > would have the same problem it you tried to send email via > NNTP (which has been suggested, though I do not see how it > would work myself). See comments in the note I sent a few hours ago (with Subject line "Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft))" and, in particular, the comments about gateways and other systems. Two comments on this new point in particular: (1) Nothing would prevent: (i) Defining a Header-format (or other) header for use in the Netnews environment. (ii) Requiring that a Mail-to-News gateway map the envelope information into that header, or that it scan the message headers and body and generate the header. (iii) Requiring that a News-to-Mail gateway map the header into appropriate envelope information or scan the message (including headers) to determine whether the envelope extension information needed to be present (or required). Scenarios that have both the envelope information and a redundant header field containing essentially the same information for the same message at the same time risk all sorts of "what happens if they are inconsistent and for what reasons" cases. It is an elementary design principle that such situations are best avoided. In the email case, that principle is backed up by a huge amount of nasty experience that shows us that, even if clear precedence is defined between the two information locations, implementations(deliberately or accidentally) get it wrong. The "Errors-to" header, which is needed for some systems that do not use SMTP envelopes or the equivalent, used to be a major example of this problem. (2) If I correctly understand the moves to make (or declare) Netnews to be 8-bit-clean, the scan permitted or required by (1)(iii) above would be required in any event, because messages might originate in the Netnews environment that contained 8bit information but didn't come from mail and hence did not have the header. Conversely, one could require that Header-type _always_ appear in Netnews files that contain 8bit information that might migrate into the headers. The thing that all of those cases and scenarios have in common is that they point to this being a Netnews and/or Netnews <-> SMTP/Internet gateway problem, not an EAI problem. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 14:15:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWXN-000155-0b; Fri, 26 Jan 2007 14:15:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWXL-00010F-Q6 for ima@ietf.org; Fri, 26 Jan 2007 14:14:59 -0500 Received: from ppsw-4.csi.cam.ac.uk ([131.111.8.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWXJ-0006aM-HC for ima@ietf.org; Fri, 26 Jan 2007 14:14:59 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:53966) by ppsw-4.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.154]:25) with esmtpa (EXTERNAL:fanf2) id 1HAWWy-0000g3-G5 (Exim 4.63) (return-path ); Fri, 26 Jan 2007 19:14:36 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HAWWy-0006Tr-Uu (Exim 4.54) (return-path ); Fri, 26 Jan 2007 19:14:36 +0000 Date: Fri, 26 Jan 2007 19:14:36 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin Subject: Re: [EAI] Re: for8 In-Reply-To: <928640D60C755353E508511D@p3.JCK.COM> Message-ID: References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> <928640D60C755353E508511D@p3.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Randall Gellens , Frank Ellermann , Chris Newman , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 26 Jan 2007, John C Klensin wrote: > > FWIW, if I recall, the text in 2821 was rather carefully written > to permit additional trace header types to be added. However the syntax for trace fields in 2822 is not extensible. Tony. -- f.a.n.finch http://dotat.at/ LUNDY FASTNET IRISH SEA: NORTHWESTERLY 4 OR 5. MODERATE OR SLIGHT. SHOWERS AT FIRST THEN MAINLY FAIR. MODERATE OR GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 14:30:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWmF-0000My-9F; Fri, 26 Jan 2007 14:30:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWmE-0000Mr-5W for ima@ietf.org; Fri, 26 Jan 2007 14:30:22 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWmC-0000EG-Pm for ima@ietf.org; Fri, 26 Jan 2007 14:30:22 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l0QJUFx2013506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 26 Jan 2007 11:30:16 -0800 Received: from [10.0.1.7] (vpn-10-50-16-251.qualcomm.com [10.50.16.251]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l0QJUE7f008630; Fri, 26 Jan 2007 11:30:15 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <218EF4FA0A1BFDB033AF0651@p3.JCK.COM> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <218EF4FA0A1BFDB033AF0651@p3.JCK.COM> Date: Fri, 26 Jan 2007 11:30:12 -0800 To: John C Klensin , Charles Lindsey , IMA From: Ted Hardie Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > >Scenarios that have both the envelope information and a >redundant header field containing essentially the same >information for the same message at the same time risk all sorts >of "what happens if they are inconsistent and for what reasons" >cases. While I'm generally sympathetic to the idea that you shouldn't set up protocols that are liable to silly states, I do have some questions here. The first is how many different gateway types we're actually likely to need here. With a single type (mail-to-news), it's pretty obvious that you can put the logic on either side of the gateway provided you have any marker at all. But if there are lots of different types of gateways that will need this, then a standard (or at least "usual") transport-independent marker might be useful. That makes it a bit easier for those writing gateways. There is also an issue of what happens when the message passes through multiple gateways (imagine some mix of mail, news, and mms a la 4356); knowing that you'll see the same marker no matter what set of gateways a message took to reach from originator to receiver does seem useful. >It is an elementary design principle that such >situations are best avoided. In the email case, that principle >is backed up by a huge amount of nasty experience that shows us >that, even if clear precedence is defined between the two >information locations, implementations(deliberately or >accidentally) get it wrong. The "Errors-to" header, which is >needed for some systems that do not use SMTP envelopes or the >equivalent, used to be a major example of this problem. It's hard to argue with that experience, but it does seem like a precedence *could* be established. If you have access to the SMTP transport this header is ignored; if you don't the header is honored. Note: no hats on; just trying to understand the design space and constraints. Ted _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 14:42:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWxq-0007O2-Fv; Fri, 26 Jan 2007 14:42:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAWxp-0007Ns-Vu for ima@ietf.org; Fri, 26 Jan 2007 14:42:21 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAWxo-00028r-JV for ima@ietf.org; Fri, 26 Jan 2007 14:42:21 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAWxe-0001BT-Rc for ima@ietf.org; Fri, 26 Jan 2007 20:42:10 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 20:42:10 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 20:42:10 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Date: 26 Jan 2007 21:42:02 +0200 Lines: 31 Message-ID: <5d64at1sol.fsf@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <218EF4FA0A1BFDB033AF0651@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Ted Hardie writes in gmane.ietf.ima: > >It is an elementary design principle that such > >situations are best avoided. In the email case, that principle > >is backed up by a huge amount of nasty experience that shows us > >that, even if clear precedence is defined between the two > >information locations, implementations(deliberately or > >accidentally) get it wrong. The "Errors-to" header, which is > >needed for some systems that do not use SMTP envelopes or the > >equivalent, used to be a major example of this problem. > > It's hard to argue with that experience, but it does seem like > a precedence *could* be established. If you have access to the > SMTP transport this header is ignored; if you don't the header is > honored. > > Note: no hats on; just trying to understand the design space > and constraints. > Ted And actually there is header field which correspond to "Errors-to". Return-Path -header field is standard. Trick is that it is valid only when mail is not on SMTP environment. Is similar structure needed on here? / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 15:29:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXgu-00067w-0Z; Fri, 26 Jan 2007 15:28:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXgt-000672-2R for ima@ietf.org; Fri, 26 Jan 2007 15:28:55 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAXgr-0001Ca-PS for ima@ietf.org; Fri, 26 Jan 2007 15:28:55 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAXgk-0006ON-Ui for ima@ietf.org; Fri, 26 Jan 2007 21:28:47 +0100 Received: from d254130.dialin.hansenet.de ([80.171.254.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 21:28:46 +0100 Received: from nobody by d254130.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 21:28:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 26 Jan 2007 21:23:07 +0100 Organization: Lines: 20 Message-ID: <45BA632B.45A9@xyzzy.claranet.de> References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> <928640D60C755353E508511D@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254130.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [EAI] Re: for8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Tony Finch wrote: >> FWIW, if I recall, the text in 2821 was rather carefully written >> to permit additional trace header types to be added. > However the syntax for trace fields in 2822 is not extensible. RFC 2822 refers to RFC 2821 for a "full discussion". RFC 2822 also says that they are strictly informational for its own purposes (the Internet Message Format), e.g. in RFC 3834 that's not the case. And there is an additional trace header field defined in RFC 4408. IMO ugly like hell, but registered as 3864 "permanent header field". DKIM-base defines the second new trace header field since RFC 822. In the 2822upd-00 draft it's clearer that defining new trace header fields is allowed. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 15:38:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXpV-0001Rh-Uv; Fri, 26 Jan 2007 15:37:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAXpU-0001RY-KU for ima@ietf.org; Fri, 26 Jan 2007 15:37:48 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAXpT-0002Ns-Bp for ima@ietf.org; Fri, 26 Jan 2007 15:37:48 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HAXpE-000Na8-8D; Fri, 26 Jan 2007 15:37:32 -0500 Date: Fri, 26 Jan 2007 15:37:31 -0500 From: John C Klensin To: Tony Finch Subject: Re: [EAI] Re: for8 Message-ID: <602563DA7DB29011799BF802@p3.JCK.COM> In-Reply-To: References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> <928640D60C755353E508511D@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Randall Gellens , Frank Ellermann , Chris Newman , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 26 January, 2007 19:14 +0000 Tony Finch wrote: > On Fri, 26 Jan 2007, John C Klensin wrote: >> >> FWIW, if I recall, the text in 2821 was rather carefully >> written to permit additional trace header types to be added. > > However the syntax for trace fields in 2822 is not extensible. Shame on Pete :-(. If that is the case, belongs on the list of things in 2822 that need fixing to align it with 2821. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 15:50:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAY1h-00011K-18; Fri, 26 Jan 2007 15:50:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAY1g-00011E-C4 for ima@ietf.org; Fri, 26 Jan 2007 15:50:24 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAY1c-0004M1-Fx for ima@ietf.org; Fri, 26 Jan 2007 15:50:24 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3*clerew&man^ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45ba698a.155d8.d for ima@ietf.org; Fri, 26 Jan 2007 20:50:18 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0QKoF6T024473 for ; Fri, 26 Jan 2007 20:50:16 GMT To: IMA Subject: Re: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft)) References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <66B5502F24092DF658DA31DF@p3.JCK.COM> Message-ID: Date: Fri, 26 Jan 2007 20:50:14 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <66B5502F24092DF658DA31DF@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 26 Jan 2007 16:46:45 -0000, John C Klensin wrote: > --On Friday, 19 January, 2007 14:28 +0000 Charles Lindsey > wrote: >> >> No worse that writing Content-Transfer-Encoding: 8bit when >> 7bit would have done. > > I disagree, and this is, IMO, fairly fundamental. > Content-Transfer-Encoding must exist as a header. The reasons > for that are well established -- MIME doesn't work without it > and systems that process MIME must be prepared for it and to > process it. What is being proposed here is to _add_ a new > header. Creating a new header, standardizing it, getting it > implemented and deployed -- all have costs, and those costs are > significant. You miss my point. If absent, the C-T-E defaults to 7bit, so it is not always required. However, for systems that routinely generate 8bit stuff, there is always a temptation to put in C-T-E: 8bit every time, without checking whether the particular message actually requires it. Likewise, there will be a temptation to write Header-Type: UTF8 even if the message happens to be pure ASCII. In both cases it is bad practice, because it may cause intermediate agents to do sxtra unnecessary work; nevertheless, it will cause no visible external harm. As for creating new headers, we are already proposing to create two other new headers, and of those "Downgraded:" is going to cause problems if ASCII-only MTAs fail to transmit it. The loss of a Header-Type: in an ASCII-only MTA is a nuisance, but not a show stopper (because it can only say "downgraded" or "ASCII" in that context). > --On Thursday, 21 December, 2006 17:41 +0000 Charles Lindsey > wrote: > >> AFAIAC, the Header-Type header field is VITAL, for the >> following reasons: >> >> 1. It is the only way to tell that a message is UTF8SMTP in >> the case where the transport mechanism is _not_ SMTP (a >> situation which the draft now claims to allow). > > Allowing a non-SMTP transport is different from an assertion > that all of the possible real or imaginary needs of non-SMTP > transports are satisfied. We have a long history of saying > that, if we are carrying information in the SMTP envelope that > some other transport environment needs to have in headers (or > elsewhere), perhaps because it doesn't have an envelope, then it > is the responsibility of the protocol specification for the > other transport system to specify where to put the information > and how to get it there. The fact that some other mail system > might require this header, or a header specifying the location > of the nearest Chinese restaurant, does not make it a > requirement for this specification or document. It has always been the case that the format of Internet Mail Messages has been standardized separately from the transport mechanism(s), so that the various agents involved don't have to worry about different formats in different contexts. What we have done, primarily, is to invent a new message format (a superset of the old one), by writing an extension to RFC 2822. It is necessary to be able to tell whether a given message is an extended message or not, because numerous other agents will need to know, and it is ridiculous to suggest that every mechanism that handles mail should invent its own out-of-band machinery to solve (in a different way) a problem that is going to affect most of them. And it is not sufficient to say that they can always do an exhautive scan through the whole message in order to find out, because that is not a simple task (Hint: it does not suffice merely to check for the absence of a bit8 anywhere, it involves a recursive descent through the MIME structure to do it properly). Common problems are most easily dealt with by common solutions. Moreover, you are making a basic assumption that every transport mechanism will need to be redefined so as to handle UTF8SMTP messages, and that therefore it can be provided with the necessary mechanisms to transport this essential extra bit of information at the same time. That is simply not true. There are existing transport mechanisms (UUCP and NNTP for a start) that are quite capable of handling extended UFT8SMTP messages as they stand. It would be ridiculous to require them to be upgraded just because we had invented a new format that was not self-identifying. >> 2. Even when the transport mechanism _is_ SMTP, you cannot >> tell in the case where all the addresses are in pure ASCII; >> there could still be Subject and other headers with UTF8 in >> them, and there could be embedded MIME objects with UTF8 in >> their headers (e.g. message/rfc822 or filenames in >> Content-Disposition). It would need an SMTP parameter such as >> BODY-UTF8SMTP to indicate that. > > It is fundamental to SMTP that accepting a message involves > accepting responsibility for that message on behalf of all > downstream systems. The strongest manifestation of that > principle is the rule that message-acceptance must be taken > seriously with messages thereafter being either delivered or > rejected in some way, not accidentally or deliberately lost. In > essence, the SMTP extension model simply extends the principle > to say that, if one accepts, or agrees to accept, a message with > a certain set of capabilities, one is taking the same > responsibilities as one had under 821 (and earlier) for > accepting the message itself. > > The EAI model essentially provides that, No it doesn't, because our smtpext document provides no way to indicate, in the envelope, that a given message is an extended UTF8SMTP one. > Also please remember that 2822 and its predecessors have a > strong bias against needing headers to be in a specific order. > If header reordering causes the "header-type" to show up after > the fields that it is supposed to protect one from, then one > needs to be able to parse, and possibly process, those fields > without whatever information "header-type" would provide. One > could avoid that problem by scanning all headers for > "header-type" before doing anything else, but that does > considerable violence to both 2822 and to the way many > contemporary MUA and delivery MTA implementations are written. There was a time when a single pass through the headers was all that could be tolerated. With modern computers, with vastly greater amounts of storage available, it is no problem at all to read in the full set of headers into a suitable internal structure before starting to process the message, and AIUI that is quite commonly done. >> 3. Once a message has passed "final delivery" (whatever that >> is), the SMTP information is no longer available, but you may >> still need to know whether it is a UTF8SMTP message. Even if >> IMAP and POP3 contrive to keep this information somehow, they >> are not the only storage mechanisms in use; for example, good >> ol' mbox format is still around, and has no other way to store >> that information. > > There is a long history of special headers, flags, and similar > information being kept with the stored form of a message. Resulting in repeated reinvention of the same wheels. Since this particular piece of information needs to accompany the message throughout the whole of its travels, it is much easier to incorporate it within the format of the message. It is clearly a protocol requirement that it be present at all stages somehow. Once it is there, then if it saves the invention of further special headers and flags that is an added bonus. Storage and other agents don't _have_ to use it, but if it is there anyway, they probably will. >> 4. You NEED that information before you can gateway the >> message to some other medium (gatewaying is always dificult in >> the general case, and the other medium may or may not require >> some downgrade, and even if it doesn't it may need to know so >> that it in turn can gateway it on to something else). > > You have not demonstrated that the information in the envelope > and the associated constraints are insufficient. Nothing in the > work of this WG prevents you from creating a header (or > equivalent) in the gateway to the other environment. Creating the information within the gateway is not the problem. Ensuring that the gateway has access to the information in the first place is. > > This is not a separate issue; it is just a different way to > restart (1). Indeed, (1) is the fundamental issue. If it is once solved there, then all the rest fall into place. >> 5. You NEED that information before you can Resend the message >> (or maybe even forward it, or encapsulate it as a >> message/rfc822 within something else). > > MUA problem, outside the scope of these specs or this WG. Just as with gateways, MUAs NEED that information, and ensuring that it is available to them is most certainly within the scope of this WG. What the MUA does with it then is, of course, its own business. > If > the MUA doesn't know what it is handling before trying to do > some of those things, it is in bad trouble. Precisely. So how is it supposed to know? >> 6. Your MUA may NEED that information before it can display it >> (e.g. does it need to upgrade it first?), or else you NEED it >> in order to determine whether it requires to be downgraded >> before submission to the MUA, or even whether it needs to be >> upgraded first. > > This appears to me to be just a variation on (3). True. >> 7. You NEED that information if the message has been >> DKIM-Signed, so you can either upgrade it before checking the >> signature, or else report "Sorry! This signature cannot be >> verified because of downgrading". > > Anything that changes the format or content of the headers of a > message is going to pose a challenge for DKIM and anything else > that depends on integrity validation of headers. If I were > inclined to depend on DKIM to get a message some kind of > preferential treatment, I'd probably be very sure that I didn't > supply an ALT-Address Unfortunately, you don't get to choose that. DKIM signing is likely to be done by the MSA, with or without your knowledge or approval (yes, DKIM is a can of worms and there seems to be no coherent strategy how to use it :-( ). I think as it is currently specified, it will work OK on a message that is UTF8SMTP and remains in a UTF8SMTP environment (even if alt-addresses happen to be in some headers). But with downgraded messages it gets, shall we say, "interesting". > Then I would go to the DKIM WG and say "look, there are going to > be messages with UTF-8-containing envelopes and headers floating > around the Internet, and some of it may involve downgrading, do > we need to adjust the DKIM machinery to deal better with that > situation?". Too late. The DKIM-base is in the very last stages of being published as a standards-track RFC. They take the view that they comply with all the current email standards, and that if there is a bunch of people inventing some extension of those standards, then it is up to that bunch of people to fix the problem. > And, yes, there are reason why the work should be > done there, rather than here. At least two of them are: (i) > They know the constraints and exceptions they need to have to > make a DKIM signature work, and are capable of changing them if > needed. We don't and can't. Sadly, they don't and can't either. >> Note that there is a feature in DKIM whereby you can say, in >> the signature, "here is how such-and-such a header was at the >> point where it was signed". And using that feature, I can just about see a method whereby downgraded messages MIGHT be handled through DKIM. But even if that turned out to be infeasible, it would at least enable the situation to be recognized when it occurred. The least we can do at the moment is to leave that possibility open. > I think this proves the point I am trying to make above. > Specifying the interactions between DKIM and downgraded i18n > messages is a DKIM problem. Then you go and try to convince them of that. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 15:50:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAY24-0001aP-W6; Fri, 26 Jan 2007 15:50:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAY1r-0001EK-EC; Fri, 26 Jan 2007 15:50:35 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HAY1o-0000wL-Od; Fri, 26 Jan 2007 15:50:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id AA9DD2ACC4; Fri, 26 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HAY1K-0004O0-F4; Fri, 26 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 26 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-pop-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : POP3 Support for UTF-8 Author(s) : C. Newman Filename : draft-ietf-eai-pop-01.txt Pages : 16 Date : 2007-1-26 This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, mail addresses, message headers, and protocol-level textual error strings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-pop-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-pop-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-pop-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-26110812.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-pop-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-pop-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-26110812.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Fri Jan 26 16:26:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAYaY-0003pY-7n; Fri, 26 Jan 2007 16:26:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAYaX-0003pT-23 for ima@ietf.org; Fri, 26 Jan 2007 16:26:25 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAYaV-0001mD-OC for ima@ietf.org; Fri, 26 Jan 2007 16:26:25 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAYZz-0005yY-JD for ima@ietf.org; Fri, 26 Jan 2007 22:25:51 +0100 Received: from d254130.dialin.hansenet.de ([80.171.254.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 22:25:51 +0100 Received: from nobody by d254130.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 26 Jan 2007 22:25:51 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Fri, 26 Jan 2007 22:17:31 +0100 Organization: Lines: 35 Message-ID: <45BA6FEB.3201@xyzzy.claranet.de> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <218EF4FA0A1BFDB033AF0651@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254130.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [EAI] mail2news and other gateways (was: CONSENSUS CALL: Removal of Header-Format: marker) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > The thing that all of those cases and scenarios have in common > is that they point to this being a Netnews and/or Netnews <-> > SMTP/Internet gateway problem, not an EAI problem. The USEFOR draft states that netnews is a kind of subset of the Internet Message format as defined in RFC 2822, and IIRC one of the MIME RFCs claims that netnews is a subset of message/rfc822. The USEFOR WG apparently intends to get rid of message/news at some point in time - Harald decided that the second WGLC wasn't an ideal time to finish it off. If USEFOR is published as RFC anybody could try to deprecate (OBSOLETE) message/news as a clerical task. It could depend on the "change controller", but IIRC Henry also wanted to get rid of it. The IANA registry is a PITA, I don't find the original registration templates for various MIME types. Allowing message/utf8smtp in netnews is a job for a USEFOR-bis. How gateways "downgrade" a message/utf8smtp to a message/rfc822 is our job (i.e. defining how to get this right). If it happens to be at a mail2news gateway there won't be many special netnews considerations, after all netnews is already "8BITMIME"-ready. Please correct me if I'm wrong, but IMO mail2news is no obstacle for UTF8SMTP, but message/rfc822 is an issue. Some weeks ago you wrote that a MIME expert you've asked said "ugh", and IIRC you said you'd write more about "MIME considerations" later (?) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 17:28:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZYS-0005hQ-Nm; Fri, 26 Jan 2007 17:28:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZYR-0005hH-BH for ima@ietf.org; Fri, 26 Jan 2007 17:28:19 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAZYQ-0003Am-06 for ima@ietf.org; Fri, 26 Jan 2007 17:28:19 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HAZYP-000OJV-3f; Fri, 26 Jan 2007 17:28:17 -0500 Date: Fri, 26 Jan 2007 17:28:16 -0500 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: for8 Message-ID: In-Reply-To: <45BA632B.45A9@xyzzy.claranet.de> References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> <928640D60C755353E508511D@p3.JCK.COM> <45BA632B.45A9@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 26 January, 2007 21:23 +0100 Frank Ellermann wrote: > Tony Finch wrote: > >>> FWIW, if I recall, the text in 2821 was rather carefully >>> written to permit additional trace header types to be added. > >> However the syntax for trace fields in 2822 is not extensible. > > RFC 2822 refers to RFC 2821 for a "full discussion". RFC 2822 > also says that they are strictly informational for its own > purposes (the Internet Message Format), e.g. in RFC 3834 > that's not the case. > > And there is an additional trace header field defined in RFC > 4408. IMO ugly like hell, but registered as 3864 "permanent > header field". > > DKIM-base defines the second new trace header field since RFC > 822. In the 2822upd-00 draft it's clearer that defining new > trace header fields is allowed. Frank, thanks for this clarification, but let me try to put one thing in perspective. Registration according to RFC 3864, even registration as "permanent" doesn't imply any special status other than "someone else is using this name, please pick something else for your next bright idea". Status and authority come from the documents or protocols to which 3864 and the registry refer, not from being listed. So, for example, a header registered by 4408 (an experimental document) implies a name that probably should not be reused, but doesn't imply that anyone needs to recognize or support that header unless they are part of the experiment. In any event, the conclusion I infer from your comments is clearly correct: we do make new trace headers, but we don't do it very often. best, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 17:52:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZvt-0002z5-8p; Fri, 26 Jan 2007 17:52:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAZvr-0002yU-NI for ima@ietf.org; Fri, 26 Jan 2007 17:52:31 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAZvp-0006ns-3C for ima@ietf.org; Fri, 26 Jan 2007 17:52:31 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HAZvo-000OSA-1v; Fri, 26 Jan 2007 17:52:28 -0500 Date: Fri, 26 Jan 2007 17:52:26 -0500 From: John C Klensin To: Charles Lindsey , IMA Subject: Re: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft)) Message-ID: <3D816681DA860388277BBD70@p3.JCK.COM> In-Reply-To: References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <66B5502F24092DF658DA31DF@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 26 January, 2007 20:50 +0000 Charles Lindsey wrote: > On Fri, 26 Jan 2007 16:46:45 -0000, John C Klensin > wrote: > >> --On Friday, 19 January, 2007 14:28 +0000 Charles Lindsey >> wrote: >>> >>> No worse that writing Content-Transfer-Encoding: 8bit when >>> 7bit would have done. >> >> I disagree, and this is, IMO, fairly fundamental. >> Content-Transfer-Encoding must exist as a header. The reasons >> for that are well established -- MIME doesn't work without it >> and systems that process MIME must be prepared for it and to >> process it. What is being proposed here is to _add_ a new >> header. Creating a new header, standardizing it, getting it >> implemented and deployed -- all have costs, and those costs >> are significant. > > You miss my point. If absent, the C-T-E defaults to 7bit, so > it is not always required. However, for systems that routinely > generate 8bit stuff, there is always a temptation to put in > C-T-E: 8bit every time, without checking whether the > particular message actually requires it. Likewise, there will > be a temptation to write Header-Type: UTF8 even if the message > happens to be pure ASCII. In both cases it is bad practice, > because it may cause intermediate agents to do sxtra > unnecessary work; nevertheless, it will cause no visible > external harm. I understood that point perfectly well. But, unless someone can depend on "Header-type: ASCII", the argument above demonstrates that the header is useless. That is not true of C-T-E, not because of "7bit", but because of "Base64" and "Q-P", both of which are, after all, 7bit and hence not definitively detectable by a simple, non-heuristic scan. > As for creating new headers, we are already proposing to > create two other new headers, and of those "Downgraded:" is > going to cause problems if ASCII-only MTAs fail to transmit > it. The loss of a Header-Type: in an ASCII-only MTA is a > nuisance, but not a show stopper (because it can only say > "downgraded" or "ASCII" in that context). Any new header needs, IMO, strong justification. That justification hasn't been shown for Header-type and some of the arguments for it, including the above, look like arguments against it to me. The questions, IMO, are "do we need this", "does it provide information that we can't get elsewhere", and "can it be trusted and, if not, can the problem be detected if it makes any difference". If the other two header proposals don't yield satisfactory answers to those questions, you will sooner or later see someone going after them too... I assure you. >> --On Thursday, 21 December, 2006 17:41 +0000 Charles Lindsey >> wrote: >> >>> AFAIAC, the Header-Type header field is VITAL, for the >>> following reasons: >... Ok. I've read through your comments on my comments. It is clear that our perspective on what has been done in the past (and maybe even the facts) and why, and how high-performance mail servers are designed and operated, are different. We also have a difference of opinion about whether one should try to standardize someone just because one might be able to write a standard, or whether there are some things the IETF should not touch absent much more compelling demand and, apparently, different history as to what is necessary to design into a gateway to maintain robust and conforming environments on both sides. That list could probably go on. Finally, the relevant ADs are quite aware that there are loose ends wrt DKIM and i18n email. Either they will get sorted out at the right times, or the presence of DKIM signatures will be taken in practice to encourage message rejection rather than downgrading, or users (and MSAs) will end up with a choice between internationalized email and DKIM. Too bad, but pulling one or two of the inhabitants out of a can of worms (your description) in order to admire them and feed them growth hormones does not seem to me to be an appropriate obstacle to set in the path of this WG, nor am I convinced that reforming one worm with an extra header will cause all of the other worms to start crawling in the same direction. So, I don't think I am going to convince you, and I don't think you are going to convince me. Our respective positions and perspectives have now been enumerated and explained (and you have responses to your seven or eight assertions, whether you agree with them or not). I don't think continuing this discussion further is useful unless some other group of people in the WG tell us they want it. regards, john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 18:10:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAaCh-0004dH-WD; Fri, 26 Jan 2007 18:09:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAaCh-0004d7-Ed for ima@ietf.org; Fri, 26 Jan 2007 18:09:55 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAaCf-0000eR-Ui for ima@ietf.org; Fri, 26 Jan 2007 18:09:55 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAaCY-0004Z2-4i for ima@ietf.org; Sat, 27 Jan 2007 00:09:46 +0100 Received: from d254130.dialin.hansenet.de ([80.171.254.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jan 2007 00:09:46 +0100 Received: from nobody by d254130.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jan 2007 00:09:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Re: for8 Date: Sat, 27 Jan 2007 00:08:41 +0100 Organization: Lines: 30 Message-ID: <45BA89F9.765@xyzzy.claranet.de> References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> <928640D60C755353E508511D@p3.JCK.COM> <45BA632B.45A9@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254130.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > Registration according to RFC 3864, even registration as > "permanent" doesn't imply any special status other than > "someone else is using this name, please pick something > else for your next bright idea". Status and authority > come from the documents or protocols to which 3864 and the > the registry refer, not from being listed. Yes, the registration template notes the status (in the case of RFC 4408 now "experimental", the proposal was "standard") and the change controller (now "IETF", updated following the the status changes). > doesn't imply that anyone needs to recognize or support > that header unless they are part of the experiment. Yes, but of course I'm interested in such details for users wishing to participate in both experiments (EAI and SPF): Downgrading a Received-SPF header field is not as simple as "remove any 'for8'". The envelope-from= value is important (as far as this trace header field is important at all). > we do make new trace headers, but we don't do it very often. 2006-1982=24 ;-) Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Jan 26 21:35:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAdOw-0006nH-Nf; Fri, 26 Jan 2007 21:34:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAdOw-0006nC-6i for ima@ietf.org; Fri, 26 Jan 2007 21:34:46 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAdOu-0001LJ-OG for ima@ietf.org; Fri, 26 Jan 2007 21:34:46 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAdOn-0008Nk-Ot for ima@ietf.org; Sat, 27 Jan 2007 03:34:37 +0100 Received: from d254130.dialin.hansenet.de ([80.171.254.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jan 2007 03:34:37 +0100 Received: from nobody by d254130.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jan 2007 03:34:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Date: Sat, 27 Jan 2007 03:23:36 +0100 Organization: Lines: 73 Message-ID: <45BAB7A8.12D7@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d254130.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [EAI] Re: gen-art LC review: draft-ietf-eai-framework-04 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Robert Sparks wrote on the GenArt list: > what's the advantage being sought for publishing this now? Tell the world that the WG is making progress, and that NOW might be a good time for potential implementors to check that it gets the bloody details right. > What's the risk that the document plan will need to change? > (This question is motivated by the uncertainty in, for example, > the second bullet of the document plan and the running train > leading to things like the comment in the reference for [EAI-DSN]). "This document, possibly with one or more supplemental ones" should be good enough to get any RFC 2822 and MIME issues under control. > First sentence, last paragraph of 4.2: I can't parse this sentence > and am not sure enough of what it's trying to say to suggest an > alternative. Confusing 4.2 and 5.2 I found two typos in the last paragraph of 5.2: s/email storage/an email storage/ _or_ s/email storage/a mailbox/ ? s/If this done/If this is done/ The first sentence in the last paragraph of 4.2 is in fact confusing, the "presumably using UTF-8" is strange, what else, BOCU-1 ? Here's a fresh attempt: | It seems clear that the time when email local parts are | internationalized is also the time when email headers should shift | to a full internationalized form, using UTF-8 rather than ASCII as | the base character set, excluding protocol elements such as the | header field names themselves. In other words we don't want to allow a say German "f=FCr"/"von" where we now have "for"/"from", but we want to allow raw UTF-8 in phrases and unstructured header field bodies, not only in addresses. That's BTW a case of TINW, I like RFC 2047. > The SHOULD in the last paragraph of 5.2 surprised me. Would it > make sense to document in the draft why the WG decided to not make > this MUST? Beats me, was this about cases where the MDA does in fact know that the receiver is only interested in the downgraded version ? > Would it be reasonable to put document references in the bullets > at the start of 4.1, and explicitly point to 4.2 instead of saying > "the next subsection"? The latter is certainly possible with xml2rfc, something like
and > "and similarly for POP" might lose a non-native-English reader. Because there are two "similarly" in this sentence ? The latter could be replaced by (adding a comma) ", and likewise for POP3". > The first sentence of section 5.1 is quite complex. Would breaking > it into more sentences help? Adding "a" to "non-delivery message" would also help, removing the final "by some MTA in the path to the presumed destination" clause: Of course the rejecting or bouncing MTA is somewhere on *a* path to the presumed destination, otherwise it can't reject or bounce the offending UTF8SMTP mail... :-) Thanks for the review, Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 27 00:57:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAgYh-0001kP-W6; Sat, 27 Jan 2007 00:57:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAgYg-0001kH-PY for ima@ietf.org; Sat, 27 Jan 2007 00:57:02 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAgYc-0002KC-IG for ima@ietf.org; Sat, 27 Jan 2007 00:57:02 -0500 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0R5uqiK021442 for ; Fri, 26 Jan 2007 22:56:54 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCI00601J6SII00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Fri, 26 Jan 2007 22:56:52 -0700 (MST) Received: from [10.0.1.3] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCI00FM1J6P1S00@mail-amer.sun.com>; Fri, 26 Jan 2007 22:56:51 -0700 (MST) Date: Fri, 26 Jan 2007 21:57:03 -0800 From: Chris Newman Subject: Re: [EAI] CONSENSUS CALL: Header format for alt-addr In-reply-to: To: Harald Tveit Alvestrand , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I agree with this resolution. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 27 00:57:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAgZ1-0002O1-5O; Sat, 27 Jan 2007 00:57:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAgYz-0002Nt-MH for ima@ietf.org; Sat, 27 Jan 2007 00:57:21 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAgYy-0002OA-Bw for ima@ietf.org; Sat, 27 Jan 2007 00:57:21 -0500 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0R5vI1i007744 for ; Fri, 26 Jan 2007 22:57:19 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCI00E01J7I5500@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Fri, 26 Jan 2007 22:57:18 -0700 (MST) Received: from [10.0.1.3] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCI00HOGJ7FR300@mail-amer.sun.com>; Fri, 26 Jan 2007 22:57:17 -0700 (MST) Date: Fri, 26 Jan 2007 21:57:29 -0800 From: Chris Newman Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker In-reply-to: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> To: Harald Tveit Alvestrand , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I agree with this resolution. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 27 01:31:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAh5v-0001u8-34; Sat, 27 Jan 2007 01:31:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAh5t-0001qn-IO for ima@ietf.org; Sat, 27 Jan 2007 01:31:21 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAguD-00061e-4B for ima@ietf.org; Sat, 27 Jan 2007 01:19:18 -0500 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0R6JAT9002349 for ; Fri, 26 Jan 2007 23:19:12 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCI00E01K3PFW00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Fri, 26 Jan 2007 23:19:10 -0700 (MST) Received: from [10.0.1.3] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCI00HOPK7VR300@mail-amer.sun.com>; Fri, 26 Jan 2007 23:19:10 -0700 (MST) Date: Fri, 26 Jan 2007 22:19:22 -0800 From: Chris Newman Subject: Re: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft)) In-reply-to: <3D816681DA860388277BBD70@p3.JCK.COM> To: John C Klensin , Charles Lindsey , IMA Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <66B5502F24092DF658DA31DF@p3.JCK.COM> <3D816681DA860388277BBD70@p3.JCK.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote on 1/26/07 17:52 -0500: >> You miss my point. If absent, the C-T-E defaults to 7bit, so >> it is not always required. However, for systems that routinely >> generate 8bit stuff, there is always a temptation to put in >> C-T-E: 8bit every time, without checking whether the >> particular message actually requires it. Likewise, there will >> be a temptation to write Header-Type: UTF8 even if the message >> happens to be pure ASCII. In both cases it is bad practice, >> because it may cause intermediate agents to do sxtra >> unnecessary work; nevertheless, it will cause no visible >> external harm. > > I understood that point perfectly well. But, unless someone can > depend on "Header-type: ASCII", the argument above demonstrates > that the header is useless. That is not true of C-T-E, not > because of "7bit", but because of "Base64" and "Q-P", both of > which are, after all, 7bit and hence not definitively detectable > by a simple, non-heuristic scan. At the time MIME was designed, computer systems were much more limited and the cost of scanning the message to determine its type was more expensive than the cost of the silly states. Today it is common practice for every MTA to scan every message (sometimes multiple times). Whether it's for spam, virus, DKIM signatures, a Sieve body or loop action, IMAP mailstore insertion, mailstore search indexing or various other reasons, we routinely scan the entire message. Given that, the cost of the extra code paths to deal with the header parsing and silly states is more expensive than the cost of scanning the message (because scanning the message is a sunk cost). If MIME were designed today, I would replace "7bit", "8bit" and "binary" with a single "identity" label and I'd certainly ignore the distinction between those three labels in any robust MIME processing agent I was writing today. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 27 01:33:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAh7y-0002Lm-Ix; Sat, 27 Jan 2007 01:33:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAh7x-0002Le-Jz for ima@ietf.org; Sat, 27 Jan 2007 01:33:29 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAh7r-0008Ps-W8 for ima@ietf.org; Sat, 27 Jan 2007 01:33:29 -0500 Received: (snipe 28064 invoked by uid 0); 27 Jan 2007 15:35:40 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.077814 secs); Received: from unknown (HELO ?192.168.10.206?) (Z???own@218.36.241.169) by unknown with SMTP; 27 Jan 2007 15:35:40 +0900 X-SNIPER-SENDERIP: 218.36.241.169 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: harald@alvestrand.no, ima@ietf.org, yangwooko@gmail.com Message-ID: <45BAF22E.5050102@icu.ac.kr> Date: Sat, 27 Jan 2007 15:33:18 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> In-Reply-To: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: > > The discussion of whether or not we need a header marker for marking > UTF8SMTP messages that actually use UTF-8 characters has reached a point > where it seems that no new technical information is being provided. > > At this point, the chairs wish to see if the group is near a possible > consensus on the issue. > > PROPOSED RESOLUTOIN: > > There is no significant operational or implementation benefit in having > a marker in the headers of UTF8SMTP messages, and significant additional > complexity. Therefore, the proposed "Header-Type" section, > draft-ietf-eai-utf8headers-02 section 5, will be removed. > > Note that this is not a call on the proposal to have a similar marker in > the SMTP protocol; that's a separate issue. > > POSSIBLE RESPONSES: > > 1. I agree with this resolution +1 This header may provide some optimization if all required conditions (e.g. no liars and so on) are met. But, expected improvement seems marginal while (also quite naturally) expected problems are a lot more overwhelming. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 27 01:36:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAhB4-0004lL-3m; Sat, 27 Jan 2007 01:36:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAhB2-0004hZ-5w for ima@ietf.org; Sat, 27 Jan 2007 01:36:40 -0500 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAhB0-0000Ro-Ib for ima@ietf.org; Sat, 27 Jan 2007 01:36:40 -0500 Received: (snipe 28746 invoked by uid 0); 27 Jan 2007 15:38:55 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.076149 secs); Received: from unknown (HELO ?192.168.10.206?) (Z???own@218.36.241.169) by unknown with SMTP; 27 Jan 2007 15:38:55 +0900 X-SNIPER-SENDERIP: 218.36.241.169 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: harald@alvestrand.no, ima@ietf.org, yangwooko@gmail.com Message-ID: <45BAF2F0.9010509@icu.ac.kr> Date: Sat, 27 Jan 2007 15:36:32 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [EAI] CONSENSUS CALL: Header format for alt-addr References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: > > I think it's time we settled the issue of the format of email addresses > in UTF8SMTP headers for this round. > > PROPOSED RESOLUTION: > > The representation of an internationalized email address with an > alternate ASCII address in an UTF8SMTP message is > > > > > A pure EAI address and a pure ASCII address are both encoded without the > extra field: as . > Details of ABNF to be worked out after a draft with this syntax has been > emitted. > > POSSIBLE RESPONSES: > > 1. I agree with this resolution +1 I like recycling <> _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 27 01:53:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAhRS-0004fj-Pg; Sat, 27 Jan 2007 01:53:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAhRR-0004fe-NL for ima@ietf.org; Sat, 27 Jan 2007 01:53:37 -0500 Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAhRQ-0002cL-AR for ima@ietf.org; Sat, 27 Jan 2007 01:53:37 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id l0R6rDqq030725; Fri, 26 Jan 2007 22:53:13 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id l0R6rCe0030722; Fri, 26 Jan 2007 22:53:13 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 26 Jan 2007 22:53:12 -0800 (PST) From: "william(at)elan.net" To: Yangwoo Ko Subject: Re: [EAI] CONSENSUS CALL: Header format for alt-addr In-Reply-To: <45BAF2F0.9010509@icu.ac.kr> Message-ID: References: <45BAF2F0.9010509@icu.ac.kr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 27 Jan 2007, Yangwoo Ko wrote: > Harald Tveit Alvestrand wrote: >> >> I think it's time we settled the issue of the format of email addresses in >> UTF8SMTP headers for this round. >> >> PROPOSED RESOLUTION: >> >> The representation of an internationalized email address with an alternate >> ASCII address in an UTF8SMTP message is >> >> > >> >> A pure EAI address and a pure ASCII address are both encoded without the >> extra field: as . >> Details of ABNF to be worked out after a draft with this syntax has been >> emitted. >> >> POSSIBLE RESPONSES: >> >> 1. I agree with this resolution > > +1 > > I like recycling <> I like it too. One possible issue is all those scripts designed to process emails and extra address from From field. Its kind of both good and bad - on one side we may want those old scripts to still work and reliably get ascii address (that its UTF8 maybe less of an issue, libraries and interpreters like perl take care of conversions and allow strings to be either ascii or utf8). On the other hand we may purpose want those scripts to fail since its a new type of address. -- William Leibzon Elan Networks william@elan.net _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 27 02:06:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAhe1-0003u2-1V; Sat, 27 Jan 2007 02:06:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAhdz-0003tr-3z for ima@ietf.org; Sat, 27 Jan 2007 02:06:35 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAhdx-00048w-L2 for ima@ietf.org; Sat, 27 Jan 2007 02:06:35 -0500 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0R76TBO022952 for ; Sat, 27 Jan 2007 00:06:31 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCI00E01LIEVD00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Sat, 27 Jan 2007 00:06:29 -0700 (MST) Received: from [10.0.1.3] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCI00HP8MERR300@mail-amer.sun.com>; Sat, 27 Jan 2007 00:06:29 -0700 (MST) Date: Fri, 26 Jan 2007 23:06:41 -0800 From: Chris Newman Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker In-reply-to: To: Charles Lindsey , IMA Message-id: <0EC11DC943D20065F77334C3@[10.0.1.3]> MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote on 1/26/07 17:44 +0000: > I gave these reasons on December 21st, and nobody has commented on my > objections. I repeat below what I wrote then: > > AFAIAC, the Header-Type header field is VITAL, for the following reasons: > > 1. It is the only way to tell that a message is UTF8SMTP in the case where > the > transport mechanism is _not_ SMTP (a situation which the draft now claims to > allow). The _only_ way to tell if a message is a UTF8SMTP message is to scan the message and MIME headers to see if they conform to UTF8SMTP syntax. A Header-Type field does not provide that information, it merely provides a non-authoritative hint about the message type which any robust processing agent needs to ignore. > 2. Even when the transport mechanism _is_ SMTP, you cannot tell in the case > where all the addresses are in pure ASCII; there could still be Subject and > other headers with UTF8 in them, and there could be embedded MIME objects > with > UTF8 in their headers (e.g. message/rfc822 or filenames in Content- > Disposition). It would need an SMTP parameter such as BODY-UTF8SMTP to > indicate that. Same answer as statement 1. > 3. Once a message has passed "final delivery" (whatever that is), the SMTP > information is no longer available, but you may still need to know whether it > is a UTF8SMTP message. Even if IMAP and POP3 contrive to keep this > information > somehow, they are not the only storage mechanisms in use; for example, good > ol' > mbox format is still around, and has no other way to store that information. A mbox-style file which contains UTF8SMTP messages would be a different file format from today's mbox format. There are multiple ways to distinguish the two file formats, including by file extension, by out-of-band typing (e.g. MacOS creator code), by file location, or by putting a magic number at the beginning of the file (a UTF-8 BOM followed by "From " would be a good magic number for a UTF8SMTP mbox file). A final delivery agent which put a UTF8SMTP message in a vanilla mbox file would have a software bug that needs to be corrected. > 4. You NEED that information before you can gateway the message to some other > medium (gatewaying is always dificult in the general case, and the other > medium may or may not require some downgrade, and even if it doesn't it may > need to know so that it in turn can gateway it on to something else). I do not understand why a gateway would require a header containing a non-authoritative hint about the message type. A gateway can scan the headers for 8-bit content and when it sees it process that content accordingly. A robust gateway should already do this today. > 5. You NEED that information before you can Resend the message (or maybe even > forward it, or encapsulate it as a message/rfc822 within something else). This information can be gained by scanning the message and MIME headers so it is not needed. > 6. Your MUA may NEED that information before it can display it (e.g. does it > need to upgrade it first?), or else you NEED it in order to determine whether > it requires to be downgraded before submission to the MUA, or even whether it > needs to be upgraded first. An MUA can be designed so it doesn't need that information. It can also be designed such that the mailstore caches that information in an authoritative fashion, which would actually be useful, unlike a header which contained an advisory hint about the message type. > 7. You NEED that information if the message has been DKIM-Signed, so you can > either upgrade it before checking the signature, or else report "Sorry! This > signature cannot be verified because of downgrading". If upgrading is desirable, there will be some sort of Downgraded-Info trace field that can be used to detect that a downgrade occurred. Of course a DKIM signature either verifies or it doesn't. If an agent looks at something else to determine whether or not a message should be verified I can assure you spammers will quickly adopt that something else and make any sort of "can't be verified because of blah" message meaningless. So the scenario you're describing is itself a design error. > 8. It will not be possible to extend this scheme to Netnews (Usenet) without > this header, because there will be no way to know whether special attention > is needed when gatewaying an article into email (a special case of point #4. > Indeed, you would have the same problem it you tried to send email via NNTP > (which has been suggested, though I do not see how it would work myself). A robust news->email gateway should already scan the message for standards conformance and downgrade any 8-bit which appears in headers. I do not see why our specifications should be concerned with non-robust software. I have yet to see a single solid technical reason why a Header-Type field is useful. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 27 03:04:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAiXs-0007IE-E3; Sat, 27 Jan 2007 03:04:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAiXr-0007I9-4a for ima@ietf.org; Sat, 27 Jan 2007 03:04:19 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAiXp-0004Oy-MT for ima@ietf.org; Sat, 27 Jan 2007 03:04:19 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAiX7-0005LP-J0 for ima@ietf.org; Sat, 27 Jan 2007 09:03:33 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jan 2007 09:03:33 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jan 2007 09:03:33 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Content-Transfer-Encoding (Re: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft))) Date: 27 Jan 2007 10:03:00 +0200 Lines: 68 Message-ID: <5d1wlgq4ln.fsf_-_@Hurtta06k.keh.iki.fi> References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <66B5502F24092DF658DA31DF@p3.JCK.COM> <3D816681DA860388277BBD70@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Newman writes in gmane.ietf.ima: <...> > At the time MIME was designed, computer systems were much more limited > and the cost of scanning the message to determine its type was more > expensive than the cost of the silly states. Today it is common > practice for every MTA to scan every message (sometimes multiple > times). Whether it's for spam, virus, DKIM signatures, a Sieve body > or loop action, IMAP mailstore insertion, mailstore search indexing or > various other reasons, we routinely scan the entire message. Given > that, the cost of the extra code paths to deal with the header parsing > and silly states is more expensive than the cost of scanning the > message (because scanning the message is a sunk cost). > > If MIME were designed today, I would replace "7bit", "8bit" and > "binary" with a single "identity" label and I'd certainly ignore the > distinction between those three labels in any robust MIME processing > agent I was writing today. > > - Chris Someone asked is MTAs scanning messages. I looked sendmail. When sendmail does 8BITMIME downgrading, I was quessing that it selects, which subparts to downgrade, by looking content-transfer-encoding. That was not true. Instead it scans subparts twice (mime.c): /* remember where we were */ offset = sm_io_tell(e->e_dfp, SM_TIME_DEFAULT); if (offset == -1) syserr("mime8to7: cannot sm_io_tell on %cf%s", DATAFL_LETTER, e->e_id); /* do a scan of this body type to count character types */ while (sm_io_fgets(e->e_dfp, SM_TIME_DEFAULT, buf, sizeof buf) != NULL) { if (mimeboundary(buf, boundaries) != MBT_NOTSEP) break; for (p = buf; *p != '\0'; p++) { /* count bytes with the high bit set */ sectionsize++; if (bitset(0200, *p)) sectionhighbits++; } /* ** Heuristic: if 1/4 of the first 4K bytes are 8-bit, ** assume base64. This heuristic avoids double-reading ** large graphics or video files. */ if (sectionsize >= 4096 && sectionhighbits > sectionsize / 4) break; } That scanning is done so that sendmail is can do smart selection between quoted-printable and base64. So it may be that Content-Transfer-Encoding with values 7bit, 8bit, binary is just used as identity. Otherwise values are ignored (and scanning is done instead.) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 27 04:24:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAjnP-0006sU-8M; Sat, 27 Jan 2007 04:24:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAjnO-0006nP-8E for ima@ietf.org; Sat, 27 Jan 2007 04:24:26 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAjnM-0001A0-Pw for ima@ietf.org; Sat, 27 Jan 2007 04:24:26 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAjnC-0006yz-BC for ima@ietf.org; Sat, 27 Jan 2007 10:24:14 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jan 2007 10:24:14 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jan 2007 10:24:14 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) Date: 27 Jan 2007 11:24:06 +0200 Lines: 64 Message-ID: <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes in gmane.ietf.ima: > Harald Tveit Alvestrand writes in gmane.ietf.ima: > > > The discussion of whether or not we need a header marker for marking > > UTF8SMTP messages that actually use UTF-8 characters has reached a > > point where it seems that no new technical information is being > > provided. > > > > At this point, the chairs wish to see if the group is near a possible > > consensus on the issue. > > > > PROPOSED RESOLUTOIN: > > > > There is no significant operational or implementation benefit in > > having a marker in the headers of UTF8SMTP messages, and significant > > additional complexity. Therefore, the proposed "Header-Type" section, > > draft-ietf-eai-utf8headers-02 section 5, will be removed. > > > > Note that this is not a call on the proposal to have a similar marker > > in the SMTP protocol; that's a separate issue. > > I can not decide yet. Specially removal of > > Header-Format: Downgraded > > marker. > > > For > Header-Format: UTF8 > > I prefer marker on outside of headers. Seems that parsing of MIME structure by every MTA on path is quite common. So when MIME structure is parsed anyway, that UTF8 indicator is not needed. So question is, do we want upgrading of downgraded header fields. If that is wanted, Header-Format: Downgraded and Header-Format: Original can be used. Without Header-Format: Downgraded heade ffiled upgrading must not be done. I think automatic 'upgrading' always does too much damage. For connecting isolated UTF8SMTP islands I have suggested encapsulation -- drawback is that this requires manual configuration for tunnel -- it is not automatic. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 27 04:37:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAk0E-0004cG-7A; Sat, 27 Jan 2007 04:37:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAk0D-0004Yx-Cu for ima@ietf.org; Sat, 27 Jan 2007 04:37:41 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAk0C-0003UP-3c for ima@ietf.org; Sat, 27 Jan 2007 04:37:41 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAk03-0008Jm-4m for ima@ietf.org; Sat, 27 Jan 2007 10:37:31 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jan 2007 10:37:31 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jan 2007 10:37:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Date: 27 Jan 2007 11:37:19 +0200 Lines: 27 Message-ID: <5d7iv8zu7k.fsf@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand writes in gmane.ietf.ima: > The discussion of whether or not we need a header marker for marking > UTF8SMTP messages that actually use UTF-8 characters has reached a > point where it seems that no new technical information is being > provided. > > At this point, the chairs wish to see if the group is near a possible > consensus on the issue. > > PROPOSED RESOLUTOIN: > > There is no significant operational or implementation benefit in > having a marker in the headers of UTF8SMTP messages, and significant > additional complexity. Therefore, the proposed "Header-Type" section, > draft-ietf-eai-utf8headers-02 section 5, will be removed. > > Note that this is not a call on the proposal to have a similar marker > in the SMTP protocol; that's a separate issue. > 1. I agree with this resolution This means also that upgrading of UTF8SMTP downgraded messages is NOT done. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 27 04:49:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAkBE-0002CX-ND; Sat, 27 Jan 2007 04:49:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAkBC-0002CQ-US for ima@ietf.org; Sat, 27 Jan 2007 04:49:02 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAkBB-0004UU-Kr for ima@ietf.org; Sat, 27 Jan 2007 04:49:02 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAkB6-00011f-8u for ima@ietf.org; Sat, 27 Jan 2007 10:48:56 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jan 2007 10:48:56 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jan 2007 10:48:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: required-fields (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) Date: 27 Jan 2007 11:48:50 +0200 Lines: 35 Message-ID: <5dd550by0t.fsf_-_@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d7iv8zu7k.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes in gmane.ietf.ima: > Harald Tveit Alvestrand writes in gmane.ietf.ima: > > > The discussion of whether or not we need a header marker for marking > > UTF8SMTP messages that actually use UTF-8 characters has reached a > > point where it seems that no new technical information is being > > provided. > > > > At this point, the chairs wish to see if the group is near a possible > > consensus on the issue. > > > > PROPOSED RESOLUTOIN: > > > > There is no significant operational or implementation benefit in > > having a marker in the headers of UTF8SMTP messages, and significant > > additional complexity. Therefore, the proposed "Header-Type" section, > > draft-ietf-eai-utf8headers-02 section 5, will be removed. > > > > Note that this is not a call on the proposal to have a similar marker > > in the SMTP protocol; that's a separate issue. > > > > 1. I agree with this resolution > > This means also that upgrading of UTF8SMTP downgraded messages > is NOT done. In past I was suggested required-fields paramater Header-Type header fields. That was added to draft-ietf-eai-utf8headers-02. When Header-Type is removed, I will suggest "UTF8-required-fields" header field to draft-ietf-eai-utf8headers instead. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 27 11:05:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAq2l-0003nh-KE; Sat, 27 Jan 2007 11:04:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAq2l-0003lE-46 for ima@ietf.org; Sat, 27 Jan 2007 11:04:43 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAq2f-0003IK-Qx for ima@ietf.org; Sat, 27 Jan 2007 11:04:43 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HAq2M-0007gX-9Z for ima@ietf.org; Sat, 27 Jan 2007 17:04:18 +0100 Received: from 212.82.251.85 ([212.82.251.85]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jan 2007 17:04:18 +0100 Received: from nobody by 212.82.251.85 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 27 Jan 2007 17:04:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: mbox & digests (was: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) Date: Sat, 27 Jan 2007 17:02:32 +0100 Organization: Lines: 19 Message-ID: <45BB7797.2F3A@xyzzy.claranet.de> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <0EC11DC943D20065F77334C3@[10.0.1.3]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.85 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Newman wrote: > A mbox-style file which contains UTF8SMTP messages would be a different > file format from today's mbox format. There are multiple ways to > distinguish the two file formats, including by file extension, [...] > A final delivery agent which put a UTF8SMTP message in a vanilla mbox > file would have a software bug that needs to be corrected. Yes, and that's an important statement, we've to make sure that the affected drafts (e.g., maybe the mailinglist I-D wrt "digest mode") clearly say so. Another example is a Web mail interface I've used, it allowed to download selected messages, and used a simple variant of the mbox- format, not MIME multipart/digest. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Jan 27 11:38:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAqZq-0003aO-CF; Sat, 27 Jan 2007 11:38:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAqZo-0003a3-P0 for ima@ietf.org; Sat, 27 Jan 2007 11:38:52 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAqZn-0001sS-Bp for ima@ietf.org; Sat, 27 Jan 2007 11:38:52 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HAqZi-0005kz-Vk; Sat, 27 Jan 2007 11:38:47 -0500 Date: Sat, 27 Jan 2007 11:38:46 -0500 From: John C Klensin To: Chris Newman , Charles Lindsey , IMA Subject: Re: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft)) Message-ID: <57ACEF55BFEC77C25C94A683@p3.JCK.COM> In-Reply-To: References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <66B5502F24092DF658DA31DF@p3.JCK.COM> <3D816681DA860388277BBD70@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Friday, 26 January, 2007 22:19 -0800 Chris Newman wrote: >> I understood that point perfectly well. But, unless someone >> can depend on "Header-type: ASCII", the argument above >> demonstrates that the header is useless. That is not true >> of C-T-E, not because of "7bit", but because of "Base64" and >> "Q-P", both of which are, after all, 7bit and hence not >> definitively detectable by a simple, non-heuristic scan. > > At the time MIME was designed, computer systems were much more > limited and the cost of scanning the message to determine its > type was more expensive than the cost of the silly states. > Today it is common practice for every MTA to scan every > message (sometimes multiple times). Whether it's for spam, > virus, DKIM signatures, a Sieve body or loop action, IMAP > mailstore insertion, mailstore search indexing or various > other reasons, we routinely scan the entire message. Given > that, the cost of the extra code paths to deal with the header > parsing and silly states is more expensive than the cost of > scanning the message (because scanning the message is a sunk > cost). > > If MIME were designed today, I would replace "7bit", "8bit" > and "binary" with a single "identity" label and I'd certainly > ignore the distinction between those three labels in any > robust MIME processing agent I was writing today. Chris, I can certainly understand your removing the distinction between "7bit" and "8bit", and maybe between "8bit" and "binary", but it is not clear to my how you would definitively determine the difference between "7bit" and the two downgrade encodings ("Base64" and "Quoted-printable"). If what you decided by heuristic scan was different from what the label indicated, you'd be faced with a choice that was discussed during the MIME work -- which to believe and the possibility that the sender intended to transmit the apparently-encoded form as a message, intending that it not be decoded. Or am I missing something? john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jan 28 12:14:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBDbR-00044l-3O; Sun, 28 Jan 2007 12:14:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBDbP-00044g-Jl for ima@ietf.org; Sun, 28 Jan 2007 12:14:03 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBDbH-00032T-4S for ima@ietf.org; Sun, 28 Jan 2007 12:14:03 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3^clerew#man#ac$uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45bcd9c7.1312e.14 for ima@ietf.org; Sun, 28 Jan 2007 17:13:43 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0SHDgI3004474 for ; Sun, 28 Jan 2007 17:13:43 GMT To: IMA Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> Message-ID: Date: Sun, 28 Jan 2007 17:13:41 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 26 Jan 2007 17:44:27 -0000, Charles Lindsey wrote: >> POSSIBLE RESPONSES: >> >> 1. I agree with this resolution >> 2. I disagree with this resolution, for the following technical reasons: >> 3. I have another opinion, which is: > > I disagree with this resolution, for the following technical reasons: > > And, on top of all those reasons, I would add: > > 8. ... And here is another addition: 9. If you remove the Header-Type header, as currently defined, then you will need to invent a Header-Language header, since AIUI it is an IESG requirement that wherever you specify the use of a non-ASCII charset you have to have also a means to specify the language which is using that charset. The existing Content-Languags header is a model of what would be required. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jan 28 12:48:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBE8S-0003q9-7L; Sun, 28 Jan 2007 12:48:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBE8Q-0003q1-P0 for ima@ietf.org; Sun, 28 Jan 2007 12:48:10 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBE8M-0006GS-5I for ima@ietf.org; Sun, 28 Jan 2007 12:48:10 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3*clerew^man#ac#uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45bce1d4.fdbd.2f for ima@ietf.org; Sun, 28 Jan 2007 17:48:04 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0SHm3AQ006774 for ; Sun, 28 Jan 2007 17:48:04 GMT Date: Sun, 28 Jan 2007 17:48:03 -0000 To: IMA Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <218EF4FA0A1BFDB033AF0651@p3.JCK.COM> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 26 Jan 2007 19:30:12 -0000, Ted Hardie wrote: > While I'm generally sympathetic to the idea that you shouldn't > set up protocols that are liable to silly states, I do have some > questions here. The first is how many different gateway types > we're actually likely to need here. With a single type > (mail-to-news), it's pretty obvious that you can put the logic > on either side of the gateway provided you have any marker > at all..... The basic RFC 822 format has now been used by Netnews, HTTP and Sip (and maybe others). It will likely be used by further protocols as time goes on. If you have N protocols, then you have in principle (N-1)**2/2 gateways, not that they all necessarily make sense). Then you have mailing list expanders, which are a little like gateways too. In addition, you have gateways to/from protocols that do not use the RFC 822 format (e.g. X.400 mail and Fidonet). > There is also an issue of what happens when > the message passes through multiple gateways (imagine > some mix of mail, news, and mms a la 4356); knowing that > you'll see the same marker no matter what set of gateways a message > took to reach from originator to receiver does seem useful. But the real problem is that email (and all the others) does not always get processed by well-written software running well-defined protocols. People write all sorts of ad-hoc scripts to process mail after it has been received, or to generate it by automatic means. There will copy it from the clipboard into a file, losing all its context, and subsequently expect to be able to send to any email addresses within it, or even to forward the whole message. They will generate messages with text editors, and then telnet to some port 25 and paste the message in after the DATA command. Such people might just about be persuaded to take note of a Header-Type header if is present (or to generate it where needed). But there is no way they are going to go to the trouble of writing complete scans through the whole message into their scripts, as has been suggested. > >> It is an elementary design principle that such >> situations are best avoided. In the email case, that principle >> is backed up by a huge amount of nasty experience that shows us >> that, even if clear precedence is defined between the two >> information locations, implementations(deliberately or >> accidentally) get it wrong. The "Errors-to" header, which is >> needed for some systems that do not use SMTP envelopes or the >> equivalent, used to be a major example of this problem. The intention of this header is that it should describe (definitively - since it is a MUST generate) the status of the message in which it is contained, travelling with it wherever it goes, since it is primarily of interest to the end-points (MTAs will normally pass it on without looking, though if they care to be liberal and handle cases where it has not been correctly provided, then good luck to them). The only case where this header is of interest bwtween the end-points is where downgrading is called for. Our documents will describe very clearly the proper way to downgrade, and if it is not implemented in strict conformance with those documents, then all sorts of things are going to go wrong. > > It's hard to argue with that experience, but it does seem like > a precedence *could* be established. If you have access to the > SMTP transport this header is ignored; if you don't the header is > honored. The current proposals for the SMTP transport do not provide any mechanism to carry this information in the envelope. IMO, that is as it should be. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jan 28 14:47:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBG00-0000Gn-74; Sun, 28 Jan 2007 14:47:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBFzz-0000F1-MU for ima@ietf.org; Sun, 28 Jan 2007 14:47:35 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBFzu-0004vR-D7 for ima@ietf.org; Sun, 28 Jan 2007 14:47:35 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HBFzl-0006fs-3o for ima@ietf.org; Sun, 28 Jan 2007 20:47:21 +0100 Received: from du-017-218.access.de.clara.net ([212.82.246.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Jan 2007 20:47:21 +0100 Received: from nobody by du-017-218.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 28 Jan 2007 20:47:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Date: Sun, 28 Jan 2007 20:45:53 +0100 Organization: Lines: 18 Message-ID: <45BCFD71.6225@xyzzy.claranet.de> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-017-218.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > AIUI it is an IESG requirement that wherever you specify the use of a > non-ASCII charset you have to have also a means to specify the language > which is using that charset. The chapters 3 and 4 in RFC 2277 are completely independent. Of course language tagging / identification / negotiation isn't bound to non-ASCII. An e-mail address typically has no "language", and for anything else it is possible to use RFC 2231 chapter 5 =?charset*langtag?x?y?= words, or the weird RFC 2231 constructs for MIME parameters. Language tags for the complete header are a dubious idea, I can imagine scenarios where it depends on the header field or on single 2047-words. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jan 28 15:58:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBH6F-0006W6-A7; Sun, 28 Jan 2007 15:58:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBH6E-0006W1-FJ for ima@ietf.org; Sun, 28 Jan 2007 15:58:06 -0500 Received: from ppsw-2.csi.cam.ac.uk ([131.111.8.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBH6A-0006fR-6R for ima@ietf.org; Sun, 28 Jan 2007 15:58:06 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:40073) by ppsw-2.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.152]:25) with esmtpa (EXTERNAL:fanf2) id 1HBH5z-0002zh-6c (Exim 4.63) (return-path ); Sun, 28 Jan 2007 20:57:51 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HBH5y-0002Yl-WB (Exim 4.54) (return-path ); Sun, 28 Jan 2007 20:57:50 +0000 Date: Sun, 28 Jan 2007 20:57:50 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin Subject: Re: [EAI] Re: for8 In-Reply-To: Message-ID: References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> <928640D60C755353E508511D@p3.JCK.COM> <45BA632B.45A9@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 26 Jan 2007, John C Klensin wrote: > On Friday, 26 January, 2007 21:23 +0100 Frank Ellermann wrote: > > Tony Finch wrote: > > > >> However the syntax for trace fields in 2822 is not extensible. > > > > RFC 2822 refers to RFC 2821 for a "full discussion". I believe that's because 2821 has rather more details about Received: and Return-Path: than 2822 does. However 2822's header ABNF and the accompanying text is quite explicit about what can be a trace field. > In any event, the conclusion I infer from your comments is > clearly correct: we do make new trace headers, but we don't do > it very often. Right. As well as the ones Frank noted, 2822 also defines new trace fields (because it says that Resent- fields are trace fields which isn't the case in 822). So 2822bis needs to make them properly extensible. Tony. -- f.a.n.finch http://dotat.at/ ROCKALL MALIN: NORTHWEST 4 OR 5 BACKING WEST 5 TO 7. MODERATE OR ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jan 28 18:35:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBJY9-0005G3-Ol; Sun, 28 Jan 2007 18:35:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBJY8-0005Fy-HE for ima@ietf.org; Sun, 28 Jan 2007 18:35:04 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBJY6-0005c8-5Z for ima@ietf.org; Sun, 28 Jan 2007 18:35:04 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 016732596DE; Mon, 29 Jan 2007 00:31:04 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22300-10; Mon, 29 Jan 2007 00:30:57 +0100 (CET) Received: from [10.71.2.170] (unknown [12.108.175.130]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5DDE92596DD; Mon, 29 Jan 2007 00:30:57 +0100 (CET) Date: Mon, 29 Jan 2007 00:34:52 +0100 From: Harald Tveit Alvestrand To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Message-ID: In-Reply-To: <45BCFD71.6225@xyzzy.claranet.de> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <45BCFD71.6225@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Speaking as the author of RFC 2277: Frank is right. The need to identify language is independent of the need to allow for multiple charsets (or at least UTF-8). There are many languages written in ASCII. Section 3 of 2277 refers to "character data". Section 4 refers to "text". E-mail addresses may be many things, including being placed in text, but they are not text. --On 28. januar 2007 20:45 +0100 Frank Ellermann wrote: > Charles Lindsey wrote: > >> AIUI it is an IESG requirement that wherever you specify the use of a >> non-ASCII charset you have to have also a means to specify the language >> which is using that charset. > > The chapters 3 and 4 in RFC 2277 are completely independent. Of course > language tagging / identification / negotiation isn't bound to non-ASCII. > > An e-mail address typically has no "language", and for anything else it > is possible to use RFC 2231 chapter 5 =?charset*langtag?x?y?= words, or > the weird RFC 2231 constructs for MIME parameters. > > Language tags for the complete header are a dubious idea, I can imagine > scenarios where it depends on the header field or on single 2047-words. > > Frank > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jan 28 18:40:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBJd6-0007Sw-Mf; Sun, 28 Jan 2007 18:40:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBJd5-0007Sr-KW for ima@ietf.org; Sun, 28 Jan 2007 18:40:11 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBJd4-0007Xz-Ac for ima@ietf.org; Sun, 28 Jan 2007 18:40:11 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E77C92596DE; Mon, 29 Jan 2007 00:36:11 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23057-01; Mon, 29 Jan 2007 00:36:07 +0100 (CET) Received: from [10.71.2.170] (unknown [12.108.175.130]) by eikenes.alvestrand.no (Postfix) with ESMTP id B97E92596DD; Mon, 29 Jan 2007 00:36:06 +0100 (CET) Date: Mon, 29 Jan 2007 00:40:02 +0100 From: Harald Tveit Alvestrand To: Kari Hurtta , ima@ietf.org Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) Message-ID: <78CDF378A62AE0D05EC763A5@[10.71.2.170]> In-Reply-To: <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 27. januar 2007 11:24 +0200 Kari Hurtta wrote: > Without > Header-Format: Downgraded > > heade ffiled upgrading must not be done. I think > automatic 'upgrading' always does too much damage. As technical contributor, I have protested long and hard against the term "upgrade" as anything but something that can optionally be applied by the end-recipient after final delivery. > For connecting isolated UTF8SMTP islands I have > suggested encapsulation -- drawback is that this > requires manual configuration for tunnel -- it > is not automatic. TCP is an excellent tunneling protocol. I believe the set of systems that *can* send SMTP mail to each other, but *cannot* establish TCP connections to each other, or to a relay friendly to both parties, is a fairly small set. Perhaps so small that we can ignore it. (the canonical exception is, of course, the port-25-relaying, SMTP-interpreting firewall that still doesn't want to hear about EHLO......) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Jan 28 19:57:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBKpc-0006FJ-Ud; Sun, 28 Jan 2007 19:57:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBKpb-0006FE-Km for ima@ietf.org; Sun, 28 Jan 2007 19:57:11 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBKpa-0002fs-1p for ima@ietf.org; Sun, 28 Jan 2007 19:57:11 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HBKpQ-000HGU-FQ; Sun, 28 Jan 2007 19:57:00 -0500 Date: Sun, 28 Jan 2007 19:56:59 -0500 From: John C Klensin To: Tony Finch Subject: Re: [EAI] Re: for8 Message-ID: <96203E0104046D727C2B1250@p3.JCK.COM> In-Reply-To: References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> <928640D60C755353E508511D@p3.JCK.COM> <45BA632B.45A9@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Sunday, 28 January, 2007 20:57 +0000 Tony Finch wrote: >... >> In any event, the conclusion I infer from your comments is >> clearly correct: we do make new trace headers, but we don't do >> it very often. > > Right. As well as the ones Frank noted, 2822 also defines new > trace fields (because it says that Resent- fields are trace > fields which isn't the case in 822). So 2822bis needs to make > them properly extensible. That leaves us something else we need to straighten out sooner or later. While it isn't explicit, the 2821 definition of "trace field" is "something inserted by the MTA to trace progress or handling of a message". To the extent to which Resent-* is supplied by an MUA as part of some MUA-level process, they aren't trace fields in the SMTP/2821 sense. This is obviously not a problem for this WG, but Pete and I probably need to talk. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 01:26:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBPy4-0006Ad-FD; Mon, 29 Jan 2007 01:26:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBPy3-0006A6-HT for ima@ietf.org; Mon, 29 Jan 2007 01:26:15 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBPy1-0006XU-In for ima@ietf.org; Mon, 29 Jan 2007 01:26:15 -0500 Received: (eyou send program); Mon, 29 Jan 2007 14:26:05 +0800 Message-ID: <370051965.12836@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Mon, 29 Jan 2007 14:26:05 +0800 Message-ID: <03fd01c7436e$5a87a0d0$1206e29f@cnnicyao> From: "YAO Jiankang" To: "Harald Tveit Alvestrand" , References: <369806007.04483@cnnic.cn> Subject: Re: [EAI] CONSENSUS CALL: Header format for alt-addr Date: Mon, 29 Jan 2007 14:26:04 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1213769485==" Errors-To: ima-bounces@ietf.org --===============1213769485== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkhhcmFsZCBUdmVpdCBBbHZl c3RyYW5kIiA8aGFyYWxkQGFsdmVzdHJhbmQubm8+DQpUbzogPGltYUBpZXRmLm9yZz4NClNlbnQ6 IEZyaWRheSwgSmFudWFyeSAyNiwgMjAwNyA2OjA1IFBNDQpTdWJqZWN0OiBbRUFJXSBDT05TRU5T VVMgQ0FMTDogSGVhZGVyIGZvcm1hdCBmb3IgYWx0LWFkZHINCg0KDQo+SSB0aGluayBpdCdzIHRp bWUgd2Ugc2V0dGxlZCB0aGUgaXNzdWUgb2YgdGhlIGZvcm1hdCBvZiBlbWFpbCBhZGRyZXNzZXMg aW4gDQo+IFVURjhTTVRQIGhlYWRlcnMgZm9yIHRoaXMgcm91bmQuDQo+IA0KPiBQUk9QT1NFRCBS RVNPTFVUSU9OOg0KPiANCj4gVGhlIHJlcHJlc2VudGF0aW9uIG9mIGFuIGludGVybmF0aW9uYWxp emVkIGVtYWlsIGFkZHJlc3Mgd2l0aCBhbiBhbHRlcm5hdGUgDQo+IEFTQ0lJIGFkZHJlc3MgaW4g YW4gVVRGOFNNVFAgbWVzc2FnZSBpcw0KPiANCj4gICA8ZWFpQGFkZHJlc3MgPGFzY2lpQGFkZHJl c3M+Pg0KPiANCj4gQSBwdXJlIEVBSSBhZGRyZXNzIGFuZCBhIHB1cmUgQVNDSUkgYWRkcmVzcyBh cmUgYm90aCBlbmNvZGVkIHdpdGhvdXQgdGhlIA0KPiBleHRyYSBmaWVsZDogYXMgPGVtYWlsQGFk ZHJlc3M+Lg0KPiBEZXRhaWxzIG9mIEFCTkYgdG8gYmUgd29ya2VkIG91dCBhZnRlciBhIGRyYWZ0 IHdpdGggdGhpcyBzeW50YXggaGFzIGJlZW4gDQo+IGVtaXR0ZWQuDQo+IA0KPiBQT1NTSUJMRSBS RVNQT05TRVM6DQo+IA0KPiAxLiBJIGFncmVlIHdpdGggdGhpcyByZXNvbHV0aW9uDQoNCkkgYWdy ZWUuDQoNCg0KWUFPIEppYW5rYW5nDQpDTk5JQw0K --===============1213769485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============1213769485==-- From ima-bounces@ietf.org Mon Jan 29 01:36:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBQ7h-0000xO-Kr; Mon, 29 Jan 2007 01:36:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBQ7f-0000xJ-AB for ima@ietf.org; Mon, 29 Jan 2007 01:36:11 -0500 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBQ7d-00006V-Hn for ima@ietf.org; Mon, 29 Jan 2007 01:36:11 -0500 Received: (eyou send program); Mon, 29 Jan 2007 14:36:06 +0800 Message-ID: <370052566.30407@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO cnnicyao) (159.226.6.18) by 159.226.7.146 with SMTP; Mon, 29 Jan 2007 14:36:06 +0800 Message-ID: <040301c7436f$c0e718f0$1206e29f@cnnicyao> From: "YAO Jiankang" To: "Harald Tveit Alvestrand" , References: <369806453.09645@cnnic.cn> Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Date: Mon, 29 Jan 2007 14:36:05 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1908191724==" Errors-To: ima-bounces@ietf.org --===============1908191724== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkhhcmFsZCBUdmVpdCBBbHZl c3RyYW5kIiA8aGFyYWxkQGFsdmVzdHJhbmQubm8+DQpUbzogPGltYUBpZXRmLm9yZz4NClNlbnQ6 IEZyaWRheSwgSmFudWFyeSAyNiwgMjAwNyA2OjEzIFBNDQpTdWJqZWN0OiBbRUFJXSBDT05TRU5T VVMgQ0FMTDogUmVtb3ZhbCBvZiBIZWFkZXItRm9ybWF0OiBtYXJrZXINCg0KDQo+IFRoZSBkaXNj dXNzaW9uIG9mIHdoZXRoZXIgb3Igbm90IHdlIG5lZWQgYSBoZWFkZXIgbWFya2VyIGZvciBtYXJr aW5nIA0KPiBVVEY4U01UUCBtZXNzYWdlcyB0aGF0IGFjdHVhbGx5IHVzZSBVVEYtOCBjaGFyYWN0 ZXJzIGhhcyByZWFjaGVkIGEgcG9pbnQgDQo+IHdoZXJlIGl0IHNlZW1zIHRoYXQgbm8gbmV3IHRl Y2huaWNhbCBpbmZvcm1hdGlvbiBpcyBiZWluZyBwcm92aWRlZC4NCj4gDQo+IEF0IHRoaXMgcG9p bnQsIHRoZSBjaGFpcnMgd2lzaCB0byBzZWUgaWYgdGhlIGdyb3VwIGlzIG5lYXIgYSBwb3NzaWJs ZSANCj4gY29uc2Vuc3VzIG9uIHRoZSBpc3N1ZS4NCj4gDQo+IFBST1BPU0VEIFJFU09MVVRPSU46 DQo+IA0KPiBUaGVyZSBpcyBubyBzaWduaWZpY2FudCBvcGVyYXRpb25hbCBvciBpbXBsZW1lbnRh dGlvbiBiZW5lZml0IGluIGhhdmluZyBhIA0KPiBtYXJrZXIgaW4gdGhlIGhlYWRlcnMgb2YgVVRG OFNNVFAgbWVzc2FnZXMsIGFuZCBzaWduaWZpY2FudCBhZGRpdGlvbmFsIA0KPiBjb21wbGV4aXR5 LiBUaGVyZWZvcmUsIHRoZSBwcm9wb3NlZCAiSGVhZGVyLVR5cGUiIHNlY3Rpb24sIA0KPiBkcmFm dC1pZXRmLWVhaS11dGY4aGVhZGVycy0wMiBzZWN0aW9uIDUsIHdpbGwgYmUgcmVtb3ZlZC4NCj4g DQo+IE5vdGUgdGhhdCB0aGlzIGlzIG5vdCBhIGNhbGwgb24gdGhlIHByb3Bvc2FsIHRvIGhhdmUg YSBzaW1pbGFyIG1hcmtlciBpbiANCj4gdGhlIFNNVFAgcHJvdG9jb2w7IHRoYXQncyBhIHNlcGFy YXRlIGlzc3VlLg0KPiANCj4gUE9TU0lCTEUgUkVTUE9OU0VTOg0KPiANCj4gMS4gSSBhZ3JlZSB3 aXRoIHRoaXMgcmVzb2x1dGlvbg0KDQpJIGFncmVlLg0KDQpUb2RheSBpdCBpcyAgcm91dGluZSB0 aGF0IG1hbnkgTVRBcyBzY2FuIA0KZXZlcnkgbWVzc2FnZSBmb3Igc3BhbSwgdmlydXMgb3Igb3Ro ZXIgcmVhc29ucy4gSXQgc2VlbXMgdGhhdCBmZXcgTVRBcyBkZXBlbmQgb24gICJIZWFkZXItVHlw ZSIgZmllbGRzIG9yIG1hcmtlciB0byBkZWNpZGUgdGhlIG1lc3NhZ2UncyB0eXBlLg0KVGhlIGJl dHRlciBjaG9pY2UgaXMgdG8gcmVseSBvbiBzY2FubmluZyB0aGUgbWVzc2FnZSB0byBkZWNpZGUg dGhlIG1lc3NhZ2UncyB0eXBlOiBVVEY4U01UUCBvciBBU0NJSSwgIGluc3RlYWQgb2YgIHRoZSAg IkhlYWRlci1UeXBlIiBmaWVsZHMgb3IgbWFya2VyLg0KDQoNCllBTyBKaWFua2FuZw0KQ05OSUMN Cg0KDQoNCg0KDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBJTUEgbWFpbGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbWE= --===============1908191724== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --===============1908191724==-- From ima-bounces@ietf.org Mon Jan 29 05:09:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBTRi-0003FF-3D; Mon, 29 Jan 2007 05:09:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBTRg-0003F7-MF for ima@ietf.org; Mon, 29 Jan 2007 05:09:04 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBTRf-0004vx-2p for ima@ietf.org; Mon, 29 Jan 2007 05:09:04 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l0TA8tJ5019902 for ; Mon, 29 Jan 2007 19:08:55 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l0TA8ttK019901 for ima@ietf.org; Mon, 29 Jan 2007 19:08:55 +0900 Date: Mon, 29 Jan 2007 19:08:55 +0900 From: Soobok Lee To: ima@ietf.org Message-ID: <20070129100855.GB30318@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [EAI] other thought about > X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org RFC822 allowed 1) below and its successor RFC2822 required angled-address like 0). But, still we see <>-omitted 1) is popular in headers. With EAI, we notice that 13) != 11) if we choose >. 0) To: 1) To: ascii@address <----- <> is omitted 2) To: display_name 3 ) To: "display_name" 11) To: > 12) To: 13) To: eai@address <----- 14) To: eai@address [ascii@address] 15) To: eai@address 16) To: I guess no MUA implementors would use 13) as abbreviation for 11), because eai@address is recognized as a display_name part. But, if we pill off outer <> from >, we get eai@address . When comparing 11) and 13), I feel they are visually confusing and there may be more chance of missing those difference by ,for example, some careless email programmers. But, if agree we need not go so far to worry about careless programmers's errors like 13), I think > is one of good choices. If we remain with , 14) has no ambiguity for parsers and for human eyes. Parsers can do more than [utf8headers] defines, to parse 14) for flexability. For me, is _visually clearer_. I had not been present in this WG from the beginning, but I guess authors might have these facts in mind when choosing []. I FAVOR , but, I do not oppose > so hard, if you all (but me) like it. :-) Regards, Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 05:44:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBU0H-0001FB-JA; Mon, 29 Jan 2007 05:44:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBU0F-0001F5-RU for ima@ietf.org; Mon, 29 Jan 2007 05:44:47 -0500 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBU0D-0002rY-IM for ima@ietf.org; Mon, 29 Jan 2007 05:44:47 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:33192) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1HBTzf-00029A-2d (Exim 4.63) (return-path ); Mon, 29 Jan 2007 10:44:12 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HBTzf-0007UM-GU (Exim 4.54) (return-path ); Mon, 29 Jan 2007 10:44:11 +0000 Date: Mon, 29 Jan 2007 10:44:11 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John C Klensin Subject: Re: [EAI] Re: for8 In-Reply-To: <96203E0104046D727C2B1250@p3.JCK.COM> Message-ID: References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> <928640D60C755353E508511D@p3.JCK.COM> <45BA632B.45A9@xyzzy.claranet.de> <96203E0104046D727C2B1250@p3.JCK.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Tony Finch , Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, 28 Jan 2007, John C Klensin wrote: > > That leaves us something else we need to straighten out sooner > or later. While it isn't explicit, the 2821 definition of > "trace field" is "something inserted by the MTA to trace > progress or handling of a message". To the extent to which > Resent-* is supplied by an MUA as part of some MUA-level > process, they aren't trace fields in the SMTP/2821 sense. However they do trace progress or handling of a message, so interleaving Resent- fields with Received: fields is the right thing. 2822 allows multiple resendings to be expressed unambiguously whereas 822 does not. Tony. -- f.a.n.finch http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE FORTIES: NORTHWEST 5 TO 7, OCCASIONALLY GALE 8 AT FIRST, BACKING WEST 4 FOR A TIME. VERY ROUGH DECREASING ROUGH. OCCASIONAL RAIN. GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 06:00:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBUEm-0007ef-Jf; Mon, 29 Jan 2007 05:59:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBUEl-0007ea-EF for ima@ietf.org; Mon, 29 Jan 2007 05:59:47 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBUEd-000504-50 for ima@ietf.org; Mon, 29 Jan 2007 05:59:47 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3$clerew&man#ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45bdd399.90f1.2c8 for ima@ietf.org; Mon, 29 Jan 2007 10:59:37 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0TAxXX9011534 for ; Mon, 29 Jan 2007 10:59:34 GMT To: IMA Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> <78CDF378A62AE0D05EC763A5@[10.71.2.170]> Message-ID: Date: Mon, 29 Jan 2007 10:59:33 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <78CDF378A62AE0D05EC763A5@[10.71.2.170]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, 28 Jan 2007 23:40:02 -0000, Harald Tveit Alvestrand wrote: > --On 27. januar 2007 11:24 +0200 Kari Hurtta > wrote: > >> Without >> Header-Format: Downgraded >> >> heade ffiled upgrading must not be done. I think >> automatic 'upgrading' always does too much damage. > > As technical contributor, I have protested long and hard against the > term "upgrade" as anything but something that can optionally be applied > by the end-recipient after final delivery. Mostly agreed. The exception is a MDA which redirects a message based on something in its /etc/aliases file, which may need to do a limited upgrade in order to detect cases which need to be redirected. Also, our IMAP document speaks of upgrading but that happens, of course, after final delivery. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 06:02:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBUGy-0008BL-Ev; Mon, 29 Jan 2007 06:02:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBUGx-0008BF-Kd for ima@ietf.org; Mon, 29 Jan 2007 06:02:03 -0500 Received: from smtp2gate.fmi.fi ([193.166.223.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBUGu-0005Ju-71 for ima@ietf.org; Mon, 29 Jan 2007 06:02:03 -0500 Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@siilo.fmi.fi) by smtp2gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20061220) with ESMTP id l0TB1tVu025030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Jan 2007 13:01:55 +0200 Received: from siilo.fmi.fi by torkku.fmi.fi with ESMTP id l0TB1tIZ031211 ; Mon, 29 Jan 2007 13:01:55 +0200 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id l0TB1tLb005655 ; Mon, 29 Jan 2007 13:01:55 +0200 Received: by siilo.fmi.fi id l0TB1tnG005651; Mon, 29 Jan 2007 13:01:55 +0200 Message-Id: <200701291101.l0TB1tnG005651@siilo.fmi.fi> Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) In-Reply-To: <78CDF378A62AE0D05EC763A5@[10.71.2.170]> To: Harald Tveit Alvestrand Date: Mon, 29 Jan 2007 13:01:55 +0200 (EET) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123e (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp2gate: 3 received headers rewritten with id 20070129/05448/01 X-Filter: smtp2gate: ID 5446/01, 1 parts scanned for known viruses X-Filter: torkku: ID 1499/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp2gate: ID 5446/01) report=BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >>> Harald Tveit Alvestrand > <...> > (the canonical exception is, of course, the port-25-relaying, > SMTP-interpreting firewall that still doesn't want to hear about EHLO......) Even if it is heard about EHLO. It is suggested, that firewall filter these EHLO keywords, which it does not know. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 06:13:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBUSH-0004qW-63; Mon, 29 Jan 2007 06:13:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBUSF-0004qK-Ic for ima@ietf.org; Mon, 29 Jan 2007 06:13:43 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBUSB-0007ZG-0s for ima@ietf.org; Mon, 29 Jan 2007 06:13:43 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3$clerew$man^ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45bdd6e1.1054a.2d for ima@ietf.org; Mon, 29 Jan 2007 11:13:37 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0TBDc0S012386 for ; Mon, 29 Jan 2007 11:13:38 GMT To: IMA Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <45BCFD71.6225@xyzzy.claranet.de> Message-ID: Date: Mon, 29 Jan 2007 11:13:38 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sun, 28 Jan 2007 23:34:52 -0000, Harald Tveit Alvestrand wrote: > Speaking as the author of RFC 2277: > > The need to identify language is independent of the need to allow for > multiple charsets (or at least UTF-8). > > There are many languages written in ASCII. But I suspect those languages mostly do not need the language information to assist in the display process, whereas I would imagine that it is useful for a user agent to know whether it is displaying Chinese or Japanese, even though those languages use essentially the same "CJK" parts of Unicode. > > Section 3 of 2277 refers to "character data". Section 4 refers to > "text". E-mail addresses may be many things, including being placed in > text, but they are not text. It is not s one should be concerned about, but rather the textual stuff one finds in s and in unstructured headers such as Subject. > > --On 28. januar 2007 20:45 +0100 Frank Ellermann > wrote: > >> An e-mail address typically has no "language", and for anything else it >> is possible to use RFC 2231 chapter 5 =?charset*langtag?x?y?= words, or >> the weird RFC 2231 constructs for MIME parameters. Sure, but the whole purpose of this WG is to do away with continued use of RFC 2047/2231 weirdness (though for sure both will linger on for quite a time :-( ). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 06:53:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBV4N-0003b0-HO; Mon, 29 Jan 2007 06:53:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBV4M-0003at-5k for ima@ietf.org; Mon, 29 Jan 2007 06:53:06 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBV4K-0007oB-DF for ima@ietf.org; Mon, 29 Jan 2007 06:53:05 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3&clerew&man$ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45bde01f.132e4.4f for ima@ietf.org; Mon, 29 Jan 2007 11:53:03 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0TBr2oJ014763 for ; Mon, 29 Jan 2007 11:53:03 GMT To: IMA Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <0EC11DC943D20065F77334C3@[10.0.1.3]> Message-ID: Date: Mon, 29 Jan 2007 11:53:01 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <0EC11DC943D20065F77334C3@[10.0.1.3]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 27 Jan 2007 07:06:41 -0000, Chris Newman wrote: > Charles Lindsey wrote on 1/26/07 17:44 +0000: >> 1. It is the only way to tell that a message is UTF8SMTP in the case >> where >> the >> transport mechanism is _not_ SMTP (a situation which the draft now >> claims to >> allow). > > The _only_ way to tell if a message is a UTF8SMTP message is to scan the > message and MIME headers to see if they conform to UTF8SMTP syntax. A > Header-Type field does not provide that information, it merely provides > a non-authoritative hint about the message type which any robust > processing agent needs to ignore. Repeatedly scanning the message at every agent is passes through is not the panacea that people seem to imaging. It is hard work (I have provided a Perl script at the end of this message to indicate how hard), and harder than simply checking for whether 8BITMIME is required. It is conceivable that such scanners will be routinely written into MTAs and user agents, less so that they will be adequately covered in gateways and mailing list expanders, and most improbable that they will be incorporated into the numerous ad hoc scripts which people tend to write to process or generate email messages for all sorts of random reasons. >> 3. Once a message has passed "final delivery" (whatever that is), the >> SMTP >> information is no longer available,... for example, good >> ol' >> mbox format is still around, and has no other way to store that >> information. > > A mbox-style file which contains UTF8SMTP messages would be a different > file format from today's mbox format. There are multiple ways to > distinguish the two file formats, including by file extension, by > out-of-band typing (e.g. MacOS creator code), by file location, or by > putting a magic number at the beginning of the file (a UTF-8 BOM > followed by "From " would be a good magic number for a UTF8SMTP mbox > file). Mbox format is nowhere rigorously defined. People interpret it as best they can, and the likelyhood of any such extensions being universally adopted is vanishingly small and is totally beyong our control (as opposed to POP3/IMAP where we have proposed extensions which have a reasonable chance of being adopted). > > A final delivery agent which put a UTF8SMTP message in a vanilla mbox > file would have a software bug that needs to be corrected. I disagree totally. It is going to happen whether we like it or not. ---------------------------------------------------------------------------- I wrote the following script to illustrate what needs to be done in order to scan a message to detect, in all cases, whether it needs to be treated as UTF8SMTP. It is not a pretty sight. Naturally, for serious use within some agent it would have to be rewritten in C to achieve any sem,blance of efficiency. The Perl version, however, is better in order to illustrate clearly the steps that need to be taken. #!/usr/local/bin/perl use English; use MIME::Head; my $LONGLINE = ' ' x 1000; $_ = $LONGLINE; # provide a buffer long enough for most lines; # if it needs more, it will malloc it #------------------------------------------- # # Set up $in and $out handlers; by default, STDIN and STDOUT # (this program is designed to operate in a pipeline). # my ($in, $out); if (defined $ARGV[0]) {open($in, "<$ARGV[0]")} else {$in = STDIN} if (defined $ARGV[1]) {open($out, ">$ARGV[1]")} else {$out = STDOUT} my $header = 0, $body=0; # To record whether we found an 8th bit #------------------------------------------- # # read_chunk ($bound) # # reads up to the given MIME boundary, or up to EOF, checking for an 8th bit # sub read_chunk { my ($bound) = @_; my $eos_type = "EOF"; # DELIM, CLOSE or EOF while (<$in>) { # will read up to next '\n' # which might be a long way away in # genuine binary attachments, but should # otherwise fit in 1000 octets if (m/[\200-\377]/o) { $body = 1; } if (substr($_,0,2) eq '--' && m/^(--$bound(--)?[ \t]*)/) { ### it was the expected boundary, and we note whether ### it is a CLOSEing boundary $eos_type = ($2 ? 'CLOSE':'DELIM'); return ($eos_type); } } return ($eos_type); } #------------------------------------------- # # process_header ($deftype) # # Reads headers, both at the top level and at the start of multipart # and message types. It reurns the Content-Type (defaulting to $deftype), # and checks the header for any 8th bit. # sub process_header { my ($deftype) = @_; my $head = new MIME::Head; $head->read($in); my $mime_type = $head->mime_type($deftype); my $bound = $head->multipart_boundary; if ($head->as_string =~ m/[\200-\377]/o) { $header = 1; } return ($mime_type, $bound); } #------------------------------------------- # # process_part ($oldbound, $deftype) # # process_part is the heart of the whole system. A 'part' is a part of # a multipart, or a message type, or even the whole message. This # routine walks through the tree of parts, calling itself recursively # as needed. # sub process_part { my ($oldbound, $deftype) = @_; my ($mime_type, $bound) = process_header($deftype); my ($type, $subtype) = split('/', $mime_type); my $eos_type; if ($type eq 'multipart') { ### multipart # determine the default type of the parts my $retype = $subtype eq 'digest'?'message/rfc822':'text/plain'; ### parse preamble # the preamble is not supposed to be displayed, but it # still gets checked ($eos_type) = read_chunk($bound); die "boundary $bound not found\n" if ($eos_type eq 'EOF'); # an expected CLOSEing boundary was never found; # a fatal error $more_parts = ($eos_type eq 'DELIM'); ### process parts while ($more_parts) { # the recursive call for each part within this # multipart ($eos_type) = process_part($bound, $retype); die "boundary $bound not found\n" if ($eos_type eq 'EOF'); $more_parts = 0 if ($eos_type eq 'CLOSE'); } ### process epilogue # the epilogue also is not for display, but still gets # checked; we are now looking for the next boundary # ($oldbound) withing our parent ($eos_type) = read_chunk($oldbound); } elsif ($type eq 'message') { ### message ### all message types have the same structure, though only ### some of them, such as message/rfc822 and message/partial ### possess bodies which might need checking; ### so, having already processed the header for the current ### part, we now encounter the header of the message proper ### - another recursive call; the mesage will be terminated ### by the boundary of the parent, hence the $oldbound ### parameter ($eos_type) = process_part($oldbound, 'text.plain'); } else { ### simple part ### this is a tip of the part tree ($eos_type) = read_chunk($oldbound); } return ($eos_type); } #------------------------------------------- # # main program # # The two parameters represent: # no boundary for any parent # no default type (actually, it is text/plain, but process_header # will tell us that) # process_part('', ''); if ($body) {print $out "This message requires 8BITMIME\n"} if ($header) {print $out "This message requires UTF8SMTP\n"} -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 07:05:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBVGf-0000Gb-Hm; Mon, 29 Jan 2007 07:05:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBVGd-0000GW-Sp for ima@ietf.org; Mon, 29 Jan 2007 07:05:47 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBVGZ-0002HA-Cj for ima@ietf.org; Mon, 29 Jan 2007 07:05:47 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3*clerew&man#ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45bde316.1611b.2c1 for ima@ietf.org; Mon, 29 Jan 2007 12:05:42 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0TC5ZTX015517 for ; Mon, 29 Jan 2007 12:05:36 GMT To: IMA Subject: Re: required-fields (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d7iv8zu7k.fsf@Hurtta06k.keh.iki.fi> <5dd550by0t.fsf_-_@Hurtta06k.keh.iki.fi> Message-ID: Date: Mon, 29 Jan 2007 12:05:35 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5dd550by0t.fsf_-_@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 27 Jan 2007 09:48:50 -0000, Kari Hurtta wrote: >> 1. I agree with this resolution >> >> This means also that upgrading of UTF8SMTP downgraded messages >> is NOT done. > > In past I was suggested required-fields paramater Header-Type > header fields. That was added to draft-ietf-eai-utf8headers-02. > When Header-Type is removed, I will suggest "UTF8-required-fields" > header field to draft-ietf-eai-utf8headers instead. Please sunnarize again what the UTF8-required-fields would do. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 07:12:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBVNO-0002l7-LW; Mon, 29 Jan 2007 07:12:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBVNO-0002l2-1C for ima@ietf.org; Mon, 29 Jan 2007 07:12:46 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HBVNM-0006pW-4t for ima@ietf.org; Mon, 29 Jan 2007 07:12:45 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3^clerew&man*ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45bde4b4.3e23.37f for ima@ietf.org; Mon, 29 Jan 2007 12:12:36 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0TCCZfo016045 for ; Mon, 29 Jan 2007 12:12:35 GMT To: IMA Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> Message-ID: Date: Mon, 29 Jan 2007 12:12:34 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Sat, 27 Jan 2007 09:24:06 -0000, Kari Hurtta wrote: > > Seems that parsing of MIME structure by every MTA on path > is quite common. So when MIME structure is parsed anyway, > that UTF8 indicator is not needed. What evidence do you have that this is commonly done? See my Perl script in reply to Chris which shows that it is hard work to do this properly, and generally speaking MTAs will be passing the whole body on untouched, and hence currently have little need to be aware of the MIME structure. > > So question is, do we want upgrading of downgraded > header fields. If that is wanted, That information will still be useful for handling the message sensibly when it arrives at its ultimate destination. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 07:16:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBVQn-00046K-V3; Mon, 29 Jan 2007 07:16:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBVQm-00040j-H7 for ima@ietf.org; Mon, 29 Jan 2007 07:16:16 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBVQk-0004cL-3L for ima@ietf.org; Mon, 29 Jan 2007 07:16:16 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HBVQc-000L8a-2Y; Mon, 29 Jan 2007 07:16:06 -0500 Date: Mon, 29 Jan 2007 07:16:05 -0500 From: John C Klensin To: Tony Finch Subject: Re: [EAI] Re: for8 Message-ID: In-Reply-To: References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> <928640D60C755353E508511D@p3.JCK.COM> <45BA632B.45A9@xyzzy.claranet.de> <96203E0104046D727C2B1250@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Frank Ellermann , ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 29 January, 2007 10:44 +0000 Tony Finch wrote: > On Sun, 28 Jan 2007, John C Klensin wrote: >> >> That leaves us something else we need to straighten out sooner >> or later. While it isn't explicit, the 2821 definition of >> "trace field" is "something inserted by the MTA to trace >> progress or handling of a message". To the extent to which >> Resent-* is supplied by an MUA as part of some MUA-level >> process, they aren't trace fields in the SMTP/2821 sense. > > However they do trace progress or handling of a message, so > interleaving Resent- fields with Received: fields is the right > thing. 2822 allows multiple resendings to be expressed > unambiguously whereas 822 does not. Understood. That is part of what needs to be clarified, since 2821 sort of assumes that, when an MUA gets and handles a message, the Received and Return-path fields will be removed before handoff back to an MTA or MSA. I really don't see this as a problem, just need to be sure that the relevant text in the two documents is aligned. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 10:06:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBY5C-0003ED-I9; Mon, 29 Jan 2007 10:06:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBY5A-0003E1-Ec for ima@ietf.org; Mon, 29 Jan 2007 10:06:08 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBY55-00086x-VP for ima@ietf.org; Mon, 29 Jan 2007 10:06:08 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HBY4v-0002TF-Jl for ima@ietf.org; Mon, 29 Jan 2007 16:05:53 +0100 Received: from d255059.dialin.hansenet.de ([80.171.255.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jan 2007 16:05:53 +0100 Received: from nobody by d255059.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jan 2007 16:05:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] Re: for8 Date: Mon, 29 Jan 2007 16:05:17 +0100 Organization: Lines: 12 Message-ID: <45BE0D2D.87C@xyzzy.claranet.de> References: <566E2A7DE35A00124B3805FD@p3.JCK.COM> <543F81AC0E4186AEC7B23AAB@[10.0.1.3]> <928640D60C755353E508511D@p3.JCK.COM> <45BA632B.45A9@xyzzy.claranet.de> <96203E0104046D727C2B1250@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d255059.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > This is obviously not a problem for this WG, but Pete and I > probably need to talk. There are more minor issues for a future 2822bis: a pending erratum, and some USEFOR folks think that the Message-ID syntax has to be cleaned up to reflect common practice and what's stated in two drafts (and several older RFCs). Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 10:37:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYZP-0007bm-0s; Mon, 29 Jan 2007 10:37:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBYZN-0007bd-ST for ima@ietf.org; Mon, 29 Jan 2007 10:37:21 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBYZM-0003II-IT for ima@ietf.org; Mon, 29 Jan 2007 10:37:21 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HBYZI-0006dn-Ho for ima@ietf.org; Mon, 29 Jan 2007 16:37:16 +0100 Received: from d255059.dialin.hansenet.de ([80.171.255.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jan 2007 16:37:16 +0100 Received: from nobody by d255059.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jan 2007 16:37:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Frank Ellermann Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Date: Mon, 29 Jan 2007 16:34:28 +0100 Organization: Lines: 28 Message-ID: <45BE1404.B7D@xyzzy.claranet.de> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <45BCFD71.6225@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d255059.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > the whole purpose of this WG is to do away with continued use of > RFC 2047/2231 weirdness (though for sure both will linger on for > quite a time :-( ). RFC 2047 and 2231 chapter 5 (= the *langtag stuff) are IMO okay. The rest of RFC 2231 about MIME parameter values is admittedly odd. From my POV the purpose of this "EAI" WG is if anything the A in EAI or IMA. IFF that "A" part works in the experiment adding more (probably anything else modulo Content-*) later should be no big issue. For that "A" part we need no language tags, and for 2047- words we have it already. Kari said that he has implemented the complete 2231, not only chapter 5. Therefore we're not forced to worry about langtags for complete headers, the 822 7bit headers also don't need / have that. It's more important to define and register a "message/utf822" superset of the pure ASCII message/rfc822 than to tackle non-"A" details. Maybe we can agree to disagree for the moment, I'm not yet sure about this "Header-Format" issue, I've too see a draft trying to get away without it, and if that breaks somewhere. But langtags probably won't be the showstopper. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 13:21:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBb8C-0006Sm-7k; Mon, 29 Jan 2007 13:21:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBb8B-0006Sf-1n for ima@ietf.org; Mon, 29 Jan 2007 13:21:27 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBb89-0000wt-KU for ima@ietf.org; Mon, 29 Jan 2007 13:21:27 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HBb7z-0004HW-4d for ima@ietf.org; Mon, 29 Jan 2007 19:21:15 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jan 2007 19:21:15 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jan 2007 19:21:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) Date: 29 Jan 2007 20:21:06 +0200 Lines: 48 Message-ID: <5dy7nl4ru5.fsf@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > On Sat, 27 Jan 2007 09:24:06 -0000, Kari Hurtta > wrote: > > > > Seems that parsing of MIME structure by every MTA on path > > is quite common. So when MIME structure is parsed anyway, > > that UTF8 indicator is not needed. > > What evidence do you have that this is commonly done? See my Perl > script in reply to Chris which shows that it is hard work to do this > properly, and generally speaking MTAs will be passing the whole body > on untouched, and hence currently have little need to be aware of the > MIME structure. On my answer to your another question I noticed that sendmail parses MIME structure of every mail (on default configuration). Have you information of some other commonly used MTAs? / Kari Hurtta ---------CLIP------------CLAP-------------- From: Kari Hurtta Subject: Re: Header-Type, Mime-Version (Re: [EAI] Status of utf8header draft) Newsgroups: gmane.ietf.ima To: ima@ietf.org Date: 25 Jan 2007 16:57:30 +0200 <...> [1] Actually this is not completely true. If MaxMimeHeaderLength or MaxMimeFieldLength is set, MMME structure is always parsed. These options are set by default starting from sendmail 8.11.7 Quote from RELEASE_NOTES 8.11.7/8.11.7 2003/03/29 <...> To provide partial protection for internal, unpatched MTAs that may be performing 7->8 or 8->7 bit MIME conversions, the default for MaxMimeHeaderLength has been changed to 2048/1024. Note: this does have a performance impact, and it only protects against frontal attacks from the outside. To disable the checks and return to pre-8.11.7 defaults, set MaxMimeHeaderLength to 0/0. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 14:12:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbvq-00024k-2n; Mon, 29 Jan 2007 14:12:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbvp-00023Z-64 for ima@ietf.org; Mon, 29 Jan 2007 14:12:45 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBbvn-0007SD-KA for ima@ietf.org; Mon, 29 Jan 2007 14:12:45 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HBbvg-0001pA-9x for ima@ietf.org; Mon, 29 Jan 2007 20:12:36 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jan 2007 20:12:36 +0100 Received: from hurtta+ietf by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jan 2007 20:12:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: required-fields (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) Date: 29 Jan 2007 21:12:26 +0200 Lines: 163 Message-ID: <5dtzy94pgl.fsf@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d7iv8zu7k.fsf@Hurtta06k.keh.iki.fi> <5dd550by0t.fsf_-_@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > On Sat, 27 Jan 2007 09:48:50 -0000, Kari Hurtta > wrote: > > >> 1. I agree with this resolution > >> > >> This means also that upgrading of UTF8SMTP downgraded messages > >> is NOT done. > > > > In past I was suggested required-fields paramater Header-Type > > header fields. That was added to draft-ietf-eai-utf8headers-02. > > When Header-Type is removed, I will suggest "UTF8-required-fields" > > header field to draft-ietf-eai-utf8headers instead. > > Please sunnarize again what the UTF8-required-fields would do. > Downgrade needs able to delete headers (when it do not know syntax of headers). Content of these headers are stored to some encapsulation format (for example Downgraded -header). These headers may be necessary for some protocols. That header field makes possible to sender specify that. UTF8-required-fields sets requirements, which header fields downgrading process must know. It says that these headers must exists even when message is on downgraded form. / Kari Hurtta ---------------------------------------------------------------------- From: Kari Hurtta Subject: [EAI] draft-ietf-eai-utf8headers-01.txt / draft-ietf-eai-downgrade-02.txt suggestion Newsgroups: gmane.ietf.ima Cc: Kari Hurtta Date: Sat, 14 Oct 2006 14:48:07 +0300 (EEST) draft-ietf-eai-utf8headers-01.txt: header-content = "UTF8SMTP:" [FWS] content-code [FWS] *( ";" parameter ) CRLF content-code = "UTF8" / "ASCII" / "Downgraded" parameter = "Header-Language:" [FWS] Language-List Language-List = Language-Tag [FWS] *("," [FWS] Language-Tag [FWS]) following was suggested: header-content = "Header-Type:" [FWS] content-code [FWS] *( ";" parameter ) CRLF ; parameter is defined on RFC 2045 content-code = "UTF8SMTP" / "ASCII" / "Downgraded" The "header-language" parameter is defined for "Header-Type" header-field. Value of "header-language" parameter is defined as following (after possible quotation of quoted-string is decode): header-language-value = Language-Tag [FWS] *("," [FWS] Language-Tag [FWS]) I also suggest following (almost same was also suggested): The "required-fields" parameter is defined for "Header-Type" header-field. Value of "required-fields" parameter is defined as following (after possible quotation of quoted-string is decode): required-fields-value = field-name [FWS] *("," [FWS] field-name [FWS]) ; field-name is defined on RFC 2822 draft-ietf-eai-downgrade-02.txt: Downgrading: * Check if the mail has 'UTF8SMTP' header and its value is "UTF8". Otherwise, downgrading is not required. * Check each header whether it contains UTF-8 characters or not. If the header contains UTF-8 characters, + If the header is an address header which is described in Section 5.1.1, - Preserve the header in 'Downgraded' header. - Downgrade the header defined in Section 5.1.1. + The other header case, encode the header by [RFC2047] with UTF-8 tag. * Change 'UTF8SMTP' header value to "Downgraded". Suggested changes: Downgrading: * Check if the mail has 'Header-Type' header field and its value is "UTF8SMTP". Otherwise, downgrading is not required. * Check each header field whether it contains UTF-8 characters or not. If the header field contains UTF-8 characters, + If the header field is an address header field which is described in Section 5.1.1, - Preserve the header in 'Downgraded' header field. - Downgrade the header field defined in Section 5.1.1. + Otherwise if syntax of header field is known: - Encode header elements according of [RFC2047] and [RFC2231] - If encoding is not possible, preserve the header in 'Downgraded' header field and remove original header field. - If syntax of header field is not known - Preserve the header in 'Downgraded' header field and remove original header field. * If some header field was removed, which is mentioned on "required-fields" parameter on 'Header-Type' header field, downgrading fails. * Change 'Header-Type' header field value to "Downgraded". NOTE: Address header downgrading in Section 5.1.1 may also remove header field. If that header field is mentioned on "required-fields" parameter on 'Header-Type' header field, downgrading fails. draft-ietf-eai-downgrade-02.txt: Upgrading: * Check if the mail has 'UTF8SMTP' header and its value is "Downgraded". Otherwise, upgrading is not required. * Decode all 'Downgraded' headers. + Decode header value field string which is [RFC2047] encoded. + If the header is address header described in Section 5.1.1, - Apply address header downgrading to the decoded header. - Remove the header line which is the same with the downgraded line. + Remove the 'Downgraded' header. + Add decoded header to mail header. * If each mail header has [RFC2047] encoded part and which encoding is "UTF-8", it is a downgraded header, so decode it. * Change 'UTF8SMTP' header value to "UTF8". Suggested changes: * Check if the mail has 'Header-Type' header field and its value is "Downgraded". Otherwise, upgrading is not required. + Decode header value field string which is [RFC2047] encoded. + If the header is address header field described in Section 5.1.1, - Apply address header field downgrading to the decoded header. - Remove the header field line which is the same with the downgraded line. + Remove the 'Downgraded' header field. + Add decoded header to mail header field. * For every mail header field, which syntax is known + If each mail header field has [RFC2047] or [RFC2231] encoded part and which encoding is "UTF-8", it is a downgraded header field, so decode it. * Change 'Header-Type' header value to "UTF8SMTP". / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 14:16:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbzS-0002vr-F3; Mon, 29 Jan 2007 14:16:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbzR-0002vl-Th for ima@ietf.org; Mon, 29 Jan 2007 14:16:29 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBbzQ-0007rk-Jw for ima@ietf.org; Mon, 29 Jan 2007 14:16:29 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ABA912580D0; Mon, 29 Jan 2007 20:12:29 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23450-03; Mon, 29 Jan 2007 20:12:19 +0100 (CET) Received: from [192.168.23.150] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id D01DB2580CD; Mon, 29 Jan 2007 20:12:18 +0100 (CET) Date: Mon, 29 Jan 2007 11:16:15 -0800 From: Harald Tveit Alvestrand To: Charles Lindsey , IMA Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Message-ID: <782A7628C38072EFB88F2E72@[172.19.11.21]> In-Reply-To: References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <0EC11DC943D20065F77334C3@[10.0.1.3]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: -0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 29. januar 2007 11:53 +0000 Charles Lindsey wrote: >> The _only_ way to tell if a message is a UTF8SMTP message is to scan the >> message and MIME headers to see if they conform to UTF8SMTP syntax. A >> Header-Type field does not provide that information, it merely provides >> a non-authoritative hint about the message type which any robust >> processing agent needs to ignore. > > Repeatedly scanning the message at every agent is passes through is not > the panacea that people seem to imaging. It is hard work (I have provided > a Perl script at the end of this message to indicate how hard), In what universe does 65 lines of Perl constitute "hard"? (I removed comment lines and blank lines before counting - a well commented program, btw - kudos for that!) Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 14:19:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBc1y-0003et-CD; Mon, 29 Jan 2007 14:19:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBc1w-0003eT-Va for ima@ietf.org; Mon, 29 Jan 2007 14:19:04 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBc1v-0008IN-Lg for ima@ietf.org; Mon, 29 Jan 2007 14:19:04 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A8E2D2580D0; Mon, 29 Jan 2007 20:15:04 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23450-06; Mon, 29 Jan 2007 20:14:56 +0100 (CET) Received: from [192.168.23.150] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4593A2580CC; Mon, 29 Jan 2007 20:14:54 +0100 (CET) Date: Mon, 29 Jan 2007 11:18:50 -0800 From: Harald Tveit Alvestrand To: Charles Lindsey , IMA Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker Message-ID: <5103A2A292C8E4D9539C0944@[172.19.11.21]> In-Reply-To: References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <45BCFD71.6225@xyzzy.claranet.de> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: -0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 29. januar 2007 11:13 +0000 Charles Lindsey wrote: > On Sun, 28 Jan 2007 23:34:52 -0000, Harald Tveit Alvestrand > wrote: > >> Speaking as the author of RFC 2277: >> > >> The need to identify language is independent of the need to allow for >> multiple charsets (or at least UTF-8). >> >> There are many languages written in ASCII. > > But I suspect those languages mostly do not need the language information > to assist in the display process, whereas I would imagine that it is > useful for a user agent to know whether it is displaying Chinese or > Japanese, even though those languages use essentially the same "CJK" > parts of Unicode. Have you read RFC 2277? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 14:40:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBcMb-0003sG-CT; Mon, 29 Jan 2007 14:40:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBcMZ-0003sB-VG for ima@ietf.org; Mon, 29 Jan 2007 14:40:23 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBcMT-0002ne-Ag for ima@ietf.org; Mon, 29 Jan 2007 14:40:23 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3&clerew^man#ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45be4d9f.3e23.679 for ima@ietf.org; Mon, 29 Jan 2007 19:40:15 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0TJeEnZ014911 for ; Mon, 29 Jan 2007 19:40:15 GMT To: IMA Subject: Re: [EAI] other thought about > References: <20070129100855.GB30318@ns5.lsb.org> Message-ID: Date: Mon, 29 Jan 2007 19:40:14 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <20070129100855.GB30318@ns5.lsb.org> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 29 Jan 2007 10:08:55 -0000, Soobok Lee wrote: > RFC822 allowed 1) below and its successor RFC2822 required > angled-address like 0). > But, still we see <>-omitted 1) is popular in headers. > > With EAI, we notice that 13) != 11) if we choose >. > > 0) To: > 1) To: ascii@address <----- <> is omitted Not quite. It is an alternative explicitly allowed by RFC 2822 (but, if you use it, you can't have a display-name as well). > > 2) To: display_name > 3 ) To: "display_name" > > 11) To: > > 12) To: > > 13) To: eai@address <----- > 14) To: eai@address [ascii@address] AFAIK, out utf8headers draft does not permit either of those (and if it does, it needs to be fixed). > 15) To: eai@address > 16) To: And utf8headers permits (I hope) both of those, -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 14:56:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBccJ-0001c7-Ms; Mon, 29 Jan 2007 14:56:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBccI-0001aq-6T for ima@ietf.org; Mon, 29 Jan 2007 14:56:38 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBccG-0005Sg-7d for ima@ietf.org; Mon, 29 Jan 2007 14:56:38 -0500 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0TJuZ6W004197 for ; Mon, 29 Jan 2007 12:56:35 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCN00A01BD9A000@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 29 Jan 2007 12:56:35 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCN000EWBE1TI30@mail-amer.sun.com>; Mon, 29 Jan 2007 12:56:35 -0700 (MST) Date: Mon, 29 Jan 2007 11:56:24 -0800 From: Chris Newman Subject: Re: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft)) In-reply-to: <57ACEF55BFEC77C25C94A683@p3.JCK.COM> To: John C Klensin , Charles Lindsey , IMA Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <66B5502F24092DF658DA31DF@p3.JCK.COM> <3D816681DA860388277BBD70@p3.JCK.COM> <57ACEF55BFEC77C25C94A683@p3.JCK.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote on 1/27/07 11:38 -0500: > --On Friday, 26 January, 2007 22:19 -0800 Chris Newman > wrote: >> If MIME were designed today, I would replace "7bit", "8bit" >> and "binary" with a single "identity" label and I'd certainly >> ignore the distinction between those three labels in any >> robust MIME processing agent I was writing today. > > Chris, I can certainly understand your removing the distinction > between "7bit" and "8bit", and maybe between "8bit" and > "binary", but it is not clear to my how you would definitively > determine the difference between "7bit" and the two downgrade > encodings ("Base64" and "Quoted-printable"). If what you > decided by heuristic scan was different from what the label > indicated, you'd be faced with a choice that was discussed > during the MIME work -- which to believe and the possibility > that the sender intended to transmit the apparently-encoded form > as a message, intending that it not be decoded. > > Or am I missing something? I was proposing that MIME designed today would have three CTE labels: "identity", "quoted-printable" and "base64" (actually, I'd get rid of quoted-printable, but that's besides the point). As you observe, distinguishing between "identity" and "base64" is important. It's critical to distinguish between content and content-transfer-encoding. An example where this was botched is the MacOS X Mail client which assumes any attachment with a zip magic number used zip as a content-transfer-encoding. This breaks badly on the standard Open Document Formats which are zipped XML files where the zip is canonical to the format, and not used as a content-transfer-encoding. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 15:01:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBchN-0004du-4J; Mon, 29 Jan 2007 15:01:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBchM-0004dp-9z for ima@ietf.org; Mon, 29 Jan 2007 15:01:52 -0500 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBchI-0006J3-0x for ima@ietf.org; Mon, 29 Jan 2007 15:01:52 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:49716) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1HBchC-0007YX-TV (Exim 4.63) (return-path ); Mon, 29 Jan 2007 20:01:42 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HBchC-0001Cg-33 (Exim 4.54) (return-path ); Mon, 29 Jan 2007 20:01:42 +0000 Date: Mon, 29 Jan 2007 20:01:42 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Charles Lindsey Subject: Re: [EAI] other thought about > In-Reply-To: Message-ID: References: <20070129100855.GB30318@ns5.lsb.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 29 Jan 2007, Charles Lindsey wrote: > On Mon, 29 Jan 2007 10:08:55 -0000, Soobok Lee wrote: > > > > 1) To: ascii@address <----- <> is omitted > > Not quite. It is an alternative explicitly allowed by RFC 2822 (but, if you > use it, you can't have a display-name as well). However you can put a name in a comment. Tony. -- f.a.n.finch http://dotat.at/ SOUTHEAST ICELAND: SOUTHWESTERLY 6 OR 7, OCCASIONALLY GALE 8. ROUGH OR VERY ROUGH . RAIN OR DRIZZLE, THEN SHOWERS. MODERATE OR POOR BECOMING GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 15:38:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdGs-0003ES-PW; Mon, 29 Jan 2007 15:38:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdGr-0003Cy-5h for ima@ietf.org; Mon, 29 Jan 2007 15:38:33 -0500 Received: from smtp-out.sendmail.com ([209.246.26.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBdGp-0004HR-Mo for ima@ietf.org; Mon, 29 Jan 2007 15:38:33 -0500 Received: from [10.0.0.51] (71-208-198-236.hlrn.qwest.net [71.208.198.236]) (authenticated bits=0) by foon.sendmail.com (Switch-3.2.5/Switch-3.2.0) with ESMTP id l0TKbjdu027560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jan 2007 12:37:47 -0800 X-DKIM: Sendmail DKIM Filter v0.5.1 foon.sendmail.com l0TKbjdu027560 DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=sendmail.com; s=tls.dkim; t=1170103068; bh=iDCj4Dg/S4GiPZvLda4WYpucHLQ=; h=X-DomainKeys: DomainKey-Signature:Date:From:X-X-Sender:To:cc:Subject:In-Reply-To: Message-ID:References:MIME-Version:Content-Type; b=tvCBZY5esDjtHquY 51rvNu00/qTOG6Q5mKS08Xo7U0eVZqlV++ad/7nvjigk+WlWPfuk/6eGh/f6yr7863C BkfZbfi2bBDh3fHlY9jb/C25Xy/u3w4jSdgJBHS/pwDanZmyDt9JCTpaUj3zVu4JeZw Q5rvE4I4CmRC8tqTBPh8c= X-DomainKeys: Sendmail DomainKeys Filter v0.4.1 foon.sendmail.com l0TKbjdu027560 DomainKey-Signature: a=rsa-sha1; s=tls; d=sendmail.com; c=nofws; q=dns; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id: references:mime-version:content-type; b=mTEltb/GunWsi6lqN2wQNw4GepX4xty1nGLiZVrC0bhOy+MnL5b283PoKpm5a2Ri9 VhHREjuhthUKJmz0NiXQeKTlfYiFn6CpbJvfrcRgeGKXT7XAbCCkuzdZHmWPRF0tczW WN9DFhsojse6U4SUtZYiQ9E7jLU+LasavipFOZA= Date: Mon, 29 Jan 2007 13:37:44 -0700 From: Philip Guenther X-X-Sender: guenther@vanye.mho.net To: Tony Finch Subject: Re: [EAI] other thought about > In-Reply-To: Message-ID: References: <20070129100855.GB30318@ns5.lsb.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 29 Jan 2007, Tony Finch wrote: > On Mon, 29 Jan 2007, Charles Lindsey wrote: >> On Mon, 29 Jan 2007 10:08:55 -0000, Soobok Lee wrote: >>> >>> 1) To: ascii@address <----- <> is omitted >> >> Not quite. It is an alternative explicitly allowed by RFC 2822 (but, if you >> use it, you can't have a display-name as well). > > However you can put a name in a comment. Sure, and some MUAs did so. Others inserted comments containing stuff unrelated to the address the comment was next to. It was common before RFC 2822 to see this**: To: original@address (resent to ) There's no particular reason to believe that a comment next to an address has anything to do with that particular address. Determining the correct semantics of a comment involves heuristics best performed by a human being. To quote the fortune file: Heuristics are bug ridden by definition. If they didn't have bugs, then they'd be algorithms. Philip Guenther ** I believe it was an old version of Eudora that did the above, dating from when it wasn't clear whether Resent-{To,Cc} would be sent replies. Once that was clarified in RFC 2822, it was corrected to generate Resent-To: another@address To: original@address _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 15:50:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdSh-0000B3-Qt; Mon, 29 Jan 2007 15:50:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBdSU-0008N7-9y; Mon, 29 Jan 2007 15:50:34 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HBdST-0003pk-9u; Mon, 29 Jan 2007 15:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 1AC2A2ACA5; Mon, 29 Jan 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HBdRy-0001Xw-RB; Mon, 29 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 29 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : International Delivery and Disposition Notifications Author(s) : C. Newman Filename : draft-ietf-eai-dsn-00.txt Pages : 17 Date : 2007-1-29 Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing draft standard is presently limited to US-ASCII text in the machine readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-dsn-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-dsn-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-dsn-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-29120515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-dsn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-dsn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-29120515.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima --NextPart-- From ima-bounces@ietf.org Mon Jan 29 18:45:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgBh-0003LD-Gn; Mon, 29 Jan 2007 18:45:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgBf-0003L3-Gh for ima@ietf.org; Mon, 29 Jan 2007 18:45:23 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBgBa-0007g1-Gs for ima@ietf.org; Mon, 29 Jan 2007 18:45:23 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4D7EC258100 for ; Tue, 30 Jan 2007 00:41:13 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30039-01 for ; Tue, 30 Jan 2007 00:41:06 +0100 (CET) Received: from [192.168.23.150] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id B04CF2580CF for ; Tue, 30 Jan 2007 00:41:05 +0100 (CET) Date: Mon, 29 Jan 2007 15:45:01 -0800 From: Harald Tveit Alvestrand To: ima@ietf.org Message-ID: <5A5B5717A957CB6B3D10E23A@[172.19.11.21]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: -0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [EAI] Poll status - FYI X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At the moment, I have 10 respondents on the "alt-addr format" question, and 10 respondents on the "marker" question. There have been a few private replies, but not enough to change the numbers; people can tell the trend from the responses on the list (if you count them by sender, not by volume). Polls close on Thursday (23:59 GMT). Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 19:06:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgWE-0003dK-OR; Mon, 29 Jan 2007 19:06:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgWD-0003dF-1I for ima@ietf.org; Mon, 29 Jan 2007 19:06:37 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBgWB-00028b-Dl for ima@ietf.org; Mon, 29 Jan 2007 19:06:37 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l0U06HJ5015562; Tue, 30 Jan 2007 09:06:17 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l0U06HpN015560; Tue, 30 Jan 2007 09:06:17 +0900 Date: Tue, 30 Jan 2007 09:06:17 +0900 From: Soobok Lee To: Charles Lindsey Subject: Re: [EAI] other thought about > Message-ID: <20070130000617.GD30318@ns5.lsb.org> References: <20070129100855.GB30318@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, Jan 29, 2007 at 07:40:14PM -0000, Charles Lindsey wrote: > On Mon, 29 Jan 2007 10:08:55 -0000, Soobok Lee wrote: > > >13) To: eai@address <----- > >14) To: eai@address [ascii@address] > > AFAIK, out utf8headers draft does not permit either of those (and if it > does, it needs to be fixed). > > >15) To: eai@address > >16) To: > > And utf8headers permits (I hope) both of those, It is clear that 16) is allowed in [utf8headers] excerpts below. But, I can't find any link between RFC2822(RFC822) <-> [utf8headers] that explicitly allows 15) . As you pointed out, "To: ascii@address" is also allowed explicitly in RFC2822. mailbox = name-addr / addr-spec <---- name-addr = [display-name] angle-addr angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr But, I find this clause is required to allow 15) in [utf8headers]. mailbox = name-addr / addr-spec / utf8-addr-spec <---- The next paragraph from [utf8headers] only defines the angled form "". If "utf8-addr-spec" is defined to supersede (override) "addr-spec" in sweeping manner, this won't be a problem, but i can't find such hints from [utf8headers]. Correct me if I am wrong. Soobok 6.3. Change on addr-spec syntax In this specification, internationalized email address will be presented in UTF-8. Thus, all header fields involving es may be different from traditional ones. There might be UTF8SMTP unaware MTAs in the mail routing path. In that case, MTA may bounce the message with reply code 550, or downgrade the non-ASCII contents of all header bodies before continuing to send the message. The downgrade process involve with a new ALT-ADDRESS parameter. When downgrade occurs, the ALT-ADDRESS will be used for mail delivery instead of the internationalized email address, the detail is described in [EAI-downgrading]. Yeh Expires April 26, 2007 [Page 8] Internet-Draft I18N Email Headers October 2006 angle-addr = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS] utf8-addr-spec = utf8-local-part "@" utf8-domain utf8-local-part= utf8-dot-atom / quoted-string / obs-local-part utf8-domain = utf8-dot-atom / domain-literal / obs-domain alt-address = [CFWS] "[" addr-spec "]" [CFWS] Below list a few possible representation as example. "DISPLAY_NAME" ; traditional mailbox format "DISPLAY_NAME" ; UTF8SMTP but no ALT-ADDRESS parameter provided, ; message will bounce if UTF8SMTP extension is not supported "DISPLAY_NAME" ; UTF8SMTP with ALT-ADDRESS parameter provided, ; ALT-ADDRESS can be used if downgrade is necessary _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 19:30:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgt1-0006ju-Ic; Mon, 29 Jan 2007 19:30:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgsz-0006jo-U4 for ima@ietf.org; Mon, 29 Jan 2007 19:30:09 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBgsy-0005v9-AQ for ima@ietf.org; Mon, 29 Jan 2007 19:30:09 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l0U0TtJ5018951; Tue, 30 Jan 2007 09:29:55 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l0U0TtFw018943; Tue, 30 Jan 2007 09:29:55 +0900 Date: Tue, 30 Jan 2007 09:29:55 +0900 From: Soobok Lee To: Charles Lindsey Subject: Re: [EAI] other thought about > Message-ID: <20070130002955.GE30318@ns5.lsb.org> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070130000617.GD30318@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, Jan 30, 2007 at 09:06:17AM +0900, Soobok Lee wrote: > > > mailbox = name-addr / addr-spec <---- > > name-addr = [display-name] angle-addr > > angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr > > > > But, I find this clause is required to allow 15) in [utf8headers]. > > > mailbox = name-addr / addr-spec / utf8-addr-spec <---- > mailbox = name-addr / utf8-addr-spec <---- Some one may argue that "addr-spec" can be omitted because addr-spec is a subset of utf8-addr-spec. [utf8headers] does not redefine "mailbox" while it does "angle-addr". Soobok > > > The next paragraph from [utf8headers] only defines the angled form > "". > If "utf8-addr-spec" is defined to supersede (override) "addr-spec" > in sweeping manner, this won't be a problem, but i can't find such > hints from [utf8headers]. Correct me if I am wrong. > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 19:32:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgul-0006uT-I6; Mon, 29 Jan 2007 19:31:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgui-0006u6-Jm for ima@ietf.org; Mon, 29 Jan 2007 19:31:56 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBguh-00067s-51 for ima@ietf.org; Mon, 29 Jan 2007 19:31:56 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HBguf-0000M8-3w; Mon, 29 Jan 2007 19:31:53 -0500 Date: Mon, 29 Jan 2007 19:31:51 -0500 From: John C Klensin To: Chris Newman , Charles Lindsey , IMA Subject: Re: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft)) Message-ID: In-Reply-To: References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <66B5502F24092DF658DA31DF@p3.JCK.COM> <3D816681DA860388277BBD70@p3.JCK.COM> <57ACEF55BFEC77C25C94A683@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 29 January, 2007 11:56 -0800 Chris Newman wrote: > John C Klensin wrote on 1/27/07 11:38 -0500: >> --On Friday, 26 January, 2007 22:19 -0800 Chris Newman >> wrote: >>> If MIME were designed today, I would replace "7bit", "8bit" >>> and "binary" with a single "identity" label and I'd certainly >>> ignore the distinction between those three labels in any >>> robust MIME processing agent I was writing today. >> >> Chris, I can certainly understand your removing the >> distinction between "7bit" and "8bit", and maybe between >> "8bit" and "binary", but it is not clear to my how you would >> definitively determine the difference between "7bit" and the >> two downgrade encodings ("Base64" and "Quoted-printable"). >> If what you decided by heuristic scan was different from what >> the label indicated, you'd be faced with a choice that was >> discussed during the MIME work -- which to believe and the >> possibility that the sender intended to transmit the >> apparently-encoded form as a message, intending that it not >> be decoded. >> >> Or am I missing something? > > I was proposing that MIME designed today would have three CTE > labels: "identity", "quoted-printable" and "base64" (actually, > I'd get rid of quoted-printable, but that's besides the > point). Aha. I gave the wrong interpretation to "identity" and it was downhill from there. We are in agreement -- including about Q-P. > As you observe, distinguishing between "identity" and > "base64" is important. It's critical to distinguish between > content and content-transfer-encoding. An example where this > was botched is the MacOS X Mail client which assumes any > attachment with a zip magic number used zip as a > content-transfer-encoding. This breaks badly on the standard > Open Document Formats which are zipped XML files where the zip > is canonical to the format, and not used as a > content-transfer-encoding. Of course, related issues with general-purpose zip files are why, after some discussion, we rejected a proposal or three for CTE: zip and some equivalents. Incidentally, Charles, I don't know if Chris would agree, but, if I were designing a mail store, I'd either make sure that everything was stored in native form (Chris's "identity") or I would record (somewhere) whatever the scanning process figured out about what was present because I might want to have that information handy to decide what sorts of mail-reader inquiries to accept, etc. But that, again, is not a case for an on-the-wire message header. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 20:16:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhbH-0002Us-J1; Mon, 29 Jan 2007 20:15:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhbG-0002Un-UN for ima@ietf.org; Mon, 29 Jan 2007 20:15:54 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBhbE-0005Pf-WC for ima@ietf.org; Mon, 29 Jan 2007 20:15:54 -0500 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0U1FqTB000733 for ; Mon, 29 Jan 2007 18:15:52 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCN00G01PX44800@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 29 Jan 2007 18:15:52 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCN000GGQ6DTI50@mail-amer.sun.com>; Mon, 29 Jan 2007 18:15:52 -0700 (MST) Date: Mon, 29 Jan 2007 17:15:49 -0800 From: Chris Newman Subject: Re: required-fields (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) In-reply-to: <5dtzy94pgl.fsf@Hurtta06k.keh.iki.fi> To: Kari Hurtta , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d7iv8zu7k.fsf@Hurtta06k.keh.iki.fi> <5dd550by0t.fsf_-_@Hurtta06k.keh.iki.fi> <5dtzy94pgl.fsf@Hurtta06k.keh.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org While this is a clever technical idea, it strikes me as over-design (something we've all done now and then ;-). This sort of "reject if you don't understand" feature has a history of either causing interoperability problems (e.g. PKIX) or being ignored (e.g. Disposition-Notification-Options, RFC 3798). It seems to me we should instead have a fixed set of "bounce-if-you-can't downgrade" headers listed in the base downgrade spec and that's it. The primary focus of this work should be to make the UTF8SMTP -> UTF8SMTP experience work well and make the UTF8SMTP -> SMTP experience not break. The UTF8SMTP -> SMTP -> UTF8SMTP experience is a tertiary case. While it's important to preserve a fixed set of critical information in that case, we have to be careful not to go overboard optimizing for a transitional case. - Chris Kari Hurtta wrote on 1/29/07 21:12 +0200: > Downgrade needs able to delete headers (when it do not > know syntax of headers). Content of these headers are > stored to some encapsulation format (for example Downgraded > -header). > > These headers may be necessary for some protocols. > That header field makes possible to sender specify that. > > UTF8-required-fields sets requirements, which header fields > downgrading process must know. It says that these headers > must exists even when message is on downgraded form. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 20:35:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhtk-0000sY-N8; Mon, 29 Jan 2007 20:35:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBhth-0000sB-Vx for ima@ietf.org; Mon, 29 Jan 2007 20:34:58 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBhtg-0001CY-9i for ima@ietf.org; Mon, 29 Jan 2007 20:34:57 -0500 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0U1YrUa020286 for ; Mon, 29 Jan 2007 18:34:53 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCN00C01R1PP700@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Mon, 29 Jan 2007 18:34:50 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCN00MBPR1O6K00@mail-amer.sun.com>; Mon, 29 Jan 2007 18:34:39 -0700 (MST) Date: Mon, 29 Jan 2007 17:34:36 -0800 From: Chris Newman Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) In-reply-to: <5dy7nl4ru5.fsf@Hurtta06k.keh.iki.fi> To: Kari Hurtta , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> <5dy7nl4ru5.fsf@Hurtta06k.keh.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Sun's MTA also parses the MIME structure. It was very thoughtful of Charles to provide perl code that proves just how simple and straightforward it is to do MIME parsing. I couldn't have supported my position as well as he did. The several C MIME parsers I've written in the past for different purposes are longer but still straightforward. The one which uses Boyer-Moore to look for MIME boundaries and mbox delimiters is a bit less simple; I was probably over-optimizing for performance when I wrote that code... - Chris Kari Hurtta wrote on 1/29/07 20:21 +0200: > "Charles Lindsey" writes in gmane.ietf.ima: > >> On Sat, 27 Jan 2007 09:24:06 -0000, Kari Hurtta >> wrote: >> > >> > Seems that parsing of MIME structure by every MTA on path >> > is quite common. So when MIME structure is parsed anyway, >> > that UTF8 indicator is not needed. >> >> What evidence do you have that this is commonly done? See my Perl >> script in reply to Chris which shows that it is hard work to do this >> properly, and generally speaking MTAs will be passing the whole body >> on untouched, and hence currently have little need to be aware of the >> MIME structure. > > On my answer to your another question I noticed that sendmail parses > MIME structure of every mail (on default configuration). > > Have you information of some other commonly used MTAs? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 22:38:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBjop-00032V-41; Mon, 29 Jan 2007 22:38:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBjoo-00032Q-Jx for ima@ietf.org; Mon, 29 Jan 2007 22:38:02 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBjom-0001pG-9l for ima@ietf.org; Mon, 29 Jan 2007 22:38:02 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 038D92596B8; Tue, 30 Jan 2007 04:34:01 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02075-10; Tue, 30 Jan 2007 04:33:56 +0100 (CET) Received: from [192.168.23.150] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 83A582580CD; Tue, 30 Jan 2007 04:33:55 +0100 (CET) Date: Mon, 29 Jan 2007 19:37:51 -0800 From: Harald Tveit Alvestrand To: Soobok Lee , ima@ietf.org Subject: Re: [EAI] other thought about > Message-ID: <27BF69182779DF65C1BE3B40@[172.19.11.21]> In-Reply-To: <20070129100855.GB30318@ns5.lsb.org> References: <20070129100855.GB30318@ns5.lsb.org> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: -0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On 29. januar 2007 19:08 +0900 Soobok Lee wrote: > > RFC822 allowed 1) below and its successor RFC2822 required angled-address > like 0). But, still we see <>-omitted 1) is popular in headers. > > With EAI, we notice that 13) != 11) if we choose >. > > 0) To: > 1) To: ascii@address <----- <> is omitted > > 2) To: display_name > 3 ) To: "display_name" > > 11) To: > > 12) To: > > 13) To: eai@address <----- > 14) To: eai@address [ascii@address] > 15) To: eai@address > 16) To: I'm happy with not allowing cases 13 and 15 in the UTF8SMTP ABNF. Let the nonconformant UTF8SMTP UA implementations fail as they may. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 22:46:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBjxM-0005ya-PV; Mon, 29 Jan 2007 22:46:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBjxL-0005yV-Bj for ima@ietf.org; Mon, 29 Jan 2007 22:46:51 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBjxK-0002Vw-2B for ima@ietf.org; Mon, 29 Jan 2007 22:46:51 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DB3472596BE for ; Tue, 30 Jan 2007 04:42:50 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08524-04 for ; Tue, 30 Jan 2007 04:42:46 +0100 (CET) Received: from [192.168.23.150] (216-239-45-4.google.com [216.239.45.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id CABC42580CD for ; Tue, 30 Jan 2007 04:42:45 +0100 (CET) Date: Mon, 29 Jan 2007 19:46:41 -0800 From: Harald Tveit Alvestrand To: EAI WG Message-ID: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: -0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [EAI] Session requested for Prague X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org FYI, I've sent a request for an EAI session for Prague (2 hours). The list of WGs to avoid is: First Priority: imapext lemonade apparea ipr lemonade ltru dkim sieve sasl dnsop ipr smime atompub krb-wg enum usefor Second Priority: dnsext crisp BOF or IRTF Sessions: please avoid conflict with BOFs of APP area If you know of other WGs that are urgent to avoid, please send them to the chairs, and we can update the request. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Jan 29 23:54:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBl0v-0008Bu-PL; Mon, 29 Jan 2007 23:54:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBl0t-00088l-G9 for ima@ietf.org; Mon, 29 Jan 2007 23:54:35 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBl0s-00062X-6m for ima@ietf.org; Mon, 29 Jan 2007 23:54:35 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HBl0h-0008Ax-AS for ima@ietf.org; Tue, 30 Jan 2007 05:54:23 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Jan 2007 05:54:23 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Jan 2007 05:54:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) Date: 30 Jan 2007 06:54:17 +0200 Lines: 29 Message-ID: <5dbqkhjerq.fsf@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> <78CDF378A62AE0D05EC763A5@[10.71.2.170]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand writes in gmane.ietf.ima: > --On 27. januar 2007 11:24 +0200 Kari Hurtta > wrote: > > > Without > > Header-Format: Downgraded > > > > heade ffiled upgrading must not be done. I think > > automatic 'upgrading' always does too much damage. > > As technical contributor, I have protested long and hard against the > term "upgrade" as anything but something that can optionally be > applied by the end-recipient after final delivery. It is still too early, if it is applied on IMAP server before MUA sees message. If "upgrading" is always done, DKIM (for example) is forced to use some other (encoded) charset than UTF-8 on headers. For example convert phrases and other places whese are signed to UTF-7 so that UTF8SMTP upgrading do not trigger. This affects also possible MIME header fields (Content-Description) on case S/MIME message. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 00:23:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBlSs-0004Jm-8p; Tue, 30 Jan 2007 00:23:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBlSq-0004Je-Ro for ima@ietf.org; Tue, 30 Jan 2007 00:23:28 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBlSp-0004i1-I8 for ima@ietf.org; Tue, 30 Jan 2007 00:23:28 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HBlSZ-0004oU-NK for ima@ietf.org; Tue, 30 Jan 2007 06:23:12 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Jan 2007 06:23:11 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Jan 2007 06:23:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: required-fields (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) Date: 30 Jan 2007 07:22:56 +0200 Lines: 29 Message-ID: <5d7iv5jdfz.fsf@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d7iv8zu7k.fsf@Hurtta06k.keh.iki.fi> <5dd550by0t.fsf_-_@Hurtta06k.keh.iki.fi> <5dtzy94pgl.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chris Newman writes in gmane.ietf.ima: > While this is a clever technical idea, it strikes me as over-design > (something we've all done now and then ;-). > > This sort of "reject if you don't understand" feature has a history of > either causing interoperability problems (e.g. PKIX) or being ignored > (e.g. Disposition-Notification-Options, RFC 3798). It seems to me we > should instead have a fixed set of "bounce-if-you-can't downgrade" > headers listed in the base downgrade spec and that's it. > > The primary focus of this work should be to make the UTF8SMTP -> > UTF8SMTP experience work well and make the UTF8SMTP -> SMTP experience > not break. > > The UTF8SMTP -> SMTP -> UTF8SMTP experience is a tertiary case. While > it's important to preserve a fixed set of critical information in that > case, we have to be careful not to go overboard optimizing for a > transitional case. > > - Chris No. That required-fields is only for UTF8SMTP -> SMTP case. UTF8SMTP -> SMTP -> UTF8SMTP is not problem, assuming that unknown header fields are encapsulated. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 01:38:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBmdH-0008G9-4P; Tue, 30 Jan 2007 01:38:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBmdF-0008G1-HK for ima@ietf.org; Tue, 30 Jan 2007 01:38:17 -0500 Received: from smtp2gate.fmi.fi ([193.166.223.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBmdE-0005cA-3f for ima@ietf.org; Tue, 30 Jan 2007 01:38:17 -0500 Received: from torkku.fmi.fi (torkku.fmi.fi [193.166.211.55]) (envelope-from hurtta@siilo.fmi.fi) by smtp2gate.fmi.fi (8.12.11.20060308/8.12.11/smtpgate-20061220) with ESMTP id l0U6cEvd030144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Jan 2007 08:38:14 +0200 Received: from siilo.fmi.fi by torkku.fmi.fi with ESMTP id l0U6cEdG016865 ; Tue, 30 Jan 2007 08:38:14 +0200 Received: from siilo.fmi.fi by siilo.fmi.fi with ESMTP id l0U6cDf7020581 ; Tue, 30 Jan 2007 08:38:13 +0200 Received: by siilo.fmi.fi id l0U6cDU7020578; Tue, 30 Jan 2007 08:38:13 +0200 Message-Id: <200701300638.l0U6cDU7020578@siilo.fmi.fi> Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) In-Reply-To: To: Chris Newman Date: Tue, 30 Jan 2007 08:38:13 +0200 (EET) From: Kari Hurtta X-Mailer: ELM [version 2.4ME+ PL123e (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtp2gate: 3 received headers rewritten with id 20070130/09486/01 X-Filter: smtp2gate: ID 9484/01, 1 parts scanned for known viruses X-Filter: torkku: ID 2493/01, 1 parts scanned for known viruses X-Spam-Flag: NO X-Spam-Status: False, hits=-2.5 required=5 (smtp2gate: ID 9484/01) report=BAYES_00,FORGED_RCVD_HELO X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org >>> Chris Newman > Sun's MTA also parses the MIME structure. > > It was very thoughtful of Charles to provide perl code that proves just how > simple and straightforward it is to do MIME parsing. I couldn't have supported > my position as well as he did. The several C MIME parsers I've written in the > past for different purposes are longer but still straightforward. The one > which uses Boyer-Moore to look for MIME boundaries and mbox delimiters is a bit > less simple; I was probably over-optimizing for performance when I wrote that > code... > > - Chris Charles' code was using MIME -module, so it was not all perl code required. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 02:16:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBnDk-00006u-EE; Tue, 30 Jan 2007 02:16:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBnDj-0008St-2Y for ima@ietf.org; Tue, 30 Jan 2007 02:15:59 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBnDh-0006Bj-Fq for ima@ietf.org; Tue, 30 Jan 2007 02:15:59 -0500 Received: from [211.72.211.94] (pc094.twnic.net.tw [211.72.211.94]) (authenticated bits=0) by twnic.net.tw (8.13.8/8.13.8) with ESMTP id l0U7FhIJ025377; Tue, 30 Jan 2007 15:15:44 +0800 Message-ID: <45BEF3A4.2010000@twnic.net.tw> Date: Tue, 30 Jan 2007 15:28:36 +0800 From: Jeff Yeh User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Harald Tveit Alvestrand Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> In-Reply-To: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Harald Tveit Alvestrand wrote: > 1. I agree with this resolution > +1 Jeff Yeh -TWNIC _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 07:58:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBsZI-0000s6-5f; Tue, 30 Jan 2007 07:58:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBsZG-0000rz-RS for ima@ietf.org; Tue, 30 Jan 2007 07:58:34 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBsZE-0004fR-EU for ima@ietf.org; Tue, 30 Jan 2007 07:58:34 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HBsZ6-0005Q3-R4; Tue, 30 Jan 2007 07:58:25 -0500 Date: Tue, 30 Jan 2007 07:58:23 -0500 From: John C Klensin To: Harald Tveit Alvestrand , Soobok Lee , ima@ietf.org Subject: Re: [EAI] other thought about > Message-ID: <3CBBE746C02F37FEB16F25A0@p3.JCK.COM> In-Reply-To: <27BF69182779DF65C1BE3B40@[172.19.11.21]> References: <20070129100855.GB30318@ns5.lsb.org> <27BF69182779DF65C1BE3B40@[172.19.11.21]> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 29 January, 2007 19:37 -0800 Harald Tveit Alvestrand wrote: >> 13) To: eai@address <----- >> 14) To: eai@address [ascii@address] >> 15) To: eai@address >> 16) To: > > I'm happy with not allowing cases 13 and 15 in the UTF8SMTP > ABNF. Note that (13), as written, would be invalid under 2821 rules. Either it would have to be interpreted as equivalent to To: willl is invalid without a comma. Or, because of the "@" the first string would need to be quoted, i.e., as To: "eas@domain" Modulo accepting the UTF-8 in what then is a quoted name-phrase ("personal name"), MUAs need to support this anyway to support "My Personal non-ascii Name" and it is not, in any sense unusual. There is even a specific downgrade, to encoded words in the personal name. I have mixed feelings, for aesthetic and historical reasons, about prohibiting (15). I won't personally lose any sleep over it, but predict that, in practice, some MUAs will display it and permit is in input and then will make mistakes and let it leak. If these then appear in headers, robustness will take over at the other end. So, I predict, we will end up with fairly broad support for it whether we prohibit and/or mandate it or not. The only case in which an unbracketed mailbox clearly needs to be prohibited is when an alt-address appears. So: Interpreting eai@domain as equivalent to and Personal name all seem safe and historically reasonable (with Personal name quoted if it contains any troublesome characters*), but there is no permitted form that contains an alt-address that does not have the entire address bracketed. * The one issue I see here is that, if unbracketed addresses are to be permitted (i.e., case 15 with personal names), then UTF8-headers is going to need to be very specific about what constitutes a "Special" in the non-ASCII space. As we have discovered while working on IDNAbis, that is not likely to be especially easy and the list will grow over time. And _that_, it seems to me, is the strongest argument for simply prohibiting case 15 and seeing where it gets us. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 08:06:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBshO-0005ph-9H; Tue, 30 Jan 2007 08:06:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBshN-0005pc-6i for ima@ietf.org; Tue, 30 Jan 2007 08:06:57 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBshK-0006I9-Cf for ima@ietf.org; Tue, 30 Jan 2007 08:06:57 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l0UD6q8H001318 for ; Tue, 30 Jan 2007 22:06:52 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 076c_c1033318_b062_11db_8dd3_0014221f2a2d; Tue, 30 Jan 2007 22:06:51 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:60689) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 30 Jan 2007 22:06:01 +0900 Message-Id: <6.0.0.20.2.20070130122812.03c131c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 30 Jan 2007 12:30:21 +0900 To: Harald Tveit Alvestrand , ima@ietf.org From: Martin Duerst Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker In-Reply-To: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 19:13 07/01/26, Harald Tveit Alvestrand wrote: >The discussion of whether or not we need a header marker for marking UTF8SMTP messages that actually use UTF-8 characters has reached a point where it seems that no new technical information is being provided. > >At this point, the chairs wish to see if the group is near a possible consensus on the issue. > >PROPOSED RESOLUTOIN: > >There is no significant operational or implementation benefit in having a marker in the headers of UTF8SMTP messages, and significant additional complexity. Therefore, the proposed "Header-Type" section, draft-ietf-eai-utf8headers-02 section 5, will be removed. > >Note that this is not a call on the proposal to have a similar marker in the SMTP protocol; that's a separate issue. > >POSSIBLE RESPONSES: > >1. I agree with this resolution I agree. I the test implementation a student of mine is working on, we haven't used this header (but we have generated it). We have implemented the sending side of SMTP in an MUA. The MUA keeps its own information on emails in draft stage or 'ready to send' stage. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 12:19:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwdE-0008A6-Nt; Tue, 30 Jan 2007 12:18:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwdD-00089i-RM for ima@ietf.org; Tue, 30 Jan 2007 12:18:55 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwd8-0005tT-OS for ima@ietf.org; Tue, 30 Jan 2007 12:18:55 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3$clerew^man^ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45bf7deb.138d3.b06 for ima@ietf.org; Tue, 30 Jan 2007 17:18:35 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0UHIXCW015175 for ; Tue, 30 Jan 2007 17:18:34 GMT Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> <5dy7nl4ru5.fsf@Hurtta06k.keh.iki.fi> Message-ID: To: IMA From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Tue, 30 Jan 2007 17:18:33 -0000 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 29 Jan 2007 18:21:06 -0000, Kari Hurtta wrote: > "Charles Lindsey" writes in gmane.ietf.ima: > >> On Sat, 27 Jan 2007 09:24:06 -0000, Kari Hurtta >> wrote: >> > >> > Seems that parsing of MIME structure by every MTA on path >> > is quite common. So when MIME structure is parsed anyway, >> > that UTF8 indicator is not needed. > 8.11.7/8.11.7 2003/03/29 > <...> > To provide partial protection for internal, unpatched MTAs that > may be > performing 7->8 or 8->7 bit MIME conversions, the default > for MaxMimeHeaderLength has been changed to 2048/1024. > Note: this does have a performance impact, and it only > protects against frontal attacks from the outside. > To disable the checks and return to pre-8.11.7 defaults, > set MaxMimeHeaderLength to 0/0. > I have just been looking through the code of sendmail, and it seems that it is done in order to avoid some buffer overflows elsewhere if Content-* headers of inordinate length are submitted. But the performance hit seems quite large, since it resuses the code that does genuine 8to7 converions - it bypasses the actual conversion bit, but still does a lot of stuff that is unnecessary for the limited purpose of checking header lengths. I doubt that other MTAs do such a complete MIME parse as a matter of routine, and there must be more efficient ways in which sendmail could have fixed this particular problem. It does, of course, check for an 8th bit set anywhere in the message as it reads it in after the DATA command (as John mentioned) for the purpose of deciding whether 8BITMIME downgrading needs to be considered. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 12:30:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwoC-00060z-Av; Tue, 30 Jan 2007 12:30:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwoB-00060t-4J for ima@ietf.org; Tue, 30 Jan 2007 12:30:15 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwo3-00015H-DS for ima@ietf.org; Tue, 30 Jan 2007 12:30:15 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HBwnc-0005A5-6h for ima@ietf.org; Tue, 30 Jan 2007 18:29:40 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Jan 2007 18:29:40 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Jan 2007 18:29:40 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) Date: 30 Jan 2007 19:29:31 +0200 Lines: 30 Message-ID: <5dmz401kzo.fsf@Hurtta06k.keh.iki.fi> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> <5dy7nl4ru5.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org "Charles Lindsey" writes in gmane.ietf.ima: > I have just been looking through the code of sendmail, and it seems that > it is done in order to avoid some buffer overflows elsewhere if Content-* > headers of inordinate length are submitted. But the performance hit seems > quite large, since it resuses the code that does genuine 8to7 converions - > it bypasses the actual conversion bit, but still does a lot of stuff that > is unnecessary for the limited purpose of checking header lengths. I doubt > that other MTAs do such a complete MIME parse as a matter of routine, and > there must be more efficient ways in which sendmail could have fixed this > particular problem. > > It does, of course, check for an 8th bit set anywhere in the message as it > reads it in after the DATA command (as John mentioned) for the purpose of > deciding whether 8BITMIME downgrading needs to be considered. Originally that was invented to protect some MUAs. Quote from RELEASE_NOTES of sendmail: 8.10.0/8.10.0 2000/03/01 <...> New option MaxMimeHeaderLength which limits the size of MIME headers and parameters within those headers. This option is intended to protect mail user agents from buffer overflow attacks. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 12:33:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwrI-0000c4-W3; Tue, 30 Jan 2007 12:33:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBwrH-0000bq-B6 for ima@ietf.org; Tue, 30 Jan 2007 12:33:27 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBwrF-0002Up-Ok for ima@ietf.org; Tue, 30 Jan 2007 12:33:27 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3^clerew&man&ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45bf8164.c1d5.270 for ima@ietf.org; Tue, 30 Jan 2007 17:33:24 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0UHXN0D016430 for ; Tue, 30 Jan 2007 17:33:24 GMT Date: Tue, 30 Jan 2007 17:33:23 -0000 To: IMA Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <45BCFD71.6225@xyzzy.claranet.de> <5103A2A292C8E4D9539C0944@[172.19.11.21]> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <5103A2A292C8E4D9539C0944@[172.19.11.21]> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 29 Jan 2007 19:18:50 -0000, Harald Tveit Alvestrand wrote: > --On 29. januar 2007 11:13 +0000 Charles Lindsey > wrote: >> But I suspect those languages mostly do not need the language >> information >> to assist in the display process, whereas I would imagine that it is >> useful for a user agent to know whether it is displaying Chinese or >> Japanese, even though those languages use essentially the same "CJK" >> parts of Unicode. > > Have you read RFC 2277? Yes, the relevant bit seems to be: Many operations, including high quality formatting, text-to-speech synthesis, searching, hyphenation, spellchecking and so on benefit greatly from access to information about the language of a piece of text. [WC 3.1.1.4]. Which seems to cover the sort of situation that I mentioned. Protocols that transfer text MUST provide for carrying information about the language of that text. Protocols SHOULD also provide for carrying information about the language of names, where appropriate. And, within headers, that would seem to apply to s, s and s (e.g. in Subjects), all of which can freely use UTF8 in our proposals. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 12:48:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBx5L-0007AJ-MG; Tue, 30 Jan 2007 12:47:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBx5K-00079j-DC for ima@ietf.org; Tue, 30 Jan 2007 12:47:58 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBx5F-00069v-RY for ima@ietf.org; Tue, 30 Jan 2007 12:47:58 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3$clerew$man*ac$uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45bf84c8.6350.116 for ima@ietf.org; Tue, 30 Jan 2007 17:47:52 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0UHlp7B017386 for ; Tue, 30 Jan 2007 17:47:52 GMT To: IMA Subject: Re: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft)) References: <458A154A.4090707@twnic.net.tw> <45AEEB62.6010606@twnic.net.tw> <45AF2466.5040005@alvestrand.no> <66B5502F24092DF658DA31DF@p3.JCK.COM> <3D816681DA860388277BBD70@p3.JCK.COM> <57ACEF55BFEC77C25C94A683@p3.JCK.COM> Message-ID: Date: Tue, 30 Jan 2007 17:47:51 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 30 Jan 2007 00:31:51 -0000, John C Klensin wrote: > Incidentally, Charles, I don't know if Chris would agree, but, > if I were designing a mail store, I'd either make sure that > everything was stored in native form (Chris's "identity") or I > would record (somewhere) whatever the scanning process figured > out about what was present because I might want to have that > information handy to decide what sorts of mail-reader inquiries > to accept, etc. But that, again, is not a case for an > on-the-wire message header. Absolutely. In an end-to-end world, that "identity" is the only reality. The only reason one might keep the encoded form in the mail store is for diagnostic/forensic purposes. That was, incidentally, one of the problems I had with DKIM. They sign the body of a message in its on-the-wire form, and so subsequent changes of encoding (e.g. for downgrading in 8BITMIME) will break it. They get around that by RECOMMENDING that all signed messages should be sent in 7bit form, which is the last thing we would want to be doing with our UTF8SMTP messages. Anyway, I am invited to prepare a draft for a canonicalization which always signs the "identity", and I may well do just that when Round Tuits become available. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 12:58:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBxFG-0002kd-Dw; Tue, 30 Jan 2007 12:58:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBxFF-0002kX-Hy for ima@ietf.org; Tue, 30 Jan 2007 12:58:13 -0500 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBxFE-0000Ff-0S for ima@ietf.org; Tue, 30 Jan 2007 12:58:13 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3^clerew&man^ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45bf8733.b3f5.423 for ima@ietf.org; Tue, 30 Jan 2007 17:58:11 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0UHw9oZ018005 for ; Tue, 30 Jan 2007 17:58:10 GMT To: IMA Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> <5dy7nl4ru5.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Tue, 30 Jan 2007 17:58:09 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 30 Jan 2007 01:34:36 -0000, Chris Newman wrote: > Sun's MTA also parses the MIME structure. I thought Sun still used sendmail. For sure, that is what comes with all Solaris versions <= 10. > > It was very thoughtful of Charles to provide perl code that proves just > how simple and straightforward it is to do MIME parsing. I couldn't > have supported my position as well as he did. The several C MIME > parsers I've written in the past for different purposes are longer but > still straightforward. The one which uses Boyer-Moore to look for MIME > boundaries and mbox delimiters is a bit less simple; I was probably > over-optimizing for performance when I wrote that code... It is simple conceptually (provided you spot all the bits that need attention), but it is a significant performance hit if it has to be repeated on every email that passes through every agent. And, as I said, it is unlikely to happen in people's ad hoc scripts. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 14:06:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HByJ0-0004q2-Tg; Tue, 30 Jan 2007 14:06:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HByJ0-0004ps-0g for ima@ietf.org; Tue, 30 Jan 2007 14:06:10 -0500 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HByIw-0004ck-EH for ima@ietf.org; Tue, 30 Jan 2007 14:06:09 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3*clerew*man&ac#uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45bf971b.41c.58 for ima@ietf.org; Tue, 30 Jan 2007 19:06:03 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0UJ61QP022119 for ; Tue, 30 Jan 2007 19:06:01 GMT Date: Tue, 30 Jan 2007 19:06:00 -0000 To: IMA Subject: Re: [EAI] other thought about > References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20070130000617.GD30318@ns5.lsb.org> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 30 Jan 2007 00:06:17 -0000, Soobok Lee wrote: > On Mon, Jan 29, 2007 at 07:40:14PM -0000, Charles Lindsey wrote: >> On Mon, 29 Jan 2007 10:08:55 -0000, Soobok Lee wrote: >> >> >13) To: eai@address <----- >> >14) To: eai@address [ascii@address] >> >> AFAIK, out utf8headers draft does not permit either of those (and if it >> does, it needs to be fixed). >> >> >15) To: eai@address >> >16) To: >> >> And utf8headers permits (I hope) both of those, > I think it is clear that we don't want (13) (we have carefully arranged that alt-addresses always occur inside of <...>. However, I think (15) is needed, simply in order to make eai@address (with no alt) be as similar as possible to the present ascii@address. > > It is clear that 16) is allowed in [utf8headers] excerpts below. > But, I can't find any link between RFC2822(RFC822) <-> [utf8headers] > that explicitly allows 15) . No, it seems not. > But, I find this clause is required to allow 15) in [utf8headers]. > > > mailbox = name-addr / addr-spec / utf8-addr-spec <---- > Yes, I think that is what is needed. Note also that there are some other bugs in that area of the syntax that need fixing, as I reported on 21st Dec. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 18:34:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2Uc-0002ea-27; Tue, 30 Jan 2007 18:34:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2Ub-0002di-AY for ima@ietf.org; Tue, 30 Jan 2007 18:34:25 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC2UW-0006ob-LF for ima@ietf.org; Tue, 30 Jan 2007 18:34:25 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l0UNYAJ5005207; Wed, 31 Jan 2007 08:34:11 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l0UNY9O5005206; Wed, 31 Jan 2007 08:34:09 +0900 Date: Wed, 31 Jan 2007 08:34:09 +0900 From: Soobok Lee To: Charles Lindsey Subject: Re: [EAI] other thought about > Message-ID: <20070130233409.GF30318@ns5.lsb.org> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, Jan 30, 2007 at 07:06:00PM -0000, Charles Lindsey wrote: > On Tue, 30 Jan 2007 00:06:17 -0000, Soobok Lee wrote: > > >On Mon, Jan 29, 2007 at 07:40:14PM -0000, Charles Lindsey wrote: > >>On Mon, 29 Jan 2007 10:08:55 -0000, Soobok Lee wrote: > >> > >>>13) To: eai@address <----- > >>>14) To: eai@address [ascii@address] > >> > >>AFAIK, out utf8headers draft does not permit either of those (and if it > >>does, it needs to be fixed). > >> > >>>15) To: eai@address > >>>16) To: > >> > >>And utf8headers permits (I hope) both of those, > > > I think it is clear that we don't want (13) (we have carefully arranged > that alt-addresses always occur inside of <...>. I agree that we don't need 13) for EAI. But, anyway, old email address parsers will recognize 13) as "eai@address" because double quotation marks are often omitted from display name parts and parsers have done well with this for "robustness". Even this WG email header has : "To: IMA ". IMA has no double quotations marks surrounding it. Most MUAs' cheking of input of 13) into headers won't produce errors, and programmers may not notice their mistakes. Soobok > However, I think (15) is > needed, simply in order to make eai@address (with no alt) be as similar as > possible to the present ascii@address. > > > >It is clear that 16) is allowed in [utf8headers] excerpts below. > >But, I can't find any link between RFC2822(RFC822) <-> [utf8headers] > >that explicitly allows 15) . > > No, it seems not. > > >But, I find this clause is required to allow 15) in [utf8headers]. > > > > > >mailbox = name-addr / addr-spec / utf8-addr-spec <---- > > > > Yes, I think that is what is needed. > > Note also that there are some other bugs in that area of the syntax that > need fixing, as I reported on 21st Dec. > > -- > Charles?H.?Lindsey?---------At?Home,?doing?my?own?thing------------------------ > Tel:?+44?161?436?6131? > ???Web:?http://www.cs.man.ac.uk/~chl > Email:?chl@clerew.man.ac.uk??????Snail:?5?Clerewood?Ave,?CHEADLE,?SK8?3JU,?U.K. > PGP:?2C15F1A9??????Fingerprint:?73?6D?C2?51?93?A0?01?E7?65?E8?64?7E?14?A4?AB?A5 > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 18:45:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2fb-0000Gz-HP; Tue, 30 Jan 2007 18:45:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC2fZ-0000Dt-WA for ima@ietf.org; Tue, 30 Jan 2007 18:45:45 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC2fY-0001rY-Ly for ima@ietf.org; Tue, 30 Jan 2007 18:45:45 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HC2fM-000AHm-81; Tue, 30 Jan 2007 18:45:32 -0500 Date: Tue, 30 Jan 2007 18:45:31 -0500 From: John C Klensin To: Soobok Lee , Charles Lindsey Subject: Re: [EAI] other thought about > Message-ID: <7518047A15D398D1797627E5@p3.JCK.COM> In-Reply-To: <20070130233409.GF30318@ns5.lsb.org> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 31 January, 2007 08:34 +0900 Soobok Lee wrote: > I agree that we don't need 13) for EAI. > > But, anyway, old email address parsers will recognize 13) > as "eai@address" > because double quotation marks are often omitted from display > name parts and parsers have done well with this for > "robustness". I think you will find that none of them accept an unquoted personal string containing an "@"-sign and will treat it as a personal name. If that "@" is there, even the most liberal of systems will treat that case as either an error or as two addresses. > Even this WG email header has : "To: IMA ". > IMA has no double quotations marks surrounding it. Sigh. Quotation marks have never been required, or even recommended in that case. For your amusement, the exact rule is the reason why I stopped using a period after the "C" in "John C Klensin", which doesn't use quotation marks either. I suggest that you might find reading the specification useful. > Most MUAs' cheking of input of 13) into headers won't produce > errors, and programmers may not notice their mistakes. See above. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 19:22:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3EJ-0000Fn-A6; Tue, 30 Jan 2007 19:21:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3EI-0000Fi-Bo for ima@ietf.org; Tue, 30 Jan 2007 19:21:38 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC3EG-0003lg-OE for ima@ietf.org; Tue, 30 Jan 2007 19:21:38 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l0V0LUJ5011284; Wed, 31 Jan 2007 09:21:30 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l0V0LUia011283; Wed, 31 Jan 2007 09:21:30 +0900 Date: Wed, 31 Jan 2007 09:21:30 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] other thought about > Message-ID: <20070131002129.GG30318@ns5.lsb.org> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7518047A15D398D1797627E5@p3.JCK.COM> User-Agent: Mutt/1.4i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns5.lsb.org id l0V0LUJ5011284 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Charles Lindsey , IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, Jan 30, 2007 at 06:45:31PM -0500, John C Klensin wrote: >=20 >=20 > --On Wednesday, 31 January, 2007 08:34 +0900 Soobok Lee > wrote: >=20 > > I agree that we don't need 13) for EAI.=20 > >=20 > > But, anyway, old email address parsers will recognize 13) > > as "eai@address" =20 > > because double quotation marks are often omitted from display > > name parts and parsers have done well with this for > > "robustness". >=20 > I think you will find that none of them accept an unquoted > personal string containing an "@"-sign and will treat it as a > personal name. If that "@" is there, even the most liberal of > systems will treat that case as either an error or as two > addresses. I have not tested every email address parser, but=20 with my favorite PERL email address parser, I found this. #!/usr/bin/perl use Mail::Address; $line=3D'=ED=95=9C=EA=B8=80@=EB=8F=84=EB=A9=94=EC=9D=B8.tld = '; my @addrs =3D Mail::Address->parse($line); foreach $addr (@addrs) { print "PHRASE: ", $addr->phrase,"\n"; print "ADDRESS: ", $addr->address,"\n"; } # output PHRASE: =ED=95=9C=EA=B8=80 @ =EB=8F=84=EB=A9=94=EC=9D=B8 . tld ADDRESS: abc@top.tld=20 >=20 > > Even this WG email header has : "To: IMA ". > > IMA has no double quotations marks surrounding it. >=20 > Sigh. Quotation marks have never been required, or even > recommended in that case. For your amusement, the exact rule is > the reason why I stopped using a period after the "C" in "John C > Klensin", which doesn't use quotation marks either. I suggest > that you might find reading the specification useful. You are right. I have bad habits of relying on my limited=20 knowledge rather than on careful reading of specifications.=20 I will correct that. Unquoted word streams can be a valid display-name. But, i can't find any rules that exclude "@" from part of=20 display-name. address =3D mailbox / group mailbox =3D name-addr / addr-spec name-addr =3D [display-name] angle-addr ..... display-name =3D phrase ..... phrase =3D 1*word / obs-phrase word =3D atom / quoted-string <----------- .... obs-phrase =3D word *(word / "." / CFWS) .... quoted-string =3D [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS] (these syntax rules are scattered around rfc2822 draft). Soobok >=20 > > Most MUAs' cheking of input of 13) into headers won't produce > > errors, and programmers may not notice their mistakes. >=20 > See above. >=20 > john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 20:00:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3q6-0002Si-Uu; Tue, 30 Jan 2007 20:00:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3q5-0002SW-3E for ima@ietf.org; Tue, 30 Jan 2007 20:00:41 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC3q3-0006Pn-GV for ima@ietf.org; Tue, 30 Jan 2007 20:00:41 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l0V10WJ5016751; Wed, 31 Jan 2007 10:00:32 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l0V10W0U016750; Wed, 31 Jan 2007 10:00:32 +0900 Date: Wed, 31 Jan 2007 10:00:32 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] other thought about > Message-ID: <20070131010031.GH30318@ns5.lsb.org> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <20070131002129.GG30318@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070131002129.GG30318@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Charles Lindsey , IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, Jan 31, 2007 at 09:21:30AM +0900, Soobok Lee wrote: > Unquoted word stream can be a valid display-name. > But, i can't find any rules that exclude "@" from part of > display-name. > > > address = mailbox / group > > mailbox = name-addr / addr-spec > > name-addr = [display-name] angle-addr > > ..... > > display-name = phrase > > ..... > > phrase = 1*word / obs-phrase > > word = atom / quoted-string <----------- > > .... > > obs-phrase = word *(word / "." / CFWS) > > .... > > quoted-string = [CFWS] > DQUOTE *([FWS] qcontent) [FWS] DQUOTE > [CFWS] > atext = ALPHA / DIGIT / ; Any character except controls, "!" / "#" / ; SP, and specials. "$" / "%" / ; Used for atoms "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" atom = [CFWS] 1*atext [CFWS] dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom-text = 1*atext *("." 1*atext) ..... qtext = NO-WS-CTL / ; Non white space controls %d33 / ; The rest of the US-ASCII %d35-91 / ; characters not including "\" %d93-126 ; or the quote character qcontent = qtext / quoted-pair quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS] It's clear that "atom" cannot contain "@" while "qcontent" can contain "@". So, if my reading of rfc2822 is correct, @-containing phrase should be put in double quotations. In other words, according to rfc2822 syntax rules, eai@address : invalid "eai@address" : valid Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 20:50:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC4c7-0002xR-BM; Tue, 30 Jan 2007 20:50:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC4c6-0002xF-FC for ima@ietf.org; Tue, 30 Jan 2007 20:50:18 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC4bq-0005Wq-3u for ima@ietf.org; Tue, 30 Jan 2007 20:50:18 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HC4bf-000BAX-BN; Tue, 30 Jan 2007 20:49:51 -0500 Date: Tue, 30 Jan 2007 20:49:50 -0500 From: John C Klensin To: Soobok Lee Subject: Re: [EAI] other thought about > Message-ID: <114B335272043EA96C9299FA@p3.JCK.COM> In-Reply-To: <20070131010031.GH30318@ns5.lsb.org> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <20070131002129.GG30318@ns5.lsb.org> <20070131010031.GH30318@ns5.lsb.org> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Charles Lindsey , IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 31 January, 2007 10:00 +0900 Soobok Lee wrote: > > > atext = ALPHA / DIGIT / ; Any character except > controls, "!" / "#" / ; SP, and > specials. "$" / "%" / ; Used for > atoms "&" / "'" / > "*" / "+" / > "-" / "/" / > "=" / "?" / > "^" / "_" / > "`" / "{" / > "|" / "}" / > "~" > > atom = [CFWS] 1*atext [CFWS] > > dot-atom = [CFWS] dot-atom-text [CFWS] > > dot-atom-text = 1*atext *("." 1*atext) > > ..... > > qtext = NO-WS-CTL / ; Non white space > controls > > %d33 / ; The rest of the > US-ASCII %d35-91 / ; characters > not including "\" %d93-126 ; > or the quote character > > qcontent = qtext / quoted-pair > > quoted-string = [CFWS] > DQUOTE *([FWS] qcontent) [FWS] DQUOTE > [CFWS] > > > > It's clear that "atom" cannot contain "@" while "qcontent" can > contain "@". > > So, if my reading of rfc2822 is correct, @-containing phrase > should be put in double quotations. In other words, according > to rfc2822 syntax rules, > > eai@address : invalid > "eai@address" : valid Yes, exactly... as long as all of "eai@address" are ASCII. If they are not, 2822, which is entirely about ASCII, requires the contents of that qcontent be encoded words. I know you know that, but the notation about is a little unclear so, to be completely precise... Presumably, we are making up different rules about the contents of that qcontent in messages with UTF-8 headers (I suppose we will call that something like "uqcontent"), but the rule about ASCII special characters should remain intact to avoid the ambiguity that would otherwise occur in these cases. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 21:10:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC4vH-0005ae-KC; Tue, 30 Jan 2007 21:10:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC4vG-0005aY-S4 for ima@ietf.org; Tue, 30 Jan 2007 21:10:06 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC4vF-0001iD-7z for ima@ietf.org; Tue, 30 Jan 2007 21:10:06 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l0V29wJ5027880; Wed, 31 Jan 2007 11:09:58 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l0V29wHU027878; Wed, 31 Jan 2007 11:09:58 +0900 Date: Wed, 31 Jan 2007 11:09:58 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] other thought about > Message-ID: <20070131020958.GI30318@ns5.lsb.org> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <20070131002129.GG30318@ns5.lsb.org> <20070131010031.GH30318@ns5.lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070131010031.GH30318@ns5.lsb.org> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Charles Lindsey , IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, Jan 31, 2007 at 10:00:32AM +0900, Soobok Lee wrote: > qtext = NO-WS-CTL / ; Non white space controls > > %d33 / ; The rest of the US-ASCII > %d35-91 / ; characters not including "\" > %d93-126 ; or the quote character > > qcontent = qtext / quoted-pair > > quoted-string = [CFWS] > DQUOTE *([FWS] qcontent) [FWS] DQUOTE > [CFWS] > > > > It's clear that "atom" cannot contain "@" while "qcontent" can contain "@". > > So, if my reading of rfc2822 is correct, @-containing phrase should be > put in double quotations. In other words, according to rfc2822 syntax rules, > > 21) eai@address : invalid > 22) "eai@address" : valid RFC2822's "qtext" definition does not allow non-ascii characters and 22) may be also invalid if it is not in QuotedPrintable or etc, under RFC2822. But, under [utf8headers], 22) is valid, since "qtext" is redefined to contain non-ascii UTF-8 encoded characters ( see below). So, if EAI-capable MUAs treat 22) as valid one, some of them may treat 21) as equivalent to 22) for "robustness" and permit, as my previous PERL (Mail::Address) parser example shows. Soobok Yeh Expires April 26, 2007 [Page 6] UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 = %xC2-DF UTF8-tail UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2(UTF8-tail) / %xED %x80-9F UTF8-tail / %xEE-EF 2(UTF8-tail) UTF8-4 = %xF0 %x90-BF 2(UTF8-tail) / %xF1-F7 3(UTF8-tail) UTF8-tail = %x80-BF These are taken from FRC 3629, but kept in this document for reasons of convenience. [Note in draft: Weather normalizing is needed or not will be place in here.] 6.2. Syntax extend from RFC 2822 The following rules are intended to extend the corresponding rules in RFC 2822 to allow UTF8 characters. ctext = NO-WS-CTL / ; all of except %d33-39 / ; SP, HTAB, "(", ")" %d42-91 / ; and "\" %d93-126 / UTF8-xtra-char qtext = NO-WS-CTL / ; all of except %d33 / ; The rest of the US-ASCII %d35-91 / ; characters not including "\" %d93-126 / ; or the quote character UTF8-xtra-char <--------------------- ... utf8-atext = ALPHA / DIGIT / "!" / "#" / ; Any character except "$" / "%" / ; controls, SP, and specials. "&" / "'" / ; Used for atoms "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" / UTF8-xtra-char <------------------ utf8-atom = [CFWS] 1*utf8-atext [CFWS] utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS] utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Jan 30 21:21:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC56C-00018h-IU; Tue, 30 Jan 2007 21:21:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC56B-00018c-Mg for ima@ietf.org; Tue, 30 Jan 2007 21:21:23 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC569-0004dV-18 for ima@ietf.org; Tue, 30 Jan 2007 21:21:23 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58901) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1HC55l-0002s8-Ms (Exim 4.63) for ima@ietf.org (return-path ); Wed, 31 Jan 2007 02:20:57 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HC55l-0003OW-08 (Exim 4.54) for ima@ietf.org (return-path ); Wed, 31 Jan 2007 02:20:57 +0000 Date: Wed, 31 Jan 2007 02:20:57 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: ima@ietf.org Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Mon, 29 Jan 2007, Internet-Drafts@ietf.org wrote: > > Title : International Delivery and Disposition Notifications > Author(s) : C. Newman > Filename : draft-ietf-eai-dsn-00.txt MIME forbids the encoding of message/* parts, so a message/utf-8 part would have to be downgraded instead. Note that new message/* parts inside 8bit messages will cause problems for existing 8BITMIME downgraders. I did wonder why text/rfc822-headers was not message/rfc822-headers, so I think the introduction of message/utf-8-headers is an improvement. The caveats about downgrading instead of encoding apply here too. The message/utf-8-delivery-status and -disposition-notification types will also need to be downgraded to their 7bit originals in some cases. This can probably be done fairly easily using the utf-8-enc address type. However there remains the problem of how to handle utf-8 SMTP response texts (if they become permitted) in DSNs. Tony. -- f.a.n.finch http://dotat.at/ ROCKALL MALIN HEBRIDES BAILEY: SOUTHWEST 7 TO SEVERE GALE 9, LATER DECREASING 5 OR 6. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. OCCASIONAL RAIN. MODERATE OR GOOD. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 03:18:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCAf0-0003po-BL; Wed, 31 Jan 2007 03:17:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCAey-0003pc-6j for ima@ietf.org; Wed, 31 Jan 2007 03:17:40 -0500 Received: from twnic.net.tw ([211.72.210.250]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCAew-00004x-JR for ima@ietf.org; Wed, 31 Jan 2007 03:17:40 -0500 Received: from [211.72.211.94] (pc094.twnic.net.tw [211.72.211.94]) (authenticated bits=0) by twnic.net.tw (8.13.8/8.13.8) with ESMTP id l0V8HQGV009423; Wed, 31 Jan 2007 16:17:27 +0800 Message-ID: <45C05399.8060103@twnic.net.tw> Date: Wed, 31 Jan 2007 16:30:17 +0800 From: Jeff Yeh User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] other thought about > References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > On Tue, 30 Jan 2007 00:06:17 -0000, Soobok Lee wrote: > >> On Mon, Jan 29, 2007 at 07:40:14PM -0000, Charles Lindsey wrote: >>> On Mon, 29 Jan 2007 10:08:55 -0000, Soobok Lee wrote: >>> >>> >13) To: eai@address <----- >>> >14) To: eai@address [ascii@address] >>> >>> AFAIK, out utf8headers draft does not permit either of those (and if it >>> does, it needs to be fixed). >>> >>> >15) To: eai@address >>> >16) To: >>> >>> And utf8headers permits (I hope) both of those, >> > I think it is clear that we don't want (13) (we have carefully arranged > that alt-addresses always occur inside of <...>. However, I think (15) > is needed, simply in order to make eai@address (with no alt) be as > similar as possible to the present ascii@address. Speak as the editor of utf8header, my intension is not to allow 13 and 15. As discussed in previous posts, I think it makes sense that 15 is allowed as we use ascii@address right now. >> >> >> mailbox = name-addr / addr-spec / utf8-addr-spec <---- >> Thanks, this will be added, see above. I'm personally prefer just for good looking reason (and also easier parsing with RE, for me). Making fewer confusing on the address representation. But I don't have strong reason to against > at this point. Regards, Jeff Yeh -TWNIC _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 07:15:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCEN8-0001hl-Ts; Wed, 31 Jan 2007 07:15:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCEN7-0001hg-QA for ima@ietf.org; Wed, 31 Jan 2007 07:15:29 -0500 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCEN6-0001vW-9A for ima@ietf.org; Wed, 31 Jan 2007 07:15:29 -0500 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l0VCF3RJ021288 for ; Wed, 31 Jan 2007 21:15:16 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007013121151022852 for ; Wed, 31 Jan 2007 21:15:10 +0900 Date: Wed, 31 Jan 2007 21:15:10 +0900 (JST) Message-Id: <20070131.211510.88494117.fujiwara@jprs.co.jp> To: ima@ietf.org Subject: Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker From: fujiwara@jprs.co.jp In-Reply-To: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org 1. I agree with this resolution In downgrading, we can use 'Downgraded:' header as a downgraded marker. -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 07:15:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCENa-0001lB-9A; Wed, 31 Jan 2007 07:15:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCENY-0001kL-K1 for ima@ietf.org; Wed, 31 Jan 2007 07:15:56 -0500 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCENV-00025i-S7 for ima@ietf.org; Wed, 31 Jan 2007 07:15:56 -0500 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l0VCFrR9021307 for ; Wed, 31 Jan 2007 21:15:53 +0900 (JST) Received: (from localhost [172.18.4.45]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007013121155222855 for ; Wed, 31 Jan 2007 21:15:52 +0900 Date: Wed, 31 Jan 2007 21:15:52 +0900 (JST) Message-Id: <20070131.211552.23029332.fujiwara@jprs.co.jp> To: ima@ietf.org Subject: Re: [EAI] CONSENSUS CALL: Header format for alt-addr From: fujiwara@jprs.co.jp In-Reply-To: References: X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > From: Harald Tveit Alvestrand > > 1. I agree with this resolution -- Kazunori Fujiwara, JPRS _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 09:07:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCG7W-000380-1p; Wed, 31 Jan 2007 09:07:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCG7U-00037r-Cs for ima@ietf.org; Wed, 31 Jan 2007 09:07:28 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCG7T-00015A-3s for ima@ietf.org; Wed, 31 Jan 2007 09:07:28 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HCG7S-000GOy-Ep; Wed, 31 Jan 2007 09:07:26 -0500 Date: Wed, 31 Jan 2007 09:07:25 -0500 From: John C Klensin To: Charles Lindsey , IMA Subject: Re: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft)) Message-ID: <89F0DCA1E9802A1BB23DC917@p3.JCK.COM> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 30 January, 2007 17:47 +0000 Charles Lindsey wrote: > That was, incidentally, one of the problems I had with DKIM. > They sign the body of a message in its on-the-wire form, and > so subsequent changes of encoding (e.g. for downgrading in > 8BITMIME) will break it. They get around that by RECOMMENDING > that all signed messages should be sent in 7bit form, which is > the last thing we would want to be doing with our UTF8SMTP > messages. And this is exactly why we can't try to fix DKIM or make adjustments for them. As long as they have a recommendation for 7bit-only messages (assuming that is the case), there is nothing that we can usefully do -- they need to fix their own protocol, presumably after we finish, or they need to look at our work and make recommendations that represent DKIM WG consensus. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 09:43:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGg7-0004UO-SS; Wed, 31 Jan 2007 09:43:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGg7-0004UJ-7N for ima@ietf.org; Wed, 31 Jan 2007 09:43:15 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGg4-00043N-UN for ima@ietf.org; Wed, 31 Jan 2007 09:43:15 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:40532) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1HCGf2-00015y-PA (Exim 4.63) (return-path ); Wed, 31 Jan 2007 14:42:08 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HCGf2-00085Y-NA (Exim 4.54) (return-path ); Wed, 31 Jan 2007 14:42:08 +0000 Date: Wed, 31 Jan 2007 14:42:08 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Jeff Yeh Subject: Re: [EAI] other thought about > In-Reply-To: <45C05399.8060103@twnic.net.tw> Message-ID: References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <45C05399.8060103@twnic.net.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 31 Jan 2007, Jeff Yeh wrote: > > I'm personally prefer just for good looking > reason (and also easier parsing with RE, for me). Making fewer confusing on > the address representation. But I don't have strong reason to against > > at this point. I agree with you and Soobok Lee on this matter. Tony. -- f.a.n.finch http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE FORTIES: WEST OR SOUTHWEST 7 TO SEVERE GALE 9, VEERING NORTHWEST 5 OR 6, BACKING SOUTHWEST 4 FOR A TIME. ROUGH OR VERY ROUGH, OCCASIONALLY MODERATE LATER. RAIN AT TIMES. GOOD, OCCASIONALLY MODERATE OR POOR. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 10:11:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCH7a-00010c-Df; Wed, 31 Jan 2007 10:11:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCH7Z-00010M-F1 for ima@ietf.org; Wed, 31 Jan 2007 10:11:37 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCH7Q-0003oK-Es for ima@ietf.org; Wed, 31 Jan 2007 10:11:37 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HCH7N-00042X-9Q for ima@ietf.org; Wed, 31 Jan 2007 16:11:25 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Jan 2007 16:11:25 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Jan 2007 16:11:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] other thought about > Date: 31 Jan 2007 17:11:12 +0200 Lines: 92 Message-ID: <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin writes in gmane.ietf.ima: > --On Wednesday, 31 January, 2007 08:34 +0900 Soobok Lee > wrote: > > > I agree that we don't need 13) for EAI. > > > > But, anyway, old email address parsers will recognize 13) > > as "eai@address" > > because double quotation marks are often omitted from display > > name parts and parsers have done well with this for > > "robustness". > > I think you will find that none of them accept an unquoted > personal string containing an "@"-sign and will treat it as a > personal name. If that "@" is there, even the most liberal of > systems will treat that case as either an error or as two > addresses. Seems that my MUA does accept eai@address as phrase ('<' is actual trigger, not '@' ). So your claim is wrong (about "none" part). / Kari Hurtta hurtta@Hurtta06k:~$ cat X >From xx Wed Jan 31 17:02:11 EET 2007 From: eai@address hurtta@Hurtta06k:~$ Display: ------------------------------------------------ Message 1/1 eai @ address Jan 31, 2007 05:02:11 pm EET >From xx Wed Jan 31 17:02:11 EET 2007 From: eai @ address -------------------------------------------------------- Debug output: ---------------------------------------------- ----- Message 1 ----- Lines: 4 Status: A C D E N P T U V O R M P U N Content-Length: 0 c o e x e r a r i l e i r s H Binary: 0 t n l p w i g g s d p m e u d 'From ' on body: 0 n f d d v d n i l e M p r Offset: 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 Received on: Wed Jan 31 17:02:11 2007 Message sent on: Wed Jan 31 17:02:11 2007 >From timezone: EET (7200) (Env) From: xx From: eai @ address Subject: Internal Index Reference Number = 0/0 (hdr index 1) Thread number = -1 Message-ID: Status: Content-Transfer-Encoding: 7bit ---------------------------------------------------------- Debug output actually says that phrase was "eai @ address" and address was "ascii@address". Also reply shows same: hurtta@Hurtta06k:~$ cat Canceled.mail.dir/13544-43.Canceled.mail Subject: Re: your mail In-Reply-To: To: "eai @ address" Date: Wed, 31 Jan 2007 17:06:12 +0200 (EET) Sender: hurtta From: Kari Hurtta X-Mailer: ELM [version ME+ 2.5 PLalpha13] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Return-path: Content-Length: 31 Status: RO eai @ address : hurtta@Hurtta06k:~$ _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 10:30:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHPn-00056h-NG; Wed, 31 Jan 2007 10:30:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHPm-00056L-7z for ima@ietf.org; Wed, 31 Jan 2007 10:30:26 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHPk-0001KT-UH for ima@ietf.org; Wed, 31 Jan 2007 10:30:26 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HCHPP-0006tJ-J9 for ima@ietf.org; Wed, 31 Jan 2007 16:30:04 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Jan 2007 16:30:03 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Jan 2007 16:30:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft)) Date: 31 Jan 2007 17:29:53 +0200 Lines: 28 Message-ID: <5dejpb6wpa.fsf@Hurtta06k.keh.iki.fi> References: <89F0DCA1E9802A1BB23DC917@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin writes in gmane.ietf.ima: > --On Tuesday, 30 January, 2007 17:47 +0000 Charles Lindsey > wrote: > > > That was, incidentally, one of the problems I had with DKIM. > > They sign the body of a message in its on-the-wire form, and > > so subsequent changes of encoding (e.g. for downgrading in > > 8BITMIME) will break it. They get around that by RECOMMENDING > > that all signed messages should be sent in 7bit form, which is > > the last thing we would want to be doing with our UTF8SMTP > > messages. > > And this is exactly why we can't try to fix DKIM or make > adjustments for them. As long as they have a recommendation for > 7bit-only messages (assuming that is the case), there is nothing > that we can usefully do -- they need to fix their own protocol, > presumably after we finish, or they need to look at our work and > make recommendations that represent DKIM WG consensus. > > john Well, there is that encapsulation draft which you strongly encouraged me to write :-) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 10:41:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHam-0002Z7-0R; Wed, 31 Jan 2007 10:41:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHak-0002Yh-U1 for ima@ietf.org; Wed, 31 Jan 2007 10:41:46 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCHaj-0008Pa-IB for ima@ietf.org; Wed, 31 Jan 2007 10:41:46 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HCHaP-0000Yf-Uj for ima@ietf.org; Wed, 31 Jan 2007 16:41:26 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Jan 2007 16:41:25 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Jan 2007 16:41:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt Date: 31 Jan 2007 17:41:13 +0200 Lines: 23 Message-ID: <5dabzz6w6e.fsf@Hurtta06k.keh.iki.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Tony Finch writes in gmane.ietf.ima: > On Mon, 29 Jan 2007, Internet-Drafts@ietf.org wrote: > > > > Title : International Delivery and Disposition Notifications > > Author(s) : C. Newman > > Filename : draft-ietf-eai-dsn-00.txt > > MIME forbids the encoding of message/* parts, so a message/utf-8 part > would have to be downgraded instead. Note that new message/* parts inside > 8bit messages will cause problems for existing 8BITMIME downgraders. > > I did wonder why text/rfc822-headers was not message/rfc822-headers, so I > think the introduction of message/utf-8-headers is an improvement. The > caveats about downgrading instead of encoding apply here too. For unknown text/* types there is on MIME default that they should displayed as text/plain. Other unknown types is required to be treated as application/octet-stream. Therefore text/rfc822-headers makes sense. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 11:34:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIPL-0007Zq-Fk; Wed, 31 Jan 2007 11:34:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIPJ-0007Zl-Tv for ima@ietf.org; Wed, 31 Jan 2007 11:34:01 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCIPI-0006NO-Kn for ima@ietf.org; Wed, 31 Jan 2007 11:34:01 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HCIPI-000Hep-9B; Wed, 31 Jan 2007 11:34:00 -0500 Date: Wed, 31 Jan 2007 11:33:59 -0500 From: John C Klensin To: Kari Hurtta , ima@ietf.org Subject: Re: Headers that define other headers and non-SMTP environments (was: Re: [EAI] The Header-Type header (was: Re: Status of utf8header draft)) Message-ID: <16D189AA10429B630C842423@p3.JCK.COM> In-Reply-To: <5dejpb6wpa.fsf@Hurtta06k.keh.iki.fi> References: <89F0DCA1E9802A1BB23DC917@p3.JCK.COM> <5dejpb6wpa.fsf@Hurtta06k.keh.iki.fi> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.6 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 31 January, 2007 17:29 +0200 Kari Hurtta wrote: >> And this is exactly why we can't try to fix DKIM or make >> adjustments for them. As long as they have a recommendation >> for 7bit-only messages (assuming that is the case), there is >> nothing that we can usefully do -- they need to fix their own >> protocol, presumably after we finish, or they need to look at >> our work and make recommendations that represent DKIM WG >> consensus. >> >> john > > Well, there is that encapsulation draft which you strongly > encouraged me to write :-) I could be wrong, but I don't believe it fixes --or is even helpful with-- the stability of DKIM header-signing. If everything, including the headers, is in seven-bit form, then there is no such thing as an internationalized address. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 11:40:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIVy-0003QU-IR; Wed, 31 Jan 2007 11:40:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIVx-0003Pf-T3 for ima@ietf.org; Wed, 31 Jan 2007 11:40:53 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCIVw-0000R8-Jf for ima@ietf.org; Wed, 31 Jan 2007 11:40:53 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HCIVw-000HjD-0S; Wed, 31 Jan 2007 11:40:52 -0500 Date: Wed, 31 Jan 2007 11:40:51 -0500 From: John C Klensin To: Kari Hurtta , ima@ietf.org Subject: Re: [EAI] other thought about > Message-ID: In-Reply-To: <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 31 January, 2007 17:11 +0200 Kari Hurtta wrote: >> I think you will find that none of them accept an unquoted >> personal string containing an "@"-sign and will treat it as a >> personal name. If that "@" is there, even the most liberal >> of systems will treat that case as either an error or as two >> addresses. > > Seems that my MUA does accept eai@address as phrase > ('<' is actual trigger, not '@' ). So your claim is wrong > (about "none" part). Does this mean that you must specify brackets to have an address? If so, while MUAs are free to do as they like, the intent and guidance of the standard is certainly being ignored. And, of course, if they send that out on the net without quotes, they are in violation of the spec. But I stand corrected. "none" should have been "very few". john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 12:00:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIp3-00084V-Hn; Wed, 31 Jan 2007 12:00:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIp1-0007qJ-0x for ima@ietf.org; Wed, 31 Jan 2007 12:00:35 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCIoz-0007FU-NW for ima@ietf.org; Wed, 31 Jan 2007 12:00:35 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HCIoN-0006yY-PP for ima@ietf.org; Wed, 31 Jan 2007 17:59:55 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Jan 2007 17:59:55 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Jan 2007 17:59:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] other thought about > Date: 31 Jan 2007 18:58:40 +0200 Lines: 40 Message-ID: <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin writes in gmane.ietf.ima: > --On Wednesday, 31 January, 2007 17:11 +0200 Kari Hurtta > wrote: > > >> I think you will find that none of them accept an unquoted > >> personal string containing an "@"-sign and will treat it as a > >> personal name. If that "@" is there, even the most liberal > >> of systems will treat that case as either an error or as two > >> addresses. > > > > Seems that my MUA does accept eai@address as phrase > > ('<' is actual trigger, not '@' ). So your claim is wrong > > (about "none" part). > > Does this mean that you must specify brackets to have an > address? If so, while MUAs are free to do as they like, the No. > intent and guidance of the standard is certainly being ignored. > And, of course, if they send that out on the net without quotes, > they are in violation of the spec. In reply phrase was quoted on my example. > But I stand corrected. "none" should have been "very few". > > john Left hand side of '<' is treated as phrase. If there is no '<' or ':', it is address. Left hand side of ':' is also phrase (if not inside of '<' and '>' tokens.) ( Tokens ':' '<' '>' ',' ';' (and end of string) are which are looked for by parser. Line is first tokenized. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 12:05:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCItk-0002hB-Ob; Wed, 31 Jan 2007 12:05:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCItj-0002gK-FJ for ima@ietf.org; Wed, 31 Jan 2007 12:05:27 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCIth-0000R7-5x for ima@ietf.org; Wed, 31 Jan 2007 12:05:27 -0500 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HCItL-0007wz-Fk for ima@ietf.org; Wed, 31 Jan 2007 18:05:03 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Jan 2007 18:05:03 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 31 Jan 2007 18:05:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] other thought about > Date: 31 Jan 2007 19:03:56 +0200 Lines: 12 Message-ID: <5dy7nj5ds3.fsf@Hurtta06k.keh.iki.fi> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Kari Hurtta writes in gmane.ietf.ima: > If there is no '<' or ':', it is address. > Left hand side of ':' is also phrase (if not inside of '<' and '>' > tokens.) Hmm. Actually group phrase is ignored. > ( Tokens ':' '<' '>' ',' ';' (and end of string) are which are looked > for by parser. Line is first tokenized. ) / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 12:11:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIzY-00058C-SX; Wed, 31 Jan 2007 12:11:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIzX-00056t-HH for ima@ietf.org; Wed, 31 Jan 2007 12:11:27 -0500 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCIv8-0000le-24 for ima@ietf.org; Wed, 31 Jan 2007 12:06:56 -0500 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HCIv7-000Hxe-Ms; Wed, 31 Jan 2007 12:06:53 -0500 Date: Wed, 31 Jan 2007 12:06:52 -0500 From: John C Klensin To: Kari Hurtta , ima@ietf.org Subject: Re: [EAI] other thought about > Message-ID: <407B9EC989C15E72DF80867C@p3.JCK.COM> In-Reply-To: <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 31 January, 2007 18:58 +0200 Kari Hurtta wrote: > John C Klensin writes in gmane.ietf.ima: > >> --On Wednesday, 31 January, 2007 17:11 +0200 Kari Hurtta >> wrote: >> >> >> I think you will find that none of them accept an unquoted >> >> personal string containing an "@"-sign and will treat it >> >> as a personal name. If that "@" is there, even the most >> >> liberal of systems will treat that case as either an error >> >> or as two addresses. >> > >> > Seems that my MUA does accept eai@address as phrase >> > ('<' is actual trigger, not '@' ). So your claim is wrong >> > (about "none" part). >> >> Does this mean that you must specify brackets to have an >> address? If so, while MUAs are free to do as they like, the > > No. > >> intent and guidance of the standard is certainly being >> ignored. And, of course, if they send that out on the net >> without quotes, they are in violation of the spec. > > In reply phrase was quoted on my example. > >> But I stand corrected. "none" should have been "very few". >> >> john > > Left hand side of '<' is treated as phrase. > > If there is no '<' or ':', it is address. > Left hand side of ':' is also phrase (if not inside of '<' and > '>' tokens.) > > ( Tokens ':' '<' '>' ',' ';' (and end of string) are which > are looked for by parser. Line is first tokenized. ) Within an MUA, that certainly works. Not to my taste, but UI behavior is, after all, a matter of taste. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 12:11:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIzz-0005F4-SK; Wed, 31 Jan 2007 12:11:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIzO-00050q-G3 for ima@ietf.org; Wed, 31 Jan 2007 12:11:18 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCIxL-0001HS-ED for ima@ietf.org; Wed, 31 Jan 2007 12:09:15 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3^clerew*man$ac*uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45c0cd30.b971.7e for ima@ietf.org; Wed, 31 Jan 2007 17:09:04 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0VH8v8G007311 for ; Wed, 31 Jan 2007 17:08:59 GMT To: IMA Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> <5dy7nl4ru5.fsf@Hurtta06k.keh.iki.fi> <5dmz401kzo.fsf@Hurtta06k.keh.iki.fi> Message-ID: Date: Wed, 31 Jan 2007 17:08:57 -0000 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <5dmz401kzo.fsf@Hurtta06k.keh.iki.fi> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 30 Jan 2007 17:29:31 -0000, Kari Hurtta wrote: > Originally that was invented to protect some MUAs. Quote from > RELEASE_NOTES of sendmail: > > > 8.10.0/8.10.0 2000/03/01 > <...> > New option MaxMimeHeaderLength which limits the size of MIME > headers and parameters within those headers. This option > is intended to protect mail user agents from buffer > overflow attacks. > Which is odd, because the later change to make it use that check by default referred to protecting MTAs, not MUAs. BTW, I tried an experiment to see how much overhead this check cost, and I could not detect any difference, which tends to suggest that sendmail uses up an awful lot of time elsewhere (all I was doing was sending a 22MB attachment to localhost, and I checked with DBX that it only called the MIME check in 1 of the 2 cases). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 12:44:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJV6-0006Ww-Ch; Wed, 31 Jan 2007 12:44:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJV4-0006WT-U4 for ima@ietf.org; Wed, 31 Jan 2007 12:44:02 -0500 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJV3-0004Fr-Bx for ima@ietf.org; Wed, 31 Jan 2007 12:44:02 -0500 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3&clerew*man^ac*uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 45c0d560.760a.372 for ima@ietf.org; Wed, 31 Jan 2007 17:44:00 +0000 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l0VHhwNN010167 for ; Wed, 31 Jan 2007 17:43:59 GMT Date: Wed, 31 Jan 2007 17:43:57 -0000 To: IMA Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt References: From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 31 Jan 2007 02:20:57 -0000, Tony Finch wrote: > On Mon, 29 Jan 2007, Internet-Drafts@ietf.org wrote: >> >> Title : International Delivery and Disposition Notifications >> Author(s) : C. Newman >> Filename : draft-ietf-eai-dsn-00.txt > > MIME forbids the encoding of message/* parts, so a message/utf-8 part > would have to be downgraded instead. Note that new message/* parts inside > 8bit messages will cause problems for existing 8BITMIME downgraders. Not quite. In fact I see no such generic rule for all of message/*. For message/rfc822, it states that the encoding must be 7bit, 8bit or binary, but if you look closely this only applies to the headers (at any depth of contained multiparts), since those headers can still specify Q-P or Base64 for the body parts under their control (but if those headers specify 8bit or binary, then the message/rfc822 as a whole must be at least 8bit or binary). It is all horribly described, but that seems to be the intent. All of which means that it IS possible, with care, to downgrade a message/rfc822 both for 8BITMIME and for UTF8SMTP purposes (and, for example, sendmail seems to do the former correctly). What is more of a problem is downgrading other (possibly not yet even defined) message/* subtypes. It turns out, AFAICS, that all of the ones so far known to IANA will survive being treated in the same way as message/rfc822, either because downgrading can never be needed, or because their structure is sufficiently similar (for example, message/partial would work in practice even if someone broke the restrictions on what you are supposed to do there). So the Perl script I recently published made that assumption, and so did the one I wrote to show how a message could be canonicalized for DKIM purposes. But it is always possible that someone someday will invent a message subtype where this does not work, and then any machinery already written (e.g. to check whether a given message requires UTF8SMTP or not) might suddenly fail to work. Fortunately, multipart subtypes are all guaranteed to obey the same basic structure, so no corresponding problem there. > > I did wonder why text/rfc822-headers was not message/rfc822-headers, so I > think the introduction of message/utf-8-headers is an improvement. The > caveats about downgrading instead of encoding apply here too. I would find it odd if DSN used text/something for ordinary email and message/something for UTF8SMTP mail, but I have not had time to read the latest draft yet. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 13:06:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJr0-00025y-A0; Wed, 31 Jan 2007 13:06:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJqy-00023F-Co for ima@ietf.org; Wed, 31 Jan 2007 13:06:40 -0500 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCJqu-0002CD-O7 for ima@ietf.org; Wed, 31 Jan 2007 13:06:40 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:44795) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1HCJqM-0005CP-0V (Exim 4.63) (return-path ); Wed, 31 Jan 2007 18:06:02 +0000 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1HCJqM-0004h4-28 (Exim 4.54) (return-path ); Wed, 31 Jan 2007 18:06:02 +0000 Date: Wed, 31 Jan 2007 18:06:02 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Charles Lindsey Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 31 Jan 2007, Charles Lindsey wrote: > > Not quite. In fact I see no such generic rule for all of message/*. The following extracts from RFC 2046 cover the encodings of all the possible message/* subtypes. 5.2.1. RFC822 Subtype No encoding other than "7bit", "8bit", or "binary" is permitted for the body of a "message/rfc822" entity. 5.2.2. Partial Subtype entities of type "message/partial" must always have a content- transfer-encoding of 7bit (the default). In particular, even in environments that support binary or 8bit transport, the use of a content- transfer-encoding of "8bit" or "binary" is explicitly prohibited for MIME entities of type "message/partial". This in turn implies that the inner message must not use "8bit" or "binary" encoding. 5.2.3. External-Body Subtype As with "message/partial", MIME entities of type "message/external- body" MUST have a content-transfer-encoding of 7bit (the default). In particular, even in environments that support binary or 8bit transport, the use of a content- transfer-encoding of "8bit" or "binary" is explicitly prohibited for entities of type "message/external-body". 5.2.4. Other Message Subtypes MIME implementations must in general treat unrecognized subtypes of "message" as being equivalent to "application/octet-stream". Future subtypes of "message" intended for use with email should be restricted to "7bit" encoding. A type other than "message" should be used if restriction to "7bit" is not possible. > For message/rfc822, it states that the encoding must be 7bit, 8bit or > binary, but if you look closely this only applies to the headers (at any > depth of contained multiparts), since those headers can still specify > Q-P or Base64 for the body parts under their control (but if those > headers specify 8bit or binary, then the message/rfc822 as a whole must > be at least 8bit or binary). It is all horribly described, but that > seems to be the intent. message/rfc822 works the same way as multipart/* in that the CTE of the part itself only applies to that one layer of nesting and nested sub-parts have their own CTEs. It makes perfect sense if you consider the double encoding that would result if a multipart attachment were encoded, and the hoops a MIME handler would have to leap through to find boundaries. Tony. -- f.a.n.finch http://dotat.at/ BISCAY FITZROY: EAST OR NORTHEAST 3 OR 4. MODERATE, OCCASIONALLY SLIGHT IN BISCAY. OCCASIONAL RAIN IN SOUTH BISCAY. GOOD, OCCASIONALLY MODERATE IN SOUTH BISCAY. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 17:34:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCO1l-0001jc-8p; Wed, 31 Jan 2007 17:34:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCO1j-0001ic-S8 for ima@ietf.org; Wed, 31 Jan 2007 17:34:04 -0500 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCO1i-00069j-BI for ima@ietf.org; Wed, 31 Jan 2007 17:34:03 -0500 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l0VMY1R9024641 for ; Thu, 1 Feb 2007 07:34:01 +0900 (JST) Received: (from NOTE233 [202.11.16.62]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007020107340124327 for ; Thu, 01 Feb 2007 07:34:01 +0900 Date: Thu, 1 Feb 2007 07:33:53 +0900 From: Yoshiro YONEYA To: ima@ietf.org Message-Id: <20070201073353.4753f66b.yone@jprs.co.jp> In-Reply-To: References: X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.7; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [EAI] Re: CONSENSUS CALL: Header format for alt-addr X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 26 Jan 2007 11:05:28 +0100 Harald Tveit Alvestrand wrote: > I think it's time we settled the issue of the format of email addresses in > UTF8SMTP headers for this round. > > PROPOSED RESOLUTION: > > The representation of an internationalized email address with an alternate > ASCII address in an UTF8SMTP message is > > > > > A pure EAI address and a pure ASCII address are both encoded without the > extra field: as . > Details of ABNF to be worked out after a draft with this syntax has been > emitted. 1. I agree with this resolution -- Yoshiro YONEYA _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 17:34:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCO1n-0001os-Cp; Wed, 31 Jan 2007 17:34:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCO1l-0001kQ-Vh for ima@ietf.org; Wed, 31 Jan 2007 17:34:05 -0500 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCO1k-00069y-F4 for ima@ietf.org; Wed, 31 Jan 2007 17:34:05 -0500 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l0VMY1RB024641 for ; Thu, 1 Feb 2007 07:34:03 +0900 (JST) Received: (from NOTE233 [202.11.16.62]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007020107340224329 for ; Thu, 01 Feb 2007 07:34:03 +0900 Date: Thu, 1 Feb 2007 07:34:01 +0900 From: Yoshiro YONEYA To: ima@ietf.org Message-Id: <20070201073401.4bac6869.yone@jprs.co.jp> In-Reply-To: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.7; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [EAI] Re: CONSENSUS CALL: Removal of Header-Format: marker X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 26 Jan 2007 11:13:49 +0100 Harald Tveit Alvestrand wrote: > The discussion of whether or not we need a header marker for marking > UTF8SMTP messages that actually use UTF-8 characters has reached a point > where it seems that no new technical information is being provided. > > At this point, the chairs wish to see if the group is near a possible > consensus on the issue. > > PROPOSED RESOLUTOIN: > > There is no significant operational or implementation benefit in having a > marker in the headers of UTF8SMTP messages, and significant additional > complexity. Therefore, the proposed "Header-Type" section, > draft-ietf-eai-utf8headers-02 section 5, will be removed. > > Note that this is not a call on the proposal to have a similar marker in > the SMTP protocol; that's a separate issue. 1. I agree with this resolution -- Yoshiro YONEYA _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 17:34:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCO1l-0001jc-8p; Wed, 31 Jan 2007 17:34:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCO1j-0001ic-S8 for ima@ietf.org; Wed, 31 Jan 2007 17:34:04 -0500 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCO1i-00069j-BI for ima@ietf.org; Wed, 31 Jan 2007 17:34:03 -0500 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l0VMY1R9024641 for ; Thu, 1 Feb 2007 07:34:01 +0900 (JST) Received: (from NOTE233 [202.11.16.62]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007020107340124327 for ; Thu, 01 Feb 2007 07:34:01 +0900 Date: Thu, 1 Feb 2007 07:33:53 +0900 From: Yoshiro YONEYA To: ima@ietf.org Message-Id: <20070201073353.4753f66b.yone@jprs.co.jp> In-Reply-To: References: X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.7; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [EAI] Re: CONSENSUS CALL: Header format for alt-addr X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 26 Jan 2007 11:05:28 +0100 Harald Tveit Alvestrand wrote: > I think it's time we settled the issue of the format of email addresses in > UTF8SMTP headers for this round. > > PROPOSED RESOLUTION: > > The representation of an internationalized email address with an alternate > ASCII address in an UTF8SMTP message is > > > > > A pure EAI address and a pure ASCII address are both encoded without the > extra field: as . > Details of ABNF to be worked out after a draft with this syntax has been > emitted. 1. I agree with this resolution -- Yoshiro YONEYA _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 17:34:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCO1n-0001os-Cp; Wed, 31 Jan 2007 17:34:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCO1l-0001kQ-Vh for ima@ietf.org; Wed, 31 Jan 2007 17:34:05 -0500 Received: from send01.jprs.co.jp ([202.11.17.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCO1k-00069y-F4 for ima@ietf.org; Wed, 31 Jan 2007 17:34:05 -0500 Received: from send01.jprs.co.jp (localhost [127.0.0.1]) by send01.jprs.co.jp (8.12.10+Sun/8.12.11) with SMTP id l0VMY1RB024641 for ; Thu, 1 Feb 2007 07:34:03 +0900 (JST) Received: (from NOTE233 [202.11.16.62]) by send01.jprs.co.jp (SMSSMTP 4.0.4.64) with SMTP id M2007020107340224329 for ; Thu, 01 Feb 2007 07:34:03 +0900 Date: Thu, 1 Feb 2007 07:34:01 +0900 From: Yoshiro YONEYA To: ima@ietf.org Message-Id: <20070201073401.4bac6869.yone@jprs.co.jp> In-Reply-To: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> X-Mailer: Sylpheed 2.3.1 (GTK+ 2.10.7; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [EAI] Re: CONSENSUS CALL: Removal of Header-Format: marker X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 26 Jan 2007 11:13:49 +0100 Harald Tveit Alvestrand wrote: > The discussion of whether or not we need a header marker for marking > UTF8SMTP messages that actually use UTF-8 characters has reached a point > where it seems that no new technical information is being provided. > > At this point, the chairs wish to see if the group is near a possible > consensus on the issue. > > PROPOSED RESOLUTOIN: > > There is no significant operational or implementation benefit in having a > marker in the headers of UTF8SMTP messages, and significant additional > complexity. Therefore, the proposed "Header-Type" section, > draft-ietf-eai-utf8headers-02 section 5, will be removed. > > Note that this is not a call on the proposal to have a similar marker in > the SMTP protocol; that's a separate issue. 1. I agree with this resolution -- Yoshiro YONEYA _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 18:14:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCOf1-0000Bw-BC; Wed, 31 Jan 2007 18:14:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCOey-0000Bp-IH for ima@ietf.org; Wed, 31 Jan 2007 18:14:36 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCOev-0008J2-Uu for ima@ietf.org; Wed, 31 Jan 2007 18:14:36 -0500 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0VNEXGm027105 for ; Wed, 31 Jan 2007 16:14:33 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCR00G019NMQ200@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Wed, 31 Jan 2007 16:14:33 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCR00D4B9W1TU00@mail-amer.sun.com>; Wed, 31 Jan 2007 16:14:33 -0700 (MST) Date: Wed, 31 Jan 2007 15:14:25 -0800 From: Chris Newman Subject: Re: Header-Format: Downgraded (Re: [EAI] CONSENSUS CALL: Removal of Header-Format: marker) In-reply-to: To: Charles Lindsey , IMA Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <07A79A2D4DF1007B66EFDA39@htat43p-no.corp.google.com> <5d64at7jdj.fsf@Hurtta06k.keh.iki.fi> <5dejpgzutl.fsf_-_@Hurtta06k.keh.iki.fi> <5dy7nl4ru5.fsf@Hurtta06k.keh.iki.fi> <5dmz401kzo.fsf@Hurtta06k.keh.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote on 1/31/07 17:08 +0000: > BTW, I tried an experiment to see how much overhead this check cost, and I > could not detect any difference, which tends to suggest that sendmail uses > up an awful lot of time elsewhere (all I was doing was sending a 22MB > attachment to localhost, and I checked with DBX that it only called the MIME > check in 1 of the 2 cases). On modern hardware, the MTA bottlenecks are either the spam/virus engine or the disk I/O subsystem. The cost to scan the MIME structure (or scan/verify a DKIM signature) is negligible by comparison. You'd probably see the same result (MIME scanning has no real cost) on any modern MTA which properly commits messages to disk with fsync/fdatasync or the equivalent. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 18:38:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCP1m-0004P8-Ki; Wed, 31 Jan 2007 18:38:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCP1l-0004On-Eq for ima@ietf.org; Wed, 31 Jan 2007 18:38:09 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCP1f-0006BR-2x for ima@ietf.org; Wed, 31 Jan 2007 18:38:09 -0500 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0VNc2qO020444 for ; Wed, 31 Jan 2007 16:38:02 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JCR00K01AOPKR00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ima@ietf.org; Wed, 31 Jan 2007 16:38:02 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JCR00BCNAZCQD00@mail-amer.sun.com>; Wed, 31 Jan 2007 16:38:02 -0700 (MST) Date: Wed, 31 Jan 2007 15:37:59 -0800 From: Chris Newman Subject: Re: [Filtered!] [EAI] I-D ACTION:draft-ietf-eai-dsn-00.txt In-reply-to: To: Tony Finch , ima@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Tony Finch wrote on 1/31/07 2:20 +0000: > On Mon, 29 Jan 2007, Internet-Drafts@ietf.org wrote: >> >> Title : International Delivery and Disposition Notifications >> Author(s) : C. Newman >> Filename : draft-ietf-eai-dsn-00.txt > > MIME forbids the encoding of message/* parts, so a message/utf-8 part > would have to be downgraded instead. Note that new message/* parts inside > 8bit messages will cause problems for existing 8BITMIME downgraders. MIME only forbids message encodings for the message subtypes it defines, no normative restrictions are placed on other message subtypes. If one of the functions of this experiment is to make email UTF-8 clean, then the advisory text in section 5.2.4 of RFC 2046 does not apply to the documents in this experiment. > The message/utf-8-delivery-status and -disposition-notification types will > also need to be downgraded to their 7bit originals in some cases. This can > probably be done fairly easily using the utf-8-enc address type. However > there remains the problem of how to handle utf-8 SMTP response texts (if > they become permitted) in DSNs. Downgrading message/utf-8-delivery-status to message/delivery-status is a bad idea, IMHO. It's not going to break anything if you leave it alone and it will lose information if downgraded. It's a lot simpler to upgrade the few automated message/delivery-status processors to support utf-8-delivery-status than to add downgrade code to every MTA. Bounce processing engines already have to deal with bounce messages in non-standard formats, so a new standard format is not a big change. Encoding with QP or base64 is fine if necessary. FYI, Alexey is working on an individual submission adding the SMTP LANG extension so clients can request localized SMTP error text. - Chris _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 21:41:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCRtP-0000uI-Jc; Wed, 31 Jan 2007 21:41:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCRtP-0000uD-5D for ima@ietf.org; Wed, 31 Jan 2007 21:41:43 -0500 Received: from ns5.lsb.org ([211.196.150.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCRtM-0003B8-G3 for ima@ietf.org; Wed, 31 Jan 2007 21:41:43 -0500 Received: from ns5.lsb.org (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l112fWJ5030872; Thu, 1 Feb 2007 11:41:32 +0900 Received: (from lsb@localhost) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4/Submit) id l112fVTq030850; Thu, 1 Feb 2007 11:41:31 +0900 Date: Thu, 1 Feb 2007 11:41:31 +0900 From: Soobok Lee To: John C Klensin Subject: Re: [EAI] other thought about > Message-ID: <20070201024131.GK30318@ns5.lsb.org> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> <407B9EC989C15E72DF80867C@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <407B9EC989C15E72DF80867C@p3.JCK.COM> User-Agent: Mutt/1.4i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns5.lsb.org id l112fWJ5030872 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ima@ietf.org, Kari Hurtta X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, Jan 31, 2007 at 12:06:52PM -0500, John C Klensin wrote: > >=20 > > In reply phrase was quoted on my example. > > =20 > >> But I stand corrected. "none" should have been "very few". > >>=20 > >> john > >=20 > > Left hand side of '<' is treated as phrase. > >=20 > > If there is no '<' or ':', it is address. > > Left hand side of ':' is also phrase (if not inside of '<' and > > '>' tokens.) > >=20 > > ( Tokens ':' '<' '>' ',' ';' (and end of string) are which > > are looked for by parser. Line is first tokenized. )=20 >=20 > Within an MUA, that certainly works. Not to my taste, but UI > behavior is, after all, a matter of taste. I made manually a message file which contains unquoted eai@address as below. You can save the next rfc2822 message into a mbox file "/tmp/mbx1" =20 and open it using "mutt -f /tmp/mbx1" (or elm,pine etc) and then=20 try to make reply-all. If your MUAs is "robust", you will see quotations marks are added around CC's name_parts below=20 in the reply form. >From lsb@lsb.org Thu Feb 1 10:23:14 2007 Received: from nobody.com (localhost [127.0.0.1]) by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id = l111NEJ5015951 for ; Thu, 1 Feb 2007 10:23:14 +0900 Date: Thu, 1 Feb 2007 10:23:14 +0900 Message-Id: <200702010123.l111NEJ5015951@lsb.org> From: "Soobok Lee" To: "Soobok Lee" Cc: =ED=95=9C=EA=B8=80@=EB=8F=84=EB=A9=94=EC=9D=B8.tld Cc: ASCII@DOMAIN.tld Subject: Re: [EAI] other thought about > This email is a test. =20 This is a mutt1.4 screenshot when I tried reply-all to the above message. :=EB=B3=B4=EB=83=84 q:=EC=B7=A8=EC=86=8C t:To c:CC s:Subj a:=ED=8C=8C= =EC=9D=BC =EC=B2=A8=EB=B6=80 d:=EC=84=A4=EB=AA=85 ?:=EB=8F=84=EC=9B=80=EB= =A7=90 =20 From: Soobok Lee To: Soobok Lee Cc: "=ED=95=9C=EA=B8=80 @ =EB=8F=84=EB=A9=94=EC=9D=B8. tld" , "ASCII @ DOMAIN. tld" Bcc: Subject: Re: [EAI] other thought about > Reply-To: Fcc: /home/lsb/Sent PGP: =EC=97=86=EC=9D=8C -- =EC=B2=A8=EB=B6=80=EB=AC=BC = = =20 - I 1 /tmp/mutt-ns5-28332-1 = [text/plain, 7bit, us-ascii, 0.1K]=20 I found either sendmail 8.13.0 process or its procmail component =20 (I don't know which of them exactly) might transform eai@address in the headers into=20 "eai@address" before saving the received message=20 into the mailbox. If you have time, you can replace From/TO addresses in the example messag= e=20 with your email address , and feed it into your sendmail process. Soobok _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Jan 31 23:42:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCTm8-0008Rx-44; Wed, 31 Jan 2007 23:42:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCTm6-0008Rq-RH for ima@ietf.org; Wed, 31 Jan 2007 23:42:18 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCTm1-0005vn-Dc for ima@ietf.org; Wed, 31 Jan 2007 23:42:18 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HCTlc-0006ia-52 for ima@ietf.org; Thu, 01 Feb 2007 05:41:48 +0100 Received: from cs181108174.pp.htv.fi ([82.181.108.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Feb 2007 05:41:48 +0100 Received: from hurtta+gmane by cs181108174.pp.htv.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Feb 2007 05:41:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: Kari Hurtta Subject: Re: [EAI] other thought about > Date: 01 Feb 2007 06:41:39 +0200 Lines: 66 Message-ID: <5dbqkebibg.fsf@Hurtta06k.keh.iki.fi> References: <20070129100855.GB30318@ns5.lsb.org> <20070130000617.GD30318@ns5.lsb.org> <20070130233409.GF30318@ns5.lsb.org> <7518047A15D398D1797627E5@p3.JCK.COM> <5diren6xkf.fsf@Hurtta06k.keh.iki.fi> <5d3b5r6slb.fsf@Hurtta06k.keh.iki.fi> <407B9EC989C15E72DF80867C@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cs181108174.pp.htv.fi User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin writes in gmane.ietf.ima: > --On Wednesday, 31 January, 2007 18:58 +0200 Kari Hurtta > wrote: > > > John C Klensin writes in gmane.ietf.ima: > > > >> --On Wednesday, 31 January, 2007 17:11 +0200 Kari Hurtta > >> wrote: > >> > >> >> I think you will find that none of them accept an unquoted > >> >> personal string containing an "@"-sign and will treat it > >> >> as a personal name. If that "@" is there, even the most > >> >> liberal of systems will treat that case as either an error > >> >> or as two addresses. > >> > > >> > Seems that my MUA does accept eai@address as phrase > >> > ('<' is actual trigger, not '@' ). So your claim is wrong > >> > (about "none" part). > >> > >> Does this mean that you must specify brackets to have an > >> address? If so, while MUAs are free to do as they like, the > > > > No. > > > >> intent and guidance of the standard is certainly being > >> ignored. And, of course, if they send that out on the net > >> without quotes, they are in violation of the spec. > > > > In reply phrase was quoted on my example. > > > >> But I stand corrected. "none" should have been "very few". > >> > >> john > > > > Left hand side of '<' is treated as phrase. > > > > If there is no '<' or ':', it is address. > > Left hand side of ':' is also phrase (if not inside of '<' and > > '>' tokens.) > > > > ( Tokens ':' '<' '>' ',' ';' (and end of string) are which > > are looked for by parser. Line is first tokenized. ) > > Within an MUA, that certainly works. Not to my taste, but UI > behavior is, after all, a matter of taste. > > john How else header can be parsed? Remember: On here parser is possibly parsing mails which are local on unux. They are newer passed via SMTP. On some configurations there is no '@' on address at all. On local mail you can have: From: Name From: account From: account (Name) There is no @ -character. / Kari Hurtta _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima