sieve authentitcation problem
I have been hapily running cyrus-imapd 1.6.24 for some time. My mail server is a black box: the users have no local accounts; imapd.conf instructs cyrus to authenticate via PAM and /etc/pam.d/imap uses pam_ldap.so to get user data from an OpenLDAP database. It all works beautifully. I do not use the SASL database at all; it is completely empty. Now I want to get sieve scripts working. When I telnet mailserver sieve then timseived answers. But when I installsieve -u username mailserver and enter username's password, it barfs, saying Authentication failed with: "user not found" Authentication failed. Packet sniffing reveals that the LDAP database was never querried. What is going on? Why doesn't timsieved use PAM just like imapd? Do I need an /etc/pam.d/sieve entry? Must I need to use the SASL database? Help, please!
signaled to death by 11 -- solved!?
I am faced with the same "signaled to death by 11" problem on RH 7.1 that has been reported in this list several times before. I think I understand the problem, but I need a little coaching to implement a solution. Here's the problem: whenever I login correctly, # telnet localhost imap Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is '^]'. * OK sartre.rprc.washington.edu Cyrus IMAP4 v2.0.16 server ready . login Connection closed by foreign host. the connection closes, and the spawned imapd process imapd[16162]: login: localhost.localdomain[127.0.0.1] plaintext imapd[16192]: pam_ldap: ldap_set_option(LDAP_OPT_X_TLS_REQUIRE_CERT): Unknown error imapd[16192]: pam_ldap: _set_ssl_options failed master[16154]: process 16192 exited, signaled to death by 11 dies ignominiously. I am using sasl_pwcheck_method: PAM and pam_ldap to authenticate against an OpenLDAP database. Note that pam_ldap complains that it has been passed an option LDAP_OPT_X_TLS_REQUIRE_CERT with which it is unfamiliar My guess is that the LDAP_OPT_X_TLS_REQUIRE_CERT option is the problem. Needless to say, that means the the previously touted explanations regarding Berkley DB linking problems are red herrings. So... how can I get cyrus-imap not to require TLS for a plaintext login? I realize the cyrus team thinks they are doing me a favour by requiring this, but there really needs to be a simple way to disable it in configuration files. Also, imapd certainly shouldn't be comiting suicide just because a PAM module doesn't understand its request for some exceedingly obscure LDAP_OPT_X option. Additional information of dubious use, follows.. If I login with an incorrect password, # telnet localhost imap Trying 127.0.0.1... Connected to localhost.localdomain. Escape character is '^]'. * OK sartre.rprc.washington.edu Cyrus IMAP4 v2.0.16 server ready . login . NO Login failed: authentication failure the authentication fails, but nobody dies. If I use another PAM module instead of pam_ldap, for example the trivial pam_permit, which always returns success, it all works. I (and, of course, everyone else in the world) can login successfully, and nobody dies! However, lest you think that a hopelessly buggy pam_ldap is the problem, you should know that the selfsame pam_ldap is working fine with about 42 other services I offer (login, netatalk, passwd, samba, ssh, ...) including an old cyrus-imapd-1.6.24 installation on another machine. The relevant version numbers are cyrus-imapd-2.0.16 (compiled from source) cyrus-sasl-1.5.24 (from cyrus.sasl-1.5.24-17.i386.rpm) Berkely DB 3.3.1 (from db3-3.1.17-7.i386.rpm) pam_ldap-122 (compiled from source) in case that helps anyone.
Re: signaled to death by 11 -- solved!?
> BTW, what is the fastest route? > imap -> sasl -> pam-ldap -> ldap server > imap -> sasl -> ldap server The fastest route to me seems to be: imap -> pam_ldap -> ldap sever Can we PLEASE produce a version of cyrus-imap imap WITHOUT SASL? PAM may be a smidgeon less flexible, but it is simplier, more widely used and supports many more authentication methods. Eliminating SASL might make life harder for the (guestimated) 10% of cyrus-imap sites that really use it, but it would make life immeasurably easier for the remaining 90% who spend countless hours just trying to circumvent it! Seriously, can someone who knows the code comment on how difficult it would be to replace SASL with another mechanism?
Re: signaled to death by 11 -- solved!?
> What's wrong with having both PAM and SASL in the implementation? And > isn't this the case? I'm still using Cyrus IMAP 2.0.13 so maybe PAM > has been removed since, but I would be surprised. PAM has never been in the distribution. SASL is in the distribution and PAM is supported by SASL. That sounds fine in theory, but in practice it appears that SASL's PAM support has some problems.
Re: signaled to death by 11 -- solved!?
I have spent more time investigating the interaction of pam_ldap and SASL, and have narrowed down the problem considerably, but still not quite "got it". The TLS options seem also to be the wrong direction; I can eliminate TLS/SSL and the problem persists. By inserting lots of debug code, I have found out where in pam_ldap the problem lives. When SASL calls pam_authenticate, the pam_sm_authenticate subroutine in pam_ldap.c gets run. This routine calls pam_get_user and pam_get_item to obtain the username and password from imapd; do problem occurs here and it gets the right username and password. It then calls a routine named _do_authentication to check these against the ldap database. Now when _do_authentication is run against a correct password, it returns success and pam_ldap returns success, but imapd dies. If I comment out the call to _do_authentication and just return success, imapd does not die. So it would seem the problem lies with _do_authentication. But here is the wierd part -- as far as I can tell, _do_authentication does not interact with imapd or the SASL library at all; it contains only LDAP library calls to interact with the LDAP server! And remember, this interaction doesn't generate any errors, but rather runs flawlessly and returns success. It seems, though, that a side-effect of this interaction is to screw up the imapd so badly that it dies with a "signaled to death by 11". ??? I do not understand! ? Can anyone explain to me how this might happen? Does OpenLDAP interact with SASL somehow? I will also forward this to the pam_ldap list.
Reality Check
Does ANYONE have the following configuration working? cyrus-imapd-2.0.x authenticating via LDAP using sasl_pwcheck_method: PAM and the pam_ldap module If so, please chime in to say on what system and how you got it to work. I can't imagine this configuration is obscure: LDAP is the preemininent large-scale directory server, cyrus-imapd the preemininent large-scale imap server, and PAM the preeminent authentication system. If everyone is having the problems I am, this is a disaster for cyrus-imapd.
OpenLDAP 2.0.x + pam_ldap + cyrus-imapd-2.0.x
I and quite a few other users of the cyrus-imapd system have found a problem which occurs exclusively when we authenticate using the PAM module pam_ldap linked against the OpenLDAP 2.0.x libraries. I am writing to ask whether this bug and any potential solutions are known to the wider OpenLDAP and pam_ldap communities. The basic problem is that, with the authentication scheme mentioned, imapd segfaults when pam_ldap returns success. Like anyone presented with this problem, I initially presumed the problem lay with cyrus-imapd (or with the cyrus-sasl library it uses). More careful investigation tends to case suspicion elsewhere: 1) The problem does not occur with any other PAM module, or with a patch which allows SASL to authenticate via LDAP directly. That would tend to cast suspicion on pam_ldap, but... 2) pam_ldap works fine with dozens of other applications. That would tend to cast suspicion on cyrus-imapd or the cyrus-sasl library. Hmm, we seem to be going in circles here. 3) By commenting out sections of pam_ldap, printing debug messages, etc, I found that the problem occurs only when the _do_authenticate subroutine in pam_ldap.c is executed. There is no PAM code in that subroutine, only calls to OpenLDAP routines! This is very wierd: the PAM exchange between cyrus-imapd and pam_ldap runs without a hitch; the LDAP exchange between pam_ldap and my OpenLDAP server also runs without a hitch. Yet the latter (not the former!) exchange seems to have the side-effect of killing the cyrus-imapd server. 4) The above behaviour occurs even when the OpenLDAP server is on a different machine, so it can't be the server that is causing the side-effect. The side effect must be the fault of the client LDAP libraries. Or of cyrus-imapd/sasl for being susceptible to the side-effect. 5) This conclusion is strengthened by the observation (due to Phillip Sacha) that when pam_ldap is linked against OpenLDAP 1.x or Netscape-LDAP libraries, the problem goes away... even when authenticating against an OpenLDAP 2.0.x server. This would seem to lay guilt on OpenLDAP libraries rather then cyrus-imapd/sasl. Finally, two more incidental observations: a) Entering a wrong password does not kill imapd. Furthermore, if I first enter a wrong password, then a right password, I can log in without killing imapd. pam_ldap seems to cache some info during a session, and it's not having to look up that info a second time prevents the side-effect. This may provide a clue as to which OpenLDAP APIs are at fault. b) Several people (eg Norbert Sendetzky) have reported that the precompiled pam_ldap binary distributed by RedHat does work. Use of ldd reveals that it is linked against the OpenLDAP 1.2.x client libraries. Can any usrers and/or devs provide more detailed observations which would allow us to identify the guily party and file a clear bug?
Re: Reality Check
Phillip Sacha, thanks so much for pointing out that pam_ldap works when linked gainst the OpenLDAP 1.x libraries. Norbert Sendetzky also point out that Red Hat's precompiled pam_ldap also works, and ldd reveals that to be linked against libldap.so.1 and liblber.so.1 -- the OpenLDAP 1.x libraries. My question is how to compile pam_ldap against the 1.x libraries. I have the 1.x shared objects liblber.so.1 and libldap.so.1 present on my RH installation from the openldap12 rpm, but my libldap.a and liblber.a development libraries are from 2.x. I believe the -lldap -llber command line options will therefore link against the 2.x libraries. I don't suppose you know a way to link directly to shared objects? Assuming not, how can I download the 1.x development libraries and get pam_ldap to compile against them without clobbering the 2.x libraries? -- I still want other projects to link against them. Thanks for your help.
SASL re-entrancy crisis (was: OpenLDAP 2.0.x + pam_ldap + cyrus-imapd-2.0.x)
First off, thanks to you, Lawrence, and the many others who helped clarify why OpenLDAP 2.0.x + pam_ldap + cyrus-imaps-2.0.x won't play together out-of-the-box. For those just tuning in to this thread, it's because the SASL routines are (1) used both by cyrus-imapd and OpenLDAP and (2) not re-entrant, so memory gets deallocated by one while the other is still trying to use it. Poof -- core dump. CMU people, please don't take the following personally; your work is impressive and appreciated. But some things about it are less than useful off the CMU campus, and I think SASL is one of them. My reasoning is simple: A non-re-entrant security layer is contradiction in terms. Security layers are designed to be ubiquitous -- if SASL works out as planned, every application involved in authentication will link to it. Problems like these would be a dime a dozen (which is one reason SASL will not become ubiquitous). I think for most applications PAM is a much better alternative. It is inherently simpler. It can support ticket systems by using Kerberos. It can support access restrictions based on time-of-day, IP-address, and such, which (correct me if I'm wrong) SASL cannot. If is far more widely used and easily understood. One PAM critic on this list said that PAM is easy to misconfigure, which is true, but if we were all held back by stuff like that we'd be using Macs. The philosophy of Unix is to give you enough rope to hang yourself... and then a bit more for good measure. Of course, one can always claim that SASL doesn't hurt anything, since it can call PAM. But my experience has proven the falacy of the doctrine of harmless layers. It turns out to be even more difficult than planned for me to avoid the re-entrancy problem, because the LDAP encyption of OpenLDAP 2.0.x gets broken when compiled --without-cyrus-sasl, and OpenLDAP 1.x doesn't have any encryption, and I need my LDAP communications encrypted (which is why the sasl-ldap patch also isn't an option). Which leads me to repeat my earilier question: how hard would it be to replace SASL with PAM, thus producing, IMHO, a more useful imap server for sites other than CMU. Basically this comes down to the question: how many calls to SASL library APIs are there in cyrus-imapd? 10? 100? 1000? If it's less than 100 I'd give it a try myself. Thanks for listening, David
Re: SASL re-entrancy crisis (was: OpenLDAP 2.0.x + pam_ldap + cyrus-imapd-2.0.x)
Please educate me, I do not understand. > Please use pwcheck. Your problems will go away. The pwcheck distributed with cyrus-sasl is not useful to me. My users are not in /etc/passwd -- they are ONLY in an LDAP database. Even a pwcheck daemon that uses LDAP is only useful to me it does LDAP-SSL -- I need password traffic encyrpted over the network. pam_ldap does this nicely, so any pwcheck daemon that did all this would basically be re-implementing the functionality of pam_ldap. Can you kindly point me to a pwcheck daemon that just calls PAM? > PAM does not do network authentication. PAM does not solve the > problems under consideration. What do you mean by "network authentication"? If you mean a ticket system so that users need only authenticte themselves once, it most certainly does, via Kerberos. If you mean certifying the identity of the client and server machines, pam_ldap and OpenLDAP can do that. What exactly is the problem under consideration that (given the appropriate modules) PAM doesn't solve?
turning off AUTH=CRAM-MD5
Cyrus-imapd (1.6.24) insists on advertising AUTH=CRAM-MD5, even though this is a lie. This is (I think) one of the (many bad) side-effects of SASL -- because of SASL cyrus advertises this AUTH, but in fact my sasldb is utterly empty (all authentication is via PAM) and so any client that takes cyrus up on the offer gets told the user doesn't exist. So... how can I get cyrus to stop advertising AUTH=CRAM-MD5?
imapd hangs
I am running a locally compiled cyrus 2.0.16 on a Red Hat 7.1 system.
Twice now one of my users (only one, but this one happens to be my
boss!) has observed a wierd, transient failure mode: in this mode, imapd
hangs on any attempt to write to a folder. Here is an example, caught by
ethereal:
000c LIST "" inbox.Sent
* LIST () "." "inbox.Sent"
000c OK Completed (0.000 secs 2 calls)
000d APPEND inbox.Sent {353}
That's it -- no word from imapd ever again. Here, for reference, is how
it's supposed to look:
0006 LIST "" inbox.Sent
* LIST () "." "inbox.Sent"
0006 OK Completed (0.000 secs 2 calls)
0007 APPEND inbox.Sent {355}
+ go ahead
Date: Mon, 26 Nov 2001 22:25:29 -0800 (PST)...
0007 OK [APPENDUID 1001546367 273] Completed
But in the hanging mode, the client never gets a "+ go ahead" from
imapd. Once this behaviour starts, it occurs for any imapd process that
my boss creates until the cyrus master process is killed and restarted.
It does not occur for other users' imapd processes, even while it is
occuring for my boss's. Mail delivered via lmtp continues to arrive
normally in my boss's inbox, even while this is occuring. The last time
this occured (about 10 days ago), I reconstructed my boss's mailboxes
and assumed that was that, but today it happened again.
My boss uses the same clients (netscape and pine) as most of my other
users. The only thing unusual about his account is its size: 246 MB
distributed over 299 folders (we have no quotas). I am wondering if
sometimes an operation on a large file or directory might time out and
leave cyrus in an inconsistent state.
One last piece of information: when setting up cyrus, I chose to ignore
the documentation's advice to set the user, quota, and partition
directories to update synchronously. The documentation implies that the
only consequence of this is possible data loss during a hard shutdown,
and since that has never happened to us (our server has a UPS and we a
re in a hospital with its own emergency power) I choose to accept that
risk. I am now wondering if asynchronicity might have additional
consequences.
That's the story. Any ideas? Can anyone suggest a way to get more
information out of cyrus, e.g. an strace or ltrace of a running imapd
process so I can see what it is doing when it dies?
Configuring Cipher Strength
For SSL/TLS connections, is there some way to tell cyrus-imap what sorts of encryption to allow? Apache's mod_ssl, for example, has the SSLCipherSuite directive, which I use thusly: SSLCipherSuite HIGH:+MEDIUM:-LOW:-EXP:-ADH:-NULL The touble with simply allowing all ciphers supported by OpenSSL is that OpenSSL has support (as it should) for some weak algorithms and some old algorithms now known to be broken.
selecting ciphers for imapd SSL/TLS
A while back I wrote to the list asking about how by specify the SSL/TLS cipher algorithms that cyrus imapd should accept (by analogy with the SSLCipherSuite directive from Apache's mod_ssl). I didn't receive a reply (which is fine) so now I want to verify: is it true that there is no way to specify which cipher algorithms cyrus imapd should accept? I think this should be considered a rather large security hole. I believe OpenSSL will even negotiate down to the NULL cipher (i.e. no encryption) if a client claims that is all it will accept.
Re: Which module in cyrus provides return receipt ?
Hi Ted! :-) > I was wondering which module in Cyrus provides return receipt ? Return receipt is traditionally provided by the mail client (outlook, netscape, pine, eudora), not the mail server. Unlike return recepit from the post office, which is a service the transport agent provides the sender, it is a service the receipient may choose to provide the sender. The only systems I know that can be configured to provide "enforced" return receipt are corporate end-to-end solutions like Exchange.
Re: Signaled to Death by 11 - Again
>>Anything look familiar or obvious? Suggestions? Familiar, anyway. Looks like the old SASL re-entrancy problem to be. Try rebuilding your OpenLDAP libs --without-sasl and linking pam_ldap to them.
Re: Signaled to Death by 11 - Again
>>Anything look familiar or obvious? Suggestions? Look familiar, anyway. It looks like the inevitable SASL reentrancy problem. Try rebuilding your LDAP libs --without-sasl and then linking pam_ldap to the new libs.
Re: LDAP accounts for Cyrus patch questions
Since there is such as SASL love-fest going on here, allow me to chime in with my dissenting viewpoint. SASL adds nothing but an annoying dependency to LDAP. No, I take that back, it also adds a security hole. Challenge-response mechanisms have absolutely no advantage over straight password transmittion across an SSL/TLS encrypted line. In fact, if they run in cleartext, they have a few disadvantages: (1) No server certificate authentication. (2) If you watch challenge-response a few times, you can get a good deal of the way toward decrypting the password. Furthermore, in order to support multiple authentication mechanisms, SASL must store password essentially in cleartext (i.e. not in a hased form). That means if anyone ever gets access to your sasldb, you are hosed. Not true for an LDAP database, stores passwords in hashed form. The only advantage of a security layer is flexibility: allowing authentication via arbitrary backeds (LDAP, SQL, passwd, shadow, kerberos). While SASL makes this possible in theory, I have not had good experiences in trying to make use of this flexibility -- there is very little in the way of widely-distributed, well-tested, well-supported, drop-in code to do all this stuff. Finally, Birger, what's "really creative" about by self write by anonymous auth by * none ?
Re: LDAP accounts for Cyrus patch questions
>>Finally, Birger, what's "really creative" about >> >> by self write >> by anonymous auth >> by * none >> >>? > > So how do we get these toys together if one > > 1. is going to protect user information based on "by self write" - you > first have to see what "self" is! - and > > 2. has, to faciliate 1., authenticate someone based on user information > > which will always result in a request loop? Umm, I don't know whether what you said went completely over my head or whether what I said went completely over your head. The ACLs that I wrote are literal (the characters s-e-l-f appear in slapd.conf) and work as advertised. When you bind to LDAP, you specify your dn and userPassword. That tells ldap who "self" is, and if the userPassword matches, it believes you. No "request loop" occurs. End of story. Of course, in this non-SASL scenario, you loose flexibility in the ways you can authenticate yourself to the LDAP server. But someone using this scenario has already bought the philosophy that the LDAP server will be the password store, so he hasn't lost anyting. (Anyone wanting an even more serious security backend could use Kerberos without SASL, too.) Once you accept LDAP as a backend, you can use a security layer (e.g. SASL or PAM) to allow other applications to authenticate off it.
Re: LDAP accounts for Cyrus patch questions
> Putting the password over the wire is always a bad idea. If there were no downside to challenge-response, I'd agree. But if the price is storing my passwords unhashed, I'm not willing to pay it. All my sites use MD5 or SHA hashing, which OpenLDAP supports. > Maybe I'm a dork for buying into Kerb, but hey, I'm sold, sue me. Sasl > seems like the best way to abstract kerb out to LDAP, cyrus, etc. Kerberos is the gold standard, I can't disagree there. But if Kerberos abstraction is your only metric for a security layer, why not just have everyone compile in libkrb and forget about the security layer alltogether? :-) > To be fair, I said that. Apologies, Birger.
Re: Error message when deleting
> When I attemp to delete a message from the client I receive the message > that The IMAP copy failed. It sounds like you have a client that deletes by moving to a Trash folder, and you don't have a Trash folder. Make sure the client is configured so that delete means "mark message as deleted."
Re: cyrus imap playing nicely with pam and Spam assassin
> I'm trying to make Cyrus IMAP work with Pam for authentication. > sasl_pwcheck_method: saslauthd You want: sasl_pwcheck_method: PAM Go on from there, and come back when you encounter the SASL re-entrancy bug.
Re: cyrus imap playing nicely with pam and Spam assassin
> SASLv2... Sorry! Rob is of course right wrt SASLv2.
2.0 to 2.1 migration procedure
I'm about to try out imapd-2.1.4 (as packaged by Henrique for Debian). I am currently running imapd-2.0.16 (custom-compiled) on a different machine. Can somone point me to tips for how to migrate my users and their mail? Do I just need to copy over the mailbox directory hierarchy and run reconstruct? Or do I also need to import and/or reconstruct the metadata?
Re: Migrate From 2.0 to 2.1.4
> doc/install-upgrade.html This information assumes you are upgrading on one box. My situation (and I suspect it is the situation of most production systems) is having 2.1 set up clean (i.e. no mail or metadata) on a second machine, and now I want to get all the mail from my 2.0 machine to it, without upgrading the 2.0 machine. This insures that falling back to the old server is trivial, in case the upgrade fails. The documentation doesn't discuss at all how to transfer mailstores between machines. I think this is what Patrick and I both want to know.
Re: unixhierarchy/altnamespace & IMAP folders, bug?
> When I use the unixhierarchy/altnamespace options in imapd.conf I can't > create sub-folders in the main inbox but I can create folders outside the > main inbox and then create subfolders in those. When I turn > unixhierarchy/altnamespace off then I can create subfolders in the main > inbox but not outside of it. > I'm pretty new to imap... is this correct behaviour? Yes. Under "normal circumstances" (altnamespace off), only the INBOX (and its subfolders) belong to the user, so he cannot create any folders outside it. Trouble is, this differes from the UW IMAP server, which allows personal folders outside the INBOX hierarchy, and many people had got used to that behaviour. Altnamespace placates these people by making subfolders of the INBOX look like seperate top-level folders. Of couse, as a side-effect, INBOX becomes something special which cannot have subfolders. I prefert to train my users in the Cyrus way of thinking and leave the altnamespace off.
imapd timeout
Using 2.0.16 on Linux 2.2.19. I am having trouble with imapd daemons hanging around for a long time. I currently (21 May) have some imapd daemons that have been hanging around for over two weeks (4 May). It is just possible that a couple users have been sending keep-alives that long, but I have a lot more than a couple. I don't set any timeout parameter in imapd.conf, so according to man imapd.conf, it should default to 30 minutes. Is this not true? Does cyrus perhaps "recycle" imapd processes rather than killing them and starting new ones? If so, what is the logic behind this? (Unix forking is remarkably fast, and starting fresh each time seems much safer/cleaner.) Do I perhaps need to set some /proc/sys/net/ TCP timeout parameter? All help is appreciated.
Re: imapd timeout
> Cyrus does recycle processes. Unix forking is amazingly slow compared > to not forking and on servers that receive many connections a second > this performance tweak is vital. That explains it; thanks for the explanation. (Still, even 10 forks/second seems entirely do-able. While I don't dispute the principle, I'd think you'd need to get closer to 100 forks/second before forking bottlenecks would become as important as disk I/O bottlenecks.)
Re: cyrus imap without sasl
> Because we think that there is no need to use SASL library in the > middle of the way to authenticate via PAM+mysql. Isnt it a better > performance issue? Or we are completely wrong? It's true, there isn't a need, meaning Cyrus could have been designed to use PAM directly as a security layer and not used SASL. On the other hand, there is a need, because Cyrus wasn't designed that way. Cyrus-IMAP has no idea how to authenticate via PAM. It only knows how to use SASL. (Fortunately, saslauthd knows how to use PAM.) PAM and SASL are not anywhere near API-compatible, which means you can't just "drop in" libpam as a replacement for libsasl. Personally, I think SASL is a pain in the ass. But its problems are not performance-related. In fact, since saslauthd acts as a connection pool to your authentication datastore, you can probably authenticate more imapd sessions per second via saslauthd -a pam than you could if PAM were linked directly into imapd.
database types
Henrique, who maintains the Debian cyrus-imap packages (and does a very good job of it) just changed the MBOX and SEEN databases to use skiplist (from db3 and flat). I had never thought about this issue before. Can someone explain what advantages and disadvantages one has from the different database types? And what is a skiplist anyway? I'm familiar with flat files and the sleepycat databases, but I've never heard of a skiplist.
Resource temporarily unavailable
I am running cyrus-imapd-1.6.24 along with postfix under Red Hat Linux 7.0 on a li'l old i386. Most of the time it works flawlessly, but occasionally a delivery dies with a log entry like the following: Feb 15 15:03:46 heidegger deliver[8181]: checkdelivered: error opening delivered database: /var/imap/deliverdb/deliver-j.db: Resource temporarily unavailable This only occurs when a mail is being sent to multiple local users. The mail is actually successfully delivered. A web search revealed that several sites had experienced "Resource temporarily unavailable" errors associated with a failure to fork, and were able to fix them by increasing the allowed number of user processes. But my error says nothing about a failure to fork, and I have not set any limit on the number of user processes. Can someone suggest what might be going on and how to fix it?
