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:>