SPF RRType

Thu Aug 11 21:44:34 UTC 2005

Dan,

At 11:50 AM 8/11/2005, Gushi wrote:
>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.

>         I have my own personal rant on this subject at
><http://bradknowles.typepad.com/considered_harmful/2004/05/spf.html>.
>And no, DomainKeys is not much better.
>
>--
>Brad Knowles, <brad at stop.mail-abuse.org>
>
>"Those who would give up essential Liberty, to purchase a little
>temporary Safety, deserve neither Liberty nor Safety."
>
>      -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
>      Assembly to the Governor, November 11, 1755
>
>    SAGE member since 1995.  See <http://www.sage.org/> for more info.

No, I'm not a SAGE member (I'm more likely closer to a sage brush 
member), but I do drive past Holiday Inn Express locations from time 
to time and have also been engaged in on-line Internet business since 1995.

Best,

Alan Maitland
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/