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

Malamud: This is Geek of the Week. We’re talk­ing to Keith Moore from the University of Tennessee. Welcome to Geek of the Week.

Moore: Thank you, Carl.

Malamud: You’re one of the prin­ci­pal con­trib­u­tors to the to MIME, the mul­ti­me­dia Internet um, exten­sions for mail on the Internet. I’ve…totally man­gled reverse engi­neer­ing that acronym. Why don’t you tell us what MIME is?

Moore: Let’s see. I think it’s Multipurpose Internet Mail Extensions.” Maybe mes­sage exten­sions, but I don’t remem­ber the acronym either. Basically MIME is a way to put any­thing besides text in Internet mail. Internet mail for you know, ten plus years has sup­port­ed only text, and MIME was a way to take exist­ing Internet mail infra­struc­ture and encode var­i­ous oth­er kinds of objects besides text into text-only mail. And so it has an encod­ing scheme for non-text objects, and it has a typ­ing scheme that allows you to say what kind of object each of these things is.

Malamud: Let’s break these pieces down. As I under­stand RFC 822 mail, the orig­i­nal… Actually there’s two con­cepts. There’s RFC 822 mail, that’s the mes­sage. And then there’s SMTP, the mes­sage trans­fer pro­to­col. And as I under­stand RFC 822, it’s a series of head­ers, and a mes­sage body.

Moore: That’s right.

Malamud: Now, how did my MIME change that kin­da flat structure?

Moore: Well, let’s see. The first thing is all MIME mes­sages are RFC 822 mes­sages. As you said, RFC [822] has a series of head­ers of at the begin­ning of a mes­sage, and then a blank line, and then the rest of the mes­sage is text. The dif­fer­ence between a MIME mes­sage and an RFC 822 mes­sage is that in the MIME case, there’s a cou­ple of extra head­ers at the top of the mes­sage that say By the way, the rest of this mes­sage is in a spe­cial for­mat. And even though it looks like text to you, if you run it through a pars­er, then it can be split up into sev­er­al body parts and types etc., and you can read them.”

Malamud: So the body of this MIME mes­sage is all just plain old ASCII text? I can read it if— Even if I don’t have a MIME read­er, I can read this message.

Moore: If the com­po­nents of the mes­sage were text only yes, you can read them. And you would see a cou­ple of things that you might not under­stand, but basi­cal­ly you’d still be able to read the mes­sage. We tried to make it is backward-compatible and as friend­ly to an install base as we could. 

Malamud: What kind of body parts can we have inside of a MIME mes­sage now?

Moore: Well there are sev­er­al top-level class­es. There’s text, of course, so that you can still do text with­in a MIME mes­sage. There are body parts for images. There are body parts defined for audio—actually there’s only one defined right now; oth­ers will be defined. Let’s see, what else. There is a gen­er­al type of body part called appli­ca­tion” which is prob­a­bly some sort of application-specific data, a word proces­sor or spread­sheet, some­thing like that. And there’s a spe­cial type called mul­ti­part.” I’m sure you’ll want to ask me about that. Then there is…besides the sort of top-level things there are some things that are spe­cif­ic to the mes­sage sys­tem as a body part type for that. And—

Malamud: So we have kin­da basic components—text, audio, image, appli­ca­tion. And then mul­ti­part is a way of struc­tur­ing those indi­vid­ual com­po­nents inside of a message? 

Moore: That’s correct. 

Malamud: So I read one piece after anoth­er, or… How does this work if I have a mul­ti­part text and then an audio and then an image? Do I first read the text and then hear the audio?

Moore: I think it’s gen­er­al­ly expect­ed that things will be pre­sent­ed in order. But there is a con­tract called multipart/parallel” which says Present every­thing with­in this enclos­ing con­struct all at the same time” so that you can do some sort of crude mul­ti­me­dia things. We did­n’t try to solve the real mul­ti­me­dia prob­lem, but we tried to give a way to car­ry sev­er­al dif­fer­ent kinds of objects, and some­one can lat­er come along and define maybe a script­ing lan­guage that ties them all togeth­er so you can do real good presentation.

Malamud: And what about the exter­nal point­er body part? Why don’t you explain what that is?

