Re: solution time for www/smtp hole

Marc VanHeyningen <>
From: Marc VanHeyningen <>
To: (Marc Andreessen)
Subject: Re: solution time for www/smtp hole 
In-reply-to: Your message of "Thu, 12 Aug 1993 19:13:39 EST."
Date: Thu, 12 Aug 1993 19:54:31 -0500
Message-id: <>
Status: RO
Thus wrote: 
>OK, let's bring this thing to a close.
>How about we start disallowing Gopher connections to anything other
>than 70 and 71 (some Gopher servers use the latter), HTTP connections
>to anything other than 80, Z39.50 and 210, and NNTP connections to
>anything other than (whatever the NNTP port is), etc. -- except for
>>1024, which is wide open.

In general, I think it's safe to assume ports >1024 are OK.  There are
a few strange ways of using them I can imagine (e.g. sending malicious
code to somebody's X server) but my off-the-top-of-my-head opinion is
that they're not a real problem.

There are some low ports that people use, but they generally follow
the "real" ones by small values (e.g. additional HTTP ports are often
81, 82, 83, Ohio State uses these if I recall correctly, and
additional gopher ports are often 71 as you mention.)

>Is that sufficient to make AT&T and MvH happy?  Does it cause any
>impact on *current* functionality?
>Is it also necessary to prohibit escaping of cr/lf?

My understanding is that real Gopher will never need CR or LF in its
titles, and thus it could be prohibited in Gopher URLs without
impacting functionality.  (I can't think of any supported protocol
that really needs them offhand, actually, but prohibiting them in all
URLs seems a bit harsh.)

Restricting to "reasonable" ports seems like a good idea.  How to
handle "suspicious-looking URLs" that don't use "reasonable ports" is
another matter; I personally would consider it fine to pop them up and
ask the user to examine the URL and confirm before the fetch is
performed.  Some people might think they should just be rejected

What you describe sounds sufficient IMHO; there's probably some other
kind of attack that nobody's thought of, but you can't anticipate

- Marc
Marc VanHeyningen  MIME, RIPEM & HTTP spoken here