15.7 Handling Forwarded Mail in SPF Using the Sender Rewriting Scheme (SRS)

As describe above, SPF is a mechanism that attempts to prevent email forgery by looking up special TXT records associated with the domain in the mail FROM: (envelope from) address. This operation, which can actually involve several DNS lookups, eventually produces a list of IP addresses that are authorized to send mail from the domain. The IP address of the SMTP client is checked against this list and if it isn't found, the message may be considered to be fraudulent. Support for SPF was implemented in version 6.3 of the Messaging Server.

SPF presents 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 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 your 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 has now been implemented for our 6.3P1 release. The following MTA options have been added:

• SRS_DOMAIN. This 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 prevents a site from using their primary domain as the SRS domain.

• SRS_SECRETS. This is a comma separated list of secret keys used to encode and decode SRS addresses. The first key on the list is used unconditionally for encoding. For decoding, each key is tried in order to generate a different hash value. The decoding operation proceeds if any of the hashes match.

  The ability to use multiple keys makes it possible to change secrets without service disruption: Add a second key, wait for all previously issued addresses to time out, and then remove the first key.

• SRS_MAXAGE. Optionally specifies the number of days before a message times out. The default if the option isn't specified is 14 days.

  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 these options is sufficient to enable SRS address decoding. Encoding is another matter - it should only be done to envelope From: addresses you know are associated with forwarding activity. SRS encoding is controlled by six new 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 (noaddress 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 non-local addresses need SRS handling. In such a setup, tcp_local would be marked with the three keywords sourcesrs, destinationsrs, and addresssrs.

Finally, imsimta test -rewrite has been enhanced to show SRS encoding and decoding results for whatever address is input. For example, the address foo@example.com might produce the output similar to:

SRS encoding = SRS0=dnG=IS=example.com=foo@example.org

If this encoded address is rewritten it will produce the output:

SRS decoding = foo@example.com

imsimta test -rewrite will also show any errors that occur during SRS decoding.