Sender Rewriting Scheme (SRS)

Advanced Configuration of Axigen


Sender Rewriting Scheme (SRS) is available starting with Axigen X3 Update 2 (10.3.2). 

SRS (Sender Rewriting Scheme) is a solution to the following problem: forwarding / redirecting breaks SPF anti-spam rules.

When SRS is enabled, Axigen rewrites the envelope from address (used in the MAIL FROM SMTP command) for all messages that originate from a forward or equivalent rule. The From header (displayed by mail clients) is not changed by SRS.

Configurations

You can configure SRS via two CLI server context parameters:.

  • enableSRS — used to decide if SRS rewriting takes place, both in the forward and the reverse case.
  • srsSecretKey — used when computing digests used by SRS. It should have at least 10 characters from the [a-zA-Z0-9] set.

The second parameter is optional, as Axigen will automatically generate / use a secret key. 

Changing srsSecretKey may result in Axigen not being able to compute the reverse SRS for emails that are already in transit using an older secret.

Note

When relying on a generated secret key in a cluster environment (this is an optional step, as Axigen has a fallback mechanism in case it's missing), the sysadmin must ensure that the srsSecretKey is shared between all the cluster members (i.e. set the same secret key on each of the cluster nodes).

When SRS is enabled

When SRS is enabled, the Axigen module that relays messages to the outside world applies the SRS rewrites to the envelope from (as part of the MAIL FROM SMTP command).

Axigen applies the SRS for non local recipients (i.e. recipients that are not hosted on the domains defined on the server), including group members using external addresses.

Handling Bounces (NDRs)

When a user sends an email to an Axigen user that has a redirect rule specified, if the message cannot be delivered to the final recipient (as specified in the redirect rule) as per the SRS standard, Axigen will forward the bounce (Non Delivery Report) message back to the original sender. This means that the end recipient of a redirect rule is revealed to the original sender as part of bounce messages.