[Dovecot] resilience suggestion

[Matthias Andree]

David Lee schrieb:
> On the whole we are pleased with our trials of dovecot to replace UW-IMAP.
> 
> But (ah!) we have hit one particular problem, in which we think dovecot
> could probably benefit from a resilience improvement.

Careful there!

> We're running dovecot on Fedora Core 5 (FC5), with passwd map details
> supplied by NIS.  We have found that "nscd" sometimes thinks that a
> username is invalid, even though it is valid.  So when "deliver" attempts
> a delivery to the INBOX of that username, it receives "user unknown" from
> the name service, and then does a 5xx permanent failure of valid email.
> From the user perspective "The System" has incorrectly rejected perfectly
> valid incoming email.  It is rare, but it does occasionally happen on
> large, busy systems.

There are several problems to this approach here, generally plain
blindness of many libc maintainers to this problem, regardless if the
system has nsswitch or no. I filed NIS lookup bugs against GNU libc (not
implementing TRYAGAIN=forever in nsswitch) and FreeBSD (timeout after a
few minutes) literally years ago, without any tangible outcome. GNU libc
 maintainer rejects the bug report as a whole, it's fallen on deaf ears
with FreeBSD.

The other important concern for a portable software as dovecot is
portability. On some systems, temporary failure of getpwnam() is
indistinguishable from permanent failure, thus the only solution to this
approach is Postfix's: implement a NIS lookup client to access the
password database to circumvent the many libc bugs lurking there.

> Clearly it is fundamentally an "nscd" bug.  But that bug is nevertheless
> out there, in the wild, on such systems, potentially affecting dovecot's
> delivery of valid user email.

You don't need nscd for unstable NIS, as laid out above :-(

> We have had a source code hack since October (in "deliver.c", simply
> replacing a "return ret" occurence with "return EX_TEMPFAIL") and it has
> worked nicely (ported forward from rc8 towards rc22).  Mail re-queues and
> a later delivery attempt then succeeds.

And lingers around in the queue for a week if an account has been
terminated? Doesn't look like a 'solution' to me.

Best regards
Matthias Andree