Re: Minor patches for builds against ancient platforms

[M. Balridge]

Quoting Joseph Tam :

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

Re: Minor patches for builds against ancient platforms

[Joseph Tam]

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.


I've tested my setup by symlinking both folders and boxes with user/0700
permissions, and they all work fine.


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"


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/


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


I'm thinking no .subscription would be better.


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


Dovecot does have chroot-ing stuff that might impede symlink following:

https://wiki.dovecot.org/Chrooting


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.


It seems you have more basic file access problems.


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.


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

then

$ telnet localhost 10143
x0 login luser ***
x1 SELECT testbox

What do you get here and in your logs?

If this doesn't produce any usable diagnostics, I would pull out the
heavy duty process trace tool and trace the imap process to figure out
what it's really doing and where it's failing.

Joseph Tam 

Re: Minor patches for builds against ancient platforms

[M. Balridge]

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_
 who when asked how she made some
"extraordinarily great" food item, her reply was always the same: scooped it
out of the tub.



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 :

> > 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 root4096 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 

Re: Minor patches for builds against ancient platforms

[M. Balridge]

Timo Sirainen inscribed:

Have you set mbox_very_dirty_syncs=yes? That should be helpful.


Oh, that sounded like a risky option.

I do have mbox_dirty_syncs enabled.

Are there still "safety checks" with the extra down-and-dirty sync option?

Joseph Tam-a-lyne wrote:
> doveadm user $user
>
> which will supply the second half: it will spit out the UID, GID, home
> and mail directories of a user as specified by dovecot's
> configuration.

Yes, that outputs the UID/GID/location of user mail, which can feed a 
tool to audit and/or change directory permissions to conform to 
expectations.



This is a consequence of writing secure software: it employs least
privilege so that a fault will not result in someone being able to
mess around with someone else's mail (or indices).  GID can also
governaccess to shared mailboxes.


Sure, sure, I understand the notion, as I aspire towards "least 
privilege necessary" designs in my own software. In this case, it seemed 
that the software was throwing an error when it failed to do something 
most unprivileged processes cannot do: change the group ownership of an 
object to a group of which you're not a member.


I would certainly want log entries, sure... but an outright failure when 
ownership/u+ permissions are otherwise supportive of the operation in 
question?


I appreciate the fact my questions (and Piltdown Box) are probably 
noising up your list, and yet you're still both giving me the time of day.


My thanks, once again,
=M=

Re: Minor patches for builds against ancient platforms

[Timo Sirainen]

On 12 Jun 2017, at 2.09, M. Balridge  wrote:
> 
>> I think it's just doing a lot of work on the mbox file itself 
>> (reading/writing/rewriting). Would be nice of course if it logged 
>> more information, but mbox format is a bit too legacy to spend 
>> much time on improving.
> 
> I suspect the (heavy) use of procmail on Herr Frankbox is contributing to
> either some lock "confusion" *OR* triggering dovecot to do "expensive" mbox
> re-read/syncs or something?

Have you set mbox_very_dirty_syncs=yes? That should be helpful.

Re: Minor patches for builds against ancient platforms

[Joseph Tam]

On that note, has anyone written a tool that "harmonises" users mail
directories' permissions - ideally reading the dovecot configuration to assess
where *THE* mail directories are actually used by dovecot?


doveadm user $user

which will supply the second half: it will spit out the UID, GID, home
and mail directories of a user as specified by dovecot's configuration.


I was surprised by the pickiness of the group ownership/permissions
issues, though reflecting on things, I can see why you'd at least want
some logging by default for those conditions.


This is a consequence of writing secure software: it employs least
privilege so that a fault will not result in someone being able to mess
around with someone else's mail (or indices).  GID can also govern access
to shared mailboxes.

Joseph Tam 

Re: Minor patches for builds against ancient platforms

[M. Balridge]

David "Show Me The Vintage!" McGuire wrote:

>   I for one am finding this thread extremely entertaining.  I have to
> wonder how you'd sound if you came across a machine that was actually
> OLD. ;)

Well, I am fond of "old" hardware, which may still be on the wrong side of the
New/Old divide for some of you: DECSYSTEM-20s and VAX 11/780s were the first
"big" systems I ran across that I admired a great deal as an assembly language
programmer and software engineer in general. 

