Interesting gmail IMAP RFC 2047 encoding

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:

7> a0007 FETCH 1:111 (UID FLAGS INTERNALDATE RFC822.SIZE
BODY.PEEK[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID
REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO
REPLY-TO LINES LIST-POST X-LABEL)])
...
7< * 111 FETCH (UID 573 RFC822.SIZE 2233 INTERNALDATE
"04-Dec-2007 21:51:57 +0000" FLAGS (Seen)
BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID
REFERENCES CONTENT-TYPE CONTENT-DESCRIPTION IN-REPLY-TO
REPLY-TO LINES LIST-POST X-LABEL)] 
Date: Tue, 4 Dec 2007 13:51:54 -0800
To: =?ISO-8859-1?Q?Br=E9ndan_Cully_<xxxxxxxxxxxxxxxgmail.com>?=
Subject: RFC 2047 mangling test
Message-ID: <20071204215153.GC6026xxxxxxx.xx.xxx.xx>
Content-Type: text/plain; charset=us-ascii
From: =?ISO-8859-1?Q?Br=E9ndan_Cully_<brendanxxxxxx.com>?=

7< )
7< a0007 OK Success
6> a0024 UID FETCH 573 BODY[]
7< * 111 FETCH (UID 573 BODY[] 
Delivered-To: xxxxxxxxxxxxxxxgmail.com
Date: Tue, 4 Dec 2007 13:51:54 -0800
To: =?iso-8859-1?Q?Br=E9ndan?= Cully <xxxxxxxxxxxxxxxgmail.com>
Subject: RFC 2047 mangling test
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Operating-System: Linux 2.6.22-14-386 i686
User-Agent: Mutt/1.5.17 (2007-11-15)
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
From: =?iso-8859-1?Q?Br=E9ndan?= Cully <brendanxxxxxx.com>

See From:
7< )
7< a0024 OK Success

(I've snipped some of the headers).

>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.

Comments?
_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol

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_<xxxxxxxxxxxxxxxgmail.com>?=
> From: =?ISO-8859-1?Q?Br=E9ndan_Cully_<brendanxxxxxx.com>?=
...
> 7< * 111 FETCH (UID 573 BODY[] 
...
> To: =?iso-8859-1?Q?Br=E9ndan?= Cully
<xxxxxxxxxxxxxxxgmail.com>
> From: =?iso-8859-1?Q?Br=E9ndan?= Cully <brendanxxxxxx.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
_______________________________________________
Imap-protocol mailing list
Imap-protocolu.washington.edu
https://mailman1.u.washington.edu/mailman/listin
fo/imap-protocol