Moore: Oh that’s right. So, let’s see. There’s a body part called message/external-body” and what hap­pens is if you see one of those things—if you’re a mail read­er and you see an external-body part, what it has instruc­tions to where to find the actu­al body part. The body part will not be actu­al­ly includ­ed in the mes­sage. When you read this thing will say By the way, this thing is over here for anony­mous FTP at this host. Go get it and present it to me.” The user agent will usu­al­ly ask you first Do you want to go get this thing?” but as a side-effect of read­ing the mes­sage will actu­al­ly go get it for you.

Malamud: So I could send you a mes­sage say­ing there’s a new radio pro­gram, and your read­er would said Do you want me to go get the audio?” So rather than send­ing you a 30-megabyte mail mes­sage, there can be a point­er to an anony­mous FTP area?

Moore: That’s right. And they’re doing this now for new RFCs that come out and new draft doc­u­ments that come out for Internet stan­dards. And—

Malamud: So if you’re on the announce­ments list it says Here’s an abstract. Do you want me to go get it for you?”

Moore: Right. 

Malamud: You talk about audio, and images, and things like that. Yet RFC 822 is sim­ply a text-based mes­sag­ing ser­vice. How do you put audio into text?

Moore: Oh. Well peo­ple’ve been doing it for years with things called UUencode, and btoa, and var­i­ous things for the Mac whose names escape me at the moment. Basically what you do is you say well, we’ll encode six bits per char­ac­ter, and we’ll use sixty-four dif­fer­ent char­ac­ters, and we split it up so that three octets get encod­ed in four char­ac­ters. The scheme we picked for doing it has cer­tain prop­er­ties. We did a sur­vey of var­i­ous kinds of mail sys­tems in the world and which char­ac­ters they would allow through the mail sys­tem there. We weren’t try­ing to solve the prob­lem just for the IP-connected Internet. There are peo­ple all over the world who are using 822 mail who aren’t actu­al­ly using TCP/IP. Or SMTP, which is what impos­es some of the restrictions. 

And so we came up with a set of sixty-four char­ac­ters that actu­al­ly is the same set that was used by PEM for the same rea­sons. And we encode things as those char­ac­ters and send them as plain ASCII char­ac­ters. Basically upper-case let­ters, lower-case let­ters, dig­its, and three or four others.

Malamud: So I get this audio file. Let’s say I do put it in my elec­tron­ic mail mes­sage. And I’ve got to have some read­er go through and my audio read­er has to first decode the mes­sage back into bina­ry data—

Moore: That’s correct.

Malamud: —and then play it for me. Why not just send the bina­ry data?

Moore: SMTP, specif­i­cal­ly, and almost every oth­er mail trans­port are not binary-transparent. SMTP requires, back from days of old, that you not send mes­sages with the most sig­nif­i­cant bit of your octet set. And it basi­cal­ly assumes that the mes­sage will be ASCII text. 

Furthermore, var­i­ous SMTP imple­men­ta­tions that would han­dle the mail, that get a mes­sage and route it and for­ward it onto some­where else, have been known to change the way ends of lines are rep­re­sent­ed, or strip out cer­tain char­ac­ters. Various oth­er mail trans­ports have oth­er lim­i­ta­tions. They may trans­late ASCII and EBCDIC or back again on the oth­er end. So there are var­i­ous things that basi­cal­ly pre­vent you from send­ing arbi­trary sequences of octets through [crosstalk] in the mail.

Malamud: But don’t a lot of mail­ing systems—cc:Mail for exam­ple lets you attach a bina­ry file. Why not allow those peo­ple to con­tin­ue doing that work and just say well you know, if you reach a place that does­n’t do 8‑bit…you lose. You just can’t get the mes­sage. Are we forc­ing our­selves into a low­est com­mon denom­i­na­tor, and is that a bad thing?

Moore: No, I think we actu­al­ly hope that one of these days you’ll have ubiq­ui­tous bina­ry trans­port. There is a way in MIME to say This is a bina­ry object. Let it go through.” But no one real­ly expects to use it any time soon. Maybe in a very local envi­ron­ment. In your mes­sage trans­port, if you have a bina­ry mes­sage and say okay We’ll con­vert it lat­er, we’ll encode it in some­thing” and maybe some­one else lat­er on decides Well, in fact we can do bina­ry from here on out. We’ll take this encod­ed thing and con­vert it back to bina­ry,” what you get is a lot of var­i­ous trans­port agents doing things like mung­ing the mes­sage in var­i­ous ways. And if it gets cor­rupt­ed, you don’t know who did it. It’s very hard to track down. So, I think the gen­er­al wis­dom is don’t try to use this yet. We’ll hope that SMTP and oth­er trans­ports can be upgrad­ed, and maybe some­day there’ll be enough of this infra­struc­ture in place where you can use it.

