Support for custom IMAP headers (e.g. "X-Keywords") for tagging messages
I use mu4e in Emacs and I use the tagging feature. For example, if I tag a message as "holiday" then mu4e adds a new header to the message like so: "X-Keywords: holiday". I also use mbsync to sync my local maildirs with remote IMAP servers and I use ProtonMail Bridge to handle this with my PM account.
This all works fine with other mail servers. If I set the tag as above then the next time mbsync syncs the message it will have the appropriate "X-Keywords" header on the remote server. However with ProtonMail Bridge, the header seems to be stripped. I can see that the header is being sent using mbsync's debug output, however it is never stored.
This is extremely important for me as I use tagging as the primary way of organising my mail. At present, these tags are only stored locally and therefore when I access my ProtonMail mailbox on another computer all of the tags are missing which is extremely inconvenient.
Fixing this should be very simple: just allow custom headers to be used when storing a message.

-
polaris64 commented
I can confirm that this is indeed the case. I cloned from https://github.com/ProtonMail/proton-bridge and removed the block referenced in my previous comment. I then tried tagging an e-mail and moving it to the INBOX from the archive. Viewing the headers in the ProtonMail web app now shows: -
...
X-Keywords: test-label
...This change is not a fix of course as I now have duplicate messages: one in the archive without that header and a copy in the INBOX with that header. But it shows that this part of the code is problematic when tagging modifies an existing message's headers and therefore I believe this to be a bug.
-
polaris64 commented
I think the issue might be here: https://github.com/ProtonMail/proton-bridge/blob/6ff4c8a73853a3794656e530c6f073e02a22568f/internal/imap/mailbox_append.go#L137
When mbsync moves a message (e.g. from INBOX to Archive) then it issues an APPEND. However as the message already exists in ProtonMail it looks like the above check prevents the modified message source (with the new X-Keywords header) from being stored.