From nobody Tue Mar 24 17:16:34 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F223A1A1BC2 for ; Tue, 24 Mar 2015 17:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 H2qAhqpF1z92 for ; Tue, 24 Mar 2015 17:16:31 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 6601E1A1BBC for ; Tue, 24 Mar 2015 17:16:31 -0700 (PDT) Received: by oigv203 with SMTP id v203so8360281oig.3 for ; Tue, 24 Mar 2015 17:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/0f9NZrgxyqnx6YuMipSWHb3KTrIVm9VO1qu/0EvNVQ=; b=csY4jrt5xSFTrSpd61dXmFEIiQLnJn+w67+jiMIxyK1eGQi9j3u5Kxvl5mFS82tulb EN9UMCR9netDWlrpJVJLf9vbqwL5krsmoEOhxiw2on6VTAKRwfSeiMnxI35c+qLY9owT uYE9d99DD0PjStfVdbvhdyD+8nxcopA1n8642GoT8+l/YYc6WXCPlPhx/hfszlKB0qK+ EyjmX4utywb548NRGcDJuhrtGP4nZRyYZXrNBD7WVPsCumtm0k0LuRtiBfqTqMMC7Nhb ecmMxG2afSNmqp+A6/Q6sA9X0tlbvQOz/FzNP2mXfyK2HSxZlgk/rQ0z1oA8GL74mTxk Vb7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=/0f9NZrgxyqnx6YuMipSWHb3KTrIVm9VO1qu/0EvNVQ=; b=nGAgc6Yv4lKZljpIn0WXoyDDGB/1ZX07f4NLZ+7O60u/rkOc0uyJFOWBaZVKMLONkY NGf0kWQ+ULL2w7Yzd0VumOOoKgIO51YGzxkfd/wL8eZ5PiGdrsUNnYEDAPLptdOu66mY pziKwOHs10onxGqf7fUClSw1CTccfhExcp28fl64oUogBY+NiRyxWSRZ0IBEssp1TzC0 2jf+KG3CIucKswE+RZ7ZHD9aHtg3KZy0bUNLZRubYH11KYRbQrkj70jEWRHmgHve2q+U x6MV7YyvTIb+7631n4i0p+BicCyN9VtW2Em3AZhf4U6URtd4qohqscgvvnWPoAGcuH17 +25w== X-Gm-Message-State: ALoCoQn8JKXZVsx4Zx01iMpLSquF9u4vqF6MXQLyt+nTCLDTSqVKU4lnNOyn/SyBcHueA0TqYzHQ MIME-Version: 1.0 X-Received: by 10.202.205.146 with SMTP id d140mr4956200oig.35.1427242590864; Tue, 24 Mar 2015 17:16:30 -0700 (PDT) Received: by 10.202.98.85 with HTTP; Tue, 24 Mar 2015 17:16:30 -0700 (PDT) Date: Tue, 24 Mar 2015 17:16:30 -0700 Message-ID: From: John Bucy To: ima@ietf.org Content-Type: multipart/alternative; boundary=001a1134e69aa3579c051211cffd Archived-At: Subject: [EAI] SMTPUTF8 for non EAI messages X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 00:16:33 -0000 --001a1134e69aa3579c051211cffd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is a spillover from a discussion on dmarc@ http://www.ietf.org/mail-archive/web/dmarc/current/msg02239.html Has the wg considered the case of using SMTPUTF8 as a means to avoid 2047/2231 encoding for messages that don't contain any eai addresses? I understand eai avoids downgrading since it doesn't really work for addr-spec but it seems like it should be harmless for places where encoded-word is allowed along the lines of the "gateway transformation" described in 6152. cheers john --001a1134e69aa3579c051211cffd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
This is a spillover from a discussion on dmarc@

Has the wg considered the case of using SMTPUTF8 as a means to avoid 2047/2231 encoding for messages that don't contain any eai addresses? I understand eai avoids downgrading since it doesn't really work for addr-spec but it seems like it should be harmless for places where encoded-word is allowed along the lines of the "gateway transformation" described in 6152.