Malamud: Looking at text mes­sages, if we can get back to that area. US ASCII is real­ly the char­ac­ter set that was defined as the way you struc­ture a mes­sage. Yet in oth­er coun­tries obvi­ous­ly we have things like accents, let alone oth­er char­ac­ter sets. How did you tack­le that prob­lem with­in the MIME body parts?

Moore: Well basi­cal­ly what we did, for the text/plain” body part—you call it plain text, in MIME it’s called text-slash-plain”—there is a para­me­ter that goes with it that says what char­ac­ter set is used. And if it’s ASCII it’s treat­ed just like it always has been. Basically we took all the sort of ISO stan­dard char­ac­ter sets that were com­plete­ly spec­i­fied and defined para­me­ters for those also. And sev­er­al new ones have been added since we actu­al­ly did the MIME stan­dard. There’s been stuff for Japanese, and Korean, and Russian I believe, and Hebrew, based on con­ven­tions that were used in the net envi­ron­ments that dealt with those languages.

Malamud: Now, a lot of these oth­er char­ac­ters sets don’t fall with­in US ASCII by def­i­n­i­tion, right, or we would­n’t be using em.

Moore: That’s correct.

Malamud: Do we have to take that and encode this the same we would a bina­ry file so that I have to decode the mes­sage before I can read it?

Moore: No. There’s actu­al­ly two dif­fer­ent encod­ings. And one is sort of opti­mized for things that con­tain a lot of ASCII char­ac­ters, and in that encod­ing which we call quoted-printable,” if it does­n’t fall with­in a cer­tain range of char­ac­ters that are in the ASCII set, you encode it with equals [=] and two hex char­ac­ters. And hope­ful­ly that does­n’t hap­pen very often. That will work for some lan­guages that…for which they most­ly use ASCII char­ac­ters. Spanish is prob­a­bly a good exam­ple. I don’t want to speak for them, but I sus­pect that it’s not too obnox­ious in Spanish. And if you—

Malamud: So José” is J O S…quote equals some­thing something…

Moore: Yeah. Equals and two hex char­ac­ters. And hope­ful­ly the accents don’t occur very often. And as far as I can tell, this has been sort of a mixed reac­tion thing. But we all know it’s some­thing for the time being. We’re hop­ing that SMTP 8‑bit trans­port can become more ubiq­ui­tous also.

Malamud: So I get a mes­sage and my read­er is smart enough and it knows the char­ac­ter set. If I’m in Spain I expect to get a lot of these, my read­er’s con­fig­ured, and it just shows it to me in the right font. If I car­bon copied some­body in some oth­er coun­try who isn’t pre­pared to deal with oth­er char­ac­ter sets—let’s say the US, right, we would see some­thing different.

Moore: I think that’s the assump­tion, that the peo­ple who speak a lan­guage will have sup­port for the char­ac­ter sets that are nor­mal­ly used for that language.

Malamud: Now, one of the things I like in my mail read­er, I like to look at my head­ers. I don’t just go read, read, read, read,” I say delete, delete, delete.” In order to do that I need to know who it’s from. You’ve talked about how we take care of char­ac­ter sets inside of the mes­sage. What about the head­ers? Is there a way of putting an accent in my name in the from” field, for example?

Moore: Yeah there is, and it’s a sep­a­rate spec­i­fi­ca­tion. It was real­ly a sep­a­rate prob­lem from the one of hav­ing to encode things with­in the doc­u­ment. Because head­ers always always always have to be ASCII, every­one has to parse them. If you can’t deal with a cer­tain thing with­in a body part in the mes­sage, you can just ignore it or tell the user you can ignore it or what­ev­er. But, the head­ers them­selves, if you break those things then you break the whole mail system.

So, there was a dif­fer­ent way of encod­ing things with­in head­ers, and there are com­pli­cat­ed restric­tions on when you can use it and exact­ly where in a head­er it can appear and things like that.

Malamud: So can my domain name be josé now?

