Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Dec 2002 14:20:26 +0000
From:      Matthew Seaman <>
To:        freebsd-questions@FreeBSD.ORG
Subject:   Re: sendmail and jail question
Message-ID:  <20021230142026.GA60420@happy-idiot-talk.infracaninophi>
In-Reply-To: <000001c2aff2$d3a2e650$952b6e94@lucifer>
References:  <000001c2aff2$d3a2e650$952b6e94@lucifer>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Mon, Dec 30, 2002 at 12:01:38PM +0100, Didier Wiroth wrote:

> I would like to use sendmail "only" to send daily reports of it's own host
> and it's running jails, to an outside mail system!
> host ( with sendmail -> should send mail/reports etc to
> jail1 ( with sendmail -> should send mail/reports etc to
> jail2 ( with sendmail -> should send mail/reports etc to
> I've modified the alias files of the host and the jails and run newaliases!
> 1) What lines/options  do you have to add to the host's and jail's rc.conf
> to use it for my purpose?
> 2) What is the most secure to achive my goal, I don't want others to use it
> as a relay?
> I've tried this setting on the host:
> sendmail_enable="NO"
> So, sendmail is only listening on the localhost! This is great!
> BUT!
> Setting the same setting in the jail makes sendmail listening on:
> jail1
> 3) This makes sendmail accessible from the outside how do you prevent this?
> 4) Can a jail have it's personal loopback interface?
> 5) How do you make sendmail listening "only" to a specific ip address (when
> using ip alias), what flags do you have to use?
> 6) I'm sure other persons use this kind of configurations, how do you run
> sendmail (which flags) on these systems?

You don't need to have a persistent sendmail process running on a
machine in order to send e-mail from there.  In principle, all that is
required is to feed the properly formatted new e-mail into the stdin
of /usr/sbin/sendmail, which will then forward that one message as
required and immediately quit.

However, in practice things are a bit more complicated.  If the
machine to which the message would have been delivered is off-line
then the local sendmail will copy the message into the mail queue
(/var/spool/mqueue) to be dealt with at a later time.  Unless you run
a sendmail process to check the queue occasionally, nothing further
would ever happen to get that message delivered.

It is perfectly possible to run a sendmail process that does nothing
except wake up occasionally and deal with any messages that are
sitting in the queue.  Particularly it won't listen on port 25 for
incoming messages.

Before the split of sendmail into separate sm-msp and sm-mta
processes, you could achieve these states of affairs quite simply.

