When I saw your first post about the exercise, I thought it was a
rhetorical one to make a point.
The problem with your exercise is that it assumes that 2821 and
2822 are mutually exclusive and a method may not encompass both.
On the contrary, the excercise covers both aspects of mutally exclusivity as
well as integrated dependency considerations, whose results all depend on
your point of view, discipline and position in the market place.
Design arguments can be made that any method should not encompass both,
but the realities of how email operates may make that difficult since
current operating practices already blur the two.
So you too, proved my point. :-)
I have been watching and reading the discussion on this and various
related lists for some time.
Although I appreciate folks are excited, let's keep the goal in mind.
An easy, light weight cryptographic solution to allow receivers to
authenticate the "sender" that does not add significant over head.
Given the various ways that we can "send" mail and identify whom the
mail is "from" in the message header, the basic design of allowing a
sender to say, "yup, I sent that mail," or "yes, that's me" without
tying that authentication to any specific path, route or part of the
message header is critical.
This will allow for "transparency" that fits with existing best
practices and standards.
Why? So that when asked, the identity that is being authenticated can
say "yup, that's me" and the receiver can reasonably rely on that
statement to do as the receiver will with the message, applying best
practices and standards.
I apologize for being pedantic and I appreciate this is not an easy
problem to solve as email, being a form of human communication is both
fragile and robust, while being simple and complex.
But a lot of time, energy, effort, design work and some significant
level of testing has gone into DK and now DKIM to capture these goals.
We must be careful not to get caught in the trap of over-engineering,
or wanting to "redesign" the underlying concepts.
This is a practical technical problem that needs a serious workable
solution which is field tested, with instructions that are "easy" to
follow and fit with best practices and existing standards, so that
those trained in the art can proceed to implement.
Potentially, we have that in "hand." My request? That we keep this in
mind and move the discussion forward, working on converting this
"potential" into reality, while being farsighted enough to avert any
reasonably foreseeable and likely dangers that may be lurking out
there within the existing framework of best practices and standards.
Simply put, no "ghosts" and let's not try and "fix" email, "stop"
spam, phishing or anything of that sort.
Now, having put my oars in the water, I am going to row back to the
river bank and return to lurking.
John Glube
Toronto, Canada
_______________________________________________
ietf-dkim mailing list
http://dkim.org