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

Re: [Mutt] #2995: Mutt is folding subject line folds using a tab,



#2995: Mutt is folding subject line folds using a tab, which appears to be 
against
RFC 2822

Comment (by Frank Bulk):

 {{{
 I think Kyle has made a pretty strong case that mutt is folding it
 incorrectly, and the reason it hasn't shown up before is that some clients
 either don't display a TAB or compensate for special characters in the
 subject line.  If we don't follow Kyle's interpretation, an e-mail client
 could add or remove an arbitrary number of WSP characters over the life of
 the message.  That should be obviously undesirable.

 In regards to how mutt unfolds it, perhaps we ought to revert to correct
 behavior but add a compiling or run time option to use the incorrect
 method.

 Frank

 -----Original Message-----
 From: fleas@xxxxxxxx [mailto:fleas@xxxxxxxx]
 Sent: Wednesday, November 28, 2007 5:04 AM
 To: frnkblk@xxxxxxxxx; pdmef@xxxxxxx
 Cc: mutt-dev@xxxxxxxx
 Subject: Re: [Mutt] #2995: Mutt is folding subject line folds using a tab,
 which appears to be against RFC 2822

 #2995: Mutt is folding subject line folds using a tab, which appears to be
 against
 RFC 2822

 Comment (by Rocco Rutte):

  {{{
  Hi,

  * Mutt wrote:
  > On Wednesday, November 28 at 09:21 AM, quoth Mutt:

  >> Please look up what WSP is in RfC2334 (it's the same as LSWP in the
  >> older RfC822):

  > Just because a WSP can be either a tab or a space does not mean that
  > they are interchangeable and that they have no semantic meaning.

  If it read like I was saying this, I didn't mean it. I just wanted to
  point out that "white space" does not mean "space" and that a tab for
  folding is not illegal per se.

  > In other words, by merely removing the CRLF, we should have the
  > original, pre-folding version of the header. Thus, when folding, we
  > may only ADD CRLFs (in specific places), rather than give ourselves
  > the freedom to delete and replace some of the characters of the
  > original header.

  I read the standard the same way, too (except RfC2047 where space or
  even white space between encoded words is to be removed).

  On the other hand, there's a compatibility issue. Some quick tests show
  that some clients properly implement it the standard way, others don't.

  So maybe mutt should just keep continuing interpreting it in the broken
  way but send in the correct. We could then leave it that way until
  somebody else complains.

  I'm still wondering though why this hasn't come up earlier...

  Rocco
  }}}

 --
 Ticket URL: <http://dev.mutt.org/trac/ticket/2995#comment:>

 }}}

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/2995#comment:>