Add to Dynamic screen refused hosts
We have a lot of hosts on Security Settings > Screen Host.
For example we have *.dotmailer.com, *.pur?.net, *.getrespooonse.com, *.createsend.com and more. Basically all this big companies that pretend to send solicited bulk mail but all they do is send unsolicited bulk mail. Thanks to this entries we have reduces our incoming mail by 90%.
The problem is this companies have loads of hosts and they try and try and try to send emails even when you reply with a 550 after the HELO several times.
Since added all those hosts to Screen Host our number of SMTP sessions (in) has gone for 300 per hour to 3000 per hour!!!
Our log files are full of 220 > HELO > 550 I thought, why don't you have an option to add to dynamic screen the refused hosts? That will stop all those incoming SMTP sessions that end with a 550 after the HELO.
Hello David,
Thank you for sharing your idea with us. It will be considered for future versions.
One thing I would like to clarify though. Adding the IP addresses of connections that are blocked by host screening to the IP screening list won’t actually stop the incoming SMTP session. It will allow MDaemon to reject the connection more quickly, but all the resources needed to establish the connection are still used. Your suggestion would save MDaemon from having to do the PTR lookup on the IP address, if its enabled, and would cause connections to be logged in the screening log instead of in the inbound SMTP log.
Thanks again for your suggestion,
Arron
-
David Alonso Pérez commented
Arron,
Thank you for your reply.
Well, it won't even save MDaemon to do the PTR record (in my case) because we don't do it, we send a 550 after the banned EHLO host and we close the connection.
However, the following benefits will apply:
a) Less clutter on the SMTP (in) screen: At the moment we have, sometimes, 20 rejected connections between good ones.
b) Smaller SMTP (in) log files: They have treble in size since we took drastic measures
c) Banned hosts do not seem to be getting the message that we do not want them, maybe if they can't even connect they will stop trying.
By the way, (a) and (b) also tie in with another suggestion I have about splitting the SMTP (in) logs which I will post as a suggestion soon.
Regards,
David