> I'm seeing the same thing, under certain circumstances. I have a PowerMac
> running Stanford's kerberized telnet program. If I telnet directly to a
> 486 running NetBSD, I get a kerberized connection, and I see the exact
> thing you see above, a ^@ after every line. What's annoying is that I
> think the telnetd is inserting it into the received data stream, and
> passing to to the shell or running program. It makes using elm imposable
> (to the extent it's possable at all :-)

The TELNET protocol specifies that bare CR should never be sent over the
wire; instead, you send <CR LF> if you want what Unix systems represent
by "\n", or <CR NUL> if you want what Unix systems represent by "\r".

See the bottom of page 10 in RFC854, and look for bugs in the client
and server implementations of this part of the spec:

"     The sequence "CR LF", as defined, will cause the NVT to be
"     positioned at the left margin of the next print line (as would,
"     for example, the sequence "LF CR").  However, many systems and
"     terminals do not treat CR and LF independently, and will have to
"     go to some effort to simulate their effect.  (For example, some
"     terminals do not have a CR independent of the LF, but on such
"     terminals it may be possible to simulate a CR by backspacing.)
"     Therefore, the sequence "CR LF" must be treated as a single "new
"     line" character and used whenever their combined action is
"     intended; the sequence "CR NUL" must be used where a carriage
"     return alone is actually desired; and the CR character must be
"     avoided in other contexts.  This rule gives assurance to systems
"     which must decide whether to perform a "new line" function or a
"     multiple-backspace that the TELNET stream contains a character
"     following a CR that will allow a rational decision.

--apb (Alan Barrett)