Don't be too clever when serving POP-3
A user of one of our small and distant mail servers reported "missing e-mails" this morning. It turns out they weren't missing (of course), but I'd had them misplaced.
When we set up the mini mail servers, I'd taken most of Exim's configuration from the original IMAP design, and in that, I had set up automatic delivery of messages marked as spam into a Junk folder, like this:
local_maildir:
driver = appendfile
maildir_format = true
directory= ${lookup ldap{ LDAP_HOMEDIR }{$value${if eq {${substr_0_3:$header_X-SpamScore:}}{sss}{/Maildir/.Junk}{/Maildir/}}}}
delivery_date_add
...
The directory into which a message is deposited in this Maildir is retrieved from LDAP: it is the user's home directory. If the spam score in the X-SpamScore header is low, I add the string /Maildir/ to $HOME, otherwise /Maildir/.Junk/, causing messages with a highish spam score to be delivered to the named directory.
All this is fine and dandy, but it is lousy when users get their e-mail via POP3, because our Dovecot servers aren't configured to look in the Junk folder for new messages! So what was happening is that spam-marked messages were never seen by the clients.
I'd fixed that some time ago, and had deployed the change to all the servers. I thought. I seem to have missed one.
File this under "oops".

is the problem in the leading dot – making it an invisible directory?
No. The leading dot is Dovecot's folder separator — that's ok. The problem is that in a default configuration, Dovecot won't serve the content of subfolders via POP-3; only via IMAP.