Duplicate Emails - 15 copies of same email message

One of the email accounts on my ISPConfig server is getting 15 copies of same email message. I can easily remove duplicates with following command:

doveadm deduplicate -u [email protected] -m ALL

Anyone knows how / why this is happening?

 

Anyone knows or have an idea how to troubleshoot this issue?

 

Thanks @till

I just sent test from GMAIL account to the email account that receives duplicate email messages on my ISPConfig, account received multiple messages on Jan 18 2026 @ 13:55, below is what's in mail log. I'm not sure what to look for, please advise?

grep "[email protected]" /var/log/mail.log

Jan 18 13:55:01 lara dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=XXX.XX.38.252, lip=XXX.XX.38.252, mpid=3556071, secured, session=<icQr865IDIuYLCb8>
Jan 18 13:55:01 lara dovecot: imap([email protected])<3556071><icQr865IDIuYLCb8>: Logged out in=102 out=147890 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0
Jan 18 13:55:36 lara dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=::1, lip=::1, mpid=3557114, secured, session=<CepH9a5IHroAAAAAAAAAAAAAAAAAAAAB>
Jan 18 13:55:36 lara dovecot: imap([email protected])<3557114><CepH9a5IHroAAAAAAAAAAAAAAAAAAAAB>: Logged out in=70 out=770 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0
Jan 18 13:55:37 lara dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=::1, lip=::1, mpid=3557117, secured, session=<MOlK9a5IKLoAAAAAAAAAAAAAAAAAAAAB>
Jan 18 13:55:37 lara dovecot: imap([email protected])<3557117><MOlK9a5IKLoAAAAAAAAAAAAAAAAAAAAB>: Logged out in=120 out=909 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0
Jan 18 13:55:37 lara dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=::1, lip=::1, mpid=3557118, secured, session=<ZPZK9a5INroAAAAAAAAAAAAAAAAAAAAB>
Jan 18 13:55:37 lara dovecot: imap([email protected])<3557118><ZPZK9a5INroAAAAAAAAAAAAAAAAAAAAB>: Logged out in=1048 out=138593 deleted=0 expunged=0 trashed=0 hdr_count=200 hdr_bytes=76865 body_count=0 body_bytes=0
Jan 18 13:55:38 lara dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=::1, lip=::1, mpid=3557121, secured, session=<0jRj9a5IPLoAAAAAAAAAAAAAAAAAAAAB>
Jan 18 13:55:38 lara dovecot: imap([email protected])<3557121><0jRj9a5IPLoAAAAAAAAAAAAAAAAAAAAB>: Logged out in=70 out=770 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0
Jan 18 13:55:38 lara dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=::1, lip=::1, mpid=3557125, secured, session=<2sxm9a5IQroAAAAAAAAAAAAAAAAAAAAB>
Jan 18 13:55:38 lara dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=::1, lip=::1, mpid=3557126, secured, session=<UdVm9a5ISroAAAAAAAAAAAAAAAAAAAAB>
Jan 18 13:55:38 lara dovecot: imap([email protected])<3557126><UdVm9a5ISroAAAAAAAAAAAAAAAAAAAAB>: Logged out in=120 out=909 deleted=0 expunged=0 trashed=0 hdr_count=0 hdr_bytes=0 body_count=0 body_bytes=0
Jan 18 13:55:38 lara dovecot: imap([email protected])<3557125><2sxm9a5IQroAAAAAAAAAAAAAAAAAAAAB>: Logged out in=1048 out=138593 deleted=0 expunged=0 trashed=0 hdr_count=200 hdr_bytes=76865 body_count=0 body_bytes=0

 

If your timeout values are very low, this can happen. your server receives it but the remote server never gets the ack that it was received.

 

This log shows only the imap login/logouts of the user but not the receiving of the testmail from GMail you have sent. Search in the log for the mail from GMail.

 

Thank You @Turgut Kalfaoglu @pyte

This is from mail.log I searched my gmail account. Is this normal what should be in log or not, I see these lines with delay

grep "myemail@gmail.com" /var/log/mail.log

Jan 18 13:56:13 lara postfix/qmgr[2946]: A9DCFBBB3C: from=<[email protected]>, size=4670, nrcpt=1 (queue active)
Jan 18 14:00:02 lara getmail: msg 3443/3443 (6841 bytes) msgid 1750306262/39609 from <[email protected]> delivered to MDA_external command sendmail (b'')
Jan 19 07:48:02 lara postfix/smtp[4052374]: B4433BBE83: to=<[email protected]>, relay=gmail-smtp-in.l.google.com[192.178.157.26]:25, delay=2.5, delays=0.92/0.02/0.66/0.86, dsn=2.0.0, status=sent (250 2.0.0 OK 1768830482 6a1803df08f44-8942e6d0a8asi94145106d6.538 - gsmtp)
Jan 19 13:04:03 lara postfix/smtp[4170531]: 73F0CBBAB0: to=<[email protected]>, relay=gmail-smtp-in.l.google.com[2607:f8b0:4023:1425::1a]:25, delay=2.4, delays=0.5/0.04/0.66/1.2, dsn=2.0.0, status=sent (250 2.0.0 OK 1768849443 af79cd13be357-8c6a725f2d6si1059173885a.467 - gsmtp)
Jan 19 13:04:04 lara postfix/smtp[4170539]: 79317BC980: to=<[email protected]>, relay=gmail-smtp-in.l.google.com[2607:f8b0:4023:1425::1a]:25, delay=1.7, delays=0.39/0.02/0.22/1.1, dsn=2.0.0, status=sent (250 2.0.0 OK 1768849444 af79cd13be357-8c6a71a22bfsi1119925985a.16 - gsmtp)
Jan 19 13:04:04 lara postfix/smtp[4170535]: 1C3C7BC8E6: to=<[email protected]>, relay=gmail-smtp-in.l.google.com[192.178.157.26]:25, delay=2.4, delays=0.2/0.03/0.29/1.9, dsn=2.0.0, status=sent (250 2.0.0 OK 1768849444 6a1803df08f44-8942e6f1f69si128498306d6.752 - gsmtp)
Jan 19 13:04:04 lara postfix/smtp[4170541]: E1B0BBC245: to=<[email protected]>, relay=gmail-smtp-in.l.google.com[192.178.157.26]:25, delay=1.7, delays=0.22/0.01/0.22/1.2, dsn=2.0.0, status=sent (250 2.0.0 OK 1768849444 d75a77b69052e-502a1fd1aa7si139513981cf.368 - gsmtp)

 

You pull in messages with getmail from Gmail then inject them into Postfix and then Postfix realizes that gmail.com is not a local domain it is responsible for, so it sends the message back out to Gmail.

 

Thanks @pyte
Issue has been resolved by changing the password on the email account. No more duplicate emails.
Thanks to all.

 

I think you should rather remove your getmail configuration. Why are you even using that?

 

@pyte I think GETMAIL was installed with ISPConfig Perfect Server Tutorial.

"ISPConfig uses getmail internally to fetch mail from external accounts (e.g., from an old provider to your new server). The configuration for this is managed through the ISPConfig web interface rather than manual file editing for most standard use cases."