Category: 
August 3, 2007DynDNS are a major player in both e-mail and DNS outsource solutions, both for home and corporate customers. The DNS for cjbuckley.net, for instance, is outsourced to DynDNS. Previously, DynDNS refused to publish their IP list for their backup MX services. Existing mail-servers that check (be it at MTA or Content-Filter level) SPF TXT record validity, and employ DynDNS’s backup MX service were currently unable to SPF whitelist their backup MX 100% accurately. But why would you wish to white-list? I think a quick history over-view would be prudent…
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:
- SPF breaks pre-delivery forwarding
- SPF relies upon DNS for security, but DNS isn’t a security service
- 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.
- Edit /usr/lib/postfix/postfix-policyd-spf-perl
- 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.
Horaayy..there are 2 comment(s) for me so far ;)
There were a few reasons why we did not. Biggest one is that we have wanted the flexibility to move them around for scaling issues and did not want to give out a list that would frequently change because of our own renumbering. I think that we are at a good place with Backup MX as we have finally renumbered everything into our own IP space. We still have a couple of Relay machines to shift around but that\’s not as bad because we’re the mail relay.
We know it has been a point of pain and we’re glad we can get rid of it.
Jeremy
–
Jeremy Hitchcock
CEO
Dynamic Network Services
Hi Jeremy,
Thanks for your informative reply – it’s a _really positive attribute_ when you see the senior leadership of a company prepared to publicly comment on issues such as the one raised above.
Upon my recommendation, we use DynDNS as our backup MX at work, so whitelisting the secondary MX IP’s was crucial. We can now do this :)
Whilst i think about it, would a dyndns suggestion be allowed..? The ability to dump your zone file within the administration page would be excellent. It would allow a company/end-user to easily backup their zone(s) if and as when required. UltraDNS and co. offer this, it’d be really nice to see dyndns offer it.
Again, thanks for your open and positive contribution.
All the best,
Chris