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.

Help Support Open Transcripts

If you found this useful or interesting, please consider supporting the project monthly at Patreon or once via Cash App, or even just sharing the link. Thanks.