[ IBM System/3X0 systems (and EBCDIC) were horrors, though POWER & PowerPC
were very interesting for me. ] My first assembly language was Z80, though,
which spoiled me for the more primitive CPUs like 6502.

I still maintain some respect for the old iron that could seemingly gracefully
handle 200+ users, many of them hammering the system with compile jobs,
Mandlebrot set "renders", or other geek-driven nonsense, without going off
into the weeds the way a 2017 system does when you do something trivial like
enumerate a large directory of files/folders recursively.

Joseph of Tam (I am) wrote:

> If all your concerned is dovecot dot-files, you can place the 
> indices somewhere else other than the user's filesapace.

When I manually created the .subscriptions file(s) in the right places, the
error message went away, and the functionality seems to work in SeaMonkey 
clients.

I wonder if it's a combination of permissions (even though the mail
directories are all owned by their respective users), or dovecot settings... 
On that note, has anyone written a tool that "harmonises" users mail
directories' permissions - ideally reading the dovecot configuration to assess
where *THE* mail directories are actually used by dovecot?  I was surprised by
the pickiness of the group ownership/permissions issues, though reflecting on
things, I can see why you'd at least want some logging by default for those
conditions.

His Timoness boomed:

> On 9 Jun 2017, at 5.03, M. Balridge  wrote:
>> 1) In src/lib/compat.h there is a definition for p(read|write) 
>> that conflicts with the one in /usr/include/unistd.h [...]
> 
> I don't know about this. Anyway, can't apply this patch since it 
> likely fails elsewhere.

Fair enough. I knew this was unlikely to be accepted for multiple reasons,
never mind a ferociously high potential-pain:reward ratio.

I'm happy to help in my insignificant way, re: the second patch.

DO many people use filesystem quotas with dovecot much, you think?

> I think it's just doing a lot of work on the mbox file itself 
>(reading/writing/rewriting). Would be nice of course if it logged 
> more information, but mbox format is a bit too legacy to spend 
> much time on improving.

I suspect the (heavy) use of procmail on Herr Frankbox is contributing to
either some lock "confusion" *OR* triggering dovecot to do "expensive" mbox
re-read/syncs or something?

There are mail-mulching scriplets in the global procmail (tied to spamassassin
results). Some daintily direct the dross to the /dev/null paradise in the sky.
Some "consume" the mail and redirect them to one of two or three folders
within mail/, while the "rest" allow procmail to append it to INBOX. 

My question is:

Is there is smarter way to do the "delivery" so that the dovecot system is
"informed" of an append (or excision), obviating or at least reducing the need
to perform more costly re-syncs (or timeouts awaiting a lock break)?

I anticipate a thundering herd declaiming that procmail is the spawn of Satan,
Hitler, and He-who-shall-not-be-named. As someone who was responsible for much
of them (nearing 10 years ago, now), I don't disagree with that view.

I don't have the budget or mandate to bring slivers of Elysium to this
downtrodden backwater of technology. I would expect that any use of procmail
with dovecot's "special" mail storage formats would *REQUIRE* the use of
"deliver" or some other tool to properly incorporate new mail into a dovecot 
hive.

My thanks as always,
=M= 

Re: Minor patches for builds against ancient platforms

[Joseph Tam]

I do know that this little box of horrors has 200-300MB mbox INBOXes on an
ext3 filesystem formatted in 2005.  I am very nervous about converting them to
Maildir at this point.


Fortunately, it just involves reformatting the data and a little
reconmfiguration of dovcot.  If you can find the tool and disk space,
it's well worth doing.  Of course, when running a proverbial dinosaur,
you're often more preoccupied with preventing the next proverbial
meteorite strike.


What I meant was, are certain types of filenames "blocked" by policy from
being created via IMAP commands?  I'm sure I could run a few tests to answer
this for myself, or better still, go through Timo's code.


