<<< Date Index >>>     <<< Thread Index >>>

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>