SRS MTA options

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  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&#x27;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&#x27;s address inside a new address using the forwarder&#x27;s own domain. Only the forwarder&#x27;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&#x27;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&#x27;s Internet since allowing their use effectively turns one&#x27;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    and     MTA options; setting the    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    and that the decoding keys be set via the    MTA option already mentioned, additional configuration is required via the    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&#x27;s normal "relay blocking" configuration. In particular, for a "typical" configuration where all three  channel options are set on the    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:



 The  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. 

 The  MTA option must be set to contain at least one SRS secret. 

 The  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&#x27;t specified is 14 days. 

 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:,  ,  ,  ,  , and.

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



 The current source channel has to be marked with. ( is the default). 

 The current destination channel has to be marked with  (  is the default). 

 The current address, when rewritten, has to match a channel marked  (  is the default). </li>

</ol>

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  channel and all nonlocal addresses need SRS handling. In such a setup the  would be marked with the three keywords ,  , and.

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

See also:
 * srs_domain MTA Option
 * srs_maxage MTA Option
 * srs_secrets MTA Option
 * token_char MTA Option
 * addresssrs Option
 * destinationsrs Option
 * sourcesrs Option
 * error_text_srs_syntax MTA Option
 * error_text_srs_timeout MTA Option
 * error_text_srs_badhash MTA Option
 * SPF MTA options
 * MTA options
 * spfhelo Option
 * Typical TCPIP channels and servers
 * SRS and Relay Blocking