Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!mcsun!ukc!edcastle!hwcs!sfleming
From: sfleming@cs.hw.ac.uk (Stewart Fleming)
Newsgroups: comp.mail.misc
Subject: Re: SMail and biff
Keywords: smail, biff, comsat
Message-ID: <3055@odin.cs.hw.ac.uk>
Date: 22 May 91 23:43:59 GMT
References: <2989@odin.cs.hw.ac.uk> <1991May18.043542.27251@Veritas.COM>
Sender: news@cs.hw.ac.uk
Reply-To: sfleming@cs.hw.ac.uk
Organization: Computer Science Dept, Heriot-Watt University, Edinburgh
Lines: 43

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 ?"