SPF on 9.4.1 now?

Sten Carlsen ccc2716 at vip.cybercity.dk
Tue May 22 08:55:04 UTC 2007

The answer that you "just" upgrade your client-SW is probably not going
to make much difference. Most people will not be like those on this
list, they will be more ordinaire guys.

I wonder how many will be able to upgrade an off the shelf windows
program? At least as I use spf, I use Thunderbird with the
spf-extension. While I have access to the source, I will not use that
effort, spf is not THE spam tool as pointed out, but in my experience it
does help in sorting things out. If only spf-RRs are published, I will
publish my own in due time when my DNS-provider has upgraded enough to
support them(I will also continue publishing txt-RRs until no longer
useful) and I will use them when "somebody else" has upgraded my
applications. This will mean a break in the usefulness of spf.

Even if you dislike it, I don't expect you to have THE other solution?

Sorry if this discussion seems off topic. The aspect I would like to get
clarified is the question: How do you most effeciently change a service
that is in place, with least disruption and greatest speed? SRV-RRs
might be an example not worth of copying?

Michael Milligan wrote:
> Mark Andrews wrote:
>>> Mark Andrews wrote:
>>>> 	No.  You use it *instead* of TXT record.  There is no need
>>>> 	to dual publish the data.  Anyone that really cares about
>>>> 	SPF will upgrade their clients.
>>> As a practical matter, I must respectfully disagree.  It will be some
>>> time before everyone gets a chance to upgrade, and the timeout issue
>>> with looking up SPF from some DNS server sets (not BIND or MS
>>> implementations far as I can tell) is a significant issue.  This timeout
>>> issue could, of course, be a firewall issue...  anyway, it has a
>>> significant impact on high-volume (for various definitions of "high")
>>> mail sites.  And thus is ultimately off-topic for this list.  FIN.
>> 	What timeout issue?  If you don't publish the old clients
>> 	will get a NODATA response.  There is no time out issue in
>> 	not publishing the TXT record.
> The timeout issue is with looking up SPF records on some name servers.
> Compare:
> $ dig +norecurse TXT massivebonus.com @ns1.massivebonus.com
> to:
> $ dig +norecurse SPF massivebonus.com @ns1.massivebonus.com
> to see what I mean (with a 9.4.x version of 'dig' of course).  And
> nevermind that this example domain is quite borked in its
> delegation/glue path.  This is an issue with a lot of domains that
> source spam and have SPF TXT records to make the envelope sender look
> "good".  This timeout issue will slow down adoption of native SPF
> records IMHO.
> SPF does not stop spam, the spammers were the early adopters of SPF...
> Again, this is all off-topic here.  Just pointing out that, like any
> other change like this, adoption of _the_ SPF Resource Record instead of
> using TXT records is not going to happen overnight because TXT records
> with SPF info are out there already, and also because the lookup of SPF
> instead of TXT is out of the hands of the organization that cares that
> other MTAs look them up...  chicken-and-egg or catch-22 apply, and thus
> to maximize the chance that _everybody else_ will find SPF information
> and act on it, smart administrators will put in both types of records in
> the short term.  That's what I see happening in my crystal ball, like it
> or not.  :-/  I'm all for a flag day!  It's just unlikely to happen, and
> more unlikely to happen because of this timeout issue, IMO.
> Regards,
> Mike

Best regards

Sten Carlsen

No improvements come from shouting:


More information about the bind-users mailing list