Xref: utzoo unix-pc.general:1898 comp.sys.att:4973
Path: utzoo!utgpu!watmath!uunet!lll-winken!pacbell!att!icus!lenny
From: lenny@icus.islp.ny.us (Lenny Tropiano)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: ubluit exists
Message-ID: <558@icus.islp.ny.us>
Date: 19 Dec 88 05:25:21 GMT
References: <6348@fluke.COM> <743@auspex.UUCP>
Reply-To: lenny@icus.islp.ny.us (Lenny Tropiano)
Distribution: unix-pc
Organization: ICUS Software Systems, Islip, New York
Lines: 26

In article <743@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:
|>>I can't give you any answers, but I have turned up an interesting
|>>clue.  I happened to run strings on /usr/ucb/mail on my Sun 3/50 (BSD
|>>4.2, Sun 3.5.2) today and what should appear in the output but
|>>*ubluit*!
|>
|>"ubluit" appears to be the user name used by "Mail"/"mailx" if it can't
|>find a user name for the current user ID any other way - for instance,
|>if "/etc/passwd" can't be read, and, at least in the S5R3 version, the
|>LOGNAME environment variable isn't set.  Given that the file system
|>seemed to be in the process of being eaten by moths, that might explain
|>this.

Probably he was running mailx on his system.  That was available to from
the STORE with the appropriate authorization.  Most likely the old
UNIX pc, "getlogin(3C)" bug has appeared.  If getlogin() fails, it
generally returns "LOGIN", which will not appear in /etc/passwd, therefore
producing the "No mail for ubluit".   At least it's better to know you
probably weren't invaded.   I would put a "root" password if I were you
though!  Better safe than sorry! :-)

-Lenny
-- 
Lenny Tropiano             ICUS Software Systems         [w] +1 (516) 582-5525
lenny@icus.islp.ny.us      Telex; 154232428 ICUS         [h] +1 (516) 968-8576
{talcott,decuac,boulder,hombre,pacbell,sbcs}!icus!lenny  attmail!icus!lenny
        ICUS Software Systems -- PO Box 1; Islip Terrace, NY  11752