26 Handling Forged Email by Using the Sender Policy Framework

About Sender Policy Framework

Spam producers and email scammers often forge email by using false domain names and email addresses, or by using legitimate domain names and email addresses to fool users into thinking that a message is from someone or some company they know. For example, a spammer could send email from an address such as president@whitehouse.gov and the user could be fooled into thinking the mail was actually from this address. Forging email might fool users into opening the unsolicited message, or worse, provide information to a false authority. Also, spammers prefer to send their email from legitimate domains that are not on an RBL list.

Sender Policy Framework (SPF) is a technology that can detect and reject forged email during the SMTP dialogue. Specifically, SPF is a protocol that allows a domain to explicitly authorize the hosts that may use its domain name. In addition, a receiving host may be configured to check this authorization. SPF can thus significantly reduce the instances of forged email.

SPF Theory of Operations

When a message comes into Messaging Server, the MTA does an SPF query to determine if the address actually came from the domain on the address. An SPF query consults the DNS for TXT records belonging to the domain of the message (domain). Domain is either the domain name specified as the argument for HELO or EHLO (if the spfhelo channel option is used) or the domain name in the originator's address given in the MAIL FROM: command (typically the part after the @ character). If no domain name is specified or available, the one specified during HELO/EHLO is used as domain. Most ISPs distribute an authorized list of IP addresses that match their domains. If the IP address does not match the domain name, then the message is assumed to be forged.

If a record found from the mapping table contains a redirect= domain clause, then the redirection to domain will be done as a DNS query, skipping the recursive and redundant mapping file check.

An example of a resulting TXT record is:

v=spf1 +mx a:colo.example.com/28 -all 

The v=spf1 token is required for SPF records supported by this RFC.

+mx checks MX records for domain and confirms that the source IP address for this SMTP connection matches one of the IP addresses given as a result of an MX query for domain. If there is a match, the + means that the result of this is Pass.

a:colo.example.com/28 checks for A records for colo.example.com, then confirm that the source IP address for this SMTP connection is in the same specified CIDR subnet as the A records, comparing only 28 bits (masked against 255.255.255.240). No qualifier character was specified, so it defaults to + meaning that a match results in a Pass.

Finally, -all matches everything else and results in Fail. For a complete description of SPF records, refer to RFC 4408 at http://www.ietf.org/rfc/rfc4408.txt.

SPF processing can have one of several results. Table 26-1 shows the results and their descriptions.

After SPF processing has completed, a Received-SPF: header is written to the message documenting the result of the SPF processing. This header can then be queried during Sieve processing for subsequent consideration. Extensive debugging is available if the MTA option MM_DEBUG is enabled (>0). In Unified Configuration, run the msconfig command to set the option. In legacy configuration, set the option in the option.dat file.

SPF Limitations

SPF is only one tool to use to fight spam, and it does not address all issues. A spammer can easily create a domain and add an SPF TXT record that makes the domain seem legitimate. On the other hand, SPF is very effective for detecting forged email from established ISPs, although many TXT records allow the SPF to not fail.

SPF Pre-Deployment Considerations

It is important to have a very fast DNS server on your system because a DNS query for every message is required.

Setting up the Technology

The two steps to set up SPF technology are:

• Place channel options on the incoming TCP channel (typically the tcp_local channel, although there might be other channels if you allow channel switching from tcp_local to another channel). See Table 26-2, "SPF Options" for more information.

• Set up the options. In Unified Configuration, run the msconfig command. In legacy configuration, edit the option.dat file. See Table 26-3, "SPF Limiting Options" for more information.

Reference Information

This section provides reference information for the SPF channel options and the SPF MTA options. SPF support is implemented through four channel options applied to the incoming tcp_* channel (typically tcp_local). Table 26-2 shows the options and their descriptions. In Unified Configuration, use the msconfig edit channels command to edit SPF channel options. In legacy configuration, edit the imta.cnf file.

Additional support to establish limits on SPF processing and to control whether SMTP commands will be accepted, failed with a 4xx response (temporary failure), or failed with a 5xx response (permanent failure) for the various SPF results includes: Fail, SoftFail, PermError, and TempError.

Table 26-3 shows the MTA options that place limits on SPF processing. In Unified Configuration, set options with the msconfig command. In legacy configuration, edit the option.dat file.

