On May 26, 2010, at 3:02 PM, Steve Atkins wrote:
On May 26, 2010, at 11:48 AM, Michael Thomas wrote:
On 05/26/2010 11:30 AM, Steve Atkins wrote:
Michael claims off-list that he has no idea what I'm speaking of.
I said "huh?" too.
Perhaps I'm missing something. I'm working with the mental model
that the underlying problem ADSP advocates would like to address
is phishing or brand protection, as they're the only concrete problems
I've seen mentioned.
So you're on a tangent about something that's not even vaguely in our
charter.
I don't believe I am.
ADSP doesn't claim to solve "phishing", it just allows bit-for-bit
domain names to be safely tossed if they don't have a signature. How that
integrates into the larger anti-phishing modules is frankly where the secret
sauce lies for vendors.
We can't usefully discuss things like best practices or a revision of
the spec without some sort of concrete operational use case.
The only operational experience I've seen discussed so far is entirely
negative - it causes mail from mailing lists to be lost and leads to
recipients being unsubscribed from those lists.
We really need to come up with some positive operational experience,
or at least a theoretical situation where some may occur, before we
can talk about either best practices for using it or modifying the spec in
order to avoid the observed problems.
Paypal is claiming an operational benefit, but haven't actually
demonstrated that ADSP either provides that benefit, nor that
those benefits can't be provided in a significantly cheaper manner.
I thought I had. Remember that business about 100 million phishing attacks
being blocked (DKIM alone would not have delivered that... it was our policy
assertion and the acceptance to act on that policy assertion that made this
happen)?
What do I need to show you guys before you accept that I have demonstrated that
ADSP provides operational benefit?
So we're left with a protocol that doesn't appear to be terribly
useful for any particular use case, and which is demonstrably
broken when used with mailing lists.
This thread started with the observation that ADSP was broken
w.r.t. mailing lists, and discussion of how the spec might be
changed such that it wasn't broken in that respect, yet would
still be effective for it's main purpose. We also have tangents
on how it should be deployed in practice ("What does 'discardable'
mean? Does it mean you should reject mail instead of discarding
it?")
And that leads to... what is the intended main purpose? Without
that, there's no way to decide whether the suggested changes
will improve things, or simply cause it to be more broken (via
increased complexity leading to reduced usage or incorrect
usage, for example), nor to provide appropriate advice on
deployment (other than "Don't, yet.").
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html