From nobody Mon Nov 7 19:25:45 2016 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 7D1F9129490; Mon, 7 Nov 2016 19:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oZaMlanucHE; Mon, 7 Nov 2016 19:25:41 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AAD1126D74; Mon, 7 Nov 2016 19:25:41 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1c3x2U-000IJN-GW; Mon, 07 Nov 2016 22:25:34 -0500 Date: Mon, 07 Nov 2016 22:25:29 -0500 From: John C Klensin To: ned+ietf@mauve.mrochek.com, Dave Crocker Message-ID: In-Reply-To: <01Q71GG3KUM8011H9Q@mauve.mrochek.com> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> <5FA03832-D38F-47F2-B974-7C903C7513FD@fugue.com> <713098835.18678872.1478547678821.JavaMail.zimbra@peachymango.org > <969d43d4-78c9-6e44-e186-ca6ed6fa3445@dcrocker.net> <01Q71GG3KUM8011H9Q@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: ima@ietf.org, dmarc@ietf.org, IETF , Terry Zink , Franck Martin Subject: Re: [EAI] [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 03:25:43 -0000 (adding the EAI list to the distribution -- there are people who hang out there who need to see, and check on, this) --On Monday, November 07, 2016 15:08 -0800 ned+ietf@mauve.mrochek.com wrote: >> Absent that, there's the small question about how the EAI >> group would have the authority to make such a major change to >> such a basic email feature... > > RFC 6854 can speak for itself as to the rationale for allowing > no address. > > The EAI connection was, as I recall, for use in downgrade > formats used to > present EAI messages to non-EAI clients via POP3 and IMAP4. Yes. IIR, 6854 was written the way it was in order to avoid getting tangled up with normative dependencies on the EAI specs. However, I find the combination of its Section 3 ("Applicability Statement") and Security Considerations rather clear as to both the motivation and the "don't do this if you don't need to and especially don't originate a message with this" advice. "Limited Use" is really very restrictive. The problem (and tradeoff) are as follows: A message gets delivered and gets as far as a mailstore with a backward-pointing address that looks like: "Non ASCii Name Phrase" Note that, if the message got that far, the delivery MTA advertised itself as fully SMTPUTF8-complaint. Then a POP or IMAP client comes along that does not support non-ASCII addresses or headers. Now, there are probably three plausible choices for the IMAP server (other than just dying a horrible death): (a) Trash the message on the theory that any users who would get themselves into that situation deserve it. However, remember the important case is a backward-pointing address and, in the general case, the delivery server doesn't know what client(s) the user is going to use (and there might be more than one). (b) Figure out how to respond to any IMAP request that involves that message with some flavor of "I have this message for you, but you can't get it and I can't tell you about it until you show up with an upgraded client". (c) Convert "Non ASCii Name Phrase" to encoded words and then do something unpleasant to the address, of which using group syntax was by far the least problematic solution anyone could come up with. If the Return-path in the mailstore is the same as the address in the "From:" and/or "Sender:" header fields, it is going to be trashed, so a competent IMAP server doing this is going to figure out how to warn the user and the user, perhaps after consulting support personnel the first time one of these happens to her, is going to figure out that doing anything with the message other than broadly getting its gist is going to require using an upgraded client. IIR, these issues are discussed at some length in RFCs 6855-6858. Now, coming back to the "identification of ... author" problem and remembering the "Limited Use" bit, if I were designing a submission server and something reached me with a group name in the "From:" (or "Sender:") field, I'd probably return it to whence it came. I'd probably do the same thing if I were a relay or delivery server, noting that there is no equivalent to group syntax in SMTP. Both are entirely consistent with Limited Use -- if one uses it in a context in which it makes no sense or poses a security threat, one refuses to accept it. If anyone things that needs to be said more clearly in one of the EAI-related documents and wants to suggest language, I, and I assume others, anxiously await an I-D. john From nobody Tue Nov 8 11:12:17 2016 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 33DB1129A68 for ; Tue, 8 Nov 2016 11:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dqd3b4NEC0H7 for ; Tue, 8 Nov 2016 11:12:14 -0800 (PST) Received: from nm44-vm6.bullet.mail.gq1.yahoo.com (nm44-vm6.bullet.mail.gq1.yahoo.com [67.195.87.29]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC6D129D92 for ; Tue, 8 Nov 2016 11:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1478632330; bh=2kqDZg1FmQoT1GNi1R3Rb4kQb6YGzRtjg8EHHIVjE4Y=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=NrJLZlv4sEqqrDzn+5jRzllStP2ERxhvvhddI80ccp5PNhBIU5Id+Y7GQ9j2IWbu3QdYTp/Mb9faOwjjjJlf+wNAqrMU5X4KtoXmvCDZAxLGCJmVWxJS4076b5dLwgAwWXRI17KkYosZDVB8VujRKb4uxJiVhLmfo8k7Yi8NHvVx2b1ILceDGZpMCE/Ih6D700u1ncQ5ZxhjtPxWFuk0RE7/ALnQjZX5rdLyoKacIoPgqx0fAbVk+Qfp7lrv1FshpRKh2k1sLy39uVzYU1d/NKaQ0Gjwk+62NwZPSBCcjYAD0lGI2oYex/v7fTv789KUX9jFoh2HtDGba9lqKmYHFA== Received: from [127.0.0.1] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 08 Nov 2016 19:12:10 -0000 Received: from [98.137.12.175] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 08 Nov 2016 19:09:09 -0000 Received: from [98.137.12.224] by tm14.bullet.mail.gq1.yahoo.com with NNFMP; 08 Nov 2016 19:09:09 -0000 Received: from [127.0.0.1] by omp1032.mail.gq1.yahoo.com with NNFMP; 08 Nov 2016 19:09:09 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 112872.69288.bm@omp1032.mail.gq1.yahoo.com X-YMail-OSG: pNRkbAYVM1m7mjHRQWLhW9SrtUn7peX37yA4Nejqj23wxim3K4yW2Rwy1uyZuB8 HnE1TKQhBtGydR6As04ZEAsv6eWqcrytuBJ2KecBYBIs8sDADz_w8lQ2BCgqj0mbhcav39mJSjo2 lKGt9uFKevsYqLIPDZs67ExmNOv7hou4GKRMEc4R0fMYf3RyseeB4sUpPPWx5LQOfA6gVOzjurJE VyI2yzKUjB4t1F72IqBx5qvNzxb6c95xm0xGLttYp5CYBUIbGGzrlauTI577Vb80Q48NFm_n4Sog 5eM77Zq2qOOdmQ9bg6.gIt8.SL6AU9urHPqTeMcQjcq_Da.EYHSuDawkQ4YDCB_nAlBKp5TPKvPg lhGovUNBZILXulWwkdGaKd2.g4vNa22JX6N7GRRz6Xk7C_pzerThQwc_eGrOWoFiT2GT4stsxlql VKB_UK8A.J8OAKhL9MxScJveQCKG9TSHbbHzHIeUeYrRj2h8REEB8KUV_0I6SzJ2O1SRzn4oN4Kk OmKgkwiy8WtlaS67OZXQEobyRHXOCmGzdzlG7b0WJf2ky1tDKhXc8cRGSVoM8HA-- Received: from jws300045.mail.gq1.yahoo.com by sendmailws144.mail.gq1.yahoo.com; Tue, 08 Nov 2016 19:09:08 +0000; 1478632148.709 Date: Tue, 8 Nov 2016 19:09:08 +0000 (UTC) From: To: "ima@ietf.org" Message-ID: <1903000483.899458.1478632148437@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_899457_1521321061.1478632148435" References: <1903000483.899458.1478632148437.ref@mail.yahoo.com> Archived-At: Cc: Harish Chowdhary Subject: [EAI] Bar BoF : Deployment Issues for IDN / IEA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 19:12:15 -0000 ------=_Part_899457_1521321061.1478632148435 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Guys, We will have a bar bof to discuss deployment issues for IDN / IEA at Studio= 3 on Thursday, =C2=A0Nov. 17th at 8:00am. We are also coordinating with UASG, discussing with i18n, and need to coord= inate with ISOC. =C2=A0 This is very much a multi-stakeholder issue. =C2=A0= And, very complex. Let's go slow and at least try to lay out the various issues and core skill= s needed. WE WILL NOT HAVE REMOTE ACCESS VIA MEETECHO. =C2=A0 So, if you want to join= remotely, send me your Skype ID & I will Skype you in. Sorry, apparently, there is no MeetEcho for bar bofs.=C2=A0Thanks, Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360 ------=_Part_899457_1521321061.1478632148435 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Guys,

We will have a bar bof to discuss deployment issues for IDN / IEA at Stu= dio 3 on Thursday,  Nov. 17th at 8:00am.

We are also coordinating with UASG, discus= sing with i18n, and need to coordinate with ISOC.   This is very much = a multi-stakeholder issue.  And, very complex.

Let's go slow and at least try to la= y out the various issues and core skills needed.

WE WILL NOT HAVE REMOTE ACCESS VIA MEET= ECHO.   So, if you want to join remotely, send me your Skype ID & = I will Skype you in.

Sorry, apparently, there is no MeetEcho for bar bofs.
 
Thanks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
------=_Part_899457_1521321061.1478632148435-- From nobody Wed Nov 9 14:18:26 2016 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 BE6B91299BE for ; Wed, 9 Nov 2016 14:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1cj-pkJj_hY for ; Wed, 9 Nov 2016 14:18:09 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA6F1299D7 for ; Wed, 9 Nov 2016 14:18:03 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id q124so32546689itd.1 for ; Wed, 09 Nov 2016 14:18:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MRzqeRAt84MTNg2agjZsxg/Qqvj5TIVqbJZ5tv7GAuM=; b=cwXgmZt1fkO3Ls0N55rP7BLBzmlyPHg0t+LZ/Lrev92jp1MgxmQ2lr41s+vgTPtz0m Mrf1YrTChYr3gD8EFHdpVbNpVVGQBkIWpTXtNNoU3lMCrN1TadBqdDVX+w1I6/bpPqOm jZfH9B5PIxh6k4olnns9x8zDpM5cWw7krgdFiWAwiNegPxs2iPDuiwlBpMineGxnMlke rP3KUsKCNUsarxN/J35nDEWL/0nOMCd41y6tqvdjBAoSMt6jgkhYFqhURNiarMTYPSrl 0xOrpD8qT99V/A0JF0M2Zoaz2rTv5NFAFb88GclJUtjcNJp4RBYxALbbInhsrUio/xHL 9g1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MRzqeRAt84MTNg2agjZsxg/Qqvj5TIVqbJZ5tv7GAuM=; b=ODGWT5odFxmjklYh1O6e9dokSJpHdV5sHy0yaoDuuxJlhatjHsrbJ8KmLN1TM5n8V5 7TVau6nd7NuBGgZn+gdIGhh/2FpPHnKytbDsr5gxgKX+YUeG7XafUJv5lDap7pf0/6NU e9dRETRePfSDy44M++AuYnFuzAhRkn9huIT26u19Ir59YxUlZ4kvXYU1C8xgYFsJb/Uh tyYpZaAxUln2QpDa0nlRbUf0m47lNsQqcpm1eJ64oQTNuvrQW0WpX6luaUPBEWQShoHI mqbhFRK2QS2z17nVg45eHoG9xQJ+lN0vv4zqOvWKkyQ9OI1U2HyEsbd+Tm7O0HQq0ZTq QEJQ== X-Gm-Message-State: ABUngvd07fgSbq/DDT2M8FHj6nceJ1resSEmgndgC1KsXPEfqn6AVpFjGT1dEBsXprdouLF+xkxEJzhDt3X3M3II X-Received: by 10.202.81.5 with SMTP id f5mr1329447oib.24.1478729882422; Wed, 09 Nov 2016 14:18:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Wed, 9 Nov 2016 14:18:00 -0800 (PST) In-Reply-To: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> <5FA03832-D38F-47F2-B974-7C903C7513FD@fugue.com> <969d43d4-78c9-6e44-e186-ca6ed6fa3445@dcrocker.net> <01Q71GG3KUM8011H9Q@mauve.mrochek.com> From: Brandon Long Date: Wed, 9 Nov 2016 14:18:00 -0800 Message-ID: To: John C Klensin Content-Type: multipart/alternative; boundary=001a113d7e885c98020540e5a11a Archived-At: Cc: Dave Crocker , IETF , Franck Martin , ned+ietf@mauve.mrochek.com, "dmarc@ietf.org" , ima@ietf.org, Terry Zink Subject: Re: [EAI] [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 22:18:24 -0000 --001a113d7e885c98020540e5a11a Content-Type: text/plain; charset=UTF-8 I think the EAI discussion took a turn a bit, but my point was: EAI sender sends mail to an EAI capable mailing list which has members which are not EAI capable is a similar scenario to what we're discussing here for DMARC. Ie, in order to resend the message, the choices are: 1) Do nothing and maybe the receiver allows the EAI message despite it not conforming to RFC 5322 and despite the receiving mail server not advertising SMTPUTF8... or maybe it rejects it. 2) Downgrade the message such that everyone on the list receives something, even if not what we'd prefer they receive 3) Don't forward EAI messages to non-EAI capable members 4) Don't accept any EAI messages to the mailing list if there are any non-EAI capable members Now, it turns out that the majority of mail software is probably fine with #1 with some level of degradation, so we're less likely to see #2 than we are in the DMARC case. Even so, at least this is an ability one could probe, so we could know when to downgrade and when not to, theoretically... a mailing list could also interpret DMARC rejects, I guess, and learn when to downgrade and not on a per-recipient basis. I would think that both #3 and #4 are less polite choices, and ditto with applying them to DMARC. In any case, I'm sure the EAI folks discussed what to do in this scenario, but I'm not really discussing whether or not #2 is within spec as much as I'm talking about the better support for your users in an imperfect world and drawing a parallel to DMARC. Brandon On Mon, Nov 7, 2016 at 7:25 PM, John C Klensin wrote: > (adding the EAI list to the distribution -- there are people who > hang out there who need to see, and check on, this) > > --On Monday, November 07, 2016 15:08 -0800 > ned+ietf@mauve.mrochek.com wrote: > > >> Absent that, there's the small question about how the EAI > >> group would have the authority to make such a major change to > >> such a basic email feature... > > > > RFC 6854 can speak for itself as to the rationale for allowing > > no address. > > > > The EAI connection was, as I recall, for use in downgrade > > formats used to > > present EAI messages to non-EAI clients via POP3 and IMAP4. > > Yes. > IIR, 6854 was written the way it was in order to avoid getting > tangled up with normative dependencies on the EAI specs. > However, I find the combination of its Section 3 ("Applicability > Statement") and Security Considerations rather clear as to both > the motivation and the "don't do this if you don't need to and > especially don't originate a message with this" advice. > "Limited Use" is really very restrictive. > > The problem (and tradeoff) are as follows: > > A message gets delivered and gets as far as a mailstore with a > backward-pointing address that looks like: > "Non ASCii Name Phrase" > > Note that, if the message got that far, the delivery MTA > advertised itself as fully SMTPUTF8-complaint. > > Then a POP or IMAP client comes along that does not support > non-ASCII addresses or headers. Now, there are probably three > plausible choices for the IMAP server (other than just dying a > horrible death): > > (a) Trash the message on the theory that any users who would get > themselves into that situation deserve it. However, remember > the important case is a backward-pointing address and, in the > general case, the delivery server doesn't know what client(s) > the user is going to use (and there might be more than one). > > (b) Figure out how to respond to any IMAP request that involves > that message with some flavor of "I have this message for you, > but you can't get it and I can't tell you about it until you > show up with an upgraded client". > > (c) Convert "Non ASCii Name Phrase" to encoded words and then do > something unpleasant to the address, of which using group syntax > was by far the least problematic solution anyone could come up > with. If the Return-path in the mailstore is the same as the > address in the "From:" and/or "Sender:" header fields, it is > going to be trashed, so a competent IMAP server doing this is > going to figure out how to warn the user and the user, perhaps > after consulting support personnel the first time one of these > happens to her, is going to figure out that doing anything with > the message other than broadly getting its gist is going to > require using an upgraded client. > > IIR, these issues are discussed at some length in RFCs 6855-6858. > > Now, coming back to the "identification of ... author" problem > and remembering the "Limited Use" bit, if I were designing a > submission server and something reached me with a group name in > the "From:" (or "Sender:") field, I'd probably return it to > whence it came. I'd probably do the same thing if I were a > relay or delivery server, noting that there is no equivalent to > group syntax in SMTP. Both are entirely consistent with > Limited Use -- if one uses it in a context in which it makes no > sense or poses a security threat, one refuses to accept it. > > If anyone things that needs to be said more clearly in one of > the EAI-related documents and wants to suggest language, I, and > I assume others, anxiously await an I-D. > > john > > --001a113d7e885c98020540e5a11a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the EAI discussion took a turn a bit, but my point= was:

EAI sender sends mail to an EAI capable mailing li= st which has members which are not EAI capable is a similar scenario to wha= t we're discussing here for DMARC.

Ie, in orde= r to resend the message, the choices are:
1) Do nothing and maybe= the receiver allows the EAI message despite it not conforming to RFC 5322 = and despite the receiving mail server not advertising SMTPUTF8... or maybe = it rejects it.

