Re: [Mutt] #2997: Missparsed/decoded headers in index view on IMAP
#2997: Missparsed/decoded headers in index view on IMAP server
Changes (by brendan):
* status: reopened => closed
* resolution: => invalid
Comment:
This is strictly a gmail IMAP bug, and the inconsistency is in the server.
Mutt does a limited header fetch for the index, then refetches the full
body in the pager. Gmail incorrectly encodes the header when a limit is
applied:
{{{
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)])
...
* 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)] {299}
Date: Tue, 4 Dec 2007 13:51:54 -0800
To: =?ISO-8859-1?Q?Br=E9ndan_Cully_<xxxxxxxxxxxxxxx@xxxxxxxxx>?=
Subject: RFC 2047 mangling test
Message-ID: <20071204215153.GC6026@xxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii
From: =?ISO-8859-1?Q?Br=E9ndan_Cully_<brendan@xxxxxxxxxx>?=
)
a0007 OK Success
}}}
But it correctly formats the header when no filter is applied:
{{{
a0024 UID FETCH 573 BODY[]
* 111 FETCH (UID 573 BODY[] {2273}
Delivered-To: xxxxxxxxxxxxxxx@xxxxxxxxx
Date: Tue, 4 Dec 2007 13:51:54 -0800
To: =?iso-8859-1?Q?Br=E9ndan?= Cully <xxxxxxxxxxxxxxx@xxxxxxxxx>
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 <brendan@xxxxxxxxxx>
See From:
)
a0024 OK Success
}}}
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'.
I would guess that other clients do not experience this bug simply because
they do not use BODY filters.
--
Ticket URL: <http://dev.mutt.org/trac/ticket/2997#comment:5>