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

Re: [Mutt] #3090: Mutt removes In-Reply-To header field



#3090: Mutt removes In-Reply-To header field

Comment (by agriffis):

 Replying to [comment:14 pdmef]:
 > Replying to [comment:13 agriffis]:
 > > If you could provide more explanation or even a (possibly incomplete)
 patch, I'd be interested.  So far, I don't understand how your suggested
 approach does anything other than move the problem around, and possibly
 creates other problems...
 >
 > Well, from my point of view the problem is that when mutt generates a
 partial message with edit_headers set and the message-id not containing
 exactly 1 @ (or not being "valid" by mutt's In-Reply-To expectations),
 mutt later can't parse that and breaks threading as it simply drops that
 message-id.
 >
 > I don't think the parser for In-Reply-To should be touched to solve the
 problem because it implements a heuristic and changing a heuristic is bad
 when you can't test that change against sample data.
 >
 > That said, the only way out I currently see is to find a way to get the
 broken message-id accross the editor. It's a feature that the parent's
 message-ids are available with edit_headers set so that users being sure
 what they're doing can adjust threading (i.e. not writing it out and
 reading it back isn't a solution).
 >
 > So, my first thought was to not add a In-Reply-To header with the parent
 message-ids but a References header to the message being edited by the
 user. If we also change mutt_parse_references() to only require exactly
 one @ for In-Reply-To but accept everything else otherwise (kind of what
 you suggested), I think this could work and be a simple patch.
 >
 > But I didn't look further into code yet.
 >
 > Can you explain why that moves the problem around?

 Well, by "moves the problem around" I mean that you're changing the parser
 for References and assuming that's better than changing the parser for In-
 Reply-To.  I think your assumption is based on the idea that References is
 more consistent than In-Reply-To, which might be right, but in fact the
 RFC gives them both the same treatement.

 Regarding putting References in lieu of In-Reply-To in the message text
 when edit_headers is set, I have a few objections:

 1. the References string is often long (up to 10 entries, hard limit in
 the mutt source).  Most of the time users simply want to change the In-
 Reply-To string, so providing References in the text is overkill
 2. this change implies that adding In-Reply-To manually to a message while
 editing will not be effective
 3. too risky at this point in 1.6 bugfixing phase.  This is the kind of
 change that needs some time to soak because it's very visible to users.

 So getting back to the problem, let's keep in mind that the issue here is
 pretty simple: References and In-Reply-To are strings in a message header,
 but for the sake of threading, mutt stores them as LIST.  In order to
 convert them to LIST, the strings are parsed to fish out the message-ids.
 If the message-ids aren't in strict format, the parser drops them.

 Normally, dropping bogus message-ids only results in broken threads on
 display, for example bug #1935.  All by itself, that's a good reason to
 loosen the parser.  However in this case, the message-id is silently
 dropped in sending, so not only is it broken on display, but mutt is also
 breaking threads for the recipients...

 So for these reasons, I think the parser needs to be loosened to allow for
 some common kinds of brokenness.  I appreciate theoretically your
 objection to changing the heuristic, but I think that pragmatically the
 parser needs to accept these bogus message-ids.  Note that already the
 parser's heuristic is clearly broken: *most* email addresses these days
 have more than 8 characters before the @-sign; that's based entirely on
 antiquated UNIX login limits!

 So how to loosen the parser?  It seems the most common kinds we know of
 are: missing @-sign or multiple @-signs.  Your patch on #1935 treats the
 former (though inexplicably it only loosens for References) and my first
 patch here treats the latter.  Ultimately I think the best thing would be
 to loosen both, assume that any non-whitespace between <..> is a message-
 id.  Patch attached, though frankly this should coordinated with some
 changes to mutt_extract_message_id()

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