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 at 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=