Re: [ietf-822] utf8 messages

Ned Freed <ned.freed@mrochek.com> Fri, 15 August 2014 20:16 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: ietf-822@ietfa.amsl.com
Delivered-To: ietf-822@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED5C1A03EA for <ietf-822@ietfa.amsl.com>; Fri, 15 Aug 2014 13:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, 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 5JgCMsM1rfla for <ietf-822@ietfa.amsl.com>; Fri, 15 Aug 2014 13:16:09 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 768911A03DE for <ietf-822@ietf.org>; Fri, 15 Aug 2014 13:16:09 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PBESP6EQGW001FFK@mauve.mrochek.com> for ietf-822@ietf.org; Fri, 15 Aug 2014 13:11:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1408133468; bh=ZAB4pt6ZVFLf74XEnz++UqcEd32hi9fAcHEWgmWp6sU=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=CFdVFiMyZtzHaEClQhZEfeyo9PrTXfW3yFLhBsA4DvngKQTd7zZ/j8q8rndw8aTYk bH09B4FpwyGBjgr3/2VkqyRiYyMu5zZBEbNJA+45g7jTMYGhEUdCajJ7Ta2dxegWRP 1CGIRT9Gw6vpgp+Fts3QmQcEjkP0s5Yams8K/Ico=
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 <01PBEHSSJOO00000SM@mauve.mrochek.com>; Fri, 15 Aug 2014 13:11:03 -0700 (PDT)
Message-id: <01PBESP4O7H20000SM@mauve.mrochek.com>
Date: Fri, 15 Aug 2014 13:06:34 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 15 Aug 2014 13:27:08 +0200" <d00d0474-d28c-4d05-b42d-79e22913d61b@flaska.net>
References: <CABa8R6tWEhjjZSvq6NbM7EimokOms3suZufn0-6N1SB_fzGM8Q@mail.gmail.com> <01PB9FABWA4E0000SM@mauve.mrochek.com> <CABa8R6tns-idiZTj=+vb9fVNyH-nNYT+w9oNMb80XbCs5osvFw@mail.gmail.com> <01PBABOOL4QO0000SM@mauve.mrochek.com> <CABa8R6vBqS1ewmTtHh8tTOdzobsWpvSEokRxOqpj1Oq3hA+vsw@mail.gmail.com> <01PBBWUH11D60000SM@mauve.mrochek.com> <CABa8R6uJ--4Fcntdgef+h6ZXjP_q0q7hZaBW-SOozMTtiE918g@mail.gmail.com> <01PBCGZERCU20000SM@mauve.mrochek.com> <CABa8R6sbFQHaP=YgrejJjUKJS+20BFP+kATZ+PrDnTgUhPMpHw@mail.gmail.com> <01PBDQ3P6A8Q0000SM@mauve.mrochek.com> <d00d0474-d28c-4d05-b42d-79e22913d61b@flaska.net>
To: Jan Kundrát <jkt@flaska.net>
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-822/jWN01x2eJ5evNIR2WfSsqw9ari8
Cc: ietf-822@ietf.org
Subject: Re: [ietf-822] utf8 messages
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of issues related to Internet Message Format \[RFC 822, RFC 2822, RFC 5322\]" <ietf-822.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-822/>
List-Post: <mailto:ietf-822@ietf.org>
List-Help: <mailto:ietf-822-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Aug 2014 20:16:11 -0000

> From my point of view, it would be most interesting to see what happens
> when I deploy e.g. a Postfix version which understands this new RFC along
> with an older Dovecot which doesn't do it. Suddenly, an IMAP client is in
> the same position as Brandon describes because there's no way of accessing
> the ESMTP envelope through IMAP.

That's an incompliant setup, so what happens doesn't have much to do with the
standards. There's an IMAP extension in addition to  an SMTP extension; if the
IMAP server offers access to the EAI messages without the client having
requested such access (and of course there will be no way to do that in an
unextended IMAP server) you're operating outside the scope of the standard.

I'll also note that the SMTPUTF8 indicator during transport doesn't necessarily
translate to an RFC 6532 message on delivery. The EAI-ness of the message
during transport could be limited to envelope fields that end up not appearing
in the delivered message. Of course you can just blindly set the store-side
indicator on the basis of the SMTPUTF8 indicator if you like.

This stuff is tricky.

				Ned