Carl Malamud: Internet Talk Radio, flame of the Internet. 

Malamud: This is Geek of the Week and we’re talk­ing to Ned Freed, who is a cofounder and Chief Development Officer with Innosoft International. Ned, I have two ques­tions to start off with, what’s a Chief Development Officer, and what’s Innosoft?

Freed: Innosoft is a small soft­ware devel­op­ment com­pa­ny that was start­ed by three stu­dents who’d just grad­u­at­ed from Harvey Mudd College, myself, and Kevin Carosso, and Dan Newman were the prin­ci­pal founders. And we ini­tial­ly start­ed out by sell­ing of all things math­e­mat­i­cal mod­el­ing soft­ware. Which turned out to be fun but not particularly…profitable, shall we say. And we as sort of a side­line we had devel­oped some elec­tron­ic mes­sag­ing facil­i­ties for VMS sys­tems. And the devel­op­ment of that turned out to be a much more rea­son­able busi­ness propo­si­tion and so we start­ed con­cen­trat­ing on that. And Innosoft cur­rent­ly… I believe we have four­teen employ­ees at the present time? And I am the nom­i­nal Chief of Development, but my strange title comes from the fact that I’m also an offi­cer of the company.

Malamud: Ah, so you’re not in human resources or any­thing like that.

Freed: No, afraid not.

Malamud: You make basi­cal­ly VMS-specific mes­sage han­dling software?

Freed: Correct. PMDF is our pri­ma­ry prod­uct. It is actu­al­ly sort of a gener­ic mes­sag­ing switch that was devel­oped orig­i­nal­ly on VMS but it has been port­ed to oth­er plat­forms. However, our inter­est thus far has been sole­ly in oper­at­ing it on VMS sys­tems, where the rel­a­tive lack of Internet mes­sag­ing tech­nol­o­gy makes it you know, a good fit, a par­tic­u­lar­ly good fit. And—

Malamud: It’s a good fit in terms of a mar­ket niche, but do you find that the Internet stan­dards are a good fit for the VMS oper­at­ing sys­tem, or are they Unix-specific?

Freed: There’s more Unix-specificity in the stan­dards that I would like. And there’s far more Unix-specificity in cer­tain imple­men­ta­tion aspects of var­i­ous Internet things. Messaging hap­pens very for­tu­nate­ly one of things is rel­a­tive­ly immune to that. But there are oth­er things that you run into from time to time. For instance things that go around look­ing at anony­mous FTP servers, as an exam­ple, and don’t under­stand the VMS path struc­ture, and you know, that kind of thing presents a prob­lem. Those crop up rel­a­tive­ly reg­u­lar­ly and present dif­fi­cul­ties to us.

But since we write all of our own code in our par­tic­u­lar envi­ron­ment, we don’t real­ly see a sig­nif­i­cant prob­lem with the incom­pat­i­bil­i­ty of the stan­dards ver­sus the envi­ron­ment that we’re in. You know, it helps that the VAX is—and the Alpha—are you know, fair­ly nat­ur­al machine struc­tures. I mean just because we’re on a dif­fer­ent oper­at­ing sys­tem does­n’t mean that the under­ly­ing hard­ware has any fun­da­men­tal­ly incom­pat­i­ble notions. I mean, we have rough­ly the same byte sizes and things like that, so we don’t run into sig­nif­i­cant prob­lems in that area. Which you do run into on oth­er weird­er kinds of hard­ware and software.

Malamud: You’ve been heav­i­ly involved in the effort to devel­op MIME, the mul­ti­me­dia mes­sag­ing in the Internet stan­dards. Tell us a lit­tle bit about MIME and what it does.

Freed: Okay. MIME, which stands for Multipurpose Internet Messaging Extensions—some peo­ple say mul­ti­me­dia, some peo­ple say mul­ti­part. It does­n’t real­ly mat­ter, it is what it is. The MIME work start­ed out odd­ly enough as an effort to devel­op a mech­a­nism to han­dle inter­na­tion­al char­ac­ter sets in the Internet mes­sag­ing envi­ron­ment. That was the orig­i­nal char­ter of the work­ing group that was orig­i­nal­ly formed to deal with these issues. 