cheers
john
--001a1134e69aa3579c051211cffd-- From nobody Wed Mar 25 00:58:35 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424941ACDE7 for ; Wed, 25 Mar 2015 00:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 bxCN8F4lcrVc for ; Wed, 25 Mar 2015 00:58:33 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B6A91ACE02 for ; Wed, 25 Mar 2015 00:58:31 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 57B9FFA00B3; Wed, 25 Mar 2015 07:58:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1427270309; bh=WhT7j5Rc5U4/AyXF4tTPGiiorRWl7nEFxtAdZXhrDuU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SicnlqQz6yos9dt4uXTPETjzprsHZgP+0e45RliuTGZ1SOsmY1SRDrvj+Q4QFzL1V GdXwUfNHZbiRVFnzZWXltu7pnbny92Si00YuvxxHtHCKMfptrdqbPVcMoDRvQ0zH6+ 1RaDNhMegfJRPjOSqW6XPk8FsbUJ8WJNsb3C+fMY= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1427270308-31136-31135/12/3; Wed, 25 Mar 2015 07:58:28 +0000 From: Arnt Gulbrandsen To: ima@ietf.org Date: Wed, 25 Mar 2015 08:58:20 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Ubuntu 14.04.2 LTS Mime-Version: 1.0 Message-Id: <5cae1bbd-01dc-4052-80aa-bf9bee813859@gulbrandsen.priv.no> In-Reply-To: References: Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [EAI] SMTPUTF8 for non EAI messages X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 07:58:34 -0000 A SMTPUTF8 message doesn't have to contain EAI addresses, if you care only about to the formal grammar. Just like for 822 mail, just a From and a Date field is enough. Subject, message-id, body text, all those things are optional in a formal sense. RFC6531 bottom of page 4 and top of page 5, and the first 3-4 paragraphs of 6532 section 3. The restriction is rather a practical one: If you're sending from an ASCII address to an ASCII address, then restricting yourself to all-SMTPUTF8 paths is chancy. Too chancy to bother with, IMO, since MIME encoders and parsers are ubiquitous. Arnt From nobody Wed Mar 25 12:46:02 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FA51A6EFB for ; Wed, 25 Mar 2015 12:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 wbzahVAqoL2n for ; Wed, 25 Mar 2015 12:45:59 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 66DB61A8A8F for ; Wed, 25 Mar 2015 12:45:59 -0700 (PDT) Received: by oicf142 with SMTP id f142so21880097oic.3 for ; Wed, 25 Mar 2015 12:45:59 -0700 (PDT) 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; bh=GZDklfx1BRnk7vF7fMyhWhHYBJEFKZIhxb7iZPa6oOM=; b=WR+2PlEaZnSQhTguHg84Wp3/DjeKfD0YVAmRY+j9Z/6qvTGQGk5fg+4ogfND8jx9KI quq7uxHibsCvUrpT7T025z+HHVGmh/rJrUs7OJANYZMhZCaV2Ct7dUSNcmy5iMrdgYO1 B6pOX2JhrI81Gb0MES5tP9Gsq269EzLJOahqgEhNS9vI/N/VfH/YXbczudolcV0L2UfI lec38nfuUzOYSSF3Gzm9aDG2TeX9++qFyAeQsHPwwrvw1vi+pgHOfLuTD477Z/gVzOcG yiGSeeiLDEEbGOyN/4Sqmx/uun8YRQ0V/V42Rwyynuk7hbaeu0LDmW5HE9m7g2m+3ttF h52w== 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:date :message-id:subject:from:to:cc:content-type; bh=GZDklfx1BRnk7vF7fMyhWhHYBJEFKZIhxb7iZPa6oOM=; b=KaZN9ZOIOmCCpOrem7MWzOm2ayiWZCNXaQnb0+SLdOv+D+AeZzJQS8IfFs45DzRFrr 2Y0qiiLCpl8kqnvOm/dCcz+o8f5r9AstwykCBCrcGiBiIwjei41A0Hco2TfzZE/qTv0t PqQOKSXUTfnl+v9fK4tjuGvS4JqU76y7XDGCd2F6r5lESA6QrO0Mo/xB3VYd0ufzUC8X m8vqN3Fft4SBO0v7hzrRpdtKIvsfQjYGhYkpOE9sPa7BTGAzhhvVWsIotFozks+RKiAw bUC7Us2QLwNabhvs0WFrbDRlScuAGIzY2aTjgFPUQpOXhBtuqNg9Zes4JYdQ0TvD+hHt OO4w== X-Gm-Message-State: ALoCoQmqb+UFaN1urgPZoAEInaolCtHBFWJ565sYm7mt5r1kGT86wHZTwaAZUwuym8v4l+nadcuR MIME-Version: 1.0 X-Received: by 10.182.20.195 with SMTP id p3mr8793314obe.1.1427312758878; Wed, 25 Mar 2015 12:45:58 -0700 (PDT) Received: by 10.202.98.85 with HTTP; Wed, 25 Mar 2015 12:45:58 -0700 (PDT) In-Reply-To: <5cae1bbd-01dc-4052-80aa-bf9bee813859@gulbrandsen.priv.no> References: <5cae1bbd-01dc-4052-80aa-bf9bee813859@gulbrandsen.priv.no> Date: Wed, 25 Mar 2015 12:45:58 -0700 Message-ID: From: John Bucy To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=e89a8f50316cfa1c5605122225ff Archived-At: Cc: ima@ietf.org Subject: Re: [EAI] SMTPUTF8 for non EAI messages X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 19:46:00 -0000 --e89a8f50316cfa1c5605122225ff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Wed, Mar 25, 2015 at 12:58 AM, Arnt Gulbrandsen wrote: > A SMTPUTF8 message doesn't have to contain EAI addresses, if you care only > about to the formal grammar. Just like for 822 mail, just a From and a Date > field is enough. Subject, message-id, body text, all those things are > optional in a formal sense. RFC6531 bottom of page 4 and top of page 5, and > the first 3-4 paragraphs of 6532 section 3. > > The restriction is rather a practical one: If you're sending from an ASCII > address to an ASCII address, then restricting yourself to all-SMTPUTF8 > paths is chancy. Too chancy to bother with, IMO, since MIME encoders and > parsers are ubiquitous. > > Well, what I was more interested in is how do people feel about downgrade/gateway-transformation in cases not involving addr-spec, where the result is within the bounds of 2047 that pre-eai MUAs already expect to receive. As far as I can tell, the EAI RFCs don't speak to this directly - 6530 says roughly "there's really no good way to downgrade addr spec so we don't do it" - 6531 says a non-msa relay SHOULD reject/bounce if the next hop doesn't support SMTPUTF8 --e89a8f50316cfa1c5605122225ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On Wed, Mar 25, 2015 at 12:58 AM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> wrote:
A SMTPUTF8 message doesn't have to contain EAI addresses, if you care only about to the formal grammar. Just like for 822 mail, just a From and a Date field is enough. Subject, message-id, body text, all those things are optional in a formal sense. RFC6531 bottom of page 4 and top of page 5, and the first 3-4 paragraphs of 6532 section 3.

