dovecot - Jun 2009 - Lots of pop3-logins

Hello,

Doing a "ps aux" on my Slackware box, I have approx 100  PID's of
"pop3-login's going on.  This is a production mail server, but it is
getting VERY low traffic.  In fact, only 3 people can "pop3" into it. 
I've check their e-mail clients, and they are not checking mail any more
often than every 5 minutes.

This is a new installation and I've had the server up and running since
Sunday.  If it matters, I'm using Postfix for the MTA and using the Dovecot
SASL library to AUTH SMTP.

Is this a cause for concern?  Why does Dovecot need this many processes?

Thanks!

Rodman

On Qui, 2009-06-25 at 09:07 -0500, Rodman Frowert wrote:
> Hello,
> 
> Doing a "ps aux" on my Slackware box, I have approx 100 
PID's of "pop3-login's going on.  This is a production mail server,
but it is getting VERY low traffic.  In fact, only 3 people can "pop3"
into it.  I've check their e-mail clients, and they are not checking mail
any more often than every 5 minutes.
> 
> This is a new installation and I've had the server up and running since
Sunday.  If it matters, I'm using Postfix for the MTA and using the Dovecot
SASL library to AUTH SMTP.
> 
> Is this a cause for concern?  Why does Dovecot need this many processes?
> 
Because dovecot preforks the *-login processes to speed-up the login.

No need to worry.


-- Jose Celestino SAPO.pt::Systems http://www.sapo.pt
--------------------------------------------------------------------- *
Progress (n.): The process through which Usenet has evolved from smart
people in front of dumb terminals to dumb people in front of smart
terminals.

On Jun 25, 2009, at 10:07 AM, Rodman Frowert wrote:
> Doing a "ps aux" on my Slackware box, I have approx 100 
PID's of
> "pop3-login's going on.  This is a production mail server, but it
> is getting VERY low traffic.  In fact, only 3 people can "pop3"  
> into it.  I've check their e-mail clients, and they are not  
> checking mail any more often than every 5 minutes.
>
> This is a new installation and I've had the server up and running  
> since Sunday.  If it matters, I'm using Postfix for the MTA and  
> using the Dovecot SASL library to AUTH SMTP.
>
> Is this a cause for concern?  Why does Dovecot need this many  
> processes?
   Take a look at your log file.  Is there a dictionary attack taking  
place?  I get this all the time.  I want to find these little cracker  
kiddies and break their fingers.

             -Dave

-- 
Dave McGuire
Port Charlotte, FL

> Hello,
> 
> Doing a "ps aux" on my Slackware box, I have approx 100 
PID's of "pop3-login's going on.  This is a production mail server,
but it is getting VERY low traffic.  In fact, only 3 people can "pop3"
into it.  I've check their e-mail clients, and they are not checking mail
any more often than every 5 minutes.
> 
> This is a new installation and I've had the server up and running since
Sunday.  If it matters, I'm using Postfix for the MTA and using the Dovecot
SASL library to AUTH SMTP.
> 
> Is this a cause for concern?  Why does Dovecot need this many processes?
> 
>> Because dovecot preforks the *-login processes to speed-up the login.
>> No need to worry.
100 login sessions for just 3 connections? That is not right, no matter what.
There is definitely some issue. Once the load increases the system will start
timing out on POP3 connections or other network connections, such as IMAP, SSH
etc. Better check out the system logs, utilization etc. for any abnormal values.

Regards
Rao

> > Doing a "ps aux" on my Slackware box, I have approx 100 
PID's of "pop3-login's going on.  This is a production mail server,
but it is getting VERY low traffic.  In fact, only 3 people can "pop3"
into it.  I've check their e-mail clients, and they are not checking mail
any more often than every 5 minutes.
> > 
> > This is a new installation and I've had the server up and running
since Sunday.  If it matters, I'm using Postfix for the MTA and using the
Dovecot SASL library to AUTH SMTP.
> > 
> > Is this a cause for concern?  Why does Dovecot need this many
processes?
> > 
> 
> >> Because dovecot preforks the *-login processes to speed-up the
login.
> 
> >> No need to worry.
> 
> 100 login sessions for just 3 connections? That is not right, no matter
what.
>> No, login_processes_count matters.
How? If my understanding is correct, you have extra 3 login processes created to
cater to new connections. So with only 3 POP3 users, why should so many login
processes be spawned? I can understand 10-15. But 100 definitely indicates
either the processes are not dying or something else happening on the system
which is causing such high number of login processes. The system definitely
needs to be checked for some kind of attack, a rogue process running on the
system or something else.

Regards
--Rao

> > > Doing a "ps aux" on my Slackware box, I have approx 100
PID's of "pop3-login's going on.  This is a production mail server,
but it is getting VERY low traffic.  In fact, only 3 people can "pop3"
into it.  I've check their e-mail clients, and they are not checking mail
any more often than every 5 minutes.
> > > 
> > > This is a new installation and I've had the server up and
running since Sunday.  If it matters, I'm using Postfix for the MTA and
using the Dovecot SASL library to AUTH SMTP.
> > > 
> > > Is this a cause for concern?  Why does Dovecot need this many
processes?
> > > 
> > 
> > >> Because dovecot preforks the *-login processes to speed-up
the login.
> > 
> > >> No need to worry.
> > 
> > 100 login sessions for just 3 connections? That is not right, no
matter what.
> 
> >> No, login_processes_count matters.
> 
> How? If my understanding is correct, you have extra 3 login processes
created to cater to new connections. So with only 3 POP3 users, why should so
many login processes be spawned? I can understand 10-15. But 100 definitely
indicates either the processes are not dying or something else happening on the
system which is causing such high number of login processes. The system
definitely needs to be checked for some kind of attack, a rogue process running
on the system or something else.
> 
>> My idle box has 64 imap-login processes and no, I'm not under a
>> dictionary attack :)
I am not sure what your load is (user base, system config etc), but I will give
you my typical load here. I run mail server for about 6000 users with a mix of
70% POP3 and 30% IMAP (thro webmail). And here are the typical stats (I run a
script in the background collecting this data every 5 secs):

pop3-logins:12
pop3-connections:8
IMAP-logins:7
IMAP-connections:11

I have read other opinions in this thread by Timo & others. And I am
interested in a few things. So if you will indulge me, maybe it will be useful
for others who face these kind of issues

Timo Wrote: You can also just decrease login_process_max_count

Wouldn't decreasing the login_process_max_count simply create more problems.
Now users will start experiencing timeouts sooner than before, because whatever
is causing the login processes to increase (attack, rogue process or whatever)
will *always* be trying to login and genuine users will be denied login. So
without knowing the root cause of the issue simply decreasing or increasing the
login_process_max_count will lead to other problems. Correct me if I am wrong.

Rodman Wrote: I'll go ahead and lower that limit to something that fits my
usage better.

No, I think leave that value to default and try and identify the root cause and
prevent it.

Noel Wrote: What would be nice is, an anti brute force option

Yes, that would be nice. But consider a situation where the system is not under
brute force attack, but for some reason the number of login processes keep on
increasing by the hour. This would ultimately lead the system to deny
connections to the users. Is there a way to track what is happening? strace
would be too complicated for us field guys to work with. Any suggestions?

Regards
--Rao