However, mes­sag­ing in the Internet, despite being prob­a­bly the largest sin­gle appli­ca­tion that’s used on the Internet today, had received rel­a­tive­ly lit­tle atten­tion in terms of the stan­dards process sub­se­quent to the devel­op­ment of RFC 822, which is a 10 year-old doc­u­ment. Actually it’s old­er than that now. But it was just reproach­ing its tenth birth­day as MIME came to fruition. The devel­op­ment of MIME start­ed as an effort to deal with inter­na­tion­al char­ac­ter sets, but because of the lack of atten­tion it grew into much more, and we want­ed to deal with a lot of the needs that had not been addressed in the mes­sag­ing world in a clean and uni­fied kind of way instead of try­ing to solve each of the indi­vid­ual prob­lems piecemeal. 

The oth­er very impor­tant thing about MIME that—it nev­er hurts to empha­size this and you real­ly can’t empha­size it enough, is that MIME is a cul­mi­na­tion of work based on three pre­vi­ous attempts to do var­i­ous types of mul­ti­me­dia and mul­ti­part Internet mes­sag­ing. Various oth­er peo­ple had tried all sorts of oth­er schemes in the past.

Malamud: What are some of those schemes?

Freed: Some of those schemes are the RFC 934 defines a mes­sage encap­su­la­tion for­mat, a way of encap­su­lat­ing one mes­sage inside of anoth­er and hav­ing mul­ti­ple parks in a mes­sage, with bound­ary mark­ers and things. RFC 1049 defines a con­tent type or a label­ing scheme so that you can tell what is in a giv­en mes­sage. The Privacy-Enhanced Mail work had defined an encod­ing for­mat so that bina­ry mate­r­i­al could be sent through exist­ing Internet mes­sag­ing. RFC 1154 had defined a label­ing and bound­ary scheme for putting mul­ti­ple things into a sin­gle mes­sage. And there were var­i­ous vendor-proprietary schemes. NeXT has a scheme that’s pop­u­lar on that plat­form. And there are sev­er­al oth­ers from oth­er dif­fer­ent ven­dors. The NeXT one is prob­a­bly the best-known of those.

Another one that’s actu­al­ly impor­tant because of the influ­ence it had on one of the coau­thors of MIME, Nathaniel Borenstein, is the Andrew mes­sag­ing sys­tem which had done mul­ti­part mail in its own pecu­liar way for many years. And Nathaniel was involved in the devel­op­ment of that. 

All of these schemes worked to a cer­tain extent. They had var­i­ous prob­lems, of course. Everything has prob­lems. But none of them had achieved wide accep­tance and wide usage across the Internet. And part of the ini­tial MIME effort focused on try­ing to iden­ti­fy why these efforts had not reached fruition and wide deploy­ment. In some cas­es it was sim­ply per­haps more of a fac­tor of these had not real­ly been standards-blessed efforts, and hence were just exper­i­men­tal things that peo­ple had put togeth­er at one point or anoth­er. A lot of the vendor-proprietary pro­to­cols used for­mats which were not backwards-compatible in any real way with exist­ing appli­ca­tions. And since we felt that that was one of the real hin­drances to accep­tance we were very care­ful to stay away from using for­mats that had sig­nif­i­cant impact in terms of back­wards com­pat­i­bil­i­ty with exist­ing appli­ca­tions. And that phi­los­o­phy, that one sin­gle point, you can see influ­ences of that through­out the devel­op­ment of MIME.

And so what we even­tu­al­ly… You take all these influ­ences and what we decid­ed to do…and all this stuff, and you wrap it all up and basi­cal­ly what we came up with was a stan­dard that basi­cal­ly real­ly does three things.

First of all is it estab­lish­es a label­ing scheme, so that you can label mate­r­i­al for what it actu­al­ly is rather than rely­ing on some kind of a embed­ding in text and peo­ple being able to say, ​“Gee, this is a sound file. Why don’t you extract it and run it through this and that and the oth­er and then play it.” We want­ed the label­ing to be nat­ur­al and machine-oriented yet read­able to human beings, simultaneously.

Second we want­ed an encod­ing for­mat so that exist­ing Internet infra­struc­ture could be used to send mul­ti­me­dia mail. Multimedia tends to be bina­ry in nature. The exist­ing Internet infra­struc­ture 7‑bit ASCII, so encod­ing is nec­es­sary in order to use that. We felt with an installed base of…what is it, a million-three sys­tems cur­rent­ly, that any­one who did­n’t try to cap­i­tal­ize on that exist­ing infra­struc­ture was basi­cal­ly going to come up with some­thing that nev­er would play. 

