🚀 go-pugleaf

In article <lyndon.674861290@aupair.cs.athabascau.ca> lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes:
>lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) writes:
>
>>What biff does is wake up periodically and check the mtime for your
>>mail file (/usr/spool/mail/$USER).  Test this by:
>>	echo Hi there >> /usr/spool/mail/$USER
>>and sit back and wait.  After a couple of minutes, biff will tell you 
>>that you have new mail.
>
>Huh? Biff (more properly, comsatd) waits for messages (on udp port 512)
>from your MTA. Upon receipt of a delivery notification from the MTA, it
>attempts to notify the user that mail has arrived. If your biff behaves like 
>you say it does, it's not the biff that the rest of us run (derived from BSD).

Yes, it quite definitely acts that way.  I just went to a su window on this
Ultrix 4.1 machine, and typed:
	(echo 'From: root'; echo Hello.; echo '') >>/usr/spool/mail/jc
I had xbiff running at the time.  About 25 seconds later, it beeped at me
and its flag went up.  I hadn't typed anything else in the meantime.  I
also had a tail -f running on /usr/spool/mqueue/syslog, and it showed no
activity whatsoever.

I strongly doubt that anything was sent to any daemon by my command.
If so, I'd really like to know what the mechanism was.  I mean, for it
to work like people are claiming, the shell would have to be realizing
that /usr/spool/mail/jc is the mailbox for a user.  This is obviously
quite feasible, but I think it's a rather dubious thing for even csh
to do.  I mean, mush, yes; csh, no.    On the other hand, such baroqueness 
would help explain why csh is the monster that it is.  Is there any way 
this might be tested?

(Well, I suppose I could write my own tcp daemon and plug it in on the
comsatd port 512/udp and have it report to me what it sees.  This is far
too much work to be worth the effort. ;-)