Thanks, Mark. The copy of the imapd being used was directly downloaded from UW and thus should be unmodified.
I compared two cases -- one is using the "spam" button and the other is the client's normal forward function, and found the following difference in the termination message(var/log/syslog): Case1: Using "Spam" button -- connection drop error message returned Dec 26 10:10:14 poisson imapd[28495]: [ID 323218 mail.debug] tid= 1: unlocking sessionLock In contrast, in the case 2 that is using forward function ( the operation successed without connection drop error message), a lot more mail info has been logged: Dec 26 10:13:20 testmachine imapd[28515]: [ID 323218 mail.debug] tid= 1: unlocking s essionLock Dec 26 10:13:20 testmachine imapd[28515]: [ID 453631 mail.debug] tid= 1: Adding conn ection (serverAddr=192.168.1.50) Dec 26 10:13:20 testmachine imapd[28515]: [ID 816976 mail.debug] tid= 1: Connection added [1] Dec 26 10:13:20 testmachine imapd[28515]: [ID 467101 mail.debug] tid= 1: connectionI D=1025 Dec 26 10:13:20 testmachine imapd[28515]: [ID 805042 mail.debug] tid= 1: shared=1 Dec 26 10:13:20 testmachine imapd[28515]: [ID 982078 mail.debug] tid= 1: usedBit=0 Dec 26 10:13:20 testmachine imapd[28515]: [ID 727660 mail.debug] tid= 1: threadID=1 Dec 26 10:13:20 testmachine imapd[28515]: [ID 577507 mail.debug] tid= 1: serverAddr= 192.168.1.50 Dec 26 10:13:20 testmachine imapd[28515]: [ID 939703 mail.debug] tid= 1: AuthType=1 Dec 26 10:13:20 testmachine imapd[28515]: [ID 142272 mail.debug] tid= 1: TlsType=0 Dec 26 10:13:20 testmachine imapd[28515]: [ID 537450 mail.debug] tid= 1: SaslMech=0 Dec 26 10:13:20 testmachine imapd[28515]: [ID 625532 mail.debug] tid= 1: SaslOpt=0 Dec 26 10:13:20 testmachine imapd[28515]: [ID 339871 mail.debug] tid= 1: hostCertPat h=/var/ldap Dec 26 10:13:20 testmachine imapd[28515]: [ID 639905 mail.debug] tid= 1: userID=uid= tester,ou=People,dc=testdomain,dc=com Dec 26 10:13:21 testmachine imapd[28515]: [ID 453631 mail.debug] tid= 1: Adding conn ection (serverAddr=192.168.1.50) Dec 26 10:13:21 testmachine imapd[28515]: [ID 816976 mail.debug] tid= 1: Connection added [2] Dec 26 10:13:21 testmachine imapd[28515]: [ID 467101 mail.debug] tid= 1: connectionI D=1026 Dec 26 10:13:21 testmachine imapd[28515]: [ID 805042 mail.debug] tid= 1: shared=1 Dec 26 10:13:21 testmachine imapd[28515]: [ID 982078 mail.debug] tid= 1: usedBit=0 Dec 26 10:13:21 testmachine imapd[28515]: [ID 727660 mail.debug] tid= 1: threadID=1 Dec 26 10:13:21 testmachine imapd[28515]: [ID 577507 mail.debug] tid= 1: serverAddr= 192.168.1.50 Dec 26 10:13:21 testmachine imapd[28515]: [ID 939703 mail.debug] tid= 1: AuthType=1 Dec 26 10:13:21 testmachine imapd[28515]: [ID 142272 mail.debug] tid= 1: TlsType=0 Dec 26 10:13:21 testmachine imapd[28515]: [ID 537450 mail.debug] tid= 1: SaslMech=0 Dec 26 10:13:21 testmachine imapd[28515]: [ID 625532 mail.debug] tid= 1: SaslOpt=0 Dec 26 10:13:21 testmachine imapd[28515]: [ID 339871 mail.debug] tid= 1: hostCertPat h=/var/ldap Dec 26 10:13:21 testmachine imapd[28515]: [ID 639905 mail.debug] tid= 1: userID=uid= tester,ou=People,dc=testdomain,dc=com Dec 26 10:13:21 testmachine imapd[28515]: [ID 234311 mail.info] Login user=tester hos t=testmachine [192.168.1.23] Dec 26 10:13:21 testmachine imapd[28515]: [ID 960700 mail.info] Logout user=tester ho st=testmachine [192.168.1.23] I am not sure what we can conclude from the above differences. Derek On Dec 25, 2007 7:35 PM, Mark Crispin <[EMAIL PROTECTED]> wrote: > Unless you have memory limits set ridiculously low (as in suitable for the > early 1980s), it is quite unlikely that imapd would fail due to lack of > memory. If it did, there would be an entry in the mail syslog reading > "IMAP toolkit crash: Out of memory". > > Nor is the IMAP command "FETCH 106 BODY[HEADER]" a particularly difficult, > unexpected, or risky operation for an IMAP server to undertake. > > Rather than guess at the problem, and trying all sorts of things at random > until you find the measure that fixes it, I suggest that you try a little > bit more investigation first. > > As noted above, UW imapd leaves its log messages in the mail syslog. [At > least it does in unmodified UW imapd. If you have a copy of UW imapd that > was modified by a third party, the first thing to do is see if unmodified > UW imapd directly from UW works any better.] So, take a look in the mail > syslog and see if there are any interesting log messages corresponding > with the incident. > > UW imapd normally logs its startup, authentication, and termination. The > last is probably the most interesting. Is there a termination message, or > did that imapd vanish without a trace? If there is a termination message, > what did the message say? That will point you towards the next step in > your debugging. > > > On Tue, 25 Dec 2007, Derek Xu wrote: > > Hello -- > > > > I am running UW IMAP 2007. The mail client is squirrel webmail 1.4.13 > > with spam_buttons plugin. When I click on the "spam" button, it always > > generates the following error message: > > > > ERROR: Connection dropped by IMAP server. > > Query: FETCH 106 BODY[HEADER] > > > > I queried the squirrel webmail mailing list, they suspected it is an > > IMAP-related issue. However, the mail log doesn't provide any useful > > information. I just came across an article talking about bincimap and > > squeirrelMail. There was a similar problem and the suggested solution > > is use /usr/local/bin/softlimit to set memory resource,such as stack > > segment per process, physical pages per process and data segment per > > process, for bincimap to much higher values. > > > > http://osdir.com/ml/mail.imap.binc.general/2003-10/msg00089.html > > > > I wonder if there is any similar way to change the memory resource > > for UW imapd. What normally cause imapd drop connections with clients? > > > > Thanks, > > > > Derek > > _______________________________________________ > > Imap-uw mailing list > > [email protected] > > https://mailman1.u.washington.edu/mailman/listinfo/imap-uw > > > > -- 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
