Submit, relay, passthrough, conditionalpassthrough, conditionalrelay, destinationpassthrough, destinationrelay Channel Options

From Messaging Server Technical Reference Wiki
Jump to: navigation, search

Channel operation type (submit, relay, passthrough, conditionalpassthrough, conditionalrelay, destinationpassthrough, destinationrelay)

The MTA supports the concept of a general "operating mode" for message enqueue. Different modes provide different levels of message inspection, fixup, and error checking. There are four basic modes: default, submit, relay, and passthrough.

The MTA supports RFC 6409's Message Submission protocol (which is an update of RFC 4409, which is in turn an update of RFC 2476). The submit source channel option may be used to mark a channel as a submit-only channel. This is normally useful mostly on TCP/IP channels, such as an SMTP server run on a special port used solely for submitting messages; RFC 2476, since updated by RFC 6409, established port 587 for such message submission use.

Note that a channel marked submit has ETRN unconditionally disabled; that is, it gets the effect of disableetrn, irrespective of any *etrn channel option setting. A channel marked submit will also add a Date: header line, if one was missing from the original submitted message, without also adding a Date-Warning: header line; that is, since submission of messages without the (normally required for regular SMTP submission) Date: header line is legal on the Message Submission port, the MTA does not flag such messages originally lacking a Date: header line with the Date-Warning: header line it would generate in the case of such messages improperly submitted to the regular SMTP port.

Proper practice (configuration) on a submit channel includes requiring some form of user authentication, typically use of SMTP AUTH, and permitting (if not requiring) use of STARTTLS; see RFC 6409 (Message Submission for Mail). Thus a properly configured submit channel should normally be marked with mustsaslserver and maytlsserver (or musttlsserver if a site wishes to require STARTTLS use). Although requiring use of SMTP AUTH is what Message Submission channels should do, sites that wish to allow message submission without authentication (submission to the Message Submission port without requiring SMTP AUTH) may do so if enforcing some other form of sender verification, such as limiting such submissions only to certain "trusted" IP sources; see for instance the FROM_ACCESS mapping table which may be used to enforce IP source based restrictions.

Relay mode performs fewer checks than submit mode, however, certain structural message problems will cause message enqueue to fail with an error. For example, a missing Date: header field will result in an SMTP-level error in relay mode.

Relay mode is specified by adding the relay option to the appropriate source channel.

Passthrough mode disables as many checks and message modification steps as practical. For example, a message that is missing its required Date: header field will not have one added.

Passthrough mode is specified by adding the passthrough option to the appropriate source channel.

IMPORTANT NOTE: Passthrough can be a dangerous setting because it disables a number of checks clients are known to depend on. Additionally, various internal MTA functionality that depends on message inspection taking place, such as header field canonicalization, is disabled in passthrough mode. While it is tempting to use passthrough mode in some cases to work around problems caused by agents that insist on receiving standards-incompliant messages, field experience has shown that this "cure" is almost invariably worse than the disease.

Default mode (which of course is the default) lies somewhere between submit and relay. Most available checks and fixups are performed but few will cause an enqueue failure. Continuing the example of the missing Date: header field, in default mode a Date: field will be added by the MTA and a Date-warning: header field will also be added explaining that this was done.

There is no option associated with default mode.

New in MS 8.0, the destinationpassthrough channel option, if set on a destination channel, causes any enqueue of a message to that channel to be done in passthrough mode as long as the source channel isn't itself marked with the submit channel keyword. If submit mode is engaged the destinationpassthrough channel option is a no-op.

The default is destinationrelay, meaning the destination channel does not activate passthrough mode.

Finally, there are two additional mode setting options: conditionalrelay and conditionalpassthrough. These settings first check to see if the message already contains any Received: header fields. If such fields exist the mode specified in the option name is enabled, if not the MTA stays in its original mode.

For the Sieve "environment" extension, the MTA supports a private item, allowing Sieve scripts to discover what the current operation mode is.

New in 8.0, see the Sieve "setoperation" action, which enables system-level Sieve scripts to set what mode of operation to use for a message.

A common use-case for passthrough mode is to prevent message modification after DKIM signing. This is normally done by introducing an additional channel hop so that normal message rewriting, canonicalization, and so on can take place, attaching an appropriately configured DKIM signing milter to that channel, and marking the channel with the passthrough channel option to prevent any additional modifications. For example, assuming that all traffic from the tcp_submit channel to the tcp_local should be signed, an appropriate DKIM signing milter is set up on spam filter slot 3, the following configuration could be used:

Conversion mapping:



Channel definition:

process-dkim-sign sourcespamfilter3 passthrough \
 noreceivedfor noreceivedfrom enqueueremoveroute

See also: