This is going to sound like an odd question, but when you performed the telnet session, were you on the same network as the server? 

Reason why I ask is because our office has multiple static IPs and 2 of the IPs are dedicated to both our main mail server and the other to our backup mail server. Well the reverse lookup tied to both of those IPs is how our mail servers identified itself to the internet. Our dedicated IP for our office initially shared the same reverse lookup name that our mail servers use  when we were initially testing Smartermail many years ago. Since our office public IP reverse lookup shared the same name as our mail server IPs, a telnet session allowed mail to be sent without authentication because SmarterMail thought it was talking to itself. I had to contact our ISP and get the reverse lookup changed on our office IP address and now a telnet session cannot send an email without authentication.

So explaining what I did above, it does look like you are on the same network as the server because the server identified itself in your telnet session. You should not be able to telnet a server session outside that IP, so for instance from home or test it on a wireless hotspot that is off your network. I'm sure this puzzled you as much as it did for me on 15.7 until I realized what was going on. Once I changed our reverse lookup for our office IP, the telnet issue was resolved for us. This may or may not be an option for you if you have only 1 static IP. I'm also  not sure if version 16 & 17 exhibit this same behavior.

another reason may be, but I guess this is too simple: when you send mail to an address that's hosted on that server you don't have to authenticate.

or you have relaying with smtp in for anyone, by this time your mailserver will be abused so guess that isn't it either

your ip address is whitelisted for smtp? check security white lists