Index: [Article Count Order] [Thread]

Date:  Fri, 27 Jul 2007 16:26:42 -0600
From:  "Rodrigo Ordonez Licona" <rodrigo (at mark) xnet.com.mx>
Subject:  [coba-e:10473] Re: POP3 Server Freezing
To:  <coba-e (at mark) bluequartz.org>
Message-Id:  <200707272224.l6RMOpgI025459 (at mark) admin.xnet.com.mx>
In-Reply-To:  <7853B509BA765D40B8DACAEA2F64B2A401294012 (at mark) es005.gramtel.office>
X-Mail-Count: 10473

We applied all the updates and had a POP problem today

Had to run dbrecover a few times- 

Ended up disabling dovecot for an hour. I think its pam related and stress
related

I think solarspeed new security package myght prevent pop3 flooding

-----Original Message-----
From: Rusty Waybrant [mailto:RWaybrant (at mark) gramtel.net] 
Sent: Viernes, 27 de Julio de 2007 10:29 a.m.
To: coba-e (at mark) bluequartz.org
Subject: [coba-e:10466] Re: POP3 Server Freezing

>Has anyone else experienced similar problems with the POP3 server?
>Any ideas to fix it?

You may be seeing a similar issue as a long ongoing... What do you see as
'freezing up'? Do you see hung dovecot-auth processes (ps)? Are other
services, like FTP, experiencing similar issues for the same users during
this time? Do you notice anything unusual in your logs during this time
(lots of failed login attempts)?

I think the base issue is related to pwdb, and when you reboot your server,
it is actually running 'dbrecover' that is actually fixing the issue. When
this issue occurs, anything relying on pwdb also has a similar issue. Like
FTP for the same users would also be "frozen". 

There are several scripts/procedures posted on this list that fixes the
issue; it stops services related to pwdb, kills any hung processes, runs
dbrecover, and then restart services. At least you wouldn't have to reboot. 

Brian  (at mark)  Nuonce suggested some tweaks for dovecot.conf to enable auth_cache.
This was very successful on my BlueQuartz servers, and I don't remember the
last time I had an issue with POP3... Well, no issues since April when it
was posted... I did not do the PAM change, just the dovecot.conf change (but
I can't remember if this was changed upstream in BlueQuartz, so should have
come down in 'yum update'?)...
http://www.bluequartz.us/phpBB2/viewtopic.php?t=21308&sid=117d18a3c89e92
fff5e8ffd8f0940833

	In your /etc/dovecot.conf

		Search for:
		Code:
		#auth_cache_size = 0
		Change to:
		auth_cache_size = 1024

		Search for:
		passdb pam {

		Then look below for:
		#args =
		Change to:
		args = session=yes cache_key=%u%s dovecot

	It is right before the '}', so make sure you get the correct one.

	Save the file and restart Dovecot. 

Brian also recently posted a good procedure to switch from pwdb to
passwd/shadow... http://www.nuonce.net/bq-howto.php?action=view&id=23
... But, it was asked what happens when there is an BlueQuartz update, would
this procedure have to be done again? I didn't catch the answer.
So, just watch the 'yum update's if you go this direction...

You should look at your logs and try to figure out what is causing this... I
think most of this happens for two reasons, either because of a
dictionary-attack, or because you just have a high-volume POP3 service
(well, these two reasons are basically the same, high-volume, either
real-users or a 'bot' with login failures). I think someone was offering a
reasonable priced firewall add-on that would prevent dictionary-attacks
against POP3/FTP? So, this might be another option to consider.



Rusty