The problem is that the default behavior of the MSP is to attempt to deliver outgoing email by talking to the MTA over the system's internal loopback interface. This means that if we shut off the local MTA, then the default MSP will be unable to send email out of the system! This is not a feature.
It turns out that the MSP doesn't have to emit email by talking to the local MTA over the loopback interface. It can talk to any mail server on the network that the administrator desires. In this mode, the MSP is acting very much like the nullclient configuration that we discussed in the previous section. The macro configuration file is only slightly more complicated:
include(`cf/m4/cf.m4') define(`confCF_VERSION', `Submit') define(`__OSTYPE__', `') define(`confTIME_ZONE', `USE_TZ') define(`confDONT_INIT_GROUPS', `True') FEATURE(`msp', `mailhost')Again, set the pathname on the first line and the name of the machine on the last line as appropriate for your site. The configuration file produced from the above macros should be installed as
/etc/mail/submit.cf
on your systems.Note that you can also simply hack the
submit.cf
file
provided by your vendor. Just look for the line that readsD{MTAHost}[127.0.0.1]Just replace
[127.0.0.1]
with the name of your new
relay host. For example,D{MTAHost}mailhostSave your changes, and you're done!
The split between MTA and MSP is also reflected in how the Sendmail daemon is started at boot time. When using Sendmail v8.12, two daemons are normally started by the system boot scripts:
/usr/sbin/sendmail -bd -q15m /usr/sbin/sendmail -Ac -q15mThe first line looks identical to the normal Sendmail invocation for Sendmail v8.11 and earlier-- this is the MTA process that is listening on 25/tcp for incoming email, and which processes a queue of messages received by this process. The second line invokes a daemon for the MSP. This daemon doesn't listen on any port for incoming messages: its sole duty is to process a separate MSP queue for messages generated on the local machine but which could not be delivered immediately because the MSP's mail relay was unavailable for some reason.
So in v8.12 Sendmail, the MSP has its own message queue and its own daemon for flushing that queue on a regular basis. This means that on email "client" type machines the MTA daemon is completely unnecessary and can be shut off completely. In order to get this to happen, however, it will probably be necessary to hack the default boot script provided by your vendor. I have yet to find a vendor who has a simple configuration switch for disabling the MTA process without disabling the MSP. In fact, most vendors in my experience don't even realize that you can run the MSP without a local MTA.
No comments:
Post a Comment