In the first case (no persistent sendmail process running at all, and
no second try at resending messages that didn't succeed first time)
all you needed was:


in /etc/rc.conf

For the second case (running a sendmail process that would do nothing
but check the outgoing mail queue occasionally), you just needed to
change the sendmail flags to drop '-bd' meaning "don't listen for new
connections on port 25":


Now with the advent of the sm-msp / sm-mta split, things are a bit
more complicated, and the number of sendmail_* variables in
/etc/defaults/rc.conf has quadrupled as a consequence.  The thing to
realise is that the sm-msp (Mail Submission Protocol) process *never*
needs to listen to a network socket, whereas the sm-mta (Mail
Transport Agent) process *always* needs to listen to one or more
network sockets.

Sending e-mail by piping it into /usr/sbin/sendmail is implicitly
talking to a sm-msp instance.  However, the sm-msp process can't do
final delivery of mail: it can only operate by feeding the message
into a sm-mta process listening on a network interface. That is
usually done to a sm-mta process on the same host listening on the
loopback interface.

This combination of flags in /etc/rc.conf will achieve the same effect
as the second case above --- a "send only" sendmail setup which will
check for and flush queued messages at regular intervals:

    sendmail_submit_enable="YES"         # This is the default setting
    sendmail_msp_queue_enable="YES"      # This is the default setting

However, it doesn't matter what the 'sendmail_outbound_enable'
variable is set to, as it's ignored if 'sendmail_submit_enable' is set
to "YES".

This gives you:

    a sm-msp process that doesn't listen to any network sockets and
    does nothing except flush the /var/spool/clientmqueue mail queue
    every so often (passing any messages to the sm-mta process).

    a sm-mta process that flushes the /var/spool/mqueue mail queue at
    regular intervals and only listens to the loopback interface
    (hence can't be used as a relay by arbitrary hosts on the 'net).

"Now", I hear you say, "that's all very well and good, but I've got a
rack of servers here that never send any e-mail except for the two or
three messages generated every day by the periodic scripts.  Surely I
don't need to run two sendmail processes all the time just for that?"

No, you don't.  If you have a central e-mail "smart host" that does
all of the real sendmail-fu you can drop the sm-mta process on your
other machines and configure the sm-msp process to talk directly to
the smart host. This entails modifying the
/etc/mail/ file, which I recommend you do as

In /etc/make.conf set the SENDMAIL_SUBMIT_MC variable to something
other than the default filename '' (this helps you avoid
trashing your settings by other-enthusiastic application of
mergemaster(8)) eg.

(Unlike the .cf and .mc files for the sm-mta process, there's no
mechanism set up in /etc/mail/Makefile for using `hostname`,
so we'll just have to do it all by hand).

Secondly, setup /etc/rc.conf:

    sendmail_msp_queue_enable="YES"         # This is the default setting

Now copy the default /etc/mail/ to your new filename
and edit it to change the FEATURE(`msp')dnl line at the end:

    # cd /etc/mail
    # cp
    # vi
    # diff -u
    ---   Fri Nov  8 13:16:39 2002
    +++ Fri Nov  8 23:14:22 2002
    @@ -20,4 +20,4 @@
     define(`__OSTYPE__',`')dnl dirty hack to keep proto.m4 from complaining
     define(`_USE_DECNET_SYNTAX_', `1')dnl support DECnet
     define(`confTIME_ZONE', `USE_TZ')dnl
    +FEATURE(`msp', `[]', `MSA')dnl

    # make install-submit-cf
    # make restart-mspq

The second argument in the FEATURE(`msp' ...) macro should be the
domain name (or IP number) of your smart host.  Enclosing the name in
[square brackets] is an optional extra that causes sendmail to ignore
any MX records in the DNS for that hostname and forward directly to
the given address.  The optional third argument tells sendmail to
speak to the smart host on port 587 --- the port reserved for
submitting new e-mails.

With this setup, there is no sm-mta process listening on any port, and
just the sm-msp process occasionally flushing the
/var/spool/clientmqueue mail queue.

"Right.  What about my machine running umpty-dozen jail environments
for my clients.  How can I let each jail user forward their e-mail
through the sm-mta process on the host environment?  How about letting
them run their own completely separate mail systems within each jail?"

To forward e-mails from a jail through the sm-mta process in the main
host environment is simple.  All you need to do is run a sm-msp
process in each jail using the modified as above.  The
"smart host" can either be in the main host environment on the jail
server or on some completely separate machine.  You might think that
you could use the default and speak to the host environment
via the loopback interface on port 587 (which, after all is shared by
all of the jails and the main host) but I've never been able to make
that work.

If you're running the sm-mta process in the main host environment it
will default to binding to all of the network interfaces on the
machine, including the alias addresses used by the jails.  That is
probably undesirable as adding or removing a jail address means
restarting sendmail and it may possibly open you up to relaying
through one of the jail addresses (although your sendmail
configuration should really be written to deny that anyhow).

You can control what addresses and ports the sm-mta process binds to
by modifying the /etc/mail/`hostname`.mc file. Suppose your jail
server has as it's principal network address, with
aliases,, ... used by jails.  In the host
environment you want the sm-mta process to listen on the loopback
address and on, and to ignore all other alias addresses.
This is achieved by adding the following to the
/etc/mail/`hostname`.mc file:

    FEATURE(no_default_msa)dnl ## overridden with DAEMON_OPTIONS below

    DAEMON_OPTIONS(`Name=IPv4, Addr=, Family=inet')dnl
    DAEMON_OPTIONS(`Name=IPv4, Addr=, Family=inet')dnl
    DAEMON_OPTIONS(`Name=MSA, Addr=, Port=587, M=E')dnl
    DAEMON_OPTIONS(`Name=MSA, Addr=, Port=587, M=E')dnl
    DAEMON_OPTIONS(`Name=IPv6, Addr=::1, Family=inet6')dnl

The FEATURE(no_default_msa) line prevents sendmail from listening for
e-mail submissions on port 587 on all interfaces, and we selectively
turn on just those interfaces we want with the
DAEMON_OPTIONS(`Name=MSA, ...')  lines.

In principle, you can run the sm-mta process in a jailed environment,
but you'll have to drop the lines referencing the loopback address
( or ::1) in the above, and you'll have to use the modified
sm-msp config as shown.  With that setup, there's nothing to prevent
you running both sm-msp and the sm-mta processes in each jail, hence
giving the jail an independendent mail system, but I've never tested
that so I can't guarrantee it will work.

Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK

To Unsubscribe: send mail to
with "unsubscribe freebsd-questions" in the body of the message

Want to link to this message? Use this URL: <>