Moore: Absolutely not. Domain names have to be ubiq­ui­tous. Everyone has to be able to type it in. And unfor­tu­nate­ly, for some peo­ple that lim­its them to ASCII char­ac­ters, and a cer­tain sub­set of those. This is some­what of a prob­lem for peo­ple who are using LAN-based mail sys­tems where they’re used to being able to have accent­ed char­ac­ters and such. And com­mu­ni­cat­ing this prob­lem is some­thing that we face. It’s like why if you… I think we under­stand that like Telex address­es have a lim­it­ed alpha­bet and peo­ple are used to that, but they’re not used to it for their own envi­ron­ments which are being gate­wayed into the Internet.

Malamud: So where in the head­er can I use these new char­ac­ter sets?

Moore: Basic—

Malamud: The sub­ject” field would seem like an easy one.

Moore: Right. So basi­cal­ly any­where that there is plain text in the head­er. But you might have to read the spec­i­fi­ca­tion— I had read RFC 822 to under­stand where it’s defined to be that. Subject is an obvi­ous place, and yes you can put what­ev­er char­ac­ter sets and such in there. Your per­son­al name that appears before your address in the mes­sage head­er is anoth­er place you can do it. And gen­er­al­ly with­in com­ments that appear in the head­er. But for instance, you’re specif­i­cal­ly disallowed for putting it in the trace infor­ma­tion that might be used to diag­nose problems. 

Malamud: We talked about how RFC 822 works over a vari­ety of dif­fer­ent trans­port mech­a­nisms, from SMTP to UUCP to…you know, you can send it into the MCI Mail world and it works. In the core Internet that uses SMTP, what kind of mod­i­fi­ca­tions have you made to sup­port this kind of emerg­ing rich­er mes­sag­ing structure?

Moore: Well, we’ve antic­i­pat­ed that if you were send­ing text-only mes­sages, you know, several-hundred K is an upper bound. You don’t usu­al­ly have huge huge huge text doc­u­ments going over email. 

On the oth­er hand as soon as you can start send­ing things like images around, then mes­sages on the order of sev­er­al megabytes are to be expect­ed. And we don’t expect how­ev­er that every­one’s SMTP can deal with these things. You may not have enough disk space, you know. You were expect­ing text-only mail and all of a sud­den you get this huge thing dumped on you. 

So, one of the exten­sions for instance is a way to say Here’s a mes­sage that’s so big, can you deal with it?” And the SMTP on the oth­er end can say Sorry, I can’t deal with this so don’t even both­er try­ing to send it to me.” 

Malamud: What if I’m send­ing to four peo­ple with­in an SMTP session?

Moore: Uh—

Malamud: I say Mail to this kind and to this guy and to that guy.”

Moore: If they all have the same SMTP serv­er, pre­sum­ably it could…it might want to reuse it for all of them and say I don’t have enough disk space.” The spec­i­fi­ca­tion actu­al­ly allows you to say I’m sor­ry I can’t send it to this guy. You may have to find anoth­er way to get it here but I’ll take it for this oth­er one.” And…that gets kin­da com­plex in terms of error recov­ery, but it was felt that it was necessary.

The way mail works, when you send it out it goes to one SMTP serv­er and it may decide to route to anoth­er one for some of the recip­i­ents and yet a third one for oth­ers. So, try­ing to find a path­way for each recip­i­ent that can han­dle the vol­ume of data required could be kind of difficult.

Malamud: Now, these SMTP exten­sions… Do you just assume that the oth­er side has it? How do you know whether these peo­ple can speak the new SMTP, or whether they’re speak­ing the old SMTP?

Moore: Oh, okay. So, there is a nego­ti­a­tion mech­a­nism. When you first talk to an SMTP tra­di­tion­al­ly you said HELO” and you give your domain name. And it comes back and says Sure, okay. And in fact my domain is this.” You’re just intro­duc­ing your­self. There’s a new word that says EHLO[pron. e‑hello”] which is extend­ed helo,” which says Don’t just tell me what your domain is, also tell me what all the capa­bil­i­ties you have are, which exten­sion you sup­port.” And you get back a list. And you’re only allowed to use those exten­sion if the serv­er end says Yes, I sup­port these.”

Malamud: Okay. So basi­cal­ly if the per­son talk­ing to you says HELO” they’re a 7‑bit. If they expect you to talk— Uh, not 7‑bit, excuse me. They’re a nor­mal SMTP world. If the per­son says E H L O instead, then you know that they speak extend­ed SMTP and if you also do it, you respond that way.

