On Wed, 26 Dec 2007, Derek Xu wrote:
I tried both "pam" and "pmb". Same problem. It appears I can get LDAP
authentication even if I set PASSWDTYPE to pam.
OK, then SUN may have fixed this bug.
As for your logs:
Dec 26 14:12:21 testmachine imapd[1892]: [ID 960700 mail.info] Killed (lost
mailbox lock) user=tester host=testmachine [192.168.1.23]
Dec 26 14:12:22 testmachine imapd[1893]: [ID 960700 mail.info] Unexpected
client disconnect, while reading line user=tester host=testmachine
[192.168.1.23]
These are the two smoking guns. We'll deal with each individually.
(1) Dec 26 14:12:21 testmachine imapd[1892]: [ID 960700 mail.info] Killed (lost
mailbox lock) user=tester host=testmachine [192.168.1.23]
This message tells me that your server uses the traditional UNIX mailbox
format (also called "mbox format"), and that your IMAP client tried to
have two sessions open to the same mailbox at the same time.
In looking at the other messages, process 1892 and 1893 were both created
at 14:12:21. Within the same second, process 1892 opened the mailbox
first, then process 1893 opened the same mailbox.
You can not have more than one IMAP session open on a traditional UNIX
format mailbox at a time. When this happens, the assumption is that the
current session was abandoned for some reason (perhaps you left your mail
program open at the office, and are now trying to access mail from home)
and the new session kills the current session.
There is no need for a client to have more than one session to the same
mailbox. IMAP operations, even searches, sorts, and threads, are fast
enough that there is no real benefit. What little benefit there may be is
dramatically outweighed by the cost to the server since IMAP is a highly
stateful protocol.
(2) Dec 26 14:12:22 testmachine imapd[1893]: [ID 960700 mail.info] Unexpected
client disconnect, while reading line user=tester host=testmachine
[192.168.1.23]
This message tells me that your IMAP client dropped the TCP connection
in the next without issuing a proper LOGOUT command first.
As an educated guess, the client probably thinks that there is a problem
at the server, so it gave up and "for efficiency" just dropped the
connection instead of issuing a LOGOUT.
The problem is client-based. Many clients are written by individuals who
only have training in stateless protocols such as HTTP ("make a
connection; if you don't get what you want right away, make another one;
if you want to do things faster make multiple ones") and not stateful
protocols such as IMAP. [I'm trying to be charitable; you don't want to
hear what I really think...]
Sadly, it is generally far easier to work around such issues in the server
than it is to get these clients fixed to work properly. My fantasy that
the market would exterminate poorly-written implementations was dashed
years ago; if anything, the bad software has crowded out the good.
So...
Your best bet is to consider an alternative mailbox format. Start by
reading the following FAQ:
http://www.washington.edu/imap/IMAP-FAQs/index.html#4.5
However, instead of mbx format, I recommend that you consider the new mix
format. The documentation in the FAQ applies to mix as well as mbx; just
substitute "mix" wherever you read mbx.
You can read more about mix format in the file imap-2007/docs/mixfmt.txt
in your copy of the imap-2007 distribution. Briefly, here are some of the
benefits of using mix format:
. Unlike traditional UNIX format and mbx format, mix format is a directory
instead of a file and offers the IMAP-optional "dual-use" semantics.
This helps with poorly-written clients that assume that "dual-use" is
mandatory on serers.
. Unlike traditional UNIX format, mbx and mix formats allow multiple
sessions to be open to the same mailbox at the same time. This helps with
poorly-written clients that falsely believe that it is "more efficient" to
do things this way.
. Unlike traditional UNIX format and mbx format, mix is indexed.
Mailboxes open much faster in mix format than in mbx format and
(especially!) traditional UNIX format. This also helps with
poorly-written clients that open multiple sessions to the same mailbox.
. Unlike traditional UNIX format, mbx and mix formats do not defer
updates. This helps with poorly-written clients that drop TCP connections
in the false belief that it is "more efficient" to do things this way.
The problem is that in certain circumstances, the deferred updates in
traditional UNIX mailbox format get lost when this happens.
Note that most other IMAP server implementations will also steer you
towards a different mailbox format than traditional UNIX format. For
example: Cyrus has its own indexed format; Dovecot supports traditional
UNIX but strongly encourages an extended form of maildir; Courier
(shudder!) has its own extended form of maildir.
No matter which IMAP software you choose, the key to a happy IMAP server
is to use some format other than traditional UNIX format. Although
traditional UNIX format is UW imapd's default, that is only for ease of
installation and compatibility. It has never been MY format of choice
(and I wrote UW imapd!). UW tried to use traditional UNIX format (with
NFS, no less) on its main servers and gave up on that nearly 15 years ago.
Changing the mailbox format on the server is a good thing to do for a
well-written IMAP client too. Poorly-written IMAP clients will work
instead of not working at all, and well-written IMAP clients (such as Pine
and Alpine) will work very well.
Good luck! I'm sure that you'll have more questions as you move forward
with alternative formats, so please don't hesitate to ask if you have any
questions.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
