7 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Flaky behavior
FromSent OnAttachments
Steve JacobsonJan 30, 2006 11:38 am 
Jay LeeJan 30, 2006 12:00 pm 
Steve JacobsonJan 30, 2006 12:10 pm 
Bowie BaileyJan 30, 2006 12:26 pm 
Steve JacobsonJan 30, 2006 12:42 pm 
Bowie BaileyJan 30, 2006 12:50 pm 
Gordon MessmerJan 30, 2006 11:11 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [courier-users] Flaky behaviorActions...
From:Jay Lee (jl@pbu.edu)
Date:Jan 30, 2006 12:00:41 pm
List:net.sourceforge.lists.courier-users

On Mon, January 30, 2006 2:37 pm, Steve Jacobson wrote:

We're running Courier 0.57 authlib, mta, imap, etc... on RHEL4 on a dual proc Xeon server. We're also running ClamAV through ClamCour, and hitting SpamAssassing through a maildrop xfilter. On average, the load on the system is very, very low - < 0.05

OK, similar to my config although I'm using a LDAP backend and most of my users are in Squirrelmail webmail although a few of us run Thunderbird.

Lately, we've started to see a bunch of flaky behaviours, where users would be prompted for their passwords on send (we're using authenticated, and SSL smtp) randomly.

I'm assuming TB already has the password saved and the saved password is failing since prompting for a password for an authenticated connection seems like a normal behavior... TB seems to do this when the server indicates a authentication failure. What backend are you using? Have you tried turning on debugging in courier-authlib?

We've also had situations where messages show up in the users sent folder, but are never delivered.

Again, your not being very clear here. Are you talking about sending via IMAP or are you saying that TB successfully saves the message to the IMAP folder but the SMTP connection fails?

In addition, we've seen situations where saving to the sent folder has failed. This one we've mostly cleared up by allowing more connections per IP, as we all appear to be coming from the same IP to the server, since it's outside our corporate firewall.

You need to figure out why connections are failing. Courier cannot log every client error, otherwise it's logs would be far beyond huge. For example, if Courier wrote a log entry every time a client tried to save to a non-valid IMAP folder, you'd be filling up your /var partition in no time... Use a packet tracer or the IMAPDEBUGFILE to find out what command is failing.

I'm getting a lot of pressure to dump courier at this point, and I'm starting to think that might be the right way to go. There's nothing useful in the logs - apparently only things that work get logged ;) None of the failures have corresponding messages.

Rip and replace is rarely the right way to go and it rarely solves your problems. You'll simply be replacing your Courier issues with issues from a new server. Besides, how do you know the problem is with Courier and not Thunderbird or your firewall? It would really suck to rip Courier out, replace it only to find the new server has the same issues and the problem is elsewhere...

Our clients are all running Thunderbird on Windows, OSX and Linux.

According to the message you posted to the list your using Thunderbird 1.0 which is rather old. Have you considered updating to at least 1.0.7 if not 1.5? It may produce better results or at the least, better error messages.

Jay