Question IMAP default folders (Sent/Drafts/Trash) stay in English after mailbox creation – how do you solve this long-term?

[dbmtrde]

Server operating system version

Ubuntu 24.04

Plesk version and microupdate number

Plesk Obsidian 18.0.79.2

Hi everyone,

I'd be curious how other Plesk admins handle the following: when a new mailbox is created, Plesk always provisions the IMAP default folders (Sent, Drafts, Trash, Junk) in English — regardless of the panel language or server locale.

Honestly, this surprised me. Localizing the panel UI, email templates, and notifications is one thing, but the actual mail folders a customer looks at every day are arguably more basic than any of that. Every non-technical customer just expects their inbox to be in their own language — nobody thinks to ask for it, it's assumed. For a product that's fully translated into dozens of languages otherwise, it feels like a fairly fundamental gap that this wasn't addressed from the start.

For non-English customers this means: even if the mail client itself is set to German (e.g. a German-language Outlook), the folders still show up as "Sent", "Drafts", "Trash" rather than being translated — because Outlook and other clients pick up the folder names from the server, not from their own UI language. The only way around this is customizing the Dovecot configuration yourself, and even then Plesk's own mailbox provisioning doesn't respect it, so the English folders keep getting created alongside the translated ones.

Specific questions for you:

• Do you localize IMAP folder names on your servers, and if so, how?
• Is there a way that reliably applies to every new mailbox (not just as a one-off fix afterward), without getting overwritten on the next Plesk update?
• Does anyone use a server-wide locale setting that handles this automatically, or is it fundamentally something you have to patch per mailbox?
• Has anyone had luck solving this through an official Plesk extension/module instead of building something custom?

Would appreciate any experience reports — including from admins running other languages, since this presumably affects any non-English installation.

Thanks!

 

[Kaspar]

Localizing IMAP folder names is a pain, because unfortunately every mail client handles this slightly differently.

Modern email clients are expected to use RFC 6154 (IMAP SPECIAL-USE attributes), meaning the client should not need to know whether a folder is called "Sent" or "Gesendet". The server advertises the folder's purpose using attributes such as \Sent, allowing the client to identify it correctly and (if supported) display a localized label. Sadly, not many mail clients implement this in a way that provides a consistent user experience. Outlook in particular is notorious for not localizing IMAP folders, even when the special-use attributes are available.

I have given up trying to provide localized folder names by default, because there does not seem to be a reliable solution that works well in a multilingual environment. This is (presumably) why Plesk defaults to English folder names (which it inherited from the Dovecot defaults): it is the most practical baseline and works reasonably well for most users. There simply is no folder naming scheme or application logic that works perfectly for every combination of server, client, and language.

If you want all mailboxes to use just one specific language (for example German), customizing the Dovecot configuration is probably the best option. This should work fine, but be aware that it can cause inconsistencies if you also use different names for the Spam folder. (Plesk expects the spam folder to be named Spam for SpamAssassin to work properly). The modified configuration will only apply to newly created mailboxes, so existing mailboxes with English folder names will need a migration or fallback configuration.

 

[dbmtrde]

Localizing IMAP folder names is a pain, because unfortunately every mail client handles this slightly differently.

Modern email clients are expected to use RFC 6154 (IMAP SPECIAL-USE attributes), meaning the client should not need to know whether a folder is called "Sent" or "Gesendet". The server advertises the folder's purpose using attributes such as \Sent, allowing the client to identify it correctly and (if supported) display a localized label. Sadly, not many mail clients implement this in a way that provides a consistent user experience. Outlook in particular is notorious for not localizing IMAP folders, even when the special-use attributes are available.

I have given up trying to provide localized folder names by default, because there does not seem to be a reliable solution that works well in a multilingual environment. This is (presumably) why Plesk defaults to English folder names (which it inherited from the Dovecot defaults): it is the most practical baseline and works reasonably well for most users. There simply is no folder naming scheme or application logic that works perfectly for every combination of server, client, and language.

If you want all mailboxes to use just one specific language (for example German), customizing the Dovecot configuration is probably the best option. This should work fine, but be aware that it can cause inconsistencies if you also use different names for the Spam folder. (Plesk expects the spam folder to be named Spam for SpamAssassin to work properly). The modified configuration will only apply to newly created mailboxes, so existing mailboxes with English folder names will need a migration or fallback configuration.

