Re: [msmtp-users] "mail" command wrapper for msmtp or sendmail?

[Robert Thorsby <robert@...93...>]

On 2007.06.22 07:36 Bill Johnstone wrote:
> Many scripts and system monitoring tools expect
> to use the "mail" command/MUA and its syntax
> rather than directly invoking the "sendmail"
> command.  I'm wondering if there is a program,
> following the same type of philosophy as msmtp,
> which provides a "mail" executable that just
> wraps msmtp or the "sendmail" command?

I think the situation is more drastic than merely "expecting" to find 
the mail command -- I suspect that many fundamental applications (eg., 
cron) will go into installation meltdown (a.k.a dependency hell) if 
"/bin/mail" is not there.

The Smoothwall/IPCop firewall applications used to get around this by 
(a) not including mail because of real or imagined security concerns 
and (b) making a symlink from "/bin/mail" to "/dev/null" (in earlier 
versions) or to "/bin/true" (in later versions). This meant that any 
application that checked on the availability of the mail command 
received a 0 reply (indicating success) and, likewise, anything sent to 
/dev/null or /bin/true received a 0 exit status report.

So, you can replace the mail applet with a symlink to nowhere if all 
you need is "confirmation" that "mail" exists -- but, beware, you will 
never actually be able to send any real mail using the "mail" command.

The other alternative is to symlink from "/bin/mail" to another applet 
-- but, why bother? The mail applet is only about 70KB in size and I 
feel sure that any replacement applet would not be significantly 
smaller.

It's worthwhile noting that the ultra-lightweight, send-only MTA's 
which are often less than 20KB in size (eg, smtpclient, nbsmtp) are 
actually substitutes for sendmail, not mail. In this context sendmail 
and its substitutes, including msmtp, are mostly used for sending mail 
to the outside world, via an ISP's MTA, whereas mail is used for 
internal (within LAN) delivery. This is why nearly all such substitutes 
"accept" sendmail options, even if they do nothing with them.

Of course, you can do the same symlink trick from "/usr/sbin/sendmail" 
to any sendmail-compatible MTA -- in fact, this is what most MTAs do. 
There are advantages in doing it this way. Your MUA simply pipes 
outgoing mail to "sendmail + options" and this is re-routed via the 
symlink to Postfix, Exim, Qmail or whatever. Thus you can change MTAs 
without reconfiguring your MUAs -- an exception is mutt which requires 
you to specify, in mutt's config file, the full path to "sendmail" (ie, 
its replacement).

The second advantage is that you can install another MTA and 
troubleshoot it completely before taking the final step of deleting 
sendmail and replacing it with a symlink -- think of the benefit to the 
enterprise sysadmin.

Sorry for this long-winded and egg-sucking ramble. But the upshot is:
	if you are going to replace mail, don't;
	if you are going to replace sendmail, use a symlink.

HTH,
Robert Thorsby