Potential Bug After Restoring Backup – Mail-in-a-Box Used for Sending Spam

1

Hello everyone,
I hope you’re all doing well.

I’m writing this post to report a potential issue I encountered while using Mail-in-a-Box.

I decided to create a new virtual machine using KVM on my server to separate the Mail-in-a-Box installation from the host system. After setting up everything and installing Mail-in-a-Box on the VM, I copied the backup files from my previous setup to restore around 2000 user accounts.

I used the following command to restore the backup:

sudo -E duplicity restore --force file:///home/backup/encrypted /home/user-data/

At first, everything seemed to work perfectly. However, after a few hours, I noticed a significant performance drop. Upon investigating, I discovered that something strange was happening—my VM was being used to send out spam emails.

The /var/log/mail.log file grew to over 6 GB in less than 12 hours, which clearly wasn’t normal.

When I ran:
postqueue -p

I was shocked to see an endless mail queue filled with outgoing spam messages. The system continues to send spam without stopping.

This behavior began only after restoring the backup. It makes me suspect that either:

  1. Something malicious got into the backup (e.g., via a compromised user account or script), or
  2. The restoration process exposed a vulnerability or misconfiguration.

I’m sharing this in case others have experienced the same issue. If anyone has insights or suggestions, please let me know.

Here’s a snippet from postqueue -p output:

