Dovecot interprets dots in plus-address component of address as subfolder boundaries -- bug or feature?

Matthew Swift

Member
Jun 27, 2018
5
1
3
Gloucester MA USA
cPanel Access Level
Root Administrator
WHM/cPanel v82.0.16. When Dovecot is configured to create subfolders when receiving plus-addressed mail, each dot in the plus-address component is interpreted as a subfolder boundary when delivering incoming mail via LMTP to a maildir folder (I have not tested mdbox format). I have found no reference to this behavior in cPanel or Dovecot's LMTP local mail delivery component. If this behavior is correct, where is it documented?

For example, mail to [email protected] gets delivered not to user john smith's INBOX/one.two.three directory as I expected but to the directory INBOX/one/two/three.
 

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,296
1,262
313
Houston
Hi @Matthew Swift


Ok, this took some serious research and it's not very well documented from dovecot but here's what I have for you:

While RFC5322 does allow for the following to be used in plus/sub addressing (+), (-), (.) there is a caveat with dovecot and maildir (also while it specifies maildir this functions in the same manner for mdbox). The feature which dovecot uses for plus/sub addressing is the recipient_delimiter (Formerly Sieve Filters) and it's handled by Dovecot's LDA with Exim. You can read all about these here:

So while that's what handles plus addressing it's not actually what dictates how the mail is organized for the user. This is instead handled by namespaces. Information on what specifically namespaces are can be found here: Namespaces — Dovecot documentation

Essentially, what namespaces do is dictate how and where to find mailboxes for users. A feature of namespaces is the hierarchy separator and that is where we'll find our answers. Namespaces — Dovecot documentation

maildir's hierarchy separator is a ( . ). Per the documentation in a couple of places, changing this hierarchy separator can cause a bunch of issues:

IMAP clients, Sieve scripts and many parts of Dovecot configuration use the configured separator when referring to mailboxes. This means that if you change the separator, you may break things.
We also found a better reason why in a more obscure documentation source for dovecot Migration/MailFormat - Dovecot Wiki:

Note that because Maildir uses '.' as the hierarchy separator in filesystem, it's not possible to have mailbox names containing '.' characters, even if you changed the separator in namespaces. If you really want to have dots, the only way to do this is by modifying the filesystem separator in MAILDIR_FS_SEP and MAILDIR_FS_SEP_S defines in src/lib-storage/index/maildir/maildir-storage.h file in the sources. Do not be tempted to change MAILDIR_FS_SEP et al to '/'; it won't work.
This is why if you go look at the structure of a user's INBOX it looks like this:

Code:
# doveadm mailbox list -u [email protected]
INBOX
INBOX.testing0
INBOX.testing0.testing1
INBOX.testing0.testing1.testing2
INBOX.Archive
INBOX.spam
INBOX.Trash
INBOX.Sent
INBOX.Junk
INBOX.Drafts
Bottom line being: The period is the separator for mailboxes - so when it comes in on the plus addressing dovecot see's that as hierarchical.
 
  • Like
Reactions: Matthew Swift

Matthew Swift

Member
Jun 27, 2018
5
1
3
Gloucester MA USA
cPanel Access Level
Root Administrator
Thank you very much for the thorough and useful reply, including all the links.

FWIW, this question came up in a general attempt to take a long, un-enumerated list of active email addresses given over many years to various companies and mailing lists in the form [email protected] and map them to [email protected]. The reason to do this is to be able to reject default ("catch all") mail on example.com. When <something-or-other> contains a dot, the mail gets put in an unexpected subfolder. It's not a significant problem in my application, but I expect if I wanted a solution, a more complicated regexp (in an exim filter) could substitute another character for the first finite N dots in the address (where N is more than ever would be expected).
 
Last edited:

cPanelLauren

Product Owner
Staff member
Nov 14, 2017
13,296
1,262
313
Houston
Hi @Matthew Swift


No problem! I'm glad it helped and it was pretty interesting to find out. I think, in your case, it might be best to do a filter, though I can't help but wonder if a forwarder might suffice?