For most purposes (and assuming per-user rather than site-wide configuration) the shortest config files are as follows:
$ cat ~/.extsmail/conf spool_dir = "~/.extsmail/spool_dir" $ cat ~/.extsmail/externals group { external mymachine { sendmail = "/usr/bin/ssh -q -C -l user mymachine.net /usr/sbin/sendmail -t" } } $
where mymachine is a human-friendly name given to an
external (it does not effect processing), and user is your
username on the remote machine mymachine.net. If
you’re using msmtp, your
externals might look as follows:
$ cat ~/.extsmail/externals group { external mymachine { sendmail = "/usr/local/bin/msmtp -a myaccount" } } $
where mymachine is a human-friendly name given to an
external (it does not effect processing), and myaccount is
the msmtp account you want to send mail as.
You then need to configure other apps to use extsmail and run extsmaild, either as a daemon
(extsmaild -m daemon) or as a batch process
(extsmaild).
Starting and stopping UNIX daemons is a perennial problem, and extsmaild is no
different. Although multiple instances of extsmaild
can (in theory) run side-by-side without negatively impacting each other, this
is likely to lead to occasionally odd behaviour, and a general waste of
resources. extsmaild therefore uses a lock file
extsmaild.lock in the spool directory. When extsmaild
is running, this lock file will be both present and flock’d; if the
lock file is present but not flock’d, extsmaild
assumes there is not another instance is running (this case can happen e.g.
after a power failure). In general this means that simply calling
extsmaild in a start-up script will do the right thing.