Malamud: Well but as I under­stand it a lot of the exist­ing sys­tems already han­dle bina­ry data with­in their mes­sag­ing. Why did­n’t you just accept that fact and go with it? I under­stand that the stan­dards talk about 7‑bit ASCII, but many peo­ple have kind of said well, that’s nice but you know, if you’re with­in this envi­ron­ment you can han­dle bina­ry data.

Freed: Well, first of all, with­in this env— The key phrase there is ​“with­in this envi­ron­ment.” We actu­al­ly use the phrase ​“enclave.” Within cer­tain enclaves bina­ry data can be han­dled, and actu­al­ly it’s rel­a­tive­ly rare to find places that can real­ly han­dle bina­ry data. It’s much more com­mon to find peo­ple that can han­dle 8‑bit text. But the prob­lem is you have no idea when you’re going to run into some­one that does it wrong. And envi­ron­ment can change from day to day. And in the absence of any stan­dards that clear­ly say ​“Thou shalt do this and sup­port it,” a ven­dor is per­fect­ly jus­ti­fied in say­ing, ​“This is not my prob­lem. You’re send­ing me some­thing that I was nev­er sup­posed to get.” And then what do you do? There’s no— You know, you have a finger-pointing exer­cise with no one real­ly being in the wrong, and there­fore there’s no clear jus­ti­fi­ca­tion for any one per­son or ven­dor to clean up the problem.

Malamud: But what about mak­ing all the ven­dors upgrade their soft­ware and let’s say you know, upgrade SMTP to spec­i­fy bina­ry data is one of the ways of trans­fer­ring things.

Freed: Well that’s sort of… That of course is in fact what has hap­pened is an extend­ed SMTP has come out of this work in addi­tion to the MIME stan­dard. However events proved us cor­rect in say­ing that that effort would take a long time to come to fruition. And it is still unclear as to how wide­spread adop­tion of the SMTP exten­sions were. 

But the fun­da­men­tal prob­lem here is that we’re fly­ing in the face of Internet phi­los­o­phy. I mean, this is more or less a philo­soph­i­cal issue which basi­cal­ly says…you know, what we like to say is that the stan­dards are the stan­dards, and you’re sup­posed to fol­low them. And if you don’t, well…you know, that’s fine as long as—and what you can get away with is what you can get away with. But don’t expect oth­er peo­ple to con­form to that. I mean, it’s a much loos­er mod­el than say, strict OSI com­pli­ance or strict ANSI com­pli­ance or some­thing. But it is nev­er­the­less a mod­el, and it is real, and it is there, and we would like to stick with the phi­los­o­phy. And the philo­soph­i­cal point of declar­ing some exist­ing infra­struc­ture as just being out­mod­ed and ille­gal…you can’t just sum­mar­i­ly do that. You have to have a tran­si­tion peri­od. And how are you going to enter in on a tran­si­tion peri­od where you’re not going to be able to use any of the tran­si­tion­al stuff with­out you know— You’re ask­ing peo­ple to upgrade to some­thing they can­not use. And they’re gonna sit there with some­thing they can­not use, that they pre­sum­ably have paid mon­ey for, until every­one in the entire net­work has upgrad­ed equiv­a­lent­ly. And then you have a flag day where you can switch over to the new thing. That may work for Switzerland when they decide what side of the road to change dri­ving on. Apparently they changed over tonight. But the Internet is a lit­tle bit of a loos­er orga­ni­za­tion and it just does­n’t fly, I’m afraid.

Malamud: You men­tioned label­ing as one of the three func­tions of MIME. What’re the oth­er two?

Freed: The oth­er two are the encod­ing facil­i­ties, and the the third one is struc­tur­ing, the abil­i­ty to send more than one object inside of a sin­gle mes­sage. And this is impor­tant for appli­ca­tions where you want to for exam­ple send an anno­ta­tion to an exist­ing doc­u­ment, or you want to send some audio and some video at the same time, and you don’t nec­es­sar­i­ly want to use an inte­grat­ed mul­ti­me­dia for­mat for that purpose. 

