Sun Java System Messaging Server 6.3 Administration Guide

15.1 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 keyword 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. Note that 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.

Note –

Prior to querying the DNS, we check the SPF_LOCAL mapping table for a match for domain. If a match is found there, it will be used first.

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.siroe.com/28 -all

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

+mx directs us to check MX records for domain and confirm 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.siroe.com/28 directs us to check for A records for colo.siroe.com, and 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 more complete description of SPF records, please refer to RFC 4408 at http://www.ietf.org/rfc/rfc4408.txt

SPF processing can have one of several results. The table below shows the results and their descriptions.

Table 15–1 SPF Processing Results


Result	Description
`Pass`	The lookup has passed meaning that an SPF record was found and the record validated the originating system as being authorized to use `domain`.
`Fail`	The lookup found a matching SPF record, however, the record explicitly denied authorization for the SMTP client to use `domain` during the SMTP transaction. The default behavior of our SPF implementation is to reject the SMTP command with a 5xx reply.
`SoftFail`	The lookup found a matching SPF record, and the record also denies authorization for the SMTP client to use `domain`, however the denial is less strict and the record does not direct an outright failure. The default behavior of our implementation is to accept the message, but note the `SoftFail` in the Received-SPF: header for subsequent evaluation such as during Sieve processing.
`Neutral`	The SPF record makes no claim to the SMTP client's authorization to use `domain`. The message will be accepted. The specification requires that `Neutral` be treated the same as `None` below.
`None`	No matching SPF record was found, therefore no SPF processing was done.
`PermError`	A permanent error was encountered during SPF processing, such as syntax errors in the SPF record, DNS failures while processing nested SPF records (due to `include:` mechanism or a `redirect=` modifier), or exceeding configured limits for SPF processing while processing nested SPF records. The default behavior is to reject the SMTP command with a 5xx reply.
`TempError`	A temporary error was encountered during SPF processing, most likely due to DNS timeouts querying SPF records. The default behavior is to reject the SMTP command with a 4xx reply.

After SPF processing has completed, a Received-SPF: header will be 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 the option.dat file.