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

Re: [Mutt] #3328: mutt should handle unencoded whitespace in



#3328: mutt should handle unencoded whitespace in Q-coded strings
------------------------------+---------------------------------------------
 Reporter:  antonio@â         |       Owner:  mutt-dev
     Type:  enhancement       |      Status:  new     
 Priority:  trivial           |   Milestone:          
Component:  mutt              |     Version:  1.5.20  
 Keywords:                    |  
------------------------------+---------------------------------------------

Comment(by vinc17):

 Replying to [comment:4 Derek Martin]:
 > ...in practice, worrying about this case is crazy.  If you can find
 > even *one* example of a subject line containing such a string,

 Well, I can't find one in my mail archives, but this doesn't mean that it
 cannot occur. Anyway I assume that the RFC disallowed spaces in order to
 have a simple parser, less prone to bugs. So, why not fixing the mailbox
 instead? I'm not opposed something like that in Mutt (when reading the
 mailbox), as long as it is optional. In that case, it should probably be
 scriptable in order to handle other bugs. For instance, the RFC requires
 all the bytes of a character (e.g. UTF8 sequence) to be in the same
 encoded word; unfortunately some software (GLPI at least) doesn't follow
 this requirement. Unencoded 8-bit characters could be handled as well.

 I think it is important to keep these things under the user control. You
 want to handle unencoded whitespace in Q-coded strings. For similar
 reasons (bugs in other software), other users may want to handle HTML
 entities (Gforge generates such entities), but for this kind of problem, I
 have examples (technical discussions / bug reports) where HTML entities
 must *not* be handled.

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3328#comment:5>
Mutt <http://www.mutt.org/>
The Mutt mail user agent