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