SPF| SRS
Navigation
› Home › Overview › Status › Download › Documentation › Support › FAQ
Validation
Validate the XHTML and CSS of this page.

SRS configuration parameters

SRS configuration parameters are the same and should behave in the same way regardless of the MTA in use. However, the mechanism for specifying these parameters will vary depending on your MTA. The SRS subsystem will use the MTA's native configuration system and will use the MTA's native definition of string, boolean, integer, list, etc. The following parameters will be available, all of which are optional except for srs_secrets and, on some MTAs, srs_domain:

srs_alwaysrewrite (boolean)
If true, perform SRS rewriting for ALL forwarding, even when not required. SRS rewriting is usually not required when the sender and forwarding domains are the same.
srs_domain (string)
A domain to use in rewritten addresses. This must point only to machines which know the encoding secret used by this system since any bounces will go to the MX for this domain. This is primarily of use when a system forwards mail for multiple virtual domains, or multiple mail servers forward mail for a single domain using different secrets. It may default to something sensible on some MTAs where appropriate information is available to the SRS subsystem.
srs_hashlength (integer)
The hash length to generate in a rewritten address. The hash length is a measure of security in the SRS system; longer is more secure. However, the default should be appropriate for all purposes.
srs_hashmin (integer)
The hash length to require when checking an address. If the hash length is increased, there may be SRS addresses from your MTA in the wild which use a shorter hash length. This parameter may be set to permit checking of hashes shorter than srs_hashlength. This parameter must be at most srs_hashlength. The default should be appropriate for all purposes.
srs_maxage (integer)
The maximum permitted age of a rewritten address. SRS rewritten addresses expire after a specified number of days (after which it is assumed no more bounces may be generated in response to the original mail). Mail sent to expired SRS address is dropped without ceremony. The default (about a month) should be appropriate for all purposes.
srs_secrets (string)
[required] A list of secrets with which to generate and check addresses. The first secret in the list is used for generating new SRS addresses. All secrets on the list may be used in an attempt to verify an SRS address.
srs_separator (string)
The separator to appear immediately after SRS[01] in rewritten addresses. This must be -, + or =. Some MTAs recognise at least one of these characters as a separator character between a username and an arbitrary text string in a local part. By setting srs_separator to such a character, all SRS addresses will appear to be directed to the user accounts srs0 or srs1. This might or might not be useful for trapping invalid SRS addresses, since the MTA's SRS subsystem will probably rewrite all valid SRS addresses before a mail reaches the recipient stage in the MTA.

Notes for exim

The exim patch was implemented by Shevek (srs [ta] anarres.org), based on work from Miles Wilton (srs [ta] mirtol.com), the author of the libsrs-alt implementation.

Notes for postfix

The postfix patch was implemented by Shevek (srs [ta] anarres.org) in a massively boring meeting which he was going to get into trouble for heckling any more.

Notes for sendmail

TODO: Document sendmail options and F/C syntax.

Notes for qmail

A qmail patch is (hopefully) in progress.

Notes for IIS/Exchange

An IIS/Exchange extension is (hopefully) in progress.

Notes for courier

We have no volunteers for a courier patch. Please offer.

Unsupported MTAs