Truly for the vault changes. I thought we had fixed the bug that was causing message-id to get encoded, yet perhaps it despite everything exists in 3.7? I don't recall when we fixed it (and I might be recollecting incorrectly!) 

With respect to X-"unstructured headers" getting destroyed, by *definition* in the rfc, if the header body is unstructured it must help RFC encoding. In the event that doesn't, it's anything but an unstructured header field. Which is the reason I said we have to consider what attributes the default parser ought to have. The RFC doesn't generally address that, it anticipates that each header should be one of the characterized types...but while a X-header may be of a characterized type, the email bundle can't realize that except if it is told, so what would it be a good idea for us to use as the default parsing procedure? "text without encoded words" isn't generally RFC consistent, I think. (In spite of the fact that I'll let it be known has been some time since I last explored the important RFCs.) 

Note that I accept that we have an open issue (or if nothing else an open conversation) that we should change the 'refold_source' default from 'long' to 'none', which implies that X-headers would in any event be gone through of course. It would likewise alleviate this issue, and can be utilized as a nearby workaround for headers that are simply getting gone through and not altered.

Regards,
Mika Hawkins