Host screening option to reject inbound EHLO based on criteria
In the light of recent botnet attacks it's become extremely useful to be able to block within the host screen using wildcards to prevent machines that are clearly compromised systems. Blocking via reverse dns checking helps someway but not in all cases and ideally if communication comes from a EHLO address that is not following RFC guidance of the dns name for the server in question then it should be rejected.
What I'm asking for in addition to this is the option to be able to enter criteria within the blocking option such as 'if the EHLO is without a dot' then refuse connection. This will stop all domestic systems such as EHLO LUCYS trying to connect and not continue with a dozen or so lines of correspondence before determining whether it's spam or not.
Thank you,
Graham
Graham Porter
shared this idea
Hello Graham,
Thank you for sharing your idea with us. Wildcards are supported in the host screening configuration. The difficulty is that email clients don’t use a FQDN when they are sending email. This means that if you were to block any EHLO value that did not include a “.” you would block all email clients that are trying to send mail through your server. This may work for you but it will cause problems for some. This is not to say that your idea is not valid, just that care should be taken. Your suggestion will be considered for future versions.
It is currently possible to block EHLO values that do not contain a “.”. To do this add an entry for . that is set to accept. Then add a second entry for * that is set to block. The entry to accept . must be above the entry to block *.
Please be careful if you add these entries, you may start blocking your own users.
Recommended values for host screening that will help to block connections can be found at: http://www.altn.com/Support/KnowledgeBase/KnowledgeBaseResults/?Number=855.
We have also added some additional security features for the next version of MDaemon that should help detect and block botnets.
Thanks again,
Arron