Moore: Right. Actually, I think we try to be care­ful about that in that the serv­er real­ly isn’t sup­posed to make any assump­tions about clien­t’s capa­bil­i­ty even if the client says EHLO.” But the client can make assump­tions about the server’s capa­bil­i­ty if the serv­er responds to EHLO.

Malamud: Okay. In addi­tion to things like size lim­its, are there oth­er things in the extend­ed SMTP?

Moore: The most impor­tant one right now is the 8 bit exten­sion that basi­cal­ly says we can break the old rule for SMTP that said we’re not allowed to send…what we call 8‑bit char­ac­ters. They’re all 8‑bits, but char­ac­ters for which the most sig­nif­i­cant bit in the octet is 1. And the European char­ac­ter sets and…all of the non-ASCII char­ac­ter sets, prac­ti­cal­ly, require this. And so, you can now query the remote SMTP if it sup­ports this exten­sion there’s no need to have the text be encod­ed in 7‑bit form, it can be in 8‑bit form. You still have to encode non-text objects, prac­ti­cal­ly speak­ing. But this—

Malamud: Well why if you’re allow­ing 8‑bit text to come through over this trans­port aren’t you allow­ing 8‑bit audio, or 8‑bit image, or some­thing else? If both sides are will­ing to do it.

Moore: Uh, there are peo­ple work­ing on pro­pos­als for that. The rea­son the cur­rent exten­sion does­n’t have it I believe is there’s a lot of mail soft­ware out there that it is easy to upgrade…in fact, mail soft­ware has done this in vio­la­tion of stan­dards for years—to go ahead and pass 8‑bit text. But when you start say­ing arbi­trary sequences of octets and we want to be able to pass these clean­ly, that requires major changes to exist­ing soft­ware. And so the cur­rent 8‑bit exten­sion is some­thing that we thought that peo­ple could graft in with­out a lot of trouble.

Malamud: How old is MIME now? How many years has it been around?

Moore: Uh, I have to think about it. MIME has been at Draft Standard state for…two thirds of a year, three quar­ters of a year, some­thing like that. Before that it was a Proposed Standard state for…about the same amount of time. So I guess now it’s…something like two…

Malamud: It’s a cou­ple years old.

Moore: A cou­ple years old. Yeah.

Malamud: Is any­one using it?

Moore: Uh, yeah. People are using it all over. 

Malamud: Do ven­dors ship it?

Moore: There are some ven­dors that ship it and more com­ing. And I’ve seen more and more of this every day. It’s becom­ing a fair­ly com­mon­place thing.

Malamud: Now, with the X.400 world, they start­ed in 84 and then 88 and then the 92. It’s been a twelve-year development/deployment. Is MIME— Is it gonna take twelve years to get MIME out as a generally-accepted set of mail extensions?

Moore: No, I don’t think so. I think— I would…be…very care­ful about mak­ing esti­ma­tions of install base. I’m sure oth­er peo­ple have done that and have real sta­tis­tics. But basi­cal­ly you already have a MIME-capable mail trans­port. You don’t need, if you have send­mail or any oth­er SMTP or any­thing that’s already used to deal­ing with 822, you don’t have to change the trans­port. And fur­ther­more, if you have any Internet mail 822-capable user agent, you don’t have to change the user agent, you can receive MIME doc­u­ments. If they’re text, you can deal with them. 

Then there are var­i­ous patch­es to exist­ing mail user agents for the 822 world that maybe don’t present an ide­al user inter­face but allow you to read and send MIME mail mes­sages. And then there are sort of exter­nal pro­grams if you get a MIME mail mes­sage from some­one and you did­n’t quite know what to do with it, there are pro­grams that deal with just the prob­lem of ship­ping files around in MIME. So there are var­i­ous things that you can do to be MIME-capable and MIME-aware until you get real­ly real­ly nice user agents along. And as I said, there’s no need to upgrade the trans­port at all. So in that sense, we already had a large infra­struc­ture of mail trans­port that was already in place that we could use. And I think that gives us a leg up on try­ing to com­pete with X.400—if that’s—you know, some peo­ple view that’s what we’re doing, and some peo­ple say we’re just try­ing to make the world safe for mul­ti­me­dia email.

Malamud: Keith Moore, we’ve been talk­ing about mul­ti­ple body parts, and audio, and image, and char­ac­ter sets. And these are things that were in the 1984 X.400 spec­i­fi­ca­tions. Why did you rein­vent the wheel? Why not just take X.400 and…you know, maybe just fix it?

