----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Scott Kitterman" <ietf-dkim(_at_)kitterman(_dot_)com>
based on a false premise and out of scope.
You agree that SSP does not provide a mechanism to prevent spoofing
without reliance upon visual presentations,
You might have brow beating down Scott, but this is totally false because
the MTA can reject it before the MUA. It doesn't need a VISUAL presentation
or confirmation.
but that a scheme which avoids this reliance as an option
within the DKIM signature is out of scope?
If it was just logic that within DKIM, thats fine, but its MORE than that.
It is not just an option. Case in point....
The "broad" binding mode would offer the same ability to reject
messages at the SMTP session as would the SSP 'o=!' policy, but in
microseconds rather than seconds.
Your DKIM options a heavy reliance on SMTP caching information, a
centralized reputation database, threathens the security of internal User
Account databases, and relies on an unestablished protocol called CSV/CSA or
whatever the name of the month it has.
If we want to go this route to the pure MTA to MTA chained security, then
lets save millions of money and man-hours cross the board and just begin to
consider SPF.
SPF is here. It is not going to go away. Time for the key cogs to get over
it, adopt it and endorse it. It is well established, well defined, millions
of people are using, 27% growth rate since July, love'em or hate'em, the
worlds #1 computer company has endorsed it, many high-value domains use it,
and what is really great, it is an RFC standard track item, doesn't need any
SUB WORKING GROUP.
Just include SPF as part of the DKIM implementation considerations and we
are done with the 2821 considerations.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org