SPF and SRS

Sender Policy Framework (SPF) is a mechanism for preventing sender forgery in SMTP transaction, thus allowing domain owners control over who may send mail from their domain.

Sender Rewriting Scheme (SRS) is a mechanism for rewriting sender addresses when a mail is forwarded in such a way that mail forwarding continues to work in an SPF compliant world.

SRS can work without SPF, but not vice versa, i.e., issues with forwards may arise if SPF is implemented without SRS.

WARNING:
If SRS is enabled in H-Sphere, the problems may arise with forwarding mail to servers where SRS is not supported. In such cases, mail may return undelivered back to users. The next H-Sphere mail service package will provide a more friendly way to handle forwards to such servers.

This documentation explains the arrangement of these resources at the server level. Please read how to enable and configure SPF and SRS in admin CP.

SPF (Sender Policy Framework)

SPF is implemented at the level of:

• DNS TXT records;
• SMTP server.

 

DNS TXT Records

Once the SPF resource is enabled in H-Sphere, DNS TXT records will be provided for each A and MX records in E.Manager->DNS Manager.

DNS TXT records have the following format:

domain.com IN TXT "v=spf1 spf_string"

Here, spf1 is SPF version, and spf_string takes the combination of the so-called mechanisms: "a, ptr, mx, ip4, include, all". all is a finalizing mechanism and must be placed at the end.

Please read more explanations on mechanisms in TXT DNS records.

Each mechanism may have a prefix pointing to a certain type of processing messages:

- fail (message is rejected)
~ softfail (message is passed with warning)
+ pass (message is passed - the default prefix value)
? neutral


Thus, the simplest SPF record will be:

domain.com IN TXT "v=spf1 -all"

It means that you deny sending any mail from this domain, i.e., you may use this domain for any hosting except mail hosting. (-all is thus somewhat similar to deny all in Apache).

Example:

Consider the following record:

domain.com IN TXT "v=spf1 mx a:test.com/24 ptr:test2.com -all"

If a message is sent with MAIL FROM: test@test3.com and from the client IP 4.5.6.7, SMTP server will check:

a) whether test3.com MX records (at least one of them) are resolved to IP 4.5.6.7;
b) whether the IP 4.5.6.7 is in a test.com's IP subnet (mask 255.255.255.0);
c) whether the PTR record for IP 4.5.6.7 is resolved to test2.com;


If none of the above conditions are met, then the last directive -all meaning "deny all other" takes effect, and the message will be rejected.

The include directive is used if you wish to delegate SPF check for another domain, for example:

"v=spf1 include:example.net -all"

 

SMTP Server

At the level of qmail server, the following SMTP parameters should be configured in respective files in /var/qmail/control directory:

spfbehavior
spfrules
spfguess
spfexp


For more details, refer to Qmail Configuration and SPF Implementation for Qmail.

 

SRS (Sender Re-write Scheme)

SRS mechanism is used in two cases:

• To form SRS-compliant mail address for forwarding messages via forward mail resources, in accordance with SRS convention;
• To form reverse SRS-compliant reverse mail address in case of reply.

H-Sphere provides the following Qmail controls for SRS (they are located in the /var/qmail/control/srs/ directory):

• SRS secrets files: reverse_srs_secrets (for reverse mail) and srs_secrets (for forwards). These files contain a set of lines with keys, each key in a separate line. These keys, called secrets, are used to validate hash from SRS formatted e-mail address. The most recent key is on top of the list. Qmail takes it first when checking SRS address, and if it doesn't fit, Qmail takes these keys one after another. If none fit, the message will be rejected.

  The revers_srs_secrets file has 400 permissions and vpopmail:vchkpw ownership.
  The srs_secrets file has 400 permissions and qmaill:qmail ownership.

• srs_maxage - an integer value for 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.

The script /var/qmail/bin/setsrssecret runs as cron on mail servers to set these controls.