Security / SMTP EHLO Blocks - IP Address
Problem reported by Curtis Kropar www.HawaiianHope.org - 8/25/2025 at 10:19 PM
Submitted
We are currently on Build 9014 (Is there any way, even in a newer version to...)
Today I am looking though the SMTP logs and realize we have thousands of authentication attempts, and most of them are connecting with a "EHLO" that is an IP address.This is just some of them.

[2025.08.26] 00:20:40.492 [190.149.234.185][23550932] cmd: EHLO [190.149.234.185]
[2025.08.26] 01:28:36.557 [107.189.46.127][26230297] cmd: EHLO [107.189.46.127]
[2025.08.26] 01:28:54.060 [13.68.214.34][33933126] cmd: EHLO [13.68.214.34]
[2025.08.26] 01:28:56.143 [98.102.148.242][63490115] cmd: EHLO [98.102.148.242]
[2025.08.26] 01:29:34.781 [121.73.169.96][56211651] cmd: EHLO [121.73.169.96]
[2025.08.26] 01:59:40.460 [73.231.102.189][4727703] cmd: EHLO [73.231.102.189]
[2025.08.26] 02:00:04.559 [70.91.135.181][13716335] cmd: EHLO [70.91.135.181]
[2025.08.26] 03:19:44.312 [34.169.155.199][27116654] cmd: ehlo [10.88.0.4]
Take notice, the last one is also a private IP address, and it has been banging away at us for days.
So, Several questions.
1) When Smartermail gets an IP Address as the EHLO, and not a domain, are the brackets [ ] included as part of the inbound data ? Or does SmarterMail add those in to signify a domain ?  If I set up an SMTP Block should the block be for " [10.88.* "   or just " 10.88.* " ?
2) Is there any way, even in a newer version, to simply say reject any EHLO attempts that is an IP address and not a domain ?  
3) Is it possible to use single space question marks, instead of Asterisk wild cards ?  So to block "???.???.???.???"  or some RegEx method to signify an IP address ?

4) Are there really legit mail servers that are on IP addresses only for the EHLO ?

www.HawaiianHope.org - Providing technology services to non profit organizations, low income families, homeless shelters, clean and sober houses and prisoner reentry programs. Since 2015, We have refurbished over 11,000 Computers !

J. LaDow Replied
Lots of Android devices fail to properly identify when connecting as clients, and revert to an IP address - we had this issue and could not block EHLO with just IP recognition.  Otherwise, there are no legit servers we've seen in 10 years.

It would be nice to be able to enforce a rule that if the server connects and IDs with IP only, that the supplied IP matches the detected physical IP and not something mismatched. That would knock down a LOT of it.
MailEnable survivor / convert --
Anyone else ?
If I SMTP block an "ehlo" with a left bracket "[" will that block IP Address attempts ?
or is there any time a bracket will legitimately show up in an "ehlo" ?
www.HawaiianHope.org - Providing technology services to non profit organizations, low income families, homeless shelters, clean and sober houses and prisoner reentry programs. Since 2015, We have refurbished over 11,000 Computers !
Andrew Barker Replied
Employee Post
SmarterMail is not adding the brackets to the received data, they are included in the data provided by the connecting system. The SMTP specification (RFC-5321) indicates that the machine sending the EHLO command should identify itself using either a domain name or an IP address. If an IP address is provided, it should be wrapped in square brackets. As J. LaDow indicated, this is most likely to occur with a user's client application, so blocking based on an EHLO including a square bracket is likely to negatively impact end users.
Andrew Barker Software Developer SmarterTools Inc. www.smartertools.com
We run  this with absolutely zero impact on users... but we dont get the hammering from IP's on EHLO.

Gabriele Maoret - SERSIS Replied
Hi Brian!

can you share the full rule and where in smartermail you enable that?
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
Sure.

Settings -> Security -> SMTP Blocks -> New

Gabriele Maoret - SERSIS Replied
Thanks Brian! I'll give it a atry...
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
J. LaDow Replied
Android clients will have an issue - most of them don't identify with a host name...  So this will only work if your mailboxes are not on the same server as the incoming SMTP...
MailEnable survivor / convert --
We run all our clients and ourselves that way and Android clients connects fine :)
Millennium Systems Replied
Brian,

You must be lucky, we had an Outlook user being blocked from sending out email within a few minutes of adding that rule.

07:32:04.504 [184.180.214.223][58145060] connected at 9/16/2025 7:32:04 AM
07:32:04.504 [184.180.214.223][58145060] Country code: US
07:32:04.517 [184.180.214.223][58145060] cmd: EHLO [192.168.1.192]

I only have it on inbound mails for that exact reason :)
Millennium Systems Replied
We had it set up inbound as well, like the screen you provided. I guess SM sees the connection as inbound when authenticating for sending email.
Apparently :)
Gabriele Maoret - SERSIS Replied
After a few hours of testing, we had to remove this rule because MANY customers that send email via direct SMTP clients (MS Outlook, EM Client, Thunderbird, and even iOS or Android smartphones) are blocked and unable to send.

Immediately after removing this rule, everyone can get their clients working again.

So, I can say that it's not a good idea after all...
Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
Thats pretty weird... we have zero complaints and zero undeliverable mail.... clients customers dont complain ether.

We have run this for 2+ years now no issues.
J. LaDow Replied
What we REALLY need is the ability to detect whether or not the supplied string from EHLO is a "generic IP address" and compare that to the actual IP that is connecting - and based on our own rules determine whether to accept or deny that connection. The ability to exclude certain ranges would help - since many "mobile device clients" EHLO as their NAT based IP and not their public IP... A huge portion of these "[nnn.nnn.nnn.nnn]" addresses aren't actually even the same IP sent as being connected from - which - if we could test for this - would eliminate a lot of bad connections.




MailEnable survivor / convert --

Reply to Thread

Enter the verification text