Minor patches for builds against ancient platforms

[M. Balridge]

Quoting Joseph Tam <jtam.home at gmail.com>:

> If this is output on the dovecot server itself so there's no mismatch
> in pathnames.  Have you checked whether the dovecot user can traverse
> all the way from / to /u2/usermail/luser/

The dovecot user, as in the "dummy" user dovecot uses for sandboxing, or the
UID of the user logged in via IMAP through dovecot?

No, the (dovecot user) doesn't have access to the director(ies), but the
logged-in users DO.  That's no different from the mail directories in /home/*,
though, which are 0700/owned-by-their-respective-users.

I have confirmed by using "su -" to the various UIDs that they can fully
access the mailboxes behind the symlinked directories.

> I'm thinking no .subscription would be better.

Done, but it makes no difference.

> Dovecot does have chroot-ing stuff that might impede symlink following:
> 
>  	https://wiki.dovecot.org/Chrooting

I'm not running dovecot chrooted.  That's a bear of a very different species,
and one I'd not care to wrestle for this sort of setup. Maybe in a "vpopmail"
type of situation where dovecot only runs as a delegate UID where there are no
real system UIDs/GIDs for the users in question.

There's no dovecotian "AllowSymlink" analogue to Apache's FollowSymLinks
directive, I assume?  I scoured through the documentation, but didn't see
anything, but it's not the first time I've missed things in documentation.

> It seems you have more basic file access problems.

I suspect so, but it's a strange one, because (al)pine and UW-imapd have
accessed these mailboxes without any issues for many years, as much as it
comes as a shock that such decrepit software could ever be accused of
performing correctly.

> Nothing with verbose logging (set mail_debug = yes)?  Try the simple case
> 
>  	ln -s /u2/usermail/luser/OLD_INBOX/INBOX_2016_01_to_08
> ~luser/mail/testbox

Will do. My thanks, Joseph.

=M=