SPF is a fairly new technology fighting spam. Domains implementing SPF records allow other MTAs to verify whether an email originating from an address inside the domain is being spoofed or not. The SPF record tells how to determine this.

Although SPF records implement a quite mighty syntax, the setup for the domains ifyouseekate.net and nwl.cc is fairly simple.

The domain nwl.cc uses mail.ifyouseekate.net as it's single MX, therefore all SPF verification should be done inside the ifyouseekate.net domain, too:

$ORIGIN nwl.cc.
	IN	TXT	"v=spf1 redirect=ifyouseekate.net"
	IN	SPF	"v=spf1 redirect=ifyouseekate.net"

as the redirect never returns, there is no need for a final -all to deny everything not accepted earlier.

Actual verification is done inside the ifyouseekate.net domain:

$ORIGIN ifyouseekate.net.
@	IN	TXT	"v=spf1 ip4:81.169.176.177 ip4:85.214.71.2 ip6:2001:6f8:900:708::2 -all"
@	IN	SPF	"v=spf1 ip4:81.169.176.177 ip4:85.214.71.2 ip6:2001:6f8:900:708::2 -all"
mail	IN	TXT	"v=spf1 ip4:81.169.176.177 ip4:85.214.71.2 ip6:2001:6f8:900:708::2 -all"
mail	IN	SPF	"v=spf1 ip4:81.169.176.177 ip4:85.214.71.2 ip6:2001:6f8:900:708::2 -all"

the ip4 and ip6 checks are considered the most efficient ones, and therefore recommended. As mail from ifyouseekate.net and all it's managed domains is being allowed only for three sending IPs, these checks are absolutely sufficient. Note that the SPF records must exist for the whole domain as well as for the MX host.

Regular behaviour is that mail relays must use SRS, else the relayed mails would get classified as spoof, as they seem to origin from the relay but having the same, unaltered envelope from address.

If the administrator of the relay is not able to setup SRS himself, one can work around these broken hosts by using an additional statement in one's own SPF records, referring to the relay in question.

To enable SPF verification in SpamAssassin insert the following line into the file init.pre:

loadplugin Mail::SpamAssassin::Plugin::SPF

documentation about configuring SPF in SpamAssassin can be viewed using:

% perldoc Mail::SpamAssassin::Plugin::SPF

Like many others, I use a single MX for delivering all my emails. Unlike what one might guess, this is not a problem with SPF. The only thing one has to make sure is that the local mail client specifies a valid envelope from address (-f flag to sendmail). The “official” From: address being displayed by most mail clients is obtained from within the mail header.

The fact, that hardly any mailserver implements SRS, introduces problems one might not be aware of at first hand. I guess the most common problem comes with mail being forwarded as requested by a .forward file on a remote system. Imagine the following setup:

 [sender]----------->[relay]------------->[destination]

so the host named sender delivers a mail from a local user to a user on host relay. The destination user has a .forward in his $HOME, stating an email address on host destination. This causes host relay to continue mail delivery to host destination, without changing the envelope sender used for the SMTP protocol.

Now imagine the same setup with all host having SPF RRs in their zone files and doing SPF checks on incoming connections. In the first step of delivery, the connection from sender to relay, everything is fine. The SPF-RR allows sender to transfer mail for users of its own domain, and relay accepts the mail. The problem comes with part two: relay tries to deliver the mail to destination, without changing the envelope sender. That means that destination will take the SPF record of sender's domain, which of course denies relay to transfer mail for sender's users.

There is only a single real solution to this problem, namely setting up SRS on relay. Or more generally: setting up SRS on any mailserver, just in case one of the local users wants to have his mail forwarded to another machine.

After being confronted with exactly the above mentioned problem, I started searching workarounds, hoping to still be able to do SPF checks on my own mailserver.

A regular .forward on host relay would look like this:

user@destination

To force the mailserver on relay to initiate a new connection to destination (and therefore change the envelope sender to the local user's address), one can use the following syntax:

"|sendmail user@destination"

This workaround is problematic, too:

• All local users on destination must be aware of this workaround, and strictly use it on all hosts they want to forward their mails to destination.
• Many email providers don't allow editing a .forward, but offer web interface based solutions instead, which makes it impossible to ensure the altering of the envelope sender.
• Bounces will loop! Since relay forwards the mail giving the local user as envelope sender, any bounces from destination will be delivered to that user just to be forwarded to destination again. Finally they will be dropped or remain in the loop forever, but they will for sure never reach their real target, the original sending user on host sender.

• Howto - Define an SPF Record
• RFC4408 - Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
• Sender Rewriting Scheme Explanation