Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!pa.dec.com!nntpd.lkg.dec.com!netrix.nac.dec.com!lan_csse From: lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) Newsgroups: comp.mail.misc Subject: Re: SMail and biff Keywords: smail, biff, comsat Message-ID: <22833@shlump.lkg.dec.com> Date: 22 May 91 15:05:45 GMT References: <1991May18.043542.27251@Veritas.COM> <22812@shlump.lkg.dec.com> Sender: news@shlump.lkg.dec.com Organization: Digital Equipment Lines: 34 In article 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. ;-)