On Thu, 19 May 2005, David MacQuigg wrote:
Looks to me like there are three possible outcomes:
1) A de-facto standard established by some large industry consortium.
2) A government-mandated standard.
3) An IETF standard.
Several standards can be passed by IETF if none of them violates the other
and does not violate other IETF standards. You're also missing option of
one standard going through IETF process and something else not being allowed
to become standard if its technically bad. I also find it unlikely that
government would mandate a standard, something like recommendation for US
and EU (like what just happened in Canada) is a lot more likely.
The IETF doesn't want to get involved in the SPF/SenderID battle. The best
you can expect from them is no interference in how each group defines its own
method, and perhaps a standard within which all the methods can operate. If
I understand the IETF "consensus" process, any uncompromising minority can
block a standard.
I think you're jumping to conclusion based on what you hear but do not
have correct understanding of how IETF works (have you ever been involved
in its WG, been to the meetings couple times?). IETF can not easily block
standards proposal if it has enough support (from multiple independent
parties) or drop it just because certain group there does not like it on
political grounds (Note: licensing and patent grounds are different and
are allowed as reason to block one proposal and support something else).
IETF does technical reviews and the main reason to block if its
technically flowed or would interfere with another IETF work.
I expect that will block both SenderID and SPF for many more years.
Scott Bradner said that MARID was closed for technical reasons, there
were two main technical problems that were brought up - (re)use of DNS
TXT records and (re)use of Resent- header fields that is against RFC2822.
Both of these could cause documents to not be eligible for IETF standard
and as WG was chartered to produce standard and obviously MS would not
have been happy if its SID documents were blocked from going all the way
but something else was, so MARID was closed.
The issue with DNS still exists but I don't think it is enough to block SPF
itself, considering that Wayne tried to work hard to bring load issues
under control and that we agree to change to SPF record type. The issue
with Resent- headers has not been resolved and SID documents are still not
eligible for standard as far as I see and may not be eligible for
experimental status either unless IETF is willing to change or absolute
its existing standard (which is long and hard process).
And don't forget about CSV. They have a lot of influence with
the IETF, and a strong dislike of both SenderID and SPF.
So? CSV deserves review by IETF on its own and it is not technically
flowed as far as I could see, so these people will work on that rather
then blocking different standard.
How about a government standard? The FTC is considering such a mandate.
They can't force it on the world, but they do have enough clout to break the
current deadlock. They don't want to get involved either, but Congress may
demand it. If all US-based domains were required to authenticate their
email, the rest of the world would probably follow.
Government is not going to mandate it for US domains. They can mandate
use of certain technology for government agencies which would be big boost
to that protocol (see old discussion with PHB about it on this list).
Looks like the most likely outcome will be #1, and we all know who has the
biggest consortium going.
Open source products and ISPs have more control then any one company
in mail arena, but industry is a lot more capable of marketing itself
to the public - these conferences do just that.
Let's keep this in mind as we discuss the details of any proposed
inter-operability standard. Which would we prefer, a standard that
accommodates all methods and will allow a superior method to show its
advantages, or one that allows only one method, the one with the
biggest market share?
You still don't get it that inter-comparability and trust can not involve
different independent identities. Protocol can be inter-operable and so
can the record format and that is what MARID tried to do with SPF already.
Seems like a futile battle to me. The best you can do is hold them back
for another year. If they really are abusing SPF1 records, the best way
to make that clear to the world is rapid deployment.
How does that solve anything when they are abusing the same records we are
asking people to deploy?
Is there some consequence to this abuse that will be noticed by people using
SenderID
It'd be noticed by few people sending email who maybe forced to change
their records.
, maybe some mail that gets incorrectly classified? If so, the
backlash from users will be far more effective than any protests at some
Microsoft-sponsored conference.
No it will not be. The backlash would be ignored as coming from users who
are not the ones using SID.
And its not "protest" on MS conference that we're talking about, just
making sure that people attending it do not get only one one-side of the
story and aware of the issues that are not being mentioned on the
conference session itself. So if backlash happens, they'd immediately
remember the warnings and it would have a lot more impact.
No - the best way for resolution is education about what they are doing
wrong which would effectively stop their deployment and abuse either
directly at the end (people will not deploy solution that is abusing
another system) or stop it from at the standardization stage.
People care about results, not whether SenderID abuses SPF. When I listen to
advocates of the different methods, even if I agree with what they are
saying, it makes me want to walk away. This battle is turning everyone off
and will only cause further delay.
Results and causes for SPF and SID are different - one is to protect
against unauthorized bouncing, the other primarily to protect against
phising and visible mail forgery. People are hearing a lot of FUD
and are confusing SPF and SID with being ultimate solution to spam.
Don't give them any more time to patch their product until nobody can tell
what it is, but it is actually SPF1 in disguise. :>)
If they were doing 100% SPF1 and just called it something else for
convenience of marketing, I'd be fine with it actually and probably
everyone else here as well.
If they see only an SPF1 record, my guess is they will do exactly what is
required to get a correct result.
Microsoft? Yeah, right, hahaha!
Just look at what they have been doing over the years with HTTP, Java,
Javascript, etc. etc.
Anything else would hurt their sales,
I really don't see how it can hurt their sales. They are selling Windows OS
and bundling Explorer & Outlook with it for free. They do sell Exchange
but Exchange is strong as groupware not as email filter (which is bundled
there as free addition like explorer is to windows).
Who said anything about random identities? Did you read the draft, or just
the noise in the discussions?
Read it, its bad. Both the idea and the implementation text is not compatible.
The fundamental flow is assuming that authorization means authentication
and that it does not matter what you authorize.
The declared Identity is the one accepting
responsibility for the transfer. Other identities may be checked, as
required by the various methods, but if the result is PASS, the declared
Identity accepts responsibility. Example: If the declared Identity offers
only a DomainKey, don't waste time checking the EHLO or MAIL FROM identities.
That is exactly the problem that I'm talking, you do not understand about
identities and you also do not understand that there is no one "declared"
identity it all depends on what you're going to do and what you're trying
to protect.
I'm actually working on the paper on this very topic. I'll make it
available very very soon and will try to explain this in detail.
Focus on what is practical, not some academic ideal. Think about how SPF
will work in an environment with other methods.
That is exactly the reason for writing the paper - how different methods
with different identities can interoperate with each other and what
considerations should be given to how that is implemented. I'm trying my
best over last week to rewrite it from more research-oriented into more
information to users and practical use oriented.
P.S. I'll not be talking any more about it, I'd rather use the time to
actually finish it.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net