On Thursday 06 December 2007 13:11, Steve Atkins wrote:
On Dec 6, 2007, at 9:58 AM, Scott Kitterman wrote:
On Thursday 06 December 2007 12:49, Steve Atkins wrote:
In a well-designed protocol based on DKIM, yes I'd agree that a
validly DKIM signed message should not provoke an SSP query.
But that's not the protocol we have.
I think RFC 5016 shows a lack of understanding of DKIM (or is
choosing
not to consider some important features of DKIM), and is
part of the push to try and build a next generation SPF on
an inappropriate base authentication technology.
I think you aren't understanding the purpose of SSP at all.
If any random signature from any domain obviates the SSP, what
possible use is
SSP?
Bill Oxley observed across threads "When it comes to discussing
SSP I hear a lot of noise with very little reason to implement or use
except in a few specific cases like highly phished sites."
There's a long discussion to be had there, which starts with me
asking "Well, what's your threat model?" and would ideally follow
with "So, given this framework, what is your attack tree, and how
does SSP help thwart it?", but when I've tried to have that discussion
in the past it's not gone anywhere productive
Personally, I think that exact question has been asked many times and answered
with great specificity many times. I agree that those who disliked SSP at
the start of the working group still disagree on this.
Personally, I think only the highly phished sites that really care about
forgery will publish highly restrictive SSP records and so I think Bill and I
actually agree.
The choice in my mind is whether something like SSP is decided in secret among
large highly phished senders and large receivers or if we are going to have a
standardized approach that all can use IF they wish. As has recently been
said, no one is forcing anyone to use SSP. Those who don't like it are
perfectly free to ignore it.
What I see going on is a desire to change SSP into something completely
useless, and then based on this change, declaring it useless.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html