SPF on 9.4.1 now?
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.
> $ dig +norecurse TXT massivebonus.com @ns1.massivebonus.com
> $ 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.
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
More information about the bind-users