🚀 go-pugleaf

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