Secondary mail servers managed by virtualmin unusable as of today: heavy bounce-back spams

I just had to shut down postfix on our secondary mail servers managed by virtualmin GPL out of Virtualmin Pro site-servers using virtualmin mail servers clustering.

Reason was that we had hundreds of smtp processes and thousands of email attempts to wrong emails but in valid domains, making our secondary servers spamming bouncebacks.

Virtualmin really needs to sync valid email addresses, and not only domains, so that secondary mail servers can directly reject invalid mails instead of trying to forward to main mail server and then to generate a SPAM mail bouncing back the original message.

As I understand from another few-months-old ticket in here (searched for it but didn't find) postfix supports a "valid emails" file, so that should be implementable.

We can't switch secondary mail servers on before that is resolved. Not a huge issue as our main servers are High-Availability, but still an issue, classifying it as a bug, as it makes the feature unusable.

Status: 
Closed (fixed)

Comments

I've heard of other users hacking up a solution to this by copying /etc/postfix/virtual to the valid-emails file on the secondary mailservers using a cron job that runs every few minutes. Ideally Virtualmin would setup something like this for you automatically, but if you need an urgent fix a solution like the one above will work..

I prefer to wait a week or so and have a clean solution integrated and maintained in Virtualmin by you guys, than a quick hack. ;-)

Our main mailservers are monitored, fully redundant with high-availability, fail-over on our private clouds with multi-tier-1 redundant connections, so we can easily live without secondary dns servers for a few days (and enjoy less spam). :-)

Many Thanks in advance for keeping us posted.

Actually, the secondary mail servers could check for the SMTP connection of primary servers, and turn on only when the primary mail servers fail, that would work too (and further reduce spam), but probably not be really green-flagged on SMTP-setup-checkers...

Actually, I would expect your clean solution to NOT be a cron job, but when users are added to primary mail servers, that it would be added to the secondary ones too using virtualmin's clustering protocol, and that there would be a button to do initial sync and/or sync check using same virtualmin clustering protocol.

Our secondary mail servers are on separate continents in different datacenters, so croning whole users-list every few minutes isn't really practical bandwith-wise.

And new mail users are not created every few minutes either.

It may take more than a week, but I'll add it to my TODO list for the next Virtualmin release.

Most likely I'll implement it by making a Webmin API call when a user or alias is added, updated or deleted .. or perhaps rsyncing the file across.

I second this feature ! But only if 1 VM Pro server is using the secondary.

I see one small issue here if you aren't using 1 secondary for 1 VM pro server.

What if the secondary server is secondary for more then 1 server ? Any clustering will cause a issue here.

I thought it was clear, but as it doesn't seem:

For us the chosen implementation needs to work similarly as Virtualmin already does... with more than 1 primary...

We have quite some primaries clustered each with the same two secondaries...

So obviously mail users need to be agregated by domains, supporting many primaries.

Any news on this item ?

Our secondary mail servers are still down due to this issue...

Sorry, I forgot all about this bug! Will take a look at it today ..

Sorry, I forgot all about this bug! Will take a look at it today ..

Sorry to bounce, but as it is 15 months later now and our secondary mail servers are still offline, I think it's ok to bounce ;) ?

I dont think this is a high priority for Joe and Jamie -- I stopped using and even setting up any secondary mail servers because this large gap in fighting spam.

This is still on my TODO list, but implementation of a syncing solution is not trivial so it hasn't been done yet..

Implementation of a syncing solution is not trivial, but there are many existing solutions to that standard problem.

This issue is a pretty annoying bug and in today's situation with spam and widespread use of automatic spamblock RBL lists does not allow to run the secondary mail servers using Virtualmin Pro, required for proper hosting configuration.

Do you have an ETA for fixing this bug (in our opinion the most annoying one of Virtualmin at this point) ?

We have been patient so far, to say the least. I hope that being patient is still the right attitude to get some priority ? ;-)

I'm going to move this up the priority list for inclusion in the next release, which should be in a few weeks ..

Thank you very much Jamie, great news!

Should be in a few days. BTW, you will need 3.87 on both the primary and secondary systems...

The one question I have is this, what if people have already started to implement the relay_recipient_maps ? Is the system going to be smart enough to know if there are existing users listed and not add duplicates or do people that are using it need to delete that map ?

Virtualmin will replace all entries in the relay_recipient_maps for the domains you are relaying with valid addresses from the primary system. So any manually added entries for other domains will be preserved, but all entries for domains managed by Virtualmin will be replaced..

Automatically closed -- issue fixed for 2 weeks with no activity.