Overview

Since SPF become a permanent extension to the SMTP RFC, domain’s wishing to have their e-mail accepted by both the ‘big three’ (Yahoo, Hotmail, GMail) and other well-run mail-servers must be sure to publish their SPF record(s).

SPF is not without it’s critics, however. SPF, currently, breaks more than it fixes. From a personal view-point, I agree entirely with these points:

1. SPF breaks pre-delivery forwarding
2. SPF relies upon DNS for security, but DNS isn’t a security service
3. SPF doesn’t actually address unsolicited bulk mail at all

Point 1 is significant.

The SPF FAQ states that:

Checking SPF On Forwarded Mail

Mail forwarding is set up by the receiver and so for forwarded mail, the border mail server (at which SPF should be checked) the the forwarder’s mail server. If you check SPF on your mail server it is coming from your forwarder and not from a mail server authorized by the sending domain. Technically this is similar to checking SPF against mail relayed from your secondary MX like discussed in the previous item. Authorized forwarders should be whitelisted against SPF checks to avoid this problem.

DynDNS addresses this problem

If you are using a backup MX service, you will need, as per instructions above, to SPF white-list the backup MX (ie, all IP addresses from which it may send e-mail to your primary MX record). To not do so creates the situation that -all- mail going to your backup MX will be subject to a negative score upon receipt to your primary MX.

As talked about at the start of this article, DynDNS previously refused to publish their IP list for backup MX, stating categorically that they would ‘not publish’ this list. I am glad to see they have finally seen sense and allowed postmasters responsible for corporate (and personal) mail-servers the ability to white-list this important MX record.

Enough talk – how do I whitelist within Postfix?

If you’re running Postfix, you will almost certainly have implemented postfix-policyd-spf-perl.

1. Edit /usr/lib/postfix/postfix-policyd-spf-perl
2. Ensure the relevant line(s) read the same as:

use constant relay_addresses => map(
NetAddr::IP->new($_),
qw( 204.13.249.0/24 208.78.69.71/32 208.78.69.72/32 208.78.69.73/32 208.78.69.74/32 ) );
# add addresses to qw ( ) above separated by spaces using CIDR notation.

You’ve now successfully white-listed DynDNS’s backup servers, and will not suffer from SPF’s ability to break pre-delivery forwarding.

Final Points

Before anyone mentions SRS: it’s broken. It doesn’t work, as i write, within Postfix. Plus, it’s a -huge- hack.

I’ve resisted the temptation to mention DKIM, until now. DomainKeys does not suffer from the same problem i’ve written above that SPF does. There are explanations of how DomainKeys work both at Wikipedia and Yahoo! This domain, and all others I am responsible for, both sign and check e-mails for DKIM/DomainKey signatures.

If, after setting up your new extensions to the SMTP protocol, you wish to verify everything is working correctly then I thoroughly recommend a blank e-mail to this address: check-auth@verifier.port25.com

Let’s run through the results of this e-mail for my domain, cjbuckley.net:

 Summary of Results
SPF check:          pass
DomainKeys check:   neutral
DKIM check:         pass
Sender-ID check:    pass

Immediately, we can see that the implementations have been successful – this is a good sign!

SPF check details
Result:         pass
ID(s) verified: smtp.mail=example@cjbuckley.net
DNS record(s):
cjbuckley.net. 300 IN TXT "v=spf1 redirect=_spf.cjbuckley.net"
_spf.cjbuckley.net. 300 IN TXT "v=spf1 ip4:87.127.106.176/29 ip4:84.45.189.64/29 include:ukfsn.org -all"

The detail outputted from this SPF check is impressive; as we can see, my domain initially does a redirect to _spf.cjbuckley.net (note the underscore – these _are_ valid in TXT records). This allows many domains I am the hostmaster for (corporate ones, usually) to be easily managed.

For example, I use redirect: _spf.mycorporatedomain.com for all my corporate domains, this cleans up the SPF records and allows easy management of the record database – all other domains can be redirected to _spf.mycorporatedomain.com. It works very well, and is something I noticed Google taking advantage of, initially.. :-)

Next up – DomainKeys:

DomainKeys check details:
Result:         neutral (message not signed)
ID(s) verified: header.From=example@cjbuckley.net
DNS record(s):

The checker confirms that I do not have DK implemented – indeed, this is correct. DKIM replaces DK, and is now being driven forward to replace Yahoo! DomainKey’s. Note: gmail.com only verifies DK signatures, not DKIM yet – a bit disappointing, though they _do_ sign both with DKIM and DK.

 DKIM check details:
Result:         pass
ID(s) verified: header.From=example@cjbuckley.net
DNS record(s):
beta._domainkey.cjbuckley.net. 300 IN TXT "k=rsa; t=y;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDiIfv9vqSRUo9L8
ztX/C4gfCD/Ivt8eAGyQbjJ2g4Rq764NPwauj5/sY2AfMrFPqhA0ieXWtmJy2gFS
c4ZlxT8KYaFsJATOpJfYAXUtzmmQ8+RcioyeN3LjzNhm1gUYyJI1Lw0yD2y+k
dN3YxY4NZ0esMXrKbsngTl3pNcNCNxXwIDAQAB"

We can see that our DKIM policy has been verified successfully. As dkim.org states:

DKIM lets an organization take responsibility for a message. The organization taking responsibility is a handler of the message, either as its originator or as an intermediary. Their reputation is the basis for evaluating whether to trust the message for delivery.

Given this statement, e-commerce, financial and banking organisations should have either implemented or be on their way to planning an implementation of DKIM. Personally, I find SPF flawed – DKIM is the wiser choice.

I’m hoping to blog a dkimproxy implementation guide shortly, as the published guide has a few advisories I have issue with and would like clarified.

Comments, welcome!