This is a multi-part message in MIME format.
If no verification is to be done on PTR records, then the PTR mechanism
should be removed from SPF. Otherwise SPF records containing ptr will be
targeted because they are easy to forge - all a spammer would have to do is
create a PTR record pointing to the target domain.
If a spammer fakes PTR records for an IP address, he must be in control of that
IP address. And if you remember, SPF itself does not prevent spam e-mails, but
together with blacklists and whitelists, it's extremely powerful. In this case,
a forged PTR record means that the IP range should be blacklisted.
Also, the basic idea behind SPF is to let the owner of a domain decide, how to
protect his/her e-mail addresses, and PTR records can be the only solution as
long as SPF isn't a world standard and you can't include the SPF records of
your ISP.
In the case of my personal domain (dybdahl.dk), it even makes more sense. Some
e-mails sent from that domain are sent through ISP mailservers I don't have a
list of, and the ISPs don't have SPF records, yet, I can include. Therefore, my
SPF record looks like this:
"v=spf1 a:mail.dybdahl.net ?ptr:tele.dk ?ptr:mail.dk ?ptr:get2net.dk -all"
I simply say that:
- E-mails from my mailserver are definitely good
- E-mails from some ISPs should be treated as if no SPF record is available
- E-mails from everywhere else is definitely spam
A spammer will not have any benefit from faking a PTR record in this case.
If your organization isn't ready for normal SPF, yet, but your e-mail address
gets exploited by people from a certain ISP, you can also make an SPF record
like:
"v=spf1 -ptr:spammernetwork.net ?all"
PTR records may not be bulletproof, but they're surely a good transition help.
Lars Dybdahl.