[comp.mail.uucp] How to generate huge numbers of failed UUCP rmail commands

karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) (08/08/88)

I had a thoroughly amusing situation inflict itself on me last Friday.
I won't mention specific hosts or people, as there is no need to
embarrass individuals, but the general principle is worth repeating.

There is an address on a mailing list which I run of the form
uhost!username@inethost.edu.  Inethost.edu and uhost are in the same
city, just across town from each other, and since I'm on the Internet,
it's easiest just to hand things to inethost.edu which speaks to uhost
on demand.

The mailing list sees some traffic every day, perhaps 2 or 3 items
lately.  Friday morning, I came in to work to find that my mailbox had
over 200 bounce failures from uhost, of the form
	uuxqt (rmail username) failed, status (signal 0, exit 67)
or something of that sort.

Two hundred is rather impressive.  But since I wasn't actively
receiving any more of these then, I just deleted them en masse on the
assumption that a problem had been caused, found, and fixed.

About half an hour later, I started getting a lot more of these.  They
started arriving 4 and 5 PER MINUTE from inethost.edu.  As I hit 250
and 275, I got rather uncomfortable, since something was clearly well
out of control somewhere.  I crawled through my UUCP map data for
uhost, found the phone number of the admin there, and called him up.

They hadn't been aware of the problem immediately.  But at my urging,
they found that there were several hundred *more* of these rejections
q'd up in my general direction via inethost.edu.  They saw to it that
the rejections were destroyed, but of course we couldn't know how many
had already escaped to inethost.edu.  Also, it took a minute or so for
them to figure out what was wrong.  It seems that /dev/null on uhost
had become owned by news and chmod'd 0600.

Oops.

Uuxqt does things with /dev/null in order to create file descriptors
where commands expect to find them.  The inability to use /dev/null
apparently caused uuxqt to retry the failing mail forever.  The admin
at uhost pondered such things a bit, and found that it was caused by
the commenting-out of one line in a news-related shell script run by
cron.

So the matter was fixed at uhost.  I was still getting blasts from the
past via inethost.edu, though, at an impressive rate.  I found the
admin's phone # for inethost.edu in the map data again and gave him a
call.  On being told what was wrong, he checked his mailq, and found
some 400(?) items aimed at me.  He said he'd been wondering why his
poor innocent VAX had had a load that was Way Up There since before
he'd gotten to the office that morning.  He graciously started
removing things and I said thanx and goodbye.

When all was said and done, the final count of rejections I received
(not including those destroyed on being found at uhost and
inethost.edu) was...
		one thousand three hundred forty-six

Thought for the day: check any scripts dealing with /dev/null to make
sure you don't futz with it in the wrong way.

Cheers,
--Karl