ned(_dot_)freed(_at_)mrochek(_dot_)com writes:
Fine, so let's run with these. The first of these canont be achieved with the
present infrastructure unless protection is restricted to long hop
situations,
doesn't protect the entire message, or both. This then exludes the ideal of
protecting the entire message end to end, which is exactly the goal some
people
seem to be striving for, and in so doing letting the best be the enemy of
what
you yourself are now saying is good enough.
I view your "ideal" as being just that: something that's
nice and that should be mandatory to support, but my "good
enough" is that I'd like senders to be able to make a
risk/reward decision on the security/robustness tradeoff.
Here, the (security) best/ideal is, IMO, the enemy of the
(robustness) good. A MASS protocol which fails verification
some large percentage of the time, IMO, is a failed
protocol.
The second of these argues stringly that accreditation has to be part of the
work we do, because without it I see no way to perform the correlation you're
after.
The home domain is one source of "accreditation", albeit
self-referential. More (and independent) sources of
accreditation are obviously better.
If you have a different set of metrics, please state them.
I have stated my metrics. I see nothing about them that's in any way
circular,
so I guess this conversation is over.
Ok, let's try this again: you said:
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.
Let's, um, run with these. (1) I guess we agree on, though I
view it as just a protocol requirement. The second... you've
lost me. I don't know how to evaluate what is "good enough"
with such a vague goal. I'm not saying that I view this as
useless against fighting spam, I'm saying that I don't see
how you've made the leap from "good enough" and "fights
spam". How did you determine that? What metrics did you use?
Mike