In no way does MIME’s struc­tur­ing attempt to usurp the ter­ri­to­ry and the pre­rog­a­tives of very sophis­ti­cat­ed and pow­er­ful mul­ti­me­dia for­mats that allow pre­cise con­trol over place­ment. That is both tem­po­ral place­ment as to what you play when and what you show when, as well as you know, place­ment on the screen and every­thing like that. But there’s a lot that can be done with impre­cise con­trol of place­ment. And by using the tools in MIME you can com­bine rel­a­tive­ly sim­ple for­mats and get very pow­er­ful results. And the bot­tom line here is that not every­body can be expect­ed to upgrade to the same you know—to some very sophis­ti­cat­ed and pow­er­ful mul­ti­me­dia tool simultaneously. 

In fact it’s not even clear that we want to be in the busi­ness of spec­i­fy­ing what mul­ti­me­dia tools peo­ple should in fact use. There’s a lot of ven­dors out there with a lot of com­pet­ing prod­ucts that imple­ment a lot of actu­al com­pet­ing stan­dards for mul­ti­me­dia. And we want­ed to avoid deal­ing with that. We want­ed to sim­ply have a label­ing scheme, and a struc­tur­ing scheme, and an encod­ing scheme, and cou­ple the three, peo­ple can label it as what it is, they can struc­ture how­ev­er they want if it needs to be. And they can encode it so it can be trans­mit­ted over the exist­ing net­work. And then it gets to wher­ev­er it’s going, and peo­ple can undo all of that because it’s actu­al­ly fair­ly sim­ple and obvi­ous how it’s all pieced togeth­er. And they can deal with the results.

Malamud: One of the clever func­tions in MIME is the point­er to exter­nal infor­ma­tion. I can send you a mail mes­sage and that mail mes­sage says ​“There hap­pens to be an archive out there and if you FTP this file we’ll go get it for you.” Could you explain that func­tion and how it works?

Freed: Basically the idea is— This was put in pri­mar­i­ly as a means of sav­ing net­work band­width for mail­ing lists that have a large num­ber of recip­i­ents mail­ing out large doc­u­ments to all the recip­i­ents when it’s prob­a­bly true that a sig­nif­i­cant frac­tion of the recip­i­ents don’t real­ly care about the con­tents of all the doc­u­ments. But that can be a very time- and space-consuming oper­a­tion to try to do that. 

So what we attempt­ed to do, in recog­ni­tion of the fact that any use of mul­ti­me­dia mail on the Internet was going to increase band­width uti­liza­tion, we attempt­ed to try to solve that prob­lem by let­ting peo­ple instead of send­ing the entire object, send a point­er to the object. And the way that works is— We iden­ti­fied sev­er­al point­er mech­a­nisms that could be used. One of them is a mail serv­er where you read the mes­sage and basi­cal­ly the read­ing agent will com­pose a request to the mail serv­er to get the actu­al doc­u­ment back. That’s a rel­a­tive­ly sim­ple scheme. Another scheme is to use FTP to FTP the doc­u­ment over—that has turned out to be the most pop­u­lar scheme, I think. The third is to use some­thing like NFS, or AFS, or some equiv­a­lent file-level access pro­to­col to do it. And owing to the inher­ent secu­ri­ty prob­lems asso­ci­at­ed with that I don’t believe it has proven to be very pop­u­lar just yet. That may change in the future.

It is actu­al­ly rather sur­pris­ing to me that this idea, which was sort of a last-minute kind of ​“gee, it would be nice to do that” sort of thing has proved to be rather incred­i­bly pop­u­lar, and one of the more widely-used pieces of MIME func­tion­al­i­ty. I sup­pose in hind­sight it was obvi­ous that it would be that way. Because no mat­ter how sim­ple a mul­ti­me­dia for­mat is, be it a GIF pic­ture or an audio/basic you know…8‑bit mu-law sound type or some­thing like that, there’s still a sig­nif­i­cant frac­tion of peo­ple who can’t deal with that kind of data on the net­work. And so you basi­cal­ly have to have pri­vate arrange­ments real­ly to know to exchange that kind of mail in any real way. Whereas the exter­nal ref­er­ence type is some­thing that basi­cal­ly every­body can use. Because what you’re send­ing a ref­er­ence to isn’t nec­es­sar­i­ly a mul­ti­me­dia doc­u­ment. It can be a large, or even a small, plain text doc­u­ment. That’s per­fect­ly acceptable. 

