J.D. Falk wrote:
Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
3rd party signing was removed from discussion some time ago
...with the intention of discussing it again after seeing how the industry
deals with 'em, both with & without ADSP.
But you been discussing it all along. It never went away. What do you
think this i= was about?
Plus the industry is already seeing what affects it can have with you
have a mailing list like mipassoc.org and ESP's gmail.com blindly sign
all mail regardless of policy (see below).
1st party, as addressed in ADSP with d=: simple, easy to understand, but
doesn't apply to all possible use cases.
No, it applies to the HUGE market of private domains that have no
expectation of having resigners do their mail.
3rd party: complex, difficult to understand, and the use cases are
infinitely varied.
Again, there is a HUGE market of private domains that simply want one
thing:
"I DON"T WANT 3rd party signers"
"I allow these signers"
Its that simple. If the 2nd one is too complex, the first one should
be possible - we have that in ADSP. But it make it worst for DKIM
resigners issues.
Until then, we're just guessing.
You know, I'm growing tire of such thinking.
This isn't the 1970s/80s where there many unknowns. These early
relaxed ideas for security related issues where justified. But after
30 years, there are what? millions of industry man-hours experiences
in how the mail system works and know exactly where are the threat
entry points. I don't think I am the only one, maybe here but I don't
think so, that understand that. It doesn't take a PHD to understand
that we have a legacy mail problem that promotes spoofing.
DKIM helps raise the bar to a new level of email expectations. It
would move the mail into a non-legacy mode.
I believe in the incremental approach, I am very conservative. But we
can't approach this with another relaxed period of many years to
confirm what we already know can cause problems today. In my view,
this would be engineering neglect.
We know what the problems are and there are some pragmatic solutions
to it. The frustration of mine is that we didn't remove these ideas
for technical reasons, but for conflict of interest reasons.
Reputation was suppose to be out of scope, but even when it repeated,
the KEY documentation gurus keep making it a vital part of the DKIM
solution with less emphasis on policy. Policy was never their prize,
Reputation trust services where. So lets the record straight. I am
not wasting your time here. The WG is wasting everyone's time.
I doubt we will get another chance like we have now to "Get right it,
the first time" (Sorry, I was Westinghouse trained with this QA
engineering motto).
If we don't, we are going to have to raise the bar again with a new
level of email expectations because DKIM/ADSP will be become the next
legacy email framework or worst, completely useless it is ignored.
We are already see this in motion with this mailing list and services
like GMAIL.COM signing mail on behalf of others. So it might bee too late.
Finally, I haven't implemented DKIM. To me, that says a lot because I
would be among the first to implement solid technology. I like to
think I represent a part of the market place that will be concern with
problematic technology.
So no, its not guessing on my part. Its called engineering with
history behind you to know what to expect and not expect.
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html