#3328: mutt should handle unencoded whitespace in Q-coded strings
------------------------------+---------------------------------------------
Reporter: anto...@… | 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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
