[250] in Release_7.7_team
Re: telnet -safe as default
daemon@ATHENA.MIT.EDU (ghudson@MIT.EDU)
Sat Jan 14 08:39:41 1995
From: ghudson@MIT.EDU
Date: Sat, 14 Jan 1995 08:40:21 -0500
To: jhawk@MIT.EDU
Cc: cfields@MIT.EDU, release-team@MIT.EDU, brlewis@MIT.EDU
In-Reply-To: "[249] in Release_7.7_team"
> If telnet -safe (-ax) were the default, then telnet to machines not
> supporting encrypted telnet, or machines that refused such for some
> reason (wrong realm, etc.), would fail.
> I would recommend that a new option be added, perhaps -A or somesuch
I could not find the bug chain you referred to, but I see no reason
why "telnet -safe" should be equivalent to "telnet -ax", or why
"telnet -ax" should fail if confronted with a system which does not
support authentication:
-a Attempt automatic login. Currently, this sends the user name via
the USER variable of the ENVIRON option if supported by the re-
mote system. The name used is that of the current user as re-
turned by getlogin(2) if it agrees with the current user ID, oth-
erwise it is the name associated with the user ID.
-x Turns on encryption of the data stream if possible. This option
is not available outside of the United States and Canada.
The language "attempt" and "if possible" suggests that fallback
behavior is appropriate; I don't see any reason to change this.
I suggest that "telnet -safe" be treated differently from "telnet
-ax", and that "telnet -ax" be the default behavior. The
documentation for -safe should be changed from:
-safe For MIT Athena, this option is equivalent to -ax.
to:
-safe For MIT Athena, this option attempts automatic login with an
encrypted data stream, and fails if this is not possible.
