sfleming@cs.hw.ac.uk (Stewart Fleming) (05/15/91)
I have had SMail (3.1.18.1 #18.7) running under Ultrix 4.0 on a pair of DECStation 5000/200 machines for a couple of months now. Mail delivery and forwarding functions work correctly; however, there is a problem with mail notification using the biff/comsat service as an inetd client. It would appear that SMail does not notify the biff server of incoming mail. Some of the source files refer to a specific BIFF transport, but this has not yet been implemented. So, two questions : 1) Does anyone have a biff notifier transport written and available ? 2) What is involved in writing a specific transport for this task ? I know the functions needed to communicate with biff, but I am unfamiliar with how to tie this into the SMail transport mechanism. Thanks for any help with this one - it's not a major-league problem, just a minor inconvenience... Stewart -- sfleming@cs.hw.ac.uk ...ukc!cs.hw.ac.uk!sfleming "Wow ! A flying mouse !" "Eeek ! A flying cat !"
tron@Veritas.COM (Ronald S. Karr) (05/18/91)
In article <2989@odin.cs.hw.ac.uk> sfleming@cs.hw.ac.uk writes: >1) Does anyone have a biff notifier transport written and available ? >2) What is involved in writing a specific transport for this task ? > I know the functions needed to communicate with biff, but I am > unfamiliar with how to tie this into the SMail transport mechanism. I don't really know how biff works (I never used it, though I have written similar things myself using shell scripts called from smail). However, if you can write a program that informs biff of what it needs to know, then you should be able to call it using a shadow transport from smail. To do this, change the "local" transport to something like: local: driver=appendfile, return_path, local, from, unix_from_hack, shadow=kick_biff; # change the stuff below as appropriate for your OS file=/usr/mail/${lc:user}, group=mail, mode=0600, suffix="\n" kick_biff: driver=pipe, local, from; # call your biff program with the user as the one argument cmd="/your/biff/program ${lc:user}", # allow the program to exit without reading the entire # message ignore_write_error, -log_output If you need to, you can also call your biff program under a specific user or group, for example, you can call it with group "tty" to access ttys directly. -- tron |-<=>-| ARPAnet: veritas!tron@apple.com tron@veritas.com UUCPnet: {amdahl,apple,pyramid}!veritas!tron
lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) (05/22/91)
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. It's that simple. All you have to do it get
smail to append the mail to the mailbox.
(Of course, I wouldn't be at all surprised if someone were to decide
that this is too simple-minded, and generate a protocol for dealing
with the job, expanding biff by a couple thousand lines and requiring
the rewriting of every mail-deliver agent in existence. :-)
{Of course, with xbiff this isn't needed, since adding the X library
itself expands biff from 10240 bytes (on this VAX) to 268288 bytes,
which should satisfy all but the pickiest memory salesmen. ;-}rickert@mp.cs.niu.edu (Neil Rickert) (05/22/91)
In article <22812@shlump.lkg.dec.com> 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. It's that simple. All you have to do it get >smail to append the mail to the mailbox. Naw. It is your shell which does that. Just set the right shell variable (MAIL for /bin/sh, mail for /bin/csh) the the path of your mail spool file, and see it happen. Biff does more. It prints part of the incoming message the moment it arrives. Actually biff itself doesn't do much more than chmod u+x `tty` . But when /bin/mail delivers mail to your mailbox, it also sends a packet to the 'comsat' network daemon giving it the name of your mailbox and the offset to the new message. comsat looks in /etc/utmp to see if your are logged in, then checks the 'x' bit of your tty to see if you wish to be biffed, then prints a few lines from the message on your terminal. The Berkeley version of /bin/mail are available with sendmail sources, so if you want to do something similar you can probably steal a few lines of code. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/22/91)
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). -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6mc.ab.can.noam As a math athiest, I should be excused from this. --Calvin
lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) (05/22/91)
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. ;-)
rickert@mp.cs.niu.edu (Neil Rickert) (05/22/91)
In article <22833@shlump.lkg.dec.com> lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) writes: >>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 The subject line and all the comments up till now have referred to 'biff'. Now you tell us you were really talking about 'xbiff', which may or maynot be the same thing. It might have been better if you had said 'xbiff' from the start. >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 On my system, csh doesn't have any trouble with this. In my .login file I simply place the command 'set mail=/usr/spool/mail/$user', and from then on csh knows exactly where to look. Other shells have similar facilities. >(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. ;-) It would be easier to just examine the output of 'netstat -a' to see if there is a listener on the biff port. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
djm@eng.umd.edu (David J. MacKenzie) (05/23/91)
You are confusing xbiff with biff. xbiff and biff are completely different programs that work completely differently. xbiff periodically stats the mailbox; biff (actually the comsat daemon does all the work; biff just chmods your tty) waits for messages on a socket saying that a user has new mail. -- David J. MacKenzie <djm@eng.umd.edu> <djm@ai.mit.edu>
djm@eng.umd.edu (David J. MacKenzie) (05/23/91)
You are confusing xbiff with biff. xbiff and biff are completely different programs that work completely differently. xbiff periodically stats the mailbox; biff (actually the comsat daemon does all the work; biff just chmods your tty) waits for messages on a socket saying that a user has new mail, and if the user is logged in and `biff y', notifies them. -- David J. MacKenzie <djm@eng.umd.edu> <djm@ai.mit.edu>
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/23/91)
lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) writes: |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. If you meant Xbiff, you should have *said* Xbiff :-) The two are completely different animals. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6mc.ab.can.noam As a math athiest, I should be excused from this. --Calvin
sfleming@cs.hw.ac.uk (Stewart Fleming) (05/23/91)
In article <1991May18.043542.27251@Veritas.COM>, tron@Veritas.COM (Ronald S. Karr) writes: >However, if you can write a program that informs biff of what it needs >to know, then you should be able to call it using a shadow transport >from smail. To do this, change the "local" transport to something >like: > local: driver=appendfile, return_path, local, from, unix_from_hack, > shadow=kick_biff; [...] > kick_biff: [...] OK, so far so good. But, the information I need to pass on to the biff server is a user name followed by an offset to the message within the mailbox. If the message for use Joe.Bloggs starts at byte 250, then I need to pass on the message : Joe.Bloggs@250 to biff. Can I guarantee that the shadow transport will run first (in which case, I just need to take the length of the file) or does it run after the "append-file" driver has been invoked (which makes for a rather trickier situation since the message length is not recorded anywhere) ? The obvious solutions are either to hack appendfile or to write a specific driver which is invoked directly before it. The SMail documentation is a bit sketchy on how to write your own drivers, transports etc. Is this kind of thing frowned upon ? One last question : why does SMail violate RFC822 in its comment header ? :-) tron |-<=>-| ARPAnet: veritas!tron@apple.com STF -- sfleming@cs.hw.ac.uk ...ukc!cs.hw.ac.uk!sfleming "Do telecommuters have more time to drive to the beach ?"
tron@Veritas.COM (Ronald S. Karr) (05/25/91)
In article <3055@odin.cs.hw.ac.uk> sfleming@cs.hw.ac.uk writes: >OK, so far so good. But, the information I need to pass on to the biff >server is a user name followed by an offset to the message within the mailbox. >If the message for use Joe.Bloggs starts at byte 250, then I need to pass on >the message : > > Joe.Bloggs@250 > >to biff. Can I guarantee that the shadow transport will run first (in which >case, I just need to take the length of the file) or does it run after the >"append-file" driver has been invoked (which makes for a rather trickier >situation since the message length is not recorded anywhere) ? Bugger. No, shadow transports run last (they are thus useful to indicate a successful delivery). Well, it is pretty easy to roll your own. I actually use the following shadow transport and shell script: shadow transport: local-report: driver=pipe, local, debug; cmd="/bin/sh /usr/smail/lib/localrpt ${lc:user}" shell script: # report message on one of the user's ttys (if logged in) tty= for test_tty in `who | grep "^$1 " | awk '{print $2}'`; do if [ -w "/dev/$test_tty" ]; then tty="$test_tty" break fi done if [ -z "$tty" ]; then cat > /dev/null # swallow the message exit 0 fi awk > "/dev/$test_tty" ' BEGIN { subject="No subject"; } /^[Aa][Pp][Pp][Aa][Rr][Ee][Nn][Tt][Ll][Yy]-[Ff][Rr][Oo][Mm] *:/ { if (sender == "") sender=substr($0,index($0,":"),255); } /^[Ff][Rr][Oo][Mm] *:/ { sender=substr($0,index($0,":"),255); } /^Subject:/ { subject=$0; } /^$/ { print "Message from" sender " " subject; exit } ' cat > /dev/null # swallow rest of message exit 0 This particular script doesn't work in a distributed environment, and should probably check for tty execute permission instead, but you should be able to get the point. >The obvious solutions are either to hack appendfile or to write a specific >driver which is invoked directly before it. The SMail documentation is a bit >sketchy on how to write your own drivers, transports etc. Is this kind of >thing frowned upon ? Despite a lack of documentation about how to do it, smail3 is very much designed to allow you to write your own drivers. This tends to be more useful for directing (resolving local addresses), and routing (resolving remote addresses), than for transports. For transports, most anything of interest can be handled by calling another program or a shell script, using the pipe driver. To get smail to work correctly with the comsat daemon, you would most likely have to hack on the appendfile driver. This would be trivial, but would be an annoying hack since it does violate smail's internal concepts of modularity. -- tron |-<=>-| ARPAnet: veritas!tron@apple.com tron@veritas.com UUCPnet: {amdahl,apple,pyramid}!veritas!tron