Issue Abnormal traffic usage caused by POP3/IMAP

[stevepa]

Server operating system version

Ubuntu 20.04.6 LTS

Plesk version and microupdate number

18.0.63 Update #4

Dear all,

I've got asubscription for a customer in my plesk environment with "normal" usage of 2 GB.
Traffic was constantly 2-5GB a month, but a few months ago monthly traffic was suddenly 300, 400, 500 GB a month, up to 3 TB.

Nothing changed, costumer is still using his email as before.
All traffic is caused by POP3/IMAP. Outgoing Mail Control is enabled (max. 30 mails an hour).

There are no anomalies in /var/log/maillog and maillog.processed - this is all minimal.

Any ideas?

Thanks a lot.

 

[Sebahat.hadzhi]

Since mail accounts authentication is performed via POP3/IMAP, this may be the cause of high traffic statistics. However, you would have probably noticed lots of entries in the maillog. Could you please try one of the following scripts and let us know what's the result you see?

 

[ChristophRo]

maybe a stuck email in the inbox, that the client tries to download over and over again? (I've only seen such things in the past, when using POP3)

 

[stevepa]

maybe a stuck email in the inbox, that the client tries to download over and over again? (I've only seen such things in the past, when using POP3)

yes it seems so, but how to find out which client is causing this issue? any ideas?

 

[stevepa]

Since mail accounts authentication is performed via POP3/IMAP, this may be the cause of high traffic statistics. However, you would have probably noticed lots of entries in the maillog. Could you please try one of the following scripts and let us know what's the result you see?

POP3/IMAP stats for info@********.net

Bytes:
SENT=340539725191
RCVD=8086097

KiloBytes:
SENT=332558325.38
RCVD=7896.58

MegaBytes:
SENT=324763.99
RCVD=7.71

GigaBytes:
SENT=317.15
RCVD=.01

 

[mcac]

Hi, I have also a customer with only one mailbox. He sent no big mails, only mails with some KB in attachement. The above script returns:
Bytes:
SENT=253712977235
RCVD=84056767

KiloBytes:
SENT=247766579.33
RCVD=82086.69

MegaBytes:
SENT=241959.55
RCVD=80.16

GigaBytes:
SENT=236.29
RCVD=.08

There is no alert for to much mails sending from outgoing mail control. In mail statistic on sent mails the most days are 0 (zero) mails. That is also very suspicious. Today the customer has only 6 mails sent (1 in one hour). Yesterday and day before zero mails. And day before 2 mails. But day before there are 0 mail sent in statistic.

Is there a problem with server? There are many mailboxes on the server. Only one mailbox generate this big traffic in statistic.
What can I do to check?

 

[stevepa]

In my case there was problem with a Apple Device. Apparently a service has hung up and has repeatedly retrieved or sent data.
Deleting the Mailaccount from the affected device was the solution,

 

[mcac]

Thanks for this feedback. The customer use only 2 Windows PCs with Outlook....

 

[stevepa]

try to disable both in different time slots an check usage.

 

[Raul A.]

I had to debug such a case recently. The log doesn't show any additional details on why the email client downloaded so much data.

You can debug this issue further by enabling mail_debug in Dovecot.

Check the value:

doveconf | grep mail_debug

Edit /etc/dovecot/dovecot.conf removing the # from before mail_debug, afterwards restart dovecot:

grep mail_debug /etc/dovecot/dovecot.conf  -n
122:#mail_debug = yes

Check new sessions to see which one had a lot of data transferred and see what happened before the session terminated:

grep -E "service=imap|service=pop3" /var/log/maillog | grep Disconnected | awk '{print $1" "$2" "$3" "$7" "$NF}' | awk -F"=" '{print $1" "$2" "$NF/1024" MB"}'
Apr 2 15:36:06 user [email protected], sent 21.5195 MB
Apr 2 15:52:23 user [email protected], sent 125.363 MB
Apr 4 12:06:23 user [email protected], sent 0.849609 MB
Apr 4 22:02:17 user [email protected], sent 169.811 MB
Apr 4 22:02:17 user [email protected], sent 85.2939 MB
Apr 7 22:10:28 user [email protected], sent 63.7705 MB
Apr 7 22:30:12 user [email protected], sent 684.421 MB