Malamud: One of the buzz­words in the 90s appears to be mail-enabled appli­ca­tions. And it sounds like the exter­nal ref­er­ence func­tion in MIME is one of the tools that a mail-enabled appli­ca­tion might want to use. Are there oth­er tools that MIME or under­ly­ing trans­port mech­a­nisms like SMTP ough­ta have?

Freed: Well, the thing that I think is the real stum­bling block to mail-enabled appli­ca­tions right now is the fact that we are only just now begin­ning to put a secu­ri­ty infra­struc­ture in place for elec­tron­ic mail. It is fine to talk about mail-enabled appli­ca­tions at a very sim­ple lev­el where rather than leav­ing the spread­sheet you send a mail mes­sage right then and there and clip out a piece of it. That’s a mail-enabled application. 

On the oth­er hand that’s not dra­mat­i­cal­ly dif­fer­ent than hop­ping to anoth­er win­dow on your work­sta­tion and doing the oper­a­tion there. So, I don’t regard that as inno­v­a­tive new use of mail-enabling of any­thing because cut and paste across win­dows on work­sta­tions is an equiv­a­lent func­tion­al­i­ty there. Mail-enabled appli­ca­tions will come into their own only when appli­ca­tions are exchang­ing and inter­pret­ing data on their own, using mail as a trans­port infra­struc­ture. And unfor­tu­nate­ly most of the appli­ca­tions where it’s real­ly inter­est­ing to do that require some degree of con­fi­dence in the authen­tic­i­ty of the mes­sage. An obvi­ous exam­ple is you do what’s called elec­tron­ic rout­ing and autho­riza­tion, where you take a document—let’s say it’s a trav­el voucher—and you send it to a mail­ing list, and the mail­ing list is accom­mo­dat­ed by a serv­er which routes the trav­el vouch­er to all the peo­ple who have to approve that vouch­er in the com­pa­ny. And they sign off on it in an authen­ti­cat­ed way. 

But we’re talk­ing about han­dling real dol­lars here, in a real sit­u­a­tion. And you absolute­ly have to have some degree of con­fi­dence in the integri­ty of that kind of a set up in order to real­ly deploy it wide­ly and make effec­tive use of it. Especially then if you’re going across the Internet, where as every­one most­ly knows, mail is not ter­ri­bly secure.

Malamud: Okay, well let’s turn our atten­tion to secu­ri­ty, then. I’ve noticed that there are actu­al­ly two elec­tron­ic mail efforts in the Internet. There’s Privacy-Enhanced Mail, and there’s MIME, and they appear to have been par­al­lel, sep­a­rate activ­i­ties. Why are there two sep­a­rate stan­dards look­ing at mail, and do they interoperate?

Freed: This is large­ly a result of time­frames and the way that the process put things togeth­er, and it has led to a rather unfor­tu­nate state of affairs which we are attempt­ing to rec­ti­fy. I per­son­al­ly believe that both MIME and PEM will come into their own only when they can avail them­selves of their coun­ter­parts’ ser­vices. MIME, which has no integri­ty check­ing, is great for send­ing around struc­tured infor­ma­tion and doing all these fan­cy appli­ca­tions. But when you can’t trust it it’s not useful. 

PEM on the oth­er hand has all of the secu­ri­ty capa­bil­i­ties but no struc­ture. And so you can send the data around but you don’t know what it is. So you real­ly need both of them, work­ing hand in hand and in con­cert, in order to get things to func­tion correctly. 

Malamud: Well if they do dif­fer­ent things then isn’t it just a mat­ter of sta­pling the two stan­dards togeth­er and reis­su­ing ​’em?

Freed: Um…to a cer­tain extent that is actu­al­ly true. Unfortunately there were design choic­es made that cause a cer­tain degree of con­flict between the two. The two stan­dards were devel­oped— MIME is a much younger effort. The Privacy-Enhanced effort has been going on for a lot longer. And it may appear that they cov­er less ter­ri­to­ry, but you also have to remem­ber that the debates and the dis­cus­sions around what con­sti­tutes secu­ri­ty and all are much more dif­fi­cult ques­tions to answer than how you come up with a struc­tur­ing scheme. So, the amount of time it took them to solve a lot of these prob­lems is prob­a­bly large­ly due to the dif­fi­cul­ty of the prob­lems. And yes they look like rel­a­tive­ly iso­lat­ed prob­lems and small prob­lems in scope, but they’re dif­fi­cult prob­lems nevertheless. 

