ned(_dot_)freed(_at_)mrochek(_dot_)com writes:
> > I've asked this before, and I'll ask it again: what
> > problem does that solve? "Good enough" that doesn't
> > solve real world problems is not "good" or "enough".
>
> It provides a sufficient basis to deploy a domain-level message
authentication
> system.
>
> Of course this is not, in and of itself, capable of addressing the spam
> problem, since spammers will simply register random domains with
whatever
> credentials they need. But this issue of what the identity the message
is bound
> to actually means arises in all signature schemes. What this scheme has
that
> the end to end proposals do not is the ability to be deployed on top of
> existing infrastructure.
You're sidestepping my question: how do you quantify "good
enough"?
I have stated what I regard "good enough" to be so many times it isn't
funny. For me "good enough" is something that:
(1) Can be widely deployed.
(2) Offers significant assistance in the fight against spam.
This seems highly dependent on the actions that a
receiving domain takes upon receipt of a signed piece of
mail. The most naive thing I can think of doing is
highlighting signed mail as to whether it was authorized
(green) or not (red). In fact, I do this today with
Evolution with a couple of input filters for IIM. For that
to be satisfactory for your average user, the green-red
ratio must be *really* high, otherwise clueless users are
going to complain and make a worse situation for their ISP
or employer. "Good enough" here has a fairly high barrier.
If we're talking about is authenticating mail end to end, we already have
four
specifications for that and no need for any more.
But feel free to tell me other use scenarios where "Good
enough" requires far, far lower breakage rates. I'm all for
not letting the best be the enemy of the good, but you have
to know friend from foe before you do that.
What you have to know is when to stop. And frankly, this is something the
IETF
rarely does well at.
> This in turn means that we need to start considering how to attach
meaning to
> domain identities sooner rather than later, e.g. by devising some form
of
> accreditation mechanism. Believing that signature schemes will widely
deploy
> when the signatures they produce have no meaning is a fantasy, plain and
> simple. So, while the signature and accreditation problems are in some
> sense separate, they both have to be solved before we'll have something
> useful. And this is also something that's missing from the current
> charter.
Do you see any value in the home domain authorizing a piece
of mail sent from it?
By itself, not really. I'm sure there will be cases of "cross authorization"
between large domains by private agreement that will solve some problems, but
not only is this insufficient, it creates the very real possibility of the
little guys getting effectively locked out of the email game.
That is, do you think that problem is
even worth solving?
It is worth solving because it is an essential component of the service we
need
to build to combat the spam problem.
With IIM, you don't _have_ to perform
the KRS check, after all -- it could be used purely as a
means of identifying the sender for use by a third party.
And again, for survivability what would be "good enough"?
It's a tradeoff: The more survivable a scheme is the easier it will be to
deploy, and vice versa.
But as far as I can tell this group refuses to admit this, and in fact I've
seen no real indication that this group believes deployability to be a
requirement. (The charter that some find to be acceptable says nothing about
it, for example. The charter also excludes the accreditation problem from
consideration, and I regard that as also being unacceptable.)
When would receivers just throw up their hands and say
"broken protocol; ignore"?
I have no idea what this means.
Ned