Facebook
Twitter- Server operating system version
- AlmaLinux 8.10 (Cerulean Leopard)
- Plesk version and microupdate number
- Plesk Obsidian 18.0.67, actualización 3 Web Host Edition
Hi guys!
A few days ago, we suffered a security breach involving an email account password, causing more than 20,000 emails to be sent from that account using webmail in just over half an hour.
We were surprised to see that the outgoing control limit is enabled, but it always shows 0, just like this:
We've reviewed the documentation and several forum posts, but I can't find anyone with the same problem or a solution.
We use Warden AntiSpam and they have given us some instructions (How can I use Warden to monitor outgoing mail so that my server does not get listed on any DNSBLs? - Knowledgebase - Danami), but we don't see anything wrong with it.
This is the imagen from Warden's report:
As you can see in the image, the attacker accessed the client's webmail (Roundcube) and created a filter to prevent emails from being sent from that account. This account and domain don't exist on our server. (I don't know if this information can help in this case.)
We have followed the steps and checked that the limit is correctly configured in both the email account, the domain, and the subscription, as explained in the documentation: Protection from Outbound Spam
Although it is not exactly the error, we also tried to repair the database as indicated in this documentation: https://support.plesk.com/hc/en-us/...ble-to-execute-mailmng-outgoing-no-such-table
We have also created a cron task as indicated in this documentation: https://support.plesk.com/hc/en-us/...-How-does-Outgoing-Mail-Control-work-in-Plesk
As an additional note, this server does not use the default email storage path.
It was changed using the documentation: https://support.plesk.com/hc/en-us/...ault-location-of-mailboxes-in-Plesk-for-Linux
The path was moved from "/var/qmail/mailnames/" to "/home/storage/mailnames," and all emails are working correctly.
After all this, we're at a dead end and don't know exactly what else to look into or do. We'd appreciate it if you could help us solve this problem.
If you need any logs or more information, just let us know!
Thanks in advance!
A few days ago, we suffered a security breach involving an email account password, causing more than 20,000 emails to be sent from that account using webmail in just over half an hour.
We were surprised to see that the outgoing control limit is enabled, but it always shows 0, just like this:
We've reviewed the documentation and several forum posts, but I can't find anyone with the same problem or a solution.
We use Warden AntiSpam and they have given us some instructions (How can I use Warden to monitor outgoing mail so that my server does not get listed on any DNSBLs? - Knowledgebase - Danami), but we don't see anything wrong with it.
This is the imagen from Warden's report:
As you can see in the image, the attacker accessed the client's webmail (Roundcube) and created a filter to prevent emails from being sent from that account. This account and domain don't exist on our server. (I don't know if this information can help in this case.)
We have followed the steps and checked that the limit is correctly configured in both the email account, the domain, and the subscription, as explained in the documentation: Protection from Outbound Spam
Although it is not exactly the error, we also tried to repair the database as indicated in this documentation: https://support.plesk.com/hc/en-us/...ble-to-execute-mailmng-outgoing-no-such-table
We have also created a cron task as indicated in this documentation: https://support.plesk.com/hc/en-us/...-How-does-Outgoing-Mail-Control-work-in-Plesk
As an additional note, this server does not use the default email storage path.
It was changed using the documentation: https://support.plesk.com/hc/en-us/...ault-location-of-mailboxes-in-Plesk-for-Linux
The path was moved from "/var/qmail/mailnames/" to "/home/storage/mailnames," and all emails are working correctly.
After all this, we're at a dead end and don't know exactly what else to look into or do. We'd appreciate it if you could help us solve this problem.
If you need any logs or more information, just let us know!
Thanks in advance!
