So Telnet as a client is not dead though, right? A long time ago, I used to use the Telnet client to talk to SMTP servers (on port 25) and send spoofed emails to friends for fun.
With port blocking widening in scope, I’ve long believed that we would one day have every service and protocol listening on port 443. Since all other ports are being knocked off in the name of security, we’ll end up having one port that makes port based filtering useless.
netcat, socat and openssl s_client are all available for general manual connection testing.
As are many other tools. But the ones above are basically far better direct telnet alternatives.
I've never really understood why it's a thing to use a telnet client for transmitting text on a socket for purposes other than telnet. My understanding is that telnet is a proper protocol with escape sequences/etc, and even that HTTP/SMTP/etc require things like \r\n for line breaks. Are these protocols just... close enough that it's not a problem in practice for text data?
Because it's there.
If it's alright to be pedantic, anyone with programming knowledge can do the same without these tools. What these offer is tried and tested secure code for client side needs, clear options and you don't need to hand roll code for.
None of this affects the use of telnet the client program nor the ability to run a telnetd on your own host (but do be sure it's patched!).
What's happened is that global routing on the internet (or big chunks of it, it's not really clear) has started blocking telnet's default port to protect presumably-unpatched/unpatchable dinosaur systems from automated attack. So you can no longer (probably) rely on getting to a SMTP server to deliver that spoofed email unless you can do it from its own local environment.
> started blocking telnet's default port
But that's 23 and smtp is 25.
SMTP has and is almost blocked everywhere to dissuade spam.
You would still be able to use the telnet client to connect to an SMTP server on TCP port 25, just not port 23, right? I don't think that part changed here.
It's... not super clear from the article whether this is a port block or a stateful protocol thing. But yes, you're probably right and SMTP spoofing is probably safe for now.