• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Unreal POP3 Stats

StvnT

New Pleskian
[Solved] Unreal POP3 Stats

A domain has recently started reporting extremely high POP3 Out statistics. Plesk is reporting between 8 and 10 gigabytes of data for our POP3 Out per night! I don't really know how to read the logs but I believe the inflated reporting is caused by a single account on the affected domain. The suspect account - from the logs:

May 11 11:21:18 web1 pop3d: IMAP connect from @ [xxx.xxx.xxx.xxx]INFO: LOGIN, [email protected], ip=[xxx.xxx.xxx.xxx]
May 11 11:21:52 web1 pop3d: 1336753312.107644 DISCONNECTED, [email protected], ip=[xxx.xxx.xxx.xxx], top=0, retr=22795503, time=34, rcvd=50, sent=23092177, maildir=/var/qmail/mailnames/domain.com/user1/Maildir

For comparison, this is another user on the domain:

May 11 11:30:34 web1 pop3d: IMAP connect from @ [xxx.xxx.xxx.xxx]INFO: LOGIN, [email protected], ip=[xxx.xxx.xxx.xxx]
May 11 11:30:34 web1 pop3d: 1336753834.615746 LOGOUT, [email protected], ip=[xxx.xxx.xxx.xxx], top=0, retr=0, time=0, rcvd=12, sent=39, maildir=/var/qmail/mailnames/domain.com/user2/Maildir

If I understand correctly, the user1 account performs a login, transfers 23MB of data and is disconnected after 30 seconds. Whereas the user2 account performs a login, sees no new mail and logs out.

What could be the problem? Could it be compromised? Could the client have changed settings and we're seeing IMAP traffic instead of POP3 (sorry, I'm not real familiar with these logs)?
 
Last edited:
Hi,

We have seen something similar to this twice, and in both times (one is still ongoing) its been caused by Kayako.

Kayako gets itself all in a tizz with emails larger than its limits, I think it downloads the email, realises its bigger than its allowed then gives up. Then on the next cycle it downloads the email, realises its bigger than its allowed then gives up (etc etc etc).

Not saying its the case you have here, but it could be something else with equally poor logic (or just a truly massive email thats somehow ended up in the inbox and times out on download every time),

Paul
 
Thanks for the help Igor and Paulie!

This only affected the one account so I was thinking either it was something on the clients end (Outlook error/bug/misconfiguration), email backscatter or a compromised account. We've had some problems with large emails before but nothing quite like this.

I wasn't able to figure out exactly what the problem was but we were able to get it fixed by resetting the password in Plesk and by having the client delete their account in Outlook. Not insightful into the cause of the problem but it worked for us.
 
Back
Top