[Dovecot] resilience suggestion
matthias.andree at gmx.de
Wed Feb 14 16:05:58 UTC 2007
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.
> 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
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.
More information about the dovecot