Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Sep 2002 11:53:52 +0100
From:      Matthew Seaman <m.seaman@infracaninophile.co.uk>
To:        Doug Hardie <bc979@lafn.org>
Cc:        freebsd-questions@FreeBSD.ORG
Subject:   Re: sendmail 8.12 structure
Message-ID:  <20020907105352.GA19010@happy-idiot-talk.infracaninophi>
In-Reply-To: <f05111b7fb99f1bd58564@[10.0.1.90]>
References:  <20020604180503.A29935@seekingfire.com> <20020604172401.A68777@xor.obsecurity.org> <f05111b59b99defefeed4@[10.0.1.90]> <20020906085719.GC34657@happy-idiot-talk.infracaninophi> <f05111b7fb99f1bd58564@[10.0.1.90]>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 06, 2002 at 08:08:55PM -0700, Doug Hardie wrote:
> >With sendmail-8.12.x, sendmail functionality has been divided between
> >two processes:
> >
> >    sm-mta: SendMail Mail Transmission Agent, which is responsible for
> >    receiving messages from other machines or sending them off to
> >    other machines or, ultimately, handing the messages off to the
> >    local delivery agent.
> >
> >    sm-msp: SendMail Mail Submission Process, which is the process
> >    that mail user agents (mail, mutt, pine, etc) use to inject a new
> >    message into the system. 
> >

> Thanks.  However, some of it seems a bit fuzzy still.  There are 2 
> queues, the clientqueue and the mail queue.  Using the names from the 
> rc.conf file for the processes, the MUA will place outbound or local 
> mail in the client queue.  I believe that outbound then tries to move 
> the mail to the mail queue so sm-mta can deliver it either locally or 
> external.  However, sm-msp-queue also seems to do the same function. 
> Obviously I am missing something on this.

OK.  There are two processes to start up: the sm-mta and sm-msp
daemons.  The various sendmail_* variables in rc.conf control the
action of the /etc/rc.sendmail script.

Let's look at the sm-msp process first, because it's quite a bit
simpler.  In /etc/rc.sendmail, the start_mspq() function starts up the
sm-msp process.  Your choice is either to start the sm-msp process, or
not.  If you read through the /etc/rc.sendmail file you can see there
are three conditions required to start up the mail submission process:

    sendmail_enable not set to "NONE" in /etc/rc.conf
    sendmail_msp_queue_enable set to "YES"
    /etc/mail/submit.cf file exists

These are the default settings.  When the mail submission process is
started up, "sendmail-clientmqueue" is printed on the console.  Also
by default, this sendmail instance is started using these flags:

    sendmail_msp_queue_flags="-L sm-msp-queue -Ac -q30m"

which have the following meanings:

    -L sm-msp-queue     Use 'sm-msp-queue' as the label on messages passed
                        to syslog

    -Ac                 Read the /etc/mail/submit.cf configuration file,
                        rather than the default /etc/mail/sendmail.cf 
                        configuration file.

    -q30m               Check for and process queued messages every 30
                        minutes

That's fairly straight forward.  A bit further up the /etc/rc.sendmail
file you'll find the definition of the start_mta() function, which is
a little more involved.  Essentially it chooses between one of four
options in this order of precedence:

    i) Not running sendmail at all: 

        sendmail_enable="NONE" in /etc/rc.conf

   ii) Running sm-mta in the default mode:

        sendmail_enable="YES" in /etc/rc.conf (default)

       This starts sendmail with these flags:

        -L sm-mta  Label for syslogged messages

        -bd        Run as a daemon, and listen for SMTP connections on
                   port 25

        -q30m      Check and process any queued messages (in
                   /var/spool/mqueue) every 30 minutes.

       With these settings, sendmail will act as a fully capable mail
       transport, receiving e-mail from remote servers over the net,
       and all the other expected operations.

  iii) Running sm-mta so that only processes on the local machine can
       speak SMTP to it.  That is how the sm-msp process hands off new
       messages to the sm-mta.  This mode is enabled by the following
       combination of settings in /etc/rc.conf:

        sendmail_enable="NO"
        sendmail_submit_enable="YES"  (default)

       and the flags are the same as for (ii) with the addition of:

        -ODaemonPortOptions=Addr=localhost Only bind to 127.0.0.1:25
                                           to listen for SMTP
                                           connections.  The loopback
                                           interface should only be
                                           accessible from the
                                           localhost: may need to be
                                           enforced by firewall rules.

       This mode is appropriate for most general purpose machines
       ie. those that aren't expected to receive incoming messages.

   iv) Running sendmail in the most restrictive mode, where it will
       not listen for SMTP connections on port 25 at all.  This, I
       think, pretty much precludes running a separate sm-msp process,
       as it won't have any way of transferring messages to the sm-mta
       process.  As far as I can tell, the only method for sending
       e-mail with these settings (and assuming that you haven't
       restored the setuid bit to sendmail) is for root to pipe new
       messages into the standard input of sendmail.  These /etc/rc.conf
       settings will enable this:

        sendmail_enable="NO"
        sendmail_submit_enable="NO"
        sendmail_outbound_enable="YES"   (default)

       The sendmail flags used (sendmail_outbound_flags) are:

        -L sm-queue Lable for messages passed to syslog.

        -q30m       Check for and process any queued messages (in
                    /var/spool/mqueue) every 30 minutes.

       Notably this command line doesn't include '-bd' so the sendmail
       process won't bind to the SMTP port and listen for connections.
       This setup is suitable only for "maximum paranoia" machines
       like firewalls.

You're right that this whole thing is pretty confusing --- I got it
wrong in my first message in this thread...  Hope this makes things
clearer.

	Cheers,

	Matthew

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

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020907105352.GA19010>