 SPF
RRType
Hey all,
I was wondering if/when the SPF record rrtype was
going to be standardized...I've heard it's out for debate but can't
find much info on it.
Thanks,
Dan Mahoney
Getting to your question. SPF is currently
implemented for publishers through DNS TXT RR records. Rumor has
it that SPF may be supported with its very own RR in BIND 9.4.x.
From an implementation perspective, that means migration could be
as easy as changing the SPF RR from current TXT to SPF in your zone
file.
In reality, it probably won't be that easy for quite
a while though, because it would mean that most all DNS and MTA
software implementations would need to support the new SPF RR and
SPF publishers would need to have published SPF records under the
new SPF RR in their zone files.
Of course, if everyone in the known universe jointly
decided to use BIND 9.4.x and published an SPF RR, that would go
a way to getting adoption of the new SPF RR accelerated. For now,
it would probably be most prudent to continue to publish the TXT
RR and any future SPF RR together until such time that the vast
number of requests fall to SPF's RR.
In any case adopting the latest version of ISC BIND
is never a bad idea - more than a few of the concerns and questions
expressed on this list over the years are successfully addressed
and answered by simply upgrading to a newer version of BIND - which
is really not all that much to ask for considering the software
is made available for free [as in free] and is available for many
OS platforms.
SPF does, however as others have pointed out, have
some well known issues where forwarders are involved, unless their
MTAs are specifically included in a domain's published SPF record
as valid mail from sources. (e.g. Domain.TLD uses ISP.TLD to forward
its messages, so make sure to include ISP.TLD in the SPF record
for Domain.TLD).
The big question you must ask yourself before deciding
to implement SPF is does your domain send mail in such a way that
the forwarding problem is going to become an issue? For many, forwarding
is simply not an issue or they have found acceptable work arounds
to address issues that have been encountered.
I have been rather disappointed by the responses
thus far on this list as regards your message and would like to
suggest that you consider participation in the SPF list to get more
detailed answers to your questions. The BIND
/ DNS list is probably not the right place to discuss SPF questions.
In fact your question was addressed to some degree on the SPF discussion
list.
For now, the site you should visit for more information
is located at http://spf.pobox.com/ but may soon be changing over
to http://www.openspf.org/
At 12:58 PM 8/11/2005, Brad Knowles wrote:
>At 2:21 PM -0400 2005-08-11, Joseph S D Yao wrote:
>
> > <URL: http://spf.pobox.com/>. I noticed no special
resource record
> > type. SPF uses TXT records.
>
> Correct. It uses TXT records.
As of today. See above.
> > Be warned: this does break some things, and it seems that
about a
> > third of the Internet is convinced that its wide implementation
> > would completely destroy e-mail, while about a quarter
of the
> > Internet considers SPF its saviour and redeemer.
Joseph, having published SPF records for around
1 year and having recently implemented SPF aware MTAs, no negative
issues with regard to SPF and email delivery have occurred as the
result of either action here.
I note that you send from a .GOV address. Even a
spammer is unlikely to attempt to spoof a .gov MAIL FROM address
in their messages, so you probably have not had the "pleasure"
of dealing with the consequences from a major spamming campaign
misusing one of your domain names as the MAIL FROM. Once you've
experienced that, it goes a long way to making you an SPF proponent.
> There are problems with the SPF specification,
and there are
>problems with the SPF implementations. For one thing, many people
do
>not implement SPF correctly, so they break mail for any domain
that
>publishes SPF records. Another problem is that spammers have
started
>publishing SPF records, and very few legitimate domains have
done the
>same.
Brad, the above argument could also be made with
implementing any protocol. If one does not follow the protocol specification,
things can break. Actually, not all that dissimilar to what happens
if one misconfigures their named.conf file in BIND. If one expects
to have software or protocols work properly, they really need to
implement properly.
> This means that the probability is very high
that anyone using
>SPF records is a spammer, which I guess explains why no one
seems to
>care that they have screwed up their SPF implementation and
instead
>throw away anything coming from domains that have SPF records.
Actually, your statements above are quite misleading
and a fairly large number of respectable companies who do publish
SPF records might take exception to them. Setting that aside, if
a spammer actually does publish an SPF record, it simply means that
the email sent did initiate from an MTA under the control of the
declared MAIL FROM domain in the message from the spammer. If a
spammer is violating any laws regarding spam, prosecuting the spammer
is going to be that much easier if they do publish and SPF record,
because in publishing their SPF record, the spammer just admitted
machines under their direct control were the actual source of the
spam. Further, if a spammer publishes and SPF record, it makes the
process of black holing the spammer that much easier.
As everyone who pays much attention to SPF at all
knows, SPF was never really conceived to directly address spam.
It does, however, address one of the things spammers do, namely
sending out mail with the identification of a domain the spammer
does not control. The consequence of a spammer doing this is that
they cause harm to the victimized domain name's reputation and cause
unneeded burden to machines in the victimized domain name holder's
control to become swept with backscatter from bounces which target
and further burden the victimized domain name holder's network.
SPF works to cause those consequences to go away.
Some companies and individuals actually do care
about their reputations and those of the domain names under their
control and thus they publish SPF records in an affirmative effort
to protect those reputations. Really.
Until something better comes along to protect a
domain name from being hijacked in an email MAIL FROM, SPF seems
the default solution du jour for such things. If you have a workable
alternate solution that has a level of support by responsible domain
holders that is even close to that enjoyed by SPF, please advise.
|
Latest
articles