Moore: Huh… Well, that’s a very good ques­tion. I think for us to have tak­en… We start­ed with the assump­tion that we have to be friend­ly to our install base. That any pro­pos­al which would say We’re gonna rein­vent a new mail sys­tem” was a non-starter. It’s very hard to deal with mul­ti­ple incom­pat­i­ble mail sys­tems. And if we had said that’s we real­ly need to do, I think we would have said okay, well what can we do as far as pro­fil­ing X.400 or tweak­ing X.400 or what­ev­er to make it work. But we did­n’t believe we need­ed to do that. We real­ly— We saw that it was pos­si­ble. We had exis­tence proofs of mul­ti­me­dia mail sys­tems that ran on top of 822 that worked very well, that had you know, min­i­mal impact on the install base, at least for the com­mu­ni­ties they’d been test­ed on, And we saw that we could take our exist­ing Internet mail sys­tem and not throw it away, not have to deal with mul­ti­ple mail sys­tems and have to wor­ry about who’s on which mail sys­tem when you’re send­ing some­one a piece of mail. And—

Malamud: But you do have to now wor­ry about gate­ways to the X.400 install base. Is that an issue?

Moore: We would’ve had that in any case because X.400 was­n’t going to go away, either. If you work with email for very long you quick­ly come to real­ize that gate­ways are very evil things. You have to have them and they do allow you to get con­nect­ed, but they’re a roy­al pain. So we knew we’d have to do X.400 gate­way­ing. At the same time, giv­ing the Internet world capa­bil­i­ties equiv­a­lent to the X.400 world real­ly makes your gate­way­ing prob­lem eas­i­er. There’s now been defined a set of map­pings between MIME body parts and X.400 body parts, and basi­cal­ly you can now map all the com­mon things. If you want a fax body part you can map that. If you want IA5 text that maps to ASCII text, it always has. And you can map a mul­ti­ple body part mes­sage in the MIME world to a mul­ti­ple body part mes­sage in the X.400 world. And it turns out that you can define in MIME a way to encap­su­late X.400 body parts, and in X.400 you can define a way to encap­su­late MIME body parts. And real­ly now it becomes fea­si­ble to estab­lish a map­ping for all these dif­fer­ent ser­vices. And so I think at least some of the X.400 com­mu­ni­ty’s pret­ty hap­py with this.

Malamud: In the X.400 world one often hears X.400 and X.500 talk togeth­er, and in fact when I talk to peo­ple about the Internet, one of their first ques­tions is How do I find some­body’s elec­tron­ic mail address?” Have you giv­en any thought to, do we need a direc­to­ry? Is it X.500? Is it the DNS? Will MIME work with­out a way of find­ing addresses?

Moore: Um, it’s cer­tain­ly a prob­lem. We cer­tain­ly need some sort of gen­er­al way to find email address­es in the grow­ing Internet. That does imply a direc­to­ry serv­er, and one that’s dis­trib­uted, and one that scales well. And it may be that X.500 can be made to work. I’m not so up on the scal­ing prob­lems, but I kind of hear sort of groans when­ev­er I men­tion X.500 to peo­ple, so I think it at this point is not a prob­lem that solves well for the sort of world-wide Internet or things on that scale. 

Malamud: But we can do email with­out a direc­to­ry. I mean, we are…

Moore: Right. We have oth­er means of dis­cov­er­ing peo­ple’s address­es. And that works for now. I think it would’ve been a bad idea to tie MIME to any kind of direc­to­ry ser­vice and say We must have this direc­to­ry ser­vice in place before we can use MIME.” And there have been at var­i­ous time sug­ges­tions that we do some­thing like that, that to say you know, you should­n’t send some­one a mes­sage that con­tains GIF files or JPEG files or audio files with­out know­ing that they can deal with it. And you know, maybe that’s true except that if we real­ly made our email sys­tem depen­dent on the abil­i­ty to dis­cov­er these things, then we would­n’t have an email system.

Malamud: I found a easy way to han­dle the prob­lem of can they deal with JPEG files, I send em one and if they can’t they call me up. [mim­ics some­one roaring]

Moore: Right. Or you send a mes­sage say­ing, Can you deal with a JPEG file. I don’t want to send this to you.” And sure, it’s infor­mal and it requires man­u­al inter­ven­tion, but.