The issue then came up that the PEM work had large­ly reached com­ple­tion short­ly after the MIME work was issued. And the choice was, do we want to hold up the PEM work which peo­ple are anx­ious­ly wait­ing for and have been for years, do we want to hold it up even more while we uni­fy the two things? Or do we want to get it out there and get peo­ple start­ed exper­i­ment­ing with the mes­sage integri­ty infra­struc­ture that they’ve been want­i­ng for so long. And the deci­sion, which was not mine to make, but it was nev­er­the­less tak­en to go ahead and push PEM through and wor­ry about the inter­op­er­abil­i­ty issues lat­er. And what then imme­di­ate­ly hap­pened, as is often the case in the Internet, is a doc­u­ment was imme­di­ate­ly com­posed and cir­cu­lat­ed almost at the same time as the PEM doc­u­ments were being issued as pro­posed stan­dards. A MIME/PEM inter­ac­tion doc­u­ment was com­posed by myself, and Marshall Rose, and Steve Crocker.

Malamud: What are exam­ples of some of the incom­pat­i­bil­i­ties between the two standards?

Freed: Well, a good exam­ple is let’s say I use Privacy-Enhanced Mail on top of some 8‑bit mate­r­i­al and I send it and I’m doing authen­ti­ca­tion only. So I’m not encrypt­ing. So I can basi­cal­ly send the stuff in clear text. Okay, so now what I have is I have a privacy-enhanced head­er on the material—actually, it’s in the body of the mes­sage. But we have the head­er and then we have the mate­r­i­al that’s been privacy-enhanced. And that mate­r­i­al let’s just say for the pur­pos­es of dis­cus­sion con­tains some 8‑bit char­ac­ters. And this goes zip­ping around the Internet. 

Now, it hits a MIME-compliant gate­way which detects the 8‑bit mate­r­i­al and says ​“I real­ly can’t trans­mit that on with­out check­ing to see how some­body else…” you know, whether the next hop can accom­mo­date it or not. It checks the next hop can­not accom­mo­date it; this is using let’s say the SMTP exten­sions. What it then does is it MIME encodes the mate­r­i­al so that it will pass through. So it goes hop hop hop, and then it hits the final des­ti­na­tion on the net­work. At which point the PEM agent, which again we’ll say for pur­pos­es of argu­ment is installed there, isn’t going to know about the encod­ing that was done in order to make the thing pass through the network. 

The best result you could hope for is that the mes­sage integri­ty check is going to fail, at which point you don’t know whether the thing is authen­tic or not. The worst case would be that the PEM imple­men­ta­tion becomes ter­ri­bly con­fused and won’t I won’t do any­thing right. Which is a pos­si­bil­i­ty depend­ing on the robust­ness of the software. 

Malamud: So PEM is mak­ing sure that your mes­sage was­n’t tam­pered with en route, and MIME explic­it­ly tam­pered with the mes­sage in order to get it to its destination.

Freed: Exactly. And so what you need to do is you need to have the PEM mate­r­i­al ini­tial­ly encap­su­lat­ed inside of MIME so that the agents can be aware of what trans­for­ma­tions occurred as the result of transport.

The way that the MIME/PEM doc­u­ment basi­cal­ly address­es this issue is we take mate­r­i­al and we we take all the encod­ings off of it and go back to a canon­i­cal for­mat. And then we apply the pri­va­cy enhance­ment tech­nol­o­gy to that. And then we re bun­dle it up in MIME all over again. And we send it off. And this has all the advan­tages that now the MIME trans­for­ma­tions are done on the out­er side of the privacy-enhanced inte­ri­or, so that there are no prob­lems or issues with what can hap­pen to it in sit­u­a­tions like what I described. 

Malamud: Well now the X.400 com­mit­tee when they were look­ing at design­ing a mes­sag­ing sys­tem they built secu­ri­ty in from the beginning.

Freed: Well… I would take some issue with that state­ment. They built secu­ri­ty in in the con­text that they have some stubs for where you could send around encrypt­ed body parts. To my knowl­edge, that work has nev­er been ful­ly fleshed out. There are also oth­er ways of doing secu­ri­ty exten­sions to X.400 which involve basi­cal­ly tak­ing the entire mes­sage and encod­ing the whole thing and send­ing it across the wire. And there also are transport-level authen­ti­ca­tion mech­a­nisms that you can use in var­i­ous ways. 

