MBOX-Line: From guenther+imap at sendmail.com  Tue Dec  4 17:00:07 2007
To: imap-protocol@u.washington.edu
From: Philip Guenther <guenther+imap@sendmail.com>
Date: Fri Jun  8 12:34:41 2018
Subject: [Imap-protocol] Interesting gmail IMAP RFC 2047 encoding
In-Reply-To: <20071204221552.GA8980@ventoux.cs.ubc.ca>
References: <20071204221552.GA8980@ventoux.cs.ubc.ca>
Message-ID: <Pine.BSO.4.64.0712041658260.10304@vanye.mho.net>

On Tue, 4 Dec 2007, Brendan Cully wrote:
> I've just received a spate of complaints from mutt users that that
> non-ascii addresses are not being decoded in the index view, but are
> in the message view. Apparently gmail is encoding them differently
> depending on whether BODY.PEEK is given a filter or not:
...
> To: =?ISO-8859-1?Q?Br=E9ndan_Cully_<xxxxxxxxxxxxxxx@gmail.com>?=
> From: =?ISO-8859-1?Q?Br=E9ndan_Cully_<brendan@xxxxxx.com>?=
...
> 7< * 111 FETCH (UID 573 BODY[] {2273}
...
> To: =?iso-8859-1?Q?Br=E9ndan?= Cully <xxxxxxxxxxxxxxx@gmail.com>
> From: =?iso-8859-1?Q?Br=E9ndan?= Cully <brendan@xxxxxx.com>
...
>> From my reading of RFC 2047 section 5.3, the first version is
> performing illegal encoding on the From and To addresses:
>
> + An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'.
>
> But I'd appreciate it if anyone could confirm my reading. If this is a
> bug in google's IMAP server I'd rather not fix it in mutt.

Yes, that's broken.  If nothing else, the data returned for 
BODY[HEADER.FIELDS (...)] must match the data for BODY[].


Philip Guenther

