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.
> > On the other hand, if you never venture outside the > Java-sphere, nor interact with anything but Java... keep > popping those pills ;)
Great point. I think it's pretty obvious that spammers have hi-jacked SMTP and the amount of spam that gets delivered is scary. Personally, I would say only about 10% of the e-mails I get are legit, the rest is spam.
Now, I filter that stuff out via Mozilla's spam filter, but it fails to solve the problem. I may have to resort to whitelists pretty soon, with some sort of authentication system for people who are sending me e-mail for the first time.
Either that or FORCE people to use SMTP-AUTH. I blame a lot of lazy sysadmins and ISP's who seem to think that their customers aren't supposed to actually learn anything about how the Internet works.
And which clients and which servers have this in place already? Where is the key exchange implementation. How many different versions of that will be written. Which will have security bugs? Which will not? How many times will I have to get a new key because mine is exposed?
The standard is important. How it is implemented, and how many times it is implemented is even more important.
> Another fundamental difference between a protocol > and a language specific piece of folklore is, well, than > one is universal and the other is not.
But on portable platforms, such as Java/Jini, portability is free. Where as if you just hold out the standard without and implementation than you get everyones interpretation, and everyones bugs.
> Plus, what's the point of using Jini when all you really > need most of the time is Zeroconf's DNS Service > Discovery:
Jini is not just about discovery. It's about reliable distributed computing including distributed transactions, leases and the JavaSpaces spec, for a central, disconnected rendevous point.
> On the other hand, if you never venture outside the > Java-sphere, nor interact with anything but Java... keep > popping those pills ;)
Funny thing is, the longer I stay in this box, the worse the outside of the box looks... I'm not crawling in a hole to hide. I am standing in this box because it has finally allowed me to focus on solving problems. I program without worrying about all the other cruft that I had to when I used any other of a number of languages that just provide part of what Java provides in totality (from my perspective).
> Sometimes it reshapes the way I think about computing, yes!
In know, when the pills are strong enough, everything looks the same shade of pink, doesn't it?
> But on portable platforms, such as Java/Jini, portability is free.
This is not about portability. This about interoperability.
> Jini is not just about discovery.
Sure. But discovery is the most useful aspect of it. In any case, ever heard of Telescript and its grand plan to change computing as we know it?
> I'm not crawling in a hole to hide.
Right... well... good for you... unfortunately... some of us (i.e. not you) live in the real world where COBOL and FORTRAN don't speak Jini just yet...
> > Jini is not just about discovery. > > Sure. But discovery is the most useful aspect of it. In > any case, ever heard of Telescript and its grand plan to > change computing as we know it?
Then you must have no real experience with using Jini nor with writing distributed applications if you think discovery is the most useful aspect! Once you find what you want to use via discovery, you've got all kinds of other issues to worry about. What if the network becomes segmented, you need leasing and transactions to help you make sure that you see the other side disappear. Then, you get to use discovery again to find a replacement service, or wait for your singleton to reappear. Because you were using transactions (you were using transactions weren't you?), you know what state the other side reached before the interruptions. If you are using activation, then you may even be able to just continue where you left off, if the singleton came back up before you failed over to the back up...
> Right... well... good for you... unfortunately... some of > us (i.e. not you) live in the real world where COBOL and > FORTRAN don't speak Jini just yet...
Ahh, and your ignorance is showing though :-) Jini 2.0 includes JERI, which gives RMI endpoints that can interact with other protocols. This means that the wire protocol becomes immaterial. You don't have to care about it beyond the time it takes to locate, or write the endpoint that provides interaction with your legacy system. From that point on, any Java code you have, or will have can talk to the legacy system. If your system is synchronous in and out, you can write a Jini service that provides the access point for everyone else to use, and the other services can feel like they are working asynchronously without having to have the synchronous aspects of the legacy system in grained in them. When the legacy system is replaced, you can use the same interfaces to implement the replacement, and the new code will just work.
Until we stop embedding legacy interfaces everywhere, we will always get to interface with legacy code...
> Then you must have no real experience with using Jini nor > with writing distributed applications if you think > discovery is the most useful aspect!
Ever heard of Telescript? You should get out more ;)
Previous Topic
