Regression: eM Client no longer displays externally-set IMAP keywords (tags) from Dovecot/Migadu — worked until last week, still works with IceWarp

Custom IMAP keywords set on my messages by an external tool (via IMAP STORE +FLAGS) stopped appearing as tags in eM Client around last week (week of 8 June 2026). They had been displaying correctly for a long time before that. The keywords are in latin, no spaces, e.g KEYWORD-TAG.

This is a regression, and it’s specific to my Migadu (Dovecot) account:

  • The same eM Client, with the same kind of setup, still displays externally-set IMAP keywords correctly on my IceWarp-hosted IMAP
    accounts. So eM Client clearly supports this — only the Migadu/Dovecot account broke.
  • Nothing changed in how the keywords are set; the external tool has been applying them the same way throughout.

Verified facts (Migadu/Dovecot account):

  • The keyword is genuinely present on the server as a raw IMAP atom — confirmed with a direct UID FETCH (FLAGS).
  • The mailbox’s PERMANENTFLAGS includes *, so custom keywords are permitted.
  • Migadu webmail and Thunderbird both display these keywords as tags — so the server side is correct and unchanged.
  • In eM Client I created a tag with the exact same name and case, restarted eM Client, and even sent a fresh
    message (so the tag was defined before the message synced). The tag still does not appear on any of these messages.
  • Running “Repair” on the folder removed eM Client’s tag display entirely (the server keywords remained intact).

Questions:

  1. What changed in eM Client’s IMAP keyword/tag handling around early June 2026?
  2. Why does eM Client display externally-set IMAP keywords correctly for IceWarp accounts but not for Dovecot/Migadu accounts in the same
    version?
  3. How can I restore the previous behavior where these keywords appeared as tags?

Hello,

to investigate this issue further, we will need to review your IMAP diagnostic logs.

Please follow the steps below to enable logging and send us the required data:

  1. Go to Menu → Settings → Advanced → Logging → Find your affected account in the list and check the box for IMAP, then click Save & Close
  2. Restart eM Client
  3. Repair one of the affected messages - Right-click in the message → select Properties → Repair tab → click on Repair
  4. Note down the tag name and the message UID (UID is in the Properties window)
  5. Go back to Menu → Settings → Advanced → Logging and click Send Logs… → A new email window will open with the logs attached, so please send it to [email protected] and include the UID and the tag name in the email

Hello,

I attached the logs and sent them. Please contact me for further info. Having tags is especially important for our organization. Thank you in advance.

Same regression here with IONOS Business Mail, which is Open-Xchange /
Dovecot-based. So this is not limited to Migadu; it affects IONOS/OX too,
while (as you noted) IceWarp still works.

Setup:

  • Server: imap.ionos.de:993 (IMAP over SSL), IONOS Business / Open-Xchange App Suite, Dovecot backend
  • A server-side Sieve filter sets a custom IMAP keyword “DSV-AV” on incoming mail (addflag).

What I see:

  • The keyword IS present on the server. Direct IMAP check:
    PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen DSV-AV *)
    • 5 FETCH (UID 5 FLAGS (\Seen DSV-AV))
  • So the folder advertises the custom keyword in PERMANENTFLAGS and the message
    carries it.
  • IONOS webmail (OX) shows the keyword. A direct IMAP session shows it.
  • eM Client shows NO tag/label for that message (“none”).
  • If I manually apply a tag in eM Client and then run Repair on the folder, the
    tag disappears again — i.e. eM Client does not read/keep the server keyword.

This used to work on this account before the early-June change, same as reported
above for Dovecot/Migadu. Happy to provide IMAP logs (see attached in my mail to
support).

eM Client version: 10.4.5326
OS: Windows 11

Cheers, Anton

@anton.kronseder I confirm your findings. I spoke with the support of eM Client and I was left with the impression that they scope imap server capabilities by server identity solely. If it doesnt fall in their accepted list, functions are rejected. Unfortunately, they dont want to take care of this.
I created a simple proxy to spoof the server identity to dovecot. Works perfectly now. The annoying thing is that this is not my homelab environment and the proxy has to be prepared for production which is extra hassle.

