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 dovecot@r.paypc.com 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=

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=