I never saw anything that could do that -- maybe you can torture the
virtual mailbox facility to get that done.  If all your concerned is
dovecot dot-files, you can place the indices somewhere else other than
the user's filesapace.


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.  I've tried
just symbolically linking to directories containing other mboxes, but
sometimes it works, and sometimes it doesn't.  I wonder if there's
paranoia checking in the code that follows symbolic links to ensure
that uids/gids of the "owning" directory and the linked-to directory
(or files within it) are the same.


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?

Joseph Tam 

Re: Minor patches for builds against ancient platforms

[Dave McGuire]

On 06/09/2017 05:13 PM, M. Balridge wrote:
> I do know that this little box of horrors has 200-300MB mbox INBOXes on an
> ext3 filesystem formatted in 2005.  I am very nervous about converting them to
> Maildir at this point.  If I could get someone (or something) to the site and
> replace it with something much more suitable, I could have these people join
> the 21st Century.

  I for one am finding this thread extremely entertaining.  I have to
wonder how you'd sound if you came across a machine that was actually
OLD. ;)

  -Dave

-- 
Dave McGuire, AK4HZ
New Kensington, PA

Re: Minor patches for builds against ancient platforms

[M. Balridge]

> >> Warning: Transaction log file
> /home/luser/mail/.imap/INBOX/dovecot.index.log
> >> was locked for 95 seconds (rotating while syncing)
> 
> Timo recently explained to me it's probably caused by slow I/O or
> processing.  This explanation is consistent with my observation that
> the users who get these messages have jumbo mailboxes.

I do know that this little box of horrors has 200-300MB mbox INBOXes on an
ext3 filesystem formatted in 2005.  I am very nervous about converting them to
Maildir at this point.  If I could get someone (or something) to the site and
replace it with something much more suitable, I could have these people join
the 21st Century.

> You can disable dotclock altogether, but I don't think this is what you
> meant.  You can use locking method "dotlock_try" rather than "dotlock"
> -- the former will ignore quota/permissions problems and plow on.
> (It still logs it.)  You could also align luser's mail folder group with
> with luser's GID, which is usually what I do.

What I meant was, are certain types of filenames "blocked" by policy from
being created via IMAP commands?  I'm sure I could run a few tests to answer
this for myself, or better still, go through Timo's code.

> Maybe locks are created even when files don't exist as there may
> be a race condition where another process is creating/deleting it at
> the same time.

Sure, I could see that.  In reading through the locking code of sendmail,
dovecot, UW-IMAPD, and procmail, it's clear that locking files under UNIX is
chaotic and filled with no small amount of voodoo.  And naturally, opinions
and implementations radically disagree. (How sensible it was of Timo to make
it a RUNTIME configuration option in dovecot.)

I appreciate your reply, Joseph.

48 hours after switching half of the userbase to dovecot, I am not seeing any
serious problems, and already people are more often than not very pleased by
the improved performance and responsiveness.

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.

I've tried just symbolically linking to directories containing other mboxes,
but sometimes it works, and sometimes it doesn't.  I wonder if there's
paranoia checking in the code that follows symbolic links to ensure that
uids/gids of the "owning" directory and the linked-to directory (or files
within it) are the same.

I'm still trying to absorb all of the documentation for dovecot.

=M=

Re: Minor patches for builds against ancient platforms

[Timo Sirainen]

On 9 Jun 2017, at 5.03, M. Balridge  wrote:
> 1) In src/lib/compat.h there is a definition for p(read|write) that conflicts
> with the one in /usr/include/unistd.h
> 
> On this box, there is a macro appended to the definition (to control whether
> or not THROW is defined in C++ "mode").  This is regulated by using the macro
> __THROW.  I assume this is anachronistic.

I don't know about this. Anyway, can't apply this patch since it likely fails 
elsewhere.

> 2) There was an odd overflow bug in the quota module. (Yes, would you believe
> that user quotas are used + enforced on this Frankenbox?)  I assume it's a
> rarely seen issue because few Dovecot users compile the software in caves on
> computers powered by horse-pulled generator wheels.  I suspect Timo's seen
> more Abominable Snowcreatures in Espoo than systems like these.
> 
> Simply adding an explicit 64 bit (unsigned) type to the constant multipliers
> seemed to address this. Of these two patches, this is probably the most "safe"
> and thus likely to be accepted into the main branch of code.