The restriction is rather a practical one: If you're sending from an ASCII address to an ASCII address, then restricting yourself to all-SMTPUTF8 paths is chancy. Too chancy to bother with, IMO, since MIME encoders and parsers are ubiquitous.


Well, what I was more interested in is how do people feel about downgrade/gateway-transformation in cases not involving addr-spec, where the result is within the bounds of 2047 that pre-eai MUAs already expect to receive. As far as I can tell, the EAI RFCs don't speak to this directly
- 6530 says roughly "there's really no good way to downgrade addr spec so we don't do it"
- 6531 says a non-msa relay SHOULD reject/bounce if the next hop doesn't support SMTPUTF8



--e89a8f50316cfa1c5605122225ff-- From nobody Wed Mar 25 13:00:00 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C211B2ABD for ; Wed, 25 Mar 2015 12:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mfVxvtDTdpYa for ; Wed, 25 Mar 2015 12:59:58 -0700 (PDT) Received: from eat1-mav01.corp.linkedin.com (eat1-mav01.corp.linkedin.com [8.18.31.21]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FA51A89AD for ; Wed, 25 Mar 2015 12:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1427313598; x=1458849598; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=//7AfTprO936m47SLFXUgeDj6DoOFA7/mLwjbt3igFk=; b=MAY/cVVk+afBx0DnkutbdXTe7m0Fo6ybGQo2SZDBFSRT8Yc2Wpodk2Y4 rq3kJMIP2NWqdV+mLvw3sij0kQOjOeSJt5hXU32Aq1QGkxbvj4LnkDv3h QhHMbIp0VaxXwaMVVASxcWaqpA3a/Veeo23DgOUWC9MIawEEaJqeaR6I2 M=; X-IronPort-AV: E=Sophos;i="5.11,466,1422950400"; d="asc'?scan'208,217";a="2842623" Received: from LCA1-HUB06.linkedin.biz (172.29.88.65) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 25 Mar 2015 12:59:55 -0700 Received: from LCA1-MB06.linkedin.biz ([fe80::c4c9:3e19:c9c0:89db]) by LCA1-HUB06.linkedin.biz ([::1]) with mapi id 14.03.0195.001; Wed, 25 Mar 2015 12:59:55 -0700 From: Franck Martin To: John Bucy Thread-Topic: [EAI] SMTPUTF8 for non EAI messages Thread-Index: AQHQZpD4PN/FCqLdFk+76IedrUQEh50tSyEAgADFtgCAAAPmgA== Date: Wed, 25 Mar 2015 19:59:55 +0000 Message-ID: References: <5cae1bbd-01dc-4052-80aa-bf9bee813859@gulbrandsen.priv.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.29.88.247] Content-Type: multipart/signed; boundary="Apple-Mail=_1B13402F-2DAE-4ED1-A3DF-16CC7BE55AAF"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: Arnt Gulbrandsen , "ima@ietf.org" Subject: Re: [EAI] SMTPUTF8 for non EAI messages X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 20:00:00 -0000 --Apple-Mail=_1B13402F-2DAE-4ED1-A3DF-16CC7BE55AAF Content-Type: multipart/alternative; boundary="Apple-Mail=_F3FBFC64-A1BC-4DC6-9104-F0CEC04C0180" --Apple-Mail=_F3FBFC64-A1BC-4DC6-9104-F0CEC04C0180 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 25, 2015, at 12:45 PM, John Bucy wrote: >=20 > On Wed, Mar 25, 2015 at 12:58 AM, Arnt Gulbrandsen = wrote: > A SMTPUTF8 message doesn't have to contain EAI addresses, if you care = only about to the formal grammar. Just like for 822 mail, just a =46rom = and a Date field is enough. Subject, message-id, body text, all those = things are optional in a formal sense. RFC6531 bottom of page 4 and top = of page 5, and the first 3-4 paragraphs of 6532 section 3. >=20 > The restriction is rather a practical one: If you're sending from an = ASCII address to an ASCII address, then restricting yourself to = all-SMTPUTF8 paths is chancy. Too chancy to bother with, IMO, since MIME = encoders and parsers are ubiquitous. >=20 >=20 > Well, what I was more interested in is how do people feel about = downgrade/gateway-transformation in cases not involving addr-spec, where = the result is within the bounds of 2047 that pre-eai MUAs already expect = to receive. As far as I can tell, the EAI RFCs don't speak to this = directly > - 6530 says roughly "there's really no good way to downgrade addr spec = so we don't do it" > - 6531 says a non-msa relay SHOULD reject/bounce if the next hop = doesn't support SMTPUTF8 >=20 It seems fine for the MSA portion of your mail server to convert the = message to have it better transmitted (if the MSA portion of your Mail = Client does not optimize the message for better transmission), but it is = not fine for the MTA portion of your mail server to do this operation. --Apple-Mail=_F3FBFC64-A1BC-4DC6-9104-F0CEC04C0180 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Mar 25, 2015, at 12:45 PM, John = Bucy <jbucy@google.com> = wrote:


On Wed, Mar 25, 2015 at 12:58 AM, Arnt Gulbrandsen = <arnt@gulbrandsen.priv.no> = wrote:
A SMTPUTF8 message = doesn't have to contain EAI addresses, if you care only about to the = formal grammar. Just like for 822 mail, just a =46rom and a Date field = is enough. Subject, message-id, body text, all those things are optional = in a formal sense. RFC6531 bottom of page 4 and top of page 5, and the = first 3-4 paragraphs of 6532 section 3.

The restriction is rather a practical one: If you're sending from an = ASCII address to an ASCII address, then restricting yourself to = all-SMTPUTF8 paths is chancy. Too chancy to bother with, IMO, since MIME = encoders and parsers are ubiquitous.


Well, what I was more interested in = is how do people feel about downgrade/gateway-transformation in cases = not involving addr-spec, where the result is within the bounds of 2047 = that pre-eai MUAs already expect to receive. As far as I can tell, the = EAI RFCs don't speak to this directly
- 6530 says roughly = "there's really no good way to downgrade addr spec so we don't do = it"
- 6531 says a non-msa relay SHOULD reject/bounce if the = next hop doesn't support = SMTPUTF8


It seems fine for the MSA portion of your mail server to convert the = message to have it better transmitted (if the MSA portion of your Mail = Client does not optimize the message for better transmission), but it is = not fine for the MTA portion of your mail server to do this = operation.


= --Apple-Mail=_F3FBFC64-A1BC-4DC6-9104-F0CEC04C0180-- --Apple-Mail=_1B13402F-2DAE-4ED1-A3DF-16CC7BE55AAF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVExO7AAoJEJHd9Bbysc+aLjUH/07jTVjOZUYP2CdFdKZ1N6DE i8CHQZj09JtXl1hyfEVQ3WWVincmV5id90wGXzd94RxX3SsOOwCM3VWVZnT2QU3q RmeE3dx+DEtKQDVzHIaazCg6uCdYFgfVk45Xlbn3D2JGuWXWLr5VPpG2w0mtTbyZ 6er/RHCWP67uxCVTSjQSglyO6QRtxqFgMKvFrlK8zKdcJhJFCktJLvzVOG0R5hoB HWncSXtx4S4bjWfEY1ND9/+DCrZ5oCMSD/mtqbSRqMUoj2WHBCVdPuA9lDf770mh TRv4eMyss+uaAkmGe41gX/AtoTh8g8iUdiWgCsLCPmAZKA0SMxW2xWVYPZTB3sQ= =gile -----END PGP SIGNATURE----- --Apple-Mail=_1B13402F-2DAE-4ED1-A3DF-16CC7BE55AAF-- From nobody Wed Mar 25 13:17:50 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D3F1B2B15 for ; Wed, 25 Mar 2015 13:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham 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 HRywrs6h3Iuf for ; Wed, 25 Mar 2015 13:17:47 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2DA1A8ABB for ; Wed, 25 Mar 2015 13:17:47 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 62E0BFA00B3; Wed, 25 Mar 2015 20:17:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1427314665; bh=YH8kXt/w9mnP4JpLoJbWsA3mJkvkqLbylgoTHbROc3o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Z9kGxLxRKQCyBPHE/KBPetmkhsngXCGdcMqvNrX7gwWILPVBDByni2gHgnt2lLL7D M2DxWv2d9ySCKDaCYfzjwVGMH+JF+aLG9tPH49A1f6dk6TC3zMw8q0wOWxj5sj6gTE 3uXHofQiO9lQUUjsAD1cUAYQV93UI7OB449oZBV0= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1427314664-31136-31135/12/7; Wed, 25 Mar 2015 20:17:44 +0000 From: Arnt Gulbrandsen To: ima@ietf.org Date: Wed, 25 Mar 2015 21:17:43 +0100 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Ubuntu 14.04.2 LTS Mime-Version: 1.0 Message-Id: In-Reply-To: References: <5cae1bbd-01dc-4052-80aa-bf9bee813859@gulbrandsen.priv.no> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [EAI] SMTPUTF8 for non EAI messages X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 20:17:50 -0000 > Well, what I was more interested in is how do people feel about > downgrade/gateway-transformation in cases not involving > addr-spec, [...] I know about no implementations of that so far. But maybe someone will come along and feel that this is something that needs doing for some MTA. Arnt From nobody Wed Mar 25 15:16:52 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861201A8AEA for ; Wed, 25 Mar 2015 15:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dRmGJUTLoQqQ for ; Wed, 25 Mar 2015 15:16:49 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBBC1A895E for ; Wed, 25 Mar 2015 15:16:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PK11LHT68000FLJQ@mauve.mrochek.com> for ima@ietf.org; Wed, 25 Mar 2015 15:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1427321509; bh=cuT49SHuZyqyj4t3COIUmyqFAhmMqXmkoozSYdGd5KM=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=XJGt236KTPGH/Euutr22tUMUhaOXnlaa36QmyuDNTLedLrypHVgD/TXyo0FTeJ1yd lxGBMeiKQy4njNDYFcgTkz4wUSbYjVtkUTu/lBaHx5P8Z9xNhOy340y96Zhlkmhgpp HkRcHr0Ya9BaSwqH9gXURcpRVB6wKFjoJl+l1IvY= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PK11G2XVJK000090@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Wed, 25 Mar 2015 15:11:45 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01PK11LGHOSC000090@mauve.mrochek.com> Date: Wed, 25 Mar 2015 15:08:03 -0700 (PDT) In-reply-to: "Your message dated Wed, 25 Mar 2015 08:58:20 +0100" <5cae1bbd-01dc-4052-80aa-bf9bee813859@gulbrandsen.priv.no> References: <5cae1bbd-01dc-4052-80aa-bf9bee813859@gulbrandsen.priv.no> To: Arnt Gulbrandsen Archived-At: Cc: ima@ietf.org Subject: Re: [EAI] SMTPUTF8 for non EAI messages X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 22:16:50 -0000 > A SMTPUTF8 message doesn't have to contain EAI addresses, if you care only > about to the formal grammar. Just like for 822 mail, just a From and a Date > field is enough. Subject, message-id, body text, all those things are > optional in a formal sense. RFC6531 bottom of page 4 and top of page 5, and > the first 3-4 paragraphs of 6532 section 3. > The restriction is rather a practical one: If you're sending from an ASCII > address to an ASCII address, then restricting yourself to all-SMTPUTF8 > paths is chancy. Too chancy to bother with, IMO, since MIME encoders and > parsers are ubiquitous. +1. There may come a time when EAI support is ubiquituous and it makes sense to "just send UTF-8" rather than depend on what will then be creaky old encoding support. But we're a long way away from that. Ned From nobody Wed Mar 25 17:03:25 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3061D1A0092 for ; Wed, 25 Mar 2015 17:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 z9_zxRRkg0cj for ; Wed, 25 Mar 2015 17:03:19 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0718.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:718]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2FCE1A0052 for ; Wed, 25 Mar 2015 17:03:15 -0700 (PDT) Received: from BLUPR03MB1378.namprd03.prod.outlook.com (25.163.81.12) by BLUPR03MB1379.namprd03.prod.outlook.com (25.163.81.13) with Microsoft SMTP Server (TLS) id 15.1.118.21; Thu, 26 Mar 2015 00:02:54 +0000 Received: from BLUPR03MB1378.namprd03.prod.outlook.com ([25.163.81.12]) by BLUPR03MB1378.namprd03.prod.outlook.com ([25.163.81.12]) with mapi id 15.01.0118.021; Thu, 26 Mar 2015 00:02:54 +0000 From: Shawn Steele To: "ima@ietf.org" Thread-Topic: SMTPUTF8 for non EAI messages Thread-Index: AdBnWADOQPRRpcbiQlK20T4OnTwESA== Date: Thu, 26 Mar 2015 00:02:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::2] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1379; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(86612001)(86362001)(107886001)(2351001)(33656002)(76576001)(99286002)(110136001)(40100003)(92566002)(122556002)(46102003)(2501003)(77156002)(450100001)(62966003)(50986999)(54356999)(74316001)(2900100001)(2656002)(102836002)(87936001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1379; H:BLUPR03MB1378.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BLUPR03MB1379; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1379; x-forefront-prvs: 0527DFA348 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2015 00:02:54.1223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1379 Archived-At: Subject: Re: [EAI] SMTPUTF8 for non EAI messages X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 00:03:22 -0000 > Has the wg considered the case of using SMTPUTF8 as a means to avoid > 2047/2231 encoding for messages that don't contain any eai addresses I would hope that systems would prefer a SMTPUTF8 connection as that avoids= unnecessary encoding of stuff, regardless of whether the addresses are EAI= or not. One huge benefit is that the code page is unambiguous and not res= tricted to ASCII. From nobody Thu Mar 26 11:33:01 2015 Return-Path: X-Original-To: ima@ietfa.amsl.com Delivered-To: ima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48B91A90C5 for ; Thu, 26 Mar 2015 11:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 UdonPFjKDarH for ; Thu, 26 Mar 2015 11:32:52 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3351A9101 for ; Thu, 26 Mar 2015 11:32:52 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PK2835DIOG00FIV6@mauve.mrochek.com> for ima@ietf.org; Thu, 26 Mar 2015 11:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1427394470; bh=BFeakOxJOSzH4hywDY/f5LBsYsWDSfye37kjhIZ2ma8=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=jealKgNWhw9uJaXS/vReex8oueLPYltC2lYeLwCQvsjOhSlieYbt4k7thPicYyeNq qhX2Ubv+a6eGEyX6dCPIyCzLyTyqVjFUZPfEe+AZTXHU0k/sSfrUaYe7M6rxkwJ7P+ O5dIXZsxE5o7XB5t6GTPno7AAqdocK4cqgglA8wU= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PK24FXIWG00000AQ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ima@ietf.org; Thu, 26 Mar 2015 11:27:48 -0700 (PDT) From: ned+ima@mrochek.com Message-id: <01PK2833UAFS0000AQ@mauve.mrochek.com> Date: Thu, 26 Mar 2015 11:18:17 -0700 (PDT) In-reply-to: "Your message dated Wed, 25 Mar 2015 21:17:43 +0100" References: <5cae1bbd-01dc-4052-80aa-bf9bee813859@gulbrandsen.priv.no> To: Arnt Gulbrandsen Archived-At: Cc: ima@ietf.org Subject: Re: [EAI] SMTPUTF8 for non EAI messages X-BeenThere: ima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAI \(Email Address Internationalization\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:32:55 -0000 > > Well, what I was more interested in is how do people feel about > > downgrade/gateway-transformation in cases not involving > > addr-spec, [...] > I know about no implementations of that so far. But maybe someone will come > along and feel that this is something that needs doing for some MTA. My problem with it is it's tricky to implement correctly, and requires some compromises in message handling I'm not ready to make. In particular, if I know that a given recipient isn't capable of handling an EAI message - never mind why or how - I'd much rather report that in resonse to the RCPT TO. (I trust I don't need to explain why this is better than bouncing the message later.) More generally, I have to have the message in hand and perform a MIME analsysis before I can determine whether or not it can be safely downgraded. If at that point I find EAI addresses in the header or whatever, I have to bounce the message, with all that implies. And waiting until I have the message in hand gets into the usual thicket of issues surrounding handling of partial failures after the DATA. As it happens we have a fairly general architecture in place for handling this sort of thing, but it's not something I rush to apply to every problem that comes along. Since the design philosophy of EAI is that bounces are better than dowangrading, I must say that at this point I have no concern with this happening. Ned