On 3/25/07, Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:
Randy Smith wrote:
>
> Greetings,
>
> I was recently discussing various issues surrounding email with a
> coworker and had a couple of ideas for authentication systems that I
> would like to get some feedback on. You can read my ideas at
>
http://perlstalker.blogspot.com/2007/03/mail-server-registries-and-foreign.html.
>
>
> As I said, I'm looking for feedback. Are these ideas worth pursuing or
> am I barking up the wrong tree?
>
> Thank you for your time.
In my opinion, you are not barking up the wrong tree, but the
"inevitable tree." Its not a new concept, but a concept we have moved
away from in the name of having an open anonymous system. But we seem to
be reinventing ourselves to go back to this direction.
The biggest problem, IMO, is not the open system but the anonymous
one. One reason spam works so well is that its so very easy to lie
about who the sender is. I don't think there's any reason why a mail
admin couldn't setup their own registration server but as the
recipient, I need to have some way of knowing that I can trust the
registry, hence the web of trust built around server keys.
In short, you are simply talking about a client/server negotiation
handshake stage. In my opinion, maybe not in our "engineering" life
time, this is will be the ultimate method of client/server operations.
The anonymous sender will be "thing" of the past.
[snip: fidonet history]
In any case, conceptually, we are talking about the same type of direction.
- Registration of servers and clients within some "controlled
and centralized" nodelist/DNS system.
- It will confronted with the same Legacy issues of supporting
legitimate clients that might not part of the "controlled network."
As with Fidonet, this is where you will have the major
uphill battle. The IETF is dead set against breaking the
the current open network integrity of the system. Legacy
software must be supported.
I happen to agree. Legacy software must be supported, however, I am also
open to introducing a ZMH like idea where systems are allowed to
designate "open" and "closed" times for legacy systems.
What I'm thinking of would be an extension to SMTP rather than an
entirely new system. As the main admin for an ISP, the last thing I
want to do is build a second system to handle a new protocol that
hardly anyone uses (at least, until the rest of the Net migrated). I
think the hand shake could be complete wrapped within the SMTP
conversation.
Based on these experiences, I had started a IETF draft awhile back that
basically defined "SERVER ATTRIBUTES" records that clients will use to
obtain server attributes that will cover these client/server negotiation
parameters. I happen to believe the idea will be eventually be a major
part of the system, in some form or another and we are beginning to
touch based with it with DKIM and its SSP ideas. Also look at the
growth of SIP communications. It is all going (back) in this direction.
It may be necessary to add a capabilities keyword similar to IMAP or
specify that the EHLO response include a list of supported keywords.
Thank you for taking the time to respond to my ramblings. :-)
--
Hector Santos/CTO
Santronics Software, Inc.
--
Randy Smith
http://vuser.org/
http://perlstalker.vuser.org/