Summary
I have put together several blogs over the past several months since JavaOne. I have neglected to post these here, but will now. There is some disjoint discussion in these. Hopefully I've made my thoughts visible...

---

Advertisement

SMTP is like POP, and Can Eat Away at Your Stomach Too

The Simple Mail Transport Protocol (SMTP) and the Post Office Protocol (POP3) (version 3 and still wrong) are great examples of the problems that I described in Jini IS THE answer. SMTP is the protocol used between Email clients and servers to submit email. It is also used between email servers to route email between systems when a client can not reach a particular network directly. POP3 is one of two well defined protocols that email clients use to get email from SMTP servers. The Internet Mail Access Protocol (IMAP) is the other well known email client. While IMAP has some more friendly features related to keeping your mailbox in one place and accessing it remotely, it still has many of the same basic shortcommings that POP3 has.

There is No Security like No Security

The electronic mail system is made of an infrastructure that is very fragil, and very insecure. The basic SMTP infrastructure has no support for authentication and very limit support for authorization. The argument to the SMTP HELO command is a host name. This argument, when HELO is issued to the SMTP server, is supposed to tell the remote host who you are. Most public network SMTP servers however accept email from anywhere because the DNS system can not provide a reliable mechanism for determining the originating domain/host of an IP address.

The wire protocol is all that is available for SMTP interactions. It defines both the connective tissue and the interactions that must occur. So, I could not, for instance, start demanding that people have Kerberos identities in order for me to accept their emails (can you say no more spam?). In the Jini v2.0 JERI transport, I can assert such requirements, and I won't, in general, have to change any software to do so. I can specify, in my configuration file, what is required to create the interface from my email client to the SMTP server. If my server utilized a JERI based transport interface to other SMTP servers, then it could be configured by me, to have the Authentication, Authorization and Integrity requirements that I want to be enforced regarding the email I receive!

What good is a Platform

When you look back at all of the wire protocols that have been developed over the years, you will notice all the attempts to make them operating system independent. One of the biggest efforts with the implementation of electronic mail was to try and make it possible for UN*X, VMS, and CICS, VM, WYLBUR, and a host of other proprietary email systems all interact together. Only the RFC822 specified standards won out in the end. Everyone finally realized that a common interface was a very good thing. The problem was that they stopped at the low level wire protocol and did not come up with a programming API that talked in terms of high level operations.

The MMDF mail System

The MMDF mail system was developed to solve very highlevel email problems. It was extended, quite naturally, with authentication that disallowed the use of particular channels under administrator specified requirements. The authentication implementation was done to allow expensive overseas communications paths to be used only be select people, under select circumstances. This work was done in the early 1980's. In 1998, I used these capabilities to disallow SMTP relaying. I also used it to allow remove POP clients to submit email into the system which would have been considered relaying because the email would have come from the SMTP channel and be destined to either the SMTP or delay channels.

MMDF was chosen for and widely used within the .mil domain email servers back in the 1980's. SCO shipped MMDF as the Mail Transport Agent (MTA) in their distribution for some number of years. Of course all BSD based systems ended up with Sendmail as their default MTA.

MMDF has a very nice programming API with the MM libraries. MMDF has a very safe design in terms of exposure of the root user. Any part of the system that needs root priviledges such as the SMTP server, or the local channel, use their priviledges immediately to bind to port 25 (in the case of the SMTP server) or change UID to the destination mailbox (in the case of the local channel).

The important thing about MMDF is that it was designed with a programming API, not a text specified configuration API that doesn't provide the outright capability to manage security, or authentication precisely as Sendmail suffers from.

Upgrading any system using a programatic interface instead of wire protocol

The next step up the ladder of progress is to start working on a programatic platform standard. Why you ask? Because it will greatly simplify what is required to make software work everywhere. It will strengthen security by making it possible for the application layer to assert security constraints in a timely manner, and do so, independent of the transport protocols capabilities.

TCP/IP transported data and control protocols do not provide authentication, authorization or security seemlessly or configurably. Sure you can set up VPN based tunnels that can secure data. But you can't assert all the necessary requirements that might be varying based on deployment. In a test environment, developers need to have speedy startup of applications. In a production environment, applications need to be deployable with a wide range of security constraints possible.

If the developer is not responsible for the constraints used at deployment, the deployer has more power to assert the proper constraints. This is one of the major themes of Jini 2.0. And, from my perspective, this is the major theme that needs to be the foundation of the next generation of software.

Talk Back!

Have an opinion? Readers have already posted 7 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Gregg Wonderly adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Gregg Wonderly graduated from Oklahoma State University in 1988 with an MS in COMSCI. His areas of concentration include Operating Systems and Languages. His first job was at the AT&T Bell Labs facilities in Naperville IL working on software retrofit for the 5ESS switch. He designed a procedure control language in the era of the development of Java with similar motivations that the Oak and then Java language development was driven by. Language design is still at the top of his list, but his focus tends to be on application languges layered on top of programming languages such as Java. Some just consider this API design, but there really is more to it! Gregg now works for Cyte Technologies Inc., where he does software engineering and design related to distributed systems in highly available environments.