<<< 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@xxxxxxxx  |       Owner:  mutt-dev
      Type:  enhancement       |      Status:  new     
  Priority:  trivial           |   Milestone:          
 Component:  mutt              |     Version:  1.5.20  
Resolution:                    |    Keywords:          
-------------------------------+--------------------------------------------

Comment(by Derek Martin):

 {{{
 On Tue, Sep 08, 2009 at 08:01:57AM -0000, Mutt wrote:

 In principle, I agree, but...


 ...in practice, worrying about this case is crazy.  If you can find
 even *one* example of a subject line containing such a string, where
 the thread happened before this discussion, and it's clear that the
 reason it appears as such was because it was intended to, I'll be
 convinced otherwise (i.e. that it's not crazy -- but I still won't be
 convinced that you shouldn't make the change).

 Another way to look at this:  The RFCs are not laws; they are merely
 guidelines.  Throughout the history of computing, there have been many
 cases where there were competing standards.  Here, you have two: the
 standard outlined by RFC 2047, and the de facto standard which allows
 space in an encoded word, thrust on the world by the most popular
 e-mail software in the world, as well as others.  You can blindly
 adhere to the written standard, or... you can ignore it and
 interoperate with the rest of the known universe.  Which is better?


 "Very bad?"  Hardly.  Besides, I assert that it will never be a
 problem (barring cases where the poster is specifically trying to
 point out problems with this encoding scheme), precisely because so
 many mailers don't interpret the RFCs correctly.  If such a thread
 were created, no doubt the subject line would be changed almost
 immediately as the thread progressed, and almost certainly writing
 such a subject line will be discouraged by people who have any clue
 about this issue.

 I think it would be a satisfactory compromize if Mutt recognized that
 such an encoded word were present, and display the given header both
 ways... although that seems slightly gross.  At least then, the user
 would be able to read the subject line as it was intended to be read,
 regardless of what mail client generated it.  But I think the most
 sensible thing would be to just ignore the standard, and interpret it
 like everyone else does.
 }}}

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