2) Downgrade the message such that = everyone on the list receives something, even if not what we'd prefer t= hey receive

3) Don't forward EAI messages to n= on-EAI capable members

4) Don't accept any EAI= messages to the mailing list if there are any non-EAI capable members

Now, it turns out that the majority of mail software i= s probably fine with #1 with some level of degradation, so we're less l= ikely to see #2 than we are in the DMARC case.=C2=A0 Even so, at least this= is an ability one could probe, so we could know when to downgrade and when= not to, theoretically... a mailing list could also interpret DMARC rejects= , I guess, and learn when to downgrade and not on a per-recipient basis.

I would think that both #3 and #4 are less polite ch= oices, and ditto with applying them to DMARC.

In a= ny case, I'm sure the EAI folks discussed what to do in this scenario, = but I'm not really discussing whether or not #2 is within spec as much = as I'm talking about the better support for your users in an imperfect = world and drawing a parallel to DMARC.

Brandon

On Mon, N= ov 7, 2016 at 7:25 PM, John C Klensin <john-ietf@jck.com> wr= ote:
(adding the EAI list to the distribu= tion -- there are people who
hang out there who need to see, and check on, this)

--On Monday, November 07, 2016 15:08 -0800
ned+ietf@m= auve.mrochek.com wrote:

>> Absent that, there's the small question about how the EAI
>> group would have the authority to make such a major change to
>> such a basic email feature...
>
> RFC 6854 can speak for itself as to the rationale for allowing
> no address.
>
> The EAI connection was, as I recall, for use in downgrade
> formats used to
> present EAI messages to non-EAI clients via POP3 and IMAP4.

