Deferred email with remote protocol error in reply

[Wesley Craig]

On 27 Oct 2006, at 05:08, Libor Pechacek wrote:
>> MAIL FROM:<lpechacek at fm.clnet.cz <mailto:lpechacek at suse.de>>  
>> SIZE=15311
>> RCPT TO:<test at fm.clnet.cz <mailto:flow at tormore.hwlab.suse.de>>
>> DATA
>  < 250 2.1.0 ok
>  < 250 2.1.5 ok
>  < 354 go ahead
>> .
>  < 7 lockers
>
> In this case the obvious reason for the error is the "7 lockers" line
> that leaked from BDB.  It makes only small harm itself but causes the
> next message to be bounced due to protocol error in case the LMTP
> connection is reused.  Workaround to the bounces is simple -
> "lmtp_cache_connection = no" in Postfix's main.cf.

Here's where this happens in BDB 4.3.29:

./lock/lock_deadlock.c-418-             *nlockers = 0;
./lock/lock_deadlock.c-419-             return (0);
./lock/lock_deadlock.c-420-     }
./lock/lock_deadlock.c-421-
./lock/lock_deadlock.c-422-     if (FLD_ISSET(dbenv->verbose,  
DB_VERB_DEADLOCK))
./lock/lock_deadlock.c:423:             __db_msg(dbenv, "%lu  
lockers", (u_long)count);
./lock/lock_deadlock.c-424-
./lock/lock_deadlock.c-425-     count += 20;
./lock/lock_deadlock.c-426-     nentries = (u_int32_t)DB_ALIGN(count,  
32) / 32;
./lock/lock_deadlock.c-427-
./lock/lock_deadlock.c-428-     /*

So, first thing is that the message shouldn't be written if this  
DB_VERB_DEADLOCK isn't set.  Quickly skimming the BDB code, it  
doesn't appear that this defaults on.  I'm wondering if you have:

	set_verbose db_verb_deadlock

in your DB_CONFIG file?  Once it's on, I don't see a way to turn it  
off, other than calling the set_verbose method from within Cyrus.

The larger problem is that daemons shouldn't be impacted by libraries  
that inappropriately write to stdout or stderr.  As such, lmtpd  
should have closed stdin, stdout, stderr and reopening them with,  
e.g., '/', O_RDONLY.  Accepted connections should not use file  
descriptors 0, 1, or 2, since those file descriptors are frequently  
(mis)used by underlying libraries.  This is the fatal error in inetd,  
and apparently in cyrus master?

:wes