From owner-freebsd-questions Sat Sep 7 3:54: 9 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 387DB37B400 for ; Sat, 7 Sep 2002 03:54:02 -0700 (PDT) Received: from smtp.infracaninophile.co.uk (happy-idiot-talk.infracaninophile.co.uk [81.2.69.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCEB243E77 for ; Sat, 7 Sep 2002 03:54:00 -0700 (PDT) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk ([IPv6:::1]) by smtp.infracaninophile.co.uk (8.12.5/8.12.5) with ESMTP id g87ArwGk094855; Sat, 7 Sep 2002 11:53:58 +0100 (BST) (envelope-from matthew@happy-idiot-talk.infracaninophile.co.uk) Received: (from matthew@localhost) by happy-idiot-talk.infracaninophile.co.uk (8.12.5/8.12.5/Submit) id g87Arr7V094854; Sat, 7 Sep 2002 11:53:53 +0100 (BST) Date: Sat, 7 Sep 2002 11:53:52 +0100 From: Matthew Seaman To: Doug Hardie Cc: freebsd-questions@FreeBSD.ORG Subject: Re: sendmail 8.12 structure Message-ID: <20020907105352.GA19010@happy-idiot-talk.infracaninophi> References: <20020604180503.A29935@seekingfire.com> <20020604172401.A68777@xor.obsecurity.org> <20020906085719.GC34657@happy-idiot-talk.infracaninophi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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