Thank you for the information, this matches most of what I found digging into it — the RFC 6154 / special-use situation and Outlook's inconsistent handling in particular.

One thing I'd push back on slightly, based on what I actually observed on my own server (Plesk 18.0.79, Dovecot 2.4.4): the assumption that the custom namespace config "will only apply to newly created mailboxes" (implying it works cleanly for those) wasn't quite what happened in practice.

I set up the exact special_use namespace config you'd expect (German folder names with \Sent, \Drafts, \Trash flags, auto = no on the English originals). Verified with doveconf -n that it loaded correctly. But when creating a brand new mailbox afterward — both via the Plesk GUI and via plesk bin mail --create — Plesk still provisioned the English folders (Sent, Drafts, Trash) in addition to the German ones I'd configured, before any client ever connected. I checked this immediately after creation, before any IMAP login, so it wasn't a client-side artifact — Plesk's own mailbox provisioning step creates them regardless of the namespace config.

So in practice, "new mailboxes" only fully worked as expected for the English originals (which Plesk seems to provision independently of Dovecot's namespace settings) — the German folders got added alongside them, not instead of them. Ended up needing a Plesk event handler (mailname_create) to clean up the empty English duplicates right after provisioning, since there's no config-level way to stop Plesk from creating them in the first place. Existing mailboxes needed a separate one-time migration on top of that, as you mentioned.

I've managed to get everything set up so far, but since I had to tweak things afterward and even get my hands dirty, I'm left with a queasy feeling about whether and how long this will all hold up. Nearly all of my clients use Outlook on their desktops, so I felt a bit silly having to explain every time why their inbox was organized in English while everything else about the service is in German — it's exactly the kind of thing customers assume just works.

That's really the reason behind my original question/criticism: why is this left to us to hack around, instead of Plesk solving it? This is such a basic, day-to-day thing for non-technical customers — arguably more fundamental than half the panel UI that already is fully localized. It doesn't feel like it should be this hard for a product whose whole value proposition is taking that kind of complexity off the admin's plate.

Not disagreeing with your overall point about there being no clean solution — just flagging that even the "new mailboxes are fine" part isn't as clean as the Dovecot docs would suggest, at least not on this Plesk/Dovecot combo. Would be curious if anyone's seen different behavior on other versions.

 

[Kaspar]

Seems you are right. Plesk does create the default English folders upon creating a mailbox, regardless of what has been configured in Dovecot. I don't recall this being the case when I tinkered with this issue a couple of years ago, but that must be my memory slipping. Sorry for leading you astray. As a workaround, you can create a script that deletes those English-named folders and add an event handler in Plesk to call the script every time a mailbox gets created to get rid of them. Leaving your users with just the locally named folders.

 

[dbmtrde]

Seems you are right. Plesk does create the default English folders upon creating a mailbox, regardless of what has been configured in Dovecot. I don't recall this being the case when I tinkered with this issue a couple of years ago, but that must be my memory slipping. Sorry for leading you astray. As a workaround, you can create a script that deletes those English-named folders and add an event handler in Plesk to call the script every time a mailbox gets created to get rid of them. Leaving your users with just the locally named folders.

No problem at all It was just a quick note on that point.

I managed to resolve the issue afterwards using an event handler, a trigger and a Bash script. However, I undid the whole thing with a rollback because I found tinkering with it too much work, even though the approach worked just fine. Whether you actually want to “tinker” with the system that much is more a matter of personal preference. It is regrettable that there is no standard solution for this and that one is forced to tinker with the system itself, since almost all business customers use Outlook and, ultimately, everything is displayed to them in English.

 

[dbmtrde]

Since this is a massive and ongoing pain point for all of us and generates completely unnecessary support tickets from clients, I decided to take this straight to Microsoft.

I just created an official feature request on the Microsoft Feedback Portal demanding support for the RFC 6154 (SPECIAL-USE) flag for IMAP accounts in Outlook, so it finally localizes folders like Apple Mail and Thunderbird do.

If we want Microsoft's dev team to even look at this, we need votes from the community. Please take a minute to upvote the idea here:
Implement IMAP RFC 6154 (SPECIAL-USE) to fix folder localization (Sent, Trash, Drafts) for non-Exchange accounts

The more admins, hosters, and agencies push this, the higher the chance they might actually fix this IMAP localization mess. Let's get some traction on this!