45A848F4F7     2893 Tue Apr 1 18:59:02 MAILER-DAEMON
(host outlook-com.olc.protection.outlook.com[REDACTED] said: 451 4.7.651 The mail server [REDACTED] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see https://postmaster.live.com (S3114) [Name=Protocol Filter Agent][AGT=PFA][MxId=11BADFAC61B2E32F] [DB5PEPF00014B89.eurprd02.prod.outlook.com 2025-04-01T17:35:39.755Z 08DD6FD6335FF6D9] (in reply to MAIL FROM command))
                                                                       n-roman@outlook.com
(host msn-com.olc.protection.outlook.com[REDACTED] said: 451 4.7.651 The mail server [REDACTED] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see https://postmaster.live.com (S3114) [Name=Protocol Filter Agent][AGT=PFA][MxId=11BADF9F521F500A] [BL6PEPF00020E60.namprd04.prod.outlook.com 2025-04-01T17:36:52.390Z 08DD6FCFAB0EA34B] (in reply to MAIL FROM command))
                                                                       nromeromartinez@msn.com
(host hotmail-com.olc.protection.outlook.com[REDACTED] said: 451 4.7.651 The mail server [REDACTED] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see https://postmaster.live.com (S3114) [Name=Protocol Filter Agent][AGT=PFA][MxId=11BADFD34A81B0B2] [BL6PEPF00022573.namprd02.prod.outlook.com 2025-04-01T17:45:13.456Z 08DD6FE9A70AB87E] (in reply to MAIL FROM command))
                                                                       nromens@hotmail.com
                                                                       nromer70@hotmail.com
                                                                       nromero@hotmail.com

4C60C8EC88   2893 Tue Apr 1 18:47:26 MAILER-DAEMON
(host live-com.olc.protection.outlook.com[REDACTED] said: 451 4.7.651 The mail server [REDACTED] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see https://postmaster.live.com (S3114) [Name=Protocol Filter Agent][AGT=PFA][MxId=11BADFABB8C97ECC] [SA2PEPF00003F67.namprd04.prod.outlook.com 2025-04-01T17:38:33.830Z 08DD6FD5DE4B550B] (in reply to MAIL FROM command))
                                                                       nicholepete@live.com
(host hotmail-com.olc.protection.outlook.com[REDACTED] said: 451 4.7.651 The mail server [REDACTED] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see https://postmaster.live.com (S3114) [Name=Protocol Filter Agent][AGT=PFA][MxId=11BADFF5D1D73EE9] [SN1PEPF000252A1.namprd05.prod.outlook.com 2025-04-01T17:51:27.413Z 08DD6FFAEAA1A465] (in reply to MAIL FROM command))
                                                                       nicholeofobbsjo0210@hotmail.com
                                                                       nicholeopunui@hotmail.com
                                                                       nicholepatricefletcher@hotmail.com
                                                                       nicholepettway@hotmail.com.

425158EF6D   2893 Tue Apr 1 18:48:29 MAILER-DAEMON
(host hotmail-com.olc.protection.outlook.com[REDACTED] said: 451 4.7.651 The mail server [REDACTED] has been temporarily rate limited due to IP reputation. For e-mail delivery information, see https://postmaster.live.com (S3114) [Name=Protocol Filter Agent][AGT=PFA][MxId=11BADFF27AF0197B] [DS3PEPF0000C37D.namprd04.prod.outlook.com 2025-04-01T17:51:27.163Z 08DD6FF93F35B7BA] (in reply to MAIL FROM command))
                                                                       nicky_evi@hotmail.com
                                                            <0xC2><0xA0

take a look on this!

root@box:/home/vbz# ps aux | grep sendmail
root       11918  0.0  0.0   7016  2060 pts/0    S+   20:50   0:00 grep --color=auto sendmail
root@box:/home/vbz# ps aux | grep sendmail
root       11920  0.0  0.0   7016  2116 pts/0    S+   20:50   0:00 grep --color=auto sendmail
root@box:/home/vbz# ps aux | grep sendmail
root       11922  0.0  0.0   7016  2040 pts/0    S+   20:50   0:00 grep --color=auto sendmail
root@box:/home/vbz# ps aux | grep sendmail
root       11924  0.0  0.0   7016  2088 pts/0    S+   20:50   0:00 grep --color=auto sendmail
root@box:/home/vbz# ps aux | grep sendmail
root       11965  0.0  0.0   7016  2264 pts/0    S+   20:51   0:00 grep --color=auto sendmail
root@box:/home/vbz# ps aux | grep sendmail
root       11967  0.0  0.0   7016  2232 pts/0    S+   20:51   0:00 grep --color=auto sendmail
root@box:/home/vbz# ps aux | grep sendmail
root       11969  0.0  0.0   7016  2240 pts/0    S+   20:51   0:00 grep --color=auto sendmail
root@box:/home/vbz# ps aux | grep sendmail
root       11971  0.0  0.0   7016  2144 pts/0    S+   20:51   0:00 grep --color=auto sendmail
root@box:/home/vbz# ps aux | grep sendmail
root       11973  0.0  0.0   7016  2072 pts/0    S+   20:51   0:00 grep --color=auto sendmail
root@box:/home/vbz# ps aux | grep sendmail
root       11975  0.0  0.0   7016  2140 pts/0    S+   20:51   0:00 grep --color=auto sendmail

Thanks in advance!

Best regards,

2

Check the Outbox of your email clients and the webmail. Delete all outgoing mail from outbox.

Please purge all email from postqueue.

Read here:

Purge

Either your backup thinks it has unsent mail. and trying to send, or your username and password have been compromised.

Do change the password. Do not change the password on any of the email clients you use as they may be the source of those messages.

As per the above I am afraid you have been blacklisted for multiple attempts to send to multiple users.

Check if you are backlisted: https://multirbl.valli.org/
Stop all the sending and try to delist yourself. Start with Spamhaus. Now they have a form in contacts. Go directly there If auto delist dosen’t work.
Explain frankly and say you are not a bulk sender.

If you are sending via port 25 and you are blacklisted, maybe you should consider changing the IP and build the IP reputation rather than wait a few weeks for Outlook Gmail and the big mail providers to delist you automatically. I am not really sure that gmail will ever forget the IP and the domain name.

Cat the maillog see what is going on. When you done with purging, Is postfix trying to send anything after purging and password change.
Are you backlisted by gmail?

cat /var/log/mail.log | grep "postfix/smtp" | grep -P 'status=' cat /var/log/mail.log | grep "postfix/smtp" | grep -P 'status='

If everything OK. Delete the logs to free up space.

3

Thank you for your reply Vele.

Unfortunately, I’ve already tried everything you suggested.

As of now, my public IP does not appear to be blacklisted — as shown in the screenshot below:
image

I have purged the Postfix mail queue multiple times, but as soon as I restart the Postfix service, the queue fills up again almost immediately.

Even after closing port 25, and even disabling HTTP/HTTPS, the issue persists.
This strongly indicates that a local script is causing the problem.

Important note:
The VM is now completely isolated from the internet ( for outgoing data ), yet the behavior continues — which confirms it’s coming from within the system.

Also, the mail log becomes unreadable:
Within just 2 minutes, /var/log/mail.log grows to over 250 MB, and it continues to expand as long as Postfix is running.

I tested this command

cat /var/log/mail.log | grep "postfix/smtp" | grep -P 'status=' cat /var/log/mail.log | grep "postfix/smtp" | grep -P 'status='

At this point, I’ve tried every reasonable method I can think of — but so far, no success.

Any other ideas or deeper debugging suggestions would be greatly appreciated.

4

Good! if you are not listed, but Outlook as per the first post seems to block you.

Start fresh.
Reserve the public IP. Terminate the instance. Make another clean instance. Reinstall the latest MIAB. Recreate the users.
DO NOT RESTORE BACKUP

Test Outlook and Gmail via telnet. Google test SMTP via telnet.

Check if you are blocked.

Read here Gmail, Yahoo work but iCloud emails bounces with 503 5.5.1 Error: send HELO/EHLO first (in reply to RCPT TO command) - #3 by vele

Are Outlook and Gmail blocking you.
If yes, delist yourself from Outlook https://sender.office.com/
No need to try to delist from Gmail they will not respond. They have an auto delist according to some AI crap. This is in the bulk sender contact form: Sender Contact Form - Gmail Help

Do not restore the backup yet. Try sending some test messages from the webmail.
Check the logs for symptoms.

I am not really sure how a backup can trigger a malware but it could be possible.

Now if your clean machine is acting OK. Use as backup method the rsync option. No need to restore from duplicity.

Rsync the user-data directory.

See what is going on afterwards.

If you wish to investigate further on the dirty machine you can try something like Tshark a WireShark gui-less app and see what or who is making the network requests and spam. This might be tedious. I am out of other ideas.
Good luck

5

Yes Vele, I followed your suggestions precisely:

  • Removed the old KVM instance
  • Set up a fresh new KVM

This time, I made sure to focus on security improvements for the Linux server, such as hardening root access, enhancing network security, and other relevant measures.

Fortunately, everything went smoothly, even with the backup restoration method! I made sure to test the server thoroughly without a domain name, and everything was functioning well.

As for the issue with Outlook, no, they did not block my IP. I performed all possible tests, and everything worked perfectly this time.

However, I’m still curious about what exactly caused the issue in the first place. It’s important to investigate further. I plan to continue testing with new KVM setups until I can find any signs or root cause. It’s possible that some dormant malware in the Mail-in-a-Box system was triggered somehow.

Thank you again for your help!

6

Hmm. Not really sure. Be careful with port egress 25 open. A malicious script can use other methods to send from the box, circumventing postfix. Then you really need Wireshark to identify the source. In your case it was the box sending via postfix and no other clients since you changed the password, so it was easy.

7

Hey Vele,

It seems the issue hasn’t been fully resolved yet. Yesterday around 18:40, the same problem reappeared. I’ve been monitoring the auth.log file and noticed that a cron job appears to be triggering some form of malicious activity.

Here’s an excerpt from the log file:

Apr  3 15:41:25 <host> systemd-logind[827]: New session 2 of user vbz.
Apr  3 15:45:01 <host> CRON[2732]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Apr  3 15:45:01 <host> sudo:     root : PWD=/root ; USER=www-data ; COMMAND=/usr/bin/php8.0 -f /usr/local/lib/app/occ dav:send-event-reminders
Apr  3 15:45:01 <host> sudo:     root : PWD=/root ; USER=www-data ; COMMAND=/usr/bin/php8.0 -f /usr/local/lib/app/cron.php

This pattern repeats frequently. The log suggests that PHP scripts are being triggered by root via cron and executed as the www-data user.

Additionally, I created a watcher script to monitor how often the sendmail method is invoked. Below is an excerpt showing repeated activity by the cron daemon:

2025-04-03 11:25:02 - User: root(0:0) - Host: <hostname> - TTY: not a tty
no-tty - PWD: /root - Parent: /usr/sbin/CRON - Args: -FCronDaemon -i -B8BITMIME -oem root
...
2025-04-03 13:50:02 - User: root(0:0) - Host: <hostname> - TTY: not a tty
no-tty - PWD: /root - Parent: /usr/sbin/CRON - Args: -FCronDaemon -i -B8BITMIME -oem root

This suggests that sendmail or a similar process is being run on a consistent schedule, potentially every 5 minutes, without any direct user interaction.

8

These are Nextcloud related.

See here: mailinabox/setup/nextcloud.sh at 3efd4257b57fe0063ab0f22e9019874e85369a7d · mail-in-a-box/mailinabox · GitHub

And also here: Using the occ command — Nextcloud latest Administration Manual latest documentation

and here: Background jobs — Nextcloud latest Administration Manual latest documentation

2 Likes
9

I am no expert on MIAB cron jobs but I am sure somebody on this forum can identify them. Anyway. Do close Port 25 and while you are trying to identify the culprit send via relay. If it is a malware script sending via PHP it must exploit port 25 for sure. Sending via relay will eliminate this problem.

@alento has a discount promo for all forum users.

Read this forum how to setup a relay in postfix’s main.cf.

1 Like
10

See my post before yours :wink:

As mentioned in my previous post, I’m pretty sure it’s Nextcloud, more specifically the occ dav:send-event-reminders command that runs every 5 minutes: mailinabox/setup/nextcloud.sh at 3efd4257b57fe0063ab0f22e9019874e85369a7d · mail-in-a-box/mailinabox · GitHub

And yes, Nextcloud does invoke the sendmail command to send event reminders to the local mailboxes. See here: mailinabox/setup/nextcloud.sh at 3efd4257b57fe0063ab0f22e9019874e85369a7d · mail-in-a-box/mailinabox · GitHub

See also the links to the Nextcloud documentation in my previous post for more detailed explenations what the cron.php and occ dav:send-event-reminders do.

I can tell you that much. It’s definitely not malicious! :slight_smile:

11

@miabuser It makes sense. Just cleaning the calendar should resolve it. On the other hand I had problems with CardDav in an unrelated incident when it was refusing to snooze and delete events via email clients. Cleaning it from the web did the job.

12

There’s probably nothing to resolve here. At least not based on @ahmadkoudier’s latest post.

I mean, he says there are 2000 mailboxes on this server. So I’d say it’s quite plausible that almost every 5 minutes at least one user gets notified about an event in their calendar, wouldn’t you? :wink:

13

WOW this is why skimming and scanning paragraphs is no good on forums. :smile:

I didn’t know that MIAB can handle 2000 mailboxes. This requires a more robust mail server.

I guess disk space is no problem @ahmadkoudier if you are running your own homelab?

14

None of the users actively use Nextcloud or any calendar-related features. Therefore, I’m focusing on migrating only the mailboxes to the new server — which is the fifth instance I’m setting up so far.

I’ve also blocked port 25 as you advised and ran multiple tests, but the root cause is still unclear at this point.

15

I don’t have any hardware limitations — I run my own on-premises datacenter with 5TB of storage and 64GB of RAM :smile:

16

If no one is using nextcloud. WARNING you may delete data: You can enable administrator login in nextcloud and either disable user by user and test
or go to >> Administrator Settings >> Basic Settings >> Email Server >>> Sendmail

JUST change to some nonexistent username or password and see if it stops sending notifications.

As a last resort just delete the users.

You are own your own this is unsupported and you have to run the script to enable the admin username in MIAB.

Also there are some more elegant ways to purge the calendars as per this:

17

Are you sure it send only to local mailboxes?
This maybe true as password reset doesn’t work via nextcloud because sendmail is not properly configured to send outside?

18

First of all, it probably doesn’t even use sendmail, because sendmail is not installed by default on Ubuntu and Mail-in-a-Box doesn’t install it either, but most MTAs create a symlink for the sendmail command. Yes, the sendmail command appears to be called every 5 minutes, but it then most likely uses the local MTA installed on the system, in this case potstfix.

Let’s summarize what we know:

According to the information we have gathered, starting with this post…

  • there is a cronjob that executes a Nextcloud occ command every 5 minutes described as “Sends event reminders”.

  • The Nextcloud install script of Mail-in-a-Box configures Nextcloud to send notification emails via 127.0.0.1, using the sendmail command, which then uses the local MTA to send emails to whatever email address is configured in the personal settings of a Nextcloud user. Nextcloud users are managed by Mail-in-a-Box, so the email addresses of the Mail-in-a-Box users will be used.

    \$CONFIG['mail_domain'] = '$PRIMARY_HOSTNAME';
\$CONFIG['mail_from_address'] = 'administrator'; # just the local part, matches therequired administrator alias on mail_domain/$PRIMARY_HOSTNAME
\$CONFIG['mail_smtpmode'] = 'sendmail';
\$CONFIG['mail_smtpauth'] = true; # if smtpmode is smtp
\$CONFIG['mail_smtphost'] = '127.0.0.1'; # if smtpmode is smtp
\$CONFIG['mail_smtpport'] = '587'; # if smtpmode is smtp
\$CONFIG['mail_smtpsecure'] = ''; # if smtpmode is smtp, must be empty string
\$CONFIG['mail_smtpname'] = ''; # if smtpmode is smtp, set this to a mail user
\$CONFIG['mail_smtppassword'] = ''; # if smtpmode is smtp, set this to the user's password

So, based on this information, how likely is it that something else is causing these sendmail command calls?

Could it be something else? Sure, but nothing in @ahmadkoudier post suggests that. In fact everything suggests that it is this very Nextcloud cronjob that triggers the sendmail command every 5 minutes.

2 Likes
19

Maybe a dumb question, or maybe I missed something, but why doesn’t OP just disable the cron job?

2 Likes
21

Yes, he could do that and then see if the sendmail calls stop, although there are other things in Mail-in-a-Box that call sendmail as well, but not likely at those exact 5 minute intervals: Code search results · GitHub

However, if this cronjob is the cause, and I’m pretty sure it is, there’s no reason to disable anything. By default Nextlcoud users are managed by Mail-in-a-Box and only the calendar and contacts app ar enabled. Nextcloud does not send any emails to random email addresses, but only to the addresses that are assigned to the respective user accounts, which again are managed by Mail-in-a-Box.

1 Like