Congratulations, you've just delved into the concept of networking layers by realizing that ports and protocols are not directly connected with each other. As others are saying, telnet can be used to connect to any TCP port. However to understand why this is possible you need to understand a bit about networking layers. If you've ever heard of the OSI 7 layer model this is what allows you to use telnet to connect to another port. Although on the Internet, they only concern themselves with 4 of the layers and its called the Internet Protocol Suite. Without layers of networking, each program would not only need to understand its own protocol, but would have to define its own IP addressing scheme and port system, which means each router would need to understand how to route these schemes and different protocols would be much harder to learn and diagnose. To put it simply, the Internet wouldn't work nearly as well without layers.
What you are concerned with are the transport layer and the application layer. At the transport layer we have Internet protocols like TCP and UDP with port numbers ranging from 1 to 65535 on each. At the application layer we have protocols such as HTTP, SMTP and DNS. Usually each Internet standards document that defines a protocol specifies a default TCP or UDP port that the protocol should use by default. Such as TCP port 80 for HTTP, TCP port 25 for SMTP, UDP port 53 for DNS and TCP port 23 for Telnet. The telnet program actually speaks the TELNET protocol, which is a standard protocol, but mostly an ancient one by current standards. Because its protocol sequences are made from 8-bit characters, you rarely see the protocol itself and its mostly transparent when compared with other more modern protocols like HTTP and SMTP that use human visible words in ASCII such as GET, POST, HELO, LOGIN, etc.
Because its protocol isn't generally visible, telnet made for a decent tool for connecting to other TCP ports and allowing the user to type in protocols manually. Some network administrators use this technique in order to diagnose problems with servers. However because the telnet program still has its own protocol and may send extra bits of data sometimes, you can still experience problems with this technique. When you use telnet you really are "making a connection" at the application layer as well as the transport layer. It just happens that other application layer protocols may work ok through it for most diagnostics and won't interfere with the telnet protocol. There is a better program for doing this through called nc (Net Cat. It gets its name from being a Network based version of the cat command).
$ nc www.stackexchange.com 80
The nc program doesn't speak any application layer protocol and when you make a connection with it you are "making a connection" only at the Internet layer (IP address) and Transport layer (TCP or UDP). What that means is that you control what application layer protocol is used. Almost anything is fair game, even binary protocols. This also allows you to do useful things like transfer files without them being corrupted and listen on ports for incoming traffic:
nc -l 9000 < movie.mp4 (Your friend runs this)
nc friends.computer.hostname 9000 > movie.mp4 (you run this)
And then movie.mp4 is transfered over the network using no application layer protocol (such as FTP) at all. The application protocol is actually your friend telling you that they are ready for you to run your command.
nc can also handle UDP packets and UNIX-domain sockets. Using it to listen can also be interesting.
nc -l 12345
Now in your web browser visit http://localhost:12345/ and in your nc session you should see the browser's
GET / HTTP/1.1 request. At this point you can type something in and press
Ctrl-D and it should show up in your browser in plain text (If you want HTML to show up, you have to send it back the proper HTTP protocol response followed by HTML code).
Sometimes, programs which natively speak one protocol like HTTP can connect to other ports that are meant for a different protocol. You typically can't do this in a GUI browser anymore because they have restricted them from connecting to some ports, but if you use a program like curl to connect to port 25 (SMTP for sending mail) you'll probably see a couple of errors about breaking protocol.
$ curl yourispsmtpserverhost.com:25
220 yourispsmtpserverhost.com ESMTP Postfix
221 2.7.0 Error: I can break rules, too. Goodbye.
This happens because curl normally speaks the HTTP protocol, so after it establishes a TCP handshake, it starts sending data like this:
GET / HTTP/1.1
But what the SMTP server is expecting is SMTP, which is more like this:
At which point the server sends back its identification line:
So you see that there is nothing that prevents curl from establishing a transport layer connection with the SMTP server, it just can't speak the protocol. But you can speak the protocol yourself with a program like telnet or more preferably nc.