Mailspring is removing custom headers provided from the sender once I reply. I found it when replying to issues generated via Gitlab: we have gitlab configured to allow developers reply to emails and generate comments on issues. Gitlab controls the thread via two custom headers:
Thread-Topic: repo-name | issue title (#225) Thread-Index: FOmNZclVgug6MVht1qPdoXk9XWrm4w==
As Mailspring destroys these headers on doing a reply, gitlab is not able to recognize the email sent.
I suppose this will happen with any header related logic regarding emails comunication.
Is there any option to prevent removing the headers?
Hmm this is interesting—AFAIK there’s not any formal spec for maintaining headers when building a reply. You basically just take the MIME Message-ID of the previous message and place it in the In-Reply-To or References headers, and it’s otherwise identical to a new message.
It seems like your client is probably detecting headers that begin with Thread- and preserving them. Will see if I can find a spec related to this and we can change the Mailspring behavior.
Update
Hmm… so based on the information I’ve found on StackOverflow (can’t seem to find a spec related to this…), it doesn’t seem like this is really a correct way for GitLab to be implementing this feature. I know GitHub uses a custom reply-to address, and that seems to be the suggested approach. It looks like users of Outlook have also complained about not being able to reply to Gitlab emails.
That said, I think we should be able to fix this - it’s just a matter of being careful and picking out only custom headers that should be copied. A lot of spam protection systems / antivirus tools, etc. add headers server-side, and re-applying those to new emails would be bad.