Yeah, I'll add that one. Not really sure if that's a generic 32bit problem. 
Nobody has previously complained about it though.

> Thanks for the great software, as always, Timo. It's a testimony to your
> design and implementation acumen that software you've written in 2017 still
> runs on machines that went obsolete in 480 B.C.E.

For a long time Dovecot supported C89 compilers, but nowadays we at least 
require proper C99 compilers..

> I am trying to track down one possible issue that could be locking-related,
> which causes some mailbox open operations to see to take longer than they
> should. Log entries like:
> 
>> Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log
>> was locked for 95 seconds (rotating while syncing)
> 
>> Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log
>> was locked for 92 seconds (rotating while syncing)

As Joseph mentioned, this is likely happening because Dovecot is doing a lot of 
work while keeping the log file locked. The "rotating while syncing" is 
probably not the real reason. I think it's just doing a lot of work on the mbox 
file itself (reading/writing/rewriting). Would be nice of course if it logged 
more information, but mbox format is a bit too legacy to spend much time on 
improving.

> imap(luser): Error: fchown(/home/luser/mail/.subscriptions.lock,
> group=501(coregroup)) failed: Operation not permitted (egid=200(users), group
> based on /home/luser/mail - see http://wiki2.dovecot.org/Errors/ChgrpNoPerm)
> 
> imap(luser): Error: file_dotlock_open() failed with subscription file
> /home/luser/mail/.subscriptions: Operation not permitted
> 
> .subscriptions doesn't exist either as a file or a directory in the named
> directories.

Client is trying to subscribe, and Dovecot wants to create subscriptions file. 
Dovecot wants to preserve the group permissions from the /home/luser/mail 
directory, but it has no permission to set the file's group to "users", so it 
aborts. You could chmod 0700 /home/luser/mail if possible.

> Is there a "filter" against dot-files being opened within the bowels of 
> dovecot?

The problem above isn't dotlock, but rather the file permission preservation in 
general.

Re: Minor patches for builds against ancient platforms

[Joseph Tam]

"M. Balridge"  writes:


I assume it's a rarely seen issue because few Dovecot users compile the
software in caves on computers powered by horse-pulled generator
wheels.


I resemble that remark.


Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log
was locked for 95 seconds (rotating while syncing)


Timo recently explained to me it's probably caused by slow I/O or
processing.  This explanation is consistent with my observation that
the users who get these messages have jumbo mailboxes.


imap(luser): Error: fchown(/home/luser/mail/.subscriptions.lock,
group=501(coregroup)) failed: Operation not permitted (egid=200(users), group
based on /home/luser/mail - see http://wiki2.dovecot.org/Errors/ChgrpNoPerm)

imap(luser): Error: file_dotlock_open() failed with subscription file
/home/luser/mail/.subscriptions: Operation not permitted

.subscriptions doesn't exist either as a file or a directory in the named
directories.

Is there a "filter" against dot-files being opened within the bowels of dovecot?


You can disable dotclock altogether, but I don't think this is what you
meant.  You can use locking method "dotlock_try" rather than "dotlock"
-- the former will ignore quota/permissions problems and plow on.
(It still logs it.)  You could also align luser's mail folder group with
with luser's GID, which is usually what I do.

Maybe locks are created even when files don't exist as there may
be a race condition where another process is creating/deleting it at
the same time.

Joseph Tam 

Minor patches for builds against ancient platforms

[M. Balridge]

I was recently asked to upgrade some neolithic aged software (UW-IMAP,
sendmail 8.12.x, apache 1.3, amongst other horrors).

The box is physically remote, so an aggressive "new flush" wasn't an option. 
I've been able to upgrade the compiler to gcc-3.4, openssl to 1.0.2k, glibc,
php to something in the 5.4-branch, etc.

I have CLucene working, even.

I know should take a shotgun to the box and retire it. It's a NORTHWOOD P4, no
less, with only 1.5GB RAM and 74GB of SCSI-160 storage.

*BUT* that isn't my call to make, as much as I'd like to do the right thing.

When Life(tm) hands you incredibly sour and bitter oranges, the best you can
do aside from making a Palmetto Punch, is perhaps traditional Cochinita pibil
the way they do in the Yucatan.

I ran across two main problems, the first of which struck during the build.

Amazingly enough, I was able to update pcre, gettext, openssl, textcat, and
other libraries to modern versions without too much pain and suffering.

1) In src/lib/compat.h there is a definition for p(read|write) that conflicts
with the one in /usr/include/unistd.h

On this box, there is a macro appended to the definition (to control whether
or not THROW is defined in C++ "mode").  This is regulated by using the macro
__THROW.  I assume this is anachronistic.

2) There was an odd overflow bug in the quota module. (Yes, would you believe
that user quotas are used + enforced on this Frankenbox?)  I assume it's a
rarely seen issue because few Dovecot users compile the software in caves on
computers powered by horse-pulled generator wheels.  I suspect Timo's seen
more Abominable Snowcreatures in Espoo than systems like these.

