Sentrion Overview Sentrion Platform Sentrion REAC Sentrion Mimecast Hard Appliances Virtual Appliances
Overview Policy Compliance Secure Content Filtering Cloud Partner Enterprise Community
Overview Download Security Support News Documentation Tips & Tricks DKIM FAQ Misc Milters
Overview Directory Synchronization Messaging Architecture Review High Volume Mail HIPAA Policy QUICKStart Implementation Performance Tuning Training Services Overview Message Routing and
Configuration
Message Policy
Management
Connection Control /
Attack Prevention
Directory Configuration
and Management
Overview Sendmail Partners Milter Community Industry Organizations System Integrators & Distributors
Overview Silver Support Gold Support Platinum Support Open Source Support Security Advisories Contact Support
Overview Customers Events Press Room Board & Investors Management Careers Contact Us
Overview Ask the Experts Security Chalk Talks Collateral Product Reviews & Awards IP Reputation Check Real-time Outbreak Monitor
Sendmail Inc.

HOME | CUSTOMER LOGIN
Follow Sendmail on Twitter
The Sendmail Blog
Sentrion Message Processors
Sentrion Application Store
Services
Partners
Support
Company
Resources
Open Source
 

Useful links

Table of Contents
home

Further Reading

secure-install

App Spotlight

Image Analyzer for Sentrion

Message Submission Program

The purpose of the Message Submission Program (MSP) is explained in secure-install. 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 submit.cf).

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

Options you may want to change include:

  • confTRUSTED_USERS, FEATURE(`use_ct_file'), and confCT_FILE for avoiding X-Authentication warnings.
  • confTIME_ZONE to change it from the default `USE_TZ'.
  • confDELIVERY_MODE is set to interactive in msp.m4 instead of the default background mode.
  • FEATURE(stickyhost) and LOCAL_RELAY to send unqualified addresses
  • confRAND_FILE if you use STARTTLS and sendmail is not compiled with the flag HASURANDOM.

The MSP performs hostname canonicalization by default. As also explained in sendmail/SECURITY, mail may end up for various DNS related reasons in the MSP queue. This problem can be minimized by using

FEATURE(`nocanonify', `canonify_hosts')
define(`confDIRECT_SUBMISSION_MODIFIERS', `C')

See the discussion about nocanonify for possible side effects.

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:127.0.0.1	"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 sendmail.mc file:

LOCAL_RULESETS
SLocal_trust_auth
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

FEATURE(`msp')

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.

Back to Table Of Contents cf/README for Sendmail 8.12.11 Eric Allman of the Sendmail Consortium Rev: 1.1.1.1, Updated 2006/10/11 Back to Top


Site Map | Privacy Policy | Terms & Conditions | Copyright © 1998-2013 Sendmail, Inc. All Rights Reserved.