Yes for the registry changes.  I thought we had fixed the bug that was causing message-id to get encoded, but maybe it still exists in 3.7?  I don't remember when we fixed it (and I may be remembering wrong!)

As for X- "unstructured headers" getting trashed, by *definition* in the rfc, if the header body is unstructured it must support RFC encoding.  If does not, it is not an unstructured header field.  Which is why I said we need to think about what characteristics the default parser should have.  The RFC doesn't really speak to that, it expects every header to be one of the defined types...but while an X- header might be of a defined type, the email package can't know that unless it is told, so what should we use as the default parsing strategy?  "text without encoded words" isn't really RFC compliant, I think.  (Though I'll admit it has been a while since I last reviewed the relevant RFCs.)

Note that I believe that we have an open issue (or at least an open discussion) that we should change the 'refold_source' default from 'long' to 'none', which means that X- headers would at least be passed through by default.  It would also mitigate this problem, and can be used as a local workaround for headers that are just getting passed through and not modified.