I've gone through and recompiled sendmail (enabling HASFLOCK) and procmail (disabling lockf()) to harmonise the locking strategies, as it seems various authors of email software over the years have pontificated with great force and wind about which locking strategy was truly FUBARed and which was not.

Naturally, different authors came to different conclusions, whilst sparing no small amount of verbiage to lash out against platforms which committed the most heinous crimes, and those whose turds are manna from heaven.

I've settled on flock (and dot-lock for writes), since NFS isn't used on yourcavesgotmail.com.

Since I have allowed a limited use of UW-imapd, which has Crispinisms (R.I.P., dear Mark) of its own, including an unyielding embrace of flock() over fcntl(), and I was NOT going to jump through the many hoops to re-build that janky code even if I could find the myriad patches I need to apply to do so, I chose the course of least pain - which still managed to involve bone knives being inserted under my fingernails all the same. (That I would willingly do this to myself should give you legitimate concern for my sanity, never mind permission to keep molesting your INBOXes.)

*BUT* in a variation of the aphorism "all things taste better with butter", all email access on hardware from the Pleistocene is better with Dovecot: faster, smoother, and more functional all-around.

Practically moribund webmail (Horde/IMP) users who had given up on it are saying they've been able to use it for the first time in years.

I cannot help but recall the housewife from _The Castle_ http://www.imdb.com/title/tt0118826/ who when asked how she made some "extraordinarily great" food item, her reply was always the same: scooped it out of the tub.

https://www.youtube.com/watch?v=PfnAhUBroF8

Because of Timo's and others' hard work, all I had to do was scoop the code out of the tarball and compile + install it.

Once I resolve the symlinked mailboxes issue, I'll be able to walk away from this completely. (Prayze beasyllabub!)

Quoting Joseph Tam-Thank-You-Ma'am jtam.home@gmail.com:

...

One last problem area is that many users have soft-links to mailboxes located on a second drive, but these never appear in folder enumeration lists or they appear grayed out in SeaMonkey/Thunderbird.

It works for me. From what I see, the ownership of the symlink is ignored; it's the underlying file that counts. Maybe a subscription issue?

I've tried changing how I symbolically linked the mailboxes, i.e., creating a sub-directory that is symlinked into the user's mail/ directory versus symbolically linking the mbox files themselves, etc. No dice. Permissions are fine. I've even resorted to changing the index locking strategy, to no avail.

Whether in Horde/IMP or current SeaMonkey, the "top-level" (symbolic link itself) shows up, but doesn't show any sub-folders of any kind.

Folders that are NOT symbolically linked work perfectly, and have various levels of hierarchy that are selectable as expected. Nothing appears in the logs.

$ cd ~/mail $ ls -l -rw------- 1 2411625 Dec 16 09:12 Dovecot lrwxrwxrwx 1 21 Jun 13 18:01 OldMail -> /u2/usermail/luser -rwx------ 8 4096 Jan 1 12:09 "Open Source Projects"

I've (rm ~/mail/.subscriptions && touch ~/mail/.subscriptions) to flush any subscriptions file issues.

The permissions seem fine. The dreaded pirate UW-IMAPD displays them without incident of any kind. When I have the user switch to UW-IMAPD under Horde, for example, the folders are fully available as expected.

$ ls -l / | grep u2 drwxr-xr-x 16 root root 4096 Jun 8 18:20 u2

$ ls -l /u2 drwxr-x--- 9 4096 Jun 14 17:07 usermail

$ ls -l /u2/usermail drwx------ 5 4096 Jun 7 01:11 luser

$ ls -l /u2/usermail/luser drwx------ 2 4096 Jun 7 01:11 OLD_INBOX drwx------ 2 4096 Jun 6 11:33 lists drwx------ 2 4096 Jun 7 01:11 saved-emails

$ ls -l /u2/usermail/luser/OLD_INBOX/ -rw------- 1 367270796 Nov 18 2016 INBOX_2016_01_to_08

Is there a subtle interaction with mail_full_filesystem_access settings, or similar that might be getting in the way?

Other data: there are fs quotas on / but not /u2. That shouldn't matter, but I will concede that I'm not a little ignorant about such things.

How might I go about further debugging this? I've tried to manually doveadm index those mailboxes, which doesn't give me any errors, but it also returns far too quickly to give me the impression that it's done anything. Same result.

When I issue IMAP commands to enumerate the mailboxes directly, I get:

$ telnet localhost 10143 127.0.0.1... Connected to localhost. Escape character is '^]'.

• OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN AUTH=DIGEST-MD5 AUTH=CRAM-MD5] IMAP ready.

A login luser ********************** A OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE NOTIFY QUOTA] Logged in

C LIST "" *

• LIST (\HasNoChildren) "/" Dovecot
• LIST (\Noselect \HasNoChildren) "/" OldMail
• LIST (\Noselect \HasChildren) "/" "Open Source Projects"
• LIST (\NoInferiors \UnMarked) "/" "Open Source Projects/Xapian"
• LIST (\NoInferiors \UnMarked) "/" "Open Source Projects/Razor"
• LIST (\NoInferiors \UnMarked) "/" "Open Source Projects/IMP-Issues"
• LIST (\NoInferiors \UnMarked) "/" "Open Source Projects/ucLibc"
• LIST (\NoInferiors \UnMarked) "/" "Open Source Projects/popa3d"
• LIST (\NoInferiors \UnMarked) "/" "Open Source Projects/Speex"
• LIST (\HasNoChildren) "/" INBOX C OK List completed (0.019 + 0.000 + 0.018 secs).

Unless dovecot is doing some kind of subscription mumbo-jumbo behind the scenes, I don't think it's a "client" problem. IMAP LIST is clearly showing the symlink, but indicating it's a child-less ghost.

I've also seen some worrying log entries, perhaps since enabling "very_down_and_dirty_mbox_syncs". This is why I went on a rampage with the rest of the code vis-a-vis locking strategies, though I'd thought dot-locks were used by all of the code when performing mbox writes.

dovecot: imap(luser): Error: Next message unexpectedly corrupted in mbox file /var/spool/mail/luser at 382669676

dovecot: imap(luser): Error: Next message unexpectedly corrupted in mbox file /var/luser/mail/luser at 383769005

dovecot: imap(luser): Error: Next message unexpectedly corrupted in mbox file /home/luser/mail/sent-mail at 37830514

Spot-checking the files don't show (obvious) corruption at or near the locations in question, so perhaps it's more of a "file changed behind my back" warning?

=M=