interesting behaviour.

[Der Tynan]

First off, at the moment I don't own a 3B1, nor have I ever seen one, but I
hope to change all that pretty soon :-)

Anyway, if you are running vanilla AT&T rmail (or even smail2.5), then nothing
can creep in via rmail.  I have looked at this code, and am pretty confident
there is nothing there that could grab you.  However, if you received a Trojan
Horse from somewhere, it could have been kicked off by the incoming mail.
Perhaps there was some keyword in there, that the TH wanted.  This could have
come from one of two places.  A/  Downloading a 'uuencoded' binary (*always*
a bad idea), or B/ not checking source-code (a quick scan of the code can
usually reveal any nasties).  Given the user name (ubluit), I would be *very*
suspicious.  However, I am unsure as to how you found the new ID.  For example,
if 'mail' can't find your name in /etc/passwd, sometimes it will default to
"???" or some other such name.  Did you perhaps, leave yourself logged in
over a period of time?  In which case, did anyone have access to the machine?
One other thing to check on umbc3 (the remote machine) is the size of the
file which was transferred.  This is available in /usr/spool/uucp/SYSLOG.
Usually, mail is fairly small (1 -> 2k on the average).  If the file
transferred is reasonably big, then this is also suspicious.  If the disk
is unbootable, it sounds like the superblock was corrupted, as opposed to
just being empty.  Usually, a nasty invader will delete all the files, as
opposed to destroying the superblock.  It could be possible that your kernel
hacking just bit you, but then again, it's hard to tell.  As a final (and
important) note, DO NOT re-initialize or re-format your disk.  Unless the
program did a physical format of the disk (which I doubt), your data is
still where it always was.  On the disk.  Deleting a file only updates the
inode table, and the superblock.  The file itself is left on the disk.  One
thing I have done it the past, is make a "poor mans backup".  To do this,
use 'dd if=/dev/hd', where 'hd' is your hard disk, pipe it through 'vol' or
equivalent, and send it to the disk drive.  This will probably take about
60 disks, but it will be worth it.  dd shouldn't care whether or not the
hard disk has a valid filesystem.  Then, rebuild your hard disk.  Now you
have a set of disks, which have all your files (granted, they're scattered
across the disks).  You can thus regenerate your most important files.  Hope
this helps.
						- Der
-- 
	dtynan at zorba.Tynan.COM  (Dermot Tynan @ Tynan Computers)
	{apple,mips,pyramid,uunet}!Tynan.COM!dtynan

 ---  Send me flames, and I'll give your name and address to Scientology  ---