Specifically, how to have qpopper in server mode coexist with the UW imapd. Since these are two of the most popular open source implementations of the two most popular mail retrieval protocols, it seems like a good thing to fix.
This seems to come up at least every few months on the list, and up to now, as far as I know nobody has had a good solution. Right now, it's a little more urgent for me than "good thing to fix". We are committed to getting a customer-accessible webmail project into beta (at least) by the end of the year - meaning next month - and rolling it out soon after. Based on our past testing, and knowing that some customers leave multiple machines checking POP every few minutes, we're fairly sure that if somebody starts a webmail (or any other) IMAP session on one of those accounts, with qpopper running in server mode, their mailspool will be corrupted in minutes. We are also fairly sure, based on what the load was like before we implemented qpopper 4.0.3 and server mode, that if we turn server mode back off, our main mail server will fall over and die; that's not even an option for us. So some of our admins here brainstormed and came up with a possible alternative answer. What I'm proposing is to implement an optional patch which would make qpopper aware in "read only mode" of when uw-imapd is running on a particular user's mailbox, so that qpopper would refuse to start a POP session in that case (just as if you tried to do multiple concurrent POP sessions on the same mailbox.) Conversely, we'll need to patch UW imapd the same way, so it's aware of qpopper's mutual exclusion lock, and will check (again "read only") for a qpopper lock before it proceeds into an IMAP session, just as it might check for a lock by another IMAP session. This solution seems to me like it would do the trick of making sure that you can never have a concurrent qpopper and imapd session, provided the locks are checked in the right order (i.e. get ones own lock first, then check for the other party's lock.) It also seems like we would need to add relatively few lines of code to each daemon, though it will be critical that they are in exactly the right place(s). Of course it will be up to the maintainers if we can get these patches into either package, but it seems worth a shot. Any comments on this idea? If it seems like it would work out, we're shooting to start coding it by Dec 15 or thereabouts. -- Clifton -- Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED] WWJD? "JWRTFM!" - Scott Dorsey (kludge) "JWG" - Eddie Aikau
