cf/README for sendmail 8.12.3

Eric Allman of the Sendmail Consortium

Message Submission Program

The purpose of the Message Submission Program (MSP) is explained in sendmail/SECURITY. This section contains a list of caveats and a few hints how for those who want to tweak the default configuration for it (which is installed as

Notice: do not add options/features to unless you are absolutely sure you need them.

Options you may want to change include:

Some things are not intended to work with the MSP. These include features that influence the delivery process (e.g., mailertable, aliases), or those that are only important for a SMTP server (e.g., virtusertable, DaemonPortOptions, multiple queues).

Moreover, relaxing certain restrictions (RestrictQueueRun, permissions on queue directory) or adding features (e.g., enabling prog/file mailer) can cause security problems.

Other things don't work well with the MSP and require tweaking or workarounds. For example, to allow for client authentication it is not just sufficient to provide a client certificate and the corresponding key, but it is also necessary to make the key group (smmsp) readable and tell sendmail not to complain about that, i.e.,

define(`confDONT_BLAME_SENDMAIL', `GroupReadableKeyFile')

If the MSP should actually use AUTH then the necessary data should be placed in a map as explained in SMTP AUTHentication:

FEATURE(`authinfo', `DATABASE_MAP_TYPE /etc/mail/msp-authinfo')

/etc/mail/msp-authinfo should contain an entry like:

AuthInfo:	"U:smmsp" "P:secret" "M:DIGEST-MD5"

The file and the map created by makemap should be owned by smmsp, its group should be smmsp, and it should have mode 640. The database used by the MTA for AUTH must have a corresponding entry. Additionally the MTA must trust this authentication data so the AUTH= part will be relayed on to the next hop. This can be achieved by adding the following to your file:

R$*	$: $&{auth_authen}
Rsmmsp	$# OK

feature/msp.m4 defines almost all settings for the MSP. Most of those should not be changed at all. Some of the features and options can be overridden if really necessary. It is a bit tricky to do this, because it depends on the actual way the option is defined in feature/msp.m4. If it is directly defined (i.e., define()) then the modified value must be defined after


If it is conditionally defined (i.e., ifdef()) then the desired value must be defined before the FEATURE line in the .mc file. To see how the options are defined read feature/msp.m4.