william(at)elan.net
release that went out before the meeting.
Plus based on what I
understand most will do checking
on SPF and not SID/PRA.
As you will remember I have consistently argued that the checking algorithm
should never have been a part of the standard. The SPF record describes the
configuration of your outgoing edge MTAs, nothing more. The interpretation
of the records is for the receiver to decide, always has been.
My private info is such that you're wrong and ISPs are
seriously considering CSV. But what will also make SPF people
happy and let you know that these
ISPs are considering trying both CSV SRV records and SPF
records for HELO checks.
AOL made it clear that they were making CSV checks against SPF syntax. It
may be possible for CSV to also emerge as a syntax format, but it is not
very likely.
I beleive FTC will make copy of the summit's minutes
available so you'll be able to see for yourself. My
impression is that people were asking for testing but not for
immediate deployment.
Deployment has happened. All the bulk email providers in ESTG have published
SPF records, all the big ISPs are in the process of publishing. In a short
while the MSS providers will be prodding their customers to publish.
What people are asking for is irrelevant, what people are doing and have
done is what matters.
Are you arguing to postpone deployment of SPF until the DNS
infrastructure is upgraded as the DNSEXT group has been
insisting on?
DNS Infrastructure is fine. New records type can be entered
in by > 95% of used dns servers and can be verified by > 95%
of the installed MTA servers.
This is untrue. The true figures are 50%.
To make use of new records possible the support has to be production
quality. I don't think that even you would argue that a DNS server that
cannot read a new RR or maintain its state past a reboot is production
quality.
I thought that you were a member of the 'deploy now its time' world.
I am. But I'm also asking to have SPF dns record type issued
ASAP and continue using SPF with TXT for now with dual use
with new RR for next 2-3
years and full move to new RR by 2010.
Phasing in the new RR is possible. Phasing out the old is not going to
happen.
This has nothing to do with Microsoft's position.
The stories I've heard about hiw Microsoft (and Verisign for
that matter)
screwing up standards and saying people its my way or highway
Only time I ever said that it was my way or the highway was in the DNSSEC
discussions on an issue where the alternatives were to continue with a spec
that would have a huge and very costly impact on running the core DNS or
make a minor change that would allow immediate deployment during the ATLAS
rollout.
If you want to deploy a spec that requires major changes to core DNS and you
refuse to listen to the parties that support core DNS then you are going to
fail. The group did fail in that instance. Had my advice been taken DNSSEC
would now be deployed in dotcom and dotnet. As it is none of the large
domains looks likely to deploy soon.
And from technical perspective of IETF, Peter Koch is absolutly
right.
As has been demonstrated repeatedly, the prefixed TXT
record and the
new RR record approach are equally sound from a technical point of
view and the prefix does not require an upgrade of the architecture.
I don't see us using prefix for SPF do I? And no, the
explanation given by
Ed Lewis at the interim MARID meeting were quite clear that
new RR is a lot better to avoid any potential conflicts
especially if wildcards are used.
If my explanation was disjointed that was probably because Ed would not let
me say more than three words without trying to heckle and talk over me.
The wildcard issue has been shown to be irrelevant, they simply do not work
for the use case that people wanted them for and DNS server implementors are
always free to devise macro schemes to simplify administration.