On Thu, 11 Nov 2004, Hallam-Baker, Phillip wrote:
william(at)elan.net
This was discussed and at the FTC meeting. The view there was that
should be no new RR and that any new RR will be ignored. The TXT
record is final and will not be revised.
Don't confuse people, it was not discussed at FTC. Existing
proposals were
presented at FTC but proposals as part of them contain text that say
that new RR type will be used but right now until its been
allocated we're using TXT for purposes of TESTING and
EXPERIMENTATION.
The issue of changing the RR was certainly raised, I raised it.
Don't remember. Possibly it was in the morning of 2nd day when I was not
present.
There was lots of talk at the summit but not all of it was equal. The key
statements were the ones made by the large ISPs and in the press release
that went out before the meeting.
I know you worked hard on those press-releases and letters by ISPs. At the
same time the situation is that security people at those ISPs (and I"m
security person and know others) are not happy and will caution about not
relaying on the checks and not deploying them beyond some experimentation
for spam filtering. Plus based on what I understand most will do checking
on SPF and not SID/PRA.
SPF/Sender-ID is now a done deal, it has gone past the point of no
return, nobody can make changes at this point if they want to.
Not so. Neither SPF nor Sender-ID are "done deal"
The CSV faction did have a legitimate complaint about the way they were
treated. They were asked to put off discussing or submitting their idea
until the issues with SPF were addressed, then it closed without any further
ado. But it was equally clear that they were too late getting started, the
boat has sailed on the syntax issue, its SPF version1.
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.
Note that FTC Summit seems to have ended not with opinion
that we should deploy SenderID immediatly but that we should
do some more testing and then discuss results again before
deciding if the system works. Very few were willing to base
their decisions based on SenderID right now.
The parties that represent the bulk of the ISP, email sending and MTA vendor
markets all said they were going ahead. People are waiting for experimental
results on the crypto issue but deployment is going ahead on SPF now.
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.
If you disagree with this decision then take it up with the UN.
We'll take it with IETF and FTC has smart technical people who agree more
with IETF then they do with somebody as monopoly-hungry as Microsoft.
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.
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.
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 make me
real mad that we allow companies like that so much power. In this case,
unlike for example iSCSI, IETF did not bow under pressing and used bad
standard format but instead disbanded the WG when they saw that technical
problems were such that they could not be reconciled.
The alleged technical 'elegance' of the solution is utterly irrelevant at
this point. If you wait for the IETF to give you an answer then you will be
waiting for another decade - witness IPSEC, DNSSEC etc ad nauseam.
That is not so. I believe we can achieve an answer to 822 security with
mail signature standard and 821 space with UnifiedSPF. This does not mean
that I think current solutions for either space are ready for widescale
deployment or that even their specs are fully ready
As I said on MASS list once there is good Russian saying "Pospeshish, lyudey
nasmeshish" which is similar to the following proverbs in english:
"Hasty climbers have sudden falls"
"The more haste, the less speed"
But in this case direct translation from Russian is even better, its
something like "if you hurry too much you'll make a fool of yourself"
Meng's hack is too widely deployed at this point to reverse out. Like MSDOS
it is never going to go away completely.
Don't remind me. It would have been much smarter if IBM actually chose
CPM/8080 from the start instead of choosing its badly designed clone QDOS
which was only good in that instead of older RT-11's style PIP they used
newly RT-11 names like COPY and RENAME, plus they did couple others things
that made it easier to newbies but this came on the expese of not so well
designed core. CP/M was really good os for its days and better designed
then DOS, its too bad Digital Research's people were not good at marketing
their work. BTW, talking about IBM choice in those days - it was also made
in part because they did not want to wait another 6 month for Digital
Research to finish and test CPM for 8080 processors (but anyway, I doubt
there are enough people here who know computer history good enough to
understand what I'm talking about above)
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.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net