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>