[RupertSalt]

No. MUDs should never have adopted port 23 or port 22 or any pre-assigned ports. There is no "well-known port assignment" from IANA for MUD-type games or servers.

The end of RFC854, the very last paragraph, states:

https://datatracker.ietf.org/doc/html/rfc854

   Port Assignment

      When used for remote user access to service hosts (i.e., remote
      terminal access) this protocol is assigned server port 23
      (27 octal).  That is L=23.

I would say that by the letter of the law, and by longstanding convention, that port 23/tcp is given to telnetd type login servers. A server listening on port 23 is expected to accept login credentials and furnish a shell or some management interface that affects the host itself. That someone would log in as a terminal user and perform computing tasks.

A MUD game could never be confused with managing the server where it runs, or a user/admin login to access that operating system. A MUD game has a specific purpose of recreation/leisure/communication.

Again, let us not conflate port 23 with telnetd with the TELNET protocol. These are all completely separate and distinct. Except that port 23/tcp implies TELNET protocol and also implies a telnetd-type server. It is sort of a one-way chain of requirement. telnetd could be run on any port (inadvisable) while TELNET protocol could be implemented by any other service (often preferable).

A MUD server is perfectly entitled to use TELNET protocol! In my server-hacking days, I often considered it a mistake and error not to support TELNET protocol! If I had known how to implement it, I would've added it to TinyMUCK myself! Honestly, it was not a priority because there was no known client supporting TELNET, either. Of course, protocol support needs to be on both ends to be effective. Without demand or capability from clients, it didn't really make sense for server programmers to add it in.

But we were perfectly content to stay on port 2283, port 4201, or port 6250, as our players and Wizards had established the games to run there, especially in those days we wished to escape notice by admins. The TELNET protocol can run on any port and support any "network virtual terminal" service. But the "telnet port" on 23 is special, unique, and as of last month, really inadvisable for everyone.

[FEELmyAGI]

> A MUD game could never be confused with managing the server where it runs

What do you think of [], highlights: It is extremely tightly integrated with the system. Connections are handled by telnetd, and the interface is basically considered a shell by the system. MUD characters are treated as actual users by the system, with a UNIX username consisting of "m-" followed by the first 5 characters of their selected character name. The database is stored as directories and files, with occasional symlinks.

Any programming or scripting language which is capable of manipulating Mooix's data files can be used to write custom commands, in a similar idea to, say, CGI. Libraries have been created to aid in this for several languages, including Perl, C, Ruby, and bash.

When a character is enabled as a programmer, they basically get the amount of power normally associated with a shell account. They can create and execute files, evaluate perl scripts, and can access a simplified version of a standard UNIX shell, among other benefits. Facilities are provided to edit Mooix scripts or programs (using your favorite editor) from within the MUD, then set them up to be executed when a user types a certain command.

[]https://everything2.com/title/Mooix

[RupertSalt]

Well that's unique!

It is a horse of a different color when user logins are handled by telnetd itself. I would imagine that access could also be provided by ssh. I know of no MUD that supports MFA, public/private keys, and host certificates!

At any rate, as of January 2026, Mooix users are gonna have a tough time connecting on port 23/tcp. I won't say they've been wrong for using it until now, but they may find themselves forced to switch to ssh, or at least a 4-digit port number. And patch that GNU telnetd ASAP, man.

EDIT: Sad to say, please do not visit the website cited in this linked article. It is, how you say, squatted by purveyors of smut. It may be the case that Mooix is abandonware.

[kps]

> by longstanding convention, that port 23/tcp is given to telnetd type login servers

First thing I ever telnetted to was Melvyl, University of California's library catalogue, around 1985. This was “remote user access” (I was a remote user) to “service hosts” (running the catalogue) providing “remote terminal access”. It was not a login.

[RupertSalt]

I remember using MELVYL too, and you're completely right about that.

I would suggest that MELVYL on port 23/tcp was also unnecessarily impinging on the IETF standards. MELVYL could have easily established its own well-known port with the IANA and not conflicted with the TELNET login port.

Before the WWW, there were a multiplicity of search services and indexes. Remember Archie, WAIS, and Gopher? Apparently, WAIS was assigned port 210/tcp, but Archie apparently used TELNET on 23/tcp as well.

I think some of the pioneering Internet services were perceived as not requiring a dedicated port. If MELVYL was the only service running on the mainframe and it wasn't running a Unix telnetd, then why not usurp 23/tcp? The admins there probably perceived it as a virtual "octopus cable" connecting remote "terminal labs", and for sure they had alternate methods of access for OS servicing and configuration purposes. In the beginning of MELVYL they were undecided about which protocol would prevail, and TCP/IP was competing with others, so port numbers may have been afterthoughts for the architects.

The most important thing may have been the principle of not surprising users or confusing them with parameters. "telnetting to a host" was way easier without trying to specify that they needed a port number. Just ask any Unix admin where MUD users try to bang on their telnetd port trying to play the game...

[simlevesque]

I don't understand how playing a MUD doesn't fit the definition of "remote user access to service hosts".

[da_chicken]

Boy, wait until I tell you what happened with http!

[metroholografix]

The vast majority of MUDs don't even implement the full TELNET protocol, just a small subset. In typical MUD fashion, fundamental TELNET parts like option negotiation were either hacked together -badly- or altogether ignored.

For the longest time in the 90s TELNET AYT would crash tons of custom implementations.

[Kim_Bruning]

You mean something like this?

     mudplayer:x:1001:1001:MUD Player:/home/mudplayer:/usr/games/adventure

[antonvs]

> I would say that by the letter of the law, and by longstanding convention,

Those are two different things, and you're confusing or conflating them.

"By the letter of the law", certainly if we're just talking about RFC 854, there's no mention of shells, or some of the other constraints you're projecting onto it.

"Remote user access to service hosts (i.e., remote terminal access)" is perfectly consistent with someone accessing a MUD.

When it comes to convention, though, which is influenced by pragmatic issues such as security constraints, you have more of a case.