Yes.
IIR, 6854 was written the way it was in order to avoid getting
tangled up with normative dependencies on the EAI specs.
However, I find the combination of its Section 3 ("Applicability
Statement") and Security Considerations rather clear as to both
the motivation and the "don't do this if you don't need to and=
especially don't originate a message with this" advice.
"Limited Use" is really very restrictive.

The problem (and tradeoff) are as follows:

A message gets delivered and gets as far as a mailstore with a
backward-pointing address that looks like:
=C2=A0 "Non ASCii Name Phrase" <non-ascii-local-part@domain-part>

Note that, if the message got that far, the delivery MTA
advertised itself as fully SMTPUTF8-complaint.

Then a POP or IMAP client comes along that does not support
non-ASCII addresses or headers.=C2=A0 =C2=A0Now, there are probably three plausible choices for the IMAP server (other than just dying a
horrible death):

(a) Trash the message on the theory that any users who would get
themselves into that situation deserve it.=C2=A0 However, remember
the important case is a backward-pointing address and, in the
general case, the delivery server doesn't know what client(s)
the user is going to use (and there might be more than one).

(b) Figure out how to respond to any IMAP request that involves
that message with some flavor of "I have this message for you,
but you can't get it and I can't tell you about it until you
show up with an upgraded client".

(c) Convert "Non ASCii Name Phrase" to encoded words and then do<= br> something unpleasant to the address, of which using group syntax
was by far the least problematic solution anyone could come up
with.=C2=A0 If the Return-path in the=C2=A0 mailstore is the same as the address in the "From:" and/or "Sender:" header fields, = it is
going to be trashed, so a competent IMAP server doing this is
going to figure out how to warn the user and the user, perhaps
after consulting support personnel the first time one of these
happens to her, is going to figure out that doing anything with
the message other than broadly getting its gist is going to
require using an upgraded client.

IIR, these issues are discussed at some length in RFCs 6855-6858.

Now, coming back to the "identification of ... author" problem and remembering the "Limited Use" bit, if I were designing a
submission server and something reached me with a group name in
the "From:" (or "Sender:") field, I'd probably retu= rn it to
whence it came.=C2=A0 =C2=A0 I'd probably do the same thing if I were a=
relay or delivery server, noting that there is no equivalent to
group syntax in SMTP.=C2=A0 =C2=A0Both are entirely consistent with
Limited Use -- if one uses it in a context in which it makes no
sense or poses a security threat, one refuses to accept it.

If anyone things that needs to be said more clearly in one of
the EAI-related documents and wants to suggest language, I, and
I assume others, anxiously await an I-D.

=C2=A0 =C2=A0john


--001a113d7e885c98020540e5a11a-- From nobody Wed Nov 16 14:37:12 2016 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 42D301293EB for ; Wed, 16 Nov 2016 14:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDmxld8NHOwH for ; Wed, 16 Nov 2016 14:37:08 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A8D1295BD for ; Wed, 16 Nov 2016 14:37:07 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1c78pF-0001CO-8T; Wed, 16 Nov 2016 17:37:05 -0500 Date: Wed, 16 Nov 2016 17:37:00 -0500 From: John C Klensin To: nalini.elkins@insidethestack.com Message-ID: <1705827F6F9D71410BCC000C@JcK-HP8200> In-Reply-To: <1903000483.899458.1478632148437@mail.yahoo.com> References: <1903000483.899458.1478632148437.ref@mail.yahoo.com> <1903000483.899458.1478632148437@mail.yahoo.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Harish Chowdhary , ima@ietf.org Subject: Re: [EAI] Bar BoF : Deployment Issues for IDN / IEA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 22:37:11 -0000 Nalini, You indicated during the IAB I18n Program meeting that you would be using an ICANN AdobeConnect account for this meeting, but have not, AFAICT, circulated connection details. The note below says Skype (and I've sent you an ID as requested). Which is it and, if it is the former, where do we find those details? best, john --On Tuesday, November 08, 2016 19:09 +0000 nalini.elkins@insidethestack.com wrote: > Guys, > We will have a bar bof to discuss deployment issues for IDN / > IEA at Studio 3 on Thursday, =C2=A0Nov. 17th at 8:00am. We are > also coordinating with UASG, discussing with i18n, and need to > coordinate with ISOC. =C2=A0 This is very much a = multi-stakeholder > issue. =C2=A0And, very complex. Let's go slow and at least try = to > lay out the various issues and core skills needed. WE WILL NOT > HAVE REMOTE ACCESS VIA MEETECHO. =C2=A0 So, if you want to = join > remotely, send me your Skype ID & I will Skype you in. Sorry, > apparently, there is no MeetEcho for bar bofs.=C2=A0Thanks, = Nalini > ElkinsInside Products, Inc.www.insidethestack.com(831) = 659-8360 From nobody Wed Nov 16 14:41:00 2016 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 2933712957B for ; Wed, 16 Nov 2016 14:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyRkUBM77FfU for ; Wed, 16 Nov 2016 14:40:58 -0800 (PST) Received: from smtp104.biz.mail.gq1.yahoo.com (smtp104.biz.mail.gq1.yahoo.com [98.137.12.179]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D82A1295AA for ; Wed, 16 Nov 2016 14:40:57 -0800 (PST) Received: (qmail 36147 invoked from network); 16 Nov 2016 22:40:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1479336056; bh=aVza2Q67YgOtoRfAlnPdFUt41cCur0kaK6DAR0L70tA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To; b=BThQ40pQby34NJ9RG2euH2khgj1vW/aR/aPrpP1W566bQZPRfD4jP/5Fn+Mm8roz11g89DK8eIWuPzklCp+zq8vRtWccRgf5F/j79yIe0D+ncAmT1S2Ta5LEQn4YPq0IoF0gOzX7B/jTycdXCWjRB2LnXxO+Sz5yg/WZJbTVYNU= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: KA2VLcwVM1mE.WmIrM_IMX.R84EvQ.Mp0zcg7bp61w0IZpg M9HgEl5Th.HjJU6K2pdzBMC4Y8m3NEBubF7qgkItIVs3J0iLeVBW00RKY_qC _XyLl3rPKz7mt5zmCpG2XPvL0ZQ5LI5NvufHnYYJ4TvEv0MKtwJ3KqgDTNFI 8CUqBgvEAi7zyXS42DfOmE_75BI3iHE04Ew4p1TnT7Whkz7KO.N.y3y4bbVh GCEIRL2j_Nvwj6NBVf2KAwOTSEEhe3fuqmUe4Oo1rMR3DBcwkfNsYPSojh8K ZFPoOfn5tIgMqpVIdY.GuC.QexnKiSEjSdm1VkjeuBs8Dj8KjKi.4zRARmk_ A248Hsu64y8nfap6yp5CWNe6kbQSzC3GSOOjU8xZ3BqIf0sZQ6Dhpbb3jmtf 9HoKqpPfOEnM_Zp2T_kFL3h0fpzR0OxNcx7O_fMJo7wHV9lcc78Y9bCJC4Wf _9sL15CpHSM7fTpqJj.GEgBTrkwiMvN3A_Eet2XmzhUQLHNZhfmplG0IL4OM ftcaNEcy7mr6sVveGVHoCE4V_bbMG3Kv6DcgSA9N5PuEwAGvlYVLl9HuXHfK Wq6gKviwCf_cblew5 X-Yahoo-SMTP: kqLn9h2swBBD0bOrAvWavgJF7WhZWryL8jA- Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Nalini Elkins X-Mailer: iPhone Mail (13G36) In-Reply-To: <1705827F6F9D71410BCC000C@JcK-HP8200> Date: Thu, 17 Nov 2016 07:40:53 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4D13E63C-DAF7-4655-B9E1-6FD89336531A@insidethestack.com> References: <1903000483.899458.1478632148437.ref@mail.yahoo.com> <1903000483.899458.1478632148437@mail.yahoo.com> <1705827F6F9D71410BCC000C@JcK-HP8200> To: John C Klensin Archived-At: Cc: Harish Chowdhary , ima@ietf.org Subject: Re: [EAI] Bar BoF : Deployment Issues for IDN / IEA X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 22:40:59 -0000 We will use Skype. Sorry for the confusion. I just tried to call you to te= st. Nalini=20 Sent from my iPhone > On Nov 17, 2016, at 7:37 AM, John C Klensin wrote: >=20 > Nalini, >=20 > You indicated during the IAB I18n Program meeting that you would > be using an ICANN AdobeConnect account for this meeting, but > have not, AFAICT, circulated connection details. The note below > says Skype (and I've sent you an ID as requested). Which is it > and, if it is the former, where do we find those details? >=20 > best, > john >=20 >=20 > --On Tuesday, November 08, 2016 19:09 +0000 > nalini.elkins@insidethestack.com wrote: >=20 >> Guys, >> We will have a bar bof to discuss deployment issues for IDN / >> IEA at Studio 3 on Thursday, Nov. 17th at 8:00am. We are >> also coordinating with UASG, discussing with i18n, and need to >> coordinate with ISOC. This is very much a multi-stakeholder >> issue. And, very complex. Let's go slow and at least try to >> lay out the various issues and core skills needed. WE WILL NOT >> HAVE REMOTE ACCESS VIA MEETECHO. So, if you want to join >> remotely, send me your Skype ID & I will Skype you in. Sorry, >> apparently, there is no MeetEcho for bar bofs. Thanks, Nalini >> ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360 >=20 >=20 >=20 >=20