At 07:49 PM 5/24/2005 -0400, Mark Shewmaker wrote:
On Tue, May 24, 2005 at 11:10:40AM -0700, David MacQuigg wrote:
> Mark,
>
> Let's wrap this up. We seem to have a fundamental disagreement on the
> purpose of authentication.
Your ID method as you have described it does not and can not
authenticate the various permissions that various parties have granted
the client MTA, permissions which are important to me.
Obj: The ID method cannot authenticate all the permissions that various
identities have granted the sending MTA. These permissions may be
important to a receiver.
Resp: The ID declaration is just that - a declaration. It is not an
authentication method. It does not take sides in the battle over
authentication methods. It simply facilitates access to whatever methods
the sending MTA provides. It does not prevent a receiver from trying other
methods. It does not prevent a receiver from rejecting a sender that
doesn't provide a receiver's favorite method.
(As a side note, it is technically possible for it to do so, given some
serious modifications that would change it drastically.)
Instead, it authenticates something else entirely, with a purpose almost
completely unrelated to my own interests and those of every other
responder I have seen on this list.
> I need to summarize your objection in a short
> statement, and present both sides fairly.
Then I would suggest studying the previous responses from myself and
others on the topic of this ID proposal of yours.
> Objection: Why should I care what the ID owner (who is trying to claim
> responsibility of some sort) wants or expects with respect to
> authentication tests?
An answer to this question that actually answers the question might
serve as a convenient jumping-off point for a new thread, once you find
a forum in which such a discussion would be fully on-topic.
If you can suggest a better statement of your objections, let me
know. Otherwise this thread is done. Statements like the above are not
appropriate for a summary. I will, of course, reference the entire thread,
in case the IESG want to read it, and see that I've made my best effort to
state both sides fairly.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *