Re: Predraft of a new URL scheme: mailmsg

> > This leaves the following ports that are clearly either useless or potentially
> > harmful:
> >
> > discard           9/tcp    Discard
> > chargen          19/tcp    Character Generator
> > smtp             25/tcp    Simple Mail Transfer
> > domain           53/tcp    Domain Name Server
> > kerberos         88/tcp    Kerberos
> > snmp            161/tcp    SNMP

> I'd add NNTP as well, assuming forging news as a problematic as forging mail.
> Unfortunately, there are hundreds of protocols, registered and unregistered,
> and I somehow doubt anybody would want to analyze them all for security
> concerns.

> When this was brought up before, it was pointed out a number of people
> use nonstandard ports for their information servers if they need to run
> multiple servers on the same machine for some reason; for instance, multiple
> HTTP servers would run on port 81, 82, 83...

Doing this sort of thing is fine, but not with the port numbers you indicate.
POrts 81-83 are assigned to the hosts2-ns, xfer, and mit-ml-dev protocols
respectively.

None of these are any sort of big deal (in fact I have no idea what any  of
them are), so this isn't likely to cause operational problems, but if you
continue this approach you'd hit port 88, which is where Kerberos lives.

A much better approach is to use port numbers >1023 for this sort of thing,
that is, ports not associated with any IANA-registered protocol.

I like the idea presented in an earlier message of saying that if the
port number is less than 1024 it has to be the actual port for that
particular service.

> Fortunately, this practice is declining now, but I expect there's somebody
> somewhere using at least some of these ports for something.  The question is
> whether it's common enough that we should have to worry about it.  I hope not.

I doubt if it really is declining that much. There is always the need to
test services on nonstandard ports, but the numbers >1023 are just the ticket
for this sort of thing.

					Ned

Received on Saturday, 7 January 1995 18:44:57 UTC