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 (192.168.0.2) with sendmail -> should send mail/reports etc to > [EMAIL PROTECTED] > jail1 (192.168.0.3) with sendmail -> should send mail/reports etc to > [EMAIL PROTECTED] > jail2 (192.168.0.4) with sendmail -> should send mail/reports etc to > [EMAIL PROTECTED] > > 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: > 192.168.0.3 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: sendmail_enable="NO" 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": sendmail_enable="YES" sendmail_flags="-q30m" 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_enable="NO" sendmail_outbound_enable="NO" 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/sendmail.submit.cf file, which I recommend you do as follows: In /etc/make.conf set the SENDMAIL_SUBMIT_MC variable to something other than the default filename 'submit.mc' (this helps you avoid trashing your submit.mc settings by other-enthusiastic application of mergemaster(8)) eg. SENDMAIL_SUBMIT_MC=myhost.example.com.submit.mc (Unlike the .cf and .mc files for the sm-mta process, there's no mechanism set up in /etc/mail/Makefile for using `hostname`.submit.mc, so we'll just have to do it all by hand). Secondly, setup /etc/rc.conf: sendmail_enable="NO" sendmail_msp_queue_enable="YES" # This is the default setting sendmail_outbound_enable="NO" sendmail_submit_enable="NO" Now copy the default /etc/mail/freebsd.submit.mc to your new filename and edit it to change the FEATURE(`msp')dnl line at the end: # cd /etc/mail # cp freebsd.submit.mc myhost.example.com.submit.mc # vi myhost.example.com.submit.mc # diff -u freebsd.submit.mc myhost.example.com.submit.mc --- freebsd.submit.mc Fri Nov 8 13:16:39 2002 +++ myhost.example.com.submit.mc 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')dnl +FEATURE(`msp', `[smtp.example.com]', `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 submit.cf 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 submit.cf 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 126.96.36.199 as it's principal network address, with aliases 188.8.131.52, 184.108.40.206, ... used by jails. In the host environment you want the sm-mta process to listen on the loopback address and on 220.127.116.11, 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=18.104.22.168, Family=inet')dnl DAEMON_OPTIONS(`Name=IPv4, Addr=127.0.0.1, Family=inet')dnl DAEMON_OPTIONS(`Name=MSA, Addr=22.214.171.124, Port=587, M=E')dnl DAEMON_OPTIONS(`Name=MSA, Addr=127.0.0.1, 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 (127.0.0.1 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 Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message