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