[mmh0000]

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.

[EE84M3i]

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?

[degamad]

Because for a long time, on most computers, the telnet client was the closest thing to an "open a tcp socket to this ip/port and connect the i/o from it to stdin/stdout" application you can get without installing something or coding it up yourself.

These days we have netcat/socat and others, but they're not reliably installed, while telnet used to be generally available because telnetting to another machine was more common.

These days, the answer would be to use a netcat variant. In the past, telnet was the best we could be confident would be there.

[indymike]

Same reason that people use vi. It's always there.

[linuxftw]

In the days of yore, Windows had telnet installed. Most hackers used telnet in the 90's and early 2000's.

[teddyh]

The telnet protocol with escapes, etc. is only used by the telnet client if you’re connecting to the telnet port. If you’re connecting to HTTP, SMTP or something else, the telnet protocol is not enabled.

[swinglock]

Because it's there.

[acters]

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.

[1718627440]

You can program without tools? I want to see that. Do you still have switches to alter RAM content, or do you use the butterfly method?

[fragmede]

who's hand rolling code anymore these days though?