Simply adding an explicit 64 bit (unsigned) type to the constant multipliers
seemed to address this. Of these two patches, this is probably the most "safe"
and thus likely to be accepted into the main branch of code.

Thanks for the great software, as always, Timo. It's a testimony to your
design and implementation acumen that software you've written in 2017 still
runs on machines that went obsolete in 480 B.C.E.

I am trying to track down one possible issue that could be locking-related,
which causes some mailbox open operations to see to take longer than they
should. Log entries like:

> Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log
> was locked for 95 seconds (rotating while syncing)

> Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log
> was locked for 92 seconds (rotating while syncing)

I am using sendmail 8.15.2 (HASFLOCK not defined) and procmail 3.22 (Locking
strategies: dotlocking, fcntl(), lockf(), flock())

I also see odd errors while using SeaMonkey clients:

imap(luser): Error: fchown(/home/luser/mail/.subscriptions.lock,
group=501(coregroup)) failed: Operation not permitted (egid=200(users), group
based on /home/luser/mail - see http://wiki2.dovecot.org/Errors/ChgrpNoPerm)

imap(luser): Error: file_dotlock_open() failed with subscription file
/home/luser/mail/.subscriptions: Operation not permitted

.subscriptions doesn't exist either as a file or a directory in the named
directories.

Is there a "filter" against dot-files being opened within the bowels of dovecot?

Onto the "meat" of this "bug" report:

Dovecot: dovecot-2.2.30.2 
Slackware 9 (with most of the core libs upgraded to the latest possible)
Kernel: 2.4.35-ow2

Configure command: CC=gcc-3.4 CXX=g++-3.4 \
CFLAGS='-O2 -march=pentium4 -mtune=pentium4 -fPIC -fPIE \
 -fomit-frame-pointer -fstack-protector-all -D_FORTIFY_SOURCE=2' \
CFLAGS='-O2 -march=pentium4 -mtune=pentium4 -fPIC -fPIE \
 -fomit-frame-pointer -fstack-protector-all -D_FORTIFY_SOURCE=2' \
CPPFLAGS=-I/dev/shm/libstemmer_c/include \
LDFLAGS='-L/dev/shm/libstemmer_c -z relro -z now' \
./configure --prefix=/usr --with-ssldir=/etc/ssl --localstatedir=/var \
--sysconfdir=/etc/dovecot --with-bzlib --with-libcap --with-lz4 \
--with-textcat --with-stemmer --with-sql=yes --with-cdb \
--with-shadow --with-libwrap --with-moduledir=/usr/lib/dovecot \
--with-icu --with-lucene --with-sqlite --with-sql=yes

Build fix patch (mismatching prototype): https://pastebin.com/GS3a2DPX
Quota Overflow Fix Patch: https://pastebin.com/gsSXmkz9

Dovecot configuration: https://pastebin.com/JX43feFw

Without the patch:

# doveadm quota get -u luser
Quota name  Type  Value   Limit%
User quota  STORAGE 3365836 1305696  257
Group quota STORAGE   0   -0

(All attempts to add mail to any folder fail with a quota error.)

With the patch:

# doveadm quota get -u luser
Quota name  Type  Value   Limit %
User quota  STORAGE 3364608 55061
Group quota STORAGE   0   - 0

Thanks,
=M=