"Some of
us" are running spoofed identds for other internal reasons.
What do you mean by "certain protocol errors"?
I've noticed five major classes of errors.
[...]
Port number mismatch
This is the big one. This refers to the response containing
port numbers other than the ones in the query, as when I send
"1397,25" and get back "4900, 6667 : USERID : UNIX : yarjo"
[...]
Bogus UNIX username
This is a "USERID:UNIX:" response where the supposed username
contains a character not present in UNIX usernames.
[...]
Most of the trips of the "bogus UNIX" test
are identds that claim UNIX
usernames beginning with a space. This was perfectly valid under
RFC931 (which specified that whitespace was ignored even at the
beginning of a username), but with 1314 having obsoleted 931 over a
decade ago, I am quite willing to consider it broken today. If you use
that one you may want to ignore leading whitespace.
ITYM 1413, which amusingly offers the same type of response as valid
(despite condemning it in other places in the document).
"The information returned is that associated with the fully specified
TCP connection identified by <server-address>, <client-address>,
<port-on-server>, <port-on-client>, where <server-address> and
<client-address> are the local and foreign IP addresses of the
querying connection -- i.e., the TCP connection to the Identification
Protocol Server. (<port-on-server> and <port-on-client> are taken
from the query.)
For example:
6193, 23 : USERID : UNIX : stjohns
6195, 23 : ERROR : NO-USER
"
--
---------------------------------- personal:
http://www.armory.com/~spectre/ --
Cameron Kaiser, Floodgap Systems Ltd * So. Calif., USA * ckaiser(a)floodgap.com
-- Immigration is the sincerest form of flattery. -- Jack Paar ----------------