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.
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.
Look at the old Fidonet technology, 100% based on a similar
client/server negotiation concepts.
1) Every server MUST be "registered" with a "HOST", in Fidonet, that
would be your uplink Net or Zone Host. In the internet, that might be
your "ISP", the early forms of Fidonet Net/Zone Hosting systems that
were the backbone of the topology.
2) When installing the software, you applied for a FIDONET address and
your "ISP" would check your system for 100% FTN compliance before you
were assigned a Fidonet Address.
3) You were not allowed to be part of the "net" if you did not have a
100% FTN compliant client and server. Not compliant? No Fidonet
address was given to you.
4) There were four basic requirements:
4.a) The software support the legacy FTN1 file transfer protocol. The
more advanced IEMSI is akin to what we have today with EHLO and extended
server attributes.
4.b) Although you can apply for a private address, ALL servers must be
available during Zone Mail Hour (ZMH). This is akin to having a 100%
closed system but there were designated times where you allowed
anonymous mail (from a registered FTN member) to come in.
4.c) ZMH was designed for making sure ROUTED mail is ALWAYS available.
So even if you didn't allow DIRECT mail, a person can send routed mail
to you via your HOST which you must ALWAYS accept.
4.d) During ZHM, at a minimum FTN1 must be supported.
There were probably others, but the above were the main things and in
addition, the most contentious issues during the "Fidonet/Internet
Migration Days."
The legacy FTN1 protocol was REALLY old and it has major problems in
packet switching networks. ZMODEM and other file transfer protocols
designed for Packet switching networks were part of the newer generation
Fidonet software, but were OPTIONAL and not required. However, new
developers were not bothering with the older problematic FTN1 protocol
and using the new protocols which at least 99% of all systems supported.
But the old school FTN net police insisted on FTN1 and rejected
applications, registrations of any person installing newer and better
software if it didn't have FTN1 support. This turned off alot of
developers and with the Internet humming around the corner, and new FTSC
(akin to IETF) groups created to get around these policing issues,
Fidonet began on a death spiral. The one thing the FTSC had control of
was the NodeList, this would be akin to DNS. So new Nodelist ZONE files
were created to establish new networks where the FTSC had no control.
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.
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.
--
Hector Santos/CTO
Santronics Software, Inc.