1

Topic: Random connection problems

==== Required information ====
- iRedMail version (check /etc/iredmail-release): 0.9.2 or earlier
- Linux/BSD distribution name and version: Debian 8
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): LDAP and MySQL
- Web server (Apache or Nginx): Apache
- Manage mail accounts with iRedAdmin-Pro? Yes
- Related log if you're reporting an issue: None
====
Hello, I have a strange problem.
My Iredmail installation manages >150 emails accounts and 5 domains.
The majority of my users don't have any problems to send/receive their mails.
But some users, sometimes (random), 3G or static ADSL connection, can't connect to the mail server using Thunderbird or the webmail or iPhone.
I don't see any logs in /var/log/mail.log and I don't even see them in my hardware firewall logs... No log too in /var/log/apache2/* if I tell them to try to connect to the webmail  Like no connection was established...?!
Worse : some users have 2 or 3 mails accounts on their iPhone. Only one account will not  work but others accounts will work perfectly.
When problem occurs, Thunderbird get a timeout error, IE or Firefox get a timeout error too. Clients resolves well the server IP address.

The only way to make it work is to reboot the server but the problem can happend 3mn or 3hours or 3days after the last reboot.

I checked and re-checked my hardware firewall, no explanation can explain this problem (and I repeat, majority of users aren't annoyed by this problem).
I opened a ticket to my ISP (pro support), nothing explain this problem.

I make a fresh install of iRedmail suite by thinking it was the problem (and to be honnest, I jump over 2 updates by lack of time) but always the same problem

Does anyone could help me ?

Thanks

Nicolas

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2

Re: Random connection problems

I have no idea yet.

Usually similar issue is caused by Fail2ban, if client had several password failures in a short period, Fail2ban will detect them and call iptables to block client ip address. But it doesn't make sense in your case, because other mail accounts configured on the same Phone/MUA successfully connect to the server. And if it was blocked by Fail2ban+iptables, you should be able to find related connection attempt in your network firewall.

The most important thing is we should be able to figure out which server the client tries to connect, then we check related access log on that server (of course it must be your server, otherwise it's a DNS issue).

3

Re: Random connection problems

Nicolas,

Allow me to share few tips with you just in case it helps. I'm sure others will have additional suggestions to help you address the problem.

First, if there is no connection at all to webmail, to me it sounds as if the server is either inaccessible at the time or the client IP has been banned. Getting an MTR, traceroute or similar could help at the time to determine what's going wrong.

If clients are not banned, they could be hitting a dovecot limitation 'mail_max_userip_connections = 10'... 10 being the default. That means that only 10 connections per user/per IP can be established at any given time. Users with multiple accounts and multiple devices sourcing from the same IP could be hitting the default limit. Obviously, dovecot should log this somewhere and you mention there is nothing in the logs. The other thing is that users with multiple accounts do not have the same username/password on each account, so I don't believe this could be affecting all users in that sense. Irrespective, it has been my experience that hitting the 10 connections per user/per IP is rather very common. A client with a Desktop application, a mobile device and a tablet, sitting at home and connecting to her/his own account can easily go over 10 connections in a heartbeat. 

Also, dovecot process_limit is 500 by default (the number of simultaneous IMAP connections)... If there are 150 users hitting your mailserver from different clients at the same time it doesn't look too far away to max the 500 process_limit. Assuming that a client can establish (unnecessarily in most cases) up to 5 connections per requests (150 x 5 = 750 connections). That's way over the process_limit = 500 by default.

What I've done myself to mitigate a similar experience (making sure it is not network or service attack related) was to increase these defaults to a more tolerant number (depending on the service load):

Here is what has worked for me so far (although you may have to adjust these to your own environment):

# /etc/dovecot/dovecot.conf

For your protocols, set a higher number of connections per user/per IP:

...
protocol imap {
...
 mail_max_userip_connections = 20
...
}
...
...
protocol pop3 {
...
 mail_max_userip_connections = 20
...
}
...

Then, I have adjusted the login processes. (Refer to Dovecot wiki for more details: http://wiki2.dovecot.org/LoginProcess)

...
service imap-login {
    service_count = 1

    # To avoid startup latency for new client connections, set process_min_avail
    # to higher than zero. That many idling processes are always kept around
    # waiting for new connections.
    process_min_avail = 16

    # number of simultaneous IMAP connections
    #process_limit = $default_process_limit
    process_limit = 800
...

Finally, the more users connected to your service, the higher the load. Hence I have proxied roundcube webmail (imapproxy) to alleviate the load in the IMAP server. Run a test and you will find 10-15 IMAP connections per webmail user at any given time for every click/interaction in webmail; it is indeed stressful for any IMAP server. Using imapproxy in your box will keep those 15-20 simultaneous connections down to a single open connection between webmail and the backend IMAP server. It also helps to speed up folder listing, etc.

Hope this help if it isn't indeed a network issue. Logs are your friend and something must have been logged somewhere. Good luck.

4

Re: Random connection problems

ZhangHuangbin wrote:

I have no idea yet.
...
The most important thing is we should be able to figure out which server the client tries to connect, then we check related access log on that server (of course it must be your server, otherwise it's a DNS issue).

It's not a DNS issue. NSLOOKUP on the client resolves the good address. After a server reboot, the connection on the defective client comes up magically on Thunderbird or on Roundcube without client reboot or client IPs re-configuration.
I own the mail server and no log is coming during the client connection even in system logs.

myroundcube wrote:

...

I already increase limitations on Dovecot(didn't mentionned it, sorry).
I'm agree with you, if a connection is established, something must be logged somewhere. If it's a ISP trouble, they must have a log... I'll "log" several fails and call them to ask them what happened with the client IP and date/time.

The worst thing is : everything working well after a server reboot and if I tell this to my ISP support, they'll drop the problem to the iRedMail installation, obviously.

Thanks

Nicolas

5

Re: Random connection problems

Is the IP address blocked in iptables when this issue happens?

The big difference after server reboot is iptables rules will be emptied.

6

Re: Random connection problems

ZhangHuangbin wrote:

Is the IP address blocked in iptables when this issue happens?

The big difference after server reboot is iptables rules will be emptied.

I don't think so... Where iptables logs are supposed to be ?

Thanks

Nicolas

7

Re: Random connection problems

nicolasfo wrote:

I don't think so... Where iptables logs are supposed to be ?

It drops connection directly, and client will time out.

Maybe you can add some additional rules in iptables to log dropped connection/packet for debugging purpose.
References:

- http://www.cyberciti.biz/tips/force-ipt … -file.html
- http://www.thegeekstuff.com/2012/08/ipt … g-packets/

8

Re: Random connection problems

Doesn't fail2ban logs to /var/log/fail2ban.log? There is gotta be traces there I guess... also, iptables -L  should list something in the Chain when IPs are blocked.