The X.400 com­mu­ni­ty, in deal­ing with secu­ri­ty, attempt­ed to address a broad­er range of prob­lems with secu­ri­ty issues. As a result they have end­ed up with a solu­tion which address­es some of the small­er prob­lems and pos­si­bly the more impor­tant prob­lems, depend­ing on your needs, less well. Privacy-Enhanced Mail with MIME allows you to do things like encrypt parts of a mes­sage but not oth­ers; or authen­ti­cate parts of a mes­sage but not oth­ers; or mix and match all these kinds of things in fair­ly com­pli­cat­ed ways, so that you can have a doc­u­ment that has sec­tions that only some peo­ple can read. You could have a doc­u­ment in two ver­sions, one of which con­tains the clas­si­fied mate­r­i­al, one of which does not. The one that does not has authen­ti­ca­tion applied, the one that con­tains the clas­si­fied mate­r­i­al is also encrypt­ed. There are all kinds of clever appli­ca­tions that you can use in mix­ing these things. The X.400 work real­ly does­n’t address a lot of those kinds of appli­ca­tions because they’ve nev­er real­ly fleshed out what it means to have an encrypt­ed sin­gle body part. 

Now, the flip side of that is that when you do these kinds of fan­cy things some­one can tam­per with the mes­sage en route and per­haps remove a body part from the mes­sage, and you will be unable, unless you have applied authen­ti­ca­tion around the whole mes­sage. You may not be able to detect that. The X.400 solu­tions solve that problem.

The X.400 solu­tions also solve a prob­lem which is of con­cern to some high-security sites, where they are less con­cerned with the mate­r­i­al being tam­pered with but with the leak­age of mate­r­i­al out of the site.

Malamud: Do you think X.400 has a future? Or is MIME gonna take it over?

Freed: Ha. Um… I have a cheap answer to that, which is I would­n’t’ve spent a sig­nif­i­cant amount of time in the last year build­ing an X.400 gate­way to MIME if I did­n’t think there was at least some future to X.400.

Will MIME take over com­plete­ly, no. Will X.400 take over com­plete­ly, no. We are doomed to a future of two stan­dards, in my opin­ion. There are enough gov­ern­ment require­ments and oth­er things that are essen­tial­ly admin­is­tra­tive fiats that have occurred that even if X.400 was a gen­uine­ly dread­ful trav­es­ty of jus­tice in every sense of the word, which per­haps some peo­ple believe but I don’t. Even if that were true, and every­one agreed on it, there would still be sites that were com­pelled to use it. And that com­pul­sion is not going away any­time soon, I don’t believe.

Malamud: But even with­out the com­pul­sion, is there room in this world for two sets of mail stan­dards? In an ide­al world, would—

Freed: In an ide­al world would there would­n’t be but in this world there’s got to be room. We are not going to be able to go with one. There are sites, there are sys­tems that sim­ply are inca­pable of using the X.400 facil­i­ties, and there are things miss­ing from X.400 that peo­ple need. Equivalently, there are sites that are not going to be able to use MIME, and there are—we hope noth­ing miss­ing from MIME that they need, but there prob­a­bly are things that we haven’t addressed.

Malamud: So in a messy world we need a messy set of solutions.

Freed: That’s exact­ly right. 

Malamud: Well there you have it.

Malamud: This is Internet Talk Radio, flame of the Internet. You’ve been lis­ten­ing to Geek of the Week. You may copy this pro­gram to any medi­um and change the encod­ing, but may not alter the data or sell the con­tents. To pur­chase an audio cas­sette of this pro­gram, send mail to radio@​ora.​com.

Support for Geek of the Week comes from Sun Microsystems. Sun, The Network is the Computer. Support for Geek of the Week also comes from O’Reilly & Associates, pub­lish­ers of the Global Network Navigator, your online hyper­text mag­a­zine. For more infor­ma­tion, send email to info@​gnn.​com. Network con­nec­tiv­i­ty for the Internet Multicasting Service is pro­vid­ed by MFS DataNet and by UUNET Technologies.

Executive pro­duc­er for Geek of the Week is Martin Lucas. Production Manager is James Roland. Rick Dunbar and Curtis Generous are the sysad­mins. This is Carl Malamud for the Internet Multicasting Service, town crier to the glob­al village.