Ralph,
First, it's good to hear you're alive! And I mean in that in all
seriousness; none of us are exactly spring chickens anymore, are we?
I hope everyone out there is doing well.
And ... yeah, it pretty much sucks that Outlook is doing it's own
thing here.
To return any header in a reply, repl(1)'s -form file can have something
like:
%<{thread-index}Thread-Index: %{thread-index}\n%>\
Should we modify nmh's standard repl format files to have this?
I think ... yes. This seems like it is very simple.
Which leaves supporting generating a new Thread-Index for comp(1), and
whether that's required. Or does Outlook add one to every email which
arrives without one?
I could do some experimentation on that regard using Outlook 365.
Honestly, I think the simplest thing to do is is generate a thread-index
value in mh-format; we don't really have an easy method of encoding
something in base64 in the mh-format language.
As I see it from the helpful references you provided, we need ....
- a single byte containing 0x01
- An 5-byte timestamp which is ... the number of 100-nanosecond intervals
since January 1st, 1601 (the upper 5 bytes of that value). And it seems
like the timestamp doesn't actually matter as Bugzille uses a fixed
timestamp.
- A 16-byte GUID. Which basically can be random bytes (I know technically
GUIDs are not, but it seems like they don't care).
--Ken