From klensin@jck.com Thu Sep 6 07:42:22 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3646021F849C for ; Thu, 6 Sep 2012 07:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjR0d-2Cw5gA for ; Thu, 6 Sep 2012 07:42:21 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id A4F2521F8448 for ; Thu, 6 Sep 2012 07:42:21 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T9dHh-000PPS-3L for ima@ietf.org; Thu, 06 Sep 2012 10:42:21 -0400 Date: Thu, 06 Sep 2012 10:42:16 -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 Subject: [EAI] Pre-Last Call comments from Pete and Barry -one action item for the WG X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:42:22 -0000 Hi. Proving that every careful reading by a new set of eyes, Pete and Barry found some small issues with the documents even after our careful reviews and revisions. To bring everyone up to date and ask a question: Barry's comments have been reflected in draft-ietf-eai-5738bis-09 Pete's comments are mostly editorial and uncontroversial. We've agreed to carry all of them forward into Last Call and to give the RFC Editor instructions to pay attention to them and apply fixes as needed. The exception is that Pete had two substantive comments about draft-ietf-eai-popimap-downgrade. They are: > 1. In section 3.1.7: Is there supposed to be a space (" ") > between display-name and ENCODED_WORD? Also, if this is > supposed to be ABNF, it needs a left hand side, and > ENCODED_WORD should be in angle brackets. > > 2. In section 3.1.9: Typed addresses do not appear in header > fields as far as I know. They only appear in DSN bodies. Why > are they specified here? See also 3.2.2. We've agreed that it is ok to go into Last Call on these two documents with those issues as no more than questions, i.e., without waiting for a new document revision. However, I'd appreciate comments from the author about what should be done about those two issues and enough comments from others that we can be confident that the WG is in agreement with any changes. Those changes, plus any of the editorial ones that seem worth fixing before the document gets to the RFC Editor, should be incorporated into a revised draft after other Last Call comments are considered and before the IESG starts voting. john p.s. the Mailinglist draft is on the IESG ballot for a week from today. So far, we have we have three "yes" votes, one "no objection" and silence from the others (not unusual at this point). Given that there were zero Last Call comments that required any changes and that the document provides a detailed discussion of issues rather than specifying a protocol, I'm hopeful that it will go through with a minimum of [further] fuss. From iesg-secretary@ietf.org Thu Sep 6 08:04:22 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371AA21F86C7; Thu, 6 Sep 2012 08:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRQgupG1oLkx; Thu, 6 Sep 2012 08:04:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A854321F852C; Thu, 6 Sep 2012 08:04:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120906150421.17077.56344.idtracker@ietfa.amsl.com> Date: Thu, 06 Sep 2012 08:04:21 -0700 Cc: ima@ietf.org Subject: [EAI] Last Call: (IMAP Support for UTF-8) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:04:22 -0000 The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'IMAP Support for UTF-8' as Proposed Standard Please note: This document is one a set of four interdependent documents: draft-ietf-eai-5738bis draft-ietf-eai-popimap-downgrade draft-ietf-eai-rfc5721bis draft-ietf-eai-simpledowngrade These documents should be reviewed, evaluated, and understood together. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-09-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses and message headers. This specification replaces RFC 5738. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eai-5738bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eai-5738bis/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu Sep 6 08:05:27 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409BC21F86EC; Thu, 6 Sep 2012 08:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OXUUsmBa9cm; Thu, 6 Sep 2012 08:05:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB64121F86C3; Thu, 6 Sep 2012 08:05:26 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120906150526.5342.57611.idtracker@ietfa.amsl.com> Date: Thu, 06 Sep 2012 08:05:26 -0700 Cc: ima@ietf.org Subject: [EAI] Last Call: (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:05:27 -0000 The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'Post-delivery Message Downgrading for Internationalized Email Messages' as Proposed Standard Please note: This document is one a set of four interdependent documents: draft-ietf-eai-5738bis draft-ietf-eai-popimap-downgrade draft-ietf-eai-rfc5721bis draft-ietf-eai-simpledowngrade These documents should be reviewed, evaluated, and understood together. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-09-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Email Address Internationalization (SMTPUTF8) extension to SMTP allows UTF-8 characters in mail header fields. Upgraded POP and IMAP servers support internationalized Email messages. If a POP/IMAP client does not support Email Address Internationalization, POP/IMAP servers cannot deliver Internationalized Email Headers to the client and cannot remove the message. To avoid the situation, this document describes a conversion mechanism for internationalized Email messages to be in traditional message format. In the process, message elements requiring internationalized treatment are recoded or removed and receivers are able to know that they received messages containing such elements even if they cannot process the internationalized elements. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eai-popimap-downgrade/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eai-popimap-downgrade/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu Sep 6 08:08:21 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B451521F86FD; Thu, 6 Sep 2012 08:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqVBPD+pfp3b; Thu, 6 Sep 2012 08:08:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C6B21F8691; Thu, 6 Sep 2012 08:08:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120906150821.5344.68586.idtracker@ietfa.amsl.com> Date: Thu, 06 Sep 2012 08:08:21 -0700 Cc: ima@ietf.org Subject: [EAI] Last Call: (POP3 Support for UTF-8) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:08:21 -0000 The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'POP3 Support for UTF-8' as Proposed Standard Please note: This document is one a set of four interdependent documents: draft-ietf-eai-5738bis draft-ietf-eai-popimap-downgrade draft-ietf-eai-rfc5721bis draft-ietf-eai-simpledowngrade These documents should be reviewed, evaluated, and understood together. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-09-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification extends the Post Office Protocol version 3 (POP3) to support UTF-8 encoded international string in user names, passwords, mail addresses, message headers, and protocol-level textual strings. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5721bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5721bis/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu Sep 6 08:09:24 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A93C21F8726; Thu, 6 Sep 2012 08:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXjQY1bjIe9Z; Thu, 6 Sep 2012 08:09:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2803721F8711; Thu, 6 Sep 2012 08:09:24 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120906150924.25208.37737.idtracker@ietfa.amsl.com> Date: Thu, 06 Sep 2012 08:09:24 -0700 Cc: ima@ietf.org Subject: [EAI] Last Call: (Simplified POP/IMAP Downgrading for Internationalized Email) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:09:24 -0000 The IESG has received a request from the Email Address Internationalization WG (eai) to consider the following document: - 'Simplified POP/IMAP Downgrading for Internationalized Email' as Proposed Standard Please note: This document is one a set of four interdependent documents: draft-ietf-eai-5738bis draft-ietf-eai-popimap-downgrade draft-ietf-eai-rfc5721bis draft-ietf-eai-simpledowngrade These documents should be reviewed, evaluated, and understood together. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-09-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement and provides only rudimentary results. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-eai-simpledowngrade/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-eai-simpledowngrade/ballot/ No IPR declarations have been submitted directly on this I-D. From klensin@jck.com Thu Sep 6 08:32:10 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B73621F86DF for ; Thu, 6 Sep 2012 08:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HL8MKDT6SiJt for ; Thu, 6 Sep 2012 08:32:09 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 82F4921F84E1 for ; Thu, 6 Sep 2012 08:32:09 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T9e3t-000PWW-4T for ima@ietf.org; Thu, 06 Sep 2012 11:32:09 -0400 Date: Thu, 06 Sep 2012 11:32:04 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <0C9D73B1E75EE8EBA00A6306@JcK-HP8200.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 Subject: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:32:10 -0000 Hi. Just to be sure the WG is informed, the Last Calls have been issued on the four IMAP/POP documents. They contain the "should be reviewed, evaluated, and understood together" language that we requested. The Last Call expires two weeks from today. Statements of enthusiasm from WG participants would be welcome. I am assuming there will be no surprises from those who receive this list given the many, many, requests we've made for reviews and comments. The Last Call announcements themselves were copied to this list. john From barryleiba.mailing.lists@gmail.com Thu Sep 6 11:49:07 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3FE21F8766 for ; Thu, 6 Sep 2012 11:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.939 X-Spam-Level: X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaJajGGFRSYF for ; Thu, 6 Sep 2012 11:49:07 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C17C221F8763 for ; Thu, 6 Sep 2012 11:49:06 -0700 (PDT) Received: by lbky2 with SMTP id y2so1537206lbk.31 for ; Thu, 06 Sep 2012 11:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FQF7fIWCu1OBpam0v0Tba579b/y0kMx2gX/dTvFMrec=; b=BVrY0gdVLNk3FO9zuul7onQSrlg6+VKejf+Zw+/3bwndXXI1np2NgC4L8avch8n/hO M2DNh9hypk0wFQ3vBbsZoRfhQtkpAY5MEQ1hJuoNJE2PGWcUcQOX8+TDzZkZOEZoKSd9 BBXwKC3Jj+xpjytgtcwyogBnPrFeYyJII0Go95D1Jcg12wCcIkjKBAVG879wXzNRq9tp 8nq1nwk8Less0Ht037z5VKlR8WjRIVU6stBj6mc+p2iRaaA2e9jUWmywH3KRKTnp47iw 824nEJ+OHV/u5zbWgYiP02L3NIpK1v+6fGe5KqefRUIkq6iFzVtnKBA1O2D07RaTTlDk DqGQ== MIME-Version: 1.0 Received: by 10.152.110.46 with SMTP id hx14mr2872170lab.21.1346957345709; Thu, 06 Sep 2012 11:49:05 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Thu, 6 Sep 2012 11:49:05 -0700 (PDT) In-Reply-To: <0C9D73B1E75EE8EBA00A6306@JcK-HP8200.jck.com> References: <0C9D73B1E75EE8EBA00A6306@JcK-HP8200.jck.com> Date: Thu, 6 Sep 2012 14:49:05 -0400 X-Google-Sender-Auth: AdAlIUPDQOS4gmGiFAF6FrcN9o8 Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: ima@ietf.org Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 18:49:07 -0000 > The Last Call expires two weeks from today. > Statements of enthusiasm from WG participants would be welcome. > I am assuming there will be no surprises from those who receive > this list given the many, many, requests we've made for reviews > and comments. If, indeed, there are no surprises, I (as an IESG member, but not your responsible AD) see no particular value in statements of enthusiasm from WG participants. Those are of more value in WGLC, I think. The IESG is aware, from the shepherd writeup, of the consensus of the WG, and I think a quiet last call period will be just fine. Of course, if issues are raised during last call, WG participants are encouraged to speak up and set folks right. Barry, the other App AD From klensin@jck.com Thu Sep 6 13:05:08 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD6721F8745 for ; Thu, 6 Sep 2012 13:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2kqlG2SvVsf for ; Thu, 6 Sep 2012 13:05:08 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFCB21F8718 for ; Thu, 6 Sep 2012 13:05:08 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T9iK2-0000LD-8I; Thu, 06 Sep 2012 16:05:06 -0400 Date: Thu, 06 Sep 2012 16:05:01 -0400 From: John C Klensin To: Barry Leiba Message-ID: In-Reply-To: References: <0C9D73B1E75EE8EBA00A6306@JcK-HP8200.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 Cc: ima@ietf.org Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 20:05:08 -0000 Barry, That certainly works for me -- we have occasionally gotten signals to the contrary from some other ADs, but you and Pete have the lead on this. best, john --On Thursday, September 06, 2012 14:49 -0400 Barry Leiba wrote: >> The Last Call expires two weeks from today. >> Statements of enthusiasm from WG participants would be >> welcome. I am assuming there will be no surprises from those >> who receive this list given the many, many, requests we've >> made for reviews and comments. > > If, indeed, there are no surprises, I (as an IESG member, but > not your responsible AD) see no particular value in statements > of enthusiasm from WG participants. Those are of more value > in WGLC, I think. The IESG is aware, from the shepherd > writeup, of the consensus of the WG, and I think a quiet last > call period will be just fine. > > Of course, if issues are raised during last call, WG > participants are encouraged to speak up and set folks right. From barryleiba@gmail.com Thu Sep 6 14:15:55 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8809221F8764 for ; Thu, 6 Sep 2012 14:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.941 X-Spam-Level: X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mD-Fej7nOcjo for ; Thu, 6 Sep 2012 14:15:54 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86D0E21F8766 for ; Thu, 6 Sep 2012 14:15:54 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so3283983vcb.31 for ; Thu, 06 Sep 2012 14:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=juLD96sQAxw1N3PgHevd8P0zspTbVo5xxnrVmKUJz+k=; b=n4AyoYsF/TnMl5LUKLRq7jRfYBD+JSeaKoxJuOS/n3Qa8I6hhx1k1JXmM/f1sLHioc Ge8CF/opyI8MGqWwkQ8ckdGhosrYh8Si/DB2Yn9vD2XgmKqx0dnS+L+TJLusOjdKCTpF DD8Li/TIO5BuZhaPf4UY70e0l8uxVZs30OAnFAg9zWpMGQZT0ydPSzZZhGgJifKXv2at HahuykCCBQfQ2zQBwzy68yVry6FcFBZ3ZMZ8jzigJo8A+2VDB8nB5Tpjw2szeYiRRq8/ R5+z0bP5c49LpFOGJDw6R3vEs92IuRLg9LdFg1ZcQlHFzhivW5nHgrhGsyJob1PRak/s K5bw== MIME-Version: 1.0 Received: by 10.52.28.169 with SMTP id c9mr3526372vdh.3.1346966154023; Thu, 06 Sep 2012 14:15:54 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.58.41 with HTTP; Thu, 6 Sep 2012 14:15:53 -0700 (PDT) In-Reply-To: References: <0C9D73B1E75EE8EBA00A6306@JcK-HP8200.jck.com> Date: Thu, 6 Sep 2012 17:15:53 -0400 X-Google-Sender-Auth: xfnnyOM3ZtuyrxqSRVHNdO8bAI4 Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: ima@ietf.org Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 21:15:55 -0000 > That certainly works for me -- we have occasionally gotten > signals to the contrary from some other ADs, but you and Pete > have the lead on this. Understood, and Pete can say otherwise: he's the responsible AD. I think expressions of "I read it, and it's ready" from WG participants during WGLC are valuable, to assure us that there was sufficient review. But during IETF last call, unless there are issues the WG has to respond to, I think the WG record can stand on its own. b From klensin@jck.com Thu Sep 6 14:34:05 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6F221F8716 for ; Thu, 6 Sep 2012 14:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkHDxDm7S33h for ; Thu, 6 Sep 2012 14:34:04 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8791821F8711 for ; Thu, 6 Sep 2012 14:34:04 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T9ji7-0000be-01; Thu, 06 Sep 2012 17:34:03 -0400 Date: Thu, 06 Sep 2012 17:33:57 -0400 From: John C Klensin To: Barry Leiba Message-ID: In-Reply-To: References: <0C9D73B1E75EE8EBA00A6306@JcK-HP8200.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 Cc: ima@ietf.org Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 21:34:06 -0000 --On Thursday, September 06, 2012 17:15 -0400 Barry Leiba wrote: >> That certainly works for me -- we have occasionally gotten >> signals to the contrary from some other ADs, but you and Pete >> have the lead on this. > > Understood, and Pete can say otherwise: he's the responsible > AD. I think expressions of "I read it, and it's ready" from > WG participants during WGLC are valuable, to assure us that > there was sufficient review. But during IETF last call, > unless there are issues the WG has to respond to, I think the > WG record can stand on its own. Certainly that is consistent with my personal view. Unless the IETF Last Call turns up controversies, a conclusion that is carefully checked within the WG should basically stand on its own, without adding to the noise on the IETF list. john From prvs=589ac42cd=fmartin@linkedin.com Thu Sep 6 15:36:47 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA8721F8568 for ; Thu, 6 Sep 2012 15:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bITHOMvTwVR4 for ; Thu, 6 Sep 2012 15:36:47 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 77FA221F8566 for ; Thu, 6 Sep 2012 15:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1346971006; x=1378507006; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=DnZcVhqSoj86xpCYZ1pR2eJbnjtVmmHbFOFWK0cxQIo=; b=dcJMl3blY6nJ1NDHAw0tGV0iPjOMoixyozBkC164/Ule85+zW542GcFW Z2WY59G/Y8U5Lw9Bwxtl4oLpFUY0XRqsh7HXyMByBFja19v0PMJj0/P9e txoOPLHgBN6Brvj76eWuiwoODI2r8PdAdBqXsIivDnW1rtm3UDdCT9Rxo 8=; X-IronPort-AV: E=Sophos;i="4.80,381,1344236400"; d="scan'208";a="24867134" Received: from ESV4-HT01.linkedin.biz (172.18.46.235) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 6 Sep 2012 15:36:06 -0700 Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.01.0218.012; Thu, 6 Sep 2012 15:36:06 -0700 From: Franck Martin To: "ima@ietf.org" Thread-Topic: [EAI] Last Calls issued Thread-Index: AQHNjETJ2J9GX953VEex5ZXaw4cUiJd+fmSA Date: Thu, 6 Sep 2012 22:36:06 +0000 Message-ID: In-Reply-To: <0C9D73B1E75EE8EBA00A6306@JcK-HP8200.jck.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="Windows-1252" Content-ID: <22A14EB6B018264EAA16F737A0395E5A@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 22:36:47 -0000 Hi all, I'm joining late, but I have a concern, and because I see now a deadline, I'm going to short cut heavily. I'm sorry in advance, but I just learn of the workgroup about a week ago and I have been busy on other things, I could not get up to speed correctly. Here in short my concern, and I just need to be pointed to some prior discussion so I can form an opinion. My personal concern, in the documents of the workgroup, is the specification change of the From header from mailbox-list to address-list, I think these concerns are partly articulated in the security section of: http://tools.ietf.org/html/draft-leiba-5322upd-from-group-03 Some protocols attempt to validate that originator address by matching the "From" address to a particular verified domain (see Author Domain Signing Practices (ADSP) [RFC5617 ] for one such protocol). Such protocols will not be applicable to messages that lack an actual email address (whether real or fake) in the "From" field, and local policy will determine how such messages are handled. Senders, therefore, need to be aware that using group syntax in the "From" might adversely affect deliverability of the message. As you may know, there is a new specification being developed, DMARC, where the goal will be to hand it over to the IETF. While ADSP has not seen much traction, DMARC while still a young specification has seen some traction with today a seriously large amount of mailboxes protected by DMARC. Like ADSP, the articulation of DMARC is based on the domain name(s) present in the From: header, because these are labels visible to the end user at the MUA level. Removing such labels from the From: headers, may render the situation more difficult, therefore lowering the authentication advantage of DMARC. I'm for increased authentication capabilities (security) not less. I can see, this notation is used in this set of documents applying to all headers and in particular the From: header which is somehow rendered to the end user via the MUA. We are going to move into an IPv6 world, where there is a non-null possibility that reputation will be organized around other labels than the IP address. In short, I don't understand why in the case of a downgrade, the email is not represented with the domain part in punnycode, while the local part could be left blank, or could be a special label like x-utf8local To be noted, this is my own writing, this is not the view of the DMARC group, nor the view of my employer, etc=8A But I felt I needed to say something before the door close. So I just need a bootstrap to the relevant archives and discussions. Thanks. On 9/6/12 5:32 PM, "John C Klensin" wrote: >Hi. > >Just to be sure the WG is informed, the Last Calls have been >issued on the four IMAP/POP documents. They contain the "should >be reviewed, evaluated, and understood together" language that >we requested. The Last Call expires two weeks from today. >Statements of enthusiasm from WG participants would be welcome. >I am assuming there will be no surprises from those who receive >this list given the many, many, requests we've made for reviews >and comments. > >The Last Call announcements themselves were copied to this list. > > john From klensin@jck.com Thu Sep 6 16:49:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85E521F86BE for ; Thu, 6 Sep 2012 16:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MkQsZ0VPg3A for ; Thu, 6 Sep 2012 16:49:54 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id E111A21F8683 for ; Thu, 6 Sep 2012 16:49:53 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T9lpZ-0000u5-0u; Thu, 06 Sep 2012 19:49:53 -0400 Date: Thu, 06 Sep 2012 19:49:47 -0400 From: John C Klensin To: Franck Martin , ima@ietf.org Message-ID: <804393AA3344363B5D2DE123@JcK-HP8200.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 Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 23:49:55 -0000 Franck, Three very general comments may help here. They may not make you happy, but should at least clarify things a bit. (1) Anything that tries to make careful tests on headers is going to need rethinking for the EAI/ SMTPUTF8 extensions. The particular issue with group "From:" headers is just the tip of a rather large iceberg that has, e.g., a much larger effect on canonicalization and comparisons for DKIM. That set of issues are discussed to some extent in RFC 6530. (2) The only place where EAI-related specs specifically call for the use of that empty group syntax on "From:" is in the interface between an SMTPUTF8-compliant IMAP or POP server and a legacy client. For most purposes, if you are doing anti-spam filtering, it would be before the message enters the mail store and so would be unaffected by this change. There is no assumption that message originators will ever use group syntax in "From:" (and I note that there is no equivalent in the SMTP envelope FROM command unless you count "<>" (which has other implications, of course). Passing messages with empty group syntax in the "From:" field to a POP or IMAP client just about guarantees that the message will not be reply-able by ordinary means, but that would be true of anything else that could be transmitted to such a client. (3) We could, as you suggest, have preserved the domain name in that particular downgrading model. But doing so would have required some very peculiar syntax that would be almost certain to break existing (legacy) implementations. Consider, as just one example, what=20 From: Encoded-Name: @domain; (with no local-part) might do to a header parser. Even then, it would apply only to that one, optional, downgrade case. It wouldn't help on the SMTP wire and it wouldn't help with any other downgrading strategy. If, on the other hand, you are suggesting rendering the local-part into some encoding like Punycode, the WG has been over variations on that option more times than I can count. The short summary is that it just isn't feasible, especially if one expects to preserve the 5321 principle that no system prior to the delivery server is permitted to interpret (or transform) the local part of an email address.=20 Independent of where the problem manifests itself, message originators will need to be aware that use of addresses or other features that require SMTPUTF8 risks deliverability problems. Of course, if a user provides only a non-ASCII address, failure to use SMTPUTF8 facilities _guarantees_ non-deliverability. If you think some additional warnings about the possible implications of actually using group syntax in "From:" are needed, I suggest that the place to argue for putting them is in draft-leiba-5322upd-from-group. best, john p.s. The work that led to this WG started in roughly 2003. The WG was chartered in 2005 and the work has been widely discussed in a number of forums in the subsequent eight or nine years. If there is more that we should have done to be sure you and others became aware of it before last week, I'd like to know for future such efforts. --On Thursday, September 06, 2012 22:36 +0000 Franck Martin wrote: > Hi all, >=20 > I'm joining late, but I have a concern, and because I see now > a deadline, I'm going to short cut heavily. I'm sorry in > advance, but I just learn of the workgroup about a week ago > and I have been busy on other things, I could not get up to > speed correctly. >=20 > Here in short my concern, and I just need to be pointed to > some prior discussion so I can form an opinion. >=20 > My personal concern, in the documents of the workgroup, is the > specification change of the From header from mailbox-list to > address-list, I think these concerns are partly articulated in > the security section of: > http://tools.ietf.org/html/draft-leiba-5322upd-from-group-03 >=20 > Some protocols attempt to validate that originator address by > matching the "From" address to a particular verified domain > (see Author Domain Signing Practices (ADSP) [RFC5617 > ] for one such > protocol). Such protocols will not be applicable to > messages that lack an actual email address (whether real or > fake) in the "From" field, and local policy will determine > how such messages are handled. Senders, therefore, need to > be aware that using group syntax in the "From" might > adversely affect deliverability of the message. >=20 >=20 > As you may know, there is a new specification being developed, > DMARC, where the goal will be to hand it over to the IETF. > While ADSP has not seen much traction, DMARC while still a > young specification has seen some traction with today a > seriously large amount of mailboxes protected by DMARC. >=20 > Like ADSP, the articulation of DMARC is based on the domain > name(s) present in the From: header, because these are labels > visible to the end user at the MUA level. Removing such labels > from the From: headers, may render the situation more > difficult, therefore lowering the authentication advantage of > DMARC. I'm for increased authentication capabilities > (security) not less. >=20 > I can see, this notation is used in this set of documents > applying to all headers and in particular the From: header > which is somehow rendered to the end user via the MUA. >=20 >=20 > We are going to move into an IPv6 world, where there is a > non-null possibility that reputation will be organized around > other labels than the IP address. >=20 > In short, I don't understand why in the case of a downgrade, > the email is not represented with the domain part in > punnycode, while the local part could be left blank, or could > be a special label like x-utf8local >=20 > To be noted, this is my own writing, this is not the view of > the DMARC group, nor the view of my employer, etc=C5=A0 But I = felt > I needed to say something before the door close. >=20 > So I just need a bootstrap to the relevant archives and > discussions. >=20 > Thanks. >=20 >=20 > On 9/6/12 5:32 PM, "John C Klensin" wrote: >=20 >> Hi. >>=20 >> Just to be sure the WG is informed, the Last Calls have been >> issued on the four IMAP/POP documents. They contain the >> "should be reviewed, evaluated, and understood together" >> language that we requested. The Last Call expires two weeks >> from today. Statements of enthusiasm from WG participants >> would be welcome. I am assuming there will be no surprises >> from those who receive this list given the many, many, >> requests we've made for reviews and comments. >>=20 >> The Last Call announcements themselves were copied to this >> list. >>=20 >> john >=20 > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From prvs=590c51800=fmartin@linkedin.com Thu Sep 6 17:26:16 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAEC21F8678 for ; Thu, 6 Sep 2012 17:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lwmL3l84B+x for ; Thu, 6 Sep 2012 17:26:15 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id E9BAD21F85B1 for ; Thu, 6 Sep 2012 17:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1346977574; x=1378513574; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=K1xwg5r3R27EkZJeeTUhRwksWSke0Oj5JLOE1OHP0nY=; b=VHn1pA31A6TsVCn1LEcaAVvauUsGaEprpJ+uMRO94RT7aFltsJjWDO+7 kQj0hRVoNELmLJTq+4tZLHj+cmQS5HxSL7CrxxUT5VBO6yGjknLx0zvLr 8ljf4q45kp42c7oOZQkrhvtJDTHBxeWBwxQkVP2/wGOJfLWfaqu/ewnlh Y=; X-IronPort-AV: E=Sophos;i="4.80,382,1344236400"; d="scan'208";a="24874474" Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.01.0355.002; Thu, 6 Sep 2012 17:25:47 -0700 From: Franck Martin To: John C Klensin , "ima@ietf.org" Thread-Topic: [EAI] Last Calls issued Thread-Index: AQHNjETJ2J9GX953VEex5ZXaw4cUiJd+fmSA///zAoCAACutAA== Date: Fri, 7 Sep 2012 00:25:45 +0000 Message-ID: In-Reply-To: <804393AA3344363B5D2DE123@JcK-HP8200.jck.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 00:26:16 -0000 John, Thanks for the quick comments/info. 1) will read RFC 6530 then 2) the issue is that the MUA is not passed the domain to render it to the user. While I understand the goals of MUA UI developers are sometimes at the antipodes of the security people. I still think it is important to pass this label to the MUA. If the MTA and MUA are all UTF8 compatible, then there is no issue, but not sure how fast the transition will be. This is why I raise this point here and not in draft-leiba-5322upd-from-group only. 3) I understand the local part cannot be punycoded. So what I was suggesting is a constant string for the local part that means, could not convert, but the domain part would be puny code Something like From: "John Doe" Or From: "John Doe" The noreply string tends to be interpreted by various automatic software(email list management) correctly. Finally, netease (chinese biggest ISP) is doing DMARC filtering, I'm worried they will be an early adopter of this spec and will quickly get conflicted with DMARC, and I'm not sure DMARC will win over the users requesting readable UTF8 email addresses. I'm not sure about the warning, this could indeed help to get people to be careful, I'm worried that if we put in DMARC to reject such emails, as draft-leiba-5322upd-from-group security note says, then getting DMARC though IETF will hit a conflict with a prior RFC and therefore rewritten in a way that minimizes DMARC effectiveness. May be the security consideration in draft-leiba-5322upd-from-group just need to be copied and pasted in all these RFCs? PS to the PS: shit happens. The DMARC spec is public since end of January but similar mechanisms have been tested well before. We tried to reach wide, but you can't keep an eye on everything and no one raised this issue early to the DMARC group AFAIK. I guess, this WG has already considered ADSP, and reached a conclusion. I just need to get the executive summary ;). On 9/7/12 1:49 AM, "John C Klensin" wrote: >Franck, > >Three very general comments may help here. They may not make >you happy, but should at least clarify things a bit. > >(1) Anything that tries to make careful tests on headers is >going to need rethinking for the EAI/ SMTPUTF8 extensions. The >particular issue with group "From:" headers is just the tip of a >rather large iceberg that has, e.g., a much larger effect on >canonicalization and comparisons for DKIM. That set of issues >are discussed to some extent in RFC 6530. > >(2) The only place where EAI-related specs specifically call for >the use of that empty group syntax on "From:" is in the >interface between an SMTPUTF8-compliant IMAP or POP server and a >legacy client. For most purposes, if you are doing anti-spam >filtering, it would be before the message enters the mail store >and so would be unaffected by this change. There is no >assumption that message originators will ever use group syntax >in "From:" (and I note that there is no equivalent in the SMTP >envelope FROM command unless you count "<>" (which has other >implications, of course). Passing messages with empty group >syntax in the "From:" field to a POP or IMAP client just about >guarantees that the message will not be reply-able by ordinary >means, but that would be true of anything else that could be >transmitted to such a client. > >(3) We could, as you suggest, have preserved the domain name in >that particular downgrading model. But doing so would have >required some very peculiar syntax that would be almost certain >to break existing (legacy) implementations. Consider, as just >one example, what=20 > From: Encoded-Name: @domain; >(with no local-part) might do to a header parser. Even then, it >would apply only to that one, optional, downgrade case. It >wouldn't help on the SMTP wire and it wouldn't help with any >other downgrading strategy. If, on the other hand, you are >suggesting rendering the local-part into some encoding like >Punycode, the WG has been over variations on that option more >times than I can count. The short summary is that it just isn't >feasible, especially if one expects to preserve the 5321 >principle that no system prior to the delivery server is >permitted to interpret (or transform) the local part of an email >address.=20 > >Independent of where the problem manifests itself, message >originators will need to be aware that use of addresses or other >features that require SMTPUTF8 risks deliverability problems. >Of course, if a user provides only a non-ASCII address, failure >to use SMTPUTF8 facilities _guarantees_ non-deliverability. > >If you think some additional warnings about the possible >implications of actually using group syntax in "From:" are >needed, I suggest that the place to argue for putting them is in >draft-leiba-5322upd-from-group. > >best, > john > >p.s. The work that led to this WG started in roughly 2003. The >WG was chartered in 2005 and the work has been widely discussed >in a number of forums in the subsequent eight or nine years. If >there is more that we should have done to be sure you and others >became aware of it before last week, I'd like to know for future >such efforts. > > > > >--On Thursday, September 06, 2012 22:36 +0000 Franck Martin > wrote: > >> Hi all, >>=20 >> I'm joining late, but I have a concern, and because I see now >> a deadline, I'm going to short cut heavily. I'm sorry in >> advance, but I just learn of the workgroup about a week ago >> and I have been busy on other things, I could not get up to >> speed correctly. >>=20 >> Here in short my concern, and I just need to be pointed to >> some prior discussion so I can form an opinion. >>=20 >> My personal concern, in the documents of the workgroup, is the >> specification change of the From header from mailbox-list to >> address-list, I think these concerns are partly articulated in >> the security section of: >> http://tools.ietf.org/html/draft-leiba-5322upd-from-group-03 >>=20 >> Some protocols attempt to validate that originator address by >> matching the "From" address to a particular verified domain >> (see Author Domain Signing Practices (ADSP) [RFC5617 >> ] for one such >> protocol). Such protocols will not be applicable to >> messages that lack an actual email address (whether real or >> fake) in the "From" field, and local policy will determine >> how such messages are handled. Senders, therefore, need to >> be aware that using group syntax in the "From" might >> adversely affect deliverability of the message. >>=20 >>=20 >> As you may know, there is a new specification being developed, >> DMARC, where the goal will be to hand it over to the IETF. >> While ADSP has not seen much traction, DMARC while still a >> young specification has seen some traction with today a >> seriously large amount of mailboxes protected by DMARC. >>=20 >> Like ADSP, the articulation of DMARC is based on the domain >> name(s) present in the From: header, because these are labels >> visible to the end user at the MUA level. Removing such labels >> from the From: headers, may render the situation more >> difficult, therefore lowering the authentication advantage of >> DMARC. I'm for increased authentication capabilities >> (security) not less. >>=20 >> I can see, this notation is used in this set of documents >> applying to all headers and in particular the From: header >> which is somehow rendered to the end user via the MUA. >>=20 >>=20 >> We are going to move into an IPv6 world, where there is a >> non-null possibility that reputation will be organized around >> other labels than the IP address. >>=20 >> In short, I don't understand why in the case of a downgrade, >> the email is not represented with the domain part in >> punnycode, while the local part could be left blank, or could >> be a special label like x-utf8local >>=20 >> To be noted, this is my own writing, this is not the view of >> the DMARC group, nor the view of my employer, etc=A9 But I felt >> I needed to say something before the door close. >>=20 >> So I just need a bootstrap to the relevant archives and >> discussions. >>=20 >> Thanks. >>=20 >>=20 >> On 9/6/12 5:32 PM, "John C Klensin" wrote: >>=20 >>> Hi. >>>=20 >>> Just to be sure the WG is informed, the Last Calls have been >>> issued on the four IMAP/POP documents. They contain the >>> "should be reviewed, evaluated, and understood together" >>> language that we requested. The Last Call expires two weeks >>> from today. Statements of enthusiasm from WG participants >>> would be welcome. I am assuming there will be no surprises >>> from those who receive this list given the many, many, >>> requests we've made for reviews and comments. >>>=20 >>> The Last Call announcements themselves were copied to this >>> list. >>>=20 >>> john >>=20 >> _______________________________________________ >> IMA mailing list >> IMA@ietf.org >> https://www.ietf.org/mailman/listinfo/ima > > > > From klensin@jck.com Thu Sep 6 19:20:14 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8EA21F844E for ; Thu, 6 Sep 2012 19:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dSUvVpTysKd for ; Thu, 6 Sep 2012 19:20:14 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id BE7B721F844D for ; Thu, 6 Sep 2012 19:20:13 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T9oAz-0001Bz-Jk; Thu, 06 Sep 2012 22:20:09 -0400 Date: Thu, 06 Sep 2012 22:20:04 -0400 From: John C Klensin To: Franck Martin , ima@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 02:20:14 -0000 --On Friday, September 07, 2012 00:25 +0000 Franck Martin wrote: > John, > > Thanks for the quick comments/info. > > 1) will read RFC 6530 then > > 2) the issue is that the MUA is not passed the domain to > render it to the user. While I understand the goals of MUA UI > developers are sometimes at the antipodes of the security > people. I still think it is important to pass this label to > the MUA. If the MTA and MUA are all UTF8 compatible, then > there is no issue, but not sure how fast the transition will > be. This is why I raise this point here and not in > draft-leiba-5322upd-from-group only. The WG has been over this territory several times, although in slightly different form. Consider that, if the delivery MTA cannot accept SMTPUTF8 messages, we have a non-issue: such a message will never reach the mail store, much less the POP or IMAP client. It is only when all of the following conditions are met that the situation you are concerned about would arise: * The delivery MTA is SMTPUTF8-capable * The mailstore has been upgraded to match * The POP and/or IMAP servers have also been upgraded. * The POP or IMAP client are ASCII-only as far as headers are concerned. Now POP, IMAP, and 5322 (and 5321, but it is not particularly relevant to POP and IMAP clients) all require that address fields, with the exception of the group syntax (where it is allowed) consist of a local-part and a domain, separated by "@". If a non-ASCII address arrives at the POP/IMAP server-client boundary, it cannot be transmitted to the client without doing something that, as far as the existing/legacy specs are concerned, is screwy. The WG concluded that, of many options that it considered, the use of Group syntax, even in the backward-pointing fields, was least likely to cause harm. But suppose some other conclusion had been reached and the plan was to change the "From:" syntax to permit "<@domain>" without a local part, or perhaps <[]@domain>, or perhaps a new header field, say From-Domain: Domain-using-A-labels In each of those cases, the odds are extremely high that a legacy client would either reject the construction as a syntax error or get terribly confused. None of those options would help you. So what you now need is a client that is upgraded to handle the new form of the information. The WG's conclusion was that it made no sense to encourage such "halfway" client upgrades because the work needed to implement and deploy them wasn't likely to be that much different from the work to implement and deploy fully upgraded, SMTPUTF8-capable, clients. And they don't have the problem. So I think the advice we would give you is that, if you need the MUA to receive domain information contained in non-ASCII "From:" addresses, you recommend either fully upgraded MUAs or that the delivery MTA be configured to not accept SMTPUTF8 mail at all. Nasty tradeoff, but you are going to find everything else more than a little fragile. > 3) I understand the local part cannot be punycoded. So what I > was suggesting is a constant string for the local part that > means, could not convert, but the domain part would be puny > code Again, considered by the WG as an alternative and rejected. Part of the reason is that while there are a bunch of conventions floating around, the community has been been very reluctant to reserve local-part strings in the protocol: "postmaster" is the only exception, and it goes back to almost the beginning. > Something like > > From: "John Doe" > Or > From: "John Doe" > > The noreply string tends to be interpreted by various automatic > software(email list management) correctly. And to be interpreted as a normal address by other things. > Finally, netease (chinese biggest ISP) is doing DMARC > filtering, I'm worried they will be an early adopter of this > spec and will quickly get conflicted with DMARC, and I'm not > sure DMARC will win over the users requesting readable UTF8 > email addresses. I'll let the readers of this list who are more familiar with the situation in China respond if they think it appropriate but, again, the only good solution is to be sure users have fully-upgraded clients. > I'm not sure about the warning, this could indeed help to get > people to be careful, I'm worried that if we put in DMARC to > reject such emails, as draft-leiba-5322upd-from-group security > note says, then getting DMARC though IETF will hit a conflict > with a prior RFC and therefore rewritten in a way that > minimizes DMARC effectiveness. May be the security > consideration in draft-leiba-5322upd-from-group just need to > be copied and pasted in all these RFCs? Again, I think the actual situation here will be much more constrained in practice than you are assuming. And, again, there is no satisfactory solution other than upgrading. A strong warning to not use empty group syntax in a remapped "From:" field is essentially a request to refuse to deliver mail content with internationalized headers to a legacy client. That causes a lot of messages to fail too. > PS to the PS: shit happens. The DMARC spec is public since end > of January but similar mechanisms have been tested well > before. We tried to reach wide, but you can't keep an eye on > everything and no one raised this issue early to the DMARC > group AFAIK. I guess, this WG has already considered ADSP, and > reached a conclusion. I just need to get the executive summary > ;). Ack. best, john From arnt@gulbrandsen.priv.no Thu Sep 6 23:31:27 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5100E11E808E for ; Thu, 6 Sep 2012 23:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mp6J-m2euq-t for ; Thu, 6 Sep 2012 23:31:27 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5ABE11E808A for ; Thu, 6 Sep 2012 23:31:26 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3F453F94E0C; Fri, 7 Sep 2012 06:31:25 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1346999484-9641-9640/10/1; Fri, 7 Sep 2012 06:31:24 +0000 Message-Id: <504994F5.9080805@gulbrandsen.priv.no> Date: Fri, 7 Sep 2012 08:32:21 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: ima@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 06:31:27 -0000 John Klensin answers Franck Martin: > So I think the advice we would give you is that, if you need the > MUA to receive domain information contained in non-ASCII "From:" > addresses, you recommend either fully upgraded MUAs or that the > delivery MTA be configured to not accept SMTPUTF8 mail at all. Keep in mind that upgrading MUAs to accept internationalized mail is extremely easy. Arnt From yaojk@cnnic.cn Fri Sep 7 00:08:49 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4113E21E808A for ; Fri, 7 Sep 2012 00:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.357 X-Spam-Level: X-Spam-Status: No, score=-99.357 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+qqVpDTxu5w for ; Fri, 7 Sep 2012 00:08:47 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 019CF21E8037 for ; Fri, 7 Sep 2012 00:08:46 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 07 Sep 2012 15:08:30 +0800 Message-ID: From: "Jiankang YAO" To: "Arnt Gulbrandsen" , References: <504994F5.9080805@gulbrandsen.priv.no> Date: Fri, 7 Sep 2012 15:08:55 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 07:08:49 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFybnQgR3VsYnJhbmRzZW4i IDxhcm50QGd1bGJyYW5kc2VuLnByaXYubm8+DQpUbzogPGltYUBpZXRmLm9yZz4NClNlbnQ6IEZy aWRheSwgU2VwdGVtYmVyIDA3LCAyMDEyIDI6MzIgUE0NClN1YmplY3Q6IFJlOiBbRUFJXSBMYXN0 IENhbGxzIGlzc3VlZA0KDQoNCj4gSm9obiBLbGVuc2luIGFuc3dlcnMgRnJhbmNrIE1hcnRpbjoN Cj4+IFNvIEkgdGhpbmsgdGhlIGFkdmljZSB3ZSB3b3VsZCBnaXZlIHlvdSBpcyB0aGF0LCBpZiB5 b3UgbmVlZCB0aGUNCj4+IE1VQSB0byByZWNlaXZlIGRvbWFpbiBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gbm9uLUFTQ0lJICJGcm9tOiINCj4+IGFkZHJlc3NlcywgeW91IHJlY29tbWVuZCBlaXRo ZXIgZnVsbHkgdXBncmFkZWQgTVVBcyBvciB0aGF0IHRoZQ0KPj4gZGVsaXZlcnkgTVRBIGJlIGNv bmZpZ3VyZWQgdG8gbm90IGFjY2VwdCBTTVRQVVRGOCBtYWlsIGF0IGFsbC4NCj4gDQo+IEtlZXAg aW4gbWluZCB0aGF0IHVwZ3JhZGluZyBNVUFzIHRvIGFjY2VwdCBpbnRlcm5hdGlvbmFsaXplZCBt YWlsIGlzIA0KPiBleHRyZW1lbHkgZWFzeS4NCj4NCg0KU29tZSAgZW1haWwgc2VydmVyIGNvbXBh bmllcyBpbiBDaGluYSB3aWxsIHJlbGVhc2UgRUFJIFNNVFAgc2VydmVyIHByb2R1Y3RzICBzdXBw b3J0aW5nIHJmYzY1MzEgYW5kIFJGQzY1MzIgaW4gdGhlIGVuZCBvZiB0aGlzIHllYXIuDQpIb3Bl IHRvIHNlZSBhdmFpbGFibGUgRUFJIE1VQSBzb29uLiANCg0KSmlhbmthbmcgWWFvDQoNCj4NCj4g QXJudA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBJTUEgbWFpbGluZyBsaXN0DQo+IElNQUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ltYQ== From internet-drafts@ietf.org Fri Sep 7 03:58:52 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CC421F8767; Fri, 7 Sep 2012 03:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.416 X-Spam-Level: X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OdfMYE0rQvD; Fri, 7 Sep 2012 03:58:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0B821F86BE; Fri, 7 Sep 2012 03:58:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120907105852.31748.23082.idtracker@ietfa.amsl.com> Date: Fri, 07 Sep 2012 03:58:52 -0700 Cc: ima@ietf.org Subject: [EAI] I-D Action: draft-ietf-eai-email-clients-01.txt X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:58:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Email Address Internationalization Workin= g Group of the IETF. Title : Guidelines for Internationalized Email Clients Author(s) : Ernie Dainow Kazunori Fujiwara Filename : draft-ietf-eai-email-clients-01.txt Pages : 16 Date : 2012-09-07 Abstract: This document provides some guidelines for email clients that support Email Address Internationalization (EAI) as outlined in [RFC6530]. A number of interoperability cases between different versions of email components are reviewed. Recommendations are made to improve interoperability and usability and to minimize discrepancies between the display of composed and received email in different language environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eai-email-clients There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eai-email-clients-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eai-email-clients-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=590c51800=fmartin@linkedin.com Fri Sep 7 05:18:31 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447D921F87FC for ; Fri, 7 Sep 2012 05:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0u2RUJ98W8jR for ; Fri, 7 Sep 2012 05:18:30 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id B0FFA21F87FB for ; Fri, 7 Sep 2012 05:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1347020310; x=1378556310; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=yIN5ww5SmS/lR02s+4uDK440x8TtJq/SewJ68zK1EYc=; b=XjpKa1pjawHhUkj3u72ki4nvzd7aePai8wucKt6Q1uLdgMgUPWtVuh3R 9azgcfmDv2/myP7KulHNfW1Y+FFnmlWuOO5MGF0IKiG7j7ul0LV/pHcIu UssX0Mx+nAiCYRh8gpB6uWZoKl+1QjOl4AFMYJcW/8avaFjxk5707hdd8 g=; X-IronPort-AV: E=Sophos;i="4.80,385,1344236400"; d="scan'208";a="23632441" Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.01.0355.002; Fri, 7 Sep 2012 05:18:04 -0700 From: Franck Martin To: Arnt Gulbrandsen , "ima@ietf.org" Thread-Topic: [EAI] Last Calls issued Thread-Index: AQHNjETJ2J9GX953VEex5ZXaw4cUiJd+fmSA///zAoCAACutAP///lEAgABGfICAAIIyAA== Date: Fri, 7 Sep 2012 12:18:03 +0000 Message-ID: In-Reply-To: <504994F5.9080805@gulbrandsen.priv.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="us-ascii" Content-ID: <354D0B159CA94549960EF4D21BA5CE8D@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:18:31 -0000 On 9/7/12 8:32 AM, "Arnt Gulbrandsen" wrote: >John Klensin answers Franck Martin: >> So I think the advice we would give you is that, if you need the >> MUA to receive domain information contained in non-ASCII "From:" >> addresses, you recommend either fully upgraded MUAs or that the >> delivery MTA be configured to not accept SMTPUTF8 mail at all. > >Keep in mind that upgrading MUAs to accept internationalized mail is >extremely easy. Like it is easy to upgrade away from IE6? Still 0.6% of users are using it, and it was still at 2% a year ago. Upgrades are slow, and 2% is still a number that scares marketers when you tell them you won't be supporting that many... From klensin@jck.com Fri Sep 7 05:47:00 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEB421F8776 for ; Fri, 7 Sep 2012 05:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntKcfxM+jsVO for ; Fri, 7 Sep 2012 05:46:59 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEF921F877A for ; Fri, 7 Sep 2012 05:46:57 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1T9xxP-000306-Nz; Fri, 07 Sep 2012 08:46:47 -0400 Date: Fri, 07 Sep 2012 08:46:42 -0400 From: John C Klensin To: Franck Martin , Arnt Gulbrandsen , ima@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:47:00 -0000 --On Friday, September 07, 2012 12:18 +0000 Franck Martin wrote: > > > On 9/7/12 8:32 AM, "Arnt Gulbrandsen" > wrote: > >> John Klensin answers Franck Martin: >>> So I think the advice we would give you is that, if you need >>> the MUA to receive domain information contained in non-ASCII >>> "From:" addresses, you recommend either fully upgraded MUAs >>> or that the delivery MTA be configured to not accept >>> SMTPUTF8 mail at all. >> >> Keep in mind that upgrading MUAs to accept internationalized >> mail is extremely easy. > > Like it is easy to upgrade away from IE6? Still 0.6% of users > are using it, and it was still at 2% a year ago. > > Upgrades are slow, and 2% is still a number that scares > marketers when you tell them you won't be supporting that > many... But, Franck, that is exactly where Arnt's comments and mine come together. There are only three choices for getting the information you want to a client: (i) Upgrade the client to accept internationalized mail. (ii) Upgrade the client to accept and process some new and funky syntax (or specialized new header fields) to as to preserve some of the information in internationalized mail but not to actually accept internationalized mail. (iii) Decide that internationalized mail won't get to the client, whether it is rejected by the delivery MTA or just not delivered in some other way. The POP-IMAP "downgrade" mechanisms are really members of the family of (iii) -- they don't deliver the message, they deliver a surrogate that helps the user understand that some things are inaccessible until the client is downgraded (or they access the message through some other client, etc.). If one concludes those surrogate messages are a bad idea, then one works out non-delivery in some other way, such as by hiding the fully internationalized messages from the user entirely. Reasons why one might conclude "bad idea" include not being able to reply to the message (from one perspective, not because information is lost but because one did not receive the message), because key information is lost in the surrogate-creation process (your situation with domain names is just one example -- message signatures will probably be high on the list for others), as well as "just too much trouble". The WG concluded that, of those three choices, the second one makes no sense. It is substantially as hard to implement as the first. It involves the same statistics, the same deployment problems, and the same likely resistance from marketers. Wrt IE and other examples, the problem is, in part, the need to install something new, learn something new, etc., without an expectation of improvements that is compelling to users. Here, that message is very simple: "you want to be able to send messages to or receive mail from users with internationalized addresses or setups, you are going to upgrade". In terms of speed of penetration of the upgrades, I'd actually worry a lot more about users of European, Latin-script, languages than about China. For the former, ASCII may be "good enough". For the latter, a fairly strong case has been made that it is not. That is precisely why Jiankang's data show implementation commitments that are well ahead of any implementation commitments we've seen from Europe or North America. How the transition will play out in the latter in terms of what delivery servers will accept (and what addresses will be permitted) relative to development and deployment of POP and IMAP clients and servers is, at this point, anyone's guess. For China, it will deploy because people are convinced that they need it and because, from a marketing standpoint, critical mass will probably be reached quickly and _not_ having upgraded software will become intolerable. At least that is the general best guess. john From prvs=590c51800=fmartin@linkedin.com Fri Sep 7 05:51:52 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9323A21F87A9 for ; Fri, 7 Sep 2012 05:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uwt+AAoPxdfx for ; Fri, 7 Sep 2012 05:51:51 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 85D8421F8790 for ; Fri, 7 Sep 2012 05:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1347022311; x=1378558311; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=ZpHnNRn1L8TolhapVUJ4OKzi5sjaDO5HszjskmQi+Ng=; b=AOUPQ0zJMdw10B7x7yKjqax/1HmyFAakLx/JVZYxWr4UUZYgQD3KsXFn 794KsARNzLfRbRCdjxGMrblnZSd686cZ33tADZO1WBIKW1rbfc0yb4L1J 0OQabECh9hwCk4cmQoW5rfvPIPGv+erD0CE3Y6ZS5fNKVUclPSK+EqPh+ 0=; X-IronPort-AV: E=Sophos;i="4.80,385,1344236400"; d="scan'208";a="23634450" Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.01.0355.002; Fri, 7 Sep 2012 05:51:22 -0700 From: Franck Martin To: John C Klensin , "ima@ietf.org" Thread-Topic: [EAI] Last Calls issued Thread-Index: AQHNjETJ2J9GX953VEex5ZXaw4cUiJd+fmSA///zAoCAACutAP///lEAgADR+IA= Date: Fri, 7 Sep 2012 12:51:21 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="Windows-1252" Content-ID: <205A1B12253AA844882E983B8608D4B2@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:51:52 -0000 On 9/7/12 4:20 AM, "John C Klensin" wrote: > > >--On Friday, September 07, 2012 00:25 +0000 Franck Martin > wrote: > >> John, >>=20 >> Thanks for the quick comments/info. >>=20 >> 1) will read RFC 6530 then >>=20 >> 2) the issue is that the MUA is not passed the domain to >> render it to the user. While I understand the goals of MUA UI >> developers are sometimes at the antipodes of the security >> people. I still think it is important to pass this label to >> the MUA. If the MTA and MUA are all UTF8 compatible, then >> there is no issue, but not sure how fast the transition will >> be. This is why I raise this point here and not in >> draft-leiba-5322upd-from-group only. > >The WG has been over this territory several times, although in >slightly different form. Consider that, if the delivery MTA >cannot accept SMTPUTF8 messages, we have a non-issue: such a >message will never reach the mail store, much less the POP or >IMAP client. It is only when all of the following conditions >are met that the situation you are concerned about would arise: > > * The delivery MTA is SMTPUTF8-capable > * The mailstore has been upgraded to match > * The POP and/or IMAP servers have also been upgraded. > * The POP or IMAP client are ASCII-only as far as > headers are concerned. > >Now POP, IMAP, and 5322 (and 5321, but it is not particularly >relevant to POP and IMAP clients) all require that address >fields, with the exception of the group syntax (where it is >allowed) consist of a local-part and a domain, separated by "@". >If a non-ASCII address arrives at the POP/IMAP server-client >boundary, it cannot be transmitted to the client without doing >something that, as far as the existing/legacy specs are >concerned, is screwy. The WG concluded that, of many options >that it considered, the use of Group syntax, even in the >backward-pointing fields, was least likely to cause harm. But >suppose some other conclusion had been reached and the plan was >to change the "From:" syntax to permit "<@domain>" without a >local part, or perhaps <[]@domain>, or perhaps a new header >field, say=20 > > From-Domain: Domain-using-A-labels > >In each of those cases, the odds are extremely high that a >legacy client would either reject the construction as a syntax >error or get terribly confused. None of those options would >help you. So what you now need is a client that is upgraded to >handle the new form of the information. The WG's conclusion was >that it made no sense to encourage such "halfway" client >upgrades because the work needed to implement and deploy them >wasn't likely to be that much different from the work to >implement and deploy fully upgraded, SMTPUTF8-capable, clients. >And they don't have the problem. > >So I think the advice we would give you is that, if you need the >MUA to receive domain information contained in non-ASCII "From:" >addresses, you recommend either fully upgraded MUAs or that the >delivery MTA be configured to not accept SMTPUTF8 mail at all. >Nasty tradeoff, but you are going to find everything else more >than a little fragile. > >> 3) I understand the local part cannot be punycoded. So what I >> was suggesting is a constant string for the local part that >> means, could not convert, but the domain part would be puny >> code > >Again, considered by the WG as an alternative and rejected. >Part of the reason is that while there are a bunch of >conventions floating around, the community has been been very >reluctant to reserve local-part strings in the protocol: >"postmaster" is the only exception, and it goes back to almost >the beginning. > >> Something like >>=20 >> From: "John Doe" >> Or >> From: "John Doe" >>=20 >> The noreply string tends to be interpreted by various automatic >> software(email list management) correctly. > >And to be interpreted as a normal address by other things. And will just bounce, like many other things=8A I don't see the issue to reserve a local-part string in the protocol if it ensure greater security with not loosing much convenience. > >> Finally, netease (chinese biggest ISP) is doing DMARC >> filtering, I'm worried they will be an early adopter of this >> spec and will quickly get conflicted with DMARC, and I'm not >> sure DMARC will win over the users requesting readable UTF8 >> email addresses. > >I'll let the readers of this list who are more familiar with the >situation in China respond if they think it appropriate but, >again, the only good solution is to be sure users have >fully-upgraded clients. > >> I'm not sure about the warning, this could indeed help to get >> people to be careful, I'm worried that if we put in DMARC to >> reject such emails, as draft-leiba-5322upd-from-group security >> note says, then getting DMARC though IETF will hit a conflict >> with a prior RFC and therefore rewritten in a way that >> minimizes DMARC effectiveness. May be the security >> consideration in draft-leiba-5322upd-from-group just need to >> be copied and pasted in all these RFCs? > >Again, I think the actual situation here will be much more >constrained in practice than you are assuming. And, again, >there is no satisfactory solution other than upgrading. A >strong warning to not use empty group syntax in a remapped >"From:" field is essentially a request to refuse to deliver mail >content with internationalized headers to a legacy client. That >causes a lot of messages to fail too. Getting the client to upgrade to benefit of the complete From: info, seems a reasonable approach, but I'm worried of the time the situation is left in limbo. The MTA can reject unauthenticated emails following DMARC, but for cousin domains, at the moment we rely on the user to see that the email did not come from the right domain. > >> PS to the PS: shit happens. The DMARC spec is public since end >> of January but similar mechanisms have been tested well >> before. We tried to reach wide, but you can't keep an eye on >> everything and no one raised this issue early to the DMARC >> group AFAIK. I guess, this WG has already considered ADSP, and >> reached a conclusion. I just need to get the executive summary >> ;). > So reading https://datatracker.ietf.org/doc/draft-ietf-eai-email-clients Is there normative information than ensure a receiving SMTPUTF8 compatible MTA MUST reject an email that contains a group syntax address in the From: ? Because there is no reason why the UTF8 email address cannot be transmitted (unless we have some serious relaying). There is still the case of a SMTPUTF8 compatible MTA sending to a legacy MTA, where the From: may contain a group syntax. This would oblige DMARC compatible receivers to upgrade to SMTPUTF8 quickly. I thought tying up the adoption of one standard to the other is frown upon=8A I'm still uneasy as the WG prefers a convenient solutions rather than a secure one, and all of this is handled in the backend, it is not like we ask the user to do these things. I'm afraid we are opening a door where the group syntax can be used even in a fully UTF8 compatible environment. As a transition mechanism, may be, and even, we have seen transition can take years... From prvs=590c51800=fmartin@linkedin.com Fri Sep 7 05:58:00 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC7D21E8041 for ; Fri, 7 Sep 2012 05:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zf4JgGVoguM2 for ; Fri, 7 Sep 2012 05:57:59 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEC721F86EC for ; Fri, 7 Sep 2012 05:57:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1347022679; x=1378558679; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=7k4zbGe2Db7qTw1AYGhHGKmkdfRA/zAthU3TYd1fMTc=; b=q8ZrrjMQB2qDGd8O2JJnYzHYHxQg+CN9bGkYLo+VjT3jNyyAbQKfyNUA 4QDembsZ2fLbvBlbg37fEHytDTWA5mS8H9t6Nre97Jyn8o9/KfFxLhuzG r8KvTFV8WURZWsvC6oJjcIkruyOPwt3hwHx5wuHvQ+fn0Eiph+yNWWzBL s=; X-IronPort-AV: E=Sophos;i="4.80,385,1344236400"; d="scan'208";a="23634791" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 7 Sep 2012 05:57:35 -0700 Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.01.0218.012; Fri, 7 Sep 2012 05:57:35 -0700 From: Franck Martin To: John C Klensin , Arnt Gulbrandsen , "ima@ietf.org" Thread-Topic: [EAI] Last Calls issued Thread-Index: AQHNjETJ2J9GX953VEex5ZXaw4cUiJd+fmSA///zAoCAACutAP///lEAgABGfICAAIIyAP//5mYAAASTkgA= Date: Fri, 7 Sep 2012 12:57:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="Windows-1252" Content-ID: <36663FD256C96F44815A875883A7BE5B@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:58:00 -0000 On 9/7/12 2:46 PM, "John C Klensin" wrote: > > >--On Friday, September 07, 2012 12:18 +0000 Franck Martin > wrote: > >>=20 >>=20 >> On 9/7/12 8:32 AM, "Arnt Gulbrandsen" >> wrote: >>=20 >>> John Klensin answers Franck Martin: >>>> So I think the advice we would give you is that, if you need >>>> the MUA to receive domain information contained in non-ASCII >>>> "From:" addresses, you recommend either fully upgraded MUAs >>>> or that the delivery MTA be configured to not accept >>>> SMTPUTF8 mail at all. >>>=20 >>> Keep in mind that upgrading MUAs to accept internationalized >>> mail is extremely easy. >>=20 >> Like it is easy to upgrade away from IE6? Still 0.6% of users >> are using it, and it was still at 2% a year ago. >>=20 >> Upgrades are slow, and 2% is still a number that scares >> marketers when you tell them you won't be supporting that >> many... > >But, Franck, that is exactly where Arnt's comments and mine come >together. There are only three choices for getting the >information you want to a client: > >(i) Upgrade the client to accept internationalized mail. When is the upgrade date? ;) > >(ii) Upgrade the client to accept and process some new and funky >syntax (or specialized new header fields) to as to preserve some >of the information in internationalized mail but not to actually >accept internationalized mail. I'm not talking of some funky syntax here. Not sure why you focus on that. A reserved local string is not funky syntax. > >(iii) Decide that internationalized mail won't get to the >client, whether it is rejected by the delivery MTA or just not >delivered in some other way. You know if this traffic is non-null the marketers will scream=8A.So deciding unilaterally/locally to reject this type of email will not fly. This has to be defined in the standard. From arnt@gulbrandsen.priv.no Fri Sep 7 06:39:42 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B2621E8051 for ; Fri, 7 Sep 2012 06:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40qDmillZuZ6 for ; Fri, 7 Sep 2012 06:39:42 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE18421E8050 for ; Fri, 7 Sep 2012 06:39:41 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5089AF94F12; Fri, 7 Sep 2012 13:39:40 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1347025179-9641-9640/10/2; Fri, 7 Sep 2012 13:39:39 +0000 Message-Id: <5049F956.30501@gulbrandsen.priv.no> Date: Fri, 7 Sep 2012 15:40:38 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: ima@ietf.org References: <504994F5.9080805@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 13:39:42 -0000 Franck Martin answers me: > Like it is easy to upgrade away from IE6? Still 0.6% of users are using > it, and it was still at 2% a year ago. No, not like that. If you want an IE comparison: like it was easy for IE to implement support for . Arnt From jyee@afilias.info Fri Sep 7 07:45:20 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183D721E80BE for ; Fri, 7 Sep 2012 07:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUxfvKrt5Fpg for ; Fri, 7 Sep 2012 07:45:19 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAC021E80BD for ; Fri, 7 Sep 2012 07:45:19 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1T9zo6-0008P6-4r for ima@ietf.org; Fri, 07 Sep 2012 14:45:18 +0000 Received: from mail-qa0-f44.google.com ([209.85.216.44]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1T9zo6-00040U-4e for ima@ietf.org; Fri, 07 Sep 2012 14:45:18 +0000 Received: by qafi29 with SMTP id i29so5777890qaf.10 for ; Fri, 07 Sep 2012 07:45:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=4B3Euhr96jFz5l3cn4oJNVdJ3PaXFzOmN0YcU6pB9tE=; b=YpBYcjxMqi/JqwAlidCbs5SULLfW+WS9HXL3OcO81r/03S4+AGrrK40Ey1xBmwaDXF x2C6YIIF3GWhGZYufGf5/Pm/GnTuCvdhRTpQaUCxQNe3kzbzhB9dmiuVdsZIqiI9f4Rd bGqDI5cu1uSJYOTOht6n2FDgOfHn7u9m8QCZ66yE74k9gYFUx89eq8pJ0VUwULMG3ICz RDTZbnQb6t28EfS6qi5VGurID2o+f+HlaYWaMZ0oj6LDg2qxNJDlOxwEPsCcZpf59njU Hhg2wtMfgLWfHfkXcXcHkvglI5+Tb4Qb/z0RZ1he7Ewre0t1VqsgYZyeo1A5XEGGiagB mkQg== MIME-Version: 1.0 Received: by 10.224.181.79 with SMTP id bx15mr7974567qab.41.1347029112752; Fri, 07 Sep 2012 07:45:12 -0700 (PDT) Received: by 10.49.127.40 with HTTP; Fri, 7 Sep 2012 07:45:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 10:45:12 -0400 Message-ID: From: Joseph Yee To: Franck Martin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkK6qI4/m8KcA+nStfpCTxdm3VKuo2P3yDQBZLlA7wG83k46koOl2Jchi8b20C9jSIjm3sy Cc: Arnt Gulbrandsen , "ima@ietf.org" Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:45:20 -0000 On Fri, Sep 7, 2012 at 8:57 AM, Franck Martin wrote: >> >>(ii) Upgrade the client to accept and process some new and funky >>syntax (or specialized new header fields) to as to preserve some >>of the information in internationalized mail but not to actually >>accept internationalized mail. > > I'm not talking of some funky syntax here. Not sure why you focus on that= . > A reserved local string is not funky syntax. Hi Franck, If the string is simple dictionary string, then the chance of stepping over existing user expectation & behaviour is very high. Then the only possible choice left is to concatenate some non-dictionary strings (like xn--*, x-*, *----pleaseupgradeyouremailclient) to make it unique for both human and machine. And this adds some funkiness to the syntax. Then in practice one have to guard the use of the new non-dictionary string in all account name very well against confusion and malicious use. You are not only have to guard against account name under your management, you have to guard the email name with similar pattern coming to your users. Joseph >> >>(iii) Decide that internationalized mail won't get to the >>client, whether it is rejected by the delivery MTA or just not >>delivered in some other way. > > You know if this traffic is non-null the marketers will scream=C5=A0.So > deciding unilaterally/locally to reject this type of email will not fly. > This has to be defined in the standard. > > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From ned+ima@mrochek.com Fri Sep 7 07:45:44 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A257521E80BA for ; Fri, 7 Sep 2012 07:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEvKkBzPwH0U for ; Fri, 7 Sep 2012 07:45:44 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id DA9F721E80B2 for ; Fri, 7 Sep 2012 07:45:43 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJYT4AGAY8007L7O@mauve.mrochek.com> for ima@ietf.org; Fri, 7 Sep 2012 07:40:40 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Fri, 7 Sep 2012 07:40:35 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OJYT47N8MI0006TF@mauve.mrochek.com> Date: Fri, 07 Sep 2012 07:30:11 -0700 (PDT) In-reply-to: "Your message dated Fri, 07 Sep 2012 08:46:42 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: John C Klensin Cc: Arnt Gulbrandsen , ima@ietf.org Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:45:44 -0000 > --On Friday, September 07, 2012 12:18 +0000 Franck Martin > wrote: > > > > > > On 9/7/12 8:32 AM, "Arnt Gulbrandsen" > > wrote: > > > >> John Klensin answers Franck Martin: > >>> So I think the advice we would give you is that, if you need > >>> the MUA to receive domain information contained in non-ASCII > >>> "From:" addresses, you recommend either fully upgraded MUAs > >>> or that the delivery MTA be configured to not accept > >>> SMTPUTF8 mail at all. > >> > >> Keep in mind that upgrading MUAs to accept internationalized > >> mail is extremely easy. > > > > Like it is easy to upgrade away from IE6? Still 0.6% of users > > are using it, and it was still at 2% a year ago. > > > > Upgrades are slow, and 2% is still a number that scares > > marketers when you tell them you won't be supporting that > > many... > But, Franck, that is exactly where Arnt's comments and mine come > together. There are only three choices for getting the > information you want to a client: > (i) Upgrade the client to accept internationalized mail. > (ii) Upgrade the client to accept and process some new and funky > syntax (or specialized new header fields) to as to preserve some > of the information in internationalized mail but not to actually > accept internationalized mail. > (iii) Decide that internationalized mail won't get to the > client, whether it is rejected by the delivery MTA or just not > delivered in some other way. To be fair, these group thingies are being produced in downgrade context where the expectation is that the client hasn't been upgraded. If this was known to cause an actual problem with a widely deployed client then I and probably several others would have objected. But tests were done and that doesn't appear to be the case. If there's evidence (not speculation, evidence) to the contrary, please present it. But the broader point is that there is no magic bullet here. It would have been great if the magic upgrade fairy had graced us with its presence and fixed the installed base with a wave of the wand. But that didn't happen, so a choice had to be made amongst various less-than-great alternatives, each involving some sort of tradeoff. > The POP-IMAP "downgrade" mechanisms are really members of the > family of (iii) -- they don't deliver the message, they deliver > a surrogate that helps the user understand that some things are > inaccessible until the client is downgraded (or they access the > message through some other client, etc.). If one concludes > those surrogate messages are a bad idea, then one works out > non-delivery in some other way, such as by hiding the fully > internationalized messages from the user entirely. Reasons why > one might conclude "bad idea" include not being able to reply to > the message (from one perspective, not because information is > lost but because one did not receive the message), because key > information is lost in the surrogate-creation process (your > situation with domain names is just one example -- message > signatures will probably be high on the list for others), as > well as "just too much trouble". > The WG concluded that, of those three choices, the second one > makes no sense. It is substantially as hard to implement as the > first. It involves the same statistics, the same deployment > problems, and the same likely resistance from marketers. Exactly. And as it happens I personally disagree with the choice that was made. But you won't find me arguing that there was a way to avoid all the tradeoffs. > Wrt IE and other examples, the problem is, in part, the need to > install something new, learn something new, etc., without an > expectation of improvements that is compelling to users. Here, > that message is very simple: "you want to be able to send > messages to or receive mail from users with internationalized > addresses or setups, you are going to upgrade". > In terms of speed of penetration of the upgrades, I'd actually > worry a lot more about users of European, Latin-script, > languages than about China. For the former, ASCII may be "good > enough". More likely ISO-8859-X or something similar at this point. But from an EAI perspective it's pretty much the same thing. For the latter, a fairly strong case has been made > that it is not. That is precisely why Jiankang's data show > implementation commitments that are well ahead of any > implementation commitments we've seen from Europe or North > America. How the transition will play out in the latter in > terms of what delivery servers will accept (and what addresses > will be permitted) relative to development and deployment of POP > and IMAP clients and servers is, at this point, anyone's guess. > For China, it will deploy because people are convinced that they > need it and because, from a marketing standpoint, critical mass > will probably be reached quickly and _not_ having upgraded > software will become intolerable. At least that is the general > best guess. That's certainly the hope. And the risk. Ned From arnt@gulbrandsen.priv.no Fri Sep 7 07:48:51 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463AD21E80BF for ; Fri, 7 Sep 2012 07:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rq5UAyDfocYx for ; Fri, 7 Sep 2012 07:48:50 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id C13F621E80BE for ; Fri, 7 Sep 2012 07:48:50 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 2A8DBFA13F1; Fri, 7 Sep 2012 14:48:50 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1347029328-9641-9640/10/3; Fri, 7 Sep 2012 14:48:48 +0000 Message-Id: <504A098B.5080607@gulbrandsen.priv.no> Date: Fri, 7 Sep 2012 16:49:47 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: ima@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: [EAI] simpledowngrade terminology X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:48:51 -0000 On 09/07/2012 02:46 PM, John C Klensin wrote: > The POP-IMAP "downgrade" mechanisms are really members of the > family of (iii) -- they don't deliver the message, they deliver > a surrogate that helps the user understand that some things are > inaccessible until the client is downgraded (or they access the > message through some other client, etc.). Surrogate message. That's the right term. If I had thought of that, that's what I would have written. Is it still worth changing, and does anyone else agree that surrogate is a better word than synthetic? (Yes, the message is both synthetic and a surrogate. But I feel that surrogate goes to the heart of the thing.) Arnt From klensin@jck.com Fri Sep 7 08:43:49 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679B621F8722 for ; Fri, 7 Sep 2012 08:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRK7kZato9px for ; Fri, 7 Sep 2012 08:43:49 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id D51BB21E8034 for ; Fri, 7 Sep 2012 08:43:48 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TA0ii-0003V5-7y; Fri, 07 Sep 2012 11:43:48 -0400 Date: Fri, 07 Sep 2012 11:43:43 -0400 From: John C Klensin To: Arnt Gulbrandsen , ima@ietf.org Message-ID: <5E028D1956183BC5539C34E0@JcK-HP8200.jck.com> In-Reply-To: <504A098B.5080607@gulbrandsen.priv.no> References: <504A098B.5080607@gulbrandsen.priv.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 Subject: Re: [EAI] simpledowngrade terminology X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:43:49 -0000 --On Friday, September 07, 2012 16:49 +0200 Arnt Gulbrandsen wrote: > On 09/07/2012 02:46 PM, John C Klensin wrote: >> The POP-IMAP "downgrade" mechanisms are really members of the >> family of (iii) -- they don't deliver the message, they >> deliver a surrogate that helps the user understand that some >> things are inaccessible until the client is downgraded (or >> they access the message through some other client, etc.). > > Surrogate message. That's the right term. > > If I had thought of that, that's what I would have written. Is > it still worth changing, and does anyone else agree that > surrogate is a better word than synthetic? > > (Yes, the message is both synthetic and a surrogate. But I > feel that surrogate goes to the heart of the thing.) First, let's see if others agree (or at least don't object). If they do and Pete is ok with this, let's handle this (and any other comments from within the WG) as a small variation on the normal Last Call process: Joseph or I will send a note to the IESG around the 19th or 20th summarizing any changes the WG concluded it ought to make. For planning purposes, I don't want to see new drafts before the 21st because they would just confuse people about what Last Call comments are based on. But I hope to have new drafts of any documents we decide should be modified (I know that popimap-downgrade is already on the list and your note probably adds simple downgrade) can be posted right after that so the actual IESG review and vote can occur on cleaned-up documents that reflect any Last Call comments with which we agree. Ok? john From arnt@gulbrandsen.priv.no Fri Sep 7 08:47:12 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D2821E8040 for ; Fri, 7 Sep 2012 08:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrdK0cL5YO3o for ; Fri, 7 Sep 2012 08:47:12 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2BF21E8039 for ; Fri, 7 Sep 2012 08:47:12 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 8206FF94F2D; Fri, 7 Sep 2012 15:47:11 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1347032829-9641-9640/10/5; Fri, 7 Sep 2012 15:47:09 +0000 Message-Id: <504A1738.9080300@gulbrandsen.priv.no> Date: Fri, 7 Sep 2012 17:48:08 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: John C Klensin References: <504A098B.5080607@gulbrandsen.priv.no> <5E028D1956183BC5539C34E0@JcK-HP8200.jck.com> In-Reply-To: <5E028D1956183BC5539C34E0@JcK-HP8200.jck.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Cc: ima@ietf.org Subject: Re: [EAI] simpledowngrade terminology X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:47:12 -0000 On 09/07/2012 05:43 PM, John C Klensin wrote: > Ok? Sure. I'm happy with or without the change. Either way is good and while "best" is better than "good", the price of change rises as publication nears. Arnt From Shawn.Steele@microsoft.com Fri Sep 7 09:21:35 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206D221E8040 for ; Fri, 7 Sep 2012 09:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vtfO+34cjVF for ; Fri, 7 Sep 2012 09:21:34 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 44EA321E8034 for ; Fri, 7 Sep 2012 09:21:34 -0700 (PDT) Received: from mail98-db3-R.bigfish.com (10.3.81.240) by DB3EHSOBE009.bigfish.com (10.3.84.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Sep 2012 16:21:33 +0000 Received: from mail98-db3 (localhost [127.0.0.1]) by mail98-db3-R.bigfish.com (Postfix) with ESMTP id 25AC62000E1 for ; Fri, 7 Sep 2012 16:21:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h683h839h944hd25hf0ah107ah1220h1288h1155h) Received-SPF: pass (mail98-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.5; KIP:(null); UIP:(null); (null); H:BY2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail98-db3 (localhost.localdomain [127.0.0.1]) by mail98-db3 (MessageSwitch) id 1347034892240974_24842; Fri, 7 Sep 2012 16:21:32 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.236]) by mail98-db3.bigfish.com (Postfix) with ESMTP id 2E098A0067 for ; Fri, 7 Sep 2012 16:21:32 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Sep 2012 16:21:30 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 7 Sep 2012 16:21:27 +0000 Received: from mail202-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Sep 2012 16:21:26 +0000 Received: from mail202-ch1 (localhost [127.0.0.1]) by mail202-ch1-R.bigfish.com (Postfix) with ESMTP id 5FA8460231 for ; Fri, 7 Sep 2012 16:21:26 +0000 (UTC) Received: from mail202-ch1 (localhost.localdomain [127.0.0.1]) by mail202-ch1 (MessageSwitch) id 1347034884944685_20409; Fri, 7 Sep 2012 16:21:24 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail202-ch1.bigfish.com (Postfix) with ESMTP id DE72B220054; Fri, 7 Sep 2012 16:21:24 +0000 (UTC) Received: from BY2PRD0310HT001.namprd03.prod.outlook.com (157.56.236.5) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Sep 2012 16:21:23 +0000 Received: from BY2PRD0310MB354.namprd03.prod.outlook.com ([169.254.6.16]) by BY2PRD0310HT001.namprd03.prod.outlook.com ([10.255.80.36]) with mapi id 14.16.0190.008; Fri, 7 Sep 2012 16:21:22 +0000 From: Shawn Steele To: "ima@ietf.org" , "YAO Jiankang (yaojk@cnnic.cn)" Thread-Topic: Adoption of RFCs? Was RE: Last Calls issued Thread-Index: Ac2NFBtnolVObG+RSc6JgGbaVlovSw== Date: Fri, 7 Sep 2012 16:21:21 +0000 Message-ID: <352CBC94712DF44392EE468860B35D303437273B@BY2PRD0310MB354.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.151.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CNNIC.CN$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: [EAI] Adoption of RFCs? Was RE: Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:21:35 -0000 Jiankang YAO said: > Some email server companies in China will release EAI SMTP server produc= ts =20 > supporting rfc6531 and RFC6532 in the end of this year. > Hope to see available EAI MUA soon. Any specifics or announcements? -Shawn From Shawn.Steele@microsoft.com Fri Sep 7 09:36:55 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD08B21E8054 for ; Fri, 7 Sep 2012 09:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJb6BnvaVgm2 for ; Fri, 7 Sep 2012 09:36:55 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2D17421E804E for ; Fri, 7 Sep 2012 09:36:55 -0700 (PDT) Received: from mail196-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Sep 2012 16:36:54 +0000 Received: from mail196-ch1 (localhost [127.0.0.1]) by mail196-ch1-R.bigfish.com (Postfix) with ESMTP id 327D32601CD for ; Fri, 7 Sep 2012 16:36:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VS0(zzzz1202hzzz2fh2a8h683h839h944hd25hf0ah107ah1220h1288h1155h) Received-SPF: pass (mail196-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Shawn.Steele@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.5; KIP:(null); UIP:(null); (null); H:BY2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail196-ch1 (localhost.localdomain [127.0.0.1]) by mail196-ch1 (MessageSwitch) id 1347035812671432_4240; Fri, 7 Sep 2012 16:36:52 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail196-ch1.bigfish.com (Postfix) with ESMTP id 97AD620010F for ; Fri, 7 Sep 2012 16:36:52 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Sep 2012 16:36:51 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 7 Sep 2012 16:36:51 +0000 Received: from mail177-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Sep 2012 16:35:43 +0000 Received: from mail177-tx2 (localhost [127.0.0.1]) by mail177-tx2-R.bigfish.com (Postfix) with ESMTP id C8C09200F8 for ; Fri, 7 Sep 2012 16:35:43 +0000 (UTC) Received: from mail177-tx2 (localhost.localdomain [127.0.0.1]) by mail177-tx2 (MessageSwitch) id 1347035742138396_13152; Fri, 7 Sep 2012 16:35:42 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.236]) by mail177-tx2.bigfish.com (Postfix) with ESMTP id 1EF7A60043 for ; Fri, 7 Sep 2012 16:35:42 +0000 (UTC) Received: from BY2PRD0310HT001.namprd03.prod.outlook.com (157.56.236.5) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Sep 2012 16:35:41 +0000 Received: from BY2PRD0310MB354.namprd03.prod.outlook.com ([169.254.6.16]) by BY2PRD0310HT001.namprd03.prod.outlook.com ([10.255.80.36]) with mapi id 14.16.0190.008; Fri, 7 Sep 2012 16:35:41 +0000 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: From 'downgrade' was Re: [EAI] Last Calls issued Thread-Index: Ac2NFg5OquxK7GCOQXeMdIHVj6Bbnw== Date: Fri, 7 Sep 2012 16:35:40 +0000 Message-ID: <352CBC94712DF44392EE468860B35D3034372923@BY2PRD0310MB354.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.151.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: [EAI] From 'downgrade' was Re: Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:36:55 -0000 > To be fair, these group thingies are being produced in downgrade context = where the expectation is that the client hasn't been upgraded. And even more, the context includes the recipient corresponding with someon= e that uses an EAI address. So (unless it's mail the user doesn't want, eg= : junk), there's a strong incentive for the user to get a patched mail clie= nt. -Shawn From ned+ima@mrochek.com Fri Sep 7 11:39:38 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562CD21F855F for ; Fri, 7 Sep 2012 11:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti9KzEaxnZFR for ; Fri, 7 Sep 2012 11:39:38 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E1A9C21F854A for ; Fri, 7 Sep 2012 11:39:37 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJZ1AAEYM8007Y31@mauve.mrochek.com> for ima@ietf.org; Fri, 7 Sep 2012 11:34:34 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Fri, 7 Sep 2012 11:34:30 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OJZ1A8KDT80006TF@mauve.mrochek.com> Date: Fri, 07 Sep 2012 11:32:56 -0700 (PDT) In-reply-to: "Your message dated Fri, 07 Sep 2012 11:43:43 -0400" <5E028D1956183BC5539C34E0@JcK-HP8200.jck.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <504A098B.5080607@gulbrandsen.priv.no> <5E028D1956183BC5539C34E0@JcK-HP8200.jck.com> To: John C Klensin Cc: Arnt Gulbrandsen , ima@ietf.org Subject: Re: [EAI] simpledowngrade terminology X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 18:39:38 -0000 > --On Friday, September 07, 2012 16:49 +0200 Arnt Gulbrandsen > wrote: > > On 09/07/2012 02:46 PM, John C Klensin wrote: > >> The POP-IMAP "downgrade" mechanisms are really members of the > >> family of (iii) -- they don't deliver the message, they > >> deliver a surrogate that helps the user understand that some > >> things are inaccessible until the client is downgraded (or > >> they access the message through some other client, etc.). > > > > Surrogate message. That's the right term. > > > > If I had thought of that, that's what I would have written. Is > > it still worth changing, and does anyone else agree that > > surrogate is a better word than synthetic? I like surrogate better - more specific - but if we've used synthetic in multiple places we need to coordinate the change. > > (Yes, the message is both synthetic and a surrogate. But I > > feel that surrogate goes to the heart of the thing.) > First, let's see if others agree (or at least don't object). If > they do and Pete is ok with this, let's handle this (and any > other comments from within the WG) as a small variation on the > normal Last Call process: Joseph or I will send a note to the > IESG around the 19th or 20th summarizing any changes the WG > concluded it ought to make. WFM. Ned From presnick@qualcomm.com Fri Sep 7 14:13:33 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A71C21E80DE for ; Fri, 7 Sep 2012 14:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.45 X-Spam-Level: X-Spam-Status: No, score=-106.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moEiuFUT+P3s for ; Fri, 7 Sep 2012 14:13:32 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6F41921E80D8 for ; Fri, 7 Sep 2012 14:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1347052412; x=1378588412; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; bh=0cRWaqAi2VF0PMqqTtoZuRytxjcIXQjljYMT+xm/Z9s=; b=ThkbptAJPicJU2z9F7r3kUP/EztyFwY4iYgUc7ABa+zeSPEuhTEtQsuA JUl4zuFHiHNd4i/ayLLA2KaPZz/+vmBzbT+s5hlkk4gy3Lc12hflDBKYU XXd2w/3aLD0mUr7HRYiuKr9mA7M8T0i70HYUFO1LWwXefrMDb4Wd76tnR w=; X-IronPort-AV: E=McAfee;i="5400,1158,6828"; a="234243375" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 07 Sep 2012 14:13:32 -0700 X-IronPort-AV: E=Sophos;i="4.80,387,1344236400"; d="scan'208";a="161352966" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Sep 2012 14:13:32 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.1; Fri, 7 Sep 2012 14:13:31 -0700 Message-ID: <504A6379.5080700@qualcomm.com> Date: Fri, 7 Sep 2012 16:13:29 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <0C9D73B1E75EE8EBA00A6306@JcK-HP8200.jck.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: Barry Leiba , ima@ietf.org Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 21:13:33 -0000 On 9/6/12 4:33 PM, John C Klensin wrote: > --On Thursday, September 06, 2012 17:15 -0400 Barry Leiba > wrote: > > >>> That certainly works for me -- we have occasionally gotten >>> signals to the contrary from some other ADs, but you and Pete >>> have the lead on this. >>> >> Understood, and Pete can say otherwise: he's the responsible >> AD. I think expressions of "I read it, and it's ready" from >> WG participants during WGLC are valuable, to assure us that >> there was sufficient review. But during IETF last call, >> unless there are issues the WG has to respond to, I think the >> WG record can stand on its own. >> > Certainly that is consistent with my personal view. Unless the > IETF Last Call turns up controversies, a conclusion that is > carefully checked within the WG should basically stand on its > own, without adding to the noise on the IETF list. > Indeed, not only do I agree that they add little value, I have sometimes been downright negative about such comments. My own view is that consensus building (and judging) is about finding objections and addressing them. Statements of support are nice, but are simply happy fluff. They are equivalent to (though much nicer than) statements of the form, "I just don't like this document." (*Shrug*) Not helpful. So, please do keep an eye on the IETF list and address any objections. But statements of support or enthusiasm are unnecessary. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From barryleiba.mailing.lists@gmail.com Sun Sep 9 08:24:33 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7C621F8496 for ; Sun, 9 Sep 2012 08:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.643 X-Spam-Level: X-Spam-Status: No, score=-102.643 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MANuVcx1K8zq for ; Sun, 9 Sep 2012 08:24:29 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A4A5B21F8469 for ; Sun, 9 Sep 2012 08:24:28 -0700 (PDT) Received: by lahm15 with SMTP id m15so667707lah.31 for ; Sun, 09 Sep 2012 08:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fzfW9XuqYhplbjcOAunrfevgLnaxM6cbowUhmgrRFhk=; b=tXQDV+qqAIHeGS4akud+4Rt9dF2hbzQJUm52f6BdI0+zptksLil067A7pKfki8mvPh eTpl6h+AxOb1M6dexsbDzpnL0H3FqhA6X4G+i9rRqDBwIIy82NkOdh4/17dXSoOtLhE/ DYxAUxc6RBgw+xwAbuXBbUUt0FRQmCQ9PGsONSS+5JV+pFuoesPt/0RLDTd4Dwm8N6Ws B8XcXahy6+qlnahRR//R4cFjEgEuL141n7jBd7Yqo2FFTG/RvKG+3WbsUKw3KAggYd2L t3bFbvixoUs8rqUIF54qlUW3B+DSU8Q8JTOmA4+A3PG8c+NVvNyREziOjIpyrDkBoxAx aQOQ== MIME-Version: 1.0 Received: by 10.112.51.228 with SMTP id n4mr4059285lbo.55.1347204266118; Sun, 09 Sep 2012 08:24:26 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Sun, 9 Sep 2012 08:24:26 -0700 (PDT) In-Reply-To: References: Date: Sun, 9 Sep 2012 11:24:26 -0400 X-Google-Sender-Auth: 67O6huaVcqDri1gIQMzit8HaUlo Message-ID: From: Barry Leiba To: Franck Martin Content-Type: text/plain; charset=ISO-8859-1 Cc: Arnt Gulbrandsen , "ima@ietf.org" Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 15:24:33 -0000 >>(ii) Upgrade the client to accept and process some new and funky >>syntax (or specialized new header fields) to as to preserve some >>of the information in internationalized mail but not to actually >>accept internationalized mail. > > I'm not talking of some funky syntax here. Not sure why you focus on that. > A reserved local string is not funky syntax. It's a Very Big Deal to reserve a local-part, and I would agree to do it only in extreme circumstances. This isn't one. What's more, this doesn't even *approach* any criteria I might use to agree to do that, because this is a transitional case in a *very* limited situation. Further, the overarching point here is to make sure that whatever is in the From *cannot* be a valid address that can ever be replied to. That means that it *cannot* be a valid address *currently*... that it will be something that existing non-EAI-compliant M*As will allow use of in replies. Any reserved name will be allowed in replies by any M*A that is not updated to conform to this, and that could cause someone to intercept replies by registering whatever local-part we try to reserve, hoping that he will snag confidential replies that way. We absolutely can't allow that. --- John has reminded you of this, but let me highlight it and ask some specific questions: - These protocols suggest using group syntax in From *only* in the specific situation where an EAI-compliant IMAP or POP server is giving the message to a non-EAI-compliant IMAP or POP client, in response to that client's asking for it. - Protocols such as ADSP and DMARC will mostly be used *upstream* of that path, at or before the message reaches the MDA. - The use of the group syntax is *only* to allow the non-EAI-compliant IMAP or POP client to see some semblance of the message, rather than being told that the message is unavailable to it. - The translation of the non-ASCII From address into group syntax will preserve the address, in 2047-encoded form, as the "name" of the group, so an MUA can still display it. Here are my questions, Franck: - To what extent do you think DMARC (or ADSP) will be applied *in clients* (MUAs)? - To what extent do you think there will be situations where DMARC will cause the message to be flagged such that the MUA warns the user herself to look carefully at the "from" domain? - In those situations, do you think my last point above will not suffice, that the user will not be able to look at the 2047-decoded group name? - Do you think, given that these specs are coming out *before* DMARC, that it's unreasonable to expect (or for DMARC to require) that clients that are updated to conform to it also implement EAI? Barry From barryleiba.mailing.lists@gmail.com Sun Sep 9 08:33:26 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3E421F84D7; Sun, 9 Sep 2012 08:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.935 X-Spam-Level: X-Spam-Status: No, score=-102.935 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWWz-zkp7v3s; Sun, 9 Sep 2012 08:33:26 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5D3221F84B2; Sun, 9 Sep 2012 08:33:25 -0700 (PDT) Received: by lahm15 with SMTP id m15so670548lah.31 for ; Sun, 09 Sep 2012 08:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=dAw/tVm17BEH1lyk1a5VvINjDvtUlsWxfeYyL3cWLzA=; b=UuhDvXwEMRD+3MvFgidFn7/maEXTCuvQ3RIQnQvVO/AuvqfeX4u3hhr2/QDtmTWnBH vmBIvuySBUDHMd53ypZbbh+oL3+10r1XrZBK4zJeBLiIwjHnQsrXpBQSHbpITmU8Q7d5 Q6QYTBea2D1vscYfg6dsQtbVxkIXZnPKAwNyT18Z2aU16CH6ZLA7sGuJhBXLB1lwhiZO w25Uzu+EOocZdAcA3XifsVmaOKdMqMPOhqXYxNQco1ZkU8HPqOg7yCogBcmHqtxfXWJG cv9yyqSKpkCvV31wlIT3fyvnwSiNHExrpN+i2685+TOTTE7POqT2ldf1JJGMBKIF7yc3 43+g== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr6957241lab.29.1347204804446; Sun, 09 Sep 2012 08:33:24 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.91.33 with HTTP; Sun, 9 Sep 2012 08:33:24 -0700 (PDT) In-Reply-To: <20120906150526.5342.57611.idtracker@ietfa.amsl.com> References: <20120906150526.5342.57611.idtracker@ietfa.amsl.com> Date: Sun, 9 Sep 2012 11:33:24 -0400 X-Google-Sender-Auth: ElI_317zTH8MoKfBPUTaExAp7W0 Message-ID: From: Barry Leiba To: ietf@ietf.org, ima@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [EAI] Last Call: (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 15:33:26 -0000 > The IESG has received a request from the Email Address > Internationalization WG (eai) to consider the following document: > - 'Post-delivery Message Downgrading for Internationalized Email > Messages' > as Proposed Standard Rats; I missed this in earlier review: -- Section 3.2.1 -- This procedure may generate empty elements in "From:", "Sender:" and "Reply-To:" header fields. [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty) elements in "From:", "Sender:" and "Reply-To:" header fields. It does not. It adds group syntax to "From" only. Group syntax is already allowed in "Reply-To", and the draft does not change the rules for "Sender". If this spec also needs "Sender" to change, I can update the 5322upd-from-group for that, but it's not there now. Barry From klensin@jck.com Sun Sep 9 08:48:15 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15F821F851B; Sun, 9 Sep 2012 08:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tod-2s4YUVl5; Sun, 9 Sep 2012 08:48:15 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 79F2521F84D6; Sun, 9 Sep 2012 08:48:15 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TAjk5-000Btl-HH; Sun, 09 Sep 2012 11:48:13 -0400 X-Vipre-Scanned: 04864E7D002C3104864FCA-TDI Date: Sun, 09 Sep 2012 11:48:12 -0400 From: John C Klensin To: Barry Leiba , ietf@ietf.org, ima@ietf.org Message-ID: In-Reply-To: References: <20120906150526.5342.57611.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [EAI] Last Call: (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 15:48:16 -0000 --On Sunday, September 09, 2012 11:33 -0400 Barry Leiba wrote: >... > Rats; I missed this in earlier review: > > -- Section 3.2.1 -- > > This procedure may generate empty elements in > "From:", "Sender:" and "Reply-To:" header fields. > [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow > (empty) elements in "From:", "Sender:" and > "Reply-To:" header fields. > > It does not. It adds group syntax to "From" only. Group > syntax is already allowed in "Reply-To", and the draft does > not change the rules for "Sender". > > If this spec also needs "Sender" to change, I can update the > 5322upd-from-group for that, but it's not there now. Barry, I think it does. The presumption (since before 822) has been that "Sender:" can contain any address that can appear in "From:". The ancient history is that "From:" need not even contain a deliverable address if "Sender:" is specified to match a business correspondence model in which: From: "Big boss who doesn't use computers" Sender: Assistanct-to-boss@example.com has to be legitimate. 5322 and its predecessors took some of that capability away, but the only difference now is that "From:" can take a list of mailboxes and "Sender:" can take only one. I think 5322upd-from-group needs to apply to both backward-pointing address types to be effective for what popimap-downgrade needs. Sorry for not finding this in my reviews -- I should have. john From barryleiba@gmail.com Sun Sep 9 08:53:00 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F5921F8513; Sun, 9 Sep 2012 08:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.936 X-Spam-Level: X-Spam-Status: No, score=-102.936 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2V9SAO1dbUA; Sun, 9 Sep 2012 08:53:00 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC2D821F84F8; Sun, 9 Sep 2012 08:52:59 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so302716vcb.31 for ; Sun, 09 Sep 2012 08:52:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wHWc2Auyk91xXKC4DSP61nLKsdSFUwhQ+Uh2DTYDFSo=; b=YtlZ6/u4ZBR771KMS48WKwB0MNujhs38kV01sjYgF1LeA0bo/pIJwiBYO20N/Xl3Yi 9bIDfjBixouonbbdb2sU3c8WOyoPQokFogIC1dzuj5gtpiT3LSDr4XDJh7xDYLRgufsa wkiUsYpYvW2zLwclpOoeNsxfGhOtacfd9bVKlHt2VGmgoEY/Ki56uLzgI2+m+6V+v2Oj GL2SHH7qPqUHkPRY2YfQ8rZ6V3vaWabyVbkdsYFou3hwF5ZMw8ThFf6Z8ar5bSOXg/Fi zNNhUw5YJp45rTU4xFbJHtX1jjd41CIvn6J86rLO+qYKdiSueB/LDVcz243qfO+oBNPx leRA== MIME-Version: 1.0 Received: by 10.58.102.80 with SMTP id fm16mr2246940veb.2.1347205979486; Sun, 09 Sep 2012 08:52:59 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.58.41 with HTTP; Sun, 9 Sep 2012 08:52:59 -0700 (PDT) In-Reply-To: References: <20120906150526.5342.57611.idtracker@ietfa.amsl.com> Date: Sun, 9 Sep 2012 11:52:59 -0400 X-Google-Sender-Auth: -YswM3VsZxRz7NBbWv5fZjD2kKQ Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: ietf@ietf.org, ima@ietf.org Subject: Re: [EAI] Last Call: (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 15:53:00 -0000 > I think 5322upd-from-group needs to apply to both > backward-pointing address types to be effective for what > popimap-downgrade needs. I will make the change. I'll also remind the EAI group that there have been a couple of objections to the 5322upd-from-group spec, which I have to address. I might do that by scoping it down a bit with some "SHOULD NOT use" sort of language to address those concerns. Have to review them and see. > Sorry for not finding this in my reviews -- I should have. As should I have. Flrg. Barry From barryleiba@gmail.com Sun Sep 9 08:55:49 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505D521F8522; Sun, 9 Sep 2012 08:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.937 X-Spam-Level: X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFrjBoVMTysz; Sun, 9 Sep 2012 08:55:48 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AE9E521F851B; Sun, 9 Sep 2012 08:55:48 -0700 (PDT) Received: by vbal1 with SMTP id l1so1854084vba.31 for ; Sun, 09 Sep 2012 08:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bGnmI7TS/iVNaJr0FDOIr2Xvb084KKJR6IWAsxF1KDk=; b=kfMBxHb8SIx6QG7BYjWJZmwI7NoKayqXmeeiFsBAdrCQn013eEEBca64Nk3gJPFqe+ ronmMCieD/c+gqk0tzUPsyGGOjzb/HltwVni6SGih9EC602SibAzGvFiUkJK1u74UPQX 0OXN4OHiVkcUKAHrhvbIUjUOfojy8sbKclRn7mnq5xefOk79qgUahuCbbptw6gXj5K0c EhoCaQAFpOnREVQV4LgdZ5BYwx9UL75PHniijUbyECSY+BXsM24wWJw71llqp9j3BUW3 4sii26OkrwyNFTzKh0cbUpZbq8WrkA28hX/Zwsj8fMGT7ixTDI76xVQEuap6Wwe/5VK1 JAbw== MIME-Version: 1.0 Received: by 10.220.149.6 with SMTP id r6mr15270571vcv.53.1347206143675; Sun, 09 Sep 2012 08:55:43 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.58.41 with HTTP; Sun, 9 Sep 2012 08:55:43 -0700 (PDT) In-Reply-To: References: <20120906150526.5342.57611.idtracker@ietfa.amsl.com> Date: Sun, 9 Sep 2012 11:55:43 -0400 X-Google-Sender-Auth: gUA6Eqyn-EIbBpR7VNVX577851I Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: ietf@ietf.org, ima@ietf.org Subject: Re: [EAI] Last Call: (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 15:55:49 -0000 >> I think 5322upd-from-group needs to apply to both >> backward-pointing address types to be effective for what >> popimap-downgrade needs. > > I will make the change. But in any case, the downgrade doc needs to remove "reply-to" from the list of header fields that 5322upd-from-group changes. Maybe this: OLD This procedure may generate empty elements in "From:", "Sender:" and "Reply-To:" header fields. [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty) elements in "From:", "Sender:" and "Reply-To:" header fields. NEW This procedure may generate empty elements in "From:", "Sender:" and "Reply-To:" header fields. [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty) elements in "From:" and "Sender:". Barry From john-ietf@jck.com Sun Sep 9 09:15:23 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8442021F8523; Sun, 9 Sep 2012 09:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xn-0KmyFzfxA; Sun, 9 Sep 2012 09:15:23 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id EF1F721F8522; Sun, 9 Sep 2012 09:15:22 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TAkAM-000C0e-3j; Sun, 09 Sep 2012 12:15:22 -0400 X-Vipre-Scanned: 049F282F002C31049F297C-TDI Date: Sun, 09 Sep 2012 12:15:21 -0400 From: John C Klensin To: Barry Leiba Message-ID: In-Reply-To: References: <20120906150526.5342.57611.idtracker@ietfa.amsl.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 Cc: ietf@ietf.org, ima@ietf.org Subject: Re: [EAI] Last Call: (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 16:15:23 -0000 --On Sunday, September 09, 2012 11:52 -0400 Barry Leiba wrote: >> I think 5322upd-from-group needs to apply to both >> backward-pointing address types to be effective for what >> popimap-downgrade needs. > > I will make the change. I'll also remind the EAI group that > there have been a couple of objections to the > 5322upd-from-group spec, which I have to address. I might do > that by scoping it down a bit with some "SHOULD NOT use" sort > of language to address those concerns. Have to review them > and see. My suggestion is to say something like the following: A great deal of Internet email procedures and software assume that the addresses in "From:" and "Sender:" fields can be replied to and are suitable for use in mail organizing and filtering. The use of groups instead of mailboxes may disrupt those uses. Consequently, with this specification legitimizes the use of group syntax, that syntax should be used in those fields only under special circumstances and with caution. In particular, users and MUAs should generally not permit the use of group syntax in those fields in outgoing messages since the syntax will usually provide even less information than a null address ("<>") which is already prohibited by RFC 5321. That could be either in Security Considerations or a separate section. You could even do something radical and incorporate it as a section called "Applicability" and use the words "LIMITED USE" (and, since no one seems to remember, a citation of RFC 2026 Section 3.3). You can probably figure out how to use fewer words, but something like that would address the comments I've seen so far and, IMO, generally strengthen the spec. best, john From sm@resistor.net Sun Sep 9 09:45:25 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF3821F849C for ; Sun, 9 Sep 2012 09:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZNvNOKFynSp for ; Sun, 9 Sep 2012 09:45:24 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 327A021F8496 for ; Sun, 9 Sep 2012 09:45:24 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q89GjELL004653; Sun, 9 Sep 2012 09:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1347209119; bh=ru+E3L1V1qFflkNGFiHvjocrmt0M2/U4v13hYmDxy08=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2GnmDigFxTmkQfHVKn6S1X4LVoxnkrNtKtbrKC2jA2er8ipBhq+VW2dvxI6p/VJDi r8+yF5vR92ZqTq2OqoNFNWCfmtMtZAkKw0SZkRY2hLPF3gO+HeLKIuksevukEgjQ4R cElE8QE0x5A23aBd1/Rg7hjamJ5oHkn/hMUhRVOY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1347209119; i=@resistor.net; bh=ru+E3L1V1qFflkNGFiHvjocrmt0M2/U4v13hYmDxy08=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3mayjRV/s/crqXVul0Q+WkXofuwuSanQEt5wSHugCqyCoFiaCZ4bQO98nT07o/Vkp dPVmMABtCac0Jp4nMI2yxZ40avgkBpcCI2vxfx0+zYU7PxE7nLSGzY7ZsEK/JeMh47 j2eWTTwU8nA7v2wzjWaSmdZT708xWeBG7gyJp1Mk= Message-Id: <6.2.5.6.2.20120909093926.0aacd530@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 09 Sep 2012 09:44:38 -0700 To: John C Klensin From: SM In-Reply-To: References: <20120906150526.5342.57611.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Barry Leiba , ima@ietf.org Subject: Re: [EAI] Last Call: (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 16:45:25 -0000 Hi John, At 09:15 09-09-2012, John C Klensin wrote: >My suggestion is to say something like the following: > > A great deal of Internet email procedures and software > assume that the addresses in "From:" and "Sender:" > fields can be replied to and are suitable for use in > mail organizing and filtering. The use of groups > instead of mailboxes may disrupt those uses. > Consequently, with this specification legitimizes the As an editorial nit about the last line quoted above: Although this specification legitimizes the Regards, -sm From ned+ima@mrochek.com Sun Sep 9 12:07:09 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644D521F856C for ; Sun, 9 Sep 2012 12:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTG6eM5Ke2qg for ; Sun, 9 Sep 2012 12:07:09 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id EFA0C21F8570 for ; Sun, 9 Sep 2012 12:07:08 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OK1UU5T7W0008WV7@mauve.mrochek.com> for ima@ietf.org; Sun, 9 Sep 2012 12:02:07 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sun, 9 Sep 2012 12:02:06 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OK1UU567QY0006TF@mauve.mrochek.com> Date: Sun, 09 Sep 2012 12:01:44 -0700 (PDT) In-reply-to: "Your message dated Sun, 09 Sep 2012 11:33:24 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120906150526.5342.57611.idtracker@ietfa.amsl.com> To: Barry Leiba Cc: ietf@ietf.org, ima@ietf.org Subject: Re: [EAI] Last Call: (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 19:07:09 -0000 > > The IESG has received a request from the Email Address > > Internationalization WG (eai) to consider the following document: > > - 'Post-delivery Message Downgrading for Internationalized Email > > Messages' > > as Proposed Standard > Rats; I missed this in earlier review: > -- Section 3.2.1 -- > This procedure may generate empty elements in "From:", > "Sender:" and "Reply-To:" header fields. > [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow (empty) > elements in "From:", "Sender:" and "Reply-To:" header fields. > It does not. It adds group syntax to "From" only. Group syntax is > already allowed in "Reply-To", and the draft does not change the rules > for "Sender". > If this spec also needs "Sender" to change, I can update the > 5322upd-from-group for that, but it's not there now. I think the answer to that is yes, this needs to be allowed for "Sender". Ned From ned+ima@mrochek.com Sun Sep 9 12:34:07 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF36621F855F for ; Sun, 9 Sep 2012 12:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vZQxqA+WiPr for ; Sun, 9 Sep 2012 12:34:05 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C3F9C21F8570 for ; Sun, 9 Sep 2012 12:34:05 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OK1VRL5M00008L2D@mauve.mrochek.com> for ima@ietf.org; Sun, 9 Sep 2012 12:29:05 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Sun, 9 Sep 2012 12:29:02 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OK1VRJUJMC0006TF@mauve.mrochek.com> Date: Sun, 09 Sep 2012 12:28:46 -0700 (PDT) In-reply-to: "Your message dated Sun, 09 Sep 2012 11:55:43 -0400" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120906150526.5342.57611.idtracker@ietfa.amsl.com> To: Barry Leiba Cc: ietf@ietf.org, ima@ietf.org Subject: Re: [EAI] Last Call: (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 19:34:08 -0000 > >> I think 5322upd-from-group needs to apply to both > >> backward-pointing address types to be effective for what > >> popimap-downgrade needs. > > > > I will make the change. > But in any case, the downgrade doc needs to remove "reply-to" from the > list of header fields that 5322upd-from-group changes. Maybe this: > OLD > This procedure may generate empty elements in > "From:", "Sender:" and "Reply-To:" header fields. > [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow > (empty) elements in "From:", "Sender:" and > "Reply-To:" header fields. > NEW > This procedure may generate empty elements in > "From:", "Sender:" and "Reply-To:" header fields. > [I-D.leiba-5322upd-from-group] updates [RFC5322] to allow > (empty) elements in "From:" and "Sender:". Looks like the correct change to me. Ned From barryleiba@gmail.com Sun Sep 9 14:01:24 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01DA21F8469; Sun, 9 Sep 2012 14:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.938 X-Spam-Level: X-Spam-Status: No, score=-102.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpVdIbTQGmxt; Sun, 9 Sep 2012 14:01:24 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D045121F8564; Sun, 9 Sep 2012 14:01:23 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so490834vcb.31 for ; Sun, 09 Sep 2012 14:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Wf5mMcqTls0FNXTVz1JDnaUU6U1RquzQAiQ+9ZYTzxM=; b=VsDjZqeUBUpebTVEENZEpkETW+wUy0RZMcW17LGRK4en/G7my3ZwcKbRlISQ+jZgxj iFyo60ZDw81ev0QQRKplLnGO4UyGyimuLpqVS/VpT9chZ7dzmkIHXTqQtNNub5x/vAgj Dfrj6En5+v61L/iPYuFxZvbKThVwcKMnsfDitNmwt3MiRpKP+wmC7SNOWMVxW93gkmpu inyCnuHvDUIBuM2N3k/6qTSb+accJzq8EtZJAMb45d9OXFi+ZVf6yRufstU9PegnSXZ5 J+kjqjCbhGeztgUUngo9X/UQKe2uondTEHqV7RxmqnaAh+V77owallLcnMk3c+dgqLCc 6exg== MIME-Version: 1.0 Received: by 10.220.149.6 with SMTP id r6mr16244321vcv.53.1347224483301; Sun, 09 Sep 2012 14:01:23 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.58.41 with HTTP; Sun, 9 Sep 2012 14:01:23 -0700 (PDT) In-Reply-To: References: <20120906150526.5342.57611.idtracker@ietfa.amsl.com> Date: Sun, 9 Sep 2012 17:01:23 -0400 X-Google-Sender-Auth: 2FWNwv5_NBoMGRfgyTNfwXFD6bY Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: ietf@ietf.org, ima@ietf.org Subject: Re: [EAI] Last Call: (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 21:01:25 -0000 >> I will make the change. I'll also remind the EAI group that >> there have been a couple of objections to the >> 5322upd-from-group spec, which I have to address. I might do >> that by scoping it down a bit with some "SHOULD NOT use" sort >> of language to address those concerns. Have to review them >> and see. > > My suggestion is to say something like the following: ... > That could be either in Security Considerations or a separate > section. You could even do something radical and incorporate it > as a section called "Applicability" and use the words "LIMITED > USE" (and, since no one seems to remember, a citation of RFC > 2026 Section 3.3). I have just posted drft-leiba-5322upd-from-group-04: http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group/ That changes the definition of Sender as well as From, and also adds a new "Applicability Statement" section that has an edited version of John's suggested text. I like the result, and I hope others do as well. I will post something to the 5322upd-from-group thread, asking that those who had objected look at the new text and see if they're happy (or at least somewhat happier) with it. Barry From johnl@iecc.com Sun Sep 9 14:04:23 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E4521F858F for ; Sun, 9 Sep 2012 14:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ahyph7RfjMre for ; Sun, 9 Sep 2012 14:04:22 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 75F3121F8564 for ; Sun, 9 Sep 2012 14:04:22 -0700 (PDT) Received: (qmail 22128 invoked from network); 9 Sep 2012 21:04:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Sep 2012 21:04:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=504d0455.xn--i8sz2z.k1208; i=johnl@user.iecc.com; bh=jTujyx9Cxl3PQgq9jj2iFx8X31HlOrMDIQ2ixE+wL8E=; b=SxXtnV9P+fzvHmF1KXMRv4PjLA0TZ2y3Uz+G60c+/x4RdeW/12WPJa9nOFGWfMNNMTY0EMYbEXljChu1VdIbls/SfCu2KlWo1dCDLflXwMs/GlezCBhvS6IsMZHYo150IjclWj8lO6FTWfDnMfY6SOtjjyrDyDWPxGNix8AnPdg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=504d0455.xn--i8sz2z.k1208; olt=johnl@user.iecc.com; bh=jTujyx9Cxl3PQgq9jj2iFx8X31HlOrMDIQ2ixE+wL8E=; b=m3qXL0jXRl0fIrtgd0VLCBibhh7ojL7KQujCgBOnjgpMtMWi9+//0swUbmybrFnq3JpmShbAPkTNe1ZRpjJvQGRk2Fxv65zBB90fhVkA5/ljf5EQUhsi/8b0N4sx+fr3v3JqptXiZh1S5ak3c/FLwx9rNbvYspvg2nMy1Ew2GqU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 9 Sep 2012 21:03:59 -0000 Message-ID: <20120909210359.36958.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] group from and DMARC, was Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 21:04:23 -0000 >Like it is easy to upgrade away from IE6? Still 0.6% of users are using >it, and it was still at 2% a year ago. I think those numbers confirm that it is indeed easy to upgrade away from IE6, since over 99% have done so. People still using it have some other issue. I really don't understand your problem with DMARC and empty From: headers. DMARC is not the FUSSP, and there will always be mail to which it is not applicable. Given that it doesn't even attempt to deal with slightly misspelled domain names (paypai.com, or your friends at security@banqofamerika.com), it's hard to see what new problems an empty From: header would introduce. As other people have noted, we expect little or no use except in mail downgraded during a POP or IMAP fetch, and in those cases DMARC would have done whatever it does long before the downgrade happened. R's, John From prvs=592801385=fmartin@linkedin.com Sun Sep 9 14:29:40 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01BB21F85F0 for ; Sun, 9 Sep 2012 14:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rL-UmsQDbJhP for ; Sun, 9 Sep 2012 14:29:40 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3D821F85AF for ; Sun, 9 Sep 2012 14:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1347226180; x=1378762180; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SKAmthO66RJesQ3xQt83G2cpDAmYUqqXG6dwAcZ1+p8=; b=M61jNZnqJqxFIv3t0l99yrA3o3TZBuKbV+/P+vmnIgNg/Nb/daFGhvcT 20qHNe61OQsfmNHsJfBFaTTGSdHoXkMB1rDZWAU3WDt6+IQYwVsCkm02q pBRjqeVuVdsXhQmWa5CaAhNYXxu1K0BANrBBRV1m0nfWBd0qMzHFSk46k Y=; X-IronPort-AV: E=Sophos;i="4.80,126,1344236400"; d="scan'208";a="25018836" Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.01.0355.002; Sun, 9 Sep 2012 14:29:09 -0700 From: Franck Martin To: John Levine Thread-Topic: [EAI] group from and DMARC, was Last Calls issued Thread-Index: AQHNjs6j5KgjEQAHb0ut+7m5ulL85peChq49 Date: Sun, 9 Sep 2012 21:29:09 +0000 Message-ID: <13093D13-6497-4550-8E9A-CA6C86FB9B63@linkedin.com> References: , <20120909210359.36958.qmail@joyce.lan> In-Reply-To: <20120909210359.36958.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] group from and DMARC, was Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 21:29:40 -0000 The game is to close the hole not making it bigger because there is already= a hole. Secondly, I wish people in this group aware of DMARC would have po= inted the DMARC group to this upcoming standard. This would have avoided la= te minute disruptive discussions. It is was me, the spec for from: would be to contain one and one only mailb= ox. I have not yet encountered some uses of the mailbox list syntax, if it is n= ot for buggy MTAs when doing out of band bounces. I would classify the mailbox-list syntax as deprecated, but I understand IE= TF prefers in general to extend than restrict. As for banqofamerica.com its reputation is different from bankofamerica.com= and that would be sufficient for emails not reaching the mailbox if needed= . Secondly the end user can read the difference, with an empty from this is= not possible anymore. Printed on recycled paper! On 09/09/2012, at 14:04, "John Levine" wrote: >> Like it is easy to upgrade away from IE6? Still 0.6% of users are using >> it, and it was still at 2% a year ago. >=20 > I think those numbers confirm that it is indeed easy to upgrade away > from IE6, since over 99% have done so. People still using it have > some other issue. >=20 > I really don't understand your problem with DMARC and empty From: > headers. DMARC is not the FUSSP, and there will always be mail to > which it is not applicable. Given that it doesn't even attempt to > deal with slightly misspelled domain names (paypai.com, or your > friends at security@banqofamerika.com), it's hard to see what new > problems an empty From: header would introduce. >=20 > As other people have noted, we expect little or no use except in mail > downgraded during a POP or IMAP fetch, and in those cases DMARC would > have done whatever it does long before the downgrade happened. >=20 > R's, > John From prvs=592801385=fmartin@linkedin.com Sun Sep 9 14:59:13 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDE321F84D2; Sun, 9 Sep 2012 14:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vO4Dxc-LQTzM; Sun, 9 Sep 2012 14:59:12 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id D355D21F845C; Sun, 9 Sep 2012 14:59:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1347227952; x=1378763952; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9EWQ7A06WuM3yWjHlKBWUBM4bkkw7egNbbZvH2D7ob0=; b=BTqv1m60rEczamYkNw5ax7E3yc3VKbzGQ182ZAiTBVHA+7/wDGhIDGC/ mjSRHiK4wdsV/8KODVqmke+YjJ+fXe1Wx+oXkz7i9tjxZcEhNpGUI86o7 SF6D65IWV9StX/vEWQSrC7W8AA8V6/miBPdkPBOleWN+DZVuYPcmb8bZv w=; X-IronPort-AV: E=Sophos;i="4.80,126,1344236400"; d="scan'208";a="25019393" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 9 Sep 2012 14:58:48 -0700 Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.01.0218.012; Sun, 9 Sep 2012 14:58:48 -0700 From: Franck Martin To: Barry Leiba , John C Klensin Thread-Topic: [EAI] Last Call: (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard Thread-Index: AQHNjs5ELWePH7UMy0mnra8dO5E1tZeCjw8A Date: Sun, 9 Sep 2012 21:58:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="us-ascii" Content-ID: <7EFF82ACB4DAAC49BB2CF1E906024AE6@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" , "ima@ietf.org" Subject: Re: [EAI] Last Call: (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 21:59:13 -0000 I'm happier, Made comments in another thread on why I believe it opens a security hole wider rather than trying to close it. I guess I could leave with it, when this downgrade is only done from a SMTPUTF8 compatible MTA to an ASCII MTA. I mean a SMTPUTF8 MTA MUST reject such downgrade. Let's not try to legitimize an attack vector (Friendly from having nothing to do with the author of the email). On 9/9/12 2:01 PM, "Barry Leiba" wrote: >>> I will make the change. I'll also remind the EAI group that >>> there have been a couple of objections to the >>> 5322upd-from-group spec, which I have to address. I might do >>> that by scoping it down a bit with some "SHOULD NOT use" sort >>> of language to address those concerns. Have to review them >>> and see. >> >> My suggestion is to say something like the following: >... >> That could be either in Security Considerations or a separate >> section. You could even do something radical and incorporate it >> as a section called "Applicability" and use the words "LIMITED >> USE" (and, since no one seems to remember, a citation of RFC >> 2026 Section 3.3). > >I have just posted drft-leiba-5322upd-from-group-04: > http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group/ > >That changes the definition of Sender as well as From, and also adds a >new "Applicability Statement" section that has an edited version of >John's suggested text. I like the result, and I hope others do as >well. I will post something to the 5322upd-from-group thread, asking >that those who had objected look at the new text and see if they're >happy (or at least somewhat happier) with it. > >Barry >_______________________________________________ >IMA mailing list >IMA@ietf.org >https://www.ietf.org/mailman/listinfo/ima From klensin@jck.com Sun Sep 9 15:12:21 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5680621F855B for ; Sun, 9 Sep 2012 15:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNtKiXsAfwKO for ; Sun, 9 Sep 2012 15:12:20 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0CD21F8539 for ; Sun, 9 Sep 2012 15:12:20 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TApjk-000CyI-Pd; Sun, 09 Sep 2012 18:12:16 -0400 X-Vipre-Scanned: 05E5EB8D002C3105E5ECDA-TDI Date: Sun, 09 Sep 2012 18:12:16 -0400 From: John C Klensin To: Franck Martin , John Levine Message-ID: <05623F7194F8707CD988AAA7@[192.168.1.128]> In-Reply-To: <13093D13-6497-4550-8E9A-CA6C86FB9B63@linkedin.com> References: , <20120909210359.36958.qmail@joyce.lan> <13093D13-6497-4550-8E9A-CA6C86FB9B63@linkedin.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 Cc: ima@ietf.org Subject: Re: [EAI] group from and DMARC, was Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 22:12:21 -0000 --On Sunday, September 09, 2012 21:29 +0000 Franck Martin wrote: > The game is to close the hole not making it bigger because > there is already a hole. Personal opinion only... I don't think anyone has suggested that. What I would suggest (others might disagree) is that filtering on the details of what appears in "From:" (banqofamerica.com notwithstanding) is a fairly weak approach. If nothing else, it seems to share the properties of several other techniques (DNSSEC itself included) that ultimately rely on the integrity and good behavior of domain name registrars in handling names. That isn't a particularly good assumption. That is not to suggest that it cannot be useful. For those who believe that the solution to Spam lies in destination- or near-destination filtering, anything that produces a noticeable decrement in the number of "bad" messages that are caught is probably worth investigating and maybe implementing. But unless such a technique (maybe in combination with others) really is the FUSSP, many of us are going to be very resistant to reducing email functionality in the hope of stopping a few more "bad" messages. > Secondly, I wish people in this group > aware of DMARC would have pointed the DMARC group to this > upcoming standard. This would have avoided late minute > disruptive discussions. But, if your comments are indicative of the position of the DMARC group, it merely would have resulted in the discussion appearing earlier. Several people have given you the reasons why the WG made the decisions that it did and explained the difficulties with your counterproposal (a variation of which was considered by the WG and was actually in an early draft of the spec). As far as I can tell, you haven't offered a single new refutation of counterargument to those decisions, so I don't believe the outcome would have been and different. > It is was me, the spec for from: would be to contain one and > one only mailbox. Now _that_ discussion occurred on, I think, the 822 list some months ago. The community was fairly strongly against a change for reasons that parallel my explanation earlier today. The discussion was certainly not "hidden" in the EAI WG. > I have not yet encountered some uses of the mailbox list > syntax, if it is not for buggy MTAs when doing out of band > bounces. I'd encourage you to search the archives, but From: Tom@example.com, Dick@example.com is actually a very useful construction. It may not be really common, but parallels the occasional need for two of more people to sign a paper letter. Remember, this isn't the envelope we are talking about. If you care more about the message sender than the originator(s), you should be looking at "Sender:" in the presence of "From:" information that is more complex than you would like. Of course, that won't help with the group issue, but they are really separate problems. If you want to use mail header fields as validators, your protocol really needs to understand and follow the mail specs, not try to reinvent them in a way that would be more convenient for you. > I would classify the mailbox-list syntax as deprecated, but I > understand IETF prefers in general to extend than restrict. I'd argue that has not been the case with email when reducing flexibility increases interoperability without significantly reducing functionality. You might find it helpful to review the rather extensive Section 4 of RFC 5322 to calibrate statements like the assertion you make above. > As for banqofamerica.com its reputation is different from > bankofamerica.com and that would be sufficient for emails not > reaching the mailbox if needed. Secondly the end user can read > the difference, with an empty from this is not possible > anymore. One can argue about differences in quality of heuristics, but any classification test based on the contents of a "From:" field is ultimately a heuristic that will work better in some cases than others. If you wanted to classify a message that uses group syntax in "From:" (or "Sender:") on the public Internet as at high risk of being garbage, I don't think anyone would fault that as a heuristic (although some people might get concerned if you started silently dropping messages on that basis). It would also be completely consistent with the "don't do that" language in Barry's revised text. So I'm unsure what you are still concerned about. If you want to explain further, please start that explanation with answers to the questions Ned Freed raised. best, john From prvs=592801385=fmartin@linkedin.com Sun Sep 9 15:37:59 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F9D21F85AF for ; Sun, 9 Sep 2012 15:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.364 X-Spam-Level: X-Spam-Status: No, score=-6.364 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, LONGWORDS=1.803, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYSrANCOrx4g for ; Sun, 9 Sep 2012 15:37:58 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1191121F849B for ; Sun, 9 Sep 2012 15:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1347230277; x=1378766277; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cSuLubUp2OWPXKzcOLdlh684tDcOzb17QUoAjyV/IKs=; b=4aBkuh2lIqxMm4NA+ernr3dAMNai5L0RTcLDjvZUnXSfBo4jHfRfUuOv lcLvwqthPngMvqUv8TcBsKz7FducnSB4P8H4i9WUOhz6JhRgV8QeYl4YQ 2CKC+HcihDyz5Uaig+aGIojGyiuygMC2BM4CBnzP8Td1JjG+Mmi6VrS5b 0=; X-IronPort-AV: E=Sophos;i="4.80,126,1344236400"; d="scan'208";a="25020159" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 9 Sep 2012 15:37:31 -0700 Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.01.0218.012; Sun, 9 Sep 2012 15:37:31 -0700 From: Franck Martin To: John C Klensin , John Levine Thread-Topic: [EAI] group from and DMARC, was Last Calls issued Thread-Index: AQHNjs6j5KgjEQAHb0ut+7m5ulL85peChq49gACBZAD//5HLgA== Date: Sun, 9 Sep 2012 22:37:30 +0000 Message-ID: In-Reply-To: <05623F7194F8707CD988AAA7@[192.168.1.128]> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ima@ietf.org" Subject: Re: [EAI] group from and DMARC, was Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 22:37:59 -0000 On 9/9/12 3:12 PM, "John C Klensin" wrote: > > >--On Sunday, September 09, 2012 21:29 +0000 Franck Martin > wrote: > >> The game is to close the hole not making it bigger because >> there is already a hole. > >Personal opinion only... > >I don't think anyone has suggested that. What I would suggest >(others might disagree) is that filtering on the details of what >appears in "From:" (banqofamerica.com notwithstanding) is a >fairly weak approach. If nothing else, it seems to share the >properties of several other techniques (DNSSEC itself included) >that ultimately rely on the integrity and good behavior of >domain name registrars in handling names. That isn't a >particularly good assumption. > >That is not to suggest that it cannot be useful. For those who >believe that the solution to Spam lies in destination- or >near-destination filtering, anything that produces a noticeable >decrement in the number of "bad" messages that are caught is >probably worth investigating and maybe implementing. But unless >such a technique (maybe in combination with others) really is >the FUSSP, many of us are going to be very resistant to reducing >email functionality in the hope of stopping a few more "bad" >messages. > >> Secondly, I wish people in this group >> aware of DMARC would have pointed the DMARC group to this >> upcoming standard. This would have avoided late minute >> disruptive discussions. > >But, if your comments are indicative of the position of the >DMARC group, it merely would have resulted in the discussion >appearing earlier. Several people have given you the reasons >why the WG made the decisions that it did and explained the >difficulties with your counterproposal (a variation of which was >considered by the WG and was actually in an early draft of the >spec). As far as I can tell, you haven't offered a single new >refutation of counterargument to those decisions, so I don't >believe the outcome would have been and different. > >> It is was me, the spec for from: would be to contain one and >> one only mailbox. > >Now _that_ discussion occurred on, I think, the 822 list some >months ago. The community was fairly strongly against a change >for reasons that parallel my explanation earlier today. The >discussion was certainly not "hidden" in the EAI WG. Never claimed it was hidden > >> I have not yet encountered some uses of the mailbox list >> syntax, if it is not for buggy MTAs when doing out of band >> bounces. > >I'd encourage you to search the archives, but > > From: Tom@example.com, Dick@example.com > >is actually a very useful construction. It may not be really >common, but parallels the occasional need for two of more people >to sign a paper letter. Remember, this isn't the envelope we >are talking about. If you care more about the message sender >than the originator(s), you should be looking at "Sender:" in >the presence of "From:" information that is more complex than >you would like. Of course, that won't help with the group >issue, but they are really separate problems. If you want to >use mail header fields as validators, your protocol really needs >to understand and follow the mail specs, not try to reinvent >them in a way that would be more convenient for you. It is indeed not common at all. It is nice to have the capability in theory but in practice, we may gain by not having it. To be noted this is my opinion and not the one of the DMARC group, as there is an obvious solution to the presence of several mailboxes in the From: Note, the group did consider to use the Sender: header but this was rejected. > >> I would classify the mailbox-list syntax as deprecated, but I >> understand IETF prefers in general to extend than restrict. > >I'd argue that has not been the case with email when reducing >flexibility increases interoperability without significantly >reducing functionality. You might find it helpful to review the >rather extensive Section 4 of RFC 5322 to calibrate statements >like the assertion you make above. I think moving From to as single mailbox reduce flexibility increases interoperability without significantly reducing practical functionality and increase security. >=20 >> As for banqofamerica.com its reputation is different from >> bankofamerica.com and that would be sufficient for emails not >> reaching the mailbox if needed. Secondly the end user can read >> the difference, with an empty from this is not possible >> anymore. > >One can argue about differences in quality of heuristics, but >any classification test based on the contents of a "From:" field >is ultimately a heuristic that will work better in some cases >than others. If you wanted to classify a message that uses >group syntax in "From:" (or "Sender:") on the public Internet as >at high risk of being garbage, I don't think anyone would fault >that as a heuristic (although some people might get concerned if >you started silently dropping messages on that basis). It would >also be completely consistent with the "don't do that" language >in Barry's revised text. > >So I'm unsure what you are still concerned about. If you want >to explain further, please start that explanation with answers >to the questions Ned Freed raised. You mean Barry? I'm just probing around to gain understanding. From john-ietf@jck.com Sun Sep 9 15:47:29 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EF721F8445; Sun, 9 Sep 2012 15:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHxNjNZktnvE; Sun, 9 Sep 2012 15:47:15 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 10E5021F85EA; Sun, 9 Sep 2012 15:47:07 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TAqHP-000D2X-Vp; Sun, 09 Sep 2012 18:47:04 -0400 X-Vipre-Scanned: 0605C4B0002C310605C5FD-TDI Date: Sun, 09 Sep 2012 18:47:03 -0400 From: John C Klensin To: Franck Martin , Barry Leiba Message-ID: <0893C01D4C3F0F63F04944D2@[192.168.1.128]> 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 Cc: ietf@ietf.org, ima@ietf.org Subject: Re: [EAI] Last Call: (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 22:47:29 -0000 --On Sunday, September 09, 2012 21:58 +0000 Franck Martin wrote: > I'm happier, > > Made comments in another thread on why I believe it opens a > security hole wider rather than trying to close it. > > I guess I could leave with it, when this downgrade is only > done from a SMTPUTF8 compatible MTA to an ASCII MTA. But, as several people have tried to remind you, the EAI specs are consistent with the prohibitions in RFC 5321, prohibitions that expressedly forbid MTAs from changing addresses enrounte (for downgrading or any other reason). The specs in Last Call now don't apply to MTAs or MTA actions _at all_. They apply _only_ to communication between an SMTPUTF8-compatible IMAP or POP server and a legacy IMAP or POP client. The experimental versions of the EAI specs did provide for in-transit downgrading. The main conclusion from those experiments (described in RFC 6530, which I'd still encourage you to read) was that such MTA->MTA downgrading was a bad idea. So the WG agrees with you, so do the specs, and you are attacking a (rather worn and threadbare) strawman. Please focus on where this actually occurs and what the specs actually say. And, again, you might start by responding to Ned's questions. > I mean a SMTPUTF8 MTA MUST reject such downgrade. With regard to whether it will tolerate group syntax in backward-pointing header fields, the decision has absolutely nothing to do with EAI and whether MTA is SMTPUTF8-capable or not. However, to get anything close to a "MUST reject", you'd need to propose a very radical change to the way email is specified. In theory and largely in practice, MTAs deal with envelopes, not header fields. RFC 5321 and its successors are carefully designed to never require that an MTA do anything with header fields other than prepending information to them. I think we all recognize that mail filtering and classification has created a lot of exceptions in which header fields (and content) are inspected prior to the final delivery server. Even that typically occurs close to either the submission or final delivery points. I think you would get a _lot_ of resistance to a change that would _require_ SMTP MTAs to inspect message bodies (including header fields) to see if they contained some offending construction. > Let's not try to legitimize an attack vector (Friendly from > having nothing to do with the author of the email). I've seen no evidence at all that this does any such thing. john From prvs=592801385=fmartin@linkedin.com Sun Sep 9 15:55:00 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E63021F849B for ; Sun, 9 Sep 2012 15:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O7iJ12gnwln for ; Sun, 9 Sep 2012 15:54:59 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id AA53D21F8566 for ; Sun, 9 Sep 2012 15:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1347231299; x=1378767299; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+7Mw8toHJrVhVO1OT9bhSW6jThZ+yQUPsDnW6mwl+iM=; b=fF7aWZlOKWaWruMMKfh851p9pc4agW23zEqsfD55BzxZ9oqQHnj/tyXN +oQFq1D/YHvsB03FwIrRGSMkgWzihIhtVJcyW2fxJp4QdhF86xdswwumo XJHqMxAqphNQaEj7M5yXeGGELx/3lA7BfwZbArqLXPTLd+7J3vsCcSCJc I=; X-IronPort-AV: E=Sophos;i="4.80,126,1344236400"; d="scan'208";a="25020514" Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.01.0355.002; Sun, 9 Sep 2012 15:54:35 -0700 From: Franck Martin To: Barry Leiba Thread-Topic: [EAI] Last Calls issued Thread-Index: AQHNjETJ2J9GX953VEex5ZXaw4cUiJd+fmSA///zAoCAACutAP///lEAgABGfICAAIIyAP//5mYAAASTkgAAZYPsAAABD/KA Date: Sun, 9 Sep 2012 22:54:35 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: text/plain; charset="us-ascii" Content-ID: <33FB4983EDDF2E4D951C88B361E07DE3@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Arnt Gulbrandsen , "ima@ietf.org" Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 22:55:00 -0000 On 9/9/12 8:24 AM, "Barry Leiba" wrote: >>>(ii) Upgrade the client to accept and process some new and funky >>>syntax (or specialized new header fields) to as to preserve some >>>of the information in internationalized mail but not to actually >>>accept internationalized mail. >> >> I'm not talking of some funky syntax here. Not sure why you focus on >>that. >> A reserved local string is not funky syntax. > >It's a Very Big Deal to reserve a local-part, and I would agree to do >it only in extreme circumstances. This isn't one. What's more, this >doesn't even *approach* any criteria I might use to agree to do that, >because this is a transitional case in a *very* limited situation. > >Further, the overarching point here is to make sure that whatever is >in the From *cannot* be a valid address that can ever be replied to. >That means that it *cannot* be a valid address *currently*... that it >will be something that existing non-EAI-compliant M*As will allow use >of in replies. Any reserved name will be allowed in replies by any >M*A that is not updated to conform to this, and that could cause >someone to intercept replies by registering whatever local-part we try >to reserve, hoping that he will snag confidential replies that way. > >We absolutely can't allow that. > >--- >John has reminded you of this, but let me highlight it and ask some >specific questions: > >- These protocols suggest using group syntax in From *only* in the >specific situation where an EAI-compliant IMAP or POP server is giving >the message to a non-EAI-compliant IMAP or POP client, in response to >that client's asking for it. > >- Protocols such as ADSP and DMARC will mostly be used *upstream* of >that path, at or before the message reaches the MDA. > >- The use of the group syntax is *only* to allow the non-EAI-compliant >IMAP or POP client to see some semblance of the message, rather than >being told that the message is unavailable to it. > >- The translation of the non-ASCII From address into group syntax will >preserve the address, in 2047-encoded form, as the "name" of the >group, so an MUA can still display it. > >Here are my questions, Franck: > >- To what extent do you think DMARC (or ADSP) will be applied *in >clients* (MUAs)? I think the ultimate goal is to display in the MUA the domain vouching for the email. Some does already with DKIM. A domain that is protected by DMARC or ADSP could have a higher confidence. As you know, we are not UI designers and we can only recommend what the MUA should do, or use what the MUAs already do (display the email address of the From: header). > >- To what extent do you think there will be situations where DMARC >will cause the message to be flagged such that the MUA warns the user >herself to look carefully at the "from" domain? DMARC should reject the email at the injection, so this is not the way it would work. The user should be suspicious of an email because it looks like a know mailer but the domain is not the one commonly used by the mailer. I think this kind of capability may take time to do in software, but is better in wetware. =20 > >- In those situations, do you think my last point above will not >suffice, that the user will not be able to look at the 2047-decoded >group name? The Friendly From is certainly an issue. Consider the sending of such email: From: "Paypal " > >- Do you think, given that these specs are coming out *before* DMARC, >that it's unreasonable to expect (or for DMARC to require) that >clients that are updated to conform to it also implement EAI? It means that DMARC MUST be installed on an MTA that does SMTPUTF8? Even so there is still an issue, I think: SMTPUTF8MTA1----downgrade---USASCIIMTA---SMTPUTF8MTA2. This email should be transmitted but it allows the injection of anything to SMTPUTF8MTA2 by design despite increased warning in the specs. From klensin@jck.com Sun Sep 9 16:11:05 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0446D21F8599 for ; Sun, 9 Sep 2012 16:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n297HEDDDWYX for ; Sun, 9 Sep 2012 16:11:04 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 36FB721F8593 for ; Sun, 9 Sep 2012 16:11:04 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TAqeZ-000D4o-DO; Sun, 09 Sep 2012 19:10:59 -0400 X-Vipre-Scanned: 061BABDD002C31061BAD2A-TDI Date: Sun, 09 Sep 2012 19:10:59 -0400 From: John C Klensin To: Franck Martin , Barry Leiba Message-ID: <62A6356109AFBD2886586A5F@[192.168.1.128]> 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 Cc: Arnt Gulbrandsen , ima@ietf.org Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2012 23:11:05 -0000 --On Sunday, September 09, 2012 22:54 +0000 Franck Martin wrote: >... > Even so there is still an issue, I think: > > SMTPUTF8MTA1----downgrade---USASCIIMTA---SMTPUTF8MTA2. > > This email should be transmitted but it allows the injection > of anything to SMTPUTF8MTA2 by design despite increased > warning in the specs. This is a non-case, as I and others have explained several times. The USASCIIMTA will not advertise SMTPUTF8 (because it has never heard of it and certainly doesn't support it or it would be an SMTPUTF8-MTA). Assuming that the message actually requires SMTPUTF8 capability, SMTPUTF8MTA1 _MUST_ reject the message at that point (or do whatever it does in lieu of rejection). That is an envelope issue and fundamental to the SMTP extension model. The message will _never_ reach USASCIIMTA, and (obviously, I hope) it won't reach SMTPUTF8MTA2 _in any form_ unless whatever sent the message to SMTPUTF8MTA1 generates a new (and different), ASCII-only/ 5321-conforming, message and sends it. If you don't believe this is explained adequately in RFCs 5630 and 5631, I'd personally welcome suggestions for improvement (and I'm confident that Yangwoo and Jiankang would too). But it is just not an issue for the IMAP/POP specs that are now in Last Call... and it has absolutely nothing to do with Group syntax. john From johnl@taugh.com Sun Sep 9 17:31:37 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A77B21F85C3 for ; Sun, 9 Sep 2012 17:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykurRufbd9Ds for ; Sun, 9 Sep 2012 17:31:36 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 73B9C21F85A7 for ; Sun, 9 Sep 2012 17:31:35 -0700 (PDT) Received: (qmail 57738 invoked from network); 10 Sep 2012 00:31:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=e189.504d34e3.k1209; bh=mD2AusrIH7iimZLOBawYJLV5GWEocf7jdhrlluARadU=; b=Xl5EQ77Hg3jSekB6ODsJ1yp1Mxm56G2nIneswbDfYe4eLr0sPU5XQjblIZXSYvWUE2ADvPiNJEGBPSzeNBbHmy6mkrZJPyTHnKzZk9fScRznOWP4VpPQyvX2TT8NQozZaxW00pLjWHmkLReZ1hAhnxHWC9oxTEam3xK01vZ1qlM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=e189.504d34e3.k1209; bh=mD2AusrIH7iimZLOBawYJLV5GWEocf7jdhrlluARadU=; b=if/RrgE517fcZIdzu1AShxJbQoOG1LuxtsMDm3QDOgEgkO+GIGio5Ee1u1xelOpJWoEz24uiyJ5d+pqJfvKH9hR9dpf6Q2cprGjxjX2WpRNlncvA8km5yTfjdFeH+T4EPi/Hq3yiDTECvF/Z2pxm3P/XPKHwz0xAFpg/R0V+lac= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 10 Sep 2012 00:31:08 -0000 Date: 9 Sep 2012 20:31:30 -0400 Message-ID: From: "John R Levine" To: "Franck Martin" In-Reply-To: <13093D13-6497-4550-8E9A-CA6C86FB9B63@linkedin.com> References: , <20120909210359.36958.qmail@joyce.lan> <13093D13-6497-4550-8E9A-CA6C86FB9B63@linkedin.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1942262186-1347237091=:41528" Cc: "ima@ietf.org" Subject: Re: [EAI] group from and DMARC, was Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 00:31:37 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-1942262186-1347237091=:41528 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > The game is to close the hole not making it bigger because there is > already a hole. Secondly, I wish people in this group aware of DMARC > would have pointed the DMARC group to this upcoming standard. This would > have avoided late minute disruptive discussions. The reason I didn't mention this to DMARC is that it is completely irrelevant. No matter how much you want DMARC to be a FUSSP, it is not one, it cannot be one, and there is no chance whatsoever to make all mail do what DMARC wants, any more than we can make it do what SPF or DKIM wants. Perhaps after you've fixed the lookalike domain "hole", come back and tell us how you did it, and we'll think about it. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1942262186-1347237091=:41528 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIIBgYJKoZIhvcNAQcCoIIH9zCCB/MCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBSMwggUfMIIEB6ADAgECAhBqmDwY4viwyBNv7hg7djRHMA0G CSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDgyNzAwMDAwMFoX DTEyMDgyNjIzNTk1OVowIDEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2gu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArjjY2CfvJ3My a2g1aOrImd0uJVLaah8aKJ8PSJJZth2vTQsMq3ozNxcZWKKRROOUfMeJWQDa xl0J7d0XCdVjK40s+ZWKvlqwxLHCyIn4Enzk8lkoMq2qQUqnGaGbNQBxQK11 4JINMKOLMkP1WZgOwfDcROBhlKnK7FgNFgXouNS0nFUzosqlKOfYW6Ryl5rV cLInOqGv78O/ekb9YtzHMVlrF9sKC5D8ijis0RY5uvdb47YCoKvI/Pm5g2wK EYeD+sJXhSUp3zPct5VLDG1jrN2zjQEVrSFDQ/Ny58EnaNkOSMdE1tRQ7/Nf ckoMGXqJRedbx7d/H62kGaDb7QrAawIDAQABo4IB3zCCAdswHwYDVR0jBBgw FoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFFNpWjhcj0fXS96W ENsvzag4QY9yMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1Ud JQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMC BSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqg SIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6 MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9D bGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wGgYDVR0RBBMwEYEP am9obmxAdGF1Z2guY29tMA0GCSqGSIb3DQEBBQUAA4IBAQB1BxfCpqDbjmN/ bGxym680l1in8LQqE0Vr/zbbz9lcDIPDdaQRDxtRkEf5KdlSrfLk23R0Ri9x UQanAmVsFpboEhR/rmSdECdkImgAHd+ruZwNpbwX5+U8T0yaU0/Y/Xm+Rdfa KuEJTVFsO9S6KsKkgTyDoeMoCRIER6ChQyRE51QCyREk9xt6aw03Vj42mZBq v4mYNVpqzFLs9JLCotV7C9oViKip1UzYj3khybTrC0wn8Q+c99qr03YCpdD5 G+fotgtPEBomtRW4UnUBmZ3foBBah5mTSwPkaBC6p1yN+2qEy075c5tzT/EH xs7UzXgqn87a8S6cROUqPtykd+NGMYICqzCCAqcCAQEwgagwgZMxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQD EzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGqYPBji+LDIE2/uGDt2NEcwCQYFKw4DAhoFAKCB2DAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA5MTAwMDMx MzBaMCMGCSqGSIb3DQEJBDEWBBRGXW7x/lLZlcNyQYteD9ud1kSnkDB5Bgkq hkiG9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASC AQA290C66a3840XIUWr64GeT1I0GbyoALkyYQyA4VGnLOZylug4WYuYD3P3I cJbLahnQ2xNDVJjEb9vlHOyqDMziDEpovLqHIUylfAjiFFR5WdvH/mQxMal6 klxMWqxJy3uxYoMNELilBBfQSWzoB1/ZNtUR/TER3TXwCFl07iU30OrBrlHV gHO2Db3nZR3TJ7G+qEBR5S0C1AqeqEd55ge4NSnnG/yS4Mk51wRYKBk9Ge4k +vgkTCzwzh6epeyfDGN+5PgN6LLB0Q1GTf44NQ4oyvi/41OB+3OupoC0UGLV du028FhDo8Flu8cViAyiP2KDrC3Zq8rwakJYYO3D0fX7 --3825401791-1942262186-1347237091=:41528-- From barryleiba@gmail.com Sun Sep 9 17:43:26 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED8321F84FA for ; Sun, 9 Sep 2012 17:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYU5VH+UUyqM for ; Sun, 9 Sep 2012 17:43:25 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92AC121F84F3 for ; Sun, 9 Sep 2012 17:43:25 -0700 (PDT) Received: by vbal1 with SMTP id l1so2156790vba.31 for ; Sun, 09 Sep 2012 17:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jQZHhnjoN+Imdm2kh+gDuvH+L0V7oORUs0QfgJs9nmA=; b=q7xZG9W1/lmMmd8VejeXOEi7sUWlFVPvDCpkZs4cUkWb+BoNI/q8jCPZhTVTMqTVkj sNuYHo0ZfuHjXpEIhucu5RWG0OJ2qmzHDqHX0lsukQIe5UfGy2VfWzJwzD5X4FFS09zI PyPS7M4A7SwuLxgKAvWYdZYh4FI6DBfDzdOculXMPxepgDqt3LpJjb+JCAwQGYNVJ6XI jTl0RW9bL3R9UlASQ7FvcDtjrYzu/QQ1ULrTd0kjocooqY6TRcXsPT5hXTfIFzL/qNcV XoFAQdroKTO9ynKK67iK5tO8gd5lfzm7ejyErKEcFhVUQx9CG/4TUI2ItxH8TrNQ3pRr 141A== MIME-Version: 1.0 Received: by 10.220.152.67 with SMTP id f3mr17339006vcw.19.1347237805083; Sun, 09 Sep 2012 17:43:25 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.58.41 with HTTP; Sun, 9 Sep 2012 17:43:24 -0700 (PDT) In-Reply-To: References: Date: Sun, 9 Sep 2012 20:43:24 -0400 X-Google-Sender-Auth: WF-DzhpM_DpxWgDaTF7jIkEP73Q Message-ID: From: Barry Leiba To: Franck Martin Content-Type: text/plain; charset=ISO-8859-1 Cc: Arnt Gulbrandsen , "ima@ietf.org" Subject: Re: [EAI] Last Calls issued X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 00:43:26 -0000 > I think the ultimate goal is to display in the MUA the domain vouching for > the email. Some does already with DKIM. A domain that is protected by > DMARC or ADSP could have a higher confidence. ... > DMARC should reject the email at the injection, so this is not the way it > would work. The user should be suspicious of an email because it looks > like a know mailer but the domain is not the one commonly used by the > mailer. I think this kind of capability may take time to do in software, > but is better in wetware. In other words, this really has nothing to do with DMARC. You're concerned that users should be shown the purported From domain, and that in this one, specific, limited "downgrade" scenario they won't be. And I'm saying that you seem to understand neither the downgrade situation nor the mechanism. See below. > The Friendly From is certainly an issue. > > Consider the sending of such email: > From: "Paypal " In that case, the downgraded result will show "Paypal" in the "friendly" text and "UT8@UTF8" in the group name. In clients that will show both, the user will still see both (but won't be able to reply to it). In clients that will only show the friendly name, "Paypal" is all that will appear in any case. So the "downgrade" situation is still showing the desired information to the user (modulo things like font support, of course). The whole point of the "downgrade" is to try to provide as much of the original information as possible to the user agent, without giving the user agent stuff it can't handle (such as UTF8 in the local-part). >>- Do you think, given that these specs are coming out *before* DMARC, >>that it's unreasonable to expect (or for DMARC to require) that >>clients that are updated to conform to it also implement EAI? > > It means that DMARC MUST be installed on an MTA that does SMTPUTF8? No; I said "clients", because I'd understood your complaint to have to do with DMARC in clients. Because it doesn't, then this question and its answer don't apply. > Even so there is still an issue, I think: > > SMTPUTF8MTA1----downgrade---USASCIIMTA---SMTPUTF8MTA2. > > This email should be transmitted but it allows the injection of anything > to SMTPUTF8MTA2 by design despite increased warning in the specs. This is why I say you don't understand the downgrade scenario. What you show above is not valid. The Experimental specs included an experimental downgrade stage as you show above. The experiment failed -- it was determined to be unworkable -- and it is not in the Standards Track specs. As John says, the step that says "downgrade" in your chain above will now be "bounce", and the message will go no farther. Please read *all* of the Standards-Track versions of the EAI specs and understand how it works. Start with the Framework doc, RFC 6530, which will explain the system as a whole. Barry From johnl@iecc.com Sun Sep 9 17:53:55 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC80B21F8605 for ; Sun, 9 Sep 2012 17:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsBYpFWLJ++Z for ; Sun, 9 Sep 2012 17:53:55 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E7AFF21F8602 for ; Sun, 9 Sep 2012 17:53:54 -0700 (PDT) Received: (qmail 60913 invoked from network); 10 Sep 2012 00:53:54 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Sep 2012 00:53:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=504d3a22.xn--3zv.k1208; i=johnl@user.iecc.com; bh=2VAStBWLaup+jaAHDDOLEP/DfZO5i29mNF0LUxBSbXo=; b=MYHXjyPmA2DcAFfa3nl78rv02ynHH1BCM81mZizhusOGk04t/EN0d+FmoMG8Wfny/ANfyxOYaeDWlDxLb2rJgV8abt1HnlgROc1mif263xbUnXaJ154kLXqtGAsL+qA+g40Ek39LG+cdEkSVy4PTv1TXgPEIVs1Khc+inVMYZBw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=504d3a22.xn--3zv.k1208; olt=johnl@user.iecc.com; bh=2VAStBWLaup+jaAHDDOLEP/DfZO5i29mNF0LUxBSbXo=; b=jZ2O5cXcqkFvTThJQMelxlW0THTIspGOBmjT7dB8N3SmXMKOBPRXTxJckOrE68WCgsANkyLvDfLH390OCOjLKjCFsJihg0rPKi2Ore8Dv1VJspFAxd5yy/HHsqAZkKJiadK7ssRRUC+YwJpTk6sVwNiwxYx3nsX4NQmjdncDhsY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 10 Sep 2012 00:53:32 -0000 Message-ID: <20120910005332.44341.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [EAI] Last Call: (Post-delivery Message Downgrading for Internationalized Email Messages) to Proposed Standard X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 00:53:55 -0000 >I guess I could leave with it, when this downgrade is only done from a >SMTPUTF8 compatible MTA to an ASCII MTA. An SMTPUTF8 compatible MTA will never, ever, send mail to an ASCII MTA that has addresses that need to be downgraded. Perhaps this would be a good time to reread the existing EAI RFCs to be sure you understand the framework within which this is all going on. R's, John From alexey.melnikov@isode.com Mon Sep 10 02:49:58 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F7E21F8620 for ; Mon, 10 Sep 2012 02:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.32 X-Spam-Level: X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71s6yt7Q7IDy for ; Mon, 10 Sep 2012 02:49:57 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5614321F8621 for ; Mon, 10 Sep 2012 02:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1347270595; d=isode.com; s=selector; i=@isode.com; bh=PmpcWvB3br7f7KOlf+QsOzqhQNhTuRnrWfeWZlRn24I=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=fC3a4LdnLc0O2KF1hq9V66dqQHYyNe6L5JYozO1qFUZTRsBbTompU204zWN80PabNMzJ6m aQaapUKjploBJfwROpu2wY60YDWYOUEluXjNh9Y3YLENyfVQwCeVZS6BzgRoAWYtMQbro/ 4+1M6jNCAbAqBPMjoQp9jh+ZNHcQZ3k=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 10 Sep 2012 10:49:53 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <504DB7CD.7060404@isode.com> Date: Mon, 10 Sep 2012 10:50:05 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: John C Klensin , Arnt Gulbrandsen References: <504A098B.5080607@gulbrandsen.priv.no> <5E028D1956183BC5539C34E0@JcK-HP8200.jck.com> In-Reply-To: <5E028D1956183BC5539C34E0@JcK-HP8200.jck.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] simpledowngrade terminology X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 09:49:58 -0000 On 07/09/2012 16:43, John C Klensin wrote: > --On Friday, September 07, 2012 16:49 +0200 Arnt Gulbrandsen > wrote: > >> On 09/07/2012 02:46 PM, John C Klensin wrote: >>> The POP-IMAP "downgrade" mechanisms are really members of the >>> family of (iii) -- they don't deliver the message, they >>> deliver a surrogate that helps the user understand that some >>> things are inaccessible until the client is downgraded (or >>> they access the message through some other client, etc.). >> Surrogate message. That's the right term. >> >> If I had thought of that, that's what I would have written. Is >> it still worth changing, and does anyone else agree that >> surrogate is a better word than synthetic? >> >> (Yes, the message is both synthetic and a surrogate. But I >> feel that surrogate goes to the heart of the thing.) > First, let's see if others agree (or at least don't object). "Surrogate" is Ok with me. It seems slightly better than "synthetic", but I have no strong opinions either way. > If > they do and Pete is ok with this, let's handle this (and any > other comments from within the WG) as a small variation on the > normal Last Call process: Joseph or I will send a note to the > IESG around the 19th or 20th summarizing any changes the WG > concluded it ought to make. > > For planning purposes, I don't want to see new drafts before the > 21st because they would just confuse people about what Last Call > comments are based on. But I hope to have new drafts of any > documents we decide should be modified (I know that > popimap-downgrade is already on the list and your note probably > adds simple downgrade) can be posted right after that so the > actual IESG review and vote can occur on cleaned-up documents > that reflect any Last Call comments with which we agree. > > Ok? > john > From tss@iki.fi Tue Sep 11 05:48:45 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC9921F87ED for ; Tue, 11 Sep 2012 05:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.855 X-Spam-Level: X-Spam-Status: No, score=-109.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDuX7Cw4o+QS for ; Tue, 11 Sep 2012 05:48:45 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4F65521F87E8 for ; Tue, 11 Sep 2012 05:48:45 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 87AFB1AE87C4 for ; Tue, 11 Sep 2012 15:48:44 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen Resent-From: Timo Sirainen Date: Tue, 11 Sep 2012 15:47:53 +0300 Content-Transfer-Encoding: quoted-printable Resent-Date: Tue, 11 Sep 2012 15:48:43 +0300 Resent-To: ima@ietf.org Message-Id: To: ima-request@ietf.org X-Mailer: Apple Mail (2.1084) Resent-Message-Id: <20120911124844.87AFB1AE87C4@dovecot.org> Subject: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 12:48:46 -0000 > IMAP servers that advertise support for "UTF8=3DACCEPT" or = "UTF8=3DONLY" > MUST reject an APPEND command that includes any 8-bit in the message > headers with a "NO" response, when IMAP clients do not issue "ENABLE > UTF8=3DACCEPT" or "ENABLE UTF8=3DONLY". This requires changing behavior of servers' existing behavior when it = encounters such data. Yes, such messages shouldn't exist, but they do. I = have tens of messages from Hotmail with 8bit subject headers in my = INBOX. If I wanted to copy them to another IMAP server via IMAP = protocol, this spec would require the destination server to fail the = operation tens of times, making it highly annoying. (I doubt (m)any IMAP = clients would attempt to convert 8bit headers to 7bit). Similarly I wouldn't want my server to reject the APPEND when the 8bit = header contained non-UTF8 input. > The "UTF8=3DONLY" capability permits an IMAP server to advertise = that > it does not permit the international mailbox name convention > (modified UTF-7), This doesn't really sound like what "design rationale" section talks = about UTF8=3DONLY. Isn't the idea simply to behave as if client has done = ENABLE UTF8=3DACCEPT (which may or may not happen to work with current = clients)? > servers that > may be accessed by the same user with different clients or methods > (e.g., POP or webmail systems in addition to IMAP or IMAP clients > with different capabilities) will need to exert extreme care to be > sure that UIDVALIDITY behaves as the user would expect I wonder what exactly that means. I guess UIDVALIDITY means something = more than the UIDVALIDITY value specifically. If client A downloads UID = 5 downgraded and client B downloads it non-downgraded, the messages are = different but that probably isn't a problem? > The > "ENABLE UTF8=3DACCEPT" command MUST only be used in the = authenticated > state. (Note that the "UTF8=3DONLY" capability described in=20 > Section 6 >=20 > implies the "UTF8=3DACCEPT" capability. So client should use ENABLE UTF8=3DACCEPT instead of ENABLE UTF8=3DONLY? = .. except this kind of sneaks in: > when IMAP clients do not issue "ENABLE > UTF8=3DACCEPT" or "ENABLE UTF8=3DONLY". Probably should be removed from here? Or shouldn't it even be simply = ENABLE UTF8? > When an IMAP server uses a mailbox format that supports UTF-8 headers > and it permits selection or examination of that mailbox without the > "UTF8" parameter This document doesn't talk about UTF8 parameter anywhere else.= From prvs=594ee9838=fmartin@linkedin.com Tue Sep 11 16:59:50 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7A221F8646; Tue, 11 Sep 2012 16:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.242 X-Spam-Level: X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rQRmlTlosLh; Tue, 11 Sep 2012 16:59:49 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id B468421F861B; Tue, 11 Sep 2012 16:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1347407989; x=1378943989; h=from:to:cc:subject:date:message-id:mime-version; bh=AE85iRyx99tjt6TWbRn4ULAv/Q+qqbKrmzUJduw0dLY=; b=Hxyof1jKXIzvS69jdKm2qW7mwG2I9/qLpCdDXZpZBA2N4Bsfb2Bdt7cZ pX4tQl7d6iFXjxVtu15gBQxCEjcs4K9gO/uYMv+BtOvLwzRAFWGUcEbKM 9VjCbl2V7BZSM6BpqeLQHSooMG0x3qykIsy6hQ3xCuUfvbc8RbzLpBsLh s=; X-IronPort-AV: E=Sophos;i="4.80,407,1344236400"; d="scan'208,217";a="25228767" Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.01.0355.002; Tue, 11 Sep 2012 16:59:20 -0700 From: Franck Martin To: "ima@ietf.org" Thread-Topic: EAI and ADSP/DMARC Thread-Index: AQHNkHl115d5a7SL3kKCpOzM5E1zTA== Date: Tue, 11 Sep 2012 23:59:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.247] Content-Type: multipart/alternative; boundary="_000_CC751E7D5AA03fmartinlinkedincom_" MIME-Version: 1.0 Cc: "ietf-822@ietf.org" Subject: [EAI] EAI and ADSP/DMARC X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 23:59:50 -0000 --_000_CC751E7D5AA03fmartinlinkedincom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm moving all the threads away from EAI last call, as I think I feel bette= r with the current last call documents. I have been advised to also post to= ietf-822@ietf.org. So apologies, if I cross post and you miss a bit of his= tory. So I read RFC6530 and I'll try to resume my understanding. No MTA talking to another MTA will downgrade or upgrade an email. If the re= ceiving MTA cannot handle UTF8, then the email will be bounced. Now the submitting MUA, will receive the bounce, and the MUA or the user ma= y decide to provide an ASCII compatible email message, to be transmitted al= l the way. The RFCs do not seem to indicate specific ways to do a downgrade= so that an International email can be converted into an ascii one and sent= . It is left to the user may be with some help from its MUA to do this work= . However what I see is the possibility, for the MUA to use the group syntax = in the From: header and submit that to the MTA to deliver to the final MTA. If my understanding is correct, this is an issue because the receiving MTA = will not have enough information to provide a check using ADSP or DMARC. Th= is case should not be allowed. That a receiving MTA downgrade the From: into a group syntax for the MUA to= be able to display the email to the end user, is an annoyance in terms of = ADSP/DMARC but as mentioned the fix is for the end user to upgrade its MUA.= ADSP/DMARC would have already been applied to the email at this stage, so = no core functionality would be lost in that transaction. The MTA would also= have added Authentication-Results: header with the necessary information t= o indicate the result of SPF, DKIM, ADSP, DMARC. However this header is not= easily visible to the end user. The DMARC spec can alert people about this= case in Security Considerations, i.e. We could live with it. So in summary, my opinion is that a submitting MUA MUST NOT be allowed to u= se the group syntax when submitting an email to an MTA. Corrolary a MTA MUS= T not accept an email where the From: header contains the group syntax and = should bounce that email. I think this course would keep the security benefits that ADSP/DMARC provid= e to the email environment. Did I miss something? This opinion is not the opinion of the DMARC group nor my company, etc=85 t= his is an individual submission as anything IETF related. --_000_CC751E7D5AA03fmartinlinkedincom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I'm moving all the threads away from EAI last call, as I think I feel = better with the current last call documents. I have been advised to also po= st to ietf-822@ietf.org. So apologies, if I cross post and you miss a bit o= f history.

So I read RFC6530 and I'll try to resume my understanding.

No MTA talking to another MTA will downgrade or upgrade an email. If t= he receiving MTA cannot handle UTF8, then the email will be bounced.

Now the submitting MUA, will receive the bounce, and the MUA or the us= er may decide to provide an ASCII compatible email message, to be transmitt= ed all the way. The RFCs do not seem to indicate specific ways to do a down= grade so that an International email can be converted into an ascii one and sent. It is left to the user may be= with some help from its MUA to do this work.

However what I see is the possibility, for the MUA to use the group sy= ntax in the From: header and submit that to the MTA to deliver to the final= MTA.

If my understanding is correct, this is an issue because the receiving= MTA will not have enough information to provide a check using ADSP or DMAR= C. This case should not be allowed.

That a receiving MTA downgrade the From: into a group syntax for the M= UA to be able to display the email to the end user, is an annoyance in term= s of ADSP/DMARC but as mentioned the fix is for the end user to upgrade its= MUA. ADSP/DMARC would have already been applied to the email at this stage, so no core functionality would be= lost in that transaction. The MTA would also have added Authentication-Res= ults: header with the necessary information to indicate the result of SPF, = DKIM, ADSP, DMARC. However this header is not easily visible to the end user. The DMARC spec can alert peo= ple about this case in Security Considerations, i.e. We could live with it.=

So in summary, my opinion is that a submitting MUA MUST NOT be allowed= to use the group syntax when submitting an email to an MTA. Corrolary a MT= A MUST not accept an email where the From: header contains the group syntax= and should bounce that email.

I think this course would keep the security benefits that ADSP/DMARC p= rovide to the email environment.

Did I miss something?

This opinion is not the opinion of the DMARC group nor my company, etc= =85 this is an individual submission as anything IETF related.

--_000_CC751E7D5AA03fmartinlinkedincom_-- From klensin@jck.com Wed Sep 12 10:06:54 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8F721F86F7; Wed, 12 Sep 2012 10:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HnWs7MiCQ1t; Wed, 12 Sep 2012 10:06:53 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 389B921F86B0; Wed, 12 Sep 2012 10:06:53 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TBqOp-000N7J-L0; Wed, 12 Sep 2012 13:06:51 -0400 Date: Wed, 12 Sep 2012 13:06:46 -0400 From: John C Klensin To: Franck Martin , ima@ietf.org Message-ID: <552AC775A1DF20391196AE4A@JcK-HP8200.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 Cc: ietf-822@ietf.org Subject: Re: [EAI] EAI and ADSP/DMARC X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 17:06:55 -0000 --On Tuesday, September 11, 2012 23:59 +0000 Franck Martin wrote: > I'm moving all the threads away from EAI last call, as I think > I feel better with the current last call documents. I have > been advised to also post to ietf-822@ietf.org. So apologies, > if I cross post and you miss a bit of history. Thanks. I suspect it should be moved off the EAI list as well. I won't insist on that (yet), but you should consider it. > So I read RFC6530 and I'll try to resume my understanding. > > No MTA talking to another MTA will downgrade or upgrade an > email. If the receiving MTA cannot handle UTF8, then the email > will be bounced. That is correct, with one qualification. If some MTA in the system decides that avoiding the risk of blowback is more important than properly delivering an NDN, the message disappears. I mention that in order to stress how little a MUST means in the presence of what RFC 5321 describes as "operational necessity". If people are convinced that what the Standard specifies is inappropriate or hazardous in their environment, they will ignore the standard and do what they think is right. In that context, the only difference between "MUST", "SHOULD" and "Pretty Please" is whether the Standard looks silly when it is ignored. The choice of requirement words won't affect the decision. > Now the submitting MUA, will receive the bounce, and the MUA > or the user may decide to provide an ASCII compatible email > message, to be transmitted all the way. The RFCs do not seem > to indicate specific ways to do a downgrade so that an > International email can be converted into an ascii one and > sent. It is left to the user may be with some help from its > MUA to do this work. Yes. There is no "do not seem". It isn't specified because circumstances and remedies will differ too much depending on what information is available and where. > However what I see is the possibility, for the MUA to use the > group syntax in the From: header and submit that to the MTA to > deliver to the final MTA. That MTA (really a Submission Server in today's vocabulary, see RFC 6409) has to generate a backward-pointing envelope address from somewhere to put into the MAIL command. As far as I know, there are only two types of methods in use: it figures the address out from the headers of the message that MUA hands it and it gets the information out of band. If it has to figure it out, it is pretty much stuck: the group syntax isn't permitted in the envelope and there is no plausible transformation from it. FWIW, the Submission Server is prohibited (with a MUST) from injecting an invalid message into the public Internet. If the backward-pointing envelope information is transmitted out of band, I suppose that the MUA could supply group information in the "From:" header field and a valid (and ASCII) address in the envelope. But that would be at least stupid and probably malicious. It is hard for me to believe that specific language banning it --language that goes beyond the "don't do this" language that already appears in draft-leiba--5322upd-from-group-04-- would have any effect on the author of an MUA who wants to do that or on the author of a Submission Server who want to allow it. So I think you are getting very excited about a non-problem. > If my understanding is correct, this is an issue because the > receiving MTA will not have enough information to provide a > check using ADSP or DMARC. This case should not be allowed. To say part of what I think John Levine has been saying, one of the characteristics of FUSSP proposals in the past has been that, having invented the FUSSP, not only the IETF will get in line and change the way email works to accommodate your solution, but those changes will deployed immediately worldwide because the FUSSP is so important (see http://www.rhyolite.com/anti-spam/you-might-be.html if you are not familiar with it). Not going to happen -- on the one hand, there are lots of ways in which a receiving MTA (relay or delivery server) may not have enough information to usefully provide the checks you are looking for. If the particular case of a group in the "From:" header field is important enough, than all an ADSP or DMARC procedure needs to do is to identify messages containing such fields as non-validatable. It isn't as if there are no other circumstances that can result in a message that can't be validated by those techniques. > That a receiving MTA downgrade the From: into a group syntax > for the MUA to be able to display the email to the end user, > is an annoyance in terms of ADSP/DMARC but as mentioned the > fix is for the end user to upgrade its MUA. ADSP/DMARC would > have already been applied to the email at this stage, so no > core functionality would be lost in that transaction. The MTA > would also have added Authentication-Results: header with the > necessary information to indicate the result of SPF, DKIM, > ADSP, DMARC. However this header is not easily visible to the > end user. The DMARC spec can alert people about this case in > Security Considerations, i.e. We could live with it. Ok. > So in summary, my opinion is that a submitting MUA MUST NOT be > allowed to use the group syntax when submitting an email to an > MTA. Corrolary a MTA MUST not accept an email where the From: > header contains the group syntax and should bounce that email. See above. Good luck with that. > I think this course would keep the security benefits that > ADSP/DMARC provide to the email environment. > > Did I miss something? Yes. See above. >... john p.s. I use different subscription addresses on different IETF mailing lists. If I were to try to reply to your message accurately with a message that would be posted by the mailing list expander to the EAI and ietf-822 or ietf-smtp lists, just about the only way to do it would be to put multiple addresses in the "From:" header, one that corresponded to each list. Yet another example of where that construction is potentially useful. From alexey.melnikov@isode.com Fri Sep 14 13:17:20 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E1F21F8564 for ; Fri, 14 Sep 2012 13:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyoCkRgMntKR for ; Fri, 14 Sep 2012 13:17:19 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id EBC1821F855F for ; Fri, 14 Sep 2012 13:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1347653837; d=isode.com; s=selector; i=@isode.com; bh=ReZEy3VEcCYMxYzpGdnZvFOVEOKYzfYoNM2abl/+Uyk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=IhSsLJSewlycTmrEyC6mKf13Ji1QMhlOJM1iYoD/UejqPzoWZjHcqqE59GepVa5X5HbtIm MdkNdmxVbznMjplROYGztpGYWm/jjrHU384onLaC8c5cxoAVxPFLCUiObEZGxlnTu6WzJS qYBcUm/io6mS+fXwm2i2A2ewvG3VnPw=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 14 Sep 2012 21:17:17 +0100 Message-ID: <505390CE.8070502@isode.com> Date: Fri, 14 Sep 2012 21:17:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Timo Sirainen References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 20:17:20 -0000 Hi Timo, On 11/09/2012 13:47, Timo Sirainen wrote: >> IMAP servers that advertise support for "UTF8=ACCEPT" or "UTF8=ONLY" >> MUST reject an APPEND command that includes any 8-bit in the message >> headers with a "NO" response, when IMAP clients do not issue "ENABLE >> UTF8=ACCEPT" or "ENABLE UTF8=ONLY". > This requires changing behavior of servers' existing behavior when it encounters such data. Yes, such messages shouldn't exist, but they do. I have tens of messages from Hotmail with 8bit subject headers in my INBOX. If I wanted to copy them to another IMAP server via IMAP protocol, this spec would require the destination server to fail the operation tens of times, making it highly annoying. (I doubt (m)any IMAP clients would attempt to convert 8bit headers to 7bit). > > Similarly I wouldn't want my server to reject the APPEND when the 8bit header contained non-UTF8 input. Hmm. Good point. I wish you brought this up earlier. Would changing the MUST to SHOULD address your concern or would you like to see further changes to this text? If the latter, can you suggest new text? >> The "UTF8=ONLY" capability permits an IMAP server to advertise that >> it does not permit the international mailbox name convention >> (modified UTF-7), > This doesn't really sound like what "design rationale" section talks about UTF8=ONLY. Isn't the idea simply to behave as if client has done ENABLE UTF8=ACCEPT (which may or may not happen to work with current clients)? No, I think the idea is to advertise that modified UTF-7 is not supported. >> servers that >> may be accessed by the same user with different clients or methods >> (e.g., POP or webmail systems in addition to IMAP or IMAP clients >> with different capabilities) will need to exert extreme care to be >> sure that UIDVALIDITY behaves as the user would expect > I wonder what exactly that means. I guess UIDVALIDITY means something more than the UIDVALIDITY value specifically. If client A downloads UID 5 downgraded and client B downloads it non-downgraded, the messages are different but that probably isn't a problem? Correct. This text is trying to talk about the case of a client A downloading a downgraded version, then being upgraded and still thinking that it has the authoritative version of the message. We don't want to require IMAP servers to use different UIDVALIDITY values for non-EAI-aware and EAI-aware clients. >> The >> "ENABLE UTF8=ACCEPT" command MUST only be used in the authenticated >> state. (Note that the "UTF8=ONLY" capability described in >> Section 6 >> >> implies the "UTF8=ACCEPT" capability. > So client should use ENABLE UTF8=ACCEPT instead of ENABLE UTF8=ONLY? .. except this kind of sneaks in: No, I think this is trying to say that either one can be used. So maybe the following change can clarify: In Section 3, change the 3rd sentence in the 2nd paragraph to read: OLD: Note that the "UTF8=ONLY" capability described in Section 6 implies the "UTF8=ACCEPT" capability. See additional information in that section.) NEW: Note that the "UTF8=ONLY" capability described in Section 6 implies the "UTF8=ACCEPT" capability and thus "ENABLE UTF8=ONLY" can be used instead of "ENABLE UTF8=ACCEPT". >> when IMAP clients do not issue "ENABLE >> UTF8=ACCEPT" or "ENABLE UTF8=ONLY". > Probably should be removed from here? Or shouldn't it even be simply ENABLE UTF8? I think it would be simpler to keep parity with IMAP CAPABILITY names. >> When an IMAP server uses a mailbox format that supports UTF-8 headers >> and it permits selection or examination of that mailbox without the >> "UTF8" parameter > This document doesn't talk about UTF8 parameter anywhere else. Well spotted. The document used to use UTF8 parameter to SELECT/EXAMINE, but this was removed. Now there is no other way of signaling the server that the client supports UTF8=ACCEPT/ONLY other than using ENABLE. So I propose the document should be changed to say: In Section 8 change the first sentence of the first paragraph to read: OLD: When an IMAP server uses a mailbox format that supports UTF-8 headers and it permits selection or examination of that mailbox without the "UTF8" parameter, it is the responsibility of the server to comply with the IMAP4rev1 base specification [RFC3501] and [RFC5322] with respect to all header information transmitted over the wire. NEW: When an IMAP server uses a mailbox format that supports UTF-8 headers and it permits selection or examination of that mailbox without issuing "ENABLE UTF8=ACCEPT" or "ENABLE UTF8=ONLY" first, it is the responsibility of the server to comply with the IMAP4rev1 base specification [RFC3501] and [RFC5322] with respect to all header information transmitted over the wire. I think this also means that that the following change should be done: In Section 3, 2nd paragraph, 1st sentence: OLD: A client MUST use the "ENABLE" command (defined in [RFC5161]) with the "UTF8=ACCEPT" option (defined in Section 4 below) to indicate to the server that the client accepts UTF-8 in quoted-strings. NEW: A client MUST use the "ENABLE" command (defined in [RFC5161]) with the "UTF8=ACCEPT" option (defined in Section 4 below) to indicate to the server that the client accepts UTF-8 in quoted-strings and supports UTF8=ACCEPT extension. From tss@iki.fi Fri Sep 14 14:37:18 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816B121F8557 for ; Fri, 14 Sep 2012 14:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.227 X-Spam-Level: X-Spam-Status: No, score=-110.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I49XwzTkFg9b for ; Fri, 14 Sep 2012 14:37:17 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8B921F84E2 for ; Fri, 14 Sep 2012 14:37:17 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 9D45B1AE87C4; Sat, 15 Sep 2012 00:37:15 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <505390CE.8070502@isode.com> Date: Sat, 15 Sep 2012 00:37:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <505390CE.8070502@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 21:37:18 -0000 On 14.9.2012, at 23.17, Alexey Melnikov wrote: > On 11/09/2012 13:47, Timo Sirainen wrote: >>> IMAP servers that advertise support for "UTF8=3DACCEPT" or = "UTF8=3DONLY" >>> MUST reject an APPEND command that includes any 8-bit in the = message >>> headers with a "NO" response, when IMAP clients do not issue = "ENABLE >>> UTF8=3DACCEPT" or "ENABLE UTF8=3DONLY". >> This requires changing behavior of servers' existing behavior when it = encounters such data. Yes, such messages shouldn't exist, but they do. I = have tens of messages from Hotmail with 8bit subject headers in my = INBOX. If I wanted to copy them to another IMAP server via IMAP = protocol, this spec would require the destination server to fail the = operation tens of times, making it highly annoying. (I doubt (m)any IMAP = clients would attempt to convert 8bit headers to 7bit). >>=20 >> Similarly I wouldn't want my server to reject the APPEND when the = 8bit header contained non-UTF8 input. > Hmm. Good point. I wish you brought this up earlier. Would changing = the MUST to SHOULD address your concern or would you like to see further = changes to this text? If the latter, can you suggest new text? How about changing the "MUST reject" to "MUST reject or translate to = 7-bit", although that requires rewriting the whole paragraph.. Something = like: If IMAP client does not issue "ENABLE UTF8=3DACCEPT" or "ENABLE = UTF8=3DONLY" and it sends an APPEND command that includes any 8-bit in the message headers, the server MUST either reject the APPEND command with "NO" response or alternatively translate the 8-bit data to 7-bit in implementation-defined way. Also I think there should be a paragraph: If IMAP client does issue "ENABLE UTF8=3DACCEPT" or "ENABLE UTF8=3DONLY" = and it sends an APPEND command that includes invalid UTF-8 data in the message headers, the server MUST reject the APPEND with "NO" response. Old = messages may contain non-UTF8 headers, so when a client copies messages from another = store to IMAP server, it SHOULD verify that it is sending only valid UTF8 = headers. Non-UTF8 data in message bodies is allowed, I think? >>> The "UTF8=3DONLY" capability permits an IMAP server to advertise = that >>> it does not permit the international mailbox name convention >>> (modified UTF-7), >> This doesn't really sound like what "design rationale" section talks = about UTF8=3DONLY. Isn't the idea simply to behave as if client has done = ENABLE UTF8=3DACCEPT (which may or may not happen to work with current = clients)? >=20 > No, I think the idea is to advertise that modified UTF-7 is not = supported. If that's the only reason for UTF8=3DONLY it seems a rather wasteful = capability. A server that doesn't bother to implement mUTF7, but does = bother to implement other kinds backwards compatibility seems rather = unlikely to me. The text in design rationale section talks that in future everyone would = be using UTF8 capable clients and servers and all the old compatibility = code could be removed. Wouldn't it make much more sense for UTF8=3DONLY = to mean that the server has no more such compatibility code? (Basically = my idea about assuming client has done ENABLE UTF8=3DACCEPT.) >>> servers that >>> may be accessed by the same user with different clients or methods >>> (e.g., POP or webmail systems in addition to IMAP or IMAP clients >>> with different capabilities) will need to exert extreme care to be >>> sure that UIDVALIDITY behaves as the user would expect >> I wonder what exactly that means. I guess UIDVALIDITY means something = more than the UIDVALIDITY value specifically. If client A downloads UID = 5 downgraded and client B downloads it non-downgraded, the messages are = different but that probably isn't a problem? > Correct. This text is trying to talk about the case of a client A = downloading a downgraded version, then being upgraded and still thinking = that it has the authoritative version of the message. > We don't want to require IMAP servers to use different UIDVALIDITY = values for non-EAI-aware and EAI-aware clients. If the UIDVALIDITY and the UID stays the same, the upgraded client can = still think that its cached message is the authoritative version, right? = Unless this text is intended for client developers to discard cache in = such situations?= From tss@iki.fi Sat Sep 15 09:35:57 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197EC21F84BF for ; Sat, 15 Sep 2012 09:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.351 X-Spam-Level: X-Spam-Status: No, score=-110.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNHBtgX1xxIe for ; Sat, 15 Sep 2012 09:35:56 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1444C21F84B5 for ; Sat, 15 Sep 2012 09:35:47 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id C3F081AE87E0 for ; Sat, 15 Sep 2012 19:35:45 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Timo Sirainen In-Reply-To: Date: Sat, 15 Sep 2012 19:35:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5916632E-D140-44AF-8679-71474DEC49EC@iki.fi> References: <505390CE.8070502@isode.com> To: IETF EAI X-Mailer: Apple Mail (2.1084) Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 16:35:57 -0000 Maybe it should also have a sentence about using UTF8 in NAMESPACE = reply. It could contain UTF8 prefixes, and also when LANGUAGE extension = is enabled the TRANSLATION could contain UTF8. From alexey.melnikov@isode.com Sat Sep 15 13:57:15 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B03721F84E1 for ; Sat, 15 Sep 2012 13:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+Wk88ICU9Pe for ; Sat, 15 Sep 2012 13:57:14 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 33F4821F84F1 for ; Sat, 15 Sep 2012 13:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1347742632; d=isode.com; s=selector; i=@isode.com; bh=IhBOqqh1Wa9Y0UBGjz1QWqCqzeUfxfxEuUebMwviLME=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=kJ+WZRnhgk7mh2V4CfLwqo+R8Jak/U0rBlLOn13wkjXhrNu5Wv+tP4lUos4ruyc13HyXx2 uLT4qCoqYVul0smj3fBWZ7XpGvK20AMSCslsnLObJ3x5SSdnnqJ0FWjicSuHaX3gLk7Bgl VqOm9nXd+c9TPSNQwGxCnkPyw8pWMZI=; Received: from [192.168.1.3] (ppp94-29-63-74.pppoe.spdop.ru [94.29.63.74]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 15 Sep 2012 21:57:10 +0100 References: <505390CE.8070502@isode.com> In-Reply-To: Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Sat, 15 Sep 2012 21:55:05 +0100 To: Timo Sirainen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 20:57:15 -0000 Hi Timo, On 14 Sep 2012, at 22:37, Timo Sirainen wrote: > On 14.9.2012, at 23.17, Alexey Melnikov wrote: >=20 >> On 11/09/2012 13:47, Timo Sirainen wrote: >>>> IMAP servers that advertise support for "UTF8=3DACCEPT" or "UTF8=3DONL= Y" >>>> MUST reject an APPEND command that includes any 8-bit in the message >>>> headers with a "NO" response, when IMAP clients do not issue "ENABLE >>>> UTF8=3DACCEPT" or "ENABLE UTF8=3DONLY". >>> This requires changing behavior of servers' existing behavior when it en= counters such data. Yes, such messages shouldn't exist, but they do. I have t= ens of messages from Hotmail with 8bit subject headers in my INBOX. If I wan= ted to copy them to another IMAP server via IMAP protocol, this spec would r= equire the destination server to fail the operation tens of times, making it= highly annoying. (I doubt (m)any IMAP clients would attempt to convert 8bit= headers to 7bit). >>>=20 >>> Similarly I wouldn't want my server to reject the APPEND when the 8bit h= eader contained non-UTF8 input. >> Hmm. Good point. I wish you brought this up earlier. Would changing the M= UST to SHOULD address your concern or would you like to see further changes t= o this text? If the latter, can you suggest new text? >=20 > How about changing the "MUST reject" to "MUST reject or translate to 7-bit= ", although that requires rewriting the whole paragraph.. Something like: >=20 > If IMAP client does not issue "ENABLE UTF8=3DACCEPT" or "ENABLE UTF8=3DONL= Y" > and it sends an APPEND command that includes any 8-bit in the message > headers, the server MUST either reject the APPEND command with "NO" > response or alternatively translate the 8-bit data to 7-bit in > implementation-defined way. Seems sensible. > Also I think there should be a paragraph: >=20 > If IMAP client does issue "ENABLE UTF8=3DACCEPT" or "ENABLE UTF8=3DONLY" a= nd it > sends an APPEND command that includes invalid UTF-8 data in the message > headers, the server MUST reject the APPEND with "NO" response. Old message= s may > contain non-UTF8 headers, so when a client copies messages from another st= ore > to IMAP server, it SHOULD verify that it is sending only valid UTF8 header= s. Ok. > Non-UTF8 data in message bodies is allowed, I think? Yes. Can be binary. >>>> The "UTF8=3DONLY" capability permits an IMAP server to advertise that >>>> it does not permit the international mailbox name convention >>>> (modified UTF-7), >>> This doesn't really sound like what "design rationale" section talks abo= ut UTF8=3DONLY. Isn't the idea simply to behave as if client has done ENABLE= UTF8=3DACCEPT (which may or may not happen to work with current clients)? >>=20 >> No, I think the idea is to advertise that modified UTF-7 is not supported= . >=20 > If that's the only reason for UTF8=3DONLY it seems a rather wasteful capab= ility. A server that doesn't bother to implement mUTF7, but does bother to i= mplement other kinds backwards compatibility seems rather unlikely to me. I think the idea was that everybody would implement UTF8=3DONLY and UTF8=3DA= CCEPT goes away and can be obsoleted. >=20 > The text in design rationale section talks that in future everyone would b= e using UTF8 capable clients and servers and all the old compatibility code c= ould be removed. Wouldn't it make much more sense for UTF8=3DONLY to mean th= at the server has no more such compatibility code? (Basically my idea about a= ssuming client has done ENABLE UTF8=3DACCEPT.) Can you suggest some text, I am not yet sure what exactly you are suggesting= . >=20 >>>> servers that >>>> may be accessed by the same user with different clients or methods >>>> (e.g., POP or webmail systems in addition to IMAP or IMAP clients >>>> with different capabilities) will need to exert extreme care to be >>>> sure that UIDVALIDITY behaves as the user would expect >>> I wonder what exactly that means. I guess UIDVALIDITY means something mo= re than the UIDVALIDITY value specifically. If client A downloads UID 5 down= graded and client B downloads it non-downgraded, the messages are different b= ut that probably isn't a problem? >> Correct. This text is trying to talk about the case of a client A downloa= ding a downgraded version, then being upgraded and still thinking that it ha= s the authoritative version of the message. >> We don't want to require IMAP servers to use different UIDVALIDITY values= for non-EAI-aware and EAI-aware clients. >=20 > If the UIDVALIDITY and the UID stays the same, the upgraded client can sti= ll think that its cached message is the authoritative version, right? Exactly. > Unless this text is intended for client developers to discard cache in suc= h situations? Yes, maybe it should be clearer about that. From alexey.melnikov@isode.com Sat Sep 15 14:08:10 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3136E21F8476 for ; Sat, 15 Sep 2012 14:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJbvvEXWCnYK for ; Sat, 15 Sep 2012 14:08:09 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id C987121F8475 for ; Sat, 15 Sep 2012 14:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1347743287; d=isode.com; s=selector; i=@isode.com; bh=IhBOqqh1Wa9Y0UBGjz1QWqCqzeUfxfxEuUebMwviLME=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=aksC/h1/cCjVBCnB9azOUd7FhgWrCVdjvsSPEZXB87VtD6uyJJFa6G7/LX9P2L5lr78ql/ LGNgQdZ86mVBy1M1Frw2OEITSbNhFghq2otBAlr+GbOCLkLpr5eF1/jr6/Pe2aZs1Roasc BuV0ADFb5O1aHkBMjBe7EtrZ0RYbL3Q=; Received: from [192.168.1.3] (ppp94-29-63-74.pppoe.spdop.ru [94.29.63.74]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 15 Sep 2012 22:07:07 +0100 References: <505390CE.8070502@isode.com> In-Reply-To: Message-Id: From: Alexey Melnikov Date: Sat, 15 Sep 2012 21:55:05 +0100 To: Timo Sirainen X-Mailer: iPad Mail (9B206) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 21:08:10 -0000 Hi Timo, On 14 Sep 2012, at 22:37, Timo Sirainen wrote: > On 14.9.2012, at 23.17, Alexey Melnikov wrote: >=20 >> On 11/09/2012 13:47, Timo Sirainen wrote: >>>> IMAP servers that advertise support for "UTF8=3DACCEPT" or "UTF8=3DONL= Y" >>>> MUST reject an APPEND command that includes any 8-bit in the message >>>> headers with a "NO" response, when IMAP clients do not issue "ENABLE >>>> UTF8=3DACCEPT" or "ENABLE UTF8=3DONLY". >>> This requires changing behavior of servers' existing behavior when it en= counters such data. Yes, such messages shouldn't exist, but they do. I have t= ens of messages from Hotmail with 8bit subject headers in my INBOX. If I wan= ted to copy them to another IMAP server via IMAP protocol, this spec would r= equire the destination server to fail the operation tens of times, making it= highly annoying. (I doubt (m)any IMAP clients would attempt to convert 8bit= headers to 7bit). >>>=20 >>> Similarly I wouldn't want my server to reject the APPEND when the 8bit h= eader contained non-UTF8 input. >> Hmm. Good point. I wish you brought this up earlier. Would changing the M= UST to SHOULD address your concern or would you like to see further changes t= o this text? If the latter, can you suggest new text? >=20 > How about changing the "MUST reject" to "MUST reject or translate to 7-bit= ", although that requires rewriting the whole paragraph.. Something like: >=20 > If IMAP client does not issue "ENABLE UTF8=3DACCEPT" or "ENABLE UTF8=3DONL= Y" > and it sends an APPEND command that includes any 8-bit in the message > headers, the server MUST either reject the APPEND command with "NO" > response or alternatively translate the 8-bit data to 7-bit in > implementation-defined way. Seems sensible. > Also I think there should be a paragraph: >=20 > If IMAP client does issue "ENABLE UTF8=3DACCEPT" or "ENABLE UTF8=3DONLY" a= nd it > sends an APPEND command that includes invalid UTF-8 data in the message > headers, the server MUST reject the APPEND with "NO" response. Old message= s may > contain non-UTF8 headers, so when a client copies messages from another st= ore > to IMAP server, it SHOULD verify that it is sending only valid UTF8 header= s. Ok. > Non-UTF8 data in message bodies is allowed, I think? Yes. Can be binary. >>>> The "UTF8=3DONLY" capability permits an IMAP server to advertise that >>>> it does not permit the international mailbox name convention >>>> (modified UTF-7), >>> This doesn't really sound like what "design rationale" section talks abo= ut UTF8=3DONLY. Isn't the idea simply to behave as if client has done ENABLE= UTF8=3DACCEPT (which may or may not happen to work with current clients)? >>=20 >> No, I think the idea is to advertise that modified UTF-7 is not supported= . >=20 > If that's the only reason for UTF8=3DONLY it seems a rather wasteful capab= ility. A server that doesn't bother to implement mUTF7, but does bother to i= mplement other kinds backwards compatibility seems rather unlikely to me. I think the idea was that everybody would implement UTF8=3DONLY and UTF8=3DA= CCEPT goes away and can be obsoleted. >=20 > The text in design rationale section talks that in future everyone would b= e using UTF8 capable clients and servers and all the old compatibility code c= ould be removed. Wouldn't it make much more sense for UTF8=3DONLY to mean th= at the server has no more such compatibility code? (Basically my idea about a= ssuming client has done ENABLE UTF8=3DACCEPT.) Can you suggest some text, I am not yet sure what exactly you are suggesting= . >=20 >>>> servers that >>>> may be accessed by the same user with different clients or methods >>>> (e.g., POP or webmail systems in addition to IMAP or IMAP clients >>>> with different capabilities) will need to exert extreme care to be >>>> sure that UIDVALIDITY behaves as the user would expect >>> I wonder what exactly that means. I guess UIDVALIDITY means something mo= re than the UIDVALIDITY value specifically. If client A downloads UID 5 down= graded and client B downloads it non-downgraded, the messages are different b= ut that probably isn't a problem? >> Correct. This text is trying to talk about the case of a client A downloa= ding a downgraded version, then being upgraded and still thinking that it ha= s the authoritative version of the message. >> We don't want to require IMAP servers to use different UIDVALIDITY values= for non-EAI-aware and EAI-aware clients. >=20 > If the UIDVALIDITY and the UID stays the same, the upgraded client can sti= ll think that its cached message is the authoritative version, right? Exactly. > Unless this text is intended for client developers to discard cache in suc= h situations? Yes, maybe it should be clearer about that. From yaojk@cnnic.cn Mon Sep 17 01:58:26 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D67921F84C2 for ; Mon, 17 Sep 2012 01:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.102 X-Spam-Level: X-Spam-Status: No, score=-100.102 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOt36Xepe-wx for ; Mon, 17 Sep 2012 01:58:25 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 3A58121F8476 for ; Mon, 17 Sep 2012 01:58:22 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 17 Sep 2012 16:58:08 +0800 Message-ID: From: "Jiankang YAO" To: "Timo Sirainen" References: Date: Mon, 17 Sep 2012 16:58:56 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ima@ietf.org Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 08:58:26 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlRpbW8gU2lyYWluZW4iIDx0 c3NAaWtpLmZpPg0KVG86IDxpbWEtcmVxdWVzdEBpZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIFNl cHRlbWJlciAxMSwgMjAxMiA4OjQ3IFBNDQpTdWJqZWN0OiBbRUFJXSA1NzM4YmlzDQouLi4NCj4g DQo+PiBzZXJ2ZXJzIHRoYXQNCj4+ICAgbWF5IGJlIGFjY2Vzc2VkIGJ5IHRoZSBzYW1lIHVzZXIg d2l0aCBkaWZmZXJlbnQgY2xpZW50cyBvciBtZXRob2RzDQo+PiAgIChlLmcuLCBQT1Agb3Igd2Vi bWFpbCBzeXN0ZW1zIGluIGFkZGl0aW9uIHRvIElNQVAgb3IgSU1BUCBjbGllbnRzDQo+PiAgIHdp dGggZGlmZmVyZW50IGNhcGFiaWxpdGllcykgd2lsbCBuZWVkIHRvIGV4ZXJ0IGV4dHJlbWUgY2Fy ZSB0byBiZQ0KPj4gICBzdXJlIHRoYXQgVUlEVkFMSURJVFkgYmVoYXZlcyBhcyB0aGUgdXNlciB3 b3VsZCBleHBlY3QNCj4gDQo+IEkgd29uZGVyIHdoYXQgZXhhY3RseSB0aGF0IG1lYW5zLiBJIGd1 ZXNzIFVJRFZBTElESVRZIG1lYW5zIHNvbWV0aGluZyBtb3JlIHRoYW4gdGhlIFVJRFZBTElESVRZ IHZhbHVlIHNwZWNpZmljYWxseS4gSWYgY2xpZW50IEEgZG93bmxvYWRzIFVJRCA1IGRvd25ncmFk ZWQgYW5kIGNsaWVudCBCIGRvd25sb2FkcyBpdCBub24tZG93bmdyYWRlZCwgdGhlIG1lc3NhZ2Vz IGFyZSBkaWZmZXJlbnQgYnV0IHRoYXQgcHJvYmFibHkgaXNuJ3QgYSBwcm9ibGVtPw0KPiANCj4N Cg0KZm9yIHRoZSBVSURWQUxJRElUWSBpc3N1ZSwgdGhlIHdnIGRpZCBoYXZlIGEgZGlzY3Vzc2lv biB0aHJlYWQgbmFtZWQgd2l0aCAiW0VBSV0gU3RhdHVzIHN1bW1hcnkgb24gU2ltcGxlRG93bmdy YWRlIg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2ltYS9jdXJyZW50L21z ZzA0NzkzLmh0bWwNCg0KDQp0aGVuIHRoZSB3ZyBoYXMgdGhlIGZvbGxvd2luZyBwcm9wb3NlZCB0 ZXh0IGFib3V0IDU3MzhiaXMNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2ltYS9jdXJyZW50L21zZzA0ODIwLmh0bWwNCg0KDQpzbyB0aGUgcHJvcG9zZWQgdGV4dCBhcHBl YXIgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiA1NzM4YmlzLg0KDQoNCkppYW5rYW5nIFlhbw0K From yaojk@cnnic.cn Mon Sep 17 02:30:01 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3036F21F854C for ; Mon, 17 Sep 2012 02:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.474 X-Spam-Level: X-Spam-Status: No, score=-100.474 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vw-vIciejFAc for ; Mon, 17 Sep 2012 02:30:00 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 2AB7721F8546 for ; Mon, 17 Sep 2012 02:29:56 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 17 Sep 2012 17:29:48 +0800 Message-ID: <8902395C76EB4765BFA506CBB1ACB718@LENOVO47E041CF> From: "Jiankang YAO" To: "Timo Sirainen" , "Alexey Melnikov" References: <505390CE.8070502@isode.com> Date: Mon, 17 Sep 2012 17:30:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 09:30:01 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlRpbW8gU2lyYWluZW4iIDx0 c3NAaWtpLmZpPg0KVG86ICJBbGV4ZXkgTWVsbmlrb3YiIDxhbGV4ZXkubWVsbmlrb3ZAaXNvZGUu Y29tPg0KQ2M6ICJJRVRGIEVBSSIgPGltYUBpZXRmLm9yZz4NClNlbnQ6IFNhdHVyZGF5LCBTZXB0 ZW1iZXIgMTUsIDIwMTIgNTozNyBBTQ0KU3ViamVjdDogUmU6IFtFQUldIDU3MzhiaXMNCg0KDQo+ IE9uIDE0LjkuMjAxMiwgYXQgMjMuMTcsIEFsZXhleSBNZWxuaWtvdiB3cm90ZToNCj4gDQo+PiBP biAxMS8wOS8yMDEyIDEzOjQ3LCBUaW1vIFNpcmFpbmVuIHdyb3RlOg0KPj4+PiAgIElNQVAgc2Vy dmVycyB0aGF0IGFkdmVydGlzZSBzdXBwb3J0IGZvciAiVVRGOD1BQ0NFUFQiIG9yICJVVEY4PU9O TFkiDQo+Pj4+ICAgTVVTVCByZWplY3QgYW4gQVBQRU5EIGNvbW1hbmQgdGhhdCBpbmNsdWRlcyBh bnkgOC1iaXQgaW4gdGhlIG1lc3NhZ2UNCj4+Pj4gICBoZWFkZXJzIHdpdGggYSAiTk8iIHJlc3Bv bnNlLCB3aGVuIElNQVAgY2xpZW50cyBkbyBub3QgaXNzdWUgIkVOQUJMRQ0KPj4+PiAgIFVURjg9 QUNDRVBUIiBvciAiRU5BQkxFIFVURjg9T05MWSIuDQo+Pj4gVGhpcyByZXF1aXJlcyBjaGFuZ2lu ZyBiZWhhdmlvciBvZiBzZXJ2ZXJzJyBleGlzdGluZyBiZWhhdmlvciB3aGVuIGl0IGVuY291bnRl cnMgc3VjaCBkYXRhLiBZZXMsIHN1Y2ggbWVzc2FnZXMgc2hvdWxkbid0IGV4aXN0LCBidXQgdGhl eSBkby4gSSBoYXZlIHRlbnMgb2YgbWVzc2FnZXMgZnJvbSBIb3RtYWlsIHdpdGggOGJpdCBzdWJq ZWN0IGhlYWRlcnMgaW4gbXkgSU5CT1guIElmIEkgd2FudGVkIHRvIGNvcHkgdGhlbSB0byBhbm90 aGVyIElNQVAgc2VydmVyIHZpYSBJTUFQIHByb3RvY29sLCB0aGlzIHNwZWMgd291bGQgcmVxdWly ZSB0aGUgZGVzdGluYXRpb24gc2VydmVyIHRvIGZhaWwgdGhlIG9wZXJhdGlvbiB0ZW5zIG9mIHRp bWVzLCBtYWtpbmcgaXQgaGlnaGx5IGFubm95aW5nLiAoSSBkb3VidCAobSlhbnkgSU1BUCBjbGll bnRzIHdvdWxkIGF0dGVtcHQgdG8gY29udmVydCA4Yml0IGhlYWRlcnMgdG8gN2JpdCkuDQo+Pj4g DQo+Pj4gU2ltaWxhcmx5IEkgd291bGRuJ3Qgd2FudCBteSBzZXJ2ZXIgdG8gcmVqZWN0IHRoZSBB UFBFTkQgd2hlbiB0aGUgOGJpdCBoZWFkZXIgY29udGFpbmVkIG5vbi1VVEY4IGlucHV0Lg0KPj4g SG1tLiBHb29kIHBvaW50LiBJIHdpc2ggeW91IGJyb3VnaHQgdGhpcyB1cCBlYXJsaWVyLiBXb3Vs ZCBjaGFuZ2luZyB0aGUgTVVTVCB0byBTSE9VTEQgYWRkcmVzcyB5b3VyIGNvbmNlcm4gb3Igd291 bGQgeW91IGxpa2UgdG8gc2VlIGZ1cnRoZXIgY2hhbmdlcyB0byB0aGlzIHRleHQ/IElmIHRoZSBs YXR0ZXIsIGNhbiB5b3Ugc3VnZ2VzdCBuZXcgdGV4dD8NCj4gDQo+IEhvdyBhYm91dCBjaGFuZ2lu ZyB0aGUgIk1VU1QgcmVqZWN0IiB0byAiTVVTVCByZWplY3Qgb3IgdHJhbnNsYXRlIHRvIDctYml0 IiwgYWx0aG91Z2ggdGhhdCByZXF1aXJlcyByZXdyaXRpbmcgdGhlIHdob2xlIHBhcmFncmFwaC4u IFNvbWV0aGluZyBsaWtlOg0KPiANCj4gSWYgSU1BUCBjbGllbnQgZG9lcyBub3QgaXNzdWUgIkVO QUJMRSBVVEY4PUFDQ0VQVCIgb3IgIkVOQUJMRSBVVEY4PU9OTFkiDQo+IGFuZCBpdCBzZW5kcyBh biBBUFBFTkQgY29tbWFuZCB0aGF0IGluY2x1ZGVzIGFueSA4LWJpdCBpbiB0aGUgbWVzc2FnZQ0K PiBoZWFkZXJzLCB0aGUgc2VydmVyIE1VU1QgZWl0aGVyIHJlamVjdCB0aGUgQVBQRU5EIGNvbW1h bmQgd2l0aCAiTk8iDQo+IHJlc3BvbnNlIG9yIGFsdGVybmF0aXZlbHkgdHJhbnNsYXRlIHRoZSA4 LWJpdCBkYXRhIHRvIDctYml0IGluDQo+IGltcGxlbWVudGF0aW9uLWRlZmluZWQgd2F5Lg0KPiAN Cg0KVGhlIHdnIGRlY2lkZXMgYXNzdW1lcyB0aGF0IGFzc3VtZXMgdGhhdCB0aGUgSU1BUCBzZXJ2 ZXIgd2lsbCBiZQ0KICAgb3BlcmF0aW5nIGluIGEgZnVsbHkgaW50ZXJuYXRpb25hbGl6ZWQgZW52 aXJvbm1lbnQsIGFuZCB0aGF0IGFsbCBkb3duZ3JhZGUgbWF0ZXJpYWwgZ29lcyB0byBzZWN0aW9u IDcuDQpzbyBJIHByb3Bvc2UgdG8gY2hhbmdlIHlvdXIgdGV4dCAiYWx0ZXJuYXRpdmVseSB0cmFu c2xhdGUgdGhlIDgtYml0IGRhdGEgdG8gNy1iaXQgaW4NCiBpbXBsZW1lbnRhdGlvbi1kZWZpbmVk IHdheSIgdG8gImFsdGVybmF0aXZlbHkgZG8gaXQgYmFzZWQgb24gdGhlIGRpc2N1c3NlZCBpbiBT ZWN0aW9uIDcgYmVsb3ciDQoNCg0KSmlhbmthbmcgWWFvDQoNCg0KDQo= From tss@iki.fi Mon Sep 17 05:17:13 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348D521F8658 for ; Mon, 17 Sep 2012 05:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.413 X-Spam-Level: X-Spam-Status: No, score=-110.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw1aLMLlRlFq for ; Mon, 17 Sep 2012 05:17:12 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5483F21F8645 for ; Mon, 17 Sep 2012 05:17:12 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 786FE1AE87C4; Mon, 17 Sep 2012 15:17:10 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen X-Priority: 3 In-Reply-To: <8902395C76EB4765BFA506CBB1ACB718@LENOVO47E041CF> Date: Mon, 17 Sep 2012 15:17:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <505390CE.8070502@isode.com> <8902395C76EB4765BFA506CBB1ACB718@LENOVO47E041CF> To: Jiankang YAO X-Mailer: Apple Mail (2.1084) Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 12:17:13 -0000 On 17.9.2012, at 12.30, Jiankang YAO wrote: >>> On 11/09/2012 13:47, Timo Sirainen wrote: >>>>> IMAP servers that advertise support for "UTF8=3DACCEPT" or = "UTF8=3DONLY" >>>>> MUST reject an APPEND command that includes any 8-bit in the = message >>>>> headers with a "NO" response, when IMAP clients do not issue = "ENABLE >>>>> UTF8=3DACCEPT" or "ENABLE UTF8=3DONLY". >>>> This requires changing behavior of servers' existing behavior when = it encounters such data. Yes, such messages shouldn't exist, but they = do. I have tens of messages from Hotmail with 8bit subject headers in my = INBOX. If I wanted to copy them to another IMAP server via IMAP = protocol, this spec would require the destination server to fail the = operation tens of times, making it highly annoying. (I doubt (m)any IMAP = clients would attempt to convert 8bit headers to 7bit). >>>>=20 >>>> Similarly I wouldn't want my server to reject the APPEND when the = 8bit header contained non-UTF8 input. >>> Hmm. Good point. I wish you brought this up earlier. Would changing = the MUST to SHOULD address your concern or would you like to see further = changes to this text? If the latter, can you suggest new text? >>=20 >> How about changing the "MUST reject" to "MUST reject or translate to = 7-bit", although that requires rewriting the whole paragraph.. Something = like: >>=20 >> If IMAP client does not issue "ENABLE UTF8=3DACCEPT" or "ENABLE = UTF8=3DONLY" >> and it sends an APPEND command that includes any 8-bit in the message >> headers, the server MUST either reject the APPEND command with "NO" >> response or alternatively translate the 8-bit data to 7-bit in >> implementation-defined way. >>=20 >=20 > The wg decides assumes that assumes that the IMAP server will be > operating in a fully internationalized environment, and that all = downgrade material goes to section 7. > so I propose to change your text "alternatively translate the 8-bit = data to 7-bit in > implementation-defined way" to "alternatively do it based on the = discussed in Section 7 below" I think that only talks about how to do downgrading of proper UTF8 mails = to 7bit mails? I'm more worried about how to handle old 8bit mails that = are not necessarily UTF8 at all.= From iesg-secretary@ietf.org Mon Sep 17 14:25:02 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE5C21F85F0; Mon, 17 Sep 2012 14:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EW0hJKGE0VRV; Mon, 17 Sep 2012 14:25:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6372421F85B4; Mon, 17 Sep 2012 14:25:01 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120917212501.26827.29839.idtracker@ietfa.amsl.com> Date: Mon, 17 Sep 2012 14:25:01 -0700 Cc: eai mailing list , eai chair , RFC Editor Subject: [EAI] Document Action: 'Mailing Lists and non-ASCII Addresses' to Informational RFC (draft-ietf-eai-mailinglistbis-05.txt) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 21:25:02 -0000 The IESG has approved the following document: - 'Mailing Lists and non-ASCII Addresses' (draft-ietf-eai-mailinglistbis-05.txt) as Informational RFC This document is the product of the Email Address Internationalization Working Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-eai-mailinglistbis/ Technical Summary This document describes considerations for mailing lists with the introduction of internationalized email addresses. It outlines some possible scenarios for handling lists with mixtures of internationalized and traditional addresses, but does not offer implementation or deployment advice. Working Group Summary There were neither controversial nor tough decisions made in developing this draft. Document Quality This document does not specify a protocol. Instead, it outlines issues in the interactions between mailing lists and the protocols developed under the EAI effort. Protocol development work may be appropriate as experience with SMTPUTF8 systems and messages accumulates. Also, once work on internationalized versions of URIs becomes completely stable, it may be appropriate to revisit such specifications as RFC 2369 and RFC 2919 and update them if appropriate. That work is not part of the present EAI Charter and the WG does to propose to add it. In addition to several reviews of the core content of the document, Martin Duerst reviewed the draft thoroughly providing insights from the URI and developing IRI perspective. Personnel Joseph Yee is the Document Shepherd for this document. Pete Resnick is the Responsible Area Director. RFC Editor Notes NEW Obsoletes: 5983 From klensin@jck.com Tue Sep 25 08:42:38 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936A121F883C for ; Tue, 25 Sep 2012 08:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEmvKPa+Fa+1 for ; Tue, 25 Sep 2012 08:42:38 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8C421F84FE for ; Tue, 25 Sep 2012 08:42:38 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1TGXHR-0006JA-Kq for ima@ietf.org; Tue, 25 Sep 2012 11:42:37 -0400 Date: Tue, 25 Sep 2012 11:42:32 -0400 From: John C Klensin To: ima@ietf.org Message-ID: <4577FCF2D873833AA616D78E@JcK-HP8200.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 Subject: [EAI] Suggested wording change to draft-ietf-eai-5738bis-09 -- pleae confirm X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 15:42:38 -0000 Hi. There has been extensive discussion of the specific wording in a few of the POP/IMAP document as part of the IESG review. Because the WG spent a lot of time on some of the sections in question, I/we (Joseph and myself with backing from Pete and Barry) want to check changes that might be significant with the WG to be sure that no one thinks they change meaning for the worse or in a way that violates WG intent. In other situations where the proposed changes are purely editorial, our intent is to let the authors and RFC Editor sort things out rather than specifying exact text as part of the IESG approval process. If anyone objects to that model, please speak up. Otherwise, a proposed change to draft-ietf-eai-5738bis is below for your reading pleasure. Anyone who believes this change is a significant problem should speak up immediately. >>> OLD: >>> >>> ... If a client requests a UTF-8 message when >>> not in UTF-8 mode, the server MUST either create the >>> message content variant (discussed in Section 7 of >>> [I-D.ietf-eai-5738bis]) it sends to the client to comply >>> with unextended POP and Internet Mail Format without UTF-8 >>> mode support, or fail the request with a -ERR response >>> containing the UTF-8 response code (see section 5). ... >>> >>> NEW: >>> >>> ... If a client requests a UTF-8 message when >>> not in UTF-8 mode, the server MUST either create the >>> message content variant it sends to the client to comply >>> with unextended POP and Internet Mail Format without UTF-8 >>> mode support or fail the request with a -ERR response. >>> The server can create the message content variant in a >>> manner of its own choosing, and Section 7 of >>> [I-D.ietf-eai-5738bis] provides some discussion of potential >>> issues. Section 5 of this document discusses UTF8 >>> response codes. I have warned the proposer and the IESG that we expect to ask the RFC Editor to change terms like "message content variant" and "synthetic message" to "surrogate message"; that change is not affected by this proposal. john From ned+ima@mrochek.com Tue Sep 25 10:32:32 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E8921F8841 for ; Tue, 25 Sep 2012 10:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8vFMjtEMHRk for ; Tue, 25 Sep 2012 10:32:28 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6E95221F8834 for ; Tue, 25 Sep 2012 10:32:28 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OKO476YIHS0065LM@mauve.mrochek.com> for ima@ietf.org; Tue, 25 Sep 2012 10:27:23 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Tue, 25 Sep 2012 10:27:11 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01OKO46YY1SG0006TF@mauve.mrochek.com> Date: Tue, 25 Sep 2012 10:26:54 -0700 (PDT) In-reply-to: "Your message dated Tue, 25 Sep 2012 11:42:32 -0400" <4577FCF2D873833AA616D78E@JcK-HP8200.jck.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <4577FCF2D873833AA616D78E@JcK-HP8200.jck.com> To: John C Klensin Cc: ima@ietf.org Subject: Re: [EAI] Suggested wording change to draft-ietf-eai-5738bis-09 -- pleae confirm X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 17:32:32 -0000 This seems like a reasonable change to me. Ned > Hi. > There has been extensive discussion of the specific wording in a > few of the POP/IMAP document as part of the IESG review. > Because the WG spent a lot of time on some of the sections in > question, I/we (Joseph and myself with backing from Pete and > Barry) want to check changes that might be significant with the > WG to be sure that no one thinks they change meaning for the > worse or in a way that violates WG intent. In other situations > where the proposed changes are purely editorial, our intent is > to let the authors and RFC Editor sort things out rather than > specifying exact text as part of the IESG approval process. > If anyone objects to that model, please speak up. > Otherwise, a proposed change to draft-ietf-eai-5738bis is below > for your reading pleasure. Anyone who believes this change is a > significant problem should speak up immediately. > >>> OLD: > >>> > >>> ... If a client requests a UTF-8 message when > >>> not in UTF-8 mode, the server MUST either create the > >>> message content variant (discussed in Section 7 of > >>> [I-D.ietf-eai-5738bis]) it sends to the client to comply > >>> with unextended POP and Internet Mail Format without UTF-8 > >>> mode support, or fail the request with a -ERR response > >>> containing the UTF-8 response code (see section 5). ... > >>> > >>> NEW: > >>> > >>> ... If a client requests a UTF-8 message when > >>> not in UTF-8 mode, the server MUST either create the > >>> message content variant it sends to the client to comply > >>> with unextended POP and Internet Mail Format without UTF-8 > >>> mode support or fail the request with a -ERR response. > >>> The server can create the message content variant in a > >>> manner of its own choosing, and Section 7 of > >>> [I-D.ietf-eai-5738bis] provides some discussion of potential > >>> issues. Section 5 of this document discusses UTF8 > >>> response codes. > I have warned the proposer and the IESG that we expect to ask > the RFC Editor to change terms like "message content variant" > and "synthetic message" to "surrogate message"; that change is > not affected by this proposal. > john > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From duerst@it.aoyama.ac.jp Tue Sep 25 17:36:09 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37AB1F0C95 for ; Tue, 25 Sep 2012 17:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.057 X-Spam-Level: X-Spam-Status: No, score=-103.057 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wJaQ5C783DC for ; Tue, 25 Sep 2012 17:36:09 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id BECDB1F0C3A for ; Tue, 25 Sep 2012 17:36:07 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q8Q0ZubV004167 for ; Wed, 26 Sep 2012 09:35:57 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 08e8_45cf_22a0d9ce_0772_11e2_b4aa_001d096c5782; Wed, 26 Sep 2012 09:35:55 +0900 Received: from [IPv6:::1] ([133.2.210.1]:57094) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 26 Sep 2012 09:35:55 +0900 Message-ID: <50624DE8.1080402@it.aoyama.ac.jp> Date: Wed, 26 Sep 2012 09:35:52 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: ned+ima@mrochek.com References: <4577FCF2D873833AA616D78E@JcK-HP8200.jck.com> <01OKO46YY1SG0006TF@mauve.mrochek.com> In-Reply-To: <01OKO46YY1SG0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ima@ietf.org Subject: Re: [EAI] Suggested wording change to draft-ietf-eai-5738bis-09 -- pleae confirm X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 00:36:09 -0000 Same to me. Regards, Martin. On 2012/09/26 2:26, ned+ima@mrochek.com wrote: > This seems like a reasonable change to me. > > Ned > >> Hi. > >> There has been extensive discussion of the specific wording in a >> few of the POP/IMAP document as part of the IESG review. >> Because the WG spent a lot of time on some of the sections in >> question, I/we (Joseph and myself with backing from Pete and >> Barry) want to check changes that might be significant with the >> WG to be sure that no one thinks they change meaning for the >> worse or in a way that violates WG intent. In other situations >> where the proposed changes are purely editorial, our intent is >> to let the authors and RFC Editor sort things out rather than >> specifying exact text as part of the IESG approval process. > >> If anyone objects to that model, please speak up. > >> Otherwise, a proposed change to draft-ietf-eai-5738bis is below >> for your reading pleasure. Anyone who believes this change is a >> significant problem should speak up immediately. > > >>>>> OLD: >>>>> >>>>> ... If a client requests a UTF-8 message when >>>>> not in UTF-8 mode, the server MUST either create the >>>>> message content variant (discussed in Section 7 of >>>>> [I-D.ietf-eai-5738bis]) it sends to the client to comply >>>>> with unextended POP and Internet Mail Format without UTF-8 >>>>> mode support, or fail the request with a -ERR response >>>>> containing the UTF-8 response code (see section 5). ... >>>>> >>>>> NEW: >>>>> >>>>> ... If a client requests a UTF-8 message when >>>>> not in UTF-8 mode, the server MUST either create the >>>>> message content variant it sends to the client to comply >>>>> with unextended POP and Internet Mail Format without UTF-8 >>>>> mode support or fail the request with a -ERR response. >>>>> The server can create the message content variant in a >>>>> manner of its own choosing, and Section 7 of >>>>> [I-D.ietf-eai-5738bis] provides some discussion of potential >>>>> issues. Section 5 of this document discusses UTF8 >>>>> response codes. > >> I have warned the proposer and the IESG that we expect to ask >> the RFC Editor to change terms like "message content variant" >> and "synthetic message" to "surrogate message"; that change is >> not affected by this proposal. > >> john > >> _______________________________________________ >> IMA mailing list >> IMA@ietf.org >> https://www.ietf.org/mailman/listinfo/ima > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima > From barryleiba@gmail.com Thu Sep 27 17:15:48 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4547C21F8514 for ; Thu, 27 Sep 2012 17:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.078 X-Spam-Level: X-Spam-Status: No, score=-103.078 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ym7V8w-uX5u for ; Thu, 27 Sep 2012 17:15:47 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6181721F8464 for ; Thu, 27 Sep 2012 17:15:47 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so2882360vbb.31 for ; Thu, 27 Sep 2012 17:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=qQatJ7uOn1bLJguRWlGRBo+YBCcEQ7FVqEtP2cbbvUs=; b=mxXAZNW4GdKsLnSJTgszTnPyCeB8mgG3KFw7096aWYaOlqRYdEblmjUm+FDL55FnuX lSzAcsMjauszSboCtC9TpOgzXDjn+EXD16owZexDb/BRM3HG8RA6GZds/Wl5Q7rZk+j8 n2ws85jJBOkI7xmcPnWoUoB2uegKKLgrfo8D1M+36MM82DzU6ravzu2RI/uPZlkuURN4 y+DV8Ti6dT1UOjAXtIfhwsjUQ4uKXnPIZePzLGbuLH05FhNmNfmbddMnSO50goT0Y9xP MgWp+JvvVMWvgu4texthgemhs6dwLVS6DLcWMrmu6fAvObGebq2q01/l8EbfXhORWiBl GQ5g== MIME-Version: 1.0 Received: by 10.220.238.148 with SMTP id ks20mr3207591vcb.5.1348791346774; Thu, 27 Sep 2012 17:15:46 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.58.41 with HTTP; Thu, 27 Sep 2012 17:15:46 -0700 (PDT) Date: Thu, 27 Sep 2012 20:15:46 -0400 X-Google-Sender-Auth: 6fl-OGKeZqtbo7M_4talcjIBB0Q Message-ID: From: Barry Leiba To: draft-ietf-eai-rfc5721bis.all@tools.ietf.org, draft-ietf-eai-5738bis.all@tools.ietf.org, draft-ietf-eai-popimap-downgrade.all@tools.ietf.org, draft-ietf-eai-simpledowngrade.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: ima@ietf.org, eai-chairs@tools.ietf.org Subject: [EAI] Results of the IESG telechat with respect to the four EAI documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 00:15:48 -0000 The IESG discussed the four EAI documents on today's telechat (Thursday, 27 Sept 2012). All will likely soon be approved, pending some updates. Three of the documents (5738bis and the two downgrade docs) have DISCUSS positions held by Russ and Benoit, related to the normative nature of the downgrade docs and their Standards Track status. We believe that the following edits will clear those discusses, and that these edits retain the working group's consensus for these documents. I recommend that the chairs look these over and ask the document editors to make them forthwith. ---------------------------------------------------------------- draft-ietf-eai-5738bis, Section 7 OLD Choices available to the server when a message that requires SMTPUTF8 is encountered and the client doesn't enable UTF-8 capability include hiding the problematic message(s), creating in band or out of band notifications or error messages, or somehow trying to create a variation on the message with the intention of providing useful information to that client about what has occurred. Such variant messages cannot be actual substitutes for the original message: NEW Choices available to the server when a message that requires SMTPUTF8 is encountered and the client doesn't enable UTF-8 capability include hiding the problematic message(s), creating in band or out of band notifications or error messages, or somehow trying to create a variation on the message with the intention of providing useful information to that client about what has occurred. In creating a variant message, it is important to use an algorithm that has been carefully engineered to present useful information to the user, while not creating security or operational problems in the mail system. For this reason, implementations that choose this option MUST use a standard algorithm. Two such standard algorithms are introduced in the next paragraph. Such variant messages cannot be actual substitutes for the original message: [...etc...] ---------------------------------------------------------------- draft-ietf-eai-popimap-downgrade, Section 1.2 OLD 2. The message may be downgraded by the POP or IMAP server, in a way that preserves maximum information at the expense of some complexity. NEW 2. The message may be downgraded by the POP or IMAP server, in a standard way that preserves maximum information at the expense of some complexity, and does not create security or operational problems in the mail system. ---------------------------------------------------------------- draft-ietf-eai-simpledowngrade, Section 1 OLD This document specifies a way to present such messages to the client. It values simplicity of implementation over fidelity of representation, since implementing a high-fidelity downgrade algorithm is likely more work than implementing proper support for [RFC5721] and/or [RFC5738]. NEW This document specifies a standard way to present such messages to the client -- a way that does not create security or operational problems in the mail system. It values simplicity of implementation over fidelity of representation, since implementing a high-fidelity downgrade algorithm is likely more work than implementing proper support for [RFC5721] and/or [RFC5738]. ---------------------------------------------------------------- I'll note that these edits will still allow the references to the downgrade docs from 5738bis to be informative -- they do NOT need to be changed to normative. With these edits, Russ (and, we believe, Benoit) will accept the downgrade docs as Standards Track. (It's possible that the edits to the downgrade docs might not be absolutely necessary, but I think it's good to emphasize that the engineering behind them had a reason, and that it's an important aspect.) In addition, all editors should please check the non-blocking AD comments that have not been addressed yet, and work with the chairs to do a good-faith effort at addressing them. Some might merit text changes, while others might just need a response to the AD. http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5721bis/ballot/ Comments by Pete, Sean, and Stephen. http://datatracker.ietf.org/doc/draft-ietf-eai-5738bis/ballot/ Comments by Adrian, Robert, Sean, and Stephen. http://datatracker.ietf.org/doc/draft-ietf-eai-popimap-downgrade/ballot/ Comments by Robert and Stephen. http://datatracker.ietf.org/doc/draft-ietf-eai-simpledowngrade/ballot/ Comments by Robert and Stephen. The 5738bis editors should also take care to address the comments made by Timo and Alexey -- I will not be approving that document until that's been cleared up. Pete, you were going to try to work on this with Sean, I believe. I think 5738bis will definitely need a revised I-D. Changes to the others might be done with an RFC Editor note, depending upon what other changes (besides what's above) are needed. Pete can decide that, as the responsible AD for the other three documents. Barry From klensin@jck.com Thu Sep 27 20:49:39 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6194621F8530 for ; Thu, 27 Sep 2012 20:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMPWviV-0umv for ; Thu, 27 Sep 2012 20:49:38 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACAC21F8514 for ; Thu, 27 Sep 2012 20:49:38 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1THRa0-000GCu-AR; Thu, 27 Sep 2012 23:49:32 -0400 Date: Thu, 27 Sep 2012 23:49:27 -0400 From: John C Klensin To: Barry Leiba , draft-ietf-eai-rfc5721bis.all@tools.ietf.org, draft-ietf-eai-5738bis.all@tools.ietf.org, draft-ietf-eai-popimap-downgrade.all@tools.ietf.org, draft-ietf-eai-simpledowngrade.all@tools.ietf.org Message-ID: <31785012C2415E9046E66550@JcK-HP8200.jck.com> 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 Cc: ima@ietf.org, eai-chairs@tools.ietf.org Subject: Re: [EAI] Results of the IESG telechat with respect to the four EAI documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 03:49:39 -0000 Barry, Thanks. A few comments inline below. --On Thursday, September 27, 2012 20:15 -0400 Barry Leiba wrote: > The IESG discussed the four EAI documents on today's telechat > (Thursday, 27 Sept 2012). All will likely soon be approved, > pending some updates. > > Three of the documents (5738bis and the two downgrade docs) > have DISCUSS positions held by Russ and Benoit, related to the > normative nature of the downgrade docs and their Standards > Track status. We believe that the following edits will clear > those discusses, and that these edits retain the working > group's consensus for these documents. I recommend that the > chairs look these over and ask the document editors to make > them forthwith. > > -------------------------------------------------------------- > -- draft-ietf-eai-5738bis, Section 7 > > OLD > Choices available to the server when a message that > requires SMTPUTF8 is encountered and the client doesn't > enable UTF-8 capability include hiding the problematic > message(s), creating in band or out of band notifications > or error messages, or somehow trying to create a variation > on the message with the intention of providing useful > information to that client about what has occurred. Such > variant messages cannot be actual substitutes for the > original message: > > NEW > Choices available to the server when a message that > requires SMTPUTF8 is encountered and the client doesn't > enable UTF-8 capability include hiding the problematic > message(s), creating in band or out of band notifications > or error messages, or somehow trying to create a variation > on the message with the intention of providing useful > information to that client about what has occurred. > > In creating a variant message, it is important to use an > algorithm that has been carefully engineered to present > useful information to the user, while not creating security > or operational problems in the mail system. For this > reason, implementations that choose this option MUST use a > standard algorithm. Two such standard algorithms are > introduced in the next paragraph. > > Such variant messages cannot be actual substitutes for the > original message: [...etc...] As Pete and I discussed briefly on Jabber during the telechat, I think "MUST use a standard algorithm" is inappropriate for at least two reasons: (i) It does not meet the 2026 criterion of being necessary to assure interoperability. Note in particular that 2026 Section 6 says "For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability." While the intent is a little different, that is precisely what a MUST does in this case. Yes, the argument in the previous paragraph is, IMO, correct and important (and one I helped make). But someone who understands both models could easily design and implement a hybrid (applying the information-retaining features of popimap-downgrade to one or two header fields but otherwise following the simpledowngrade rules. That might or might not be wise and/or even sensible, but it would not be any more of an interoperability problem than either of the two specs alone would be. (ii) Putting in a MUST on this subject invites people to ignore us. Some will ignore us and get things right, others will ignore us and get them wrong. We would, IMO, actually be in a stronger position if we said something like "SHOULD use a standard algorithm. An exception might be justified if the algorithm chosen is either a combination of the standard models that does not introduce any new issues or if the implementer is confident that the select different procedure has achieved at least the same quality of community review that went into the standard algorithms." WG, consider this a call for comments and consensus: If others don't see this issue as significant, I'll drop my concerns and encourage the authors to use the language Barry proposes. If there are a significant number of people who share one or both of my concerns, I'm prepared to push back with an appeal if that is necessary. > -------------------------------------------------------------- > -- draft-ietf-eai-popimap-downgrade, Section 1.2 > > OLD > 2. The message may be downgraded by the POP or IMAP > server, in a way that preserves maximum information at > the expense of some complexity. > NEW > 2. The message may be downgraded by the POP or IMAP > server, in a standard way that preserves maximum > information at the expense of some complexity, and does > not create security or operational problems in the mail > system. This actually doesn't seem to add anything non-obvious to the document, but I don't see it as harmful. That said, I believe that "does not create security or operational problems..." is a much stronger assertion than can be justified. By any measure, replacing a message that the sender intended to be delivered as sent, without loss of information, with all integrity checks intact, and that can be replied to with a surrogate that may lack all of those properties is an "operational problem". Again, if others are comfortable with the new language, I can live with it. But, if not, we will need to figure out how to proceed. > -------------------------------------------------------------- > -- draft-ietf-eai-simpledowngrade, Section 1 > > OLD > This document specifies a way to present such messages to > the client. It values simplicity of implementation over > fidelity of representation, since implementing a > high-fidelity downgrade algorithm is likely more work than > implementing proper support for [RFC5721] and/or [RFC5738]. > > NEW > This document specifies a standard way to present such > messages to the client -- a way that does not create > security or operational problems in the mail system. It > values simplicity of implementation over fidelity of > representation, since implementing a high-fidelity > downgrade algorithm is likely more work than implementing > proper support for [RFC5721] and/or [RFC5738]. Cosmetic. If it amuses the IETF to insert the word "standard" in this or other places, I don't see why we should worry about it. > -------------------------------------------------------------- > > I'll note that these edits will still allow the references to > the downgrade docs from 5738bis to be informative -- they do > NOT need to be changed to normative. With these edits, Russ > (and, we believe, Benoit) will accept the downgrade docs as > Standards Track. (It's possible that the edits to the > downgrade docs might not be absolutely necessary, but I think > it's good to emphasize that the engineering behind them had a > reason, and that it's an important aspect.) > In addition, all editors should please check the non-blocking > AD comments that have not been addressed yet, and work with > the chairs to do a good-faith effort at addressing them. Some > might merit text changes, while others might just need a > response to the AD. > http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5721bis/ball > ot/ Comments by Pete, Sean, and Stephen. Authors should have received copies of most or all of those comments when they were made and should have seen responses from me to several of them. If you believe those responses are adequate, just say so -- you are not obligated to respond again unless Barry or Pete really want additional conformation. > http://datatracker.ietf.org/doc/draft-ietf-eai-5738bis/ballot/ > Comments by Adrian, Robert, Sean, and Stephen. > > > http://datatracker.ietf.org/doc/draft-ietf-eai-popimap-downgra > de/ballot/ Comments by Robert and Stephen. > > > http://datatracker.ietf.org/doc/draft-ietf-eai-simpledowngrade > /ballot/ Comments by Robert and Stephen. > The 5738bis editors should also take care to address the > comments made by Timo and Alexey -- I will not be approving > that document until that's been cleared up. Pete, you were > going to try to work on this with Sean, I believe. > > I think 5738bis will definitely need a revised I-D. Changes > to the others might be done with an RFC Editor note, depending > upon what other changes (besides what's above) are needed. > Pete can decide that, as the responsible AD for the other > three documents. Let me express a strong preference for new drafts of any document that requires more than a very small number of trivial and obvious changes (I think that means all of them, but haven't checked back over my list of the comments). The cleaner we can make the documents that go to the RFC Editor, the less likely they are to make errors, the more rapidly they can get the documents out, and the less time-consuming hassle we will have at AUTH48. It remains reasonable to insert a note into a document that a particular sentence or paragraph needs an editorial re-working if it is hard to follow and you aren't sure how to fix it: pointing out something to which the RFC Editor should pay extra attention is appropriate and they are good at their work. best, john > > Barry > _______________________________________________ > IMA mailing list > IMA@ietf.org > https://www.ietf.org/mailman/listinfo/ima From barryleiba@gmail.com Thu Sep 27 21:48:11 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1364F21F843F for ; Thu, 27 Sep 2012 21:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.058 X-Spam-Level: X-Spam-Status: No, score=-103.058 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSvgB9+UmuIX for ; Thu, 27 Sep 2012 21:48:09 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD77621F84C2 for ; Thu, 27 Sep 2012 21:48:09 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so3110644vcb.31 for ; Thu, 27 Sep 2012 21:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=oN+1+G+sQ3PficryytHmrHwg12Ed3/NopI9ju4Wqsg0=; b=M2Lox5J0bDtOT9R3+zZLAOw9RSiufFSlY41CztU74sLKJr7EoKTbOxAqHKB72okWUH MHSDfsYRJ2p62Z60ym6b3RkxVGPHgNH2jDylfqI1Ko2jbf5UUcd9mVBjOXSyvTJWFxA3 QCJqVPTIvkr6nakbbGcHWxCENtV3v0u5Th/y3C/z5SWxNbNBvzd7zUJcKmRiv3mGIFJk n/bEaGv4ec4D0do1emg916un6esBcJeY4/vfAoD1KGuIM/dwJrbe74RpvrXnfV4bIxSX EZyqKQxKao2qj9I1ycfTrRTIugKlmlWxHoFrjwucPDIx7KwyVyxRt+9Xd0TON5PW86we nN2A== MIME-Version: 1.0 Received: by 10.58.86.36 with SMTP id m4mr3610185vez.14.1348807689127; Thu, 27 Sep 2012 21:48:09 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.58.41 with HTTP; Thu, 27 Sep 2012 21:48:09 -0700 (PDT) In-Reply-To: <31785012C2415E9046E66550@JcK-HP8200.jck.com> References: <31785012C2415E9046E66550@JcK-HP8200.jck.com> Date: Fri, 28 Sep 2012 00:48:09 -0400 X-Google-Sender-Auth: s9lgQkgzsPUSuFKuLJyxQS-GgHI Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: eai-chairs@tools.ietf.org, draft-ietf-eai-rfc5721bis.all@tools.ietf.org, draft-ietf-eai-5738bis.all@tools.ietf.org, draft-ietf-eai-simpledowngrade.all@tools.ietf.org, ima@ietf.org, draft-ietf-eai-popimap-downgrade.all@tools.ietf.org Subject: Re: [EAI] Results of the IESG telechat with respect to the four EAI documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 04:48:11 -0000 > As Pete and I discussed briefly on Jabber during the telechat, I > think "MUST use a standard algorithm" is inappropriate for at > least two reasons: I understand your reasons. I don't know if a "SHOULD use a standard algorithm" would satisfy Russ and Benoit. You could ask, and try engaging them further on the question. > That said, I believe > that "does not create security or operational problems..." is a > much stronger assertion than can be justified. By any measure, > replacing a message that the sender intended to be delivered as > sent, without loss of information, with all integrity checks > intact, and that can be replied to with a surrogate that may > lack all of those properties is an "operational problem". Well, certainly feel free to change that phrase in all three places. It's what I came up with; that doesn't make it right. I think you know what I'm trying to say, so if you (or the WG) comes up with different language that gets the point across I think it will be fine. > Cosmetic. If it amuses the IETF to insert the word "standard" > in this or other places, I don't see why we should worry about > it. As I said, I don't know that that's necessary. The key part is the change to Section 7 of the IMAP spec. >> In addition, all editors should please check the non-blocking >> AD comments that have not been addressed yet, and work with >> the chairs to do a good-faith effort at addressing them. Some >> might merit text changes, while others might just need a >> response to the AD. > > Authors should have received copies of most or all of those > comments when they were made and should have seen responses from > me to several of them. If you believe those responses are > adequate, just say so -- you are not obligated to respond again > unless Barry or Pete really want additional conformation. I just listed the ones that are there and that I don't explicitly remember seeing addressed. It's possible that they all have been, in which case this is an easy step. Just making sure we have it covered. Barry From barryleiba@gmail.com Thu Sep 27 22:17:35 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF7D21F855D for ; Thu, 27 Sep 2012 22:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.051 X-Spam-Level: X-Spam-Status: No, score=-103.051 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z53mtT5soVq for ; Thu, 27 Sep 2012 22:17:35 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E206A21F855B for ; Thu, 27 Sep 2012 22:17:34 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so3131149vcb.31 for ; Thu, 27 Sep 2012 22:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tbbv5w5q7egIblscBety+tqqL+PYRT63iMpk1Kvwrgc=; b=otk/8IhbMwxQnq1CSePNu473lpOu4hENT1zXmO5MXu0sFvLn+m0d1Z6is91AzWh1jn o4ENtDFpR3SVcHlr7nx0TKRH6at6vSwuUsBoXBEKgT7fwVVwKUckS39a9FSh2Yxne9L4 /t8elsExIQoF+TYZyzI1jdOT3IV9zkXmFHcxz6+KTOBTidjZWPb55oOvU+PzXZLCN7ul AAsJU0SSurfl625A6WncHtKbHBvGGdv5l7AkdDSWpVbIVDNjZw01mmAUmB59nNgObf8O sC3E7eOtqdoWKlGaVCeNkpBQpgljRT0yqS4apCYfxoeIbuGW2KeXUI01lKyLPuUQws5k 2YeQ== MIME-Version: 1.0 Received: by 10.58.209.73 with SMTP id mk9mr3571608vec.25.1348809454175; Thu, 27 Sep 2012 22:17:34 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.58.41 with HTTP; Thu, 27 Sep 2012 22:17:34 -0700 (PDT) In-Reply-To: References: <31785012C2415E9046E66550@JcK-HP8200.jck.com> Date: Fri, 28 Sep 2012 01:17:34 -0400 X-Google-Sender-Auth: X2eJO4FLOZIUC-Pptfg-7yy-nHI Message-ID: From: Barry Leiba To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Cc: eai-chairs@tools.ietf.org, draft-ietf-eai-rfc5721bis.all@tools.ietf.org, draft-ietf-eai-5738bis.all@tools.ietf.org, draft-ietf-eai-simpledowngrade.all@tools.ietf.org, ima@ietf.org, draft-ietf-eai-popimap-downgrade.all@tools.ietf.org Subject: Re: [EAI] Results of the IESG telechat with respect to the four EAI documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 05:17:35 -0000 >> As Pete and I discussed briefly on Jabber during the telechat, I >> think "MUST use a standard algorithm" is inappropriate for at >> least two reasons: > > I understand your reasons. I don't know if a "SHOULD use a standard > algorithm" would satisfy Russ and Benoit. You could ask, and try > engaging them further on the question. On re-thinking this, I'll say two things: 1. 2119 also allows MUST "to limit behavior which has potential for causing harm." One thing we're saying is that if you don't do this right, it's likely to cause harm in some significant way -- having a (wrong) replyable address, otherwise misleading the user, whatever. I think MUST is justified on those grounds. 2. If the WG really *are* saying that these two algorithms are just examples, and you can roll your own, taking this from this and that from that, and making things up on your own (like Franck's idea of just reserving a bogus local-part and leaving the domain alone)... then I think I *agree* with Russ that there's no reason to make these two Standards Track. But I don't think that's what the WG are saying. We spent a lot of time engineering these quite carefully, and there's a reason we had to do that. The message is (and should be), "Don't try this at home." Barry From johnl@iecc.com Thu Sep 27 22:46:04 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C89C21F8512 for ; Thu, 27 Sep 2012 22:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.193 X-Spam-Level: X-Spam-Status: No, score=-111.193 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1NjhFITZNgz for ; Thu, 27 Sep 2012 22:46:03 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C34C621F8504 for ; Thu, 27 Sep 2012 22:46:02 -0700 (PDT) Received: (qmail 10784 invoked from network); 28 Sep 2012 05:46:00 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Sep 2012 05:46:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50653998.xn--30v786c.k1208; i=johnl@user.iecc.com; bh=LIpjk7MJD8F4iLpWRWrByzIGcyJZckZeZzoORxeSdNg=; b=ubSMHoevYiLNjUAuW8N3kLYO9KHl5ahy2iiKLOxbibPVmmStNSEaKDsV5tMlYnnjMcm1qaM/E+XL6wPcVUxcc9DDOZLL2ik8zMUpIcfFA02UXe03fBSZLmbav0xZu8PrthFMGKL68oHnZDDrN6X15TCLVQCEX3kQkP9uZ1p4s6A= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50653998.xn--30v786c.k1208; olt=johnl@user.iecc.com; bh=LIpjk7MJD8F4iLpWRWrByzIGcyJZckZeZzoORxeSdNg=; b=RFBmNPX3QIkR0lVvoPip+CMRUsO4R8nnBdsB3Zx2SLbCY0lmP8R557WIR2q1VgcWsM+JKhKkn7JosoxGX+nKp1fQng5WLihLyGbo1qvzbFev3lpGWaeZTW6wGt76GNL/eVQUZ+ETXp4csXcvEw2s1cAqMS30vCcDk9qULloa3b8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 28 Sep 2012 05:45:38 -0000 Message-ID: <20120928054538.90973.qmail@joyce.lan> From: "John Levine" To: ima@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: barryleiba@computer.org Subject: Re: [EAI] Results of the IESG telechat with respect to the four EAI documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 05:46:04 -0000 >I understand your reasons. I don't know if a "SHOULD use a standard >algorithm" would satisfy Russ and Benoit. You could ask, and try >engaging them further on the question. I prefer SHOULD, but not enough to get into a fight with Russ and Benoit. Since SHOULD roughly means "MUST unless you're sure you know what you're doing", that seems appropropriate. It is true that we spent a long time thinking about this, and there are plenty of superficially plausible approaches that turn out to have serious problems, so they're right that you shouldn't make up something at random. R's, John From klensin@jck.com Thu Sep 27 23:49:17 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6230621F851B for ; Thu, 27 Sep 2012 23:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ie-Z7f-+E2Dh for ; Thu, 27 Sep 2012 23:49:16 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9277521F84A2 for ; Thu, 27 Sep 2012 23:49:16 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1THUNt-000GS3-6e; Fri, 28 Sep 2012 02:49:13 -0400 Date: Fri, 28 Sep 2012 02:49:08 -0400 From: John C Klensin To: Barry Leiba Message-ID: <93ED76682752B11FE63F2266@JcK-HP8200.jck.com> In-Reply-To: References: <31785012C2415E9046E66550@JcK-HP8200.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 Cc: eai-chairs@tools.ietf.org, draft-ietf-eai-rfc5721bis.all@tools.ietf.org, draft-ietf-eai-5738bis.all@tools.ietf.org, draft-ietf-eai-simpledowngrade.all@tools.ietf.org, ima@ietf.org, draft-ietf-eai-popimap-downgrade.all@tools.ietf.org Subject: Re: [EAI] Results of the IESG telechat with respect to the four EAI documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 06:49:17 -0000 --On Friday, September 28, 2012 01:17 -0400 Barry Leiba wrote: >>> As Pete and I discussed briefly on Jabber during the >>> telechat, I think "MUST use a standard algorithm" is >>> inappropriate for at least two reasons: >> >> I understand your reasons. I don't know if a "SHOULD use a >> standard algorithm" would satisfy Russ and Benoit. You could >> ask, and try engaging them further on the question. > > On re-thinking this, I'll say two things: > > 1. 2119 also allows MUST "to limit behavior which has > potential for causing harm." One thing we're saying is that > if you don't do this right, it's likely to cause harm in some > significant way -- having a (wrong) replyable address, > otherwise misleading the user, whatever. I think MUST is > justified on those grounds. Sure. "MUST be careful", "MUST not screw up", "MUST protect the client from receiving anything that does not conform to the base POP or IMAP specs at least as far as headers are concerned" would all be appropriate statements to "limit behavior... harm". "MUST run only protocols that have received the IETF seal of approval" is nonsense unless you believe that the IETF have a inherent monopoly on quality specifications in this area. It also requires you to believe that, e.g., popimap-downgrade will be safer two months from now (or whenever it is approved and then published) than it is today despite absolutely no change in the specification itself. The latter possibly takes us out of the "stamp of approval" regime and into a regime in which one believes that the IETF anoints protocols and that the anointment process gives them extra magical powers (or at least safety properties). > 2. If the WG really *are* saying that these two algorithms are > just examples, and you can roll your own, taking this from > this and that from that, and making things up on your own > (like Franck's idea of just reserving a bogus local-part and > leaving the domain alone)... then I think I *agree* with Russ > that there's no reason to make these two Standards Track. But I didn't say a word about "making things up on your own". Franck's idea isn't present in ether spec, so using it would not be conformant in the synthesis model I am suggesting. Backing up a step, there is a protocol the WG did not decide to write up. Let's call it "flexible downgrade" to contrast it with "simple downgrade" and "maximum information preservation downgrade" (aka popimap-downgrade). From a 10,000 foot level, it soul contain a collection of operations, just like popimap-downgrade does today but also including the operations that appear in/for simpledowngrade. Then, much like popimap-downgrade, it would have a case for each relevant header fields (or group of them). The case would say "for this header field, either do or perform ... as in "you MUST do one or the other for that header field type". There are several reasons why such a spec would be a bad idea, but let's ignore them for the present. Suppose that spec had been written. We could then either lose the standalone simpledowngrade and popimap-downgrade specs entirely or convert them into profiles (e.g., "simpledowngrade" would be defined as "always pick column A" and popimap-downgrade would be defined as "always pick column B". One spec, no competing standards, two profiles but not bar on creating more. We wouldn't be having this conversation because there wouldn't be competing specs and, while I wouldn't be happy with it, I could tolerate a MUST for the spec because it would generate all of the surrogate message cases we have evaluated and have reason to believe are ok. > But I don't think that's what the WG are saying. We spent a > lot of time engineering these quite carefully, and there's a > reason we had to do that. The message is (and should be), > "Don't try this at home." Agreed. What we are quibbling about is the meaning of "this". And a SHOULD allows for the difference between "if anyone tries this, ever, the IETF deity will strike you with its thunderbolts" and "you shouldn't try this unless you are a professional driver and 'home' is a closed track". john From dhc@dcrocker.net Fri Sep 28 10:51:05 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A821721F855B for ; Fri, 28 Sep 2012 10:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-gNyOISqVKo for ; Fri, 28 Sep 2012 10:51:04 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 117A121F8523 for ; Fri, 28 Sep 2012 10:51:04 -0700 (PDT) Received: from [192.168.1.8] (ppp-67-124-89-127.dsl.pltn13.pacbell.net [67.124.89.127]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q8SHotXf028942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 28 Sep 2012 10:50:56 -0700 Message-ID: <5065E36C.8010608@dcrocker.net> Date: Fri, 28 Sep 2012 10:50:36 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 28 Sep 2012 10:50:58 -0700 (PDT) Cc: eai-chairs@tools.ietf.org, draft-ietf-eai-rfc5721bis.all@tools.ietf.org, draft-ietf-eai-5738bis.all@tools.ietf.org, draft-ietf-eai-simpledowngrade.all@tools.ietf.org, ima@ietf.org, draft-ietf-eai-popimap-downgrade.all@tools.ietf.org Subject: Re: [EAI] Results of the IESG telechat with respect to the four EAI documents X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 17:51:05 -0000 On 9/27/2012 5:15 PM, Barry Leiba wrote: > ---------------------------------------------------------------- > draft-ietf-eai-5738bis, Section 7 ... > NEW > Choices available to the server when a message that requires SMTPUTF8 > is encountered and the client doesn't enable UTF-8 capability include > hiding the problematic message(s), creating in band or out of band > notifications or error messages, or somehow trying to create a > variation on the message with the intention of providing useful > information to that client about what has occurred. > > In creating a variant message, it is important to use an algorithm > that has been carefully engineered to present useful information to > the user, while not creating security or operational problems in the > mail system. For this reason, implementations that choose this > option MUST use a standard algorithm. Two such standard algorithms > are introduced in the next paragraph. > > Such variant messages cannot be actual substitutes for the original > message: [...etc...] The haggling over must vs. should is not irrelevant, but there's a deeper problem with the proposed solution: It uses the word 'standard' as a kind of magic handwave, rather than a precise, technical (or process) term: "implementations that choose this option MUST use a standard algorithm". What does that mean? So, the text defines a criterion ("present useful information to the user, while not creating security or operational problems") but no basis for determining what algorithms satisfy it and what don't AND no on-going process for registering algorithms deemed worthy. Hence, it is not possible to know whether the normative condition has been satisfied. > draft-ietf-eai-popimap-downgrade, Section 1.2 ... > NEW > 2. The message may be downgraded by the POP or IMAP server, in a > standard way that preserves maximum information at the expense of > some complexity, and does not create security or operational > problems in the mail system. same problem My suggestion is to drop the word standard, define a registry and make adding entries to it carry the Specification Required condition. (Feel free to argue for any of the more-stringent conditions; I'm merely suggesting the lowest process bar that makes sense to replace the word 'standard'.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From tss@iki.fi Sun Sep 30 06:26:32 2012 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B97421F862B for ; Sun, 30 Sep 2012 06:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.52 X-Spam-Level: X-Spam-Status: No, score=-109.52 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhiciNbofVsF for ; Sun, 30 Sep 2012 06:26:31 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 269A621F856F for ; Sun, 30 Sep 2012 06:26:31 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 9702B1AE87E6; Sun, 30 Sep 2012 16:26:29 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Sun, 30 Sep 2012 16:26:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2F437CEF-D1BB-42DF-BB0F-650D3E20A868@iki.fi> References: <505390CE.8070502@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: IETF EAI Subject: Re: [EAI] 5738bis X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 13:26:32 -0000 OK, finally feeling energetic enough today to answer this mail :) On 15.9.2012, at 23.55, Alexey Melnikov wrote: >>>>> The "UTF8=3DONLY" capability permits an IMAP server to advertise = that >>>>> it does not permit the international mailbox name convention >>>>> (modified UTF-7), >>>> This doesn't really sound like what "design rationale" section = talks about UTF8=3DONLY. Isn't the idea simply to behave as if client = has done ENABLE UTF8=3DACCEPT (which may or may not happen to work with = current clients)? >>>=20 >>> No, I think the idea is to advertise that modified UTF-7 is not = supported. >>=20 >> If that's the only reason for UTF8=3DONLY it seems a rather wasteful = capability. A server that doesn't bother to implement mUTF7, but does = bother to implement other kinds backwards compatibility seems rather = unlikely to me. >=20 > I think the idea was that everybody would implement UTF8=3DONLY and = UTF8=3DACCEPT goes away and can be obsoleted. >>=20 >> The text in design rationale section talks that in future everyone = would be using UTF8 capable clients and servers and all the old = compatibility code could be removed. Wouldn't it make much more sense = for UTF8=3DONLY to mean that the server has no more such compatibility = code? (Basically my idea about assuming client has done ENABLE = UTF8=3DACCEPT.) >=20 > Can you suggest some text, I am not yet sure what exactly you are = suggesting. I'm hoping to avoid having to implement the message downgrading. Has = anyone tried various IMAP clients what they do if they are already being = fed UTF8 headers and LIST reply? My guess is that they will handle it = pretty well. So I'm thinking that the differences between UTF8=3DACCEPT = vs. UTF8=3DONLY are: * APPEND: UTF8=3DACCEPT requires UTF8 parameter for UTF8 headers, = UTF8=3DONLY doesn't. Downgrading not needed, since APPEND can simply = fail with NO. * FETCH BODY[], BODY[HEADER], etc: Non-UTF8 enabled client is tricky, = but with UTF8=3DONLY the headers can be sent as-is always. * FETCH BODY/BODYSTRUCTURE/ENVELOPE: Semi-easy to convert everything(?) = for non-UTF8 enabled client. With UTF8=3DONLY just send as-is. * LIST: Trivial to convert mailbox names to mUTF7 for non-UTF8 enabled = clients. With UTF8=3DONLY always send as UTF8. So only mentioning that UTF8=3DONLY affects LIST reply isn't enough. And = if my UTF8=3DONLY understanding is correct, all of those commands behave = identically with UTF8=3DACCEPT enabled client and non-UTF8 enabled = UTF8=3DONLY server. So that's why I'm suggesting simply to change this: > The "UTF8=3DONLY" capability permits an IMAP server to advertise that > it does not permit the international mailbox name convention > (modified UTF-7), to: The "UTF8=3DONLY" capability permits an IMAP server to advertise that it = does not support legacy clients anymore, but behaves as if the client = had issued ENABLE UTF8=3DONLY command immediately after connect. This = also means that when a client detects the UTF8=3DONLY capability, there = is no need for it to even send the ENABLE UTF8=3DONLY command.=