But it doesn't use telnet!

When testing mail, I'll often have a customer do something like "telnet mailserver 25" or "telnet mailserver 110". The purpose, of course, is to do command line testing of smtp or pop (see How do I test a smtp connection?, How do I test an imap server? and How do I test a popd connection?)

Strangely enough, three times this week I've had the same response: "But we don't have telnet enabled on the server". More surprising to me was that at least two of these were from people I thought would know better: that is, they knew that adding a port number at the end of the telnet made it contact a different port. Apparently the confusion was elsewhere: they thought that a telnet program would be answering this request, noticing the different port number, and forwarding the traffic to something else (which is actually exactly what inetd and xinetd do, of course). Complicating things further, one explained that he knew inetd would be handling the request, but he still thought that telnet had to be running on the server because the origin of the connection was by telnet.

The answering daemon has no clue what program created the connection request it is talking to. Whether it was telnet, nc, Outlook Express or another smtp server is completely unimportant and completely unknown. Well, that's not completely true: it's vaguely possible that an answering daemon might hazard a guess based on heuristic analysis of how the other end makes requests, and a packet sniffer might make even better guesses based on packet header information, but that's all pretty esoteric and meaningless in this context.

It's always interesting to see how people have constructed an incorrect view of how something works. All of us have our own fuzzy areas where knowledge blends with invention and wishful thinking.