Hello eM Client team,

I would like to confirm slazarov’s findings in forum thread 117054. Credit goes to
slazarov and to your own support team, who identified that eM Client enables IMAP
keyword/tag sync based on the server’s reported identity, and that servers not on
the accepted list are rejected.

I can confirm this from my side with concrete data. My provider is IONOS Business
Mail; the IMAP server identifies itself via the RFC 2971 ID response as:

  name        = "RZimapd"

slazarov and to your own support team, who identified that eM Client enables IMAP
keyword/tag sync based on the server’s reported identity, and that servers not on
the accepted list are rejected.

I can confirm this from my side with concrete data. My provider is IONOS Business
Mail; the IMAP server identifies itself via the RFC 2971 ID response as:

  name        = "RZimapd"
  vendor      = "Strato GmbH"
  support-url = https://www.ionos.com/help/email

It does not report “Dovecot”, although the backend behaves like one. The server
fully supports custom IMAP keywords – the mailbox advertises them in PERMANENTFLAGS:

  PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen DSV-AV \*)

and server-side Sieve filters set the keyword “DSV-AV”, which a raw IMAP session and
the IONOS webmail both display correctly. eM Client, however, does not show these
keywords as tags – consistent with exactly the identity-gating that slazarov and
your support described.

My request

As confirmed, the capability is gated by the reported ID string rather than by what
the server actually advertises (it announces ID, ENABLE, MOVE, UIDPLUS, and
PERMANENTFLAGS clearly allows custom keywords). I understand you may not want to add
every provider’s identity to the accepted list. Would you consider at least a
“dark”/advanced, per-account option to override this – e.g. manually set the
accepted server-identity string, force a server family (“treat this account as
Dovecot”), or simply “force-enable IMAP keyword/tag sync for this account”?

That would let users with capable-but-unlisted servers opt in themselves, instead of
having to run an ID-spoofing proxy in production – the workaround slazarov mentioned.

I’m happy to provide IMAP logs or test against my account.

Thank you,
Anton Kronseder
smartics

eM Client version: 10.4.5326.0
OS: Windows 11

Hi slazarov, thank you so much for digging into this and sharing your findings —
and the proxy workaround. It explained exactly why my IONOS tags wouldn’t sync and
saved me a lot of guesswork. Much appreciated!

Here is the simple proxy src code for anyone to tinker with. Dovecot was chosen because it’s one of the most simple servers and we only want to trick the client to enable the tags not try capabilities that don’t exist.

1 Like

Hello all, we really have a white list for servers we’ve tested and approved for tags synchronization. There is a very good reason for that. We’ve done a lot of testing here. A lot of servers (even though they advertised mentioned capabilities) do not behave correctly. One of the common and really big problem here is that many servers allow only limited IMAP keywords to be used per folder or per account which results a lot of issues and misbehavior. That’s why we have to explicitly allow a specific server once the testing is successfully completed. If the identification of the server changes or it is for example a fork of Dovecot server we have no way how to detect it will work correctly. That’s why we always request IMAP log files and we can always see that the identification of the server differs from our white list. If you are convinced it your IMAP server should be part of the white list, let us know and we’ll add it to our white list. You can manually workaround it with an advanced parameter --force-imap-server-type dovecot.
You can set advanced parameters in Menu → Accounts → particular account → Diagnostics → Adavanced parameter. Once the advanced parameter is set, it should behave as with any other Dovecot server (including server tags support).

1 Like

Hello Michael,

thank you — that’s a really clear and convincing explanation. The whitelist
approach makes complete sense now: I hadn’t considered that many servers advertise
capabilities they don’t actually honor (the limited-keywords-per-folder/account
issue is a great example). Thanks for taking the time to lay out the reasoning so
thoroughly.

The per-account workaround --force-imap-server-type dovecot works perfectly, and
since it’s scoped to the individual account it leaves my other accounts untouched —
exactly what I needed.

Great job, and thanks again for the excellent support!

Best regards,
Anton

1 Like