cancel
Showing results for 
Search instead for 
Did you mean: 

SPF DNS Records

Community Veteran
Posts: 3,789
Registered: 08-06-2007

SPF DNS Records

A la my usual slashdot surfing, I came across this article:

Its the (start?) of spam prevention techniques using DNS records to prevent forging of FROM addresses.

Are PlusNET looking into supporting this? Without widespread usage it will never work, but if no-one attempts it then critical mass will NEVER be reached!

Barry
10 REPLIES
N/A

Seconded.

As far as I'm aware, we users have no way of editing our DNS TXT records to implement SPF.

I run my own DNS server to cover the two domains I run from my account, and have implemented SPF on those (try dig @tranchant.plus.com billericaybaptist.net TXT). However, I can't add SPF to my plus.com address.

How about adding a sensible default SPF to everyone's DNS entries, "certifying" mail from (anything).plus.net and (user).plus.com IP addresses? Not only would this cover all users, but it would help those like me by covering bounced messages sent under one of my other domains' aliases but which bounce to the reverse-resolved plus.com address.

(user).plus.com. IN TXT "v=spf1 a mx ptr:plus.net -all"

AOL have just done this - see the Slashdot article. Partial output of dig aol.com TXT:

aol.com. 300 IN TXT "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/24 ip4:205.188.157.0/24 ip4:205.188.159.0/24 ip4:64.12.136.0/24 ip4:64.12.137.0/24 ip4:64.12.138.0/24 ptr:mx.aol.com -all"
csogilvie
Grafter
Posts: 5,852
Registered: 04-04-2007

SPF DNS Records

Theres some discussion in this ADSL Guide thread about this, including a couple of thoughts from one of the support staff on how it could be done.

Edited URL as it was causing page to be very wide
N/A

SPF DNS Records

A followup to my own post above: I think I have a solution for my own domains, but the issue remains for my plus.com mail.

I'm using:

billericaybaptist.net IN TXT "v=spf1 +ip4Sadmy ip) +ptr:plus.net -all"

which allows mail from my own IP, as well as anything under plus.net. Anything else fails.

This has a slight disadvantage in that anyone using relay.plus.net is able to send SPF-approved mail from my domain, but that still cuts down the potential problem by a large amount.

There's a good SPF tester at http://www.dnsstuff.com/pages/spf.htm.
N/A

SPF DNS Records

I have just performed some tests on that page using your domain and a non-plusnet IP.

From what I can make out, all the IP's I used would have allowed me to use you domain without issue.

It does look like the test has a previous record cached, but because of the include fail, it shuld fail, or am I not understanding things correctly.
N/A

SPF DNS Records

I think you're right about the previous entry being cached. If it includes "include:relay.plus.net", that is wrong and will allow mail through until plus.net adopt SPF themselves. Using ptr:plus.net works - try back later...
N/A

SPF DNS Records

OK, SPF has 4 possible outcomes.

PASS, FAIL, ERROR and UNKOWN.

If a domain does not have a SPF record, UNKOWN is returned. Good, as this will allow e-mail through and preventing a forced adoption (though this is definate standard that stand a very damned good chance).

I supposed it is upto a server via a default or by setting, if it treats ERROR as FAIL or UNKNOWN (never PASS).

What does stike me as a major blunder though, is the include: element.

domain.co.uk could have a very valid SPF record, with a include: element in it (example include:relay.plus.net).

The problem arrises when the DNS server associated with relay.plus.net dies due to downtime or server failure (not that it would, this is just an example of the pitfalls), and there is no SPF record in the cache.

Any include: failures are returned as UNKNOWN. As such, the extream measure of DDOS could be used to bring a include: server down, and this allow e-mail to bypass the SPF system.

I would have thought a 5th item could have been implimented of RETRY. When this is encountered (under include: failure), as server could be configured to treat it as FAIL, UNKNOWN, or ever queue the mail and retry SPF later.

At a later date, PASS or FAIL could be returned depending on the number of retries.

This si the only real pitfall of the system.
Community Veteran
Posts: 3,789
Registered: 08-06-2007

SPF DNS Records

I'd like to see comments from Josh or Ian on this thread, perhaps?

B.
csogilvie
Grafter
Posts: 5,852
Registered: 04-04-2007

SPF DNS Records

Matt Francis, another of the PlusNet staff commented in this comment at ADSLGuide:

Quote
I've looked informally at how we could implement this before. We could certainly do it - the question is what records would we actually apply? SPF is rather a kitchen-sink standard, and it has a multitude of different configuration modes

We could for instance:
- Give individual records restricting every username.plus.com to their static (if applicable) and the relays
- Allow anyone in our ranges to be @*.plus.com
- Restrict all plus.com mail to being sent from our relays

Or any combination or variation of the above, with varying amounts of pain and strictness. The one big trip up is the problem of blind forwarding - mailbox forwarding uses this, and we'd have to migrate to sender-rewriting forwarding to be sure nobody shot themselves in the foot (read the draft for details if you don't get what I'm talking about). This may become an issue anyway if many other domains start publishing and checking SPF records.


So it appears someone has actually started looking into it.
oliverb
Grafter
Posts: 606
Registered: 02-08-2007

SPF DNS Records

Seems to me that blind-forwarding is a problem but one fairly easily cured by a whitelist.

Anyone holding a forwarding account needs a way of saying they expect email from certain domains. Then those domains could be exempted.

As a fallback the message could be blind forwarded initially, then if that failed the message would be resent with a "Wrapper" from the forwarding system so that it passed.

I guess it could be made transparent but only by serious modification to SMTP.
csogilvie
Grafter
Posts: 5,852
Registered: 04-04-2007

SPF DNS Records

Update to this from Ben earlier today in this thread.

Quote
This should already of been accepted...I'll chase it up tommorow.

We're trialling SPF on inbound mail but havent come to any decisions on implementing it for outgoung (ie publishing SPF records for customer domains)

We will be allowing TXT records to be added so you can add your own to any hosted domains though