SRS MTA options

From Messaging Server Technical Reference Wiki
Revision as of 17:12, 13 February 2020 by BulkPageCreator (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The MTA has a number of options relating to SRS (Sender Rewriting Scheme). SRS is a mechanism that can solve certain forwarding problems inherent in SPF (Sender Policy Framework, formerly referred to as Sender Permitted From). For a discussion of SPF itself, see SPF MTA options and the spf* channel options.

SPFpresents serious problems for sites that provide mail forwarding services such as universities (for their alumni) or professional organizations (for their members). A forwarder ends up sending out mail from essentially arbitrary senders, which of course can include senders who have implemented SPF policies and which of course don't list the IP addresses of the forwarding system or systems as being permitted to use addresses from their domain.

The Sender Rewriting Scheme, or SRS, provides a solution to this problem. SRS works by encapsulating the original sender's address inside a new address using the forwarder's own domain. Only the forwarder's own domain is exposed for purposes of SPF checks. When the address is used, it routes the mail (usually a notification) to the forwarder, which removes the address encapsulation and sends the message on to the real destination.

Of course address encapsulation isn't exactly new. Source routes were defined in RFC 822 and provide exactly this sort of functionality, as does percent hack routing and bang paths. However, these mechanisms are all problematic on today's Internet since allowing their use effectively turns one's system into an open relay.

SRS deals with this problem by adding a keyed hash and a timestamp to the encapsulation format. The address is only valid for some period of time, after which it cannot be used. The hash prevents modification of either the timestamp or the encapsulated address.

SRS also provides a mechanism for handling multi-hop forwarding without undue growth in address length. For this to work certain aspects of SRS address formatting have to be done in the same way across all systems implementing SRS.

SRS support is new in MS 6.3P1. SRS address decoding is enabled by setting the srs_domain and srs_secrets MTA options; setting the srs_maxage MTA option is optional as it has a reasonable default value. See the discussions of the specific options for more details.

Note: Every system that handles email for the selected SRS domain must be configured for SRS processing and must have all three SRS options set identically.

Enabling SRS address encoding must be more precisely configured. In particular, it should only be done to envelope From addresses that you know are associated with forwarding activity. In addition to requiring that the SRS domain be configured via srs_domain and that the decoding keys be set via the srs_secrets MTA option already mentioned, additional configuration is required via the *srs channel options, controlling exactly which addresses, on exactly which messages, have SRS encoding applied.

Prior to the 8.0 release, note that SRS decoding of addresses, as for notification messages routing back through the SRS MTA, could run afoul of the MTA's normal "relay blocking" configuration. In particular, for a "typical" configuration where all three *srs channel options are set on the tcp_local channel, this would be an issue. See SRS and Relay Blocking for a work around approach.

The basic steps to set up SRS are as follows:

  1. The srs_domain MTA option must be set to the domain to use in SRS addresses. Email sent to this domain must always be routed to a system capable SRS operations for the domain. SRS processing is handled as an overlay on top of normal address processing so nothing pervents a site from using their primary domain as the SRS domain.
  2. The srs_secrets MTA option must be set to contain at least one SRS secret.
  3. The srs_maxage can optionally be set to the number of days before an generated SRS address times out and becomes unusable. The default if the option isn't specified is 14 days.
  4. Configured SRS usage on the appropriate mail flows. (See below.)

Note that every system that handles email for the selected SRS domain must be configured for SRS processing and must have all three SRS options set identically.

Setting the three options described above is sufficient to enable SRS address decoding. Encoding is another matter - it should only be done to envelope from addresses yoy know are associated with forwarding activity. SRS encoding is controlled by six channel keywords: addresssrs, noaddresssrs, destinationsrs, nodestinationsrs, sourcesrs, and nosourcesrs.

Three conditions have to be met for SRS encoding to occur:

  1. The current source channel has to be marked with sourcesrs. (nosourcesrs is the default).
  2. The current destination channel has to be marked with destinationsrs (nodestinationsrs is the default).
  3. The current address, when rewritten, has to match a channel marked addresssrs (noaddresssrs is the default).

Encoding only occurs when all of these conditions are true. About the simplest setup is a pure forwarding one where all messages enter and exit on the tcp_local channel and all nonlocal addresses need SRS handling. In such a setup the tcp_local would be marked with the three keywords sourcesrs, destinationsrs, and addresssrs.

See also the error_text_srs_* MTA options, which control the exact error text issued when SRS errors occur.

See also: