From ima-bounces@ietf.org Sun Sep 02 11:20:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRrF6-0002VQ-Py; Sun, 02 Sep 2007 11:20:04 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IRrF5-0002T1-6x for ima-confirm+ok@megatron.ietf.org; Sun, 02 Sep 2007 11:20:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRrF4-0002SV-HD; Sun, 02 Sep 2007 11:20:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRrF4-0001eF-4A; Sun, 02 Sep 2007 11:20:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 0823826E2A; Sun, 2 Sep 2007 15:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IRrF3-0008Vd-UD; Sun, 02 Sep 2007 11:20:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 02 Sep 2007 11:20:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-dsn-03.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : International Delivery and Disposition Notifications Author(s) : C. Newman, A. Melnikov Filename : draft-ietf-eai-dsn-03.txt Pages : 19 Date : 2007-09-02 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. This document experimentally extends RFC 3461, RFC 3464 and RFC 3798. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-dsn-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-dsn-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-dsn-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-09-02111002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-dsn-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-dsn-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-02111002.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 Tue Sep 04 15:15:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdrm-0008DK-Ty; Tue, 04 Sep 2007 15:15:14 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ISdrb-0007wi-Mo for ima-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 15:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdrb-0007v8-8D; Tue, 04 Sep 2007 15:15:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISdra-0000jU-3Z; Tue, 04 Sep 2007 15:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 1331332854; Tue, 4 Sep 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ISdrZ-0000fo-Vd; Tue, 04 Sep 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 04 Sep 2007 15:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-smtpext-08.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : SMTP extension for internationalized email address Author(s) : J. Yao, W. Mao Filename : draft-ietf-eai-smtpext-08.txt Pages : 20 Date : 2007-9-4 This document specifies the use of SMTP extension for internationalized email address delivery. Communication with systems that do not implement this specification is specified in another document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-smtpext-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-smtpext-08.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-9-4141551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-smtpext-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-smtpext-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-4141551.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 Tue Sep 04 15:15:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdrq-0008NN-0Z; Tue, 04 Sep 2007 15:15:18 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ISdrc-0007zH-KV for ima-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 15:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdrb-0007wj-PC; Tue, 04 Sep 2007 15:15:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISdra-0000jV-FX; Tue, 04 Sep 2007 15:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5B6F526E39; Tue, 4 Sep 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ISdra-0000gY-8f; Tue, 04 Sep 2007 15:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 04 Sep 2007 15:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-07.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Internationalized Email Headers Author(s) : J. Yeh Filename : draft-ietf-eai-utf8headers-07.txt Pages : 17 Date : 2007-9-4 Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-utf8headers-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-utf8headers-07.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-9-4143345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-utf8headers-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-utf8headers-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-4143345.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 Tue Sep 04 15:15:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdrm-0008DK-Ty; Tue, 04 Sep 2007 15:15:14 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ISdrb-0007wi-Mo for ima-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 15:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdrb-0007v8-8D; Tue, 04 Sep 2007 15:15:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISdra-0000jU-3Z; Tue, 04 Sep 2007 15:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 1331332854; Tue, 4 Sep 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ISdrZ-0000fo-Vd; Tue, 04 Sep 2007 15:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 04 Sep 2007 15:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-smtpext-08.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : SMTP extension for internationalized email address Author(s) : J. Yao, W. Mao Filename : draft-ietf-eai-smtpext-08.txt Pages : 20 Date : 2007-9-4 This document specifies the use of SMTP extension for internationalized email address delivery. Communication with systems that do not implement this specification is specified in another document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-smtpext-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-smtpext-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-smtpext-08.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-9-4141551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-smtpext-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-smtpext-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-4141551.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 Tue Sep 04 15:15:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdrq-0008NN-0Z; Tue, 04 Sep 2007 15:15:18 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ISdrc-0007zH-KV for ima-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 15:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdrb-0007wj-PC; Tue, 04 Sep 2007 15:15:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISdra-0000jV-FX; Tue, 04 Sep 2007 15:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5B6F526E39; Tue, 4 Sep 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ISdra-0000gY-8f; Tue, 04 Sep 2007 15:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 04 Sep 2007 15:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-07.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Internationalized Email Headers Author(s) : J. Yeh Filename : draft-ietf-eai-utf8headers-07.txt Pages : 17 Date : 2007-9-4 Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-utf8headers-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-utf8headers-07.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-9-4143345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-utf8headers-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-utf8headers-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-4143345.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 Sep 07 09:52:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITeGP-0001xV-R3; Fri, 07 Sep 2007 09:52:49 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1ITeGO-0001xO-01 for ima-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 09:52:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITeGN-0001xG-Ml for ima@ietf.org; Fri, 07 Sep 2007 09:52:47 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITeGM-00016n-8H for ima@ietf.org; Fri, 07 Sep 2007 09:52:47 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4B91A259702 for ; Fri, 7 Sep 2007 15:52:45 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20274-01 for ; Fri, 7 Sep 2007 15:52:40 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 721E82596FF for ; Fri, 7 Sep 2007 15:52:40 +0200 (CEST) Message-ID: <46E157A8.7000105@alvestrand.no> Date: Fri, 07 Sep 2007 15:52:40 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [EAI] Heads-up on WG Last Call X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org As of this week, the following new I-Ds are out: - Sep 4 20:32 internet-drafts/draft-ietf-eai-utf8headers-07.txt - Sep 4 20:15 internet-drafts/draft-ietf-eai-smtpext-08.txt - Sep 2 17:08 internet-drafts/draft-ietf-eai-dsn-03.txt This chair has not prepared enough to emit the Last Call today, but we aim to emit the WG Last Call on these 3 documents Monday of next week. This will be a 2-week Last Call for publication as Experimental, ending on September 24. Harald, for the chairs _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Sep 08 09:21:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU0FZ-0005C0-TI; Sat, 08 Sep 2007 09:21:26 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IU0FZ-0005Bo-5r for ima-confirm+ok@megatron.ietf.org; Sat, 08 Sep 2007 09:21:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU0FY-0005Be-GJ; Sat, 08 Sep 2007 09:21:24 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IU0FX-00086w-7s; Sat, 08 Sep 2007 09:21:24 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm3f46e2adb6; Sat, 08 Sep 2007 21:33:37 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2a46de23ef; Wed, 05 Sep 2007 03:32:47 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 05 Sep 2007 03:32:47 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdrr-0008Ov-PA; Tue, 04 Sep 2007 15:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdrb-0007wj-PC; Tue, 04 Sep 2007 15:15:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISdra-0000jV-FX; Tue, 04 Sep 2007 15:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5B6F526E39; Tue, 4 Sep 2007 19:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ISdra-0000gY-8f; Tue, 04 Sep 2007 15:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 04 Sep 2007 15:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ima@ietf.org Subject: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-07.txt X-BeenThere: ima@ietf.org Reply-To: internet-drafts@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : Internationalized Email Headers Author(s) : J. Yeh Filename : draft-ietf-eai-utf8headers-07.txt Pages : 17 Date : 2007-9-4 Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-utf8headers-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-utf8headers-07.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-9-4143345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-utf8headers-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-utf8headers-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-9-4143345.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Sep 10 06:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUgyQ-0002Gg-CY; Mon, 10 Sep 2007 06:58:34 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IUgyO-0002Ct-W5 for ima-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 06:58:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUgyO-00028n-LY for ima@ietf.org; Mon, 10 Sep 2007 06:58:32 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUgyN-00019K-Iz for ima@ietf.org; Mon, 10 Sep 2007 06:58:31 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3^clerew^man&ac*uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.253) id 46e52353.2c13.b4 for ima@ietf.org; Mon, 10 Sep 2007 11:58:27 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8AAwJ4m009642 for ; Mon, 10 Sep 2007 11:58:20 +0100 (BST) To: IMA Subject: Re: [EAI] Heads-up on WG Last Call References: <46E157A8.7000105@alvestrand.no> Message-ID: Date: Mon, 10 Sep 2007 11:58:19 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <46E157A8.7000105@alvestrand.no> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 07 Sep 2007 14:52:40 +0100, Harald Alvestrand wrote: > As of this week, the following new I-Ds are out: > > - Sep 4 20:32 internet-drafts/draft-ietf-eai-utf8headers-07.txt > - Sep 4 20:15 internet-drafts/draft-ietf-eai-smtpext-08.txt > - Sep 2 17:08 internet-drafts/draft-ietf-eai-dsn-03.txt But we still await the downgrade document to complete the set. Since there are so many interactions between them, I would prefer to wait until the set is complete before going to WG last call (I presume the next downgrade document cannot be far away). Also, I raised an issue regarding whether the headers returned with a DSN should be a text type rather than a message type. Chris disagreed, but he did agree that it ought to be formally recognised as an issue. I therefore request that be done. -- 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 Sep 10 21:06:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUuCt-0004Vb-6j; Mon, 10 Sep 2007 21:06:23 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IUuCr-0004VU-UA for ima-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 21:06:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUuCr-0004Mg-Iw for ima@ietf.org; Mon, 10 Sep 2007 21:06:21 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IUuCo-0002xp-Hx for ima@ietf.org; Mon, 10 Sep 2007 21:06:19 -0400 Received: (eyou send program); Tue, 11 Sep 2007 09:06:10 +0800 Message-ID: <389472770.25388@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.35) by 159.226.7.146 with SMTP; Tue, 11 Sep 2007 09:06:10 +0800 Message-ID: <048401c7f40f$ee33afc0$236ff1da@yaojk> From: "YAO Jiankang" To: "Charles Lindsey" References: <46E157A8.7000105@alvestrand.no> <389421931.28708@cnnic.cn> Subject: Re: [EAI] Heads-up on WG Last Call Date: Tue, 11 Sep 2007 09:06:05 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: , Content-Type: multipart/mixed; boundary="===============1764158163==" Errors-To: ima-bounces@ietf.org --===============1764158163== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkNoYXJsZXMgTGluZHNleSIg PGNobEBjbGVyZXcubWFuLmFjLnVrPg0KVG86ICJJTUEiIDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBN b25kYXksIFNlcHRlbWJlciAxMCwgMjAwNyA2OjU4IFBNDQpTdWJqZWN0OiBSZTogW0VBSV0gSGVh ZHMtdXAgb24gV0cgTGFzdCBDYWxsDQoNCg0KPiBPbiBGcmksIDA3IFNlcCAyMDA3IDE0OjUyOjQw ICswMTAwLCBIYXJhbGQgQWx2ZXN0cmFuZCAgDQo+IDxoYXJhbGRAYWx2ZXN0cmFuZC5ubz4gd3Jv dGU6DQo+IA0KPj4gQXMgb2YgdGhpcyB3ZWVrLCB0aGUgZm9sbG93aW5nIG5ldyBJLURzIGFyZSBv dXQ6DQo+Pg0KPj4gLSBTZXAgIDQgMjA6MzIgaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZWFp LXV0ZjhoZWFkZXJzLTA3LnR4dA0KPj4gLSBTZXAgIDQgMjA6MTUgaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtZWFpLXNtdHBleHQtMDgudHh0DQo+PiAtIFNlcCAgMiAxNzowOCBpbnRlcm5ldC1k cmFmdHMvZHJhZnQtaWV0Zi1lYWktZHNuLTAzLnR4dA0KPiANCj4gQnV0IHdlIHN0aWxsIGF3YWl0 IHRoZSBkb3duZ3JhZGUgZG9jdW1lbnQgdG8gY29tcGxldGUgdGhlIHNldC4gU2luY2UgdGhlcmUg IA0KPiBhcmUgc28gbWFueSBpbnRlcmFjdGlvbnMgYmV0d2VlbiB0aGVtLCBJIHdvdWxkIHByZWZl ciB0byB3YWl0IHVudGlsIHRoZSAgDQo+IHNldCBpcyBjb21wbGV0ZSBiZWZvcmUgZ29pbmcgdG8g V0cgbGFzdCBjYWxsIChJIHByZXN1bWUgdGhlIG5leHQgZG93bmdyYWRlICANCj4gZG9jdW1lbnQg Y2Fubm90IGJlIGZhciBhd2F5KS4NCg0KV2UnZCBiZXR0ZXIgZG8gb3VyIHdvcmsgc3RlcCBieSBz dGVwLiBUaGUgZmlyc3Qgc3RlcCBpcyB0byBmaW5pc2ggdGhlc2UgMyBkb2N1bWVudHMgV0cgTGFz dCBjYWxsLg0KVGhlIHNlY29uZCBzdGVwIGlzIHRvIGRlYWwgd2l0aCBvdGhlciBkb2N1bWVudHMg c3VjaCBhcyBkb3duZ3JhZGUsIHBvcCBhbmQgb3RoZXJzLg0KV2UgY2FuIG5vdCBmaW5pc2ggYWxs IGluIGEgc2luZ2xlIGRheS4NCg0KWUFPIEppYW5rYW5nDQpDTk5JQw0KIA0KDQoNCg0KPiANCj4g QWxzbywgSSByYWlzZWQgYW4gaXNzdWUgcmVnYXJkaW5nIHdoZXRoZXIgdGhlIGhlYWRlcnMgcmV0 dXJuZWQgd2l0aCBhIERTTiAgDQo+IHNob3VsZCBiZSBhIHRleHQgdHlwZSByYXRoZXIgdGhhbiBh IG1lc3NhZ2UgdHlwZS4gQ2hyaXMgZGlzYWdyZWVkLCBidXQgaGUgIA0KPiBkaWQgYWdyZWUgdGhh dCBpdCBvdWdodCB0byBiZSBmb3JtYWxseSByZWNvZ25pc2VkIGFzIGFuIGlzc3VlLiBJIHRoZXJl Zm9yZSAgDQo+IHJlcXVlc3QgdGhhdCBiZSBkb25lLg0KPiANCj4gLS0gDQo+IENoYXJsZXMgSC4g TGluZHNleSAtLS0tLS0tLS1BdCBIb21lLCBkb2luZyBteSBvd24gdGhpbmctLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gVGVsOiArNDQgMTYxIDQzNiA2MTMxICAgICAgICAgICAgICAgICAgICAg ICANCj4gV2ViOiBodHRwOi8vd3d3LmNzLm1hbi5hYy51ay9+Y2hsDQo+IEVtYWlsOiBjaGxAY2xl cmV3Lm1hbi5hYy51ayBTbmFpbDogNSBDbGVyZXdvb2QgQXZlLCBDSEVBRExFLCBTSzggM0pVLCBV LksuDQo+IFBHUDogMkMxNUYxQTkgRmluZ2VycHJpbnQ6IDczIDZEIEMyIDUxIDkzIEEwIDAxIEU3 IDY1IEU4IDY0IDdFIDE0IEE0IEFCIEE1DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSU1BIG1haWxpbmcgbGlzdA0KPiBJTUFAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW1hDQo+ --===============1764158163== 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 --===============1764158163==-- From ima-bounces@ietf.org Tue Sep 11 01:46:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUyZk-0000UI-6B; Tue, 11 Sep 2007 01:46:16 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IUyZi-0000Tu-SG for ima-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 01:46:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUyZi-0000Tm-DG for ima@ietf.org; Tue, 11 Sep 2007 01:46:14 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUyZh-0000dR-QQ for ima@ietf.org; Tue, 11 Sep 2007 01:46:14 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CD2D32596BA for ; Tue, 11 Sep 2007 07:46:12 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09433-01 for ; Tue, 11 Sep 2007 07:46:07 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id A47BB2596B9 for ; Tue, 11 Sep 2007 07:46:07 +0200 (CEST) Message-ID: <46E62B9D.3040300@alvestrand.no> Date: Tue, 11 Sep 2007 07:46:05 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [EAI] WG Last Call on -smtp, -utf8 and -dsn X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This message starts the 2-week WG LAST CALL for comments on the following three documents, intended for EXPERIMENTAL publication as RFC: draft-ietf-eai-utf8headers-07 draft-ietf-eai-smtpext-08 draft-ietf-eai-dsn-03 The WG Last Call will conclude on Tuesday September 25, 2007; after resolution of issues raised (if any), the documents will be forwarded to the IESG for approval for Experimental publication as a set. To simplify resolution of comments, please follow the following formats for comments: SUPPORT: If you have read the documents in their latest version, and support their publication, please send a message with the subject line "SUPPORT" to the mailing list. You may use "SUPPORT: smtp", "SUPPORT: utf8" or "SUPPORT: dsn", if you want to. REVIEW: If you have reviewed the documents in detail, and wish to send one (possibly long) message with a review of a whole document, please use the subject line "REVIEW: ". The chairs will be looking for these messages to indicate that the documents have been reviewed by a sufficiently large number of people in the WG. EDITORIAL: If you have editorial issues, but are not asking for any change to the technical specification, and do not wish to claim to have reviewed the whole specification, please use the subject line "EDITORIAL: ". For small issues, please send directly to the editors. ISSUE: If you think that there is a technical issue that should be addressed before sending the documents to the IESG, please use the subject line "ISSUE: ". If the WG chairs agree that this is an issue that needs resolution, or if other WG members support the issue by replying and saying "this is an issue", the issue will be assigned a tracking number from the issue tracker, and will have to be resolved before sending the documents to the IESG. The WG Chairs _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 11 01:51:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUyeQ-0003Zw-Gk; Tue, 11 Sep 2007 01:51:06 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IUyeP-0003Zp-7T for ima-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 01:51:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUyeO-0003Zh-Tg for ima@ietf.org; Tue, 11 Sep 2007 01:51:04 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUyeO-0000ov-Fy for ima@ietf.org; Tue, 11 Sep 2007 01:51:04 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CFFB82596C0; Tue, 11 Sep 2007 07:51:03 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09086-06; Tue, 11 Sep 2007 07:50:56 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2991D2596B9; Tue, 11 Sep 2007 07:50:56 +0200 (CEST) Message-ID: <46E62CB8.8010500@alvestrand.no> Date: Tue, 11 Sep 2007 07:50:48 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: Charles Lindsey Subject: Re: [EAI] Heads-up on WG Last Call References: <46E157A8.7000105@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > On Fri, 07 Sep 2007 14:52:40 +0100, Harald Alvestrand > wrote: > >> As of this week, the following new I-Ds are out: >> >> - Sep 4 20:32 internet-drafts/draft-ietf-eai-utf8headers-07.txt >> - Sep 4 20:15 internet-drafts/draft-ietf-eai-smtpext-08.txt >> - Sep 2 17:08 internet-drafts/draft-ietf-eai-dsn-03.txt > > But we still await the downgrade document to complete the set. Since > there are so many interactions between them, I would prefer to wait > until the set is complete before going to WG last call (I presume the > next downgrade document cannot be far away). I have formed the opposite opinion; the total number of pages for review in the 3 documents listed is great enough, and the distance to -downgrade is big enough, that it makes sense to ask for their review separately. Of course, you're free to raise issues about their interaction with -downgrade as long as those issues could affect the text of these documents. > > Also, I raised an issue regarding whether the headers returned with a > DSN should be a text type rather than a message type. Chris disagreed, > but he did agree that it ought to be formally recognised as an issue. > I therefore request that be done. On which date did you send the message with "ISSUE:" to the mailing list? Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Sep 12 13:56:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWSN-0005gx-E1; Wed, 12 Sep 2007 13:56:55 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IVWSL-0005gK-Pg for ima-confirm+ok@megatron.ietf.org; Wed, 12 Sep 2007 13:56:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVWSL-0005g7-EM for ima@ietf.org; Wed, 12 Sep 2007 13:56:53 -0400 Received: from ns1.qubic.net ([208.185.248.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVWSK-0003FR-SC for ima@ietf.org; Wed, 12 Sep 2007 13:56:53 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Alpha0/8.14.2.Alpha0) with ESMTP id l8CHuL1i019645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Sep 2007 10:56:36 -0700 (PDT) VBR-Info: md=resistor.net; mc=all; mv=elandsys.com DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1189619798; x=1189706198; bh=3ahMZJGD7ozKuTbKO/Jt06EkfdMBT4EKyHO6 WpFFf7Q=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:In-Reply-To:References:Mime-Version:Content-Type:Cc; b=RGp 1TzKBlX+aiwOA4iObEYNSB9sbLJNWfmTSXe0Cclp39CY4NpclZHz6v3hw3HJOwq9mo/ mFaqpUUuWgzQj6LKtM0v4bxr+bG7uz/gVL3Q3flwz1uTZYihHfAo8x/ywxB4It6xvhl 5cSti+58qBRBawiElY9TxQuv86pRMT1P0w= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=1msyuQ0UKUR99MLb7abH8+DZeSeytmn9ElEbMeLYrxy7TrMJvM/k9NnoJgVpnN/iY UKFcjjTmDRVyPlsU0HhQ4DTvb0rdCSLk4zepk3FDPl03XsGSLbL9C/BNFjGWvspg37a CADWDKmwYhtrBdlvT+kCHDqHMzJi7XK6ufbNAPI= Message-Id: <6.2.5.6.2.20070912095432.030088a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 12 Sep 2007 10:51:54 -0700 To: ima@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [EAI] REVIEW: draft-ietf-eai-smtpext-08.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 At 12:15 04-09-2007, Internet-Drafts@ietf.org wrote: > Title : SMTP extension for internationalized email address In Section 2.2. The UTF8SMTP Extension: "3. Find an alternate route to the destination that permits UTF8SMTP. That route may be discovered by trying alternate MX hosts (using preference rules as specified in RFC 2821) or using other means available to the SMTP-sender." The receiver publishes MX records to indicate which MX hosts will be handling mail for the domain and the order in which they should be tried (preference). The rules are described in Section 5.1 of RFC 2821. The "or using other means available to the SMTP-sender" introduces a rule for the sender to sidestep that. I suggest dropping that to keep the behavior in line with RFC 2821 and having that paragraph as: 3. Find an alternate route to the destination that permits UTF8SMTP. That route may be discovered by trying alternate MX hosts according to the preference rules specified in RFC 2821. Note that the rule prescribes that all records at that preference level and higher-numbered ones MUST be discarded from consideration. In Section 2.5. ALT-ADDRESS parameter usage and response codes: "When messages are rejected because they require UTF8SMTP, the response code "550" is used, defined in [RFC2821], meaning "mailbox unavailable". If enhanced mail system status codes [RFC3463] are" Shouldn't that be a "553", i.e. mailbox name not allowed? If the SMTP server does not advertize the UTF8SMTP extension, I don't see how we are getting to the stage where we get that response code as we cannot use the ALT-ADDRESS parameter in the MAIL FROM or RCPT TO unless we ignore the absence of UTF8SMTP support. Regards, -sm _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 14 04:14:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW6Jq-0004YV-43; Fri, 14 Sep 2007 04:14:30 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IW6Jo-0004Vz-SH for ima-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 04:14:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW6Jo-0004OQ-0i for ima@ietf.org; Fri, 14 Sep 2007 04:14:28 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IW6Jm-0004kd-Ka for ima@ietf.org; Fri, 14 Sep 2007 04:14:27 -0400 Received: (eyou send program); Fri, 14 Sep 2007 16:14:22 +0800 Message-ID: <389757662.10327@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.35) by 159.226.7.146 with SMTP; Fri, 14 Sep 2007 16:14:22 +0800 Message-ID: <043e01c7f6a7$3f15c0b0$236ff1da@yaojk> From: "YAO Jiankang" To: "SM" References: <389619830.09132@cnnic.cn> Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt Date: Fri, 14 Sep 2007 16:14:17 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1034620945==" Errors-To: ima-bounces@ietf.org --===============1034620945== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNNIiA8c21AcmVzaXN0b3Iu bmV0Pg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDEzLCAy MDA3IDE6NTEgQU0NClN1YmplY3Q6IFtFQUldIFJFVklFVzogZHJhZnQtaWV0Zi1lYWktc210cGV4 dC0wOC50eHQgDQoNCg0KPiBBdCAxMjoxNSAwNC0wOS0yMDA3LCBJbnRlcm5ldC1EcmFmdHNAaWV0 Zi5vcmcgd3JvdGU6DQo+PiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFNNVFAgZXh0ZW5zaW9u IGZvciBpbnRlcm5hdGlvbmFsaXplZCBlbWFpbCBhZGRyZXNzDQo+IA0KPiBJbiBTZWN0aW9uIDIu Mi4gIFRoZSBVVEY4U01UUCBFeHRlbnNpb246DQo+IA0KPiAgICIzLiAgRmluZCBhbiBhbHRlcm5h dGUgcm91dGUgdG8gdGhlIGRlc3RpbmF0aW9uIHRoYXQgcGVybWl0cyBVVEY4U01UUC4NCj4gICAg ICAgIFRoYXQgcm91dGUgbWF5IGJlIGRpc2NvdmVyZWQgYnkgdHJ5aW5nIGFsdGVybmF0ZSBNWCBo b3N0cyAodXNpbmcNCj4gICAgICAgIHByZWZlcmVuY2UgcnVsZXMgYXMgc3BlY2lmaWVkIGluIFJG QyAyODIxKSBvciB1c2luZyBvdGhlciBtZWFucw0KPiAgICAgICAgYXZhaWxhYmxlIHRvIHRoZSBT TVRQLXNlbmRlci4iDQo+IA0KPiBUaGUgcmVjZWl2ZXIgcHVibGlzaGVzIE1YIHJlY29yZHMgdG8g aW5kaWNhdGUgd2hpY2ggTVggaG9zdHMgd2lsbCBiZSANCj4gaGFuZGxpbmcgbWFpbCBmb3IgdGhl IGRvbWFpbiBhbmQgdGhlIG9yZGVyIGluIHdoaWNoIHRoZXkgc2hvdWxkIGJlIA0KPiB0cmllZCAo cHJlZmVyZW5jZSkuICBUaGUgcnVsZXMgYXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMSBvZiBS RkMgDQo+IDI4MjEuICBUaGUgIm9yIHVzaW5nIG90aGVyIG1lYW5zIGF2YWlsYWJsZSB0byB0aGUg U01UUC1zZW5kZXIiIA0KPiBpbnRyb2R1Y2VzIGEgcnVsZSBmb3IgdGhlIHNlbmRlciB0byBzaWRl c3RlcCB0aGF0LiAgSSBzdWdnZXN0IA0KPiBkcm9wcGluZyB0aGF0IHRvIGtlZXAgdGhlIGJlaGF2 aW9yIGluIGxpbmUgd2l0aCBSRkMgMjgyMSBhbmQgaGF2aW5nIA0KPiB0aGF0IHBhcmFncmFwaCBh czoNCj4gDQo+ICAgIDMuICBGaW5kIGFuIGFsdGVybmF0ZSByb3V0ZSB0byB0aGUgZGVzdGluYXRp b24gdGhhdCBwZXJtaXRzIFVURjhTTVRQLg0KPiAgICAgICAgVGhhdCByb3V0ZSBtYXkgYmUgZGlz Y292ZXJlZCBieSB0cnlpbmcgYWx0ZXJuYXRlIE1YIGhvc3RzIGFjY29yZGluZw0KPiAgICAgICAg dG8gdGhlIHByZWZlcmVuY2UgcnVsZXMgc3BlY2lmaWVkIGluIFJGQyAyODIxLg0KDQpnb29kIHRl eHQuIFdlIHdpbGwgY29uc2lkZXIgdG8gdXBkYXRlIGl0Lg0KDQo+IA0KPiBOb3RlIHRoYXQgdGhl IHJ1bGUgcHJlc2NyaWJlcyB0aGF0IGFsbCByZWNvcmRzIGF0IHRoYXQgcHJlZmVyZW5jZSANCj4g bGV2ZWwgYW5kIGhpZ2hlci1udW1iZXJlZCBvbmVzIE1VU1QgYmUgZGlzY2FyZGVkIGZyb20gY29u c2lkZXJhdGlvbi4NCj4gDQo+IEluIFNlY3Rpb24gMi41LiAgQUxULUFERFJFU1MgcGFyYW1ldGVy IHVzYWdlIGFuZCByZXNwb25zZSBjb2RlczoNCj4gDQo+ICAgIldoZW4gbWVzc2FnZXMgYXJlIHJl amVjdGVkIGJlY2F1c2UgdGhleSByZXF1aXJlIFVURjhTTVRQLCB0aGUNCj4gICAgcmVzcG9uc2Ug Y29kZSAiNTUwIiBpcyB1c2VkLCBkZWZpbmVkIGluIFtSRkMyODIxXSwgbWVhbmluZyAibWFpbGJv eA0KPiAgICB1bmF2YWlsYWJsZSIuICBJZiBlbmhhbmNlZCBtYWlsIHN5c3RlbSBzdGF0dXMgY29k ZXMgW1JGQzM0NjNdIGFyZSINCj4gDQo+IFNob3VsZG4ndCB0aGF0IGJlIGEgIjU1MyIsIGkuZS4g bWFpbGJveCBuYW1lIG5vdCBhbGxvd2VkPw0KDQpJbiBteSB2aWV3LCBib3RoICI1NTMiIGFuZCAi NTUwIiBhcmUgb2suDQoNCj4gDQo+IElmIHRoZSBTTVRQIHNlcnZlciBkb2VzIG5vdCBhZHZlcnRp emUgdGhlIFVURjhTTVRQIGV4dGVuc2lvbiwgSSBkb24ndCANCj4gc2VlIGhvdyB3ZSBhcmUgZ2V0 dGluZyB0byB0aGUgc3RhZ2Ugd2hlcmUgd2UgZ2V0IHRoYXQgcmVzcG9uc2UgY29kZSANCj4gYXMg d2UgY2Fubm90IHVzZSB0aGUgQUxULUFERFJFU1MgcGFyYW1ldGVyIGluIHRoZSBNQUlMIEZST00g b3IgUkNQVCANCj4gVE8gdW5sZXNzIHdlIGlnbm9yZSB0aGUgYWJzZW5jZSBvZiBVVEY4U01UUCAg c3VwcG9ydC4NCg0KSSBzdGlsbCBjYW4gbm90IHVuZGVyc3RhbmQgd2hhdCBpcyB5b3VyIG1lYW5p bmcgYWJvdmUgdmVyeSBjbGVhcmx5Lg0KQ291bGQgeW91IGhlbHAgbWUgYmVpbmcgdW5kZXJzdG9v ZD8NCml0IG1lYW5zIHRoYXQNCiBJZiB0aGUgU01UUCBzZXJ2ZXIgZG9lcyBub3QgYWR2ZXJ0aXpl IHRoZSBVVEY4U01UUCBleHRlbnNpb24gYW5kICB0aGVyZSBpcyBubyBBTFQtQUREUkVTUyBwYXJh bWV0ZXIgaW4gdGhlIE1BSUwgRlJPTSBvciBSQ1BUICwgDQpob3cgd2UgZ2V0IHRoZSByZXNwb25z ZSBjb2RlPw0KDQoNClRoYW5rcyBhIGxvdC4NCg0KWUFPIEppYW5rYW5nDQpDTk5JQw0KDQo+IA0K PiBSZWdhcmRzLA0KPiAtc20gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ0KPg== --===============1034620945== 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 --===============1034620945==-- From ima-bounces@ietf.org Fri Sep 14 04:33:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW6cL-00060O-2C; Fri, 14 Sep 2007 04:33:37 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IW6cJ-00060H-Ve for ima-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 04:33:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW6cJ-000609-Kr for ima@ietf.org; Fri, 14 Sep 2007 04:33:35 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IW6cJ-00059e-2P for ima@ietf.org; Fri, 14 Sep 2007 04:33:35 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IW6cI-000GA4-26; Fri, 14 Sep 2007 04:33:34 -0400 Date: Fri, 14 Sep 2007 04:33:33 -0400 From: John C Klensin To: SM , ima@ietf.org Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt Message-ID: In-Reply-To: <6.2.5.6.2.20070912095432.030088a8@resistor.net> References: <6.2.5.6.2.20070912095432.030088a8@resistor.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 12 September, 2007 10:51 -0700 SM wrote: > At 12:15 04-09-2007, Internet-Drafts@ietf.org wrote: >> Title : SMTP extension for >> internationalized email address > > In Section 2.2. The UTF8SMTP Extension: > > "3. Find an alternate route to the destination that > permits UTF8SMTP. > That route may be discovered by trying alternate MX > hosts (using > preference rules as specified in RFC 2821) or using > other means > available to the SMTP-sender." > > The receiver publishes MX records to indicate which MX hosts > will be handling mail for the domain and the order in which > they should be tried (preference). The rules are described in > Section 5.1 of RFC 2821. The "or using other means available > to the SMTP-sender" introduces a rule for the sender to > sidestep that. I suggest dropping that to keep the behavior > in line with RFC 2821 and having that paragraph as: > > 3. Find an alternate route to the destination that > permits UTF8SMTP. > That route may be discovered by trying alternate MX > hosts according > to the preference rules specified in RFC 2821. > > Note that the rule prescribes that all records at that > preference level and higher-numbered ones MUST be discarded > from consideration. Careful... 2821 is _very_ careful about this. Once any host in the preference list receives the mail, it is responsible for delivery, etc., but using SMTP and following the preference rules is only one of the options available to it. It is free to move the mail toward the final destination using any method it likes, including ocpying it to small pieces of paper and sending out a flock of pigeons. EAI-smtpext should not be more restrictive, IMO. > In Section 2.5. ALT-ADDRESS parameter usage and response > codes: > > "When messages are rejected because they require UTF8SMTP, > the > response code "550" is used, defined in [RFC2821], meaning > "mailbox > unavailable". If enhanced mail system status codes > [RFC3463] are" > > Shouldn't that be a "553", i.e. mailbox name not allowed? > > If the SMTP server does not advertize the UTF8SMTP extension, > I don't see how we are getting to the stage where we get that > response code as we cannot use the ALT-ADDRESS parameter in > the MAIL FROM or RCPT TO unless we ignore the absence of > UTF8SMTP support. Correct, I believe. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 14 05:54:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW7sS-0004OM-L8; Fri, 14 Sep 2007 05:54:20 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IW7sQ-0004O5-So for ima-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 05:54:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW7sQ-0004Nw-Gf for ima@ietf.org; Fri, 14 Sep 2007 05:54:18 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW7sP-0000Fo-1u for ima@ietf.org; Fri, 14 Sep 2007 05:54:18 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 46C7B2596EC; Fri, 14 Sep 2007 11:54:16 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31794-08; Fri, 14 Sep 2007 11:54:11 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5E5362596EA; Fri, 14 Sep 2007 11:54:11 +0200 (CEST) Message-ID: <46EA5A43.2080203@alvestrand.no> Date: Fri, 14 Sep 2007 11:54:11 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: SM Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt References: <6.2.5.6.2.20070912095432.030088a8@resistor.net> In-Reply-To: <6.2.5.6.2.20070912095432.030088a8@resistor.net> 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: 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 SM wrote: > > If the SMTP server does not advertize the UTF8SMTP extension, I don't > see how we are getting to the stage where we get that response code as > we cannot use the ALT-ADDRESS parameter in the MAIL FROM or RCPT TO > unless we ignore the absence of UTF8SMTP support. If the SMTP server does not advertise the UTF8SMTP extension, none of the procedures described in this document apply; the sender has to follow the rules of 2821, and may choose to apply the provisions of the -downgrade document in order to get a message that can be sent under those rules. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 14 06:23:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW8Kp-0007k3-Qh; Fri, 14 Sep 2007 06:23:39 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IW8Ko-0007iG-Qr for ima-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 06:23:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW8Ko-0007i8-H7 for ima@ietf.org; Fri, 14 Sep 2007 06:23:38 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW8Kn-0000va-A1 for ima@ietf.org; Fri, 14 Sep 2007 06:23:38 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C0BE02596C1; Fri, 14 Sep 2007 12:23:36 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32240-09; Fri, 14 Sep 2007 12:23:31 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 95A922596BF; Fri, 14 Sep 2007 12:23:31 +0200 (CEST) Message-ID: <46EA6123.3090301@alvestrand.no> Date: Fri, 14 Sep 2007 12:23:31 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: SM Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt References: <6.2.5.6.2.20070912095432.030088a8@resistor.net> In-Reply-To: <6.2.5.6.2.20070912095432.030088a8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org SM wrote: > consideration. > > In Section 2.5. ALT-ADDRESS parameter usage and response codes: > > "When messages are rejected because they require UTF8SMTP, the > response code "550" is used, defined in [RFC2821], meaning "mailbox > unavailable". If enhanced mail system status codes [RFC3463] are" > > Shouldn't that be a "553", i.e. mailbox name not allowed? > > If the SMTP server does not advertize the UTF8SMTP extension, I don't > see how we are getting to the stage where we get that response code as > we cannot use the ALT-ADDRESS parameter in the MAIL FROM or RCPT TO > unless we ignore the absence of UTF8SMTP support. oops - I misunderstood. you can get into this situation if the SMTP server advertises the UTF8SMTP extension, but knows that it may have to forward the message to some other system that does not support UTF8SMTP - for instance, it may have a local IMAP server that doesn't support UTF8SMTP, but have a local POP server that does - so for a POP recipient, UTF8SMTP-requiring mails would be OK, but for an IMAP recipient, it would have to reject them. Other situations are surely imaginable. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 14 13:08:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWEeD-0006lR-Pj; Fri, 14 Sep 2007 13:08:05 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IWEeC-0006jv-BE for ima-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 13:08:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWEeB-0006gj-Q3 for ima@ietf.org; Fri, 14 Sep 2007 13:08:03 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWEeA-0003LH-DZ for ima@ietf.org; Fri, 14 Sep 2007 13:08:03 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1IWEe6-000PFX-VE; Fri, 14 Sep 2007 13:07:59 -0400 Date: Fri, 14 Sep 2007 13:07:57 -0400 From: John C Klensin To: Harald Alvestrand , SM Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt Message-ID: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Friday, 14 September, 2007 12:23 +0200 Harald Alvestrand wrote: > SM wrote: >> consideration. >> >> In Section 2.5. ALT-ADDRESS parameter usage and response >> codes: >> >> "When messages are rejected because they require UTF8SMTP, >> the response code "550" is used, defined in [RFC2821], >> meaning "mailbox unavailable". If enhanced mail system >> status codes [RFC3463] are" >> >> Shouldn't that be a "553", i.e. mailbox name not allowed? >> >> If the SMTP server does not advertize the UTF8SMTP extension, >> I don't see how we are getting to the stage where we get >> that response code as we cannot use the ALT-ADDRESS >> parameter in the MAIL FROM or RCPT TO unless we ignore the >> absence of UTF8SMTP support. > oops - I misunderstood. > > you can get into this situation if the SMTP server advertises > the UTF8SMTP extension, but knows that it may have to forward > the message to some other system that does not support > UTF8SMTP - for instance, it may have a local IMAP server that > doesn't support UTF8SMTP, but have a local POP server that > does - so for a POP recipient, UTF8SMTP-requiring mails would > be OK, but for an IMAP recipient, it would have to reject them. > > Other situations are surely imaginable. Harald, It feels to me as if this may be another section of the hypothetical "recommendations to implementers and for configuration" doc, which I hope someone is planning to write. Consider that, in the general case, the SMTP server cannot have any idea how the user will pick up the mail since a given user may use POP on even-numbered days, IMAP on odd ones, and something else entirely in any month in which there are five Fridays. The 821/2821 requirement that a server either deliver the mail or not, i.e., that it not deliver and report an error further constrains the situation. So, in the example you give, if the POP server is to be supported, the SMTP server would need to return a positive response in all cases. I think that would leave it in a major tangle if it did not support some sort of post-SMTP-delivery downgrading, but that isn't a topic for the smptext document. The situation you describe could arise if the SMTP server had UTF8SMTP capability but the mail store to which delivery was to be made for that particular user would not accept 8bit delivery and no post-delivery downgrading was available. But, while I can imagine a few edge cases involving delivery SMTP servers using different mail stores (with different capabilities) for different users, it would, in general, be fairly bizarre to configure things that way. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 14 14:44:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWG9X-0002qG-BK; Fri, 14 Sep 2007 14:44:31 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IWG9V-0002q9-So for ima-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 14:44:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWG9V-0002q1-He for ima@ietf.org; Fri, 14 Sep 2007 14:44:29 -0400 Received: from ns1.qubic.net ([208.185.248.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWG9V-0008SF-1G for ima@ietf.org; Fri, 14 Sep 2007 14:44:29 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Alpha0/8.14.2.Alpha0) with ESMTP id l8EIhlRP009778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Sep 2007 11:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1189795452; x=1189881852; bh=n/rV7CjGyDAjI2wVi/hYqcNYsodaPCdYfqUL Jvwy+PY=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type; b=yGy IbdxfXgXpNtE9qrGP0Di4TjYEqxceXMv+gzLPu1590cdhXkoXMXrZhfGdpi2H81lop+ K9b1NfAID9E5UP59EUlJlJRl1tAfU8pcR7Ic8MmqSf4MIaxQOOk6fs0NG2rURWTEv2P 1dz4SFQ0xXaHGWpQcO36ObUl3RO20mWCFg= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=uFPOAXHJkiLNEoFqjK1gDX5N4yLO9e7hLniKbVlrQShQ7zmTOXaxX+xBd25XD/j2N vVYPRKyonQclHyGJenXH1KZPSRS6jjIlSxU0pQk3CLhiIrdvEd0D504p+Z8h3ofgesG +xH5b5cWk2LpS9m6BC0JhpbEV3w8Eutny3/zhIw= Message-Id: <6.2.5.6.2.20070914105639.02fe8a28@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Sep 2007 11:43:30 -0700 To: YAO Jiankang From: SM Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt In-Reply-To: <389757662.10327@cnnic.cn> References: <389619830.09132@cnnic.cn> <389757662.10327@cnnic.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 01:14 14-09-2007, YAO Jiankang wrote: >I still can not understand what is your meaning above very clearly. >Could you help me being understood? >it means that > If the SMTP server does not advertize the UTF8SMTP extension > and there is no ALT-ADDRESS parameter in the MAIL FROM or RCPT , >how we get the response code? What I meant was that if the SMTP server does not have UTF8SMTP support, then a compliant SMTP client won't try using the ALT-ADDRESS parameter in MAIL FROM or RCPT TO. If the SMTP client is using ALT-ADDRESS (I'm still talking about SMTP server mentioned above), then it is not compliant with RFC 2821. Quoting Section 4.1.1.3 (RCPT) of RFC 2821: "If service extensions were negotiated, the RCPT command may also carry parameters associated with a particular service extension offered by the server. The client MUST NOT transmit parameters other than those associated with a service extension offered by the server in its EHLO response." Any response code given for such a case would fall under RFC 2821 then instead of eai-smtpext. Regards, -sm _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 14 16:22:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWHgP-0002bd-5g; Fri, 14 Sep 2007 16:22:33 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IWHgO-0002bU-2X for ima-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 16:22:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWHgN-0002bM-P5 for ima@ietf.org; Fri, 14 Sep 2007 16:22:31 -0400 Received: from ns1.qubic.net ([208.185.248.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWHgK-0001JO-BS for ima@ietf.org; Fri, 14 Sep 2007 16:22:31 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Alpha0/8.14.2.Alpha0) with ESMTP id l8EKLvUg021083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Sep 2007 13:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1189801334; x=1189887734; bh=D3vrSrqWyfZqJNuWeA53xMHmNdUi+J1so4L7 m2UvUnY=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:In-Reply-To:References:Mime-Version:Content-Type:Cc; b=L3l y2mksgnQWai3nJTDiC9bqMF196kntYSSoStn76giriEv6AUCEU1Gna6toHvtTYlaU4Y adFqr8QHzo4QaB83UJMCBAM3L4KglxIls8TBsSeL5d0SRZoobg6hd5JeobbRc1SrBkZ mY0fJvDizIz7/V2nBcc5CKZBsTikepu4Jc= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=otXBGdggEl8Sj4vaf246h1i2MLd29ZEoPwA+I0weS7Q02bTJen3gAAP9c5LeOoy9o Bn2ocqHqYEa7D7XJWlAiMW9wjUx1+USQlcmY0RwK6gcGaOpOoBrlktwSl2n5YJ5/CWH Q8qVfnCF2znaTM8A1duFFcNFt73Sl2EBpg2AZMg= Message-Id: <6.2.5.6.2.20070914114713.02f109e8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Sep 2007 13:21:38 -0700 To: ima@ietf.org From: SM Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt In-Reply-To: References: <6.2.5.6.2.20070912095432.030088a8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 01:33 14-09-2007, John C Klensin wrote: >Careful... 2821 is _very_ careful about this. Once any host in >the preference list receives the mail, it is responsible for >delivery, etc., but using SMTP and following the preference >rules is only one of the options available to it. It is free to >move the mail toward the final destination using any method it >likes, including ocpying it to small pieces of paper and sending >out a flock of pigeons. EAI-smtpext should not be more >restrictive, IMO. My point is that EAI-smtpext should defer to RFC 2821 when it comes to dealing with the preference list. Any host in the preference list taking responsibility for a message is free to do what it deems necessary to get the mail to its destination. At 03:23 14-09-2007, Harald Alvestrand wrote: >you can get into this situation if the SMTP server advertises the >UTF8SMTP extension, but knows that it may have to forward the >message to some other system that does not support UTF8SMTP - for >instance, it may have a local IMAP server that doesn't support >UTF8SMTP, but have a local POP server that does - so for a POP >recipient, UTF8SMTP-requiring mails would be OK, but for an IMAP >recipient, it would have to reject them. Thanks for the explanation. I suggest the following change in line with the above: When the address is rejected because the mailbox does not support UTF8SMTP, the response code "553" is used, defined in [RFC2821], meaning "mailbox name not allowed". If enhanced mail system status codes [RFC3463] are used, the response code should be "5.6.x" [SMTP-codes], meaning that "The alt-address is required but not specified". In my opinion, "mailbox does not support UTF8SMTP" covers the case where the system where the message will be forwarded to doesn't support UTF8SMTP. If it is not clear, we could have: "because of lack of UTF8SMTP support (e.g. mailbox or destination does not support UTF8SMTP" The mailbox will be allowed if an alt-address is specified. Regards, -sm _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 14 18:06:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJIj-0005kD-CR; Fri, 14 Sep 2007 18:06:13 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IWJIi-0005eD-1s for ima-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 18:06:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJIh-0005d0-N0 for ima@ietf.org; Fri, 14 Sep 2007 18:06:11 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWJIh-0007Bn-AW for ima@ietf.org; Fri, 14 Sep 2007 18:06:11 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1IWJIf-0005DC-OE; Fri, 14 Sep 2007 18:06:10 -0400 Date: Fri, 14 Sep 2007 18:06:08 -0400 From: John C Klensin To: SM , ima@ietf.org Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt Message-ID: <4A6479F368636EB6E34B34EE@[192.168.0.3]> In-Reply-To: <6.2.5.6.2.20070914114713.02f109e8@resistor.net> References: <6.2.5.6.2.20070912095432.030088a8@resistor.net> <6.2.5.6.2.20070914114713.02f109e8@resistor.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 Friday, 14 September, 2007 13:21 -0700 SM wrote: > At 01:33 14-09-2007, John C Klensin wrote: >> Careful... 2821 is _very_ careful about this. Once any host >> in the preference list receives the mail, it is responsible >> for delivery, etc., but using SMTP and following the >> preference rules is only one of the options available to it. >> It is free to move the mail toward the final destination >> using any method it likes, including ocpying it to small >> pieces of paper and sending out a flock of pigeons. >> EAI-smtpext should not be more restrictive, IMO. > > My point is that EAI-smtpext should defer to RFC 2821 when it > comes to dealing with the preference list. Any host in the > preference list taking responsibility for a message is free to > do what it deems necessary to get the mail to its destination. Agreed. I can see no reason why smtpext should handle this case differently from the SMTP norm. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 14 21:42:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWMft-0001OF-Vt; Fri, 14 Sep 2007 21:42:21 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IWMft-0001OA-Hp for ima-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 21:42:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWMft-0001O2-7z for ima@ietf.org; Fri, 14 Sep 2007 21:42:21 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWMfr-0003OI-NV for ima@ietf.org; Fri, 14 Sep 2007 21:42:21 -0400 Received: (snipe 14932 invoked by uid 0); 15 Sep 2007 10:42:54 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 1.083546 secs); Received: from unknown (HELO ?210.107.251.4?) (Z???own@210.107.251.4) by unknown with SMTP; 15 Sep 2007 10:42:53 +0900 X-SNIPER-SENDERIP: 210.107.251.4 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: klensin@jck.com, harald@alvestrand.no, sm@resistor.net, ima@ietf.org, yangwooko@gmail.com Message-ID: <46EB388A.5060106@icu.ac.kr> Date: Sat, 15 Sep 2007 10:42:34 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt References: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> In-Reply-To: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > > > --On Friday, 14 September, 2007 12:23 +0200 Harald Alvestrand > wrote: > >> SM wrote: >>> consideration. >>> >>> In Section 2.5. ALT-ADDRESS parameter usage and response >>> codes: >>> >>> "When messages are rejected because they require UTF8SMTP, >>> the response code "550" is used, defined in [RFC2821], >>> meaning "mailbox unavailable". If enhanced mail system >>> status codes [RFC3463] are" >>> >>> Shouldn't that be a "553", i.e. mailbox name not allowed? >>> >>> If the SMTP server does not advertize the UTF8SMTP extension, >>> I don't see how we are getting to the stage where we get >>> that response code as we cannot use the ALT-ADDRESS >>> parameter in the MAIL FROM or RCPT TO unless we ignore the >>> absence of UTF8SMTP support. >> oops - I misunderstood. >> >> you can get into this situation if the SMTP server advertises >> the UTF8SMTP extension, but knows that it may have to forward >> the message to some other system that does not support >> UTF8SMTP - for instance, it may have a local IMAP server that >> doesn't support UTF8SMTP, but have a local POP server that >> does - so for a POP recipient, UTF8SMTP-requiring mails would >> be OK, but for an IMAP recipient, it would have to reject them. >> >> Other situations are surely imaginable. > > Harald, > > It feels to me as if this may be another section of the > hypothetical "recommendations to implementers and for > configuration" doc, which I hope someone is planning to write. > Consider that, in the general case, the SMTP server cannot have > any idea how the user will pick up the mail since a given user > may use POP on even-numbered days, IMAP on odd ones, and > something else entirely in any month in which there are five > Fridays. The 821/2821 requirement that a server either deliver > the mail or not, i.e., that it not deliver and report an error > further constrains the situation. > > So, in the example you give, if the POP server is to be > supported, the SMTP server would need to return a positive > response in all cases. I think that would leave it in a major > tangle if it did not support some sort of post-SMTP-delivery > downgrading, but that isn't a topic for the smptext document. Post SMTP delivery downgrade is described as "MAY" in the framework document. Do we need to change it to "SHOULD" or stronger? Anyway, I have mixed feelings about this. In general, final SMTP server should not be sensitive to configurations of IMAP/POP and others, because SMTP is, as far as I understand, a hop-by-hop protocol and it should not try to convey semantics beyond the current hop. On the other hand, as an end user, it will be very helpful to see where and how a mail delivery fails in end-to-end or sending MUA <--> receiving POP/IMAP/or others) manner. By the way, do we have an end-to-end mail capability checking protocol? > > The situation you describe could arise if the SMTP server had > UTF8SMTP capability but the mail store to which delivery was to > be made for that particular user would not accept 8bit delivery > and no post-delivery downgrading was available. But, while I > can imagine a few edge cases involving delivery SMTP servers > using different mail stores (with different capabilities) for > different users, it would, in general, be fairly bizarre to > configure things that way. > > john > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 14 23:03:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWNw9-0002bQ-HD; Fri, 14 Sep 2007 23:03:13 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IWNw9-0002Zh-3k for ima-confirm+ok@megatron.ietf.org; Fri, 14 Sep 2007 23:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWNw8-0002YK-PJ for ima@ietf.org; Fri, 14 Sep 2007 23:03:12 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWNw7-0006x0-9r for ima@ietf.org; Fri, 14 Sep 2007 23:03:12 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1IWNvu-0009o9-TD; Fri, 14 Sep 2007 23:02:59 -0400 Date: Fri, 14 Sep 2007 23:02:57 -0400 From: John C Klensin To: Yangwoo Ko Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt Message-ID: In-Reply-To: <46EB388A.5060106@icu.ac.kr> References: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> <46EB388A.5060106@icu.ac.kr> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Saturday, 15 September, 2007 10:42 +0900 Yangwoo Ko wrote: >... >> So, in the example you give, if the POP server is to be >> supported, the SMTP server would need to return a positive >> response in all cases. I think that would leave it in a major >> tangle if it did not support some sort of post-SMTP-delivery >> downgrading, but that isn't a topic for the smptext document. > > Post SMTP delivery downgrade is described as "MAY" in the > framework document. Do we need to change it to "SHOULD" or > stronger? I don't think so. The reality is that, in most cases (at least in my experience), delivery MTAs hand things off to mail stores or their management software and not to POP or IMAP servers separately. If the mail store is not 8-bit-header-capable, then Harald's case isn't going to apply because either everything will be downgraded on the way to the store or because the MTA won't offer the UTF8SMTP extension at all. If the mail store is 8-bit-header-capable, then, presumably, the message gets delivered into the store without any downgrading. The interesting cases arise (1) if either the POP or IMAP server (but not both) are 8-bit-header-capable despite working off of a capable message store. However, while the situation may not be under the control of the user or sysadmin, it will generally be easier to upgrade the relevant remote message access server than to modify the message store machinery to provide downgrading. (2) If, despite having adequate capability in the IMAP or POP server, some of the clients are not 8-bit-header-capable. This is the only case I consider likely, but it is very far removed from anything that would affect the smtpext document. Moreover, the "fix" is as likely speaking very sternly with the user about offering to receive mail containing 8bit header or address material when the mail-retrieving agent is not capable of actually receiving that material or about upgrading the MUA or agent as it is about downgrading in that case either. > Anyway, I have mixed feelings about this. In general, final > SMTP server should not be sensitive to configurations of > IMAP/POP and others, because SMTP is, as far as I understand, > a hop-by-hop protocol and it should not try to convey > semantics beyond the current hop. Because this effects only the final delivery MTA, the hop-by-hop character of SMTP isn't involved. But I believe you are correct anyway. > On the other hand, as an end > user, it will be very helpful to see where and how a mail > delivery fails in end-to-end or sending MUA <--> receiving > POP/IMAP/or others) manner. But, generally, one can't tell even today in the non-UTF8SMTP cases. And, when one does find out, it is via an NDN message of some sort, not an SMTP reply. These processes and decisions are just too far downstream to be reflected in SMTP replies.\ > By the way, do we have an end-to-end mail capability checking > protocol? Some work on message tracking/ tracing only. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Sep 15 02:55:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWRYj-00017A-7b; Sat, 15 Sep 2007 02:55:17 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IWRYh-00015C-TU for ima-confirm+ok@megatron.ietf.org; Sat, 15 Sep 2007 02:55:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWRYd-0000yr-TH for ima@ietf.org; Sat, 15 Sep 2007 02:55:11 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWRYc-0005JC-9u for ima@ietf.org; Sat, 15 Sep 2007 02:55:11 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 694B32596F0; Sat, 15 Sep 2007 08:55:09 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00951-10; Sat, 15 Sep 2007 08:55:04 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id C47CD2596CB; Sat, 15 Sep 2007 08:55:03 +0200 (CEST) Message-ID: <46EB81C5.1060700@alvestrand.no> Date: Sat, 15 Sep 2007 08:55:01 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: John C Klensin Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt References: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> In-Reply-To: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> 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: c1c65599517f9ac32519d043c37c5336 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: >> oops - I misunderstood. >> >> you can get into this situation if the SMTP server advertises >> the UTF8SMTP extension, but knows that it may have to forward >> the message to some other system that does not support >> UTF8SMTP - for instance, it may have a local IMAP server that >> doesn't support UTF8SMTP, but have a local POP server that >> does - so for a POP recipient, UTF8SMTP-requiring mails would >> be OK, but for an IMAP recipient, it would have to reject them. >> >> Other situations are surely imaginable. >> > > Harald, > > It feels to me as if this may be another section of the > hypothetical "recommendations to implementers and for > configuration" doc, which I hope someone is planning to write. > Consider that, in the general case, the SMTP server cannot have > any idea how the user will pick up the mail since a given user > may use POP on even-numbered days, IMAP on odd ones, and > something else entirely in any month in which there are five > Fridays. The 821/2821 requirement that a server either deliver > the mail or not, i.e., that it not deliver and report an error > further constrains the situation. > > So, in the example you give, if the POP server is to be > supported, the SMTP server would need to return a positive > response in all cases. I think that would leave it in a major > tangle if it did not support some sort of post-SMTP-delivery > downgrading, but that isn't a topic for the smptext document. > > The situation you describe could arise if the SMTP server had > UTF8SMTP capability but the mail store to which delivery was to > be made for that particular user would not accept 8bit delivery > and no post-delivery downgrading was available. But, while I > can imagine a few edge cases involving delivery SMTP servers > using different mail stores (with different capabilities) for > different users, it would, in general, be fairly bizarre to > configure things that way. I used a bad example (since most IMAP servers I'm familiar with also have POP capability). A more realistic one would be one where the IMAP server was UTF8SMTP compliant, but the mailing list handling software (Mailman in the case of my installation, for instance) was not upgraded. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Sep 15 06:54:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWVHo-0003lC-KB; Sat, 15 Sep 2007 06:54:04 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IWVHn-0003l6-Bn for ima-confirm+ok@megatron.ietf.org; Sat, 15 Sep 2007 06:54:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWVHn-0003ky-1a for ima@ietf.org; Sat, 15 Sep 2007 06:54:03 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWVHm-0000EU-Ku for ima@ietf.org; Sat, 15 Sep 2007 06:54:02 -0400 Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1IWVHj-000J3F-JG; Sat, 15 Sep 2007 06:53:59 -0400 Date: Sat, 15 Sep 2007 06:53:58 -0400 From: John C Klensin To: Harald Alvestrand Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt Message-ID: In-Reply-To: <46EB81C5.1060700@alvestrand.no> References: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> <46EB81C5.1060700@alvestrand.no> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 --On Saturday, 15 September, 2007 08:55 +0200 Harald Alvestrand wrote: >> The situation you describe could arise if the SMTP server had >> UTF8SMTP capability but the mail store to which delivery was >> to be made for that particular user would not accept 8bit >> delivery and no post-delivery downgrading was available. >> But, while I can imagine a few edge cases involving delivery >> SMTP servers using different mail stores (with different >> capabilities) for different users, it would, in general, be >> fairly bizarre to configure things that way. > I used a bad example (since most IMAP servers I'm familiar > with also have POP capability). Yep > A more realistic one would be one where the IMAP server was > UTF8SMTP compliant, but the mailing list handling software > (Mailman in the case of my installation, for instance) was not > upgraded. Yes, but the answer is the same in most cases: too far behind the network-facing side of the delivery MTA to generate real-time reply codes. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Sep 19 04:16:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXuiN-0006fJ-Io; Wed, 19 Sep 2007 04:15:19 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IXuiK-0006dF-Jd for ima-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 04:15:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXuiG-0006an-G6 for ima@ietf.org; Wed, 19 Sep 2007 04:15:12 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IXuiB-000052-AY for ima@ietf.org; Wed, 19 Sep 2007 04:15:08 -0400 Received: (eyou send program); Wed, 19 Sep 2007 16:15:00 +0800 Message-ID: <390189700.01300@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.35) by 159.226.7.146 with SMTP; Wed, 19 Sep 2007 16:15:00 +0800 Message-ID: <033401c7fa95$28162700$236ff1da@yaojk> From: "YAO Jiankang" To: Date: Wed, 19 Sep 2007 16:14:53 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 4.3 (++++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [EAI] Strongly SUPPORT: -smtp, -utf8 and -dsn X-BeenThere: ima@ietf.org 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="===============0109307610==" Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --===============0109307610== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0331_01C7FAD8.36265430" This is a multi-part message in MIME format. ------=_NextPart_000_0331_01C7FAD8.36265430 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCiAgIEkgaGF2ZSByZWFkIHRoZXNlIDMgZG9jdW1lbnRzOg0KICAgZHJhZnQt aWV0Zi1lYWktdXRmOGhlYWRlcnMtMDcNCiAgIGRyYWZ0LWlldGYtZWFpLXNtdHBleHQtMDgNCiAg IGRyYWZ0LWlldGYtZWFpLWRzbi0wMw0KDQpJIHN0cm9uZ2x5IHN1cHBvcnQgdGhlbS4gVGhlIGJh c2ljIGlkZWFzIGFuZCBkZXRhaWxzIGFyZSBvayB0byBiZSBpbXBsZW1lbnRlZC4NCkkgaG9wZSB0 aGF0IENoaW5lc2UgYW5kIGFsbCBub24tRW5nbGlzaCBzcGVha2VycyBjYW4gdXNlIGludGVybmF0 aW9uYWxpemVkIGVtYWlsIGFkZHJlc3Mgc29vbi4NCg0KWUFPIEppYW5rYW5nDQpDTk5JQw== ------=_NextPart_000_0331_01C7FAD8.36265430 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjMxNTciIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNjY2U4Y2Y+DQo8RElWPjxGT05UIHNpemU9Mj5EZWFyIGFsbCw8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj4mbmJzcDsmbmJzcDsgSSBoYXZlIHJlYWQgdGhlc2UgMyBkb2N1bWVudHM6PC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjxGT05U IA0Kc2l6ZT0zPmRyYWZ0LWlldGYtZWFpLXV0ZjhoZWFkZXJzLTA3PEJSPiZuYnNwOyZuYnNwOyAN CmRyYWZ0LWlldGYtZWFpLXNtdHBleHQtMDg8QlI+Jm5ic3A7Jm5ic3A7IGRyYWZ0LWlldGYtZWFp LWRzbi0wMzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5JIHN0cm9uZ2x5IHN1cHBvcnQgdGhlbS4gVGhlIGJhc2ljIGlkZWFzIGFuZCBkZXRhaWxzIGFy ZSBvayB0byANCmJlIGltcGxlbWVudGVkLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PkkgaG9wZSB0aGF0IENoaW5lc2UgYW5kIGFsbCBub24tRW5nbGlzaCBzcGVha2VycyBjYW4gdXNl IA0KaW50ZXJuYXRpb25hbGl6ZWQgZW1haWwgYWRkcmVzcyBzb29uLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPllB TyBKaWFua2FuZzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkNOTklDPC9GT05UPjwv RElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0331_01C7FAD8.36265430-- --===============0109307610== 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 --===============0109307610==-- From ima-bounces@ietf.org Wed Sep 19 05:56:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXwHj-00062y-AN; Wed, 19 Sep 2007 05:55:55 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IXwHh-00060n-JC for ima-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 05:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXwHh-00060V-67 for ima@ietf.org; Wed, 19 Sep 2007 05:55:53 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXwHa-0005It-PG for ima@ietf.org; Wed, 19 Sep 2007 05:55:53 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 Sep 2007 10:55:34 +0100 Message-ID: <46F0F23A.9060601@isode.com> Date: Wed, 19 Sep 2007 10:56:10 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ima@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Subject: [EAI] EDITORIAL: draft-ietf-eai-smtpext-08.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 Hi, Most of the issues below are editorial, some of them can be considered nitpicking. 1). I am having a deja vue about this: why is the document referencing RFC 1869, which got obsoleted by RFC 2821? The two references to RFC 1869 are talking about ESMTP, I think RFC 2821 is quite appropriate. 2). In Section 2.2: The UTF8SMTP extension is valid on the submission port [RFC4409]. This sentence is usually a part of the SMTP service registration template, should it be moved to section 2.1? An SMTP Client that receives the UTF8SMTP extension keyword in response to the "EHLO" command MAY transmit a mailbox name as an internationalized string in UTF-8 form and MAY send an UTF-8 header [EAI-utf8header]. It MAY transmit the domain part of that string in either the form of ACE labels specified in [RFC3490] or UTF-8 form. In the domain part of the mailbox string, if any of the labels are intended to be interpreted as non-ASCII (i.e., are IDNs), then the Message Submission Server ("MSA") [RFC4409] MUST take responsibility for ensuring that the labels are valid (whether they appear in native character or ACE form). Does "native character" mean UTF-8 here? I hope we are not recommending use of any other charsets here. [...] 2. Reject the message during the SMTP transaction or generate a notification of non-deliverability, as specified in RFC 2821 [RFC2821] and RFC 3464 [RFC3464]. If the message content can be returned without alteration, content should be returned as specified in 2821 but, if a server is encountered along the return path that cannot accept UTF8SMTP traffic, the content should simply be abridged or dropped. The last sentence is trying to redefine something already specified in [EAI-dsn]. I think it contradicts [EAI-dsn]. Suggestion to replace the last sentence with a pointer to [EAI-dsn] 3). In Section 2.4: "RCPT TO:" ("" / "" / Should "domain" be replaced with "uDomain" for consistency? (It can be argued that Postmaster@ is still allowed by uForward-Path below:) uForward-Path) [ SP Rcpt-parameters ] CRLF ; Update rcpt command in RFC 2821, section 4.1.1.3. ; A new parameter defined by the ABNF non-terminal ; is added. It complies ; with the syntax specified by . 4). In section 2.6: The UTF8SMTP extension MAY be used with the BODY=8BITMIME parameter if that is appropriate given the body content or, if the server advertises it and it is appropriate, with the BODY=BINARYMIME The use of "it" is confusing here. parameter specified in [RFC3030]. I think the part starting from "if the server advertises" should read: if the server advertises BINARYMIME [RFC3030] and the the BODY=BINARYMIME is appropriate, with the BODY=BINARYMIME parameter. 5). In section 2.7.4: If the VRFY and EXPN commands have the optional parameter "UTF8REPLY", it indicates the client can accept UTF-8 on replies of UTF-8 *in* replies *to* the VRFY and EXPN commands. Specially this allows to use UTF-8 on UTF-8 *in* (here and in many cases below) mailboxes and full names which occur on replies. The SMTP client following this specification MUST accept UTF-8 on replies of the VRFY and EXPN commands. However the SMTP server MUST not use UTF-8 on replies, if the SMTP client does not ask UTF-8 replies. Some replies include the mailbox, but usually most of replies do not require that the mailbox is included in it and therefore UTF-8 is not needed. The UTF8REPLY parameter on the VRFY and EXPN commands tells the SMTP server that the client is prepared for UTF-8 on SMTP replies. [...] If the SMTP Client lack of the UTF8SMTP support receives the UTF-8 SMTP client *which lacks UTF8SMTP support* receives a UTF-8 message on reply, it may crash. UTF-8 messages on reply are only [*in* reply.] I would change "message" to "text" here to avoid any confusion with RFC 2821 message. allowed in the commands under the situations described above. Under any other circumstances, UTF-8 messages on the reply MUST NOT be used. 6). In Section 3.2: The existing draft standard Delivery status notifications (DSNs)[RFC3461] is presently limited to US-ASCII text in the machine readable portions of the protocol. "International Delivery and Disposition Notifications" [EAI-dsn] 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. If an SMTP server advertises both the UTF8SMTP and the DSN extension, that server MUST implement EAI-dsn [EAI-dsn] including support for the ORCPT parameter. This reference to [EAI-dsn] is not informative! I think [EAI-dsn] should be moved from Informative References to Normative References. 7). In Section 10.2: [RFC2554bis] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", draft-siemborski-rfc2554bis-09 (work in progress), April 2007. This is now an RFC 4954. [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. As this document puts some requirements on Submission Agents, I don't think this reference is informative. Regards, Alexey _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Sep 19 06:11:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXwWh-0007E6-Bn; Wed, 19 Sep 2007 06:11:23 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IXwWf-0007CE-72 for ima-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 06:11:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXwWe-0007B6-Rq for ima@ietf.org; Wed, 19 Sep 2007 06:11:20 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXwWe-0003Z6-B1 for ima@ietf.org; Wed, 19 Sep 2007 06:11:20 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 Sep 2007 11:11:17 +0100 Message-ID: <46F0F5E6.9080101@isode.com> Date: Wed, 19 Sep 2007 11:11:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ima@ietf.org References: <46F0F23A.9060601@isode.com> In-Reply-To: <46F0F23A.9060601@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [EAI] Re: EDITORIAL: draft-ietf-eai-smtpext-08.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 Alexey Melnikov wrote: > Hi, > > Most of the issues below are editorial, some of them can be considered > nitpicking. I need to add that otherwise I find the document to be in good shape and support its publication. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Sep 19 08:14:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXyRA-0001Ko-2B; Wed, 19 Sep 2007 08:13:48 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IXyR8-0001Ht-Uy for ima-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 08:13:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXyR8-0001Hk-Gf for ima@ietf.org; Wed, 19 Sep 2007 08:13:46 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXyR7-0006P8-BV for ima@ietf.org; Wed, 19 Sep 2007 08:13:46 -0400 Received: (snipe 17266 invoked by uid 0); 19 Sep 2007 21:14:19 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.409192 secs); Received: from unknown (HELO ?210.107.251.4?) (Z???own@210.107.251.4) by unknown with SMTP; 19 Sep 2007 21:14:18 +0900 X-SNIPER-SENDERIP: 210.107.251.4 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: ima@ietf.org, yangwooko@gmail.com Message-ID: <46F1128A.9030802@icu.ac.kr> Date: Wed, 19 Sep 2007 21:14:02 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Subject: [EAI] Editorial change suggestions -- smtpext-08 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Basically, I support this draft to be published. Below are a few minor / editorial / nitpicky change suggestions. Authors may accept them as much as they like. (1) Abstract > This document specifies the use of SMTP extension for > internationalized email address delivery. This document specifies the use of an SMTP extension for delivery of email messages with internationalized email addresses. (2) First paragraph of 1. Introduction > which clients can make decisions for further processing; please see > more in [EAI-framework]. More of what? More discussion? (3) First paragraph of 1. Introduction > architecturally desirable approach. This document specifies an SMTP > extension to permit internationalized email addresses in envelopes, > and UTF-8 in headers. The protocol described here is an MTA solution and unicode characters (encoded in UTF-8) in headers. (4) End of section 2.2 > address in the envelope is in ASCII or if an ALT-Address ALT-ADDRESS (5) First paragraph of section 2.3 > RFC 2821, section 4.1.2, defines the syntax of a mailbox entirely in > terms of ASCII characters, using the production for "Mailbox" and .. a mailbox entirely in ASCII characters, ... (6) First paragraph of section 2.5 > [EAI-utf8header] specifies "UTF8SMTP message" which requires UTF8SMTP > support. ... which requires UTF8SMTP service extension. (7) Last paragraph of section 2.7 > Support and use of this extension requires support for 8BITMIME. It > means that 8BITMIME MUST be advertised by the UTF8SMTP capable SMTP > server. This requirement is already said in section 2.1. Could be removed. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Sep 19 08:59:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXz8L-0004ea-Kr; Wed, 19 Sep 2007 08:58:25 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IXz8J-0004Yy-F6 for ima-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 08:58:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXz8J-0004Yo-1y for ima@ietf.org; Wed, 19 Sep 2007 08:58:23 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXz8A-0000wT-4c for ima@ietf.org; Wed, 19 Sep 2007 08:58:23 -0400 Received: (snipe 29315 invoked by uid 0); 19 Sep 2007 21:58:37 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.405369 secs); Received: from unknown (HELO ?210.107.251.4?) (Z???own@210.107.251.4) by unknown with SMTP; 19 Sep 2007 21:58:37 +0900 X-SNIPER-SENDERIP: 210.107.251.4 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: ima@ietf.org, yangwooko@gmail.com Message-ID: <46F11CEC.7030205@icu.ac.kr> Date: Wed, 19 Sep 2007 21:58:20 +0900 From: Yangwoo Ko User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [EAI] Editorial change suggestions -- utf8headers X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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 support this draft to be published. Below are a few editorial / minor change suggestions. (1) Last paragraph of Section 4. > Those syntax rules not referred to this section remain as the > original definition in [RFC2822]. Those syntax rules that are not redefined in this section remain ... (2) First paragraph of section 4.1 > UTF-8 characters can be defined in terms of octets using the > following ABNF, taken from [RFC3629]:" Please remove " at the end of the line. (3) First paragraph of section 4.4 > as well as an additional, optional all-ascii alternate address. Note ... all-ASCII... > that MSAs and MTAs may downgrade internationalized messages as > needed. The procedure for doing so in described in [EAI-downgrading]. ... for doing so is described in ... (4) Section 4.6 > Subtype name: utf8smtp global now? > File extension(s): The extension ".u8msg" is suggested. Could be ".globalmsg" (or something similar) or keep as is? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Sep 19 15:36:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY5L3-00028t-7S; Wed, 19 Sep 2007 15:35:57 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IY5L1-00026X-HO for ima-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 15:35:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY5L1-0001vl-0B for ima@ietf.org; Wed, 19 Sep 2007 15:35:55 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY5Kb-00033J-S2 for ima@ietf.org; Wed, 19 Sep 2007 15:35:30 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3&clerew^man#ac#uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.256) id 46f179ff.5031.87 for ima@ietf.org; Wed, 19 Sep 2007 20:35:27 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8JJZOxE009522 for ; Wed, 19 Sep 2007 20:35:25 +0100 (BST) To: IMA Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt References: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> Message-ID: Date: Wed, 19 Sep 2007 20:35:23 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Fri, 14 Sep 2007 18:07:57 +0100, John C Klensin wrote: > --On Friday, 14 September, 2007 12:23 +0200 Harald Alvestrand > wrote: > > It feels to me as if this may be another section of the > hypothetical "recommendations to implementers and for > configuration" doc, which I hope someone is planning to write. > Consider that, in the general case, the SMTP server cannot have > any idea how the user will pick up the mail since a given user > may use POP on even-numbered days, IMAP on odd ones, and > something else entirely in any month in which there are five > Fridays. The 821/2821 requirement that a server either deliver > the mail or not, i.e., that it not deliver and report an error > further constrains the situation. > > So, in the example you give, if the POP server is to be > supported, the SMTP server would need to return a positive > response in all cases. I think that would leave it in a major > tangle if it did not support some sort of post-SMTP-delivery > downgrading, but that isn't a topic for the smptext document. But surely this is just the distinction between 'Reject' and 'Bounce' that we have discussed before. If an MTA returns a 2xx response, then the most it is claiming is "I think I know what to do with this message, so I am accepting (allowing you to send) it; but the next man in line might think otherwise, in which case I promise to send a bounce (DSN) up the Return Path". That can apply whether the "next man" is the next hop to another MTA, or whether it is some complex situation in the local storage/delivery/forwarding system. So I see no reason why the (supposedly final) MTA cannot accept the message, but later bounce it because it subsequently transpires that there are the wrong number of Fridays in this particular month. Just so long as it does not lose it without trace. -- 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 Sep 19 18:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY7uU-0000K3-1g; Wed, 19 Sep 2007 18:20:42 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IY7uR-0000JS-W0 for ima-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 18:20:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY7uR-0000Gg-K0 for ima@ietf.org; Wed, 19 Sep 2007 18:20:39 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY7uF-0000J9-LP for ima@ietf.org; Wed, 19 Sep 2007 18:20:33 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3&clerew&man$ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.254) id 46f1a097.94a.92 for ima@ietf.org; Wed, 19 Sep 2007 23:20:07 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8JMK4Lu019910 for ; Wed, 19 Sep 2007 23:20:05 +0100 (BST) Date: Wed, 19 Sep 2007 23:20:03 +0100 To: ima@ietf.org From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [EAI] EDITORIAL: utf8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org 4.6. message/global Internationalized messages, also called UTF8SMTP messages, must only be transmitted as authorized by [EAI-SMTP-extension] or within a non- SMTP environment which supports these messages. A message is a "message/global message", if There seems to be a confusion between the new type of message we have now invented (we used to call them "UTF8SMTP messages" and now we seem to be calling then "global messages") and the MIME-type which is sometimes used to encapsulate them. So I think what you need to say above is: ... A message is termed a "global message" if o it contains UTF-8 header values as specified in this document, or o it contains UTF-8 values in the headers fields of body parts. Note that the DSN draft is still using the term "UTF8SMTP messages", and needs to be changed. The second type, used for content return, is message/global which is similar to message/rfc822, except it contains a message with UTF-8 headers. What does "second" mean there (or where is the "first type")? It can't refer to your 2nd bullet above, since that situation can arise within a multipart type with no message/global in sight. Moreover, use of the message/global type is not restricted to "content return"; it can be used wherever encapsulation of a global message is required. So I think that wording should be: A new MIME type "message global" is defined for encapsulating global messages (such as when content is returned in a DSN). This type is similar to message. rfc822, except that it contains ... This type has profound implications on the email infrastructure. If this type is sent to a 7-bit-only system, it could be encoded in [RFC2045]. (Note that a system compliant with MIME that doesn't recognize message/global would treat it as "application/octet-stream" as described in Section 5.2.4 of [RFC2046].) ... I have already pointed out that many existing systems do not treat it as "application/octet stream" (whether or not they are supposed to do that, which is arguable). ...... Type name: message Subtype name: utf8smtp ^^^^^^^^ global -- 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 Sep 19 18:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY7um-0000TT-K8; Wed, 19 Sep 2007 18:21:00 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IY7ul-0000TO-CI for ima-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 18:20:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY7ul-0000TG-2X for ima@ietf.org; Wed, 19 Sep 2007 18:20:59 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY7uj-0000KQ-LT for ima@ietf.org; Wed, 19 Sep 2007 18:20:59 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3$clerew$man$ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.254) id 46f1a0c8.762.91 for ima@ietf.org; Wed, 19 Sep 2007 23:20:57 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8JMKsuh019963 for ; Wed, 19 Sep 2007 23:20:54 +0100 (BST) Date: Wed, 19 Sep 2007 23:20:53 +0100 To: ima@ietf.org From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [EAI] ISSUE utf8 meaage/global X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org 4.2. Changes on MIME headers This specification updates section 6.4 of RFC 2045. RFC 2045 prohibits applying a content-transfer-encoding to all subtypes of message/. This specification relaxes the rule, allowing newly defined MIME types to permit content-transfer-encoding. (see Section 4.6). I reiterate my objection to this breach of the "EXPRESSLY FORBIDDEN" rule in RFC 2045, unless it can be established that a significant part of the installed base of MTAs will cope with it when downgrading to Non-8BITMIME (it is already established that a significant part of that base will _not_ cope with it). It is claimed in 4.6 that existing MTAs will cope with this unknown MIME type by treating it as application/octet stream (although it is unclear whether that default pvovision was ever intended to apply to other than MUAs, and whether MUAs handle Q-P and Base64 in message types is irrelevant to my argument). The issue is what the current installed base of MTAs actually _does_ (rightly or wrongly). Note that we are now proposing to apply this relaxation to four new message types: message/global message/global-delivery-status message/global-headers message/global-disposition-notification of which problems with the third could be avoided by using text/global-headers instead. I understand that the consensus is against me on this issue, and I am therefore not asking that it be reopened at this stage. However, I repeat what I have already stated before, that I intend to raise it at IESG Last Call. Note that I have written separate EDITORIAL comments on the utf8 and dsn drafts. -- 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 Sep 19 18:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY7uU-0000K3-1g; Wed, 19 Sep 2007 18:20:42 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IY7uR-0000JS-W0 for ima-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 18:20:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY7uR-0000Gg-K0 for ima@ietf.org; Wed, 19 Sep 2007 18:20:39 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY7uF-0000J9-LP for ima@ietf.org; Wed, 19 Sep 2007 18:20:33 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3&clerew&man$ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.254) id 46f1a097.94a.92 for ima@ietf.org; Wed, 19 Sep 2007 23:20:07 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8JMK4Lu019910 for ; Wed, 19 Sep 2007 23:20:05 +0100 (BST) Date: Wed, 19 Sep 2007 23:20:03 +0100 To: ima@ietf.org From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [EAI] EDITORIAL: utf8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org 4.6. message/global Internationalized messages, also called UTF8SMTP messages, must only be transmitted as authorized by [EAI-SMTP-extension] or within a non- SMTP environment which supports these messages. A message is a "message/global message", if There seems to be a confusion between the new type of message we have now invented (we used to call them "UTF8SMTP messages" and now we seem to be calling then "global messages") and the MIME-type which is sometimes used to encapsulate them. So I think what you need to say above is: ... A message is termed a "global message" if o it contains UTF-8 header values as specified in this document, or o it contains UTF-8 values in the headers fields of body parts. Note that the DSN draft is still using the term "UTF8SMTP messages", and needs to be changed. The second type, used for content return, is message/global which is similar to message/rfc822, except it contains a message with UTF-8 headers. What does "second" mean there (or where is the "first type")? It can't refer to your 2nd bullet above, since that situation can arise within a multipart type with no message/global in sight. Moreover, use of the message/global type is not restricted to "content return"; it can be used wherever encapsulation of a global message is required. So I think that wording should be: A new MIME type "message global" is defined for encapsulating global messages (such as when content is returned in a DSN). This type is similar to message. rfc822, except that it contains ... This type has profound implications on the email infrastructure. If this type is sent to a 7-bit-only system, it could be encoded in [RFC2045]. (Note that a system compliant with MIME that doesn't recognize message/global would treat it as "application/octet-stream" as described in Section 5.2.4 of [RFC2046].) ... I have already pointed out that many existing systems do not treat it as "application/octet stream" (whether or not they are supposed to do that, which is arguable). ...... Type name: message Subtype name: utf8smtp ^^^^^^^^ global -- 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 Sep 19 18:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY7um-0000TT-K8; Wed, 19 Sep 2007 18:21:00 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IY7ul-0000TO-CI for ima-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 18:20:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY7ul-0000TG-2X for ima@ietf.org; Wed, 19 Sep 2007 18:20:59 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY7uj-0000KQ-LT for ima@ietf.org; Wed, 19 Sep 2007 18:20:59 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3$clerew$man$ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.254) id 46f1a0c8.762.91 for ima@ietf.org; Wed, 19 Sep 2007 23:20:57 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8JMKsuh019963 for ; Wed, 19 Sep 2007 23:20:54 +0100 (BST) Date: Wed, 19 Sep 2007 23:20:53 +0100 To: ima@ietf.org From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [EAI] ISSUE utf8 meaage/global X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org 4.2. Changes on MIME headers This specification updates section 6.4 of RFC 2045. RFC 2045 prohibits applying a content-transfer-encoding to all subtypes of message/. This specification relaxes the rule, allowing newly defined MIME types to permit content-transfer-encoding. (see Section 4.6). I reiterate my objection to this breach of the "EXPRESSLY FORBIDDEN" rule in RFC 2045, unless it can be established that a significant part of the installed base of MTAs will cope with it when downgrading to Non-8BITMIME (it is already established that a significant part of that base will _not_ cope with it). It is claimed in 4.6 that existing MTAs will cope with this unknown MIME type by treating it as application/octet stream (although it is unclear whether that default pvovision was ever intended to apply to other than MUAs, and whether MUAs handle Q-P and Base64 in message types is irrelevant to my argument). The issue is what the current installed base of MTAs actually _does_ (rightly or wrongly). Note that we are now proposing to apply this relaxation to four new message types: message/global message/global-delivery-status message/global-headers message/global-disposition-notification of which problems with the third could be avoided by using text/global-headers instead. I understand that the consensus is against me on this issue, and I am therefore not asking that it be reopened at this stage. However, I repeat what I have already stated before, that I intend to raise it at IESG Last Call. Note that I have written separate EDITORIAL comments on the utf8 and dsn drafts. -- 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 Sep 19 18:21:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY7uS-0000Ju-Ro; Wed, 19 Sep 2007 18:20:40 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IY7uR-0000J1-Hh for ima-confirm+ok@megatron.ietf.org; Wed, 19 Sep 2007 18:20:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY7uR-0000Gh-7T for ima@ietf.org; Wed, 19 Sep 2007 18:20:39 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY7uD-0000Ic-GA for ima@ietf.org; Wed, 19 Sep 2007 18:20:33 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3$clerew*man$ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.254) id 46f1a089.18060.2 for ima@ietf.org; Wed, 19 Sep 2007 23:19:53 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8JMJogL019893 for ; Wed, 19 Sep 2007 23:19:51 +0100 (BST) Date: Wed, 19 Sep 2007 23:19:49 +0100 To: ima@ietf.org From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [EAI] EDITORIAL: dsn X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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 DSN draft is still using the term "UTF8SMTP message" (in at least two places). I think it shold now be "global message". 4. UTF-8 Delivery Status Notifications .... As the present DSN format does not permit returning of undeliverable UTF8SMTP message, three new media types are needed. ^^^^^^^ messages The third type, used for header return, is message/global-headers and contains only the UTF-8 headers of a message (all lines prior to the first blank line in a UTF8SMTP message). Unlike message/global, this body part provides no difficulties for present infrastructure. On the contrary, it provides precisely the same difficulties :-( . 4.1. Additional requirements on SMTP servers If an SMTP server which advertises both UTF8SMTP and DSN needs to return an undeliverable UTF8SMTP message, then it MUST NOT downgrade [I-D.ietf-eai-downgrade] the UTF8SMTP message when generating the corresponding multipart/report. If the return path SMTP server does not support UTF8SMTP, then the undeliverable body part and headers MUST be encoded using a 7 bit Content-Transfer-Encoding such as base64 or quoted-printable [RFC2045], as detailed in Section 4. Otherwise 8bit Content-Transfer-Encoding can be used. Why do you want to forbid downgrade here? The UTF-8 draft explicitly allows downgrade as an alternative to re-encoding in Q-P or Base64, so why be different? -- 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 Sep 20 05:42:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYIX6-0002z0-8H; Thu, 20 Sep 2007 05:41:16 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYIX5-0002ys-7M for ima-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 05:41:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYIX4-0002yP-In for ima@ietf.org; Thu, 20 Sep 2007 05:41:14 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYIX2-0007hQ-Nf for ima@ietf.org; Thu, 20 Sep 2007 05:41:14 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 20 Sep 2007 10:41:08 +0100 Message-ID: <46F1A0A4.6020305@isode.com> Date: Wed, 19 Sep 2007 23:20:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ima@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Subject: [EAI] EDITORIAL: draft-ietf-eai-utf8headers-07.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 Hi, I fully support publication of this document. Some editorial comments/suggestions are below: Abstract Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected ..., but also a capability to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. 1.2. Relation to other standards Allowing of use a content-transfer-encoding on subtypes of messages is not limited to transmissions, which are authorized by the SMTP extension specified in [EAI-SMTP-extension]. I am not sure what this sentence is trying to say. Is it saying something like the following: Transmissions of subtypes of the "message" MIME type containing content-transfer-encoding are authorized by the SMTP extension specified in [EAI-SMTP-extension]. ? 4.2. Changes on MIME headers Changes *to* MIME headers [...] To be able to use UTF-8 characters in MIME header field paramerer typo: parameter values, the syntax of , as defined in [RFC2045], is extended as 4.3. Syntax extensions to RFC 2822 [...] To able to use UTF-8 on Content-Description header field on To be able to use UTF-8 in Content-Description header field defined in [RFC2045], following syntax is used I think "the" is missing before "following". syntax is extended on next chapter to allow UTF-8 characters *in* the next chapter on header fields. *in* 4.4. Change on addr-spec syntax Internationalized email addresses are represented in UTF-8. Thus, all header fields containing es are updated to permit UTF-8 as well as an additional, optional all-ascii alternate address. all-ASCII *alternative* address Below list a few possible representation as example. Replace the whole sentence with "A few possible examples are listed below". 4.5. Trace field syntax [...] The "Return-Path" header provides the email return address in the mail delivery. Thus, it MUST able to carry UTF8 addresses (see the revised syntax of in Section 4.4 of this document). This will not break the rule of trace fied integrity, because it is typo: field added at the last MTA. on "Received:" syntax is augmented to allow UTF-8 email *in* "Received:" header field syntax address on "For" clause. is augmented to include UTF-8 address *in* "For" clause. email address on previous chapter. To allow UTF-8 email address also email address *in the* previous chapter. on syntax corresponding of on original syntax, is added to . 4.6. message/global Internationalized messages, also called UTF8SMTP messages, must only be transmitted as authorized by [EAI-SMTP-extension] or within a non- SMTP environment which supports these messages. A message is a "message/global message", if The previous version said "A message is a UTF8SMTP message". I think the old text is more correct. (A message is message/global if it it has "message/global" MIME type) o it contains UTF-8 header values as specified in this document, or o it contains UTF-8 values in the headers fields of body parts. The second type, used for content return, is message/global which is similar to message/rfc822, except it contains a message with UTF-8 headers. I would change this sentence to read (This document only defines one MIME type): message/global is similar to message/rfc822, except that it contains a message with UTF-8 headers. 10.2. Informative References [...] [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. This reference is normative, so it should be moved to section 10.1 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. This reference is no longer used, it should be deleted. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 20 09:11:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYLo6-0001df-8z; Thu, 20 Sep 2007 09:11:02 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYLo5-0001cy-2s for ima-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 09:11:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYLo4-0001Ol-Ks for ima@ietf.org; Thu, 20 Sep 2007 09:11:00 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYLnm-00065A-Pe for ima@ietf.org; Thu, 20 Sep 2007 09:10:43 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3^clerew$man^ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.254) id 46f27149.b8e.3b3 for ima@ietf.org; Thu, 20 Sep 2007 14:10:33 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8KDAUjb029419 for ; Thu, 20 Sep 2007 14:10:31 +0100 (BST) To: IMA Subject: Re: [EAI] EDITORIAL: draft-ietf-eai-utf8headers-07.txt References: <46F1A0A4.6020305@isode.com> Message-ID: Date: Thu, 20 Sep 2007 14:10:29 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <46F1A0A4.6020305@isode.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Wed, 19 Sep 2007 23:20:20 +0100, Alexey Melnikov wrote: > 1.2. Relation to other standards > > Allowing of use a content-transfer-encoding on subtypes of messages > is not limited to transmissions, which are authorized by the SMTP > extension specified in [EAI-SMTP-extension]. > > I am not sure what this sentence is trying to say. Is it saying > something like the following: > > Transmissions of subtypes of the "message" MIME type containing > content-transfer-encoding > are authorized by the SMTP extension specified in > [EAI-SMTP-extension]. > I think it is trying to say that some message types are now allowed to use encodings other than 7bit, 8bit and binary (i.e. Q-P and Base64), but I do not see where EAI-SMTP-extension] comes into it. Agreed it needs clarification. > ? > 4.6. message/global > > Internationalized messages, also called UTF8SMTP messages, must only > be transmitted as authorized by [EAI-SMTP-extension] or within a non- > SMTP environment which supports these messages. A message is a > "message/global message", if > > The previous version said "A message is a UTF8SMTP message". I think the > old text is more correct. > (A message is message/global if it it has "message/global" MIME type) Yes, see my own editorial comments on this bit. I think s/UTF8SMTP message/global message/ throughout the documents will accord well with our decision to use message/global as the MIME type for them. But to speak of "message/global messages" seems an overkill. -- 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 Sep 20 13:22:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPis-0005hw-5x; Thu, 20 Sep 2007 13:21:54 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYPiq-0005ho-Pw for ima-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 13:21:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPiq-0005hb-BU for ima@ietf.org; Thu, 20 Sep 2007 13:21:52 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYPip-0005wO-If for ima@ietf.org; Thu, 20 Sep 2007 13:21:52 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 20 Sep 2007 18:21:49 +0100 Message-ID: <46F2AC4A.7090605@isode.com> Date: Thu, 20 Sep 2007 18:22:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Charles Lindsey Subject: Re: [EAI] EDITORIAL: dsn References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > The DSN draft is still using the term "UTF8SMTP message" (in at least > two places). I think it shold now be "global message". UTF8SMTP is referencing the SMTP extension name, so I don't think this is particularly confusing. I personally find "global message" to be more confusing (unlike message/global). > 4. UTF-8 Delivery Status Notifications > > .... As the present DSN format does not permit returning of > undeliverable UTF8SMTP message, three new media types are needed. > ^^^^^^^ > messages Changed, thanks. > The third type, used for header return, is message/global-headers and > contains only the UTF-8 headers of a message (all lines prior to the > first blank line in a UTF8SMTP message). Unlike message/global, this > body part provides no difficulties for present infrastructure. > > On the contrary, it provides precisely the same difficulties :-( . I think we need an interop event to prove one way or another. I can delete the second sentence, if people prefer. > 4.1. Additional requirements on SMTP servers > > If an SMTP server which advertises both UTF8SMTP and DSN needs to > return an undeliverable UTF8SMTP message, then it MUST NOT downgrade > [I-D.ietf-eai-downgrade] the UTF8SMTP message when generating the > corresponding multipart/report. If the return path SMTP server does > not support UTF8SMTP, then the undeliverable body part and headers > MUST be encoded using a 7 bit Content-Transfer-Encoding such as > base64 or quoted-printable [RFC2045], as detailed in Section 4. > Otherwise 8bit Content-Transfer-Encoding can be used. > > Why do you want to forbid downgrade here? The UTF-8 draft explicitly > allows downgrade as an alternative to re-encoding in Q-P or Base64, so > why be different? I've already commented on UTF-8 headers draft, saying that it is in conflict with EAI DSN. The issue was discussed in Chicago: basically use of C-T-E is safer then downgrade, because downgrade is not always possible. It is better to change C-T-E, then to lose the bounce message because it can't be converted. Another argument for using C-T-E conversion is that servers can already do that (or can be made capable of doing that using some minor code changes) and they don't need to implement downgrade just for processing of DSN reports. Regards, Alexey _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 20 14:12:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYQVN-0005UR-2I; Thu, 20 Sep 2007 14:12:01 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYQVM-0005TB-H3 for ima-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 14:12:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYQVM-0005T3-51 for ima@ietf.org; Thu, 20 Sep 2007 14:12:00 -0400 Received: from ns1.qubic.net ([208.185.248.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYQVL-0007YG-JZ for ima@ietf.org; Thu, 20 Sep 2007 14:11:59 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Alpha0/8.14.2.Alpha0) with ESMTP id l8KIBOUm021039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Sep 2007 11:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1190311904; x=1190398304; bh=gmC9vgz6l/qbm0PxqtEsWwZ0dLQWoa8kw7WF CkaU+UM=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:Mime-Version:Content-Type:Cc; b=pjZUcW08MnL8u+eh2PcHAD1i3L B3EXQLS7GPPRj/M4EPSmWmXP3CwbfWxSHvhuF2nnOfQBO9u95/50WeQ5iSY1mfKzbbN +S9iNyApwM4sTQ3jJCwev5hr580zSc1H8A+4vt02aEe9sHy96N1ZTmfr6Ez4QFH3aJ/ FhJO4X/u5bU= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=2xdUBTrFOOE+6JiQLhVf5fvsHjFcCihFoU5arNzYMOZB1BlYDNaAEnYnXWNHipDnO haLVBtHFBQCJPeyAx9defDdNEWDoZQrXMIIlxf3fsx1zlyIJ66DLiAOH6ZwWkf4gB/6 DtiDiWqNnFT9X3W1179dWJvvjRxb0s7YbM9GHEo= Message-Id: <6.2.5.6.2.20070920103926.02f336c0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 20 Sep 2007 10:59:54 -0700 To: ima@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [EAI] ISSUE: draft-ietf-eai-utf8headers-07 - message/ subtypes X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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, Section 1.2 of draft-ietf-eai-utf8headers-07 mentions: "This document updates section 6.4 of RFC 2045. It removes the blanket ban on applying a content-transfer-encoding to all subtypes of message/, and instead specifies that a composite subtype MAY specify whether or not a content-transfer-encoding can be used for that subtype, with "cannot be used" as the default" This draft is applicable to SMTP whereas some of the message/ subtypes may be used by other mechanisms. Is there a reason why the removal should apply to other transport mechanisms? Regards, -sm _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 20 14:33:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYQpH-0003YH-TS; Thu, 20 Sep 2007 14:32:35 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYQpF-0003WB-Vy for ima-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 14:32:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYQpF-0003W3-JF for ima@ietf.org; Thu, 20 Sep 2007 14:32:33 -0400 Received: from ns1.qubic.net ([208.185.248.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYQpE-0008Ez-Ur for ima@ietf.org; Thu, 20 Sep 2007 14:32:33 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Alpha0/8.14.2.Alpha0) with ESMTP id l8KIW5DP029278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Sep 2007 11:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1190313139; x=1190399539; bh=lSxOrmOigK4aKtsm6PWxAaef6aWe0j1lAY+M e482CjY=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:Mime-Version:Content-Type:Cc; b=i+JoWIB/ZCsW6ds5x48vJi5me3 Hvji6SNiY+E5cYMNIO+s1LtDeGNgb+SMRIQL5LEIEcwbbsVOzNgkLv5zC7zP7y1QHx2 hECH5+C6DJa2vQRBIcw0zlPF0OVrZy8rTRrJu6RQdyI9rBY+JaqADiZFwc7Shh8lrZZ S2mMa9wFcRw= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=dnnwCfdxWnYcXFCAaet8cdQJlT5neRvWWtPksWeBo3LLvse+viGwZDRM1i+4Fe6J0 mUSsXPKy/eMv/0vFc4Egi9pqPkx5E69Ar34jUuA3qpo6omj7W4FghGuSMp/y3vCJ4kg SpwruJ/cEYLE54wGupG/0CgQ1T97e+mgE1pELYw= Message-Id: <6.2.5.6.2.20070920111954.02ec47b0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 20 Sep 2007 11:29:03 -0700 To: ima@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [EAI] ISSUE: draft-ietf-eai-utf8headers-07 - nested encoding X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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, In Section 4.2, it is mentioned that double encoding might happen in practice. Quoting Section 6.4 of RFC 2045: "NOTE ON ENCODING RESTRICTIONS: Though the prohibition against using content-transfer-encodings on composite body data may seem overly restrictive, it is necessary to prevent nested encodings, in which data are passed through an encoding algorithm multiple times, and must be decoded multiple times in order to be properly viewed. Nested encodings add considerable complexity to user agents: Aside from the obvious efficiency problems with such multiple encodings, they can obscure the basic structure of a message. In particular, they can imply that several decoding operations are necessary simply to find out what types of bodies a message contains. Banning nested encodings may complicate the job of certain mail gateways, but this seems less of a problem than the effect of nested encodings on user agents. It may be more efficient implementation-wise to prohibit double encoding to avoid several decoding operations. The paragraph also mentions several other reasons for having such a restriction. Regards, -sm _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 20 14:58:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYREE-0008UX-AS; Thu, 20 Sep 2007 14:58:22 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYREC-0008TV-KD for ima-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 14:58:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYREC-0008TM-8J for ima@ietf.org; Thu, 20 Sep 2007 14:58:20 -0400 Received: from ns1.qubic.net ([208.185.248.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYREB-0001Bp-Ne for ima@ietf.org; Thu, 20 Sep 2007 14:58:19 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Alpha0/8.14.2.Alpha0) with ESMTP id l8KIvnpl023422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Sep 2007 11:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1190314686; x=1190401086; bh=FBlnNCuDHC6utinsxkjk1/M3cf1UuxPc+Gbl KK3NFcI=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:Mime-Version:Content-Type:Cc; b=m7JkK4buEqhCufsDYkFWWD2Vmk kM5UijOabM4iR2xxDHx3wirB9op9CwMnoX8LlDHCWHyZGhqgBua3lI5uhgSydoZM3tp vR30N2qBiafGJTBfDEnq55oTsrYbNdWSzh7IOsWESAX9jrvQ/kCUupiNk6ePuU/u0QF IU9ndhSdpFs= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=a6MGLS2nM0RM1he6zYYCtZjYlg4g/Fv9FRqjwU+bKvQsH6GwgAM6Jv9/CaK+74IeZ vXRe5mlXYyP5PJSOIDqGUsH6d6kk6W4dIS4MmObg4IiTZOaekXlTyu2RQf+ceraQ13h I7aN6rELOsvEsg3WYLtYHwG5azopAxfC6GZxPk0= Message-Id: <6.2.5.6.2.20070920115650.02f40c28@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 20 Sep 2007 11:56:55 -0700 To: ima@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [EAI] ISSUE: draft-ietf-eai-utf8headers-07 - Content-Description X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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, Section 4.3 provides for UTF-8 being allowed in "Content-Description" header fields. Does that mean that a "Content-Description" header for an image/ type, for example, found within a multipart/ can have UTF-8 text? Regards, -sm _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 21 06:25:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYffu-0005lv-8u; Fri, 21 Sep 2007 06:23:54 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYfft-0005lq-Hy for ima-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 06:23:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYfft-0005TF-3w for ima@ietf.org; Fri, 21 Sep 2007 06:23:53 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYffX-0006ZA-Vw for ima@ietf.org; Fri, 21 Sep 2007 06:23:32 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3$clerew&man^ac*uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.254) id 46f39ba1.8d2f.34 for ima@ietf.org; Fri, 21 Sep 2007 11:23:29 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8LANPgB007220 for ; Fri, 21 Sep 2007 11:23:26 +0100 (BST) To: IMA Subject: Re: [EAI] EDITORIAL: dsn References: <46F2AC4A.7090605@isode.com> Message-ID: Date: Fri, 21 Sep 2007 11:23:24 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <46F2AC4A.7090605@isode.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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, 20 Sep 2007 18:22:18 +0100, Alexey Melnikov wrote: > Charles Lindsey wrote: >> Why do you want to forbid downgrade here? The UTF-8 draft explicitly >> allows downgrade as an alternative to re-encoding in Q-P or Base64, so >> why be different? > > I've already commented on UTF-8 headers draft, saying that it is in > conflict with EAI DSN. > > The issue was discussed in Chicago: basically use of C-T-E is safer then > downgrade, because downgrade is not always possible. It is better to > change C-T-E, then to lose the bounce message because it can't be > converted. > Another argument for using C-T-E conversion is that servers can already > do that ..... I have repeatedly asked for a single example of a server that can already do that, and no example has been forthcoming (whereas we know of several servers that currently cannot do it). That is the whole basis of the ISSUE that I have raised. > ...(or can be made capable of doing that using some minor code changes) > ... The whole basis of our endeavour is that only those agents that want to take advantage of our new "global"/"UTF8SNTP" message need to have their implementations changed. Now you are suggesting that all existing MTAs will need to be upgraded (which just ain't going to happen, however minor the code changes involved). > ... and they don't need to implement downgrade just for processing of > DSN reports. The downgrade option would be used by a UTF8SMTP-capable agent (such as the one generating the DSN) when it saw that it was being asked to send the DSN to a Non-UTF8SMTP agent. If it decided not to do that (it is currently just an option in utf8headers), then a subsequent Non-UTF8SMTP would (hopefully) encode it in Q-P or Base64 before giving it to a Non-8BITMIME agent. Evidently, your degree of Hopefulness is greater than mine :-) . -- 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 Sep 21 06:27:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYfjI-0000YU-7Q; Fri, 21 Sep 2007 06:27:24 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYfjG-0000W7-SY for ima-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 06:27:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYfjG-0000Vz-Gu for ima@ietf.org; Fri, 21 Sep 2007 06:27:22 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYfjF-0006gr-To for ima@ietf.org; Fri, 21 Sep 2007 06:27:22 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3*clerew^man$ac#uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.254) id 46f39c89.8d2f.40 for ima@ietf.org; Fri, 21 Sep 2007 11:27:21 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8LARHIA007454 for ; Fri, 21 Sep 2007 11:27:18 +0100 (BST) To: IMA Subject: Re: [EAI] ISSUE: draft-ietf-eai-utf8headers-07 - Content-Description References: <6.2.5.6.2.20070920115650.02f40c28@elandnews.com> Message-ID: Date: Fri, 21 Sep 2007 11:27:16 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <6.2.5.6.2.20070920115650.02f40c28@elandnews.com> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Thu, 20 Sep 2007 19:56:55 +0100, SM wrote: > Hello, > > Section 4.3 provides for UTF-8 being allowed in "Content-Description" > header fields. Does that mean that a "Content-Description" header for > an image/ type, for example, found within a multipart/ can have UTF-8 > text? Yes, that was the intention. The body of a Content-Description is , so it can easily be downgraded using RFC 2047. It would clearly be useful for an image being sent from one Chinese speaker to another to have the Content-Description describing the image written in Chinese. -- 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 Sep 21 07:10:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYgON-0003Vv-9v; Fri, 21 Sep 2007 07:09:51 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYgOM-0003V1-DZ for ima-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 07:09:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYgOM-0003Qu-0D for ima@ietf.org; Fri, 21 Sep 2007 07:09:50 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYgOL-0007fg-B1 for ima@ietf.org; Fri, 21 Sep 2007 07:09:49 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 21 Sep 2007 12:09:46 +0100 Message-ID: <46F3A69D.1080803@isode.com> Date: Fri, 21 Sep 2007 12:10:21 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Charles Lindsey Subject: Re: [EAI] EDITORIAL: dsn References: <46F2AC4A.7090605@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Thu, 20 Sep 2007 18:22:18 +0100, Alexey Melnikov > wrote: > >> Charles Lindsey wrote: > >>> Why do you want to forbid downgrade here? The UTF-8 draft >>> explicitly allows downgrade as an alternative to re-encoding in >>> Q-P or Base64, so why be different? >> >> I've already commented on UTF-8 headers draft, saying that it is in >> conflict with EAI DSN. >> >> The issue was discussed in Chicago: basically use of C-T-E is safer >> then downgrade, because downgrade is not always possible. It is >> better to change C-T-E, then to lose the bounce message because it >> can't be converted. >> Another argument for using C-T-E conversion is that servers can >> already do that ..... > > I have repeatedly asked for a single example of a server that can > already do that, and no example has been forthcoming (whereas we know > of several servers that currently cannot do it). That is the whole > basis of the ISSUE that I have raised. I believe Isode pp can do that. But I haven't tested this yet ;-). _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 21 12:54:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYll3-0008Dg-9o; Fri, 21 Sep 2007 12:53:37 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYll2-0008DS-1u for ima-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 12:53:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYll1-0008Av-Jr for ima@ietf.org; Fri, 21 Sep 2007 12:53:35 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYll1-0002EQ-2E for ima@ietf.org; Fri, 21 Sep 2007 12:53:35 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 25260259742; Fri, 21 Sep 2007 18:53:34 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01755-05; Fri, 21 Sep 2007 18:53:28 +0200 (CEST) Received: from [192.168.1.119] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id A5CE625973E; Fri, 21 Sep 2007 18:53:28 +0200 (CEST) Date: Fri, 21 Sep 2007 18:51:36 +0200 From: Harald Tveit Alvestrand To: SM , ima@ietf.org Subject: Re: [EAI] ISSUE: draft-ietf-eai-utf8headers-07 - message/ subtypes Message-ID: In-Reply-To: <6.2.5.6.2.20070920103926.02f336c0@elandnews.com> References: <6.2.5.6.2.20070920103926.02f336c0@elandnews.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.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 20. september 2007 10:59 -0700 SM wrote: > Hello, > > Section 1.2 of draft-ietf-eai-utf8headers-07 mentions: > > "This document updates section 6.4 of RFC 2045. It removes the > blanket ban on applying a content-transfer-encoding to all subtypes > of message/, and instead specifies that a composite subtype MAY > specify whether or not a content-transfer-encoding can be used for > that subtype, with "cannot be used" as the default" > > This draft is applicable to SMTP whereas some of the message/ subtypes > may be used by other mechanisms. Is there a reason why the removal > should apply to other transport mechanisms? Yes. Having different restrictions on a subtype depending on the transport mechanism will make moving MIME objects between different transports very difficult. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 21 14:35:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYnLN-0000Ar-Oc; Fri, 21 Sep 2007 14:35:13 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYnLN-0000Ag-54 for ima-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 14:35:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYnLM-0008RN-Re for ima@ietf.org; Fri, 21 Sep 2007 14:35:12 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYnL8-0002Gl-Rl for ima@ietf.org; Fri, 21 Sep 2007 14:35:03 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 761CD2FA; Fri, 21 Sep 2007 14:34:50 -0400 (EDT) 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 23277814BD; Fri, 21 Sep 2007 14:34:49 -0400 (EDT) Date: Fri, 21 Sep 2007 11:34:25 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1894950817.20070921113425@pobox.com> To: IMA Discussion 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] ISSUE - draft-ietf-eai-utf8headers-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This discussion of how to handle Content-Transfer-Encoding for composite types leads me to consider that what we probably should be proposing instead is a *new* MIME header field: Content-Header-Encoding which only is meaningful for composite types and only affects the HEADER of a message/* or the PART-HEADERS of a multipart/*. This avoids the "double encoding" problem and also preserves MIME structure visibility. (We might need to warn about the problem of specifying a non-ASCII multipart separator string to a non-EAI-aware program.) Since any relaxation of the "blanket ban" of Content-Transfer-Encoding for composite types would probably require *some* updating of code in EAI-aware programs, the addition of a Content-Header-Encoding field should be of similar effort and would narrow this solution to only the portion of the data where it is needed. Sorry if I have missed a discussion of this possibility previously in this group. -- Bill McQuillan _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 21 16:52:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYpTc-00086m-Ld; Fri, 21 Sep 2007 16:51:52 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYpTb-00085v-Ij for ima-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 16:51:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYpTb-00085E-8P for ima@ietf.org; Fri, 21 Sep 2007 16:51:51 -0400 Received: from ns1.qubic.net ([208.185.248.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYpTU-0006VH-VZ for ima@ietf.org; Fri, 21 Sep 2007 16:51:51 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Alpha0/8.14.2.Alpha0) with ESMTP id l8LKp4C4025909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Sep 2007 13:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1190407881; x=1190494281; bh=MFz037WRo+4W7/U6AuMj/jqoR3iz7Mt9Rn3d oZCDVEM=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:In-Reply-To:References:Mime-Version:Content-Type:Cc; b=x/w GGmXbTEAQN41ilpPxBVoFMh8h+Gez+UJU2j2XsC3J1yEf2yQDH7VZ2WaHgCOOgLz9f9 TCjTHJbzPpIWJuw9rdNmNp1c20mhGX3N6P+9wpRsGyxBna2ZLPV5BEmFaUnRIgVIEKX nB2jeEbbue0FhFolYnokRBp4gwZFkQndnQ= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=yM4AvAUtGd6vdP8Ydey6RaGfuckZq+RldNzLZCknFwUk2oKdtG5n+34GyDMyYiD8Y F6fRyFMVoimrdktCR00IJs3XE8Eile7N7XwscmvYHc7CYCf0pqqGNaCTx9o30jIARl3 P2aRLKDZF+mhZ9jLbR0cQz7BEapP116CYpBEDaQ= Message-Id: <6.2.5.6.2.20070921133017.02d16c18@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 21 Sep 2007 13:35:36 -0700 To: IMA From: SM Subject: Re: [EAI] ISSUE: draft-ietf-eai-utf8headers-07 - Content-Description In-Reply-To: References: <6.2.5.6.2.20070920115650.02f40c28@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Hi Charles, At 03:27 21-09-2007, Charles Lindsey wrote: >Yes, that was the intention. The body of a Content-Description is >, so it can easily be downgraded using RFC 2047. Thanks for the explanation. Regards, -sm _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 21 17:07:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYpiM-0003ch-E0; Fri, 21 Sep 2007 17:07:06 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYpiL-0003YJ-D5 for ima-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 17:07:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYpiK-0003XN-SV for ima@ietf.org; Fri, 21 Sep 2007 17:07:04 -0400 Received: from ns1.qubic.net ([208.185.248.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYpiK-0002cZ-Ba for ima@ietf.org; Fri, 21 Sep 2007 17:07:04 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Alpha0/8.14.2.Alpha0) with ESMTP id l8LL6XLL008751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Sep 2007 14:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1190408810; x=1190495210; bh=1DiiJONPrLHxw12MWE6mj9Y8Fih0lVhPFw1H VPy7sZg=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:In-Reply-To:References:Mime-Version:Content-Type:Cc; b=J/v /1l47Q2o9AgRV4ECK7Pk95o4TGXU4PzYNN77KqiFU87E71wvTAMSwN3EBMLmz1Sia6G Ex17uUdMIIyYKBqbBfKJVY5SBRL/H/2e+Nq/xDoWUn03IlfRnVmc0nPo5Napk/enwVq KPehClJQS7v6pPKsoR19Ybbca9kF4i5gzY= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=ZAUtWBqVRQ4RwiQ26kGfQHlDnj2+Yq/kGIi5NcBVjlJZlftZfqSRaeTBfiUuYOnvd 9kwCeM7vwh8CCn8abVxejyuCybT6X+j6Z87HUxF5wsEqlyGXHqPMazsiIuhG22Pcxl4 ovV7/ROeD83UTezzbCT5uQOlGFt4+sRK/rUp84I= Message-Id: <6.2.5.6.2.20070921140038.02f3cdb8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 21 Sep 2007 14:04:49 -0700 To: ima@ietf.org From: SM Subject: Re: [EAI] ISSUE: draft-ietf-eai-utf8headers-07 - message/ subtypes In-Reply-To: References: <6.2.5.6.2.20070920103926.02f336c0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Hi Harald, At 09:51 21-09-2007, Harald Tveit Alvestrand wrote: >Yes. Having different restrictions on a subtype depending on the >transport mechanism will make moving MIME objects between different >transports very difficult. That sounds sensible. Regards, -sm _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 21 17:27:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYq1j-0002Lj-6s; Fri, 21 Sep 2007 17:27:07 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYq1i-0002LU-H8 for ima-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 17:27:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYq1i-0002KT-7B for ima@ietf.org; Fri, 21 Sep 2007 17:27:06 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYq1h-0007h6-0C for ima@ietf.org; Fri, 21 Sep 2007 17:27:06 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IYq1g-000Fb3-Lz for ima@ietf.org; Fri, 21 Sep 2007 17:27:04 -0400 Date: Fri, 21 Sep 2007 17:27:04 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <966730A3104AC560EA230C43@p3.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [EAI] EDITORIAL: smtpext sections X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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. In recent months, I have read the smtpext document for technical content, ignoring editorial issues. After reading it carefully as part of the WG Last Call, and independent of editorial nit-picking, I believe that (1) Section 3.1 (POP and IMAP) should be dropped. This is covered in Framework (RFC 4952 here and below). The text in this document adds nothing and is confusing about document scope. (2) Section 4 (Potential problems) should be dropped. This is covered in Framework. If it is not adequate there, we should revise Framework, not try to insert these types of comment in this document, where it appears to be out of scope. (3) While I am less convinced about this that about the above two, I also believe that Sections 3.1 (LMTP) and 3.2 (DSNs) should be dropped, hence removing all of Section 3. The section doesn't fit naturally here; if it is necessary and not adequately covered in Framework, we should either replace Framework or move this material to an appendix to this document that is explicitly indicated as Updating RFC 4952. I hope the WG concurs with these unfortunately late organizational suggestions. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 21 17:29:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYq3W-000363-Kh; Fri, 21 Sep 2007 17:28:58 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYq3U-00032w-VA for ima-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 17:28:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYq3U-00032o-Li for ima@ietf.org; Fri, 21 Sep 2007 17:28:56 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYq3T-0007jC-FY for ima@ietf.org; Fri, 21 Sep 2007 17:28:56 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IYq3T-000FdZ-7C for ima@ietf.org; Fri, 21 Sep 2007 17:28:55 -0400 Date: Fri, 21 Sep 2007 17:28:54 -0400 From: John C Klensin To: ima@ietf.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [EAI] SUPPORT: draft-ietf-eai-smtpext-08, ...utf8-headers, ...dsn X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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. Sorry I've been mostly out of circulation for the last two weeks (for reasons unrelated to EAI). I have reviewed and support publication of the substance of all three of these documents as Experimental. While I have some quibbles, I believe that they, and the protocol principles involved, are good enough for Experimental documents and that the advantages of significant further tuning are significantly outweighed by the time it would take. That said, the documents need some editorial work. I'll transcribe aand forward notes on all three soon although probably not until Sunday. There is one editorial issue in "smtpext" that I just sent out in a separate note. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 21 17:31:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYq5q-00066M-Cx; Fri, 21 Sep 2007 17:31:22 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYq5p-000665-LY for ima-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 17:31:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYq5p-00064o-7j for ima@ietf.org; Fri, 21 Sep 2007 17:31:21 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYq5o-00038q-GL for ima@ietf.org; Fri, 21 Sep 2007 17:31:20 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IYq5n-000FgH-O5; Fri, 21 Sep 2007 17:31:20 -0400 Date: Fri, 21 Sep 2007 17:31:18 -0400 From: John C Klensin To: Charles Lindsey , IMA Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt Message-ID: In-Reply-To: References: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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, 19 September, 2007 20:35 +0100 Charles Lindsey wrote: > On Fri, 14 Sep 2007 18:07:57 +0100, John C Klensin > wrote: > >> --On Friday, 14 September, 2007 12:23 +0200 Harald Alvestrand >> wrote: >> >> It feels to me as if this may be another section of the >> hypothetical "recommendations to implementers and for >> configuration" doc, which I hope someone is planning to write. >> Consider that, in the general case, the SMTP server cannot >> have any idea how the user will pick up the mail since a >> given user may use POP on even-numbered days, IMAP on odd >> ones, and something else entirely in any month in which there >> are five Fridays. The 821/2821 requirement that a server >> either deliver the mail or not, i.e., that it not deliver and >> report an error further constrains the situation. >> >> So, in the example you give, if the POP server is to be >> supported, the SMTP server would need to return a positive >> response in all cases. I think that would leave it in a major >> tangle if it did not support some sort of post-SMTP-delivery >> downgrading, but that isn't a topic for the smptext document. > > But surely this is just the distinction between 'Reject' and > 'Bounce' that we have discussed before. If an MTA returns a > 2xx response, then the most it is claiming is "I think I know > what to do with this message, so I am accepting (allowing you > to send) it; but the next man in line might think otherwise, > in which case I promise to send a bounce (DSN) up the Return > Path". Yes. > That can apply whether the "next man" is the next hop to > another MTA, or whether it is some complex situation in the > local storage/delivery/forwarding system. So I see no reason > why the (supposedly final) MTA cannot accept the message, but > later bounce it because it subsequently transpires that there > are the wrong number of Fridays in this particular month. Just > so long as it does not lose it without trace. I think we agree, so am no longer sure what the issue is here. A problem would arise iff someone or something required that the delivery MTA _reject_ (not bounce/ generate an NDN) message if it could not deliver an i18n email message all the way to the POP client. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 21 17:38:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYqCd-0005Cv-Jd; Fri, 21 Sep 2007 17:38:23 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IYqCc-0005CU-D1 for ima-confirm+ok@megatron.ietf.org; Fri, 21 Sep 2007 17:38:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYqCc-0005CM-1G for ima@ietf.org; Fri, 21 Sep 2007 17:38:22 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYqCb-0003Io-EJ for ima@ietf.org; Fri, 21 Sep 2007 17:38:21 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IYqCb-000FrY-2k; Fri, 21 Sep 2007 17:38:21 -0400 Date: Fri, 21 Sep 2007 17:38:20 -0400 From: John C Klensin To: Alexey Melnikov , ima@ietf.org Subject: Re: [EAI] EDITORIAL: draft-ietf-eai-smtpext-08.txt Message-ID: <545C05C2356954E62D1A5D7E@p3.JCK.COM> In-Reply-To: <46F0F23A.9060601@isode.com> References: <46F0F23A.9060601@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Wednesday, 19 September, 2007 10:56 +0100 Alexey Melnikov wrote: > 2. Reject the message during the SMTP transaction or > generate a > notification of non-deliverability, as specified in RFC > 2821 > [RFC2821] and RFC 3464 [RFC3464]. If the message > content can be > returned without alteration, content should be returned > as > specified in 2821 but, if a server is encountered along > the > return path that cannot accept UTF8SMTP traffic, the > content > should simply be abridged or dropped. > > The last sentence is trying to redefine something already > specified in [EAI-dsn]. I think it contradicts [EAI-dsn]. > Suggestion to replace the last sentence with a pointer to > [EAI-dsn] IMO, this suggestion does not go far enough. The correct fix, IMO, is to replace this paragraph with 2. Reject the message during the SMTP transaction or generate a notification of non-deliverability, as specified in RFC 2821 [RFC2821], RFC 3464 [RFC3464], and [EAI-dsn]. If any of the other material in that paragraph is not adequately specified in the DSN document, that should be fixed. And I agree that the references to EAI-DSN and to RFC 4409 are normative. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Sep 23 10:26:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZSOR-0005ML-Vp; Sun, 23 Sep 2007 10:25:07 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZSOQ-0005Ja-DR for ima-confirm+ok@megatron.ietf.org; Sun, 23 Sep 2007 10:25:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZSOQ-0005JS-3t for ima@ietf.org; Sun, 23 Sep 2007 10:25:06 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZSOL-0008MB-HC for ima@ietf.org; Sun, 23 Sep 2007 10:25:06 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2007 15:25:00 +0100 Message-ID: <46F6775F.6060805@isode.com> Date: Sun, 23 Sep 2007 15:25:35 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: John C Klensin Subject: Re: [EAI] EDITORIAL: smtpext sections References: <966730A3104AC560EA230C43@p3.JCK.COM> In-Reply-To: <966730A3104AC560EA230C43@p3.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: >Hi. > >In recent months, I have read the smtpext document for technical >content, ignoring editorial issues. > >After reading it carefully as part of the WG Last Call, and >independent of editorial nit-picking, I believe that > > (1) Section 3.1 (POP and IMAP) should be dropped. This > is covered in Framework (RFC 4952 here and below). The > text in this document adds nothing and is confusing > about document scope. > > Agree. > (2) Section 4 (Potential problems) should be dropped. > This is covered in Framework. If it is not adequate > there, we should revise Framework, not try to insert > these types of comment in this document, where it > appears to be out of scope. > > Agree. > (3) While I am less convinced about this that about the > above two, I also believe that Sections 3.1 (LMTP) and > 3.2 (DSNs) should be dropped, hence removing all of > Section 3. > I frankly don't understand why we have section 3.1 (LMTP). I thought I line sentence saying that this extension is also applicable to LMTP would be much better. I disagree about removed of section 3.2 (DSN). The requirement that a system that implements both UTF8SMTP and DSN extensions must also implement EAI-dsn is important. However I have no problems with moving this text within the document. >The section doesn't fit naturally here; if > it is necessary and not adequately covered in Framework, > we should either replace Framework or move this material > to an appendix to this document that is explicitly > indicated as Updating RFC 4952. > >I hope the WG concurs with these unfortunately late >organizational suggestions. > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sun Sep 23 10:31:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZSUZ-0003mh-Fq; Sun, 23 Sep 2007 10:31:27 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZSUY-0003fk-54 for ima-confirm+ok@megatron.ietf.org; Sun, 23 Sep 2007 10:31:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZSUX-0003fb-PM for ima@ietf.org; Sun, 23 Sep 2007 10:31:25 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZSUX-00086X-40 for ima@ietf.org; Sun, 23 Sep 2007 10:31:25 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2007 15:31:23 +0100 Message-ID: <46F678DE.3040109@isode.com> Date: Sun, 23 Sep 2007 15:31:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: John C Klensin Subject: Re: [EAI] EDITORIAL: smtpext sections References: <966730A3104AC560EA230C43@p3.JCK.COM> <46F6775F.6060805@isode.com> In-Reply-To: <46F6775F.6060805@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Alexey Melnikov wrote: > John C Klensin wrote: > >> (3) While I am less convinced about this that about the >> above two, I also believe that Sections 3.1 (LMTP) and >> 3.2 (DSNs) should be dropped, hence removing all of >> Section 3. > > I frankly don't understand why we have section 3.1 (LMTP). I thought I > line sentence saying that this extension is also applicable to LMTP > would be much better. I should have reread the section 3.1 before saying that. It actually says something else - "if your LMTP is not updated to support UTF8SMTP, then you might have a problem". What I've suggested above is in addition to this. I don't have a strong feeling on whether section 3.1 should stay or be removed. I slightly prefer to keep it. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 06:34:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZlGM-0004Q7-6H; Mon, 24 Sep 2007 06:34:02 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZlGL-0004Ou-0k for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 06:34:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZlGK-0004GZ-NP for ima@ietf.org; Mon, 24 Sep 2007 06:34:00 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZlG9-0002rC-8z for ima@ietf.org; Mon, 24 Sep 2007 06:33:55 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZl9B-0006gb-Jt for ima@ietf.org; Mon, 24 Sep 2007 10:26:37 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 10:26:37 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 10:26:37 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 12:18:51 +0200 Lines: 8 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [EAI] ISSUE: smtpext-08 2.2 erroneous MUSTard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org | If 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 message which contains internationalized mail headers | [EAI-utf8header] at any level within its MIME structure. It MUST NOT transmit a message with an I18N header. As soon as that's clear the object is by definition a message/rfc822, and its internal MIME structure isn't the business of relaying MTAs or this I-D. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 06:53:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZlYd-0001AS-Az; Mon, 24 Sep 2007 06:52:55 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZlYc-0001AK-4U for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 06:52:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZlYb-0001AC-Ov for ima@ietf.org; Mon, 24 Sep 2007 06:52:53 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZlYb-0005As-8P for ima@ietf.org; Mon, 24 Sep 2007 06:52:53 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZlYY-0000SK-61 for ima@ietf.org; Mon, 24 Sep 2007 10:52:50 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 10:52:50 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 10:52:50 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 12:50:35 +0200 Lines: 16 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [EAI] ISSUE: smtpext-08 2.4 ABNF X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org 2.4: Two ABNF oddities: -| "RCPT TO:" ("" / "" / | uForward-Path) [ SP Rcpt-parameters ] CRLF +| "RCPT TO:" ("" / "" / | uForward-Path) [ SP Rcpt-parameters ] CRLF -| ALT-ADDRESS-parameter=3D"ALT-ADDRESS=3D" ALT-ADDRESS-esmtp-value | -| ALT-ADDRESS-esmtp-value=3Dxtext That's hard to read. Proposal: +| Alt-address-parameter =3D "ALT-ADDRESS=3D" Alt-address-value | +| Alt-address-value =3D xtext _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 07:25:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZm3p-0002ba-Dp; Mon, 24 Sep 2007 07:25:09 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZm3n-0002aX-TS for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 07:25:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZm3n-0002Yp-HW for ima@ietf.org; Mon, 24 Sep 2007 07:25:07 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZm3n-0005xO-11 for ima@ietf.org; Mon, 24 Sep 2007 07:25:07 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZm3e-0002sW-Bc for ima@ietf.org; Mon, 24 Sep 2007 11:24:58 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 11:24:58 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 11:24:58 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 13:22:45 +0200 Lines: 14 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [EAI] ISSUE: smtpext-08 2.8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org IMO belonging to the same issue, 2.6 states: | Since there is no ESMTP parameter which tells whether the | message is UTF8SMTP message, SMTP server needs to parse | all message header fields and MIME header fields in the | message body to discover which messages are UTF8SMTP. Editorial: "a UTF8SMTP message" and "an SMTP server". Technical: It needs only to parse _the_ message header. The internal MIME structure of the body is irrelevant for relaying MTAs. =20 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 08:42:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnFa-0001AT-8C; Mon, 24 Sep 2007 08:41:22 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZnFY-00019F-PC for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 08:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnFY-00016y-FU for ima@ietf.org; Mon, 24 Sep 2007 08:41:20 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZnFN-00064E-2l for ima@ietf.org; Mon, 24 Sep 2007 08:41:15 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZnF0-0000AF-JE for ima@ietf.org; Mon, 24 Sep 2007 12:40:46 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 12:40:46 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 12:40:46 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 14:38:21 +0200 Lines: 226 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Subject: [EAI] EDITORIAL: smtpext-08 (1 .. 3) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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,=20 I'd say "An internationalized email address includes" instead of "Internationalized email address includes without article. Ditto "the email transport [...] provides" with an article, maybe there are more missing articles in the document. Is the reference to RFC 1869 necessary ? It's obsoleted by RFC 2821. Something's odd with RFC 1869, its front page says that it belongs to STD 10, but RFC 3700 says that STD 10 consists of RFC 821 and RFC 1870 (not 1869). Maybe replace "the specification in [EAI-ut8header] specifies" by "[EAI-utf8header] specifies", or s/specifies/explains/ 2.1 #9: "The mail datum is extended"... what's a mail datum ? 2.2 s/a "mailbox" MAY appear/a mailbox may appear/, it's not about a normative OPTION. Or s/MAY/can/ to be sure. "The UTF8SMTP extension is valid on the submission port [RFC4409]." Maybe write "... can be also used for message submission [RCF4409]." 2.3 : | That string MUST NOT contain any of the ASCII characters | (either graphics or controls) that are not permitted in=20 | "atext"; it is otherwise unrestricted. s/; it is otherwise unrestricted// At some point in time (not now) there can be resrictions about say non-characters or private use characters. 2.5: | [EAI-utf8header] specifies "UTF8SMTP message" which requires | UTF8SMTP support. Such a message MUST NOT be sent to an SMTP [...] An UTF8SMTP message or message/global or whatever requires UTF8SMTP support only if transported with ESMTP, other transport protocols like xmpp, nntp, etc. need to find their own way to deal with such messages. Proposal: | An "UTF8SMTP message" as specified in [EAI-utf8header] MUST | NOT be sent to an SMTP [...] 2.6: | 1. For No "Body" parameter, headers are in UTF-8, body parts | are in ASCII. | 2. For BODY=3D8BITMIME parameter, headers are in UTF-8, some | or all body parts contain 8-bit line-oriented data. | 3. For BODY=3DBINARYMIME parameter, headers are in UTF-8, some | or all body parts contain binary data without restriction | as to line lengths or delimiters. s/headers are/the header is/ and /body parts are/the body is/. The internal MIME structure of messages is opaque for relaying MTAs. 2.7.3: -| Time stamp appears in the form of "Received: lines". +| "Received:" header fields are also known as time stamp lines. And s/("time stamp" or "Received")// before. s/debugging mail faults/forensics/ (?) (caveat, my DEnglish is utter dubious) | The primary purpose of the Return-path is to designate the=20 | address to which messages indicating non-delivery or other | mail system failures are to be sent. s/mail system failures/auto-replies/ Or maybe delete this very incomplete explanation of the Return-Path here =3D> KISS. -| we update the time stamp line and the return path line +| this memo updates the time stamp line and the return path +| header field [RFC2821] Maybe a matter of taste. The "we update" style is fine, but I think it should be used consistently or not. | ; Replaces Return-path-line in the section 4.4 of I'd replace "in the section ... of" by "in section ... of" everywhere. =20 | where non-ASCII domain name may be used s/name/names/ -| More information is in the "IANA Considerations" section -| of this document.=20 +| Compare the "IANA Considerations" of this document. 2.7.4: -| If the client issues the RCPT command which contains=20 -| non-ASCII characters, the SMTP server +| If the client sends a RCPT command containing non-ASCII +| characters, the SMTP server | the client can accept UTF-8 on replies of the VRFY and | EXPN commands Maybe s/on replies of/in replies to/ (???) | MUST not use UTF-8 on replies, if the SMTP client does | not ask UTF-8 replies Maybe s/on replies/in replies/ and s/ask/ask for/ (???) s/most of replies/most replies/ =20 ABNF-nit: -| "VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF; +| "VRFY" SP (uLocal-part / uMailbox) [SP "UTF8REPLY"] CRLF Ditto for EXPN (=3D remove the unnecessary semicolon). -| This parameter "UTF8REPLY" does not have value. If SMTP reply +| The parameter "UTF8REPLY" has no value. If the SMPT reply Or better remove this "no value" remark, the syntax is clear. -| ; User Name allows the non-ASCII character. +| ; User Name can contain non-ASCII UTF-8 characters. That's an issue in 2821bis-04, if the User Name syntax is not yet specified. E.g. we can't have a "<" here. -| enhanced mail system status code [RFC3463] is used +| enhanced mail system status codes [RFC3463] are used -| If the SMTP Client lack of the UTF8SMTP support receives -| the UTF-8 message on reply, it may crash. That's gibberish, just delete it. Of course the client "may crash" if the server violates MUSTard, that's more or less=20 the definition of MUST in 2119. I think one of the two last paragraphs in 2.7.4 can be=20 deleted, they are variations of the same obvious concept. Please get rid of chapter 3, these issues are discussed in other I-Ds. Frank =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 09:04:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnc9-0003G4-6H; Mon, 24 Sep 2007 09:04:41 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZnc8-00035W-8H for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 09:04:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnc7-0002Pb-RL for ima@ietf.org; Mon, 24 Sep 2007 09:04:39 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZnbr-00007g-Tc for ima@ietf.org; Mon, 24 Sep 2007 09:04:24 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3$clerew*man#ac*uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.254) id 46f7b5d4.4646.ae for ima@ietf.org; Mon, 24 Sep 2007 14:04:20 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8OD4JuY016966 for ; Mon, 24 Sep 2007 14:04:21 +0100 (BST) To: IMA Subject: Re: [EAI] ISSUE: smtpext-08 2.2 erroneous MUSTard References: Message-ID: Date: Mon, 24 Sep 2007 14:04:19 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Mon, 24 Sep 2007 11:18:51 +0100, Frank Ellermann wrote: > | 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 message which contains internationalized mail headers > | [EAI-utf8header] at any level within its MIME structure. > > It MUST NOT transmit a message with an I18N header. As soon as that's > clear the object is by definition a message/rfc822, and its internal > MIME structure isn't the business of relaying MTAs or this I-D. No, that is not enough. Suppose the message has all-ascii addresses throughout, and everything in the top-level header is pure ASCII, but suppose that the body is a multipart and one of the multiparts has a Content-Description written in Chinese using raw UTF-8. Then that message is a global/UTF8SMTP message and must not be transmitted outside the UTF8SMTP world without downgrading. The existing wording makes this perfectly clear (and makes it clear that a scan through the full body is always necessary to check for such 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 Mon Sep 24 09:06:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZndI-0006Zi-8F; Mon, 24 Sep 2007 09:05:52 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZndH-0006ZU-4A for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 09:05:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZndG-0006ZK-MQ for ima@ietf.org; Mon, 24 Sep 2007 09:05:50 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZndF-0000Ad-VR for ima@ietf.org; Mon, 24 Sep 2007 09:05:50 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3^clerew*man*ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.254) id 46f7b62c.4594.a5 for ima@ietf.org; Mon, 24 Sep 2007 14:05:48 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8OD5ijE017057 for ; Mon, 24 Sep 2007 14:05:45 +0100 (BST) Date: Mon, 24 Sep 2007 13:03:47 +0100 From: "Charles Lindsey" To: "John C Klensin" Subject: Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt References: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) Resent-To: IMA Resent-From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Resent-Date: Mon, 24 Sep 2007 14:05:44 +0100 Resent-Message-ID: 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: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Fri, 21 Sep 2007 22:31:18 +0100, John C Klensin wrote: > --On Wednesday, 19 September, 2007 20:35 +0100 Charles Lindsey > wrote: > >> That can apply whether the "next man" is the next hop to >> another MTA, or whether it is some complex situation in the >> local storage/delivery/forwarding system. So I see no reason >> why the (supposedly final) MTA cannot accept the message, but >> later bounce it because it subsequently transpires that there >> are the wrong number of Fridays in this particular month. Just >> so long as it does not lose it without trace. > > I think we agree, so am no longer sure what the issue is here. > A problem would arise iff someone or something required that the > delivery MTA _reject_ (not bounce/ generate an NDN) message if > it could not deliver an i18n email message all the way to the > POP client. Yes. think my only worry is that, as we all know, a final delivery agent has all sorts of other agents hiding behind it for storage of the message and for delivering it to clients via POP3, IMAP, procmail and doubtless many others. Traditionally, the interfaces between the MTA and these other agents in invisible from the outside, and the IETF steers clear of trying to specify them. Nevertheless, it is often these 'hidden' agents that will actually initiate the bounces/DSNs when they are unable to cope with the message as received (e.g. wrong number of Fridays in the month). OTOH, RFC 3461 (and hence our own DSN draft) is written on the assumption that these DSNs etc will be sent by an MTA, and any status codes etc giving the reason for the failure will be based on the return codes from RFC 2821 or from RFC 3463, which may not cover some of the more obscure reasons that may apply. However, this is not really our problem (except insofar as downgrading disabilities may provide a fresh crop of such obscure reasons). It is a proplem for email in general which we should probably steer clear of. -- 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 Sep 24 09:09:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnh5-00029c-2o; Mon, 24 Sep 2007 09:09:47 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZnh2-00029L-6d for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 09:09:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnh1-0001q9-La for ima@ietf.org; Mon, 24 Sep 2007 09:09:43 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZngm-0000HN-Gl for ima@ietf.org; Mon, 24 Sep 2007 09:09:28 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3^clerew#man&ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.254) id 46f7b707.1558f.567 for ima@ietf.org; Mon, 24 Sep 2007 14:09:27 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8OD9QIX017281 for ; Mon, 24 Sep 2007 14:09:27 +0100 (BST) To: IMA Subject: Re: [EAI] EDITORIAL: smtpext sections References: <966730A3104AC560EA230C43@p3.JCK.COM> <46F6775F.6060805@isode.com> <46F678DE.3040109@isode.com> Message-ID: Date: Mon, 24 Sep 2007 14:09:26 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <46F678DE.3040109@isode.com> 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 Sun, 23 Sep 2007 15:31:58 +0100, Alexey Melnikov wrote: > Alexey Melnikov wrote: > >> John C Klensin wrote: >> >>> (3) While I am less convinced about this that about the >>> above two, I also believe that Sections 3.1 (LMTP) and >>> 3.2 (DSNs) should be dropped, hence removing all of >>> Section 3. >> >> I frankly don't understand why we have section 3.1 (LMTP). I thought I >> line sentence saying that this extension is also applicable to LMTP >> would be much better. +1. The smtpext draft must be clear that it updates both SMTP and LMTP (if there is some specific feature of LMTP where that would not apply, then let us hear about it). > > I should have reread the section 3.1 before saying that. It actually > says something else - "if your LMTP is not updated to support UTF8SMTP, > then you might have a problem". What I've suggested above is in addition > to this. By all means. > > I don't have a strong feeling on whether section 3.1 should stay or be > removed. I slightly prefer to keep it. So long as it is said somewhere, it doesn't need to be section 3.1. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 09:13:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnkZ-0006gX-13; Mon, 24 Sep 2007 09:13:23 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZnkW-0006dL-Sc for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 09:13:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnkW-0006bG-EY for ima@ietf.org; Mon, 24 Sep 2007 09:13:20 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZnkV-0000PO-PX for ima@ietf.org; Mon, 24 Sep 2007 09:13:20 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3$clerew#man&ac^uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.254) id 46f7b7ee.facd.18 for ima@ietf.org; Mon, 24 Sep 2007 14:13:18 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8ODDGik017515 for ; Mon, 24 Sep 2007 14:13:17 +0100 (BST) To: IMA Subject: Re: [EAI] EDITORIAL: dsn References: <46F2AC4A.7090605@isode.com> <46F3A69D.1080803@isode.com> Message-ID: Date: Mon, 24 Sep 2007 14:13:16 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <46F3A69D.1080803@isode.com> 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 Fri, 21 Sep 2007 12:10:21 +0100, Alexey Melnikov wrote: > Charles Lindsey wrote: >>> Another argument for using C-T-E conversion is that servers can >>> already do that ..... >> >> I have repeatedly asked for a single example of a server that can >> already do that, and no example has been forthcoming (whereas we know >> of several servers that currently cannot do it). That is the whole >> basis of the ISSUE that I have raised. > > I believe Isode pp can do that. But I haven't tested this yet ;-). OK, can anyone else confirm this? I just Googled for ISODE PP, and all the mentions of it that I found seemed increadibly ancient. Is it widely used in pure SMTP circles (as opposed to situations where X.400 is being gatewayed to/from)? -- 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 Sep 24 11:43:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZq4b-0004Oy-PS; Mon, 24 Sep 2007 11:42:13 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZq4Z-0004Mt-UM for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 11:42:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZq4Z-0004MN-IJ for ima@ietf.org; Mon, 24 Sep 2007 11:42:11 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZq4Y-0004om-U2 for ima@ietf.org; Mon, 24 Sep 2007 11:42:11 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IZq4Y-000BFT-7o; Mon, 24 Sep 2007 11:42:10 -0400 Date: Mon, 24 Sep 2007 11:42:09 -0400 From: John C Klensin To: Charles Lindsey , IMA Subject: Re: [EAI] EDITORIAL: dsn Message-ID: <039AFF3E32FA1046CC3D9B2C@p3.JCK.COM> In-Reply-To: References: <46F2AC4A.7090605@isode.com> <46F3A69D.1080803@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 Charles, I'm confused about what you are asking for, but * Every server that can do 8BITMIME downgrading (and that includes such popular ones as Sun and Sendmail), does C-T-E remapping. This is also true of servers that do BINARYMIME downgrading, but there may be fewer of those. * Every delivery server (or IMAP/POP server/processor) that converts content from C-T-E q-p or base64 to the corresponding 8bit form (and there are many of those), does C-T-E remapping. I, at least, haven't responded to your request because I have believed that I either didn't understand it (which is still possible) or that the feature was so wideely deployed as to not be worth discussing further. john --On Monday, 24 September, 2007 14:13 +0100 Charles Lindsey wrote: > On Fri, 21 Sep 2007 12:10:21 +0100, Alexey Melnikov > wrote: > >> Charles Lindsey wrote: > >>>> Another argument for using C-T-E conversion is that servers >>>> can already do that ..... >>> >>> I have repeatedly asked for a single example of a server >>> that can already do that, and no example has been >>> forthcoming (whereas we know of several servers that >>> currently cannot do it). That is the whole basis of the >>> ISSUE that I have raised. >> >> I believe Isode pp can do that. But I haven't tested this yet >> ;-). > > OK, can anyone else confirm this? I just Googled for ISODE PP, > and all the mentions of it that I found seemed increadibly > ancient. > > Is it widely used in pure SMTP circles (as opposed to > situations where X.400 is being gatewayed to/from)? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 12:02:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZqNp-0002dt-QF; Mon, 24 Sep 2007 12:02:05 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZqNo-0002d8-SR for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 12:02:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZqNo-0002cz-Gg for ima@ietf.org; Mon, 24 Sep 2007 12:02:04 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZqNn-0005ST-R3 for ima@ietf.org; Mon, 24 Sep 2007 12:02:04 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 24 Sep 2007 17:02:00 +0100 Message-ID: <46F7DF90.20403@isode.com> Date: Mon, 24 Sep 2007 17:02:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Charles Lindsey Subject: Re: [EAI] EDITORIAL: dsn References: <46F2AC4A.7090605@isode.com> <46F3A69D.1080803@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: IMA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Charles Lindsey wrote: > On Fri, 21 Sep 2007 12:10:21 +0100, Alexey Melnikov > wrote: > >> Charles Lindsey wrote: > >>>> Another argument for using C-T-E conversion is that servers can >>>> already do that ..... >>> >>> I have repeatedly asked for a single example of a server that can >>> already do that, and no example has been forthcoming (whereas we >>> know of several servers that currently cannot do it). That is the >>> whole basis of the ISSUE that I have raised. >> >> I believe Isode pp can do that. But I haven't tested this yet ;-). > > OK, can anyone else confirm this? I just Googled for ISODE PP, and all > the mentions of it that I found seemed increadibly ancient. http://www.isode.com/products/m-switch.html (pp is an internal name, the product is now known as M-Switch) > Is it widely used in pure SMTP circles (as opposed to situations > where X.400 is being gatewayed to/from)? It can be run as a pure Internet MTA. I am certainly not communicating to you using X.400/MIXER ;-) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 13:04:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrLg-0001vz-1v; Mon, 24 Sep 2007 13:03:56 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZrLf-0001vu-2T for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 13:03:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrLe-0001uV-Mz for ima@ietf.org; Mon, 24 Sep 2007 13:03:54 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZrLc-0008DT-0U for ima@ietf.org; Mon, 24 Sep 2007 13:03:52 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZrLW-0007vY-5N for ima@ietf.org; Mon, 24 Sep 2007 17:03:46 +0000 Received: from 1cust116.tnt1.hbg2.deu.da.uu.net ([149.225.10.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 17:03:46 +0000 Received: from nobody by 1cust116.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 17:03:46 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 19:03:19 +0200 Organization: http://purl.net/xyzzy Lines: 34 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust116.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [EAI] ISSUE: smtpext-08 3..5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org As John and others have noted, chapters 3..5 are somewhat odd. The I-D isn't about POP3, LMTP, IMAP, DSNs, MIME, or 2822upd, it's about ESMTP with the UTF8SMTP and should focus on this.=B4 As an editorial point about section 4: The subsection 4.1 is an orphan, there's no 4.2. Substantial point about a remark in section 5: | It is notable in an internationalization context that there | is a long history on some systems of using overstruck ASCII | characters (a character, a backspace, and another character) | within a quoted string to approximate non-ASCII characters. I've never seen this, maybe it's limited to communities where the Latin-1 subset of Unicode isn't the predominant charset. | This form of internationalization SHOULD be phased out as | this extension becomes widely deployed Using NO-WS-CTL anywhere in a message header should be phased out a.s.a.p. in 2822upd. That's no job for EAI, let alone this I-D. | backward-compatibility considerations require that it | continue to be supported. At the moment 2822upd still allows NO-WS-CTL. In the "worst" (for the *alleged* backward compatibility) case it could say "MUST accept, MUST NOT generate" moving NO-WS-CTL wholesale to its obs-cenity section. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 13:19:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZra4-00031H-3R; Mon, 24 Sep 2007 13:18:48 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZra2-000316-DJ for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 13:18:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZra2-00030y-3l for ima@ietf.org; Mon, 24 Sep 2007 13:18:46 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZrZw-0006fV-R9 for ima@ietf.org; Mon, 24 Sep 2007 13:18:46 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZrZd-00021z-Ur for ima@ietf.org; Mon, 24 Sep 2007 17:18:21 +0000 Received: from 1cust116.tnt1.hbg2.deu.da.uu.net ([149.225.10.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 17:18:21 +0000 Received: from nobody by 1cust116.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 17:18:21 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 19:17:42 +0200 Organization: http://purl.net/xyzzy Lines: 13 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust116.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [EAI] ISSUE: smtext-08 security considerations X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I'm at a loss how section 7 passed any giggle test before WGLC. Without a thorough discussion why offering UTF8SMTP at the MX when it won't work out at the final delivery MTA is a really bad idea this I-D isn't ready for an IETF Last Call. Nobody wants *more* undeliverable mails causing misdirected bounces. That's likely not the only missing "security consideration", the very minumum I expect in an RFC is a honest attempt to discuss potential security issues. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 13:28:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrjb-0004DF-MM; Mon, 24 Sep 2007 13:28:39 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZrja-0004BF-GP for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 13:28:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrja-0004AH-4L for ima@ietf.org; Mon, 24 Sep 2007 13:28:38 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZrjZ-0000gA-JY for ima@ietf.org; Mon, 24 Sep 2007 13:28:37 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZrjO-0003AW-Up for ima@ietf.org; Mon, 24 Sep 2007 17:28:26 +0000 Received: from 1cust116.tnt1.hbg2.deu.da.uu.net ([149.225.10.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 17:28:26 +0000 Received: from nobody by 1cust116.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 17:28:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 19:27:59 +0200 Organization: http://purl.net/xyzzy Lines: 19 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust116.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [EAI] EDITORIAL: smtpext-08 references X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org For my questions about the RFC 1869 reference see=20 | draft-klensin-emailaddr-i18n-03 (work in progress), There's a trick how to get rid of "work in progress" where it's clearly wrong, IIRC it has to be done with a manual when using xml2rfc. | [RFC2554bis] | Siemborski, R. and A. Melnikov, "SMTP Service Extension | for Authentication", draft-siemborski-rfc2554bis-09 (work | in progress), April 2007. That's now RFC 4954. =20 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 13:34:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZroz-00069K-Pp; Mon, 24 Sep 2007 13:34:13 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZroz-00068m-D2 for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 13:34:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZroz-000682-3D for ima@ietf.org; Mon, 24 Sep 2007 13:34:13 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZros-0007Cv-Rz for ima@ietf.org; Mon, 24 Sep 2007 13:34:13 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IZroh-000ENQ-1w; Mon, 24 Sep 2007 13:33:55 -0400 Date: Mon, 24 Sep 2007 13:33:54 -0400 From: John C Klensin To: Frank Ellermann Subject: Re: [EAI] ISSUE: smtpext-08 3..5 Message-ID: <65FED6357B54E828B90B1066@p3.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Monday, 24 September, 2007 19:03 +0200 Frank Ellermann wrote: > As John and others have noted, chapters 3..5 are somewhat odd. >=20 > The I-D isn't about POP3, LMTP, IMAP, DSNs, MIME, or 2822upd, > it's about ESMTP with the UTF8SMTP and should focus on = this.=C2=B4 >=20 > As an editorial point about section 4: The subsection 4.1 is > an orphan, there's no 4.2. >=20 > Substantial point about a remark in section 5: >=20 > | It is notable in an internationalization context that there > | is a long history on some systems of using overstruck ASCII > | characters (a character, a backspace, and another character) > | within a quoted string to approximate non-ASCII characters. >=20 > I've never seen this, maybe it's limited to communities where > the Latin-1 subset of Unicode isn't the predominant charset. It is limited to communities where eight-bit character sets haven't taken off, or before they had taken off. If you have ever wondered why the backspace character in Unix and U**x-derived systems is non-destructive, you have seen the symptoms. But, as with the material in Sections 3-5, it is not clear that the comments belong in this document. =20 >... john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 13:35:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrqY-0007hA-R8; Mon, 24 Sep 2007 13:35:50 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZrqX-0007h1-TC for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 13:35:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZrqX-0007gt-HT for ima@ietf.org; Mon, 24 Sep 2007 13:35:49 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZrqX-0000uL-1G for ima@ietf.org; Mon, 24 Sep 2007 13:35:49 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZrqP-0004Cv-JS for ima@ietf.org; Mon, 24 Sep 2007 17:35:41 +0000 Received: from 1cust116.tnt1.hbg2.deu.da.uu.net ([149.225.10.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 17:35:41 +0000 Received: from nobody by 1cust116.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 17:35:41 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 19:35:14 +0200 Organization: http://purl.net/xyzzy Lines: 10 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust116.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [EAI] Re: EDITORIAL: smtpext-08 references X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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: [...] Sorry, I missed another nit: | [SMTP-codes] | KLensin, J., "An IANA Registry for Extended SMTP Status | Codes", draft-klensin-smtp-code-registry-00 (work in | progress), April 2007. ITYM draft-hansen-4468upd-mailesc-registry-02 (July 8) _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 13:56:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZsAn-0002oy-Ev; Mon, 24 Sep 2007 13:56:45 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZsAm-0002oU-Nj for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 13:56:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZsAm-0002oB-Bo for ima@ietf.org; Mon, 24 Sep 2007 13:56:44 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZsAl-0001c7-Py for ima@ietf.org; Mon, 24 Sep 2007 13:56:44 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZsAe-0006tn-9x for ima@ietf.org; Mon, 24 Sep 2007 17:56:36 +0000 Received: from 1cust116.tnt1.hbg2.deu.da.uu.net ([149.225.10.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 17:56:36 +0000 Received: from nobody by 1cust116.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 17:56:36 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 19:56:04 +0200 Organization: http://purl.net/xyzzy Lines: 21 Message-ID: References: <65FED6357B54E828B90B1066@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust116.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [EAI] Re: ISSUE: smtpext-08 3..5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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: [Interesting (ab)uses of BS] > It is limited to communities where eight-bit character sets > haven't taken off, or before they had taken off. If you have > ever wondered why the backspace character in Unix and U**x- > derived systems is non-destructive, you have seen the symptoms. Well, I know the trick in conjunction with documents sent to a printer, and I know "less" to view such documents without a printer. But I've never seen that anybody went so far to use this trick in the local part of an e-mail address. =20 > as with the material in Sections 3-5, it is not clear that > the comments belong in this document. +1 Maybe the EAI WG could petition the 2822upd and 2821bis authors to get rid of NO-WS-CTL as far as possible... _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 15:26:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZtZG-0006xT-Al; Mon, 24 Sep 2007 15:26:06 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZtZF-0006wW-7K for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 15:26:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZtZE-0006tW-Tw for ima@ietf.org; Mon, 24 Sep 2007 15:26:04 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZtZ2-0002mQ-K7 for ima@ietf.org; Mon, 24 Sep 2007 15:26:00 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZtYa-0003LF-OW for ima@ietf.org; Mon, 24 Sep 2007 19:25:24 +0000 Received: from 1cust116.tnt1.hbg2.deu.da.uu.net ([149.225.10.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 19:25:24 +0000 Received: from nobody by 1cust116.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 19:25:24 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 21:24:56 +0200 Organization: http://purl.net/xyzzy Lines: 65 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust116.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [EAI] EDITORIAL: dsn-03 1..3 (at the end it's an ISSUE: dsn HEXPOINT) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org 2: -| and the rules in section 4 of RFC 3629. Lack of caffeine, I really clicked on the rfcmarkup link to check what you're talking about. Maybe say: +| and the UTF-8 syntax rules in section 4 of RFC 3629. 3: | I.e. the utf-8-address form MUST NOT be used in the | ORCPT parameter when the SMTP server doesn't advertise | support for UTF8SMTP or the SMTP server supports | UTF8SMTP, but the address contains US-ASCII characters | not permitted in the ORCPT parameter (e.g. the ORCPT | parameter forbids unencoded SP and =3D); or in a=20 | 7-bit transport environment including a=20 | message/delivery-status Original-Recipient or | Final-Recipient field. Hard to parse. How about an ordered list [...] "when:" "1: the SMTP server doesn't advertise UTF8SMTP" [...], "2: the SMTP server supports UTF8SMTP, but" [...], "3: in a 7-bit transport environment" [...]. | In the former case the utf-8-addr-xtext form What's the former case here, the "1" in my proposal ? | in the latter case the utf-8-addr-unitext form If the latter case is "3", what about "2" ? The prose is really hardcore, I had to jump forward to the ABNF to get a vague idea what you're talking about. An is apparently a "raw" with an optional ASCII in angle brackets for the optional Alt-Address. Readers need to know this before you start with the MUSTard and the fine print. Then there's a problem with some ASCII characters not allowed in ORCPT. For that you introduce an=20 term, which is the 3461-xtext encoding of a . =20 And is apparently any UTF-8 character excluding CTLs, SP, "\", "+", and "=3D", where you need an \x... notation with the name . [The remark "printable" for QUCHAR confuses me, not all non-ASCII UTF-8 characters are printable]. Another question, if an contains an Alt-Address, then it also contains 1*WSP as a separator between uMailbox and "<" Mailbox ">". Often WSP is SP, and that's not allowed for the ORCPT magic, is that correct ? How about some examples ? The HEXPOINT syntax is completely beyond me, what is this about ? What problem are you trying to solve ? Why can't you use simple hex. NCRs, and be done with it ? =20 Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 16:16:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZuLy-0005oQ-7k; Mon, 24 Sep 2007 16:16:26 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZuLx-0005oL-F7 for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 16:16:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZuLx-0005m4-2k for ima@ietf.org; Mon, 24 Sep 2007 16:16:25 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZuLw-0006DU-HC for ima@ietf.org; Mon, 24 Sep 2007 16:16:24 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZuDJ-0003Bw-DX for ima@ietf.org; Mon, 24 Sep 2007 20:07:29 +0000 Received: from 1cust116.tnt1.hbg2.deu.da.uu.net ([149.225.10.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 20:07:29 +0000 Received: from nobody by 1cust116.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 20:07:29 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 22:00:45 +0200 Organization: http://purl.net/xyzzy Lines: 18 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust116.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [EAI] EDITORIAL: dsn-03 chapter 3 QMIDCHAR + QHIGHCHAR X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Okay, now I think I see what's HEXPOINT about, it tries to avoid leading zeros and surrogates in ABNF. Actually it's one of the three notations in John's=20 http://tools.ietf.org/html/draft-klensin-unicode-escapes Hopefully perl-fans will love it, that's good enough. IMO it's not strictly necessary to discuss surrogates in ABNF in an I-D about DSNs, but that's no "ISSUE" (now I had some coffee, that helped). Back to the editorial nitpicking: The 6th paragraph in section 3 talks about QMIDCHAR and QHIGHCHAR, but there's no ABNF or other explanation for this anymore. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 16:42:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZukT-0007ow-Bn; Mon, 24 Sep 2007 16:41:45 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZukR-0007mY-FG for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 16:41:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZukR-0007iP-5f for ima@ietf.org; Mon, 24 Sep 2007 16:41:43 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZukE-00057v-52 for ima@ietf.org; Mon, 24 Sep 2007 16:41:38 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZuWf-0007s6-HI for ima@ietf.org; Mon, 24 Sep 2007 20:27:29 +0000 Received: from 1cust116.tnt1.hbg2.deu.da.uu.net ([149.225.10.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 20:27:29 +0000 Received: from nobody by 1cust116.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 20:27:29 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 22:20:55 +0200 Organization: http://purl.net/xyzzy Lines: 6 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust116.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [EAI] EDITORIAL: dsn-03 "i-default" X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Chapter 4 says that "i-default" is explained in [LANGTAGS], and the references say that [LANGTAGS] is RFC 4646. But RFC 4646 doesn't discuss "i-default", it's explained in 4646bis (work in progress) with a reference to RFC 2277 [BCP 18]. Proposal: Use RFC 2277 for now, and switch to 4646bis later if it's ready when you need it. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 17:43:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZvhu-00015j-HU; Mon, 24 Sep 2007 17:43:10 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZvhs-0000vv-Ic for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 17:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZvhs-0000sP-8x for ima@ietf.org; Mon, 24 Sep 2007 17:43:08 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZvhh-0006kR-2H for ima@ietf.org; Mon, 24 Sep 2007 17:43:03 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZvZw-0006X7-Nz for ima@ietf.org; Mon, 24 Sep 2007 21:34:56 +0000 Received: from 1cust116.tnt1.hbg2.deu.da.uu.net ([149.225.10.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 21:34:56 +0000 Received: from nobody by 1cust116.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 21:34:56 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 22:36:38 +0200 Organization: http://purl.net/xyzzy Lines: 8 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust116.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [EAI] ISSUE: dsn-03 utf8-text X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org | utf8-text =3D %d1-9 / ; Any Unicode character except for NUL, | %d11 / ; CR and LF, encoded in UTF-8 | %d12 / | %d14-127 / | UTFMB || UTFMB =3D UTF2 / UTF3 / UTF4I don't like this, it allows NO-WS-CTL. = And the "UTFMB" isn'tused elsewhere. How about this:utf8-text =3D SP / = VCHAR / UTF2 / UTF3 / UTF4 Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 17:56:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZvuV-0007yg-9I; Mon, 24 Sep 2007 17:56:11 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZvuU-0007ya-6j for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 17:56:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZvuT-0007yS-Nr for ima@ietf.org; Mon, 24 Sep 2007 17:56:09 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZvuS-0000YJ-TF for ima@ietf.org; Mon, 24 Sep 2007 17:56:09 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZvga-00081b-WD for ima@ietf.org; Mon, 24 Sep 2007 21:41:49 +0000 Received: from 1cust116.tnt1.hbg2.deu.da.uu.net ([149.225.10.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 21:41:48 +0000 Received: from nobody by 1cust116.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 21:41:48 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 23:28:04 +0200 Organization: http://purl.net/xyzzy Lines: 45 Message-ID: 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: 1cust116.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [EAI] Re: ISSUE: smtpext-08 2.2 erroneous MUSTard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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: >> It MUST NOT transmit a message with an I18N header. As soon as = that's >> clear the object is by definition a message/rfc822, and its internal >> MIME structure isn't the business of relaying MTAs or this I-D. =20 > No, that is not enough. Suppose the message has all-ascii addresses =20 > throughout, and everything in the top-level header is pure ASCII, but = > suppose that the body is a multipart and one of the multiparts has a =20 > Content-Description written in Chinese using raw UTF-8. The wonders of 8BITMIME or even binary mail bodies aren't relevant for the UTF8SMTP ESMTP extension, they're discussed elsewhere. Besides MIME 1.0 doesn't allow raw UTF-8 in Content-* header fields, so who knows what that is you're talking about, maybe it's MIME 2.0. Relaying MTAs should look for trouble in the body only on a "need to know" basis. They don't need to know MIME 2.0 or say yenc to support internationalized addresses. > Then that message is a global/UTF8SMTP message and must not be > transmitted outside the UTF8SMTP world without downgrading. If this global/UTF8SMTP message format is incompatible with known 8BITMIME or binary bodies it has to indicate this in its header, maybe using MIME-Version: . But that has nothing to do with internationalized addresses and the goal of the EAI experiment. Unless the desired outcome is "FAIL", and that would be sneaky. The EAI idea is interesting enough to deserve a fair chance, it must not be burdened with MIME 2.0. Besides I don't believe for a second that message/global could be limited to the "UTF8SMTP world" (i.e. to participants of the EAI experiment), anybody can use it as part of a message/rfc822, or FWIW as part of message/news, everywhere. For crying out loud, the smtpext-08 "security considerations" are *empty*. They don't mention an "UTF8SMTP world" or "sandbox" or other fantastic stories not limited to MIME 2.0. =20 Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 17:58:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZvwd-0000XA-47; Mon, 24 Sep 2007 17:58:23 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZvwb-0000Wz-MT for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 17:58:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZvwb-0000Wh-Cu for ima@ietf.org; Mon, 24 Sep 2007 17:58:21 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZvwX-000750-3s for ima@ietf.org; Mon, 24 Sep 2007 17:58:21 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZvrR-00026e-DO for ima@ietf.org; Mon, 24 Sep 2007 21:53:01 +0000 Received: from 1cust116.tnt1.hbg2.deu.da.uu.net ([149.225.10.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 21:53:01 +0000 Received: from nobody by 1cust116.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 21:53:01 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Mon, 24 Sep 2007 23:47:41 +0200 Organization: http://purl.net/xyzzy Lines: 16 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust116.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [EAI] Re: ISSUE: dsn-03 utf8-text X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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 has to learn how to tame OE, sorry, next attempt: | utf8-text =3D %d1-9 / ; Any Unicode character except for NUL, | %d11 / ; CR and LF, encoded in UTF-8 | %d12 / | %d14-127 / | UTFMB | | UTFMB =3D UTF2 / UTF3 / UTF4 I don't like this, it allows NO-WS-CTL. And the "UTFMB" isn't used elsewhere. How about this: utf8-text =3D SP / VCHAR / UTF2 / UTF3 / UTF4 Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 18:16:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwE3-0005Jj-18; Mon, 24 Sep 2007 18:16:23 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZwE1-0005I1-8n for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 18:16:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwE0-0005Ht-Sc for ima@ietf.org; Mon, 24 Sep 2007 18:16:20 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZwE0-0000rP-BG for ima@ietf.org; Mon, 24 Sep 2007 18:16:20 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZwDQ-0006HV-0D for ima@ietf.org; Mon, 24 Sep 2007 22:15:44 +0000 Received: from 1cust116.tnt1.hbg2.deu.da.uu.net ([149.225.10.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 22:15:43 +0000 Received: from nobody by 1cust116.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 22:15:43 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 25 Sep 2007 00:14:59 +0200 Organization: http://purl.net/xyzzy Lines: 6 Message-ID: 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: 1cust116.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [EAI] Re: ISSUE utf8 meaage/global X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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: =20 > I reiterate my objection to this breach of the "EXPRESSLY FORBIDDEN" > rule in RFC 2045 +1 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 18:41:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwcB-0002Je-LB; Mon, 24 Sep 2007 18:41:19 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZwcA-0002IJ-P0 for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 18:41:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwcA-0002F4-93 for ima@ietf.org; Mon, 24 Sep 2007 18:41:18 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZwc9-0001Jh-Kw for ima@ietf.org; Mon, 24 Sep 2007 18:41:17 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZwbu-00020B-2R for ima@ietf.org; Mon, 24 Sep 2007 22:41:02 +0000 Received: from 1cust116.tnt1.hbg2.deu.da.uu.net ([149.225.10.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 22:41:02 +0000 Received: from nobody by 1cust116.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 22:41:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 25 Sep 2007 00:40:36 +0200 Organization: http://purl.net/xyzzy Lines: 31 Message-ID: References: <46F0F23A.9060601@isode.com> <545C05C2356954E62D1A5D7E@p3.JCK.COM> 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: 1cust116.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [EAI] Re: EDITORIAL: draft-ietf-eai-smtpext-08.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > Alexey Melnikov wrote: [...] >> The last sentence is trying to redefine something already >> specified in [EAI-dsn]. I think it contradicts [EAI-dsn]. >> Suggestion to replace the last sentence with a pointer to >> [EAI-dsn] =20 > IMO, this suggestion does not go far enough. The correct > fix, IMO, is to replace this paragraph with=20 =20 > 2. Reject the message during the SMTP transaction or > generate a notification of non-deliverability, as > specified in RFC 2821 [RFC2821], RFC 3464 [RFC3464], and > [EAI-dsn]. Yes, that should cover UTF8SMTP with and without DSN.=20 If Alexey prefers to couple the UTF8SMTP extension with DSN like it's already coupled with 8BITMIME this would need fresh MUSTard in the I-D, and a subject starting with "ISSUE" for the Chairs :-) IIRC DSN-support is at SHOULD in 2821 and 2821bis, I could not tell spontaneously why UTF8SMTP needs a MUST. > I agree that the references to EAI-DSN and to RFC 4409 are > normative. +1 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Mon Sep 24 19:12:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZx5g-0001YR-Rq; Mon, 24 Sep 2007 19:11:48 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IZx5e-0001Wn-Qs for ima-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 19:11:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZx5e-0001Qy-Ez for ima@ietf.org; Mon, 24 Sep 2007 19:11:46 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZx5W-0000q2-79 for ima@ietf.org; Mon, 24 Sep 2007 19:11:44 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZx5A-0006SR-FW for ima@ietf.org; Mon, 24 Sep 2007 23:11:16 +0000 Received: from 1cust116.tnt1.hbg2.deu.da.uu.net ([149.225.10.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 23:11:16 +0000 Received: from nobody by 1cust116.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Sep 2007 23:11:16 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 25 Sep 2007 01:10:34 +0200 Organization: http://purl.net/xyzzy Lines: 23 Message-ID: References: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> 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: 1cust116.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [EAI] Re: REVIEW: draft-ietf-eai-smtpext-08.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: =20 > Charles Lindsey wrote: >> If an MTA returns a 2xx response, then the most it is=20 >> claiming is "I think I know what to do with this message, >> so I am accepting (allowing you to send) it; but the >> next man in line might think otherwise, in which case >> I promise to send a bounce (DSN) up the Return Path". =20 > Yes. No :-) The DSN has to go to the "originator as indicated in the Return Path", therefore the MTA has to be confident that the Return Path in fact indicates the originator. Otherwise it better rejects "dubious" mails instead of risking to violate this RFC 2821 requirement, where "dubious" includes any instance of "final delivery is less than almost certain". =20 Frank=20 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 25 00:38:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia2BB-0004SW-2N; Tue, 25 Sep 2007 00:37:49 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ia2B9-0004KE-JE for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 00:37:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia2B9-0004K6-9A for ima@ietf.org; Tue, 25 Sep 2007 00:37:47 -0400 Received: from mail1.exchange.microsoft.com ([131.107.1.17] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia2B8-0008DK-Vu for ima@ietf.org; Tue, 25 Sep 2007 00:37:47 -0400 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server (TLS) id 8.1.192.0; Mon, 24 Sep 2007 21:37:31 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.8]) by df-bhd-02.exchange.corp.microsoft.com ([157.54.71.155]) with mapi; Mon, 24 Sep 2007 21:37:31 -0700 From: Yuri Inglikov To: Frank Ellermann , "ima@ietf.org" Date: Mon, 24 Sep 2007 21:37:30 -0700 Subject: RE: [EAI] Re: ISSUE utf8 meaage/global Thread-Topic: [EAI] Re: ISSUE utf8 meaage/global Thread-Index: Acf++PB5gvxsd1P0TP23v2ZaxGrvHQAM1Zjw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -4.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 +1 I consider such restriction for compound types as quite fundamental, handli= ng messages without such restriction can be extremely expensive. Yuri Inglikov -----Original Message----- From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] Sent: Monday, September 24, 2007 3:15 PM To: ima@ietf.org Subject: [EAI] Re: ISSUE utf8 meaage/global Charles Lindsey wrote: > I reiterate my objection to this breach of the "EXPRESSLY FORBIDDEN" > rule in RFC 2045 +1 _______________________________________________ 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 Sep 25 01:21:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia2qz-0001QC-VY; Tue, 25 Sep 2007 01:21:01 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ia2qy-0001Py-MO for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 01:21:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia2qy-0001Pq-99 for ima@ietf.org; Tue, 25 Sep 2007 01:21:00 -0400 Received: from mail1.exchange.microsoft.com ([131.107.1.17] helo=mail.exchange.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia2qx-0002sT-MN for ima@ietf.org; Tue, 25 Sep 2007 01:20:59 -0400 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server (TLS) id 8.1.192.0; Mon, 24 Sep 2007 22:20:59 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.8]) by df-bhd-02.exchange.corp.microsoft.com ([157.54.71.155]) with mapi; Mon, 24 Sep 2007 22:20:58 -0700 From: Yuri Inglikov To: "ima@ietf.org" Date: Mon, 24 Sep 2007 22:20:57 -0700 Subject: [EAI] EDITORIAL: headers Thread-Topic: [EAI] EDITORIAL: headers Thread-Index: Acf/M9qRzrZ807nhTACiq92Itmbuow== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 X-BeenThere: ima@ietf.org 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="===============2088882228==" Errors-To: ima-bounces@ietf.org --===============2088882228== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E1D42DFE30883B488A5BEFC1801FA2DCAD36D760D7DFGRTDANEMSGe_" --_000_E1D42DFE30883B488A5BEFC1801FA2DCAD36D760D7DFGRTDANEMSGe_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable 4.3. Syntax extensions to RFC 2822 syntax is extended on next chapter to allow UTF-8 characters on header fields. In fact it the ABNF for extended comes earlier in the same section,= not in a following chapter. 4.6. message/global Subtype name: utf8smtp Should be: Subtype name: global --_000_E1D42DFE30883B488A5BEFC1801FA2DCAD36D760D7DFGRTDANEMSGe_ Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable

4.3.=9A Syntax extensions to RFC 2822=

 

<utext> syntax is extended on next ch=
apter to allow UTF-8 characters
=9A=9A on <unstructured> header fields.

 

In fact it the ABNF for extended <utext> comes e= arlier in the same section, not in a following chapter.

 

=9A=9A=9A=9A=9A=9A=9A 4.6.=9A message/global

 

=9A=9A =9A=9A=9A=9A Subtype name:=9A utf8smtp
 

Should be:

 

=9A=9A =9A=9A=9A=9A Subtype name:=9A global

 

--_000_E1D42DFE30883B488A5BEFC1801FA2DCAD36D760D7DFGRTDANEMSGe_-- --===============2088882228== 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 --===============2088882228==-- From ima-bounces@ietf.org Tue Sep 25 03:49:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia5AA-0002Qo-6j; Tue, 25 Sep 2007 03:48:58 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ia5A8-0002Qh-Te for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 03:48:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia5A8-0002QY-Jf for ima@ietf.org; Tue, 25 Sep 2007 03:48:56 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia5A8-0006nG-6N for ima@ietf.org; Tue, 25 Sep 2007 03:48:56 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 76589259715; Tue, 25 Sep 2007 09:48:55 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28418-08; Tue, 25 Sep 2007 09:48:46 +0200 (CEST) Received: from htat43p-no.corp.google.com (scandic814.host.songnetworks.se [212.214.188.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id B78252596F2; Tue, 25 Sep 2007 09:48:46 +0200 (CEST) Date: Tue, 25 Sep 2007 09:45:09 +0200 From: Harald Tveit Alvestrand To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] ISSUE: smtpext-08 2.2 erroneous MUSTard Message-ID: In-Reply-To: References: 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: 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 --On 24. september 2007 12:18 +0200 Frank Ellermann wrote: >| 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 message which contains internationalized mail headers >| [EAI-utf8header] at any level within its MIME structure. > > It MUST NOT transmit a message with an I18N header. As soon as that's > clear the object is by definition a message/rfc822, and its internal > MIME structure isn't the business of relaying MTAs or this I-D. Technical disagreement. If I forward a Message/Global, without a C-T-E, and using UTF-8 characters in the headers, the message containing the forwarded message is a Message/Global, not a message/rfc822, no matter what I put into the headers of the outermost message. If there is a C-T-E on the message/global, the message is (as far as I can see, and if the current resolution on extending MIME is accepted) a message/rfc822. But the issue is real, and will be tracked; I'm still not sure whether it is the same issue number as Charles' protest against the WG decision on relaxing the restriction in MIME or not. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 25 05:17:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia6XB-0003Qy-Hn; Tue, 25 Sep 2007 05:16:49 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ia6XA-0003Qs-MZ for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 05:16:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia6XA-0003Fs-9z for ima@ietf.org; Tue, 25 Sep 2007 05:16:48 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ia6X6-0001OC-4s for ima@ietf.org; Tue, 25 Sep 2007 05:16:45 -0400 Received: (eyou send program); Tue, 25 Sep 2007 17:16:39 +0800 Message-ID: <390711799.24415@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 25 Sep 2007 17:16:39 +0800 Message-ID: <060d01c7ff54$c4e312a0$21db6a9c@yaojk> From: "YAO Jiankang" To: Date: Tue, 25 Sep 2007 17:16:30 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 4.3 (++++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [EAI] about reference to RFC1869 X-BeenThere: ima@ietf.org 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="===============1648036382==" Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --===============1648036382== Content-Type: multipart/alternative; boundary="----=_NextPart_000_060A_01C7FF97.D0828DF0" This is a multi-part message in MIME format. ------=_NextPart_000_060A_01C7FF97.D0828DF0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpJIHJlbWVtYmVyIHRoYXQgdGhpcyBxdWVzdGlvbiBpcyBkaXNjdXNzZWQgQXByaWwgMDcsIDIw MDYgMTA6NTkgUE0uDQpiZWxvdyBpcyBzb21lIGFyZ3VtZW50cyBmcm9tIEpvaG4uDQppZiBwb3Nz aWJsZSwgd2UgcmVmZXJlbmNlIHRvIGJvdGggUkZDIDE4NjkgYW5kIDI4MjEgZm9yIG1vcmUgY2xl YXIgaW5mb3JtYXRpb24/DQogDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4uLi4NCj4+ICogU2VjdGlvbiAxLjE6IFJGQyAx ODY5IGlzIG9ic29sZXRlLCBjdXJyZW50IGlzIDI4MjENCj4gDQo+IHdpbGwgdXBkYXRlIGl0IGFj Y29yZGluZyB0byB5b3VyIGNvbW1lbnRzLg0KDQpQbGVhc2UgYmUgY2FyZWZ1bCBhYm91dCBjb250 ZXh0IGhlcmUuICBNeSByZWNvbGxlY3Rpb24gaXMgdGhhdA0KMTg2OSB3YXMgcmVmZXJlbmNlZCBp biB0aGUgZG9jdW1lbnQgeW91IGRyZXcgZnJvbSBpbiBjcmVhdGluZw0KdGhlIFNNVFAgZXh0ZW5z aW9uIGRyYWZ0IGJlY2F1c2UgaXQgY29udGFpbnMgYSBjZXJ0YWluIGFtb3VudCBvZg0KcmF0aW9u YWxlIGFuZCBleHBsYW5hdGlvbiB0aGF0IGlzIG5vdCBwcmVzZW50IGluIDI4MjEuICAgS25vd2lu Zw0KdGhhdCAyODIxIG9ic29sZXRlcyAxODY5IGZvciBzdGFuZGFyZHMtcmVmZXJlbmNlIHB1cnBv c2VzIGRvZXMNCm5vdCBpbXBseSB0aGF0IDI4MjEgY29udGFpbnMgYWxsIG9mIHRoZSBzYW1lIHRl eHQgYW5kDQpleHBsYW5hdGlvbnMgdGhhdCAxODY5IGRvZXMuICAgUGxlYXNlIG5vdGUgdGhhdCBJ IGFtIF9ub3RfDQphc2tpbmcgeW91IHRvIGF2b2lkIG1ha2luZyB0aGlzIGNoYW5nZSwgb25seSB0 aGF0IHlvdSBkbyB0aGUNCndvcmsgdG8gZmlndXJlIG91dCB3aGF0IHRoZSByZWZlcmVuY2UgaXMg cG9pbnRpbmcgdG8gYW5kLCBvbg0KdGhhdCBiYXNpcywgZGVjaWRlIHdoZXRoZXIgdGhlIGNoYW5n ZSBpcyBhcHByb3ByaWF0ZS4gTXkgZ3Vlc3MsDQp3aXRob3V0IHJlcmVhZGluZyB0aGUgdHdvLCBp cyB0aGF0IGl0IG1pZ2h0IGJlIGJldHRlciB0bw0KcmVmZXJlbmNlIGJvdGggZG9jdW1lbnRzIHJh dGhlciB0aGFuIHNpbXBseSBkcm9wcGluZyB0aGUgMTg2OQ0KcmVmZXJlbmNlIGluIGZhdm9yIG9m IHRoZSAyODIxIG9uZS4= ------=_NextPart_000_060A_01C7FF97.D0828DF0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjMxNTciIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNjY2U4Y2Y+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXpl PTI+SSByZW1lbWJlciB0aGF0IHRoaXMgcXVlc3Rpb24gaXMgZGlzY3Vzc2VkIDwvRk9OVD48Rk9O VCANCnNpemU9Mz5BcHJpbCAwNywgMjAwNiAxMDo1OSBQTS48L0ZPTlQ+PC9ESVY+DQo8RElWPmJl bG93IGlzIHNvbWUgYXJndW1lbnRzIGZyb20gSm9obi48L0RJVj4NCjxESVY+aWYgcG9zc2libGUs IHdlIHJlZmVyZW5jZSB0byBib3RoIFJGQyAxODY5IGFuZCAyODIxIGZvciBtb3JlIGNsZWFyIA0K aW5mb3JtYXRpb24/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCANCnNpemU9 Mj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08L0ZPTlQ+PC9ESVY+DQo8RElWPiZndDsuLi48QlI+Jmd0OyZndDsgKiBTZWN0aW9u IDEuMTogUkZDIDE4NjkgaXMgb2Jzb2xldGUsIGN1cnJlbnQgaXMgDQoyODIxPEJSPiZndDsgPEJS PiZndDsgd2lsbCB1cGRhdGUgaXQgYWNjb3JkaW5nIHRvIHlvdXIgY29tbWVudHMuPEJSPjxCUj5Q bGVhc2UgDQpiZSBjYXJlZnVsIGFib3V0IGNvbnRleHQgaGVyZS4mbmJzcDsgTXkgcmVjb2xsZWN0 aW9uIGlzIHRoYXQ8QlI+MTg2OSB3YXMgDQpyZWZlcmVuY2VkIGluIHRoZSBkb2N1bWVudCB5b3Ug ZHJldyBmcm9tIGluIGNyZWF0aW5nPEJSPnRoZSBTTVRQIGV4dGVuc2lvbiBkcmFmdCANCmJlY2F1 c2UgaXQgY29udGFpbnMgYSBjZXJ0YWluIGFtb3VudCBvZjxCUj5yYXRpb25hbGUgYW5kIGV4cGxh bmF0aW9uIHRoYXQgaXMgbm90IA0KcHJlc2VudCBpbiAyODIxLiZuYnNwOyZuYnNwOyBLbm93aW5n PEJSPnRoYXQgMjgyMSBvYnNvbGV0ZXMgMTg2OSBmb3IgDQpzdGFuZGFyZHMtcmVmZXJlbmNlIHB1 cnBvc2VzIGRvZXM8QlI+bm90IGltcGx5IHRoYXQgMjgyMSBjb250YWlucyBhbGwgb2YgdGhlIA0K c2FtZSB0ZXh0IGFuZDxCUj5leHBsYW5hdGlvbnMgdGhhdCAxODY5IGRvZXMuJm5ic3A7Jm5ic3A7 IFBsZWFzZSBub3RlIHRoYXQgSSBhbSANCl9ub3RfPEJSPmFza2luZyB5b3UgdG8gYXZvaWQgbWFr aW5nIHRoaXMgY2hhbmdlLCBvbmx5IHRoYXQgeW91IGRvIHRoZTxCUj53b3JrIHRvIA0KZmlndXJl IG91dCB3aGF0IHRoZSByZWZlcmVuY2UgaXMgcG9pbnRpbmcgdG8gYW5kLCBvbjxCUj50aGF0IGJh c2lzLCBkZWNpZGUgDQp3aGV0aGVyIHRoZSBjaGFuZ2UgaXMgYXBwcm9wcmlhdGUuIE15IGd1ZXNz LDxCUj53aXRob3V0IHJlcmVhZGluZyB0aGUgdHdvLCBpcyANCnRoYXQgaXQgbWlnaHQgYmUgYmV0 dGVyIHRvPEJSPnJlZmVyZW5jZSBib3RoIGRvY3VtZW50cyByYXRoZXIgdGhhbiBzaW1wbHkgDQpk cm9wcGluZyB0aGUgMTg2OTxCUj5yZWZlcmVuY2UgaW4gZmF2b3Igb2YgdGhlIDI4MjEgb25lLjwv RElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_060A_01C7FF97.D0828DF0-- --===============1648036382== 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 --===============1648036382==-- From ima-bounces@ietf.org Tue Sep 25 06:49:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia7xg-0004u8-Lg; Tue, 25 Sep 2007 06:48:16 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ia7xf-0004lD-NE for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 06:48:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia7xf-0004ky-Cx for ima@ietf.org; Tue, 25 Sep 2007 06:48:15 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia7xf-0003us-0H for ima@ietf.org; Tue, 25 Sep 2007 06:48:15 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ia7xY-00038B-5g for ima@ietf.org; Tue, 25 Sep 2007 10:48:08 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 10:48:08 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 10:48:08 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 25 Sep 2007 12:45:56 +0200 Lines: 28 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [EAI] ISSUE: dsn HEXPOINT X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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,=20 I've now read about the \x{...} notation, and I'm not sure that it's clear what \x{5C} and \x{80} up to \x{FF} actually mean. The example on the perluniintro page is: | perl -e 'print "\x{DF}\n", "\x{0100}\x{DF}\n"' | produces a fairly useless mixture of native bytes and | UTF-8, as well as a warning Apparently this construct enumerates octets in the local charset up to \x{FF}, switching to Unicode points only for \x{100} up to \x{10FFFF}. That's some kind of backward compatibility feature, it can't be removed by decree in an RFC, perl users would expect that this notation works as is for them. If that's correct this notation is also unsuited for http://tools.ietf.org/html/draft-klensin-unicode-escapes Minor point, the perl manual page apparently doesn't say that leading zeros are "verboten", but the ABNF in the I-D specifies this. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 25 07:21:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8Tp-00042m-7O; Tue, 25 Sep 2007 07:21:29 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ia8To-00041w-5S for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 07:21:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8Tn-0003xP-BG for ima@ietf.org; Tue, 25 Sep 2007 07:21:27 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia8Th-0002KA-Th for ima@ietf.org; Tue, 25 Sep 2007 07:21:27 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 25 Sep 2007 12:21:09 +0100 Message-ID: <46F8EF43.7060001@isode.com> Date: Tue, 25 Sep 2007 12:21:39 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: YAO Jiankang Subject: Re: [EAI] about reference to RFC1869 References: <390711799.24415@cnnic.cn> In-Reply-To: <390711799.24415@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org YAO Jiankang wrote: > I remember that this question is discussed April 07, 2006 10:59 PM. > below is some arguments from John. > if possible, we reference to both RFC 1869 and 2821 for more clear > information? > --------------------------------------------------------------- > >... > >> * Section 1.1: RFC 1869 is obsolete, current is 2821 > > > > will update it according to your comments. > > Please be careful about context here. My recollection is that > 1869 was referenced in the document you drew from in creating > the SMTP extension draft because it contains a certain amount of > rationale and explanation that is not present in 2821. Knowing > that 2821 obsoletes 1869 for standards-reference purposes does > not imply that 2821 contains all of the same text and > explanations that 1869 does. Please note that I am _not_ > asking you to avoid making this change, only that you do the > work to figure out what the reference is pointing to and, on > that basis, decide whether the change is appropriate. My guess, > without rereading the two, is that it might be better to > reference both documents rather than simply dropping the 1869 > reference in favor of the 2821 one. I think referencing both would be the best thing. Make RFC 2821 a normative refence and also mention RFC 1869 as an informative reference. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 25 07:36:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8hv-0005QF-Ps; Tue, 25 Sep 2007 07:36:03 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ia8ht-0005OO-HV for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 07:36:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8ht-0005OF-79 for ima@ietf.org; Tue, 25 Sep 2007 07:36:01 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia8hs-0005JV-QD for ima@ietf.org; Tue, 25 Sep 2007 07:36:01 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ia8hn-0008Aw-AD for ima@ietf.org; Tue, 25 Sep 2007 11:35:55 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 11:35:55 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 11:35:55 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 25 Sep 2007 13:32:53 +0200 Lines: 39 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [EAI] EDITORIAL: dsn-03 (4..8) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org 4: | The third type, used for header return, is message/global-headers | and contains only the UTF-8 headers of a message (all lines prior | to the first blank line in a UTF8SMTP message).=20 s/headers/header/ or s/headers/header fields/ for the terminology police. | Note that [I-D.ietf-eai-utf8headers] relaxed restriction from | MIME [RFC2046] regarding use of Content-Transfer-Encoding in new | "message" subtypes. Also note that does not contain a single occurence of MIME. 5: | When generating a MDN for a UTF-8 header message, content or | header return is the same as for DSNs.=20 Hard to read, do you mean something like this: "When generating a MDN for a UTF-8 header message, the returned content or header (message/global or message/global-headers) uses the same format as for DSNs." | The MDN specification also defines the Original-Recipient | header field OT: That's not yet listed in the message header field registry. I-D.lilly-legacy-fields is in state ISR-AUTH for some years (?) on http://rfc-editor.org/queue.html Last nit, appendix B should be removed before an IETF Last Call. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 25 07:37:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8iz-000247-PV; Tue, 25 Sep 2007 07:37:09 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ia8iz-00021A-2T for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 07:37:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8iy-000211-IV for ima@ietf.org; Tue, 25 Sep 2007 07:37:08 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia8iy-0005Kb-1g for ima@ietf.org; Tue, 25 Sep 2007 07:37:08 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3^clerew$man*ac^uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.256) id 46f8f2e1.147d6.48 for ima@ietf.org; Tue, 25 Sep 2007 12:37:05 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8PBb4RQ022982 for ; Tue, 25 Sep 2007 12:37:05 +0100 (BST) To: IMA Subject: Re: [EAI] Re: REVIEW: draft-ietf-eai-smtpext-08.txt References: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> Message-ID: Date: Tue, 25 Sep 2007 12:37:04 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 25 Sep 2007 00:10:34 +0100, Frank Ellermann wrote: > John C Klensin wrote: > >> Charles Lindsey wrote: > >>> If an MTA returns a 2xx response, then the most it is >>> claiming is "I think I know what to do with this message, >>> so I am accepting (allowing you to send) it; but the >>> next man in line might think otherwise, in which case >>> I promise to send a bounce (DSN) up the Return Path". > >> Yes. > > No :-) The DSN has to go to the "originator as indicated > in the Return Path", therefore the MTA has to be confident > that the Return Path in fact indicates the originator. So far as an MTA is concerned, the 'originator' is what was in the SMTP MAIL FROM. That later gets copied into a Return-Path header as part of the final delivery process. So when, on this list, we speak of a "Return-Path", we mean either the MAIL FROM address or whatever is in the Return-Path header according to the stage of processing we are talking about. But editors of drafts need to be careful to state the requirements more precisely, of course. So I think what I informally wrote, and John agreed to, is correct. -- 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 Sep 25 07:46:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8rk-000612-SN; Tue, 25 Sep 2007 07:46:12 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ia8rk-00060f-8q for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 07:46:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia8rj-00060N-UD for ima@ietf.org; Tue, 25 Sep 2007 07:46:11 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ia8rj-0005VN-E5 for ima@ietf.org; Tue, 25 Sep 2007 07:46:11 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3#clerew#man*ac$uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.256) id 46f8f502.4e0e.1a8 for ima@ietf.org; Tue, 25 Sep 2007 12:46:10 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8PBk9Zn023525 for ; Tue, 25 Sep 2007 12:46:10 +0100 (BST) To: IMA Subject: Re: [EAI] Re: ISSUE: smtpext-08 2.2 erroneous MUSTard References: Message-ID: Date: Tue, 25 Sep 2007 12:46:08 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Mon, 24 Sep 2007 22:28:04 +0100, Frank Ellermann wrote: > Charles Lindsey wrote: > >>> It MUST NOT transmit a message with an I18N header. As soon as that's >>> clear the object is by definition a message/rfc822, and its internal >>> MIME structure isn't the business of relaying MTAs or this I-D. > >> No, that is not enough. Suppose the message has all-ascii addresses >> throughout, and everything in the top-level header is pure ASCII, but >> suppose that the body is a multipart and one of the multiparts has a >> Content-Description written in Chinese using raw UTF-8. > > The wonders of 8BITMIME or even binary mail bodies aren't relevant > for the UTF8SMTP ESMTP extension, they're discussed elsewhere. > > Besides MIME 1.0 doesn't allow raw UTF-8 in Content-* header fields, > so who knows what that is you're talking about, maybe it's MIME 2.0. We had this discussion way back when we got rid of the Header-Type header. I disagreed with that, but the consensus was against me. So the situation now is that our documents extend what is allowed in MIME 1.0, but only for use within the UTF8SMTP universe. So when you want to pass stuff out of that universe you have to detect that these extensions have been used and downgrade (or reject) accordingly. That is what we all agreed some months ago, and actually it is not that hard to detect it since current MTAs already do similar tests when passing stuff into the Non-8BITMIME world. -- 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 Sep 25 08:54:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9vy-0008TD-Tg; Tue, 25 Sep 2007 08:54:38 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ia9vx-0008T7-UD for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 08:54:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ia9vx-0008St-KL for ima@ietf.org; Tue, 25 Sep 2007 08:54:37 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ia9vr-0004Y4-9W for ima@ietf.org; Tue, 25 Sep 2007 08:54:37 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ia9va-0002az-KP for ima@ietf.org; Tue, 25 Sep 2007 12:54:14 +0000 Received: from mail.st-michaelis.de ([217.86.170.58]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 12:54:14 +0000 Received: from nobody by mail.st-michaelis.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 12:54:14 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 25 Sep 2007 14:52:01 +0200 Lines: 62 Message-ID: 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: mail.st-michaelis.de X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [EAI] Re: ISSUE: smtpext-08 2.2 erroneous MUSTard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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: =20 > If I forward a Message/Global, without a C-T-E, and using UTF-8 > characters in the headers, the message containing the forwarded > message is a Message/Global, not a message/rfc822, no matter what > I put into the headers of the outermost message. I'd say your object is a message/rfc822 containing a message/global part, and it needs CTE: 8bit, e.g. | From: me@xn-e1afmkfd.xn--80akhbyknj4f | To: you@xn--fsqu00a.xn--0zwm56d | Date: Tue, 25 Sep 2007 09:45:09 +0200 | Subject: Loo what he said | MIME-Version: 1.0 | Content-Type: message/global | Content-Transfer-Encoding: 8bit | | From: he@xn--r8jz45g.xn--zckzah | To: she@xn--9n2bp8q.xn--9t4b11yi5a | Date: Mon, 24 Sep 2007 12:34:56 -0000 | Subject: =E4=F6=FC (pls consider this as UTF-8 example) | | Body of forwarded message/global (ASCII example) It's the same idea if this message/global is a part of a=20 multipart/message, just add the boundaries. Without the CTE: 8bit in the "outer" header you'd send binary=20 garbage, i.e. raw 8bit within a 7bit CTE. =20 > If there is a C-T-E on the message/global, the message is > (as far as I can see, and if the current resolution on=20 > extending MIME is accepted) a message/rfc822. Are you really talking about "forwarding" as sending the original message/global as part of a containing message ? The CTE of the parts determines what you can use as CTE of the "outer" container, if all parts are 7bit, QP, or B64, then the container can be 7bit. If at least one part is 8bit the container needs to be 8bit, unless you can replace all "inner" 8bit by say QP or B64. =20 I'd say that a message/* can't be B64 or QP, but that's another issue. Let's assume a message/global can be sent with CTE B64 or QP in the sending container. Then the content (header plus body) is pure ASCII, and the "outer" container is a perfect message/rfc822 ready to go to a 7bit MTA. In my example above replace "8bit" by "QP", and fix the example Subject to get QP-encoded umlauts. > I'm still not sure whether it is the same issue number > as Charles' protest against the WG decision on relaxing > the restriction in MIME or not. IMO it's not the "EXPRESSLY FORBIDDEN" issue: We could replace message/global 8bit by application/message 8bit in my example, and I'd still say that the complete object is a message/rfc822 containing "something". Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 25 09:12:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaADF-0000RI-PZ; Tue, 25 Sep 2007 09:12:29 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaADE-0000Q7-JC for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 09:12:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaADE-0000NH-9R for ima@ietf.org; Tue, 25 Sep 2007 09:12:28 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaAD1-0004wI-DD for ima@ietf.org; Tue, 25 Sep 2007 09:12:21 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3^clerew#man#ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.256) id 46f90909.1d11.45d for ima@ietf.org; Tue, 25 Sep 2007 14:11:37 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8PDBUXL028666 for ; Tue, 25 Sep 2007 14:11:32 +0100 (BST) To: IMA Subject: Re: [EAI] EDITORIAL: dsn References: <46F2AC4A.7090605@isode.com> <46F3A69D.1080803@isode.com> <039AFF3E32FA1046CC3D9B2C@p3.JCK.COM> Message-ID: Date: Tue, 25 Sep 2007 14:11:30 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <039AFF3E32FA1046CC3D9B2C@p3.JCK.COM> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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, 24 Sep 2007 16:42:09 +0100, John C Klensin wrote: > Charles, > > I'm confused about what you are asking for, but > > * Every server that can do 8BITMIME downgrading (and > that includes such popular ones as Sun and Sendmail), > does C-T-E remapping. This is also true of servers that > do BINARYMIME downgrading, but there may be fewer of > those. NO! That is not true, which is the whole point of my argument. Let us consider sendmail, with which I have some familiarity. I have examined the code, and what it does appears to be as follows: Essentially, it a two-pass process. As it receives stuff from the SMTP DATA command, it looks to see if a bit8 is set anywhere in the body, and sets a flag accordingly (later, if this flag is not present, it can bypass a lot of stuff). Then it places the message in its queue. On taking it out of the queue to send to some particular site, it observes whether that site supports 8BITMIME (and eventually will presumably detect UTF8SMTP likewise). So it the flag is set and 8BITMIME is not supported it enters a downgrading routine which first examines the Content-Type and distinguishes three cases: 1. multipart types; 2. message types; 3. all others. For "all others", obviously, it sets about changing the C-T-E to Q-P or Bas64 (after deciding which off these seems likely to be best). For "multipart types" is takes note of the 'boundary' string and goes looking for the various parts one-by-one, and calls itself recursively for each one. For "message types" it first checks for the special case message/rfc822, and proceeds to call itself recursively on the encapsulated message (which may cause individual parts of that encapsulated message to be re-encoded in Q-P of Base64). But in the case of message types other than message/rfc822 it simply leaves the content of the message alone; so if there is any bit8 present it simply gets sent as-is (that situation is just not supposed to happen with any message type, but as a strategy which will "probably work most of the time" it is probably a sensible thing to do). BUT, since it NEVER tries to change the encoding of such a message type, it never infringes that "EXPRESSLY FORBIDDEN" in RFC 2045. So you can't accuse iot of non-compliance in that regard. It is not easy to set up an experiment to verify this is what actually happens (you need to find or create a Non-8BITMIME MTA, and there are not many of them around). However, sendmail can also be configured to use LMTP for final delivery, so I did set up a Non-8BITMIME storage agent and configured sendmail to deliver to it by LMTP, and it behaved just as I have described above (well it is some months now since I did the experiment, so I do not remember the exact details of what I did). As for exim and qmail, it has been reported on this list that neither of them will downgrade anything at all, though both transmit the full 8bits onwards. Exim out of the box does not announce 8BITMIME, though it may be (and often is) configured to do so. Qmail always announces 8BITMIME, which is naughty but which DJB will stoutly defend. Between them, sendmail, exim and qmail cover quite a substantial slice of deployed MTAs. > > * Every delivery server (or IMAP/POP server/processor) > that converts content from C-T-E q-p or base64 to the > corresponding 8bit form (and there are many of those), > does C-T-E remapping. Yes, it may be that delivery agents regularly convert to Q-P or Base64 (and MUAs then upconvert it for display). But that is irrelevant to my argument, which is solely concerned as to whether such encodings will be applied by MTAs during transit. -- 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 Sep 25 10:05:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaB1s-0001du-W8; Tue, 25 Sep 2007 10:04:48 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaB1r-0001d0-U1 for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 10:04:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaB1r-0001cs-JQ for ima@ietf.org; Tue, 25 Sep 2007 10:04:47 -0400 Received: from ns1.qubic.net ([208.185.248.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaB1r-0000UI-7I for ima@ietf.org; Tue, 25 Sep 2007 10:04:47 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Alpha0/8.14.2.Alpha0) with ESMTP id l8PE42TK023719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Sep 2007 07:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1190729073; x=1190815473; bh=OrUBcYsImnHkirqaj1mnumwvVKSupy0S/ORi rpTEQZY=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:In-Reply-To:References:Mime-Version:Content-Type:Cc; b=L4R j3Aby954O59iKiXY2SzmnRYbbbT9dcX9hIEyE+n+VEQY9+SwJjtYjz9U4HmIEEVOC0s AwI+r2Efs+RV7AI+XYfJl097OBl2GonNXV9AeqIbh+LTjhxvfq0mtXKoEgu/sB2/baK 4LFdeYIWdL9xAhPqZgz88SBLEpLmmHG+1E= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=XhZ9resXU/BxM7F8HfEPXf6nMNxVFCuBpIuxSBF/wVVut+5+igEsPhU47kqU2MJg/ KUOrFgywJwKrPRFGCHE0Bv1L8FwdYo+KpNK251o0HF1JDCqm+yl5t39/Y2rzrYJWA9P nKUqHyk9j6YKxYEyH879TcZGtQRj1z5TnhVi7Oo= Message-Id: <6.2.5.6.2.20070925064208.030b5178@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 25 Sep 2007 06:51:24 -0700 To: ima@ietf.org From: SM Subject: Re: [EAI] ISSUE: smtpext-08 2.2 erroneous MUSTard In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 00:45 25-09-2007, Harald Tveit Alvestrand wrote: Technical disagreement. >If I forward a Message/Global, without a C-T-E, and using UTF-8 >characters in the headers, the message containing the forwarded >message is a Message/Global, not a message/rfc822, no matter what I >put into the headers of the outermost message. > >If there is a C-T-E on the message/global, the message is (as far as >I can see, and if the current resolution on extending MIME is >accepted) a message/rfc822. No, it is still not a message/rfc822 except for the purposes of this experiment. Any extension or relaxation of MIME requirements apply to EAI only. Other transport mechanisms may treat a message/rfc822 as defined in Section 6.4 of RFC 2045. Regards, -sm _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 25 10:34:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaBUM-0004f2-6h; Tue, 25 Sep 2007 10:34:14 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaBUL-0004ew-Rg for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 10:34:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaBUL-0004em-IB for ima@ietf.org; Tue, 25 Sep 2007 10:34:13 -0400 Received: from ns1.qubic.net ([208.185.248.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaBUF-00072Z-AF for ima@ietf.org; Tue, 25 Sep 2007 10:34:13 -0400 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Alpha0/8.14.2.Alpha0) with ESMTP id l8PEXP2E024813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Sep 2007 07:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1190730827; x=1190817227; bh=6T+3EIFX2G+7nY9lpTL6Bqah6kRWUrj78W73 zNEty6w=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:In-Reply-To:References:Mime-Version:Content-Type:Cc; b=sR+ ndMI3xFbB/6lET8wlZvgI6/+uwpjBf6tWZB9i76v4Lyy+U48twYQvH3b/A6bPcVWsts hWIgsJCdKFjCab+M03lZ3SLcRKtIJwXJab2m6BZ8XgaK37GWJvke48bOtn2ZGrICha7 vT33tL5Caj+JqWCD79Yi/9HbN309yW9bkk= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=KwSlehjpBnAuXBGk6A/2YAkQk07c5OGsQnzCjdE+d1RP2+Sg7mFTDK3IoZvsUjArc qrmjikCqz00V/uE1yAjFvdiO9c4c6/PCz+cT/6nnLai1TOUry/V3lQwtnlNcTJnKjui Tc0eVnHx3rQokNU/maV2UwyaJo9j4VT3IcczWco= Message-Id: <6.2.5.6.2.20070925070048.030be9a0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 25 Sep 2007 07:31:39 -0700 To: IMA From: SM Subject: Re: [EAI] Re: ISSUE: smtpext-08 2.2 erroneous MUSTard In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org At 04:46 25-09-2007, Charles Lindsey wrote: >So the situation now is that our documents extend what is allowed in MIME >1.0, but only for use within the UTF8SMTP universe. So when you want to >pass stuff out of that universe you have to detect that these extensions >have been used and downgrade (or reject) accordingly. That is what we all >agreed some months ago, and actually it is not that hard to detect it >since current MTAs already do similar tests when passing stuff into the >Non-8BITMIME world. What we have is MIME 2.0 without calling it that. The changes aren't restricted to 8-bit content only. The MIME changes will be passed to the non-UTF8SMTP universe and may affects parsers. Regards, -sm _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 25 11:26:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCIZ-0006us-J9; Tue, 25 Sep 2007 11:26:07 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaCIY-0006qb-BX for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 11:26:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCIX-0006lC-SG for ima@ietf.org; Tue, 25 Sep 2007 11:26:06 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IaCIU-0002cy-QI for ima@ietf.org; Tue, 25 Sep 2007 11:26:03 -0400 Received: (eyou send program); Tue, 25 Sep 2007 23:25:57 +0800 Message-ID: <390733957.09706@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (159.226.7.245) by 159.226.7.146 with SMTP; Tue, 25 Sep 2007 23:25:57 +0800 Message-ID: <08bf01c7ff88$5ac0ac00$21db6a9c@yaojk> From: "YAO Jiankang" To: Date: Tue, 25 Sep 2007 23:25:46 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 4.3 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [EAI] about section 3 and 4 of smtpext X-BeenThere: ima@ietf.org 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="===============0985857684==" Errors-To: ima-bounces@ietf.org This is a multi-part message in MIME format. --===============0985857684== Content-Type: multipart/alternative; boundary="----=_NextPart_000_08BC_01C7FFCB.66B39E80" This is a multi-part message in MIME format. ------=_NextPart_000_08BC_01C7FFCB.66B39E80 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpiYXNlZCBvbiByZWNlbnQgZGlzY3Vzc2lvbnMsIGl0IHNlZW1zIHRoYXQgd2Ugc2hvdWxkIGRy b3AgU2VjdGlvbnMgMy4zIGFuZCBzZWN0aW9uIDQuDQoNCkl0IHNlZW1zIHRoYXQgaXQgaXMgc3Rp bGwgcmVhc29uYWJsZSB0byBrZWVwIFNlY3Rpb25zIDMuMSAoTE1UUCkgYW5kIDMuMiAoRFNOcyku DQoNCg0KWWFvIEppYW5rYW5nDQpDTk5JQw0K ------=_NextPart_000_08BC_01C7FFCB.66B39E80 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjMxNTciIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNjY2U4Y2Y+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5iYXNlZCBvbiByZWNlbnQgZGlzY3Vzc2lvbnMsIGl0IHNl ZW1zIHRoYXQgd2Ugc2hvdWxkIA0KZHJvcCZuYnNwO1NlY3Rpb25zIDMuMyZuYnNwO2FuZCBzZWN0 aW9uIDQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+SXQgc2VlbXMgdGhhdCBpdCBpcyBzdGlsbCByZWFzb25hYmxl IHRvIGtlZXAgU2VjdGlvbnMgMy4xIA0KKExNVFApIGFuZCAzLjIgKERTTnMpLjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6 ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPllhbyBKaWFua2FuZzwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkNOTklDPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_08BC_01C7FFCB.66B39E80-- --===============0985857684== 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 --===============0985857684==-- From ima-bounces@ietf.org Tue Sep 25 11:34:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCQV-0008Q3-3L; Tue, 25 Sep 2007 11:34:19 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaCQU-0008OB-DL for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 11:34:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCQU-0008O0-3f for ima@ietf.org; Tue, 25 Sep 2007 11:34:18 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaCQO-00005x-Q4 for ima@ietf.org; Tue, 25 Sep 2007 11:34:18 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IaCQO-0000HH-2A; Tue, 25 Sep 2007 11:34:12 -0400 Date: Tue, 25 Sep 2007 11:34:11 -0400 From: John C Klensin To: YAO Jiankang , ima@ietf.org Subject: Re: [EAI] about section 3 and 4 of smtpext Message-ID: <9D1B57D2208353F17CB4ADFF@p3.JCK.COM> In-Reply-To: <390733957.09706@cnnic.cn>, <08bf01c7ff88$5ac0ac00$21db6a9c@yaojk> References: <390733957.09706@cnnic.cn>, <08bf01c7ff88$5ac0ac00$21db6a9c@yaojk> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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, 25 September, 2007 23:25 +0800 YAO Jiankang wrote: > based on recent discussions, it seems that we should drop > Sections 3.3 and section 4. > > It seems that it is still reasonable to keep Sections 3.1 > (LMTP) and 3.2 (DSNs). Not, in my opinion, without some significant rewriting. Moving things to an appendix that starts, e.g., "this appendix updates and provides additional information that should have been in RFC 4952" would be ok, but smptext should not contain arbitrary material that should be in Framework. To do so creates reading loops and risks creating general confusion about which one is authoritative. Just my opinion, of course. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 25 11:57:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaClZ-0001RX-TS; Tue, 25 Sep 2007 11:56:05 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaClZ-0001RS-Cq for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 11:56:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaClZ-0001RK-3C for ima@ietf.org; Tue, 25 Sep 2007 11:56:05 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaClX-00010h-Ox for ima@ietf.org; Tue, 25 Sep 2007 11:56:05 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IaClW-0000gv-CR; Tue, 25 Sep 2007 11:56:02 -0400 Date: Tue, 25 Sep 2007 11:56:01 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] ISSUE: dsn HEXPOINT Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --On Tuesday, 25 September, 2007 12:45 +0200 Frank Ellermann wrote: > Hi, > > I've now read > about the \x{...} notation, and I'm not sure that it's > clear what \x{5C} and \x{80} up to \x{FF} actually mean. > > The example on the perluniintro page is: > > | perl -e 'print "\x{DF}\n", "\x{0100}\x{DF}\n"' > | produces a fairly useless mixture of native bytes and > | UTF-8, as well as a warning > > Apparently this construct enumerates octets in the local > charset up to \x{FF}, switching to Unicode points only > for \x{100} up to \x{10FFFF}. As I read this, it is all tied up with the environment, the presence of absence of a "PerlIO layer" and the presence of absence of an "encoding" pragma (see http://perldoc.perl.org/perluniintro.html#Legacy-Encodings). The "legacy" material seems to say that, if the encoding is specified, Perl will perform legacy-> Unicode conversion. I would hope that something like use encoding 'UTF-8' ; would cause all of the right things to happen in Perl, but we don't have that construction in DSN. And I agree that the description in the Perl manual is somewhere between ambiguous and utterly confusing. > That's some kind of backward compatibility feature, it > can't be removed by decree in an RFC, perl users would > expect that this notation works as is for them. > > If that's correct this notation is also unsuited for > http://tools.ietf.org/html/draft-klensin-unicode-escapes I have now fixed the next version of that draft, which I'm working on this week anyway, to note this problem, refer to the Perl document, and issue a general "there be dragons" comment. > Minor point, the perl manual page apparently doesn't > say that leading zeros are "verboten", but the ABNF > in the I-D specifies this. That is the ABNF in "dsn", not the ABNF in "unicode-escapes", yes? The latter seems to be consistent with the Perl man page. But I think all of this suggests that DSN needs either a lot more specificity (possibly defining some reasonable and clear rules and describing them as Perl-like, rather than as Perl rules) or a different syntax entirely. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 25 12:05:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCuI-0001EV-6t; Tue, 25 Sep 2007 12:05:06 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaCuH-0001Dy-1J for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 12:05:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaCuG-0001AW-7N for ima@ietf.org; Tue, 25 Sep 2007 12:05:04 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaCu9-0001H7-RQ for ima@ietf.org; Tue, 25 Sep 2007 12:05:04 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IaCjD-0006kj-OX for ima@ietf.org; Tue, 25 Sep 2007 15:53:39 +0000 Received: from 1cust196.tnt1.hbg2.deu.da.uu.net ([149.225.10.196]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 15:53:39 +0000 Received: from nobody by 1cust196.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 15:53:39 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 25 Sep 2007 17:37:22 +0200 Organization: http://purl.net/xyzzy Lines: 54 Message-ID: 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: 1cust196.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [EAI] Re: ISSUE: smtpext-08 2.2 erroneous MUSTard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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: =20 > We had this discussion way back when we got rid of the Header-Type > header. I disagreed with that, but the consensus was against me. Yes, I recall that decision. IIRC your idea was *NOT* to emulate a kind of "MIME-Version: 2.0", it was something else. Maybe I missed that it's in essence the same idea as "MIME-Version: 2.0", affecting not only the "outer" header, but also all "inner" MIME Content-* headers. If the latter is the case we'd still disagree about the purpose of this stage of the EAI experiment. I dare not screw with MIME 1.0 unless Ned, Keith, or the IAB say that this could be fun ;-) > So the situation now is that our documents extend what is allowed > in MIME 1.0, but only for use within the UTF8SMTP universe. IMO there's no such thing as an "UTF8SMTP sandbox". As soon as the message/global type exists, it can be put into multipart/message or similar MIME containers everywhere, and these containers can be transported with any protocol that can transport MIME 1.0 messages. Http, nntp, and 8bit smtp can handle a Content-Type: message/global in their header introducing a body with a raw message/global. Only 7bit smtp can't do this, because it can't transport raw 8bit data in the body. I'm too lazy to look, did http register its own message/http MIME type, with charset Latin-1 for its header field bodies ? I guess that exists for Web-by-mail access, and it should be no big problem for 8bit smtp. =20 Let's say I've got a "message/http" containing an ASCII text/html document in the body. And let's say the "message/http" header contains some raw Latin-1 characters. Now I want to forward this object within a message/rfc822 over 7bit smtp. How does this work, does message/http permit CTE B64, in spite of the "expressly forbidden" rule ? Or is there an application/http type for this purpose ? This can't be a "mission impossible", or can it ? One thing is sure, the complete object transported by smtp is then still a message/rfc822, no matter if it contains message/global, message/http, or application/foo parts. And FWIW it's also still MIME 1.0 without experimental updates of RFC 2045. Frank =20 =20 =20 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 25 13:51:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaEZ6-0000K0-QA; Tue, 25 Sep 2007 13:51:20 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaEZ5-0000Jf-5r for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 13:51:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaEZ4-0000HW-Qq for ima@ietf.org; Tue, 25 Sep 2007 13:51:18 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaEYz-0007GA-T6 for ima@ietf.org; Tue, 25 Sep 2007 13:51:14 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IaEYi-0000wF-4v for ima@ietf.org; Tue, 25 Sep 2007 17:50:56 +0000 Received: from 1cust196.tnt1.hbg2.deu.da.uu.net ([149.225.10.196]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 17:50:56 +0000 Received: from nobody by 1cust196.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 17:50:56 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 25 Sep 2007 19:50:25 +0200 Organization: http://purl.net/xyzzy Lines: 183 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust196.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Subject: [EAI] REVIEW: utf8headers-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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.2: | This document updates section 6.4 of RFC 2045. Discussed in a separate issue. EAI should need no "experimental update" of MIME. If it turns out that the RFC 2045 restriction is in practice obsolete for other purposes outside of EAI, we might need a "real update" of MIME. | This document also updates [RFC2822] and MIME Ditto, an "experimental update" of RFC 2822 is okay, but touching MIME (excl. the separate issue above) is IMO unnecessary and too dangerous. 4.1: | [Note in draft: Whether normalizing is needed or not | will be place in here.] Please create a real note about this design decision, and that it might be revised when the experiment is evaluated. 4.2: | This specification does not prohibit other | content-transfer-encodings on nested body parts, so | double encoding might happen, but is expected to be | rarely seen in practice. Quite so. And if we'd use say an application/message type for 7bit transport of a message/global, it would be still a kind of double-encoding for parts "within" the B64 or QP encoded message/global. There's no way around this. It's only a question of "play it save and follow the rules using an application subtype" vs. "the rules are pointless for this application, because the result is always QP or B64". BTW, if we follow the rules we could also decree which encoding should be always used, B64 might be robuster, QP is nicer for humans, but QP of QP would be horrible. | To be able to use UTF-8 characters in MIME header field | paramerer values, the syntax of , as defined in | [RFC2045], is extended as | | value =3D/ utf8-quoted-string Don't. s/paramerer/parameter/, but better leave MIME alone and let's experiment with _addresses_ and 2822 header fields, not with Content-*. 4.3: | utf8-quoted-pair =3D ("\" utf8-text) / obs-qp Oops, what's the idea here ? Why not keep quoted-pair as is ? You'd get (hex. example for \u+0080) 5C C2 80, why not simply use C2 80 without backslash ? | To able to use UTF-8 on Content-Description header field | on [RFC2045], following syntax is used | | description =3D "Content-Description:" unstructured CRLF "To allow the use of UTF-8 in" ... "header fields specified in RFC2045, the following syntax is used:" (or similar). Of course I propose to leave all MIME 1.0 Content-* alone. | syntax is extended on next chapter to allow UTF-8 | characters on header fields. "The syntax is extended to allow UTF-8 characters in header fields, for details see the following chapter" (or similar) 4.4: | alt-address =3D 1*FWS "<" addr-spec ">" Don't get carried away, FWS will do, you don't want more than one FWS in a row... ;-) | Below list a few possible representation as example. "Some examples of representations:" (or similar) 4.6: s/UTF-8 header values/UTF-8 in header field bodies/ (?) | o it contains UTF-8 header values as specified in this document, or | o it contains UTF-8 values in the headers fields of body parts. Remove the second clause and leave MIME part headers alone. | The second type, used for content return, is message/global That's no second type, it's the same thing transported a MIME part of a DSN. We're always talking about the one and only message/global here, the derived types are discussed in the DSN I-D. | Subtype name: utf8smtp s/utf8smtp/global/ (JFTR, already noted by Charles and others) | Encoding considerations: The 8-bit or binary content-transfer- | encoding MUST be used unless this media type is sent over a | 7-bit only transport. No, say "unless the message happens to be a 7bit message/rfc822". That's clumsy, and related to the CTE issue. If we stick to the rules without "experimental update" we'd get: "An 8-bit or binary content-transfer-encoding MUST be used when the message contains non-ASCII UTF-8 characters in its header, otherwise the encoding considerations for a message/rfc822 are applicable." 5: Remove the first paragraph and remove the 5.1 title, i.e. keep the second paragraph of 5 as new first paragraph, and add the text in 5.1 as new second paragraph. 7: The message/global template in chapter 4.6 are actually "IANA considerations". There has to be a review on the MIME type list before IETF Last Call (ditto for the derived DSN types). 10.2: At least the RFC 3501 reference isn't used anywhere. Frank=20 . a we Without this oddity=20 =20 and u100 Why not simply keep those ugly=20 r =20 =20 l(wIf that's tagged as say application/message it can't cause havoc for agents believing in RFC 2045. =20 .still include suchhide some kind ofor these require =20 =20 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 25 14:05:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaEn5-0007lg-9D; Tue, 25 Sep 2007 14:05:47 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaEn4-0007jQ-5s for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 14:05:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaEn3-0007ge-QS for ima@ietf.org; Tue, 25 Sep 2007 14:05:45 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaEn3-000854-Dw for ima@ietf.org; Tue, 25 Sep 2007 14:05:45 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IaEme-0002Jx-Af for ima@ietf.org; Tue, 25 Sep 2007 18:05:20 +0000 Received: from 1cust196.tnt1.hbg2.deu.da.uu.net ([149.225.10.196]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 18:05:20 +0000 Received: from nobody by 1cust196.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 18:05:20 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 25 Sep 2007 20:04:51 +0200 Organization: http://purl.net/xyzzy Lines: 28 Message-ID: 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: 1cust196.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [EAI] Re: ISSUE: dsn HEXPOINT X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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: =20 >> If that's correct this notation is also unsuited for >> http://tools.ietf.org/html/draft-klensin-unicode-escapes =20 > I have now fixed the next version of that draft, which I'm > working on this week anyway, to note this problem, refer to the > Perl document, and issue a general "there be dragons" comment. Thanks. I just met the "LWSP-dragon" again, it tried to hide itself as 1*FWS in the utf8headers-07 draft. >> Minor point, the perl manual page apparently doesn't >> say that leading zeros are "verboten", but the ABNF >> in the I-D specifies this. =20 > That is the ABNF in "dsn", not the ABNF in "unicode-escapes", > yes? The latter seems to be consistent with the Perl man page. Yes, the ABNF in "dsn". I guess the authors were forced to eliminate leading zeros, because they wanted to eliminate surrogates in ABNF. IMO they could use the simple ABNF in your draft, and let other texts discuss surrogates. =20 Ideally your I-D is published before "dsn", and "dsn" could then simply reference it. =20 Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 25 14:32:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFCz-0005yB-6r; Tue, 25 Sep 2007 14:32:33 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaFCy-0005y4-G9 for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 14:32:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFCy-0005xu-60 for ima@ietf.org; Tue, 25 Sep 2007 14:32:32 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaFCx-0000R0-Pk for ima@ietf.org; Tue, 25 Sep 2007 14:32:32 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IaFCx-0005HQ-1H; Tue, 25 Sep 2007 14:32:31 -0400 Date: Tue, 25 Sep 2007 14:32:30 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: ISSUE: dsn HEXPOINT Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) 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 Tuesday, 25 September, 2007 20:04 +0200 Frank Ellermann wrote: > Yes, the ABNF in "dsn". I guess the authors were forced to > eliminate leading zeros, because they wanted to eliminate > surrogates in ABNF. IMO they could use the simple ABNF in > your draft, and let other texts discuss surrogates. > > Ideally your I-D is published before "dsn", and "dsn" could > then simply reference it. I hope to get my (newer) draft posted this week. Assuming that there are no major comments, it will presumably then go out for a four-week IETF Last Call. But, if DSN is modified to reflect WG LC comments and reposted, it could presumably go into a two-week (as a WG document) IETF Last Call as early as next week. So, whether the race here will be won or lost is going to be a close call. I definitely do not think it worthwhile to hold up an _experimental_ DSN document for the "Unicode escapes" piece, but that is just my opinion. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Tue Sep 25 14:42:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFMR-0000oG-Ie; Tue, 25 Sep 2007 14:42:19 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaFMP-0000o5-TZ for ima-confirm+ok@megatron.ietf.org; Tue, 25 Sep 2007 14:42:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaFMP-0000nw-JS for ima@ietf.org; Tue, 25 Sep 2007 14:42:17 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaFMP-0000hY-7k for ima@ietf.org; Tue, 25 Sep 2007 14:42:17 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IaFLr-00060d-El for ima@ietf.org; Tue, 25 Sep 2007 18:41:43 +0000 Received: from 1cust196.tnt1.hbg2.deu.da.uu.net ([149.225.10.196]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 18:41:43 +0000 Received: from nobody by 1cust196.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Sep 2007 18:41:43 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Tue, 25 Sep 2007 20:41:06 +0200 Organization: http://purl.net/xyzzy Lines: 21 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust196.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [EAI] Re: REVIEW: utf8headers-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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 is still learning to tame OE, sorry... :-( > 7: > The message/global template in chapter 4.6 are actually "IANA > considerations". There has to be a review on the MIME type > list before IETF Last Call (ditto for the derived DSN types). I've checked what happens if an experimental RFC registers a MIME subtype, apparently that's possible without "variance" procedure in the standards tree. RFC 4288 4.2.6 states: | All subtypes of multipart and message MUST conform to the | syntax rules and other requirements specified in [RFC2046]. Let's drop the plan of an "experimental RFC 2046 update". If you insist on it, we have to update RFC 2046 for real. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Sep 26 11:08:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYUx-0000s1-AC; Wed, 26 Sep 2007 11:08:23 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaYUw-0000rv-PI for ima-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 11:08:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYUw-0000rm-Fb for ima@ietf.org; Wed, 26 Sep 2007 11:08:22 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaYUr-0004TR-0K for ima@ietf.org; Wed, 26 Sep 2007 11:08:22 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IaYUK-00048u-HF for ima@ietf.org; Wed, 26 Sep 2007 15:07:44 +0000 Received: from 1cust180.tnt1.hbg2.deu.da.uu.net ([149.225.10.180]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Sep 2007 15:07:44 +0000 Received: from nobody by 1cust180.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Sep 2007 15:07:44 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Wed, 26 Sep 2007 17:07:13 +0200 Organization: http://purl.net/xyzzy Lines: 41 Message-ID: References: <1894950817.20070921113425@pobox.com> 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: 1cust180.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [EAI] Re: ISSUE - draft-ietf-eai-utf8headers-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Bill McQuillan wrote: > This discussion of how to handle Content-Transfer-Encoding for = composite > types leads me to consider that what we probably should be proposing > instead is a *new* MIME header field: Content-Header-Encoding which = only > is meaningful for composite types and only affects the HEADER of a > message/* or the PART-HEADERS of a multipart/*. =20 > This avoids the "double encoding" problem and also preserves MIME > structure visibility. (We might need to warn about the problem of > specifying a non-ASCII multipart separator string to a non-EAI-aware > program.) An interesting idea. Slight variation: For a Content-Type: message/global (and its DSN-variants) we normally expect CTE 8bit and a header charset UTF-8. If we could get away with 7bit and header charset ASCII a message/global in essence degenerates into an ordinary message/rfc822. IOW we could decree that a message/global in the context of a CTE 7bit is "by definition" a QP-encoded UTF-8 header followed by a 7bit body as specified in the CTE header field of the QP-encoded UTF8-header. That would be still a kind of "double encoding" for any 2231-Q word in the original message/global header. If you pick something better than QP like B64 you'd lose the "visibility". >From my POV your "issue" affects the following statement in section 4.6 of the I-D: | Encoding considerations: The 8-bit or binary content-transfer- | encoding MUST be used unless this media type is sent over a 7-bit | only transport. What exactly is a message/global in the context of 7-bit transport ? Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Wed Sep 26 12:39:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZtt-0003uk-3D; Wed, 26 Sep 2007 12:38:13 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaZts-0003uV-OK for ima-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 12:38:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZts-0003io-Ed for ima@ietf.org; Wed, 26 Sep 2007 12:38:12 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaZtZ-0007dG-Mz for ima@ietf.org; Wed, 26 Sep 2007 12:38:00 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3#clerew$man#ac^uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.257) id 46fa8aba.353a.241 for ima@ietf.org; Wed, 26 Sep 2007 17:37:14 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8QGbDsP007639 for ; Wed, 26 Sep 2007 17:37:14 +0100 (BST) Date: Wed, 26 Sep 2007 17:36:12 +0100 From: "Charles Lindsey" To: SM Subject: Re: [EAI] Re: ISSUE: smtpext-08 2.2 erroneous MUSTard References: <6.2.5.6.2.20070925070048.030be9a0@resistor.net> Message-ID: In-Reply-To: <6.2.5.6.2.20070925070048.030be9a0@resistor.net> User-Agent: Opera M2/8.01 (SunOS, build 1204) Resent-To: IMA Resent-From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Resent-Date: Wed, 26 Sep 2007 17:37:13 +0100 Resent-Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Tue, 25 Sep 2007 15:31:39 +0100, SM wrote: > At 04:46 25-09-2007, Charles Lindsey wrote: >> So the situation now is that our documents extend what is allowed in >> MIME >> 1.0, but only for use within the UTF8SMTP universe. So when you want to >> pass stuff out of that universe you have to detect that these extensions >> have been used and downgrade (or reject) accordingly. That is what we >> all >> agreed some months ago, and actually it is not that hard to detect it >> since current MTAs already do similar tests when passing stuff into the >> Non-8BITMIME world. > > What we have is MIME 2.0 without calling it that. The changes aren't > restricted to 8-bit content only. The MIME changes will be passed to > the non-UTF8SMTP universe and may affects parsers. Not if the people who implement our extensions stick rigorously to what we have said. We had this discussion when we abolished the Header-Type header. The argument was that we could not trust people to insert Header-Type: UTF-8 in all the cases where it was strictly needed, and henceforth the ONLY way to determine whether a given message was a global/UTF8SMTP message would be to scan through the whole message looking for trouble. In defence of this, it was pointed out that MTAs routinely have to do this anyway for other reasons. That was the decision we took, and the consequence was that we need to specify very carefully what is to be done. Which we have, except for some uncertainty with the message/global - but there is a separate ISSUE regarding that, so do not let us confuse the two ISSUEs. For this discussion, just assume that message/global works "by magic" (or will somehow be fixed to do so), and leave the details of that to that other ISSUE. -- 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 Sep 26 12:55:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaaAI-000207-Rl; Wed, 26 Sep 2007 12:55:10 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaaAH-0001wp-60 for ima-confirm+ok@megatron.ietf.org; Wed, 26 Sep 2007 12:55:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaaAG-0001wh-Sn for ima@ietf.org; Wed, 26 Sep 2007 12:55:08 -0400 Received: from lon-mail-3.gradwell.net ([193.111.201.127]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaaAF-0008Jp-J2 for ima@ietf.org; Wed, 26 Sep 2007 12:55:08 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3*clerew&man$ac$uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.257) id 46fa8ee1.35c2.292 for ima@ietf.org; Wed, 26 Sep 2007 17:54:57 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8QGsrab008790 for ; Wed, 26 Sep 2007 17:54:54 +0100 (BST) To: IMA Subject: Re: [EAI] REVIEW: utf8headers-07 References: Message-ID: Date: Wed, 26 Sep 2007 17:54:53 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org On Tue, 25 Sep 2007 18:50:25 +0100, Frank Ellermann wrote: > | This document also updates [RFC2822] and MIME > > Ditto, an "experimental update" of RFC 2822 is okay, > but touching MIME (excl. the separate issue above) > is IMO unnecessary and too dangerous. > But cannot be avoided. The whole purpose of our endeavour is to get rid of the need for funny encodings (whether RFC 2047 or RFC 2231) in headers, and if we exclude the body-part headers ffrom that, then we shall have failed utterly in our prime objective. You cannot say that Content-Description: mañana or Content-Disposition: attachment; filename=mañana are allowed at the top level of a message, but not in MIME objects lower down. The world will just never learn to make such non-obvious distinctions. As to whether the particular case of message/global as proposed will pass through the existing network, that is a separate technical ISSUE which needs to be studied and resolved separately. -- 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 Sep 27 06:06:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaqFd-0007FV-BJ; Thu, 27 Sep 2007 06:05:45 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaqFa-0007CQ-IH for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 06:05:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaqFZ-0007BA-Ip for ima@ietf.org; Thu, 27 Sep 2007 06:05:41 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaqFS-00017T-Ko for ima@ietf.org; Thu, 27 Sep 2007 06:05:40 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 27 Sep 2007 11:05:21 +0100 Message-ID: <46FAC8FB.4030609@isode.com> Date: Wed, 26 Sep 2007 22:02:51 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Frank Ellermann Subject: Re: [EAI] EDITORIAL: dsn-03 "i-default" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann wrote: >Chapter 4 says that "i-default" is explained in [LANGTAGS], >and the references say that [LANGTAGS] is RFC 4646. But >RFC 4646 doesn't discuss "i-default", it's explained in >4646bis (work in progress) with a reference to RFC 2277 >[BCP 18]. > Oops, good catch. >Proposal: Use RFC 2277 for now, and switch to >4646bis later if it's ready when you need it. > Fixed, thanks! _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 06:06:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaqFL-00072q-Ps; Thu, 27 Sep 2007 06:05:27 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaqFK-000722-NJ for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 06:05:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaqFK-00071u-CP for ima@ietf.org; Thu, 27 Sep 2007 06:05:26 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaqFJ-0002gG-Mx for ima@ietf.org; Thu, 27 Sep 2007 06:05:26 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 27 Sep 2007 11:05:23 +0100 Message-ID: <46FACE15.90401@isode.com> Date: Wed, 26 Sep 2007 22:24:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Frank Ellermann Subject: Re: [EAI] EDITORIAL: dsn-03 (4..8) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8From ima-bounces@ietf.org Thu Sep 27 06:06:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaqFd-0007FV-BJ; Thu, 27 Sep 2007 06:05:45 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaqFa-0007CQ-IH for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 06:05:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaqFZ-0007BA-Ip for ima@ietf.org; Thu, 27 Sep 2007 06:05:41 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaqFS-00017T-Ko for ima@ietf.org; Thu, 27 Sep 2007 06:05:40 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 27 Sep 2007 11:05:21 +0100 Message-ID: <46FAC8FB.4030609@isode.com> Date: Wed, 26 Sep 2007 22:02:51 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Frank Ellermann Subject: Re: [EAI] EDITORIAL: dsn-03 "i-default" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann wrote: >Chapter 4 says that "i-default" is explained in [LANGTAGS], >and the references say that [LANGTAGS] is RFC 4646. But >RFC 4646 doesn't discuss "i-default", it's explained in >4646bis (work in progress) with a reference to RFC 2277 >[BCP 18]. > Oops, good catch. >Proposal: Use RFC 2277 for now, and switch to >4646bis later if it's ready when you need it. > Fixed, thanks! _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 06:06:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaqFL-00072q-Ps; Thu, 27 Sep 2007 06:05:27 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaqFK-000722-NJ for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 06:05:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaqFK-00071u-CP for ima@ietf.org; Thu, 27 Sep 2007 06:05:26 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaqFJ-0002gG-Mx for ima@ietf.org; Thu, 27 Sep 2007 06:05:26 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 27 Sep 2007 11:05:23 +0100 Message-ID: <46FACE15.90401@isode.com> Date: Wed, 26 Sep 2007 22:24:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Frank Ellermann Subject: Re: [EAI] EDITORIAL: dsn-03 (4..8) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann wrote: >4: >| The third type, used for header return, is message/global-headers >| and contains only the UTF-8 headers of a message (all lines prior >| to the first blank line in a UTF8SMTP message). > >s/headers/header/ or s/headers/header fields/ for the terminology >police. > > The latter. Changed. >| Note that [I-D.ietf-eai-utf8headers] relaxed restriction from >| MIME [RFC2046] regarding use of Content-Transfer-Encoding in new >| "message" subtypes. > >Also note that >does not contain a single occurence of MIME. > >5: >| When generating a MDN for a UTF-8 header message, content or >| header return is the same as for DSNs. > >Hard to read, do you mean something like this: >"When generating a MDN for a UTF-8 header message, the returned > content or header (message/global or message/global-headers) > uses the same format as for DSNs." > > I've changed that to: When generating a MDN for a UTF-8 header message, the third part of the multipart/report contains the returned content (message/global) or header (message/global-headers), same as for DSNs. instead. >| The MDN specification also defines the Original-Recipient >| header field > >OT: That's not yet listed in the message header field registry. >I-D.lilly-legacy-fields is in state ISR-AUTH for some years (?) >on http://rfc-editor.org/queue.html > > Hmm, another todo item for somebody :-) >Last nit, appendix B should be removed before an IETF Last Call. > > Good point. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann wrote: >4: >| The third type, used for header return, is message/global-headers >| and contains only the UTF-8 headers of a message (all lines prior >| to the first blank line in a UTF8SMTP message). > >s/headers/header/ or s/headers/header fields/ for the terminology >police. > > The latter. Changed. >| Note that [I-D.ietf-eai-utf8headers] relaxed restriction from >| MIME [RFC2046] regarding use of Content-Transfer-Encoding in new >| "message" subtypes. > >Also note that >does not contain a single occurence of MIME. > >5: >| When generating a MDN for a UTF-8 header message, content or >| header return is the same as for DSNs. > >Hard to read, do you mean something like this: >"When generating a MDN for a UTF-8 header message, the returned > content or header (message/global or message/global-headers) > uses the same format as for DSNs." > > I've changed that to: When generating a MDN for a UTF-8 header message, the third part of the multipart/report contains the returned content (message/global) or header (message/global-headers), same as for DSNs. instead. >| The MDN specification also defines the Original-Recipient >| header field > >OT: That's not yet listed in the message header field registry. >I-D.lilly-legacy-fields is in state ISR-AUTH for some years (?) >on http://rfc-editor.org/queue.html > > Hmm, another todo item for somebody :-) >Last nit, appendix B should be removed before an IETF Last Call. > > Good point. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 06:06:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaqFu-0007Ti-Cv; Thu, 27 Sep 2007 06:06:02 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaqFs-0007TV-Rz for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 06:06:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaqFs-0007Rw-Gl for ima@ietf.org; Thu, 27 Sep 2007 06:06:00 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaqFs-0002gz-5w for ima@ietf.org; Thu, 27 Sep 2007 06:06:00 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 27 Sep 2007 11:05:48 +0100 Message-ID: <46FAD098.90706@isode.com> Date: Wed, 26 Sep 2007 22:35:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Frank Ellermann Subject: Re: [EAI] EDITORIAL: dsn-03 chapter 3 QMIDCHAR + QHIGHCHAR References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann wrote: >Okay, now I think I see what's HEXPOINT about, it >tries to avoid leading zeros and surrogates in ABNF. > > Correct. >Actually it's one of the three notations in John's >http://tools.ietf.org/html/draft-klensin-unicode-escapes >Hopefully perl-fans will love it, that's good enough. > >IMO it's not strictly necessary to discuss surrogates >in ABNF in an I-D about DSNs, but that's no "ISSUE" >(now I had some coffee, that helped). > >Back to the editorial nitpicking: The 6th paragraph >in section 3 talks about QMIDCHAR and QHIGHCHAR, but >there's no ABNF or other explanation for this anymore. > > Good catch. Fixed. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 06:38:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaqkm-0000fD-JR; Thu, 27 Sep 2007 06:37:56 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iaqkl-0000dL-7f for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 06:37:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaqkk-0000YP-U5 for ima@ietf.org; Thu, 27 Sep 2007 06:37:54 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iaqka-0001qE-Mm for ima@ietf.org; Thu, 27 Sep 2007 06:37:50 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iaqjf-0006sz-6L for ima@ietf.org; Thu, 27 Sep 2007 10:36:47 +0000 Received: from 1cust147.tnt2.hbg2.deu.da.uu.net ([149.225.12.147]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 10:36:47 +0000 Received: from nobody by 1cust147.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 10:36:47 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Thu, 27 Sep 2007 12:35:21 +0200 Organization: http://purl.net/xyzzy Lines: 21 Message-ID: References: <46FACE15.90401@isode.com> 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: 1cust147.tnt2.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [EAI] Re: EDITORIAL: dsn-03 (4..8) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Alexey Melnikov wrote: >| When generating a MDN for a UTF-8 header message, the third part of >| the multipart/report contains the returned content (message/global) >| or header (message/global-headers), same as for DSNs. Yes, that's better. >> OT: That's not yet listed in the message header field registry. >> I-D.lilly-legacy-fields is in state ISR-AUTH for some years (?) >> on http://rfc-editor.org/queue.html > Hmm, another todo item for somebody :-) If nothing happens somebody could extract the template from Bruce's I-D, add the published dsn-03 RFC to the references, post it on the message header review list, and submit it to IANA after two weeks. Noted as "todo" after the DSN RFC got its number. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 06:57:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iar3D-0007o6-NR; Thu, 27 Sep 2007 06:56:59 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iar3C-0007mp-VZ for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 06:56:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iar3C-0007mf-Lu for ima@ietf.org; Thu, 27 Sep 2007 06:56:58 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iar38-0002Hd-ED for ima@ietf.org; Thu, 27 Sep 2007 06:56:58 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iar2u-0000ve-HL for ima@ietf.org; Thu, 27 Sep 2007 10:56:40 +0000 Received: from 1cust147.tnt2.hbg2.deu.da.uu.net ([149.225.12.147]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 10:56:40 +0000 Received: from nobody by 1cust147.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 10:56:40 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Thu, 27 Sep 2007 12:56:05 +0200 Organization: http://purl.net/xyzzy Lines: 23 Message-ID: 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: 1cust147.tnt2.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [EAI] Re: REVIEW: utf8headers-07 X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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 our endeavour is to get rid of the need > for funny encodings (whether RFC 2047 or RFC 2231) in headers TINW, I prefer to stick to the WG charter and MIME 1.0 for this episode. If that turned out to work and the UTF8SMTP core RFCs are on standards track tackling MIME 2.0 might be fine. > You cannot say that > Content-Description: ma=F1ana > or > Content-Disposition: attachment; filename=3Dma=F1ana > are allowed at the top level of a message, but not in MIME > objects lower down. Quite so. I say "leave MIME 1.0 and Content-*" alone everywhere. All it takes to get this effect is a note in the utf8headers I-D. And lets please get rid of , if you're looking for funny encodings that construct should trigger some alarms. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 07:05:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IarBg-0005gx-26; Thu, 27 Sep 2007 07:05:44 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IarBe-0005fQ-Ie for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 07:05:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IarBe-0005fH-1w for ima@ietf.org; Thu, 27 Sep 2007 07:05:42 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IarBc-0002XF-GP for ima@ietf.org; Thu, 27 Sep 2007 07:05:41 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 27 Sep 2007 12:05:29 +0100 Message-ID: <46FB8E97.40308@isode.com> Date: Thu, 27 Sep 2007 12:05:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Frank Ellermann Subject: Re: [EAI] EDITORIAL: dsn-03 1..3 (at the end it's an ISSUE: dsn HEXPOINT) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann wrote: >2: >-| and the rules in section 4 of RFC 3629. > >Lack of caffeine, I really clicked on the rfcmarkup >link to check what you're talking about. Maybe say: > >+| and the UTF-8 syntax rules in section 4 of RFC 3629. > > Ok. >3: >| I.e. the utf-8-address form MUST NOT be used in the >| ORCPT parameter when the SMTP server doesn't advertise >| support for UTF8SMTP or the SMTP server supports >| UTF8SMTP, but the address contains US-ASCII characters >| not permitted in the ORCPT parameter (e.g. the ORCPT >| parameter forbids unencoded SP and =); or in a >| 7-bit transport environment including a >| message/delivery-status Original-Recipient or >| Final-Recipient field. > >Hard to parse. How about an ordered list [...] "when:" >"1: the SMTP server doesn't advertise UTF8SMTP" [...], >"2: the SMTP server supports UTF8SMTP, but" [...], >"3: in a 7-bit transport environment" [...]. > > I've done something like that. >| In the former case the utf-8-addr-xtext form >What's the former case here, the "1" in my proposal ? > > Yes. >| in the latter case the utf-8-addr-unitext form >If the latter case is "3", what about "2" ? > > utf-8-addr-unitext should be used in both cases 2 and 3. I will clarify. >The prose is really hardcore, I had to jump forward >to the ABNF to get a vague idea what you're talking >about. > > It was very painful to come up with a way of describing 3 layer syntax. >An is apparently a "raw" >with an optional ASCII in angle brackets >for the optional Alt-Address. Readers need to know >this before you start with the MUSTard and the fine >print. > > Any specific suggestions? >Then there's a problem with some ASCII characters >not allowed in ORCPT. For that you introduce an > term, which is the 3461-xtext >encoding of a . > >And is apparently any UTF-8 >character excluding CTLs, SP, "\", "+", and "=", >where you need an \x... notation with the name >. > > Correct. >[The remark "printable" for QUCHAR confuses me, > not all non-ASCII UTF-8 characters are printable]. > > Printable was regarding US-ASCII subset. I've changed to clarify. >Another question, if an contains >an Alt-Address, then it also contains 1*WSP as a >separator between uMailbox and "<" Mailbox ">". >Often WSP is SP, and that's not allowed for the >ORCPT magic, is that correct ? > Correct. >How about some examples ? > I will think about that. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 07:55:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iarxh-0007OC-NK; Thu, 27 Sep 2007 07:55:21 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iarxe-0007Ie-4s for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 07:55:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iarxd-0007HE-OY for ima@ietf.org; Thu, 27 Sep 2007 07:55:17 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IarxT-0003at-7D for ima@ietf.org; Thu, 27 Sep 2007 07:55:17 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5C2EA2596C0; Thu, 27 Sep 2007 13:55:02 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13874-03; Thu, 27 Sep 2007 13:54:56 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8A93D2596D9; Thu, 27 Sep 2007 13:54:56 +0200 (CEST) Message-ID: <46FB9A10.9050500@alvestrand.no> Date: Thu, 27 Sep 2007 13:54:56 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [EAI] Re: REVIEW: draft-ietf-eai-smtpext-08.txt References: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> 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: 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 Frank Ellermann wrote: > No :-) The DSN has to go to the "originator as indicated > in the Return Path", therefore the MTA has to be confident > that the Return Path in fact indicates the originator. > > Otherwise it better rejects "dubious" mails instead of > risking to violate this RFC 2821 requirement, where > "dubious" includes any instance of "final delivery is > less than almost certain". > Out of scope for this WG to change mail's behaviour in that way, Frank. And you knew that already... _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 08:11:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IasCb-0001mp-3t; Thu, 27 Sep 2007 08:10:45 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IasCZ-0001md-MI for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 08:10:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IasCZ-0001mM-CP for ima@ietf.org; Thu, 27 Sep 2007 08:10:43 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IasCX-00040r-Gt for ima@ietf.org; Thu, 27 Sep 2007 08:10:43 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 27 Sep 2007 13:10:38 +0100 Message-ID: <46FB9BEF.905@isode.com> Date: Thu, 27 Sep 2007 13:02:55 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Frank Ellermann Subject: Re: [EAI] Re: ISSUE: dsn HEXPOINT References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Frank Ellermann wrote: >>>Minor point, the perl manual page apparently doesn't >>>say that leading zeros are "verboten", but the ABNF >>>in the I-D specifies this. >>> >>> >>That is the ABNF in "dsn", not the ABNF in "unicode-escapes", >>yes? The latter seems to be consistent with the Perl man page. >> >> >Yes, the ABNF in "dsn". I guess the authors were forced to >eliminate leading zeros, because they wanted to eliminate >surrogates in ABNF. > Yes. > IMO they could use the simple ABNF in >your draft, and let other texts discuss surrogates. > > I slightly prefer the current syntax. Other opinions? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 08:35:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IasaH-000154-15; Thu, 27 Sep 2007 08:35:13 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IasaF-00014y-AF for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 08:35:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IasaF-00014q-0G for ima@ietf.org; Thu, 27 Sep 2007 08:35:11 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IasaE-0006tx-MM for ima@ietf.org; Thu, 27 Sep 2007 08:35:10 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 08E842596D9 for ; Thu, 27 Sep 2007 14:35:10 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14746-08 for ; Thu, 27 Sep 2007 14:35:04 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id BDD802596DC for ; Thu, 27 Sep 2007 14:35:02 +0200 (CEST) Message-ID: <46FBA376.1030007@alvestrand.no> Date: Thu, 27 Sep 2007 14:35:02 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: EAI WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [EAI] WG Last Call on core documents has ended X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org As of this Tuesday, Last Call on the core documents is over. A total of 13 messages have been received with "ISSUE:" at the start of the subject line; I am going through them and assigning issue numbers to those that don't seem to be either off-topic or sufficiently resolved in discussion. All those issues will have to be disposed of (either with a WG consensus of "no change" or with a document change) before the documents are sent to the IESG. I'll send a reply to each original message indicating its disposition. Harald _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 08:51:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaspT-0008CK-0H; Thu, 27 Sep 2007 08:50:55 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaspS-0008BY-86 for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 08:50:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaspR-0008BQ-TE for ima@ietf.org; Thu, 27 Sep 2007 08:50:53 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaspQ-000543-HN for ima@ietf.org; Thu, 27 Sep 2007 08:50:53 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C9CAF2596DA; Thu, 27 Sep 2007 14:50:46 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15167-08; Thu, 27 Sep 2007 14:50:40 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A98E2596AF; Thu, 27 Sep 2007 14:50:40 +0200 (CEST) Message-ID: <46FBA71F.40302@alvestrand.no> Date: Thu, 27 Sep 2007 14:50:39 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Charles Lindsey Subject: #1485 (closed) Re: [EAI] ISSUE utf8 meaage/global 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This message has been recorded as a comment on closed issue #1485. Charles Lindsey wrote: > 4.2. Changes on MIME headers > > This specification updates section 6.4 of RFC 2045. RFC 2045 > prohibits applying a content-transfer-encoding to all subtypes of > message/. This specification relaxes the rule, allowing newly > defined MIME types to permit content-transfer-encoding. (see > Section 4.6). > > I reiterate my objection to this breach of the "EXPRESSLY FORBIDDEN" > rule in RFC 2045, unless it can be established that a significant part > of the installed base of MTAs will cope with it when downgrading to > Non-8BITMIME (it is already established that a significant part of > that base will _not_ cope with it). > > It is claimed in 4.6 that existing MTAs will cope with this unknown > MIME type by treating it as application/octet stream (although it is > unclear whether that default pvovision was ever intended to apply to > other than MUAs, and whether MUAs handle Q-P and Base64 in message > types is irrelevant to my argument). The issue is what the current > installed base of MTAs actually _does_ (rightly or wrongly). > > Note that we are now proposing to apply this relaxation to four new > message types: > message/global > message/global-delivery-status > message/global-headers > message/global-disposition-notification > of which problems with the third could be avoided by using > text/global-headers instead. > > I understand that the consensus is against me on this issue, and I am > therefore not asking that it be reopened at this stage. However, I > repeat what I have already stated before, that I intend to raise it at > IESG Last Call. > > Note that I have written separate EDITORIAL comments on the utf8 and > dsn drafts. > > --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 Thu Sep 27 08:52:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IasrD-0001Sh-Qt; Thu, 27 Sep 2007 08:52:43 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IasrC-0001SH-CD for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 08:52:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IasrC-0001S8-1t for ima@ietf.org; Thu, 27 Sep 2007 08:52:42 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IasrB-0007SR-Ml for ima@ietf.org; Thu, 27 Sep 2007 08:52:41 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2EFC92596DA; Thu, 27 Sep 2007 14:52:41 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15412-03; Thu, 27 Sep 2007 14:52:36 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 15A3A2596AF; Thu, 27 Sep 2007 14:52:36 +0200 (CEST) Message-ID: <46FBA793.7010603@alvestrand.no> Date: Thu, 27 Sep 2007 14:52:35 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: SM Subject: No # assigned Re: [EAI] ISSUE: draft-ietf-eai-utf8headers-07 - message/ subtypes References: <6.2.5.6.2.20070920103926.02f336c0@elandnews.com> In-Reply-To: <6.2.5.6.2.20070920103926.02f336c0@elandnews.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org This one seems to have been resolved in discussion. SM wrote: > Hello, > > Section 1.2 of draft-ietf-eai-utf8headers-07 mentions: > > "This document updates section 6.4 of RFC 2045. It removes the > blanket ban on applying a content-transfer-encoding to all subtypes > of message/, and instead specifies that a composite subtype MAY > specify whether or not a content-transfer-encoding can be used for > that subtype, with "cannot be used" as the default" > > This draft is applicable to SMTP whereas some of the message/ subtypes > may be used by other mechanisms. Is there a reason why the removal > should apply to other transport mechanisms? > > Regards, > -sm > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 08:57:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IasvG-0006XV-9S; Thu, 27 Sep 2007 08:56:54 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IasvE-0006XQ-V9 for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 08:56:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IasvE-0006X0-KS for ima@ietf.org; Thu, 27 Sep 2007 08:56:52 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IasvE-0007Xh-6s for ima@ietf.org; Thu, 27 Sep 2007 08:56:52 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7F9F32596DA; Thu, 27 Sep 2007 14:56:51 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15412-05; Thu, 27 Sep 2007 14:56:46 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 111252596AF; Thu, 27 Sep 2007 14:56:46 +0200 (CEST) Message-ID: <46FBA88D.1030902@alvestrand.no> Date: Thu, 27 Sep 2007 14:56:45 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20070920111954.02ec47b0@elandnews.com> In-Reply-To: <6.2.5.6.2.20070920111954.02ec47b0@elandnews.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ima@ietf.org Subject: [EAI] #1504 ISSUE: draft-ietf-eai-utf8headers-07 - nested encoding X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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 saw no response on this, and there might be a need for more text here. I believe the WG came to consensus that allowing nested encodings was better than inventing new schemes for handling nested types - that's why I've lumped this together with the "content-header-encoding" idea of another message. Tracker #1504 is assigned to this issue; please keep that in the subject line. SM wrote: > Hello, > > In Section 4.2, it is mentioned that double encoding might happen in > practice. Quoting Section 6.4 of RFC 2045: > > > "NOTE ON ENCODING RESTRICTIONS: Though the prohibition against using > content-transfer-encodings on composite body data may seem overly > restrictive, it is necessary to prevent nested encodings, in which > data are passed through an encoding algorithm multiple times, and > must be decoded multiple times in order to be properly viewed. > Nested encodings add considerable complexity to user agents: Aside > from the obvious efficiency problems with such multiple encodings, > they can obscure the basic structure of a message. In particular, > they can imply that several decoding operations are necessary simply > to find out what types of bodies a message contains. Banning nested > encodings may complicate the job of certain mail gateways, but this > seems less of a problem than the effect of nested encodings on user > agents. > > It may be more efficient implementation-wise to prohibit double > encoding to avoid several decoding operations. The paragraph also > mentions several other reasons for having such a restriction. > > Regards, > -sm > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 08:58:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaswH-0007XS-9m; Thu, 27 Sep 2007 08:57:57 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IaswG-0007Ot-74 for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 08:57:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaswF-0007No-Sz for ima@ietf.org; Thu, 27 Sep 2007 08:57:55 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaswF-0007Yt-Im for ima@ietf.org; Thu, 27 Sep 2007 08:57:55 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 170182596DA; Thu, 27 Sep 2007 14:57:55 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15460-03; Thu, 27 Sep 2007 14:57:50 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A19B2596AF; Thu, 27 Sep 2007 14:57:50 +0200 (CEST) Message-ID: <46FBA8CD.3090106@alvestrand.no> Date: Thu, 27 Sep 2007 14:57:49 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: SM Subject: No # assigned Re: [EAI] ISSUE: draft-ietf-eai-utf8headers-07 - Content-Description References: <6.2.5.6.2.20070920115650.02f40c28@elandnews.com> In-Reply-To: <6.2.5.6.2.20070920115650.02f40c28@elandnews.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I believe this has been clarified sufficiently in later discussion. SM wrote: > Hello, > > Section 4.3 provides for UTF-8 being allowed in "Content-Description" > header fields. Does that mean that a "Content-Description" header for > an image/ type, for example, found within a multipart/ can have UTF-8 > text? > > Regards, > -sm > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 08:59:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iasxz-0003I7-Qa; Thu, 27 Sep 2007 08:59:43 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iasxz-0003I2-64 for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 08:59:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iasxy-0003Hu-S9 for ima@ietf.org; Thu, 27 Sep 2007 08:59:42 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iasxy-0007bj-G6 for ima@ietf.org; Thu, 27 Sep 2007 08:59:42 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 001562596DA; Thu, 27 Sep 2007 14:59:41 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15412-10; Thu, 27 Sep 2007 14:59:37 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E675F2596AF; Thu, 27 Sep 2007 14:59:36 +0200 (CEST) Message-ID: <46FBA938.3000604@alvestrand.no> Date: Thu, 27 Sep 2007 14:59:36 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Bill McQuillan Subject: #1504 Re: [EAI] ISSUE - draft-ietf-eai-utf8headers-07 References: <1894950817.20070921113425@pobox.com> In-Reply-To: <1894950817.20070921113425@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: IMA Discussion X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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've lumped this together with the double encoding issue - #1504. Please keep the number in the subject line when responding. Bill McQuillan wrote: > This discussion of how to handle Content-Transfer-Encoding for composite > types leads me to consider that what we probably should be proposing > instead is a *new* MIME header field: Content-Header-Encoding which only is > meaningful for composite types and only affects the HEADER of a message/* > or the PART-HEADERS of a multipart/*. > > This avoids the "double encoding" problem and also preserves MIME structure > visibility. (We might need to warn about the problem of specifying a > non-ASCII multipart separator string to a non-EAI-aware program.) > > Since any relaxation of the "blanket ban" of Content-Transfer-Encoding for > composite types would probably require *some* updating of code in EAI-aware > programs, the addition of a Content-Header-Encoding field should be of > similar effort and would narrow this solution to only the portion of the > data where it is needed. > > Sorry if I have missed a discussion of this possibility previously in this > group. > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 09:03:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iat1S-0007J8-1Q; Thu, 27 Sep 2007 09:03:18 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iat1R-0007Hd-Ku for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 09:03:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iat1R-0007ET-8W for ima@ietf.org; Thu, 27 Sep 2007 09:03:17 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iat1Q-0007i1-Tr for ima@ietf.org; Thu, 27 Sep 2007 09:03:17 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 607412596DB; Thu, 27 Sep 2007 15:03:16 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15772-01; Thu, 27 Sep 2007 15:03:11 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1E2E32596AF; Thu, 27 Sep 2007 15:03:11 +0200 (CEST) Message-ID: <46FBAA0F.4050306@alvestrand.no> Date: Thu, 27 Sep 2007 15:03:11 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Frank Ellermann Subject: #1505 Re: [EAI] ISSUE: smtpext-08 2.8 References: In-Reply-To: Content-Type: text/plain; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Merged with comment on 2.2, issue #1505. Frank Ellermann wrote: > IMO belonging to the same issue, 2.6 states: > > | Since there is no ESMTP parameter which tells whether the > | message is UTF8SMTP message, SMTP server needs to parse > | all message header fields and MIME header fields in the > | message body to discover which messages are UTF8SMTP. > > Editorial: "a UTF8SMTP message" and "an SMTP server". > Technical: It needs only to parse _the_ message header. > > The internal MIME structure of the body is irrelevant for > relaying MTAs. > > > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 09:04:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iat2d-0001Ms-1R; Thu, 27 Sep 2007 09:04:31 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iat2b-0001Cd-2m for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 09:04:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iat2a-0001CO-P0 for ima@ietf.org; Thu, 27 Sep 2007 09:04:28 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iat2V-0005Ot-AS for ima@ietf.org; Thu, 27 Sep 2007 09:04:28 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A78D32596DB; Thu, 27 Sep 2007 15:04:20 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15646-05; Thu, 27 Sep 2007 15:04:15 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 762662596AF; Thu, 27 Sep 2007 15:04:15 +0200 (CEST) Message-ID: <46FBAA4F.3090500@alvestrand.no> Date: Thu, 27 Sep 2007 15:04:15 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Frank Ellermann Subject: #1505 Re: [EAI] ISSUE: smtpext-08 2.2 erroneous MUSTard References: In-Reply-To: Content-Type: text/plain; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I believe the WG has previously had consensus that the entire message had to be scanned to determine if the UTF8SMTP extension was required, and that this was OK. However, it's worth re-checking that consensus. Issue #1505 assigned. Frank Ellermann wrote: > | 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 message which contains internationalized mail headers > | [EAI-utf8header] at any level within its MIME structure. > > It MUST NOT transmit a message with an I18N header. As soon as that's > clear the object is by definition a message/rfc822, and its internal > MIME structure isn't the business of relaying MTAs or this I-D. > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 09:07:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iat59-0007c7-Oo; Thu, 27 Sep 2007 09:07:07 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iat58-0007YJ-7C for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 09:07:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iat57-0007Vw-0Y for ima@ietf.org; Thu, 27 Sep 2007 09:07:05 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iat55-0005Tk-P5 for ima@ietf.org; Thu, 27 Sep 2007 09:07:04 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 485242596BB; Thu, 27 Sep 2007 15:07:03 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15772-05; Thu, 27 Sep 2007 15:06:54 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C56752596BA; Thu, 27 Sep 2007 15:06:54 +0200 (CEST) Message-ID: <46FBAAEE.9070303@alvestrand.no> Date: Thu, 27 Sep 2007 15:06:54 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Frank Ellermann Subject: No # assigned Re: [EAI] ISSUE: dsn HEXPOINT References: In-Reply-To: Content-Type: text/plain; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Since the DSN document as of version -03 contains no reference to Perl, and has all the documentation for HEXPOINT internal to itself, I fail to see how this is an issue. No issue # recorded. Frank Ellermann wrote: > Hi, > > I've now read > about the \x{...} notation, and I'm not sure that it's > clear what \x{5C} and \x{80} up to \x{FF} actually mean. > > The example on the perluniintro page is: > > | perl -e 'print "\x{DF}\n", "\x{0100}\x{DF}\n"' > | produces a fairly useless mixture of native bytes and > | UTF-8, as well as a warning > > Apparently this construct enumerates octets in the local > charset up to \x{FF}, switching to Unicode points only > for \x{100} up to \x{10FFFF}. > > That's some kind of backward compatibility feature, it > can't be removed by decree in an RFC, perl users would > expect that this notation works as is for them. > > If that's correct this notation is also unsuited for > http://tools.ietf.org/html/draft-klensin-unicode-escapes > > Minor point, the perl manual page apparently doesn't > say that leading zeros are "verboten", but the ABNF > in the I-D specifies this. > > 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 Thu Sep 27 09:11:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iat8z-00061C-Ld; Thu, 27 Sep 2007 09:11:05 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iat8y-000606-Fj for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 09:11:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iat8y-0005zy-61 for ima@ietf.org; Thu, 27 Sep 2007 09:11:04 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iat8w-0005Zq-V5 for ima@ietf.org; Thu, 27 Sep 2007 09:11:04 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6AF3D2596BB; Thu, 27 Sep 2007 15:11:02 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15772-07; Thu, 27 Sep 2007 15:10:57 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DD4C22596BA; Thu, 27 Sep 2007 15:10:56 +0200 (CEST) Message-ID: <46FBABE0.1040905@alvestrand.no> Date: Thu, 27 Sep 2007 15:10:56 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Frank Ellermann Subject: EDITORIAL Re: [EAI] ISSUE: smtpext-08 2.4 ABNF References: In-Reply-To: Content-Type: text/plain; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I'm classifying this issue as editorial; I don't think making the handling of domainname different in the special case of "postmaster" was the intention at any point, and the other one doesn't seem to be a protocol change. Both changes are a good idea, in my opinion. Good catch! Frank Ellermann wrote: > 2.4: Two ABNF oddities: > > -| "RCPT TO:" ("" / "" / > | uForward-Path) [ SP Rcpt-parameters ] CRLF > +| "RCPT TO:" ("" / "" / > | uForward-Path) [ SP Rcpt-parameters ] CRLF > > -| ALT-ADDRESS-parameter="ALT-ADDRESS=" ALT-ADDRESS-esmtp-value > | > -| ALT-ADDRESS-esmtp-value=xtext > > That's hard to read. Proposal: > > +| Alt-address-parameter = "ALT-ADDRESS=" Alt-address-value > | > +| Alt-address-value = xtext > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 09:20:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IatIE-0006CP-Lo; Thu, 27 Sep 2007 09:20:38 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IatID-0006C1-Cj for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 09:20:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IatIC-0006Bt-VR for ima@ietf.org; Thu, 27 Sep 2007 09:20:36 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IatIB-0005qT-MS for ima@ietf.org; Thu, 27 Sep 2007 09:20:36 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 278332596DA; Thu, 27 Sep 2007 15:20:35 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16167-02; Thu, 27 Sep 2007 15:20:29 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 90E5B2596BB; Thu, 27 Sep 2007 15:20:29 +0200 (CEST) Message-ID: <46FBAE1D.7070305@alvestrand.no> Date: Thu, 27 Sep 2007 15:20:29 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Frank Ellermann Subject: #1506 Re: [EAI] ISSUE: smtpext-08 3..5 References: In-Reply-To: Content-Type: text/plain; charset=Windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I've assigned #1506 to discussions about the substantial content of=20 sections 3-5 that do not affect the protocol in any substantial way. Frank Ellermann wrote: > As John and others have noted, chapters 3..5 are somewhat odd. > > The I-D isn't about POP3, LMTP, IMAP, DSNs, MIME, or 2822upd, > it's about ESMTP with the UTF8SMTP and should focus on this.=B4 > > As an editorial point about section 4: The subsection 4.1 is > an orphan, there's no 4.2. > > Substantial point about a remark in section 5: > > | It is notable in an internationalization context that there > | is a long history on some systems of using overstruck ASCII > | characters (a character, a backspace, and another character) > | within a quoted string to approximate non-ASCII characters. > > I've never seen this, maybe it's limited to communities where > the Latin-1 subset of Unicode isn't the predominant charset. > > | This form of internationalization SHOULD be phased out as > | this extension becomes widely deployed > > Using NO-WS-CTL anywhere in a message header should be phased > out a.s.a.p. in 2822upd. That's no job for EAI, let alone > this I-D. > > | backward-compatibility considerations require that it > | continue to be supported. > > At the moment 2822upd still allows NO-WS-CTL. In the "worst" > (for the *alleged* backward compatibility) case it could say > "MUST accept, MUST NOT generate" moving NO-WS-CTL wholesale > to its obs-cenity section. > > Frank > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > =20 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 09:53:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iatny-0007ss-IB; Thu, 27 Sep 2007 09:53:26 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iatnx-0007si-8P for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 09:53:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iatnw-0007qO-UJ for ima@ietf.org; Thu, 27 Sep 2007 09:53:24 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iatnv-0006rX-NK for ima@ietf.org; Thu, 27 Sep 2007 09:53:24 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C0BA2596D6; Thu, 27 Sep 2007 15:53:23 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16535-10; Thu, 27 Sep 2007 15:53:17 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C84252596D5; Thu, 27 Sep 2007 15:53:17 +0200 (CEST) Message-ID: <46FBB5CD.8060305@alvestrand.no> Date: Thu, 27 Sep 2007 15:53:17 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Frank Ellermann Subject: No issue # Re: [EAI] ISSUE: smtext-08 security considerations References: In-Reply-To: Content-Type: text/plain; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no 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 I do not see an issue specific to EAI here. MX paths can fail for all sorts of reasons, the combination of no UTF8SMTP and no downgrade is just one of them. No issue # assigned. Frank Ellermann wrote: > I'm at a loss how section 7 passed any giggle test before WGLC. > > Without a thorough discussion why offering UTF8SMTP at the MX > when it won't work out at the final delivery MTA is a really > bad idea this I-D isn't ready for an IETF Last Call. Nobody > wants *more* undeliverable mails causing misdirected bounces. > > That's likely not the only missing "security consideration", > the very minumum I expect in an RFC is a honest attempt to > discuss potential security issues. > > > > > > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www1.ietf.org/mailman/listinfo/ima > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 09:56:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IatqQ-0003WH-JJ; Thu, 27 Sep 2007 09:55:58 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IatqQ-0003UQ-5c for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 09:55:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IatqP-0003UD-Rq for ima@ietf.org; Thu, 27 Sep 2007 09:55:57 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IatqP-00016s-HT for ima@ietf.org; Thu, 27 Sep 2007 09:55:57 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EE07A2596D5; Thu, 27 Sep 2007 15:55:56 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17047-03; Thu, 27 Sep 2007 15:55:49 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 448412596D6; Thu, 27 Sep 2007 15:55:48 +0200 (CEST) Message-ID: <46FBB664.4040608@alvestrand.no> Date: Thu, 27 Sep 2007 15:55:48 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Frank Ellermann Subject: #1507 NO-WS-CTL Re: [EAI] ISSUE: dsn-03 utf8-text References: In-Reply-To: Content-Type: text/plain; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org I have recorded this as issue #1507, and given it the title UTF8HDR/DSN: Remove NO-WS_CTL from specification? Frank Ellermann wrote: > | utf8-text = %d1-9 / ; Any Unicode character except for NUL, > | %d11 / ; CR and LF, encoded in UTF-8 > | %d12 / > | %d14-127 / > | UTFMB > || UTFMB = UTF2 / UTF3 / UTF4I don't like this, it allows NO-WS-CTL. And the "UTFMB" isn'tused elsewhere. How about this:utf8-text = SP / VCHAR / UTF2 / UTF3 / UTF4 Frank > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 14:48:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IayOw-00080r-7M; Thu, 27 Sep 2007 14:47:54 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IayOv-00080l-L7 for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 14:47:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IayOv-000800-BA for ima@ietf.org; Thu, 27 Sep 2007 14:47:53 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IayOm-0007a4-WB for ima@ietf.org; Thu, 27 Sep 2007 14:47:51 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IayOJ-0001Xm-2j for ima@ietf.org; Thu, 27 Sep 2007 18:47:15 +0000 Received: from 1cust133.tnt2.hbg2.deu.da.uu.net ([149.225.12.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 18:47:15 +0000 Received: from nobody by 1cust133.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 18:47:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Thu, 27 Sep 2007 20:46:49 +0200 Organization: http://purl.net/xyzzy Lines: 64 Message-ID: References: <46FB8E97.40308@isode.com> 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: 1cust133.tnt2.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [EAI] Re: EDITORIAL: dsn-03 1..3 (at the end it's an ISSUE: dsn HEXPOINT) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Alexey Melnikov wrote: >> Hard to parse. How about an ordered list [...] "when:" >> "1: the SMTP server doesn't advertise UTF8SMTP" [...], >> "2: the SMTP server supports UTF8SMTP, but" [...], >> "3: in a 7-bit transport environment" [...]. > I've done something like that. Thanks. =20 >> The prose is really hardcore, I had to jump forward >> to the ABNF to get a vague idea what you're talking >> about. > It was very painful to come up with a way of describing > 3 layer syntax. Yes, and hard to groke because I've forgotten the details since I read an earlier version months ago. >> An is apparently a "raw" >> with an optional ASCII in angle brackets >> for the optional Alt-Address. Readers need to know >> this before you start with the MUSTard and the fine >> print. > Any specific suggestions? Maybe introduce (prose and ABNF) first, separate subsection. =20 Then explain the issue with ORCPT in DSNs, quoting 3461. Admittedly "xtext" and its motivation isn't something I know by heart. That could be a second subsection. After that explain your solution and its ABNF, with a hint that the HEXPOINT is in fact simple, only the ABNF is horrible because it tries to eliminate surrogates. =20 >> Another question, if an contains >> an Alt-Address, then it also contains 1*WSP as a >> separator between uMailbox and "<" Mailbox ">". >> Often WSP is SP, and that's not allowed for the >> ORCPT magic, is that correct ? > Correct. Okay. But don't propose to use HT instead of SP... ;-) >> How about some examples ? > I will think about that. Maybe you can use the example in the Jabber-ID draft: jiři@čechy.example (ASCII with hex. NCRs) ji%C5%99i@%C4%8Dechy.example (percent encoded UTF-8) For a convincing alt-address you'd need the xn--form of čechy. You could then use this example with and without alt-address to explore the wonders of "xtext" and SP. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 15:01:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaybq-0006cy-Kx; Thu, 27 Sep 2007 15:01:14 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iaybq-0006ct-9I for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 15:01:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaybp-0006cl-Vo for ima@ietf.org; Thu, 27 Sep 2007 15:01:13 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iaybj-0007vv-PD for ima@ietf.org; Thu, 27 Sep 2007 15:01:13 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 27 Sep 2007 20:01:06 +0100 Message-ID: <46FBFDF4.20108@isode.com> Date: Thu, 27 Sep 2007 20:01:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Frank Ellermann Subject: Re: [EAI] Re: ISSUE: dsn-03 utf8-text References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Frank Ellermann wrote: >Frank Ellermann has to learn how to tame OE, sorry, next attempt: > >| utf8-text = %d1-9 / ; Any Unicode character except for NUL, >| %d11 / ; CR and LF, encoded in UTF-8 >| %d12 / >| %d14-127 / >| UTFMB >| >| UTFMB = UTF2 / UTF3 / UTF4 > >I don't like this, it allows NO-WS-CTL. And the "UTFMB" isn't >used elsewhere. How about this: > > utf8-text = SP / VCHAR / UTF2 / UTF3 / UTF4 > > No HTAB then ;-)? _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 15:11:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaylB-0001Ef-It; Thu, 27 Sep 2007 15:10:53 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Iayl9-0001Cg-JI for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 15:10:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iayl9-0001CJ-8R for ima@ietf.org; Thu, 27 Sep 2007 15:10:51 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iayl8-0003lR-ND for ima@ietf.org; Thu, 27 Sep 2007 15:10:51 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 27 Sep 2007 20:10:49 +0100 Message-ID: <46FC003A.6020609@isode.com> Date: Thu, 27 Sep 2007 20:10:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Frank Ellermann Subject: Re: No issue # Re: [EAI] ISSUE: smtext-08 security considerations References: <46FBB5CD.8060305@alvestrand.no> In-Reply-To: <46FBB5CD.8060305@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; 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 Alvestrand wrote: > I do not see an issue specific to EAI here. > > MX paths can fail for all sorts of reasons, the combination of no > UTF8SMTP and no downgrade is just one of them. > > No issue # assigned. > > Frank Ellermann wrote: > >> I'm at a loss how section 7 passed any giggle test before WGLC. >> >> Without a thorough discussion why offering UTF8SMTP at the MX >> when it won't work out at the final delivery MTA is a really >> bad idea this I-D isn't ready for an IETF Last Call. Nobody >> wants *more* undeliverable mails causing misdirected bounces. >> >> That's likely not the only missing "security consideration", >> the very minumum I expect in an RFC is a honest attempt to >> discuss potential security issues. > Frank, if you want anything to be added I would recommend that you be more specific and suggest some text for inclusion. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 15:48:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IazKm-0004ti-J2; Thu, 27 Sep 2007 15:47:40 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IazKl-0004rL-9o for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 15:47:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IazKk-0004o7-Qs for ima@ietf.org; Thu, 27 Sep 2007 15:47:38 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IazKk-0004ok-6s for ima@ietf.org; Thu, 27 Sep 2007 15:47:38 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IazKZ-0006wf-6p for ima@ietf.org; Thu, 27 Sep 2007 19:47:27 +0000 Received: from 1cust133.tnt2.hbg2.deu.da.uu.net ([149.225.12.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 19:47:27 +0000 Received: from nobody by 1cust133.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 19:47:27 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Thu, 27 Sep 2007 21:46:55 +0200 Organization: http://purl.net/xyzzy Lines: 33 Message-ID: References: <46FBA71F.40302@alvestrand.no> 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: 1cust133.tnt2.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [EAI] Re: #1485 (closed) Re: ISSUE utf8 meaage/global X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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: > This message has been recorded as a comment on closed issue #1485. Your records of #1485 mainly document how you arrived at the names message/global etc. in 8BITMIME and UTF8SMTP environments. These names are fine, the issue is the violation of a rule in RFC 2045. I've checked the relevant RFCs (4288, 2046, 2045, and 2049) again. 1 - RFC 4288 says "message/* subtypes MUST follow RFC 2046 rules". 2 - RFC 2046 allows only 7bit/8bit/binary for multipart/* (sic!), it has no overall CTE restriction for any message/* (ignoring a lower case "should ASCII"). It has individual restrictions for the discussed subtypes rfc822, partial, and external-body. 3 - RFC 2046 and 2049 both say that an unknown message/* has to be handled like application/octet-stream. 4 - RFC 2045 has the famous "EXPRESSLY FORBIDDEN" about any CTEs different from 7bit, 8bit, and binary for all composite media types, especially for multipart/* (confirmed in RFC 2046) and for message/* (NOT confirmed in RFC 2046, where restrictions are obviously and intentionally listed per message/* subtype). 5 - By definition a 7bit MTA cannot "know" (=3D support) any subtype defined only for 8bit and binary. Therefore it must handle message/global and its variants like application/octet-stream. 6 - CTE B64 and QP are perfectly okay for application/octet-stream. Maybe the I-D should explain why the apparent violation of RFC 2045 is okay. Actually either RFC 2045 or 2046 must be incorrect, and picking RFC 2046 as correct makes sense. Maybe we should submit this issue as an erratum for RFC 2045. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 16:20:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IazqH-0001MV-8C; Thu, 27 Sep 2007 16:20:13 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IazqF-0001FT-7j for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 16:20:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IazqE-0001B4-UI for ima@ietf.org; Thu, 27 Sep 2007 16:20:10 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iazq6-0001RW-Na for ima@ietf.org; Thu, 27 Sep 2007 16:20:08 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iazoo-0002Ts-IF for ima@ietf.org; Thu, 27 Sep 2007 20:18:42 +0000 Received: from 1cust133.tnt2.hbg2.deu.da.uu.net ([149.225.12.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 20:18:42 +0000 Received: from nobody by 1cust133.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 20:18:42 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Thu, 27 Sep 2007 22:16:38 +0200 Organization: http://purl.net/xyzzy Lines: 17 Message-ID: References: <46FBFDF4.20108@isode.com> 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: 1cust133.tnt2.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [EAI] Re: ISSUE: dsn-03 utf8-text X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Alexey Melnikov wrote: >> utf8-text =3D SP / VCHAR / UTF2 / UTF3 / UTF4 > No HTAB then ;-)? ...oops :-) Please s/SP/WSP/ for this proposal. =20 If the utf8header I-D gets rid of utf8-quoted-pair it doesn't need its own utf8-text anymore. Therefore you could use a simplfied utf8-text for your purposes (the localized diagnostics) without fearing a conflict with the utf8header definition. Frank=20 _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 16:51:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib0K2-0005GS-65; Thu, 27 Sep 2007 16:50:58 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ib0K0-0005Ef-Cn for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 16:50:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib0K0-0005Cq-0t for ima@ietf.org; Thu, 27 Sep 2007 16:50:56 -0400 Received: from mail7.exchange.microsoft.com ([131.107.1.27] helo=mail.exchange.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ib0Jz-0006Uc-JA for ima@ietf.org; Thu, 27 Sep 2007 16:50:55 -0400 Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.54.216) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.1.206.1; Thu, 27 Sep 2007 13:50:54 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.8]) by df-bhd-01.exchange.corp.microsoft.com ([157.54.54.216]) with mapi; Thu, 27 Sep 2007 13:50:54 -0700 From: Yuri Inglikov To: Frank Ellermann , "ima@ietf.org" Date: Thu, 27 Sep 2007 13:50:51 -0700 Subject: RE: [EAI] Re: #1485 (closed) Re: ISSUE utf8 meaage/global Thread-Topic: [EAI] Re: #1485 (closed) Re: ISSUE utf8 meaage/global Thread-Index: AcgBP30NrsvPsDomRkWf8RaHxfWu8wABt5wg Message-ID: References: <46FBA71F.40302@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.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 Could we at least limit the maximum nesting of encoded message/global to on= e level? Implementations will likely need to put a cap on it anyway and lea= ving it open-ended can create interoperability issues. On the other hand, o= ne-level encoding should be sufficient to address all UTF8SMTP scenarios? Yuri -----Original Message----- From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] Sent: Thursday, September 27, 2007 12:47 PM To: ima@ietf.org Subject: [EAI] Re: #1485 (closed) Re: ISSUE utf8 meaage/global Harald Alvestrand wrote: > This message has been recorded as a comment on closed issue #1485. Your records of #1485 mainly document how you arrived at the names message/global etc. in 8BITMIME and UTF8SMTP environments. These names are fine, the issue is the violation of a rule in RFC 2045. I've checked the relevant RFCs (4288, 2046, 2045, and 2049) again. 1 - RFC 4288 says "message/* subtypes MUST follow RFC 2046 rules". 2 - RFC 2046 allows only 7bit/8bit/binary for multipart/* (sic!), it has no overall CTE restriction for any message/* (ignoring a lower case "should ASCII"). It has individual restrictions for the discussed subtypes rfc822, partial, and external-body. 3 - RFC 2046 and 2049 both say that an unknown message/* has to be handled like application/octet-stream. 4 - RFC 2045 has the famous "EXPRESSLY FORBIDDEN" about any CTEs different from 7bit, 8bit, and binary for all composite media types, especially for multipart/* (confirmed in RFC 2046) and for message/* (NOT confirmed in RFC 2046, where restrictions are obviously and intentionally listed per message/* subtype). 5 - By definition a 7bit MTA cannot "know" (=3D support) any subtype defined only for 8bit and binary. Therefore it must handle message/global and its variants like application/octet-stream. 6 - CTE B64 and QP are perfectly okay for application/octet-stream. Maybe the I-D should explain why the apparent violation of RFC 2045 is okay. Actually either RFC 2045 or 2046 must be incorrect, and picking RFC 2046 as correct makes sense. Maybe we should submit this issue as an erratum for RFC 2045. 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 Thu Sep 27 16:57:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib0Pa-0004BD-6a; Thu, 27 Sep 2007 16:56:42 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ib0PZ-00049D-0b for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 16:56:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib0PY-000481-LZ for ima@ietf.org; Thu, 27 Sep 2007 16:56:40 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ib0PY-0006cJ-7j for ima@ietf.org; Thu, 27 Sep 2007 16:56:40 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ib0PN-0006lt-Be for ima@ietf.org; Thu, 27 Sep 2007 20:56:29 +0000 Received: from 1cust133.tnt2.hbg2.deu.da.uu.net ([149.225.12.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 20:56:29 +0000 Received: from nobody by 1cust133.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 20:56:29 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Thu, 27 Sep 2007 22:54:25 +0200 Organization: http://purl.net/xyzzy Lines: 25 Message-ID: References: <7F7A21F0CD318D347D9BD263@klensin-asus.dnvrairport.denveco.wayport.net> <46FB9A10.9050500@alvestrand.no> 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: 1cust133.tnt2.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [EAI] Re: REVIEW: draft-ietf-eai-smtpext-08.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 Harald Alvestrand wrote: >> No :-) The DSN has to go to the "originator as indicated >> in the Return Path", therefore the MTA has to be confident >> that the Return Path in fact indicates the originator. [...] =20 > Out of scope for this WG to change mail's behaviour in that > way, Frank. Just citing one of the most important statements in RFC 2821 and its logical consequences, when Charles and John discussed that receivers are free to assume that Return-Paths are okay. > And you knew that already... ...and John knows that I managed to read the right hand side of the first non-empty line in RFC 2821, there should be no problem with a joke here. For the less funny sides of it=20 see on the SMTP list. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 17:19:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib0ku-00044Q-Ul; Thu, 27 Sep 2007 17:18:44 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ib0ks-00040w-UN for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 17:18:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib0ks-00040m-Jy for ima@ietf.org; Thu, 27 Sep 2007 17:18:42 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ib0ks-00079h-8L for ima@ietf.org; Thu, 27 Sep 2007 17:18:42 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ib0ki-0000U9-4s for ima@ietf.org; Thu, 27 Sep 2007 21:18:32 +0000 Received: from 1cust133.tnt2.hbg2.deu.da.uu.net ([149.225.12.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 21:18:32 +0000 Received: from nobody by 1cust133.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 21:18:32 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Thu, 27 Sep 2007 23:18:08 +0200 Organization: http://purl.net/xyzzy Lines: 17 Message-ID: References: <46FBB5CD.8060305@alvestrand.no> <46FC003A.6020609@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust133.tnt2.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [EAI] Re: No issue # Re: ISSUE: smtext-08 security considerations X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Alexey Melnikov wrote: =20 > if you want anything to be added I would recommend that you be=20 > more specific and suggest some text for inclusion. Okay, that's fair, one suggestion, in addition to the security considerations already covered in RFC 4592: | The optional ALT-ADDRESS parameter allows to use unrelated | domains in the UTF8SMTP address and the alternative address, | i.e. the alternative domain is not guaranteed to be the IDNA | ACE version of the IDNA UTF-8 domain in the UTF8SMTP address. | The study of the security implications of this freedom in the | choice of alternative addresses is one goal of the experiment | specified in this memo. Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Thu Sep 27 17:33:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib0z9-0002Yk-Ok; Thu, 27 Sep 2007 17:33:27 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ib0z8-0002Yd-Af for ima-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 17:33:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib0z8-0002S0-15 for ima@ietf.org; Thu, 27 Sep 2007 17:33:26 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib0yx-000308-Oz for ima@ietf.org; Thu, 27 Sep 2007 17:33:21 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ib0yh-0001kj-Dz for ima@ietf.org; Thu, 27 Sep 2007 21:32:59 +0000 Received: from 1cust133.tnt2.hbg2.deu.da.uu.net ([149.225.12.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 21:32:59 +0000 Received: from nobody by 1cust133.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 21:32:59 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Thu, 27 Sep 2007 23:32:26 +0200 Organization: http://purl.net/xyzzy Lines: 12 Message-ID: References: <46FBA71F.40302@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust133.tnt2.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [EAI] Re: Re: #1485 (closed) Re: ISSUE utf8 meaage/global X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Yuri Inglikov wrote: > Could we at least limit the maximum nesting of encoded message/global > to one level? Indeed, doing it bottom-up would be unwise, top-down B64 once per message/global part (including its complete body) is good enough. Maybe the I-D could RECOMMEND this recipe, or is this an obvious implementation detail ? Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 28 04:01:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbAmG-0005VC-6J; Fri, 28 Sep 2007 04:00:48 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IbAmF-0005TR-Ah for ima-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 04:00:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbAmE-0005TH-Aw for ima@ietf.org; Fri, 28 Sep 2007 04:00:47 -0400 Received: from mail1.exchange.microsoft.com ([131.107.1.17] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbAm8-0000CS-58 for ima@ietf.org; Fri, 28 Sep 2007 04:00:46 -0400 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server (TLS) id 8.1.206.1; Fri, 28 Sep 2007 01:00:29 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.8]) by df-bhd-02.exchange.corp.microsoft.com ([157.54.71.155]) with mapi; Fri, 28 Sep 2007 01:00:29 -0700 From: Yuri Inglikov To: Frank Ellermann , "ima@ietf.org" Date: Fri, 28 Sep 2007 01:00:12 -0700 Subject: RE: [EAI] Re: Re: #1485 (closed) Re: ISSUE utf8 meaage/global Thread-Topic: [EAI] Re: Re: #1485 (closed) Re: ISSUE utf8 meaage/global Thread-Index: AcgBTl02p7m+qQA3TGiUFL84zbbFGgAVbVfQ Message-ID: References: <46FBA71F.40302@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org Ah, if this is an "obvious implementation detail", or even if this is just = "a recommendation", then anybody needs to be prepared to handle arbitrary n= esting. It should be completely prohibited to have any effect, like in that= famous "EXPRESSLY FORBIDDEN" statement. Trivial (and often the only feasib= le) implementation of decoding nested encoded messages has quadratic comple= xity. It is unwise to define such "feature" in e-mail standard. -----Original Message----- From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] Sent: Thursday, September 27, 2007 2:32 PM To: ima@ietf.org Subject: [EAI] Re: Re: #1485 (closed) Re: ISSUE utf8 meaage/global Yuri Inglikov wrote: > Could we at least limit the maximum nesting of encoded message/global > to one level? Indeed, doing it bottom-up would be unwise, top-down B64 once per message/global part (including its complete body) is good enough. Maybe the I-D could RECOMMEND this recipe, or is this an obvious implementation detail ? Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 28 05:58:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbCbK-0003jF-RB; Fri, 28 Sep 2007 05:57:38 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IbCbK-0003j3-6T for ima-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 05:57:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbCbJ-0003iv-S8 for ima@ietf.org; Fri, 28 Sep 2007 05:57:37 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbCbI-000380-H1 for ima@ietf.org; Fri, 28 Sep 2007 05:57:37 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DF2512596EA; Fri, 28 Sep 2007 11:57:30 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19818-08; Fri, 28 Sep 2007 11:57:22 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D1B902596EB; Fri, 28 Sep 2007 11:57:19 +0200 (CEST) Message-ID: <46FCCFFF.1030709@alvestrand.no> Date: Fri, 28 Sep 2007 11:57:19 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Yuri Inglikov Subject: Re: [EAI] Re: Re: #1485 (closed) Re: ISSUE utf8 meaage/global References: <46FBA71F.40302@alvestrand.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.9 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Yuri Inglikov wrote: > Ah, if this is an "obvious implementation detail", or even if this is just "a recommendation", then anybody needs to be prepared to handle arbitrary nesting. It should be completely prohibited to have any effect, like in that famous "EXPRESSLY FORBIDDEN" statement. Agreed on that. If we accept the current proposal, I don't expect double encoding to happen much in practice - the main case I can think of offhand would be someone in UTF8 land who gets a message/rfc822 with parts using Q-P or base64, forwards that message to another UTF8 user (which doesn't impose any encoding), and the second user then forwards the whole message as a message/global to a non-UTF8 user. Pass the message around the same circle once more to get a triple encoding. (If the UTF8 user just forwards the first 822 message to an ASCII user, the outer message gets downgraded to message/rfc822, and no double encoding of the inner message happens; you need 2 levels of forwarding to get a double encoding.) > Trivial (and often the only feasible) implementation of decoding nested encoded messages has quadratic complexity. It is unwise to define such "feature" in e-mail standard. > quadratic in what? I believe that if your language-of-choice supports queues and either cheap threads or coroutines, there's a fairly trivial implementation that's linear in the number of levels of encoding (a message part that is doubly encoded needs twice the processing power of a message that's singly encoded). > -----Original Message----- > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: Thursday, September 27, 2007 2:32 PM > To: ima@ietf.org > Subject: [EAI] Re: Re: #1485 (closed) Re: ISSUE utf8 meaage/global > > Yuri Inglikov wrote: > > >> Could we at least limit the maximum nesting of encoded message/global >> to one level? >> > > Indeed, doing it bottom-up would be unwise, top-down B64 once per > message/global part (including its complete body) is good enough. > > Maybe the I-D could RECOMMEND this recipe, or is this an obvious > implementation detail ? > > 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 > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 28 09:12:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFd3-0002UC-Rx; Fri, 28 Sep 2007 09:11:37 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IbFd3-0002U4-60 for ima-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 09:11:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbFd2-0002Tw-SU for ima@ietf.org; Fri, 28 Sep 2007 09:11:36 -0400 Received: from lon-mail-4.gradwell.net ([193.111.201.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbFcx-0008Ee-EG for ima@ietf.org; Fri, 28 Sep 2007 09:11:36 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3^clerew&man*ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.257) id 46fcfd6e.4ab7.38e for ima@ietf.org; Fri, 28 Sep 2007 14:11:10 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l8SDB8Wa000750 for ; Fri, 28 Sep 2007 14:11:10 +0100 (BST) Date: Fri, 28 Sep 2007 10:37:41 +0100 From: "Charles Lindsey" To: "Charles Lindsey" References: Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) Resent-To: IMA Resent-From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Resent-Date: Fri, 28 Sep 2007 14:11:08 +0100 Resent-Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Subject: [EAI] #1505 Can we alter MIME 1.0? X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ima-bounces@ietf.org Errors-To: ima-bounces@ietf.org On Wed, 26 Sep 2007 17:54:53 +0100, Charles Lindsey wrote: > On Tue, 25 Sep 2007 18:50:25 +0100, Frank Ellermann > wrote: > >> | This document also updates [RFC2822] and MIME >> >> Ditto, an "experimental update" of RFC 2822 is okay, >> but touching MIME (excl. the separate issue above) >> is IMO unnecessary and too dangerous. >> This is the essential matter behind the new ISSUE 1505. The others are just details. My opinion is to leave it as in the present drafts, and my reasons are best summarized by my earlier reply to Frank, repeated below. If we are trying to allow UTF-8 in headers rather than messy encodings into 7bit ASCII, then we need to allow them in ALL appropriate headers WHEREVER they occur: > > But cannot be avoided. The whole purpose of our endeavour is to get rid > of the need for funny encodings (whether RFC 2047 or RFC 2231) in > headers, and if we exclude the body-part headers ffrom that, then we > shall have failed utterly in our prime objective. > > You cannot say that > Content-Description: mañana > or > Content-Disposition: attachment; filename=mañana > are allowed at the top level of a message, but not in MIME objects lower > down. The world will just never learn to make such non-obvious > distinctions. As to detecting whether a message uses our extensions (including within extended MIME objects), there are three alternatives: 1. REQUIRE a special header (e.g. Header-Type) at the top level. 2. REQUIRE a recursive search through the message looking for use of extensions 3. REQUIRE both of the above If properly implemented, all those methods are technically correct. The WG discussed this a while back and the consensus was to speciy #2. Although that was not my preference, I am not calling for that to be reviwed (though others may). > As to whether the particular case of message/global as proposed will > pass through the existing network, that is a separate technical ISSUE > which needs to be studied and resolved separately. > So, for discussion of this thread, let us assume that message/global WILL magically work, or that it will be made to work somehow. It is a separate issue which has attracted some discussion (and will undoubtedly arise again), but it is not officially on our current agenda. So keep it out of #1505. -- 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 Sep 28 11:27:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbHjh-0006Of-3K; Fri, 28 Sep 2007 11:26:37 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IbHjf-0006Ex-JD for ima-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 11:26:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbHjf-0006En-8u for ima@ietf.org; Fri, 28 Sep 2007 11:26:35 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbHje-0001nD-UH for ima@ietf.org; Fri, 28 Sep 2007 11:26:35 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IbHiu-000344-VG for ima@ietf.org; Fri, 28 Sep 2007 15:25:48 +0000 Received: from 1cust91.tnt1.hbg2.deu.da.uu.net ([149.225.10.91]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Sep 2007 15:25:48 +0000 Received: from nobody by 1cust91.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Sep 2007 15:25:48 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Fri, 28 Sep 2007 17:24:14 +0200 Organization: http://purl.net/xyzzy Lines: 17 Message-ID: References: <46FBA71F.40302@alvestrand.no> <46FCCFFF.1030709@alvestrand.no> 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: 1cust91.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [EAI] Re: #1485 (closed) Re: ISSUE utf8 meaage/global X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 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: =20 > I believe that if your language-of-choice supports queues and either=20 > cheap threads or coroutines, there's a fairly trivial implementation=20 > that's linear in the number of levels of encoding (a message part that = > is doubly encoded needs twice the processing power of a message that's = > singly encoded). We could have a situation if the MUA is smarter in decoding than the AV software before this MUA. A new point for the security considerations in the utfheaders I-D, the bad guys will try to abuse this feature of message/global. =20 Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 28 11:54:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIA2-0006Ur-VG; Fri, 28 Sep 2007 11:53:50 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IbIA1-0006Lh-CT for ima-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 11:53:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbIA0-0006LD-N1 for ima@ietf.org; Fri, 28 Sep 2007 11:53:48 -0400 Received: from mail1.exchange.microsoft.com ([131.107.1.17] helo=mail.exchange.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbIA0-0003Yb-4Q for ima@ietf.org; Fri, 28 Sep 2007 11:53:48 -0400 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server (TLS) id 8.1.206.1; Fri, 28 Sep 2007 08:53:47 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.8]) by df-bhd-02.exchange.corp.microsoft.com ([157.54.71.155]) with mapi; Fri, 28 Sep 2007 08:53:47 -0700 From: Yuri Inglikov To: Harald Alvestrand Date: Fri, 28 Sep 2007 08:53:41 -0700 Subject: RE: [EAI] Re: Re: #1485 (closed) Re: ISSUE utf8 meaage/global Thread-Topic: [EAI] Re: Re: #1485 (closed) Re: ISSUE utf8 meaage/global Thread-Index: AcgBtjgP35kVHLqGThmjIsJMWD5EnQALZBUA Message-ID: References: <46FBA71F.40302@alvestrand.no> <46FCCFFF.1030709@alvestrand.no> In-Reply-To: <46FCCFFF.1030709@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 >> there's a fairly trivial implementation that's linear in the number of l= evels of encoding Complexity of decoding each level is proportional to its length, not consta= nt. The overall complexity is something like O(n*m) where n is size of oute= r MIME in bytes and m is the number of nested levels. Intuitively it is obv= ious as you need to touch every byte of most nested encoding m times to dec= ode it. In extreme the m can be pretty close to n, hence the quadratic comp= lexity. I can imagine a linear complexity implementation if I speculate tha= t there is a decode(b) operation which can be implemented in a constant = time, but I am not sure how feasible such operation can be, considering art= ifacts like arbitrary folding of nested encoded content and mixing 2 encodi= ng schemes. I would be very curious to see a trivial O(n) implementation of= arbitrarily nested decoding. Please don't allow this. -----Original Message----- From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Friday, September 28, 2007 2:57 AM To: Yuri Inglikov Cc: Frank Ellermann; ima@ietf.org Subject: Re: [EAI] Re: Re: #1485 (closed) Re: ISSUE utf8 meaage/global Yuri Inglikov wrote: > Ah, if this is an "obvious implementation detail", or even if this is jus= t "a recommendation", then anybody needs to be prepared to handle arbitrary= nesting. It should be completely prohibited to have any effect, like in th= at famous "EXPRESSLY FORBIDDEN" statement. Agreed on that. If we accept the current proposal, I don't expect double encoding to happen much in practice - the main case I can think of offhand would be someone in UTF8 land who gets a message/rfc822 with parts using Q-P or base64, forwards that message to another UTF8 user (which doesn't impose any encoding), and the second user then forwards the whole message as a message/global to a non-UTF8 user. Pass the message around the same circle once more to get a triple encoding. (If the UTF8 user just forwards the first 822 message to an ASCII user, the outer message gets downgraded to message/rfc822, and no double encoding of the inner message happens; you need 2 levels of forwarding to get a double encoding.) > Trivial (and often the only feasible) implementation of decoding nested e= ncoded messages has quadratic complexity. It is unwise to define such "feat= ure" in e-mail standard. > quadratic in what? I believe that if your language-of-choice supports queues and either cheap threads or coroutines, there's a fairly trivial implementation that's linear in the number of levels of encoding (a message part that is doubly encoded needs twice the processing power of a message that's singly encoded). > -----Original Message----- > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: Thursday, September 27, 2007 2:32 PM > To: ima@ietf.org > Subject: [EAI] Re: Re: #1485 (closed) Re: ISSUE utf8 meaage/global > > Yuri Inglikov wrote: > > >> Could we at least limit the maximum nesting of encoded message/global >> to one level? >> > > Indeed, doing it bottom-up would be unwise, top-down B64 once per > message/global part (including its complete body) is good enough. > > Maybe the I-D could RECOMMEND this recipe, or is this an obvious > implementation detail ? > > 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 > > _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 28 14:46:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKqy-0002LK-Vl; Fri, 28 Sep 2007 14:46:20 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IbKqw-0002He-LC for ima-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 14:46:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbKqw-0002ES-9d for ima@ietf.org; Fri, 28 Sep 2007 14:46:18 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbKqv-0000Rl-H7 for ima@ietf.org; Fri, 28 Sep 2007 14:46:18 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IbKqu-000Ie5-KR; Fri, 28 Sep 2007 14:46:16 -0400 Date: Fri, 28 Sep 2007 14:46:15 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: No issue # Re: ISSUE: smtext-08 security considerations Message-ID: <40BF919CEF6264216A2A157C@p3.JCK.COM> In-Reply-To: References: <46FBB5CD.8060305@alvestrand.no> <46FC003A.6020609@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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, 27 September, 2007 23:18 +0200 Frank Ellermann wrote: > Alexey Melnikov wrote: > =20 >> if you want anything to be added I would recommend that you >> be more specific and suggest some text for inclusion. >=20 > Okay, that's fair, one suggestion, in addition to the security > considerations already covered in RFC 4592: >=20 > | The optional ALT-ADDRESS parameter allows to use unrelated > | domains in the UTF8SMTP address and the alternative address, > | i.e. the alternative domain is not guaranteed to be the IDNA > | ACE version of the IDNA UTF-8 domain in the UTF8SMTP = address. > | The study of the security implications of this freedom in = the > | choice of alternative addresses is one goal of the = experiment > | specified in this memo. Frank, as has been pointed out several times in the development of the current model, there are legitimate reasons why the domain might be different. For example, one might imagine a whole collection of content-translation services that would do some of the remappings that one might want along with simple address/ header downgrading on a commercial or service basis. So, while a different domain might represent something one might warn against, the implication that it is inherently bad news --which your paragraph almost does-- is a bit too much. Perhaps: The optional ALT-ADDRESS parameter allows the use of UTF8SMTP addresses and alternate addresses that are not related to each other in any obvious algorithmic way. There is no requirement that the alternate local-part be, e.g., a translations or transliteration of the UTF8SMTP local part nor that the alternate domain part be the IDNA ACE version of the IDNA UTF-8 domain part. The flexibility this implies appears to be necessary because a number of reasonable configuration relationships cannot easily be reflected in DNS or syntax relationships. However, like all other in-transit transformations of message bodies (such as those performed by gateways), the same flexibility provides a potential vector for attacks. During the experiment proposed in this set of documents, careful attention should be paid to whether the risks associated with, e.g., use of ALT-ADDRESS to divert messages to unexpected destinations are significantly more problematic and email address spoofing more generally. That is a lot more words than your proposal, for which I apologize (perhaps someone else can do better), but covers the same basic ground and points out that there is no less problem with the local-part (e.g., is fred@example.com related to Fr=C3=A9d=C3=A9ric@example.com or not?). It also avoids = statements about what the experiment is. I would prefer to avoid that at this point, at least without reissuing "framework" (RFC 4932), but I think the paragraph makes the point. john p.s. So that no one is surprised and to give an early opportunity for objections (ask Harald for an Issue number if you do): I argued on a recent editorial team call that material that would have been been placed in RFC 4932 if we had understood the need for it before that document was completed should be placed in "updates RFC 4932" appendices to these documents rather than being incorporated inline in the newer documents. Examples include the material in sections 3-5 of smtpext that might better have been placed in RFC 4932, updating the relevant sections there and security considerations material that applies, not to a single document of the series but to multiple documents in the collection. That separation has no substantive effect on the protocol specification or explanations, but will make it much easier to re-integrate the material into RFC 4932bis when we start on it as part of the post-experiment process (assuming, of course, that we get = there). _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 28 16:24:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbMMr-0001VL-Od; Fri, 28 Sep 2007 16:23:21 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IbMMq-0001Kc-GO for ima-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 16:23:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbMMp-0000va-H2 for ima@ietf.org; Fri, 28 Sep 2007 16:23:19 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbMMm-0003Bt-Mu for ima@ietf.org; Fri, 28 Sep 2007 16:23:17 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IbMMb-0003K4-69 for ima@ietf.org; Fri, 28 Sep 2007 20:23:05 +0000 Received: from 1cust91.tnt1.hbg2.deu.da.uu.net ([149.225.10.91]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Sep 2007 20:23:05 +0000 Received: from nobody by 1cust91.tnt1.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Sep 2007 20:23:05 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Fri, 28 Sep 2007 22:22:36 +0200 Organization: http://purl.net/xyzzy Lines: 73 Message-ID: References: <46FBB5CD.8060305@alvestrand.no> <46FC003A.6020609@isode.com> <40BF919CEF6264216A2A157C@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust91.tnt1.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [EAI] Re: No issue # Re: ISSUE: smtext-08 security considerations X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org John C Klensin wrote: > while a different domain might represent something one might > warn against, the implication that it is inherently bad news > --which your paragraph almost does-- is a bit too much. It's not necessarily bad news. If the different domains use the same MXs it's a sound "Return-Path" scenario. Something on a route from A to B doesn't work, and MTA X on this route is forced to report an error. At this point the A -> X part of the rout A -> X -> B worked, and I'd hope that a NDR will make it back from X to A. If the envelope sender (UTF8SMTP or alt-address) is unrelated to A, say C !=3D A, then the NDR has to make it from X to this unrelated C, where it might meet new trouble between X and C. Introducing new potential sources of errors while trying to report and fix the original problem between X and B would be an inherently bad idea. Of course that's a general consideration, it's no specific problem with the UTF8SMTP "alternate envelope sender" option. [Your proposal] > The optional ALT-ADDRESS parameter allows the use of > UTF8SMTP addresses and alternate addresses that are not > related to each other in any obvious algorithmic way. There > is no requirement that the alternate local-part be, e.g., a > translations or transliteration of the UTF8SMTP local part > nor that the alternate domain part be the IDNA ACE version > of the IDNA UTF-8 domain part. The flexibility this implies > appears to be necessary because a number of reasonable > configuration relationships cannot easily be reflected in > DNS or syntax relationships. In theory we could recommend "same MXs", but in practice I fear this would unnecessarily obscure the issues. And we'd certainly not want somebody trying to enforce this detail. > However, like all other > in-transit transformations of message bodies (such as those > performed by gateways), the same flexibility provides a > potential vector for attacks. During the experiment > proposed in this set of documents, careful attention should > be paid to whether the risks associated with, e.g., use of > ALT-ADDRESS to divert messages to unexpected destinations > are significantly more problematic and email address > spoofing more generally. Sounds good. > It also avoids statements about what the experiment is. I > would prefer to avoid that at this point, at least without > reissuing "framework" (RFC 4932), but I think the paragraph > makes the point. Yes, s/4932/4952/g :-) > re-integrate the material into RFC 4932bis when we start on > it as part of the post-experiment process That's still too far away for me to think about it. We'll then have 2821bis, 2822upd, IDNAbis, mailto-bis, and what else, and a different email world with EAI, DKIM, SPF, etc. (email-arch, hutzler-spamops, 4409upd, ...). If you're looking for more work please insert 3696bis before 4952bis, just today I needed RFC 3696 again on another list: Frank _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 28 17:40:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNZ7-0000vv-2C; Fri, 28 Sep 2007 17:40:05 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IbNZ6-0000rU-9V for ima-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 17:40:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNZ5-0000r6-Vj; Fri, 28 Sep 2007 17:40:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbNZ4-0006uF-G9; Fri, 28 Sep 2007 17:40:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 66C803289E; Fri, 28 Sep 2007 21:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IbNZ4-0002e5-9V; Fri, 28 Sep 2007 17:40:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 28 Sep 2007 17:40:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ima@ietf.org Subject: [EAI] I-D Action:draft-ietf-eai-dsn-04.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email Address Internationalization Working Group of the IETF. Title : International Delivery and Disposition Notifications Author(s) : C. Newman, A. Melnikov Filename : draft-ietf-eai-dsn-04.txt Pages : 16 Date : 2007-09-28 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. This document experimentally extends RFC 3461, RFC 3464 and RFC 3798. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eai-dsn-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eai-dsn-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eai-dsn-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-09-28173339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eai-dsn-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eai-dsn-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-28173339.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 Sep 28 18:58:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbOm6-0005Cs-4C; Fri, 28 Sep 2007 18:57:34 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IbOm4-0005Am-S2 for ima-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 18:57:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbOm4-0005Ae-IO for ima@ietf.org; Fri, 28 Sep 2007 18:57:32 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbOly-0000BQ-B1 for ima@ietf.org; Fri, 28 Sep 2007 18:57:32 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IbOls-000Oqf-F0; Fri, 28 Sep 2007 18:57:20 -0400 Date: Fri, 28 Sep 2007 18:57:19 -0400 From: John C Klensin To: Frank Ellermann , ima@ietf.org Subject: Re: [EAI] Re: No issue # Re: ISSUE: smtext-08 security considerations Message-ID: <5BC14245CF6D2C30F020F4B1@p3.JCK.COM> In-Reply-To: References: <46FBB5CD.8060305@alvestrand.no> <46FC003A.6020609@isode.com> <40BF919CEF6264216A2A157C@p3.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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, 28 September, 2007 22:22 +0200 Frank Ellermann wrote: >... > If you're looking for more work please insert 3696bis before > 4952bis, just today I needed RFC 3696 again on another list: > I'm completely overwhelmed by what is in the queue already so, no, I'm not looking for more work. I would probably get motivated about 3696bis if, after the queues cleared somewhat, I saw fairly clear consensus on the IETF list that the community wanted a revision... perhaps wanted it enough to make the revision a BCP. john _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 28 21:01:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbQgz-0006Dv-5j; Fri, 28 Sep 2007 21:00:25 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IbQgy-0006Dp-Gw for ima-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 21:00:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbQgy-00064X-7D for ima@ietf.org; Fri, 28 Sep 2007 21:00:24 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbQgn-00029T-02 for ima@ietf.org; Fri, 28 Sep 2007 21:00:19 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IbQfd-0006Sn-Bk for ima@ietf.org; Sat, 29 Sep 2007 00:59:01 +0000 Received: from 1cust176.tnt2.hbg2.deu.da.uu.net ([149.225.12.176]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 29 Sep 2007 00:59:01 +0000 Received: from nobody by 1cust176.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 29 Sep 2007 00:59:01 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ima@ietf.org From: "Frank Ellermann" Date: Sat, 29 Sep 2007 02:57:17 +0200 Organization: http://purl.net/xyzzy Lines: 10 Message-ID: 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: 1cust176.tnt2.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [EAI] Re: I-D Action:draft-ietf-eai-dsn-04.txt (#1507) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ima-bounces@ietf.org > Filename : draft-ietf-eai-dsn-04.txt Hi, I think that's ready when we have decided what to do about its utf8-text . I've added a comment to #1507. Frank P.S., typo, s/doesn't contains/doesn't contain/ in section 3. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Fri Sep 28 22:07:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbRjJ-0005Id-BZ; Fri, 28 Sep 2007 22:06:53 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1IbNTQ-0007Lx-TY for ima-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 17:34:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbNTQ-0007Lo-IL for ima@ietf.org; Fri, 28 Sep 2007 17:34:12 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IbNTQ-0008Td-Au for ima@ietf.org; Fri, 28 Sep 2007 17:34:12 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 03D66175AA; Fri, 28 Sep 2007 21:33:42 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IbNSv-0004ej-HM; Fri, 28 Sep 2007 17:33:41 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: alexey.melnikov@isode.com From: IETF I-D Submission Tool Message-Id: Date: Fri, 28 Sep 2007 17:33:41 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Fri, 28 Sep 2007 22:06:51 -0400 Cc: Alexey.Melnikov@isode.com, ima@ietf.org Subject: [EAI] New Version Notification for draft-ietf-eai-dsn-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 A new version of I-D, draft-ietf-eai-dsn-04.txt has been successfuly submitted by Alexey Melnikov and posted to the IETF repository. Filename: draft-ietf-eai-dsn Revision: 04 Title: International Delivery and Disposition Notifications Creation_date: 2007-09-28 WG ID: eai Number_of_pages: 16 Abstract: 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. This document experimentally extends RFC 3461, RFC 3464 and RFC 3798. The IETF Secretariat. _______________________________________________ IMA mailing list IMA@ietf.org https://www1.ietf.org/mailman/listinfo/ima From ima-bounces@ietf.org Sat Sep 29 22:54:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibove-0005Ds-Cy; Sat, 29 Sep 2007 22:53:10 -0400 Received: from ima by megatron.ietf.org with local (Exim 4.43) id 1Ibovd-0005Dn-DD for ima-confirm+ok@megatron.ietf.org; Sat, 29 Sep 2007 22:53:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibovd-0005CX-2v for ima@ietf.org; Sat, 29 Sep 2007 22:53:09 -0400 Received: from smtp.cnnic.cn ([159.226.7.146] helo=cnnic.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IbovX-0004u5-0S for ima@ietf.org; Sat, 29 Sep 2007 22:53:03 -0400 Received: (eyou send program); Sun, 30 Sep 2007 10:52:59 +0800 Message-ID: <391120779.26784@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO yaojk) (218.241.111.35) by 159.226.7.146 with SMTP; Sun, 30 Sep 2007 10:52:59 +0800 Message-ID: <050901c8030c$ff1d99c0$236ff1da@yaojk> From: "YAO Jiankang" To: "SM" References: <389619830.09132@cnnic.cn> Subject: response code 550 VS 553 Re: [EAI] REVIEW: draft-ietf-eai-smtpext-08.txt Date: Sun, 30 Sep 2007 10:52:53 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ima@ietf.org X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1175579856==" Errors-To: ima-bounces@ietf.org --===============1175579856== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNNIiA8c21AcmVzaXN0b3Iu bmV0Pg0KVG86IDxpbWFAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDEzLCAy MDA3IDE6NTEgQU0NClN1YmplY3Q6IFtFQUldIFJFVklFVzogZHJhZnQtaWV0Zi1lYWktc210cGV4 dC0wOC50eHQgDQoNCg0KPiBJbiBTZWN0aW9uIDIuNS4gIEFMVC1BRERSRVNTIHBhcmFtZXRlciB1 c2FnZSBhbmQgcmVzcG9uc2UgY29kZXM6DQo+IA0KPiAgICJXaGVuIG1lc3NhZ2VzIGFyZSByZWpl Y3RlZCBiZWNhdXNlIHRoZXkgcmVxdWlyZSBVVEY4U01UUCwgdGhlDQo+ICAgIHJlc3BvbnNlIGNv ZGUgIjU1MCIgaXMgdXNlZCwgZGVmaW5lZCBpbiBbUkZDMjgyMV0sIG1lYW5pbmcgIm1haWxib3gN Cj4gICAgdW5hdmFpbGFibGUiLiAgSWYgZW5oYW5jZWQgbWFpbCBzeXN0ZW0gc3RhdHVzIGNvZGVz IFtSRkMzNDYzXSBhcmUiDQo+IA0KPiBTaG91bGRuJ3QgdGhhdCBiZSBhICI1NTMiLCBpLmUuIG1h aWxib3ggbmFtZSBub3QgYWxsb3dlZD8NCj4gDQoNCkFmdGVyIGRpc2N1c3Npb24gd2l0aCBzb21l IGVkaXRvcnMsIHdlIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyB0ZXh0Og0KDQoNCndoZW4gbWVzc2Fn ZXMgYXJlIHJlamVjdGVkIGJlY2F1c2UgdGhlIFJDUFQgVE8gcmVxdWlyZXMgYW4gQUxULUFERFJF UywgdGhlIHJlc3BvbnNlIGNvZGUgNTUzIGlzIHVzZWQuIFdoZW4gbWVzc2FnZXMgYXJlIHJlamVj dGVkIGZvciBvdGhlciByZWFzb25zLCBzdWNoIGFzIE1BSUwgRlJPTSByZXF1aXJpbmcgYW4gQUxU LUFERFJFU1MsIHRoZSByZXNwb25zZSBjb2RlIDU1MCBpcyB1c2VkLg0KDQphbnkgZnVydGhlciBy ZWZpbmVtZW50cz8NCg0KWUFPIEppYW5rYW5nDQpDTk5JQw0KDQoNCg0KDQo+IA0KPiBSZWdhcmRz LA0KPiAtc20gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IElNQSBtYWlsaW5nIGxpc3QNCj4gSU1BQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ0KPg== --===============1175579856== 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 --===============1175579856==--