Malamud: Speaking of deal­ing with some­thing, one of the things that I’ve looked at in the MIME stan­dards is this appli­ca­tion” body part in which I’m send­ing you a Perl script, or I’m send­ing you PostScript. Is this secure? I mean, what are the secu­ri­ty impli­ca­tions of send­ing arbi­trary appli­ca­tions over messaging?

Moore: Um. I like to think of the Internet worm and there was a fin­ger serv­er that peo­ple exploit­ed. It turns out if you sent a long enough com­mand to a fin­ger on a par­tic­u­lar host, then you could actu­al­ly gain priv­i­leged access to the sys­tem. And the rea­son that this was the case is that you basi­cal­ly had a net­work pro­to­col serv­er that did noth­ing but take this string that it got from the client in and feed it to an ordi­nary user pro­gram that was not designed to be a net­work pro­to­col serv­er. You would just feed it to the local fin­ger pro­gram and return what­ev­er it gave back. 

And if you start tak­ing text that comes from you don’t know where, and feed­ing it to a PostScript inter­preter or a spread­sheet or a word proces­sor, in many many cas­es there is some way to export a hole that can do some­thing unkind to your sys­tem, maybe exposed to secu­ri­ty risks, or maybe you know, expose… It might be able to to trash your sys­tem, it might be able to let some­one else get into your sys­tem, it might be able to expose data that’s on your sys­tem to some­where else. There are lots of ways this can hap­pen. And yeah, it’s a gen­er­al problem.

Malamud: Is this some­thing that if some­one sends you an appli­ca­tion you should­n’t exe­cute it?

Moore: Well

Malamud: If a stranger sends you an application?

Moore: If a stranger sends you an appli­ca­tion and you know, you don’t know that the appli­ca­tion is safe against this kind of attack then…yeah, you want to think very care­ful­ly about doing it or do it in some sort of safe envi­ron­ment. The oth­er thing is you don’t real­ly know whether some­one send­ing you some­thing is a stranger or not. We don’t have authen­ti­ca­tion mech­a­nisms in place, at least in the gen­er­al case.

Malamud: While you were devel­op­ing MIME there was anoth­er set of mes­sag­ing pro­to­cols, known as the Privacy-Enhanced Mail, mov­ing for­ward that does solve the authen­ti­ca­tion, and mes­sage integri­ty, and con­fi­den­tial­i­ty of the mes­sages. How does the PEM work relate to MIME? Do you have to run PEM or MIME? Can you run both?

Moore: There are pro­pos­als for inte­grat­ing the two, basi­cal­ly call­ing a PEM object just anoth­er type of MIMe object. The nice thing about that is if you have a MIME mail read­er, then you should be able to just plug in the PEM mod­ule, basi­cal­ly. And when you get one of these things your mail read­er will call the PEM mod­ule to decrypt the mes­sage or cer­ti­fy that yes it real­ly did come from the per­son who it says it came from, or some­thing like that. That has­n’t quite gone out the door yet but it’s being worked on.

Malamud: So there is a body part of type mes­sage” and the sub-type is…type PEM.”

Moore: Right. 

Malamud: It’s that simple.

Moore: It’s a lit­tle more com­pli­cat­ed than that, as secu­ri­ty always is, but that’s the basic idea. 

Malamud: Well how long is it gonna be before we have secure elec­tron­ic mes­sag­ing on the Internet?

Moore: That depends on a lot of things that have noth­ing to do with pro­to­cols. Security is this is real touchy issue that involves licens­ing restric­tions, and export rules, and dis­tri­b­u­tion of trust and key exchange, and all those things are hard prob­lems. And you know, it’s easy to encrypt mes­sages. It’s hard to get the keys across. And uh—

Malamud: It’s even hard­er to get export con­trols approved.

Moore: That’s right. So there’s so many bar­ri­ers to get­ting a real secure mail sys­tem in place. And—

Malamud: Do we need one now?

Moore: Oh, absolute­ly. Any time you’re deal­ing on some­thing on the order of tens of mil­lions of users, you’re going to need some sort of secu­ri­ty thing. There’s going to be some­one out there that wants to mess with you. It does­n’t take many peo­ple on an Internet, it’s very easy to reach out and touch some­one. So, yeah, you need em.

Malamud: There you have it. We’ve been talk­ing to Keith Moore, and this has been Geek of the Week.

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 net­work is the com­put­er. 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 mail 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 Producer 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.