Additionally, the following MTA options can be configured to control the behavior of the SMTP server in response to SPF results of Fail, SoftFail, PermError, and TempError. In Unified Configuration, run the msconfig command. In legacy configuration, edit the option.dat file. For each of these results, the SMTP server can send back a 2xx (success) response, 4xx (temporary failure), or 5xx (permanent failure). Also, for Fail and SoftFail, the MTA can distinguish between an SPF result as the result of an "all" mechanism versus an otherwise explicitly referenced match. You can then make a distinction between a particular result and the SPF record's default result. The valid values for any of these options is 2, 4, or 5. The values of 2, 4, or 5 correspond to 2xx, 4xx, or 5xx responses from the SMTP server as a result of getting that particular SPF status. So, for example, if SPF_SMTP_STATUS_FAIL=2 and the SPF record explicitly blocks us with a "-a:192.168.1.44" (our IP address), then instead of responding with a 5xx response, we'll accept the address with a "250 OK" instead.

Table 26-4 shows MTAP options that control SPF failures and error options.

Testing SPF by Using spfquery

You can use the spfquery testing utility to test SPF processing.

Requirements: Must be run as a user who has access to run the Messaging Server binaries and access its libraries such as root or mailsrv, for example.

Location: MessagingServer_home/bin/

spfquery [-i ip-address] [-s sender-email] [-h helo-domain] [-e none | neutral | pass | fail | temperror | permerror] [-v] [-V] [?] domain

# /opt/sun/comms/messaging64/bin/spfquery -v -i 192.168.1.3 11.spf1-test.example.com
    Running SPF query with:
      IP address: 192.168.1.3
          Domain: 11.spf1-test.example.com
          Sender: postmaster@11.spf1-test.example.com (local-part: postmaster)
     HELO Domain: 11.spf1-test.example.com

    15:30:04.33: ----------------------------------------------------------------
    15:30:04.33: SPFcheck_host called:
    15:30:04.33:       source ip = 192.168.1.3
    15:30:04.33:          domain = 11.spf1-test.example.com
    15:30:04.33:          sender = postmaster@11.spf1-test.example.com
    15:30:04.33:      local_part = postmaster
    15:30:04.33:     helo_domain = 11.spf1-test.example.com
    15:30:04.33:
    15:30:04.33:   Looking up "v=spf1" records for 11.spf1-test.example.com
    15:30:04.35:     DNS query status: Pass
    15:30:04.35:       "v=spf1 mx:spf1-test.example.com                  -all"
    15:30:04.35:
    15:30:04.35:   Parsing mechanism: " mx : spf1-test.example.com"
    15:30:04.35:     Assuming a Pass prefix
    15:30:04.35:     Processing macros in spf1-test.example.com
    15:30:04.35:     Comparing against 192.168.1.3
    15:30:04.35:     Looking for MX records for spf1-test.example.com
    15:30:04.41:       mx02.spf1-test.example.com:
    15:30:04.41:         192.0.2.22 - No match
    15:30:04.41:         192.0.2.21 - No match
    15:30:04.41:         192.0.2.20 - No match
    15:30:04.41:         192.0.2.23 - No match
    15:30:04.41:       mx01.spf1-test.example.com:
    15:30:04.42:         192.0.2.13 - No match
    15:30:04.42:         192.0.2.11 - No match
    15:30:04.42:         192.0.2.12 - No match
    15:30:04.42:         192.0.2.10 - No match
    15:30:04.42:       mx03.spf1-test.example.com:
    15:30:04.42:         192.0.2.32 - No match
    15:30:04.42:         192.0.2.30 - No match
    15:30:04.42:         192.0.2.31 - No match
    15:30:04.42:         192.168.1.3 - Matched
    15:30:04.42:   Mechanism matched; returning Pass
    15:30:04.42:
    15:30:04.42:   Parsing mechanism: "- all : " (not evaluated)
    15:30:04.42:
    15:30:04.42: SPFcheck_host is returning Pass
    15:30:04.42: ---------------------------------------------------------------- 

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

As described 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 can be considered to be fraudulent.

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, do not 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.

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 of 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 and should only be done to envelope From: addresses you know are associated with forwarding activity. SRS encoding is controlled by six new channel options: 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. The simplest setup consists of pure forwarding 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 options 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 produces the following output:

SRS decoding = foo@example.com

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