ACM ByteCast - Eric Allman - Episode 85

Episode Date: May 14, 2026

In this episode of ACM ByteCast, our special guest host Scott Hanselman (of The Hanselminutes Podcast) welcomes ACM Fellow Eric Allman, a foundational figure of the early Internet as the developer of Sendmail and its precursor Delivermail (for the original ARPANET) in the late 1970s at UC Berkeley. Sendmail is the mail transfer agent that powered a large portion of global email infrastructure through the formative years of the network and helped shape how messages move across the web. Allman is also an ACM Distinguished Engineer and was inducted into the Internet Hall of Fame in 2014. The conversation explores the origins of Internet email, the messy realities of building software that must operate at planetary scale, and what lessons today’s engineers can learn from the systems and design decisions that quietly underpin modern computing. Eric shares his work at UC Berkeley spanning a variety of domains, from user interfaces to neural networks. He and Scott touch on current AI capabilities, including their personal experiments in assistive coding with current models such as Claude, and discuss into the programming languages Python, C#, TypeScript, and JavaScript. Eric also shares candid thoughts on letting go of computing after retirement.

This is ACM Bytecast, a podcast series from the Association for Computing Machinery, the world's largest education and scientific computing society. We talk to researchers, practitioners, and innovators who are at the intersection of computing research and practice. They share their experiences, the lessons they've learned, and their own visions for the future of computing. I'm your host today, Scott Hanselman. Hi, I'm Scott Hanselman. This is another episode of Hansel Minutes in association with the ACM Bytecast. Today I have the distinct pleasure with chatting.

with Eric Allman. He is a computer programmer who developed Send Mail and its precursor deliver mail in the late 1970s at UC Berkeley. And in 1998, he and Greg Olson co-founded Send Mail Incorporated. How are you, sir? I'm doing pretty well. It's a lovely day. It is a lovely day. I woke up and I thought to myself, I'm going to try to get some sun and some vitamin D today. And I think that as programmers, I'm sure it's a constant balance between working on the thing that captures your attention and trying to get some sunshine and touching grass. Yeah, I'm looking out my window at the garden right now, so. So you are currently retired. I'm curious what made you retire. Some people just work until they finally fall into a hole. I think I would probably

have to say it had a lot to do with actually a lot of things. I retired basically during COVID. I was working at UC Berkeley for my third job at UC Berkeley, third and presumably last. And the last grad student on the project I was working on graduated, and the new grad students didn't show up because of COVID, but they were working together. And I had worked on a project with this group, and I had assumed they were going to leverage off the code that I had already written. and I and, you know, the other people in the group. And they didn't. They wanted to go in a totally different direction. So at some point I went, you know, they're paying me to do nothing or nothing of use.

I mean, I'm available, but that didn't sit well with me. And I was a retirement age. And my husband has a degenerative neural disease. So he's slowly losing the ability to walk and he wanted to do traveling as much as he could. Well, he still could. And so that seemed like another good reason to do it. And a bunch of things just came together all at once. And have you been able to do that traveling?

Yeah. Actually, we've done a couple of trips, several trips, actually, and we've got two other big ones coming out this year, including a train tour around Africa. Oh, wow. That's amazing. Yeah, it should be kind of fun. So I've been married for 25 years.

You're coming up on 13 this year. Is that right, sir? Actually, based on the beginning of our relationship, it's more like 44, 46, somewhere in there. Okay, that's amazing. About 179. Oh, wow, that's fantastic. And your husband Marshall is a well-known computer scientist as well.

And I'm curious because my wife and I, she is non-technical. She's a nurse. And we were writing a book on what it's like to be in a mixed marriage. And the joke is, the mixed marriage is, I'm technical and she's not. is two technical people in a relationship challenging? Do you chat about computer stuff, or do you just keep that part of the relationship separate? No, I think you could safely say that we chat about it.

I mean, he's got his stuff that he does. He's basically a file systems guy. I don't do file systems, but, you know, he doesn't do email. So actually, I won't do much email anymore. Sure. Getting far too much of it and so forth. I use it.

Yeah. But I'm out of the development cycle now. And in fact, my main gig is a 501C3 that I helped found called the Berkeley Historic Building Fund. And we raised funds for preservation of historic buildings, starting with the Hillside Club, which is just up the street for me. That's fantastic. Is that amazing, though, to let go of so much computing? I'm just really, as I start thinking about when I'm going to retire, do you just release it into the universe and you just say, I'm just not up on the latest stuff? Or did you cling to trying to stay current and stay up to date? Well, I've got a ability to concentrate, I guess you'd say it. I've done many, many things. So various stuff I've done. I started off really doing database systems and was the lead programmer on the Ingress project at UC Berkeley. That was my first university.

university job. And I've done sort of user interfaces to database systems, which I think I overreached for the ability of the technology to support it at the time. So that one never got out as a product. And I worked on neural networks at International Computer Science Institute for a while. So that's basically the same technology behind all the AI you see today. But back then, a megaflop was a really, really, really, really. fast machine and now it's like they're gigaflops. So that one, we got some interesting papers out of it. It was an academic organization, but the goal was continuous speaker independent speech recognition. And we never really got that to the point where it worked to our satisfaction. Now, of course, you know, my phone can do it. What does that feel like? Because I feel like I can see so much history, and I've only been doing this 35 years to be sitting at the tail end of this and go, wow, we really built a deep stack of stuff.

Like we're teeter tottering at the top of this pyramid of all the different protocols that came before us and all the pieces. And each additional layer of abstraction is indistinguishable from magic. And now I've got this pocket supercomputer that can recognize my voice and do stuff. Well, I actually started on the ARPANET

and that was a very different network. They only felt they needed 8-bit host addresses. Should be enough for everyone. Yeah, exactly. And what was it? Thomas Watson, I think, said the international market for computers is going to be about 100. It would be a mainframe on each country, and that would be it.

Each country would have their own mainframe, and maybe one per continent. It should be fine for everyone. Yeah. And so I've seen a lot of stuff happen. It's been kind of interesting. You know, when the network first appeared, we, I think, had this fantasy that we were going to bring understanding to the world. When everyone could communicate with everyone else, then, you know, wars would be gone and so forth and so on. We really had a concept that this is going to be a utopian future.

Now that it's the future, I don't think it looks quite as utopian as we used to think it would be. So that's why it's disappointing. It is disappointing. It does feel like eternal September really is kind of eternal at this point. There was a smaller kind of feeling of community and neighborhood in the early days. When I first got online in the late 80s, mid 80s, late 80s, it just felt like there was maybe a couple of thousand of us and we were all pretty pleasant. And now it seems somewhat chaotic. I actually have a book in the other room, which was essentially a phone book for the ARPANET slash early days of the internet with the name, address, and phone number of every user on the network.

And I'm in it. Yeah. I had a phytonet node for a time that I ran in my bulletin board and was, you know, making local phone calls, trying to not pay long distance phone calls and bouncing email rather around or phytonet mail at least for a time. I had a spiral notebook with kind of the 30 or 40 folks that I knew around. It felt like the ham. It was like ham radio, you know.

It was very small. Yeah, I guess Ham Radio still is. Yeah, I guess it's, well, because it's hard. You got to get a license, which is an interesting idea, in fact. Maybe they should have given us a license to send email. That would have solved a lot of problems. Yeah, indeed. Were you thinking planetary scale when you're building these systems,

when you and your compatriots were doing things like sending mail? I mean, email is kind of the original open adversarial system. It's open, it's federated, it's effectively unconstitutional, authenticated, or at least it was at the time, but it's also constantly attacked. And, you know, I'm curious, were you thinking this is for everyone for the world right now, or are you just building it for you and your friends? So there was already a network known as UUCP, and that was dial-up modems. And it turns out that I know the guy who first brought UUCP to Japan. I know the guy who brought the first UUCP to Europe. And so all that's a guy who brought the first UUCP to Europe. And so

Australia, actually. Is that Mike Lesk? No, Tozhaugan in the Netherlands, Robert Ells in Australia, and the point is we were very early on thinking there's no particular reason why this can't be an international thing, which is I think part of the reason we really thought it was going to make the world a smaller place, and everyone would discover that we're just people and so forth. Like I said, fantasies. Did it send mail is somewhat famous for being extremely configurable. Maybe a little complexity crept in there over time.

Do you see any parallels between send mail and sending mail and the kind of retries and cues and queues and store and forward? And then what we're seeing in agents and things like that in AI, do you think at all about how we're all just building the same thing over again in a different font? Actually, I hadn't thought about the comparison to AI, and I probably should have because the reason sendmail is so configurable is because it started before the internet. And so I was trying to get the local network at Berkeley, which was called Creatively enough,

Birknet, and your UCP and the ARPANET, and so forth, to talk to each other. And they all had different address syntaxes and different semantics and so forth. So Sendmail was designed to be the glue that would hold them together. And I had taken an AI course, and one of the things we talked about was production systems. And I said, you know, I know AI is maybe overkill for an email program, but production system looks like it fits really very nicely. And in fact, that's the core of the Sunmail configuration file. So it's been proven that it's turn complete, which probably doesn't need to happen. And the truth is, it's, I mean, the world pretty much agrees now that everything should be user at sign domain.

And nobody uses host bang, host bang user or host colon colon user or any of those others. So, yeah, it was basically setting up something where you could use effectively an AI technique. to route email. But it hadn't occurred to me anything comparing it to large language models. What do you think is a design decision in Sendmail that may have aged better than you expected? You don't really know if these things are going to be extensible, if they're going to hit some kind of a design wall. But looking back, is there a particular design decision that may be aged quite well? Well, I mean, there was a couple of things that I did kind of on the side. not as well known as my background with Sendmail is that I also did the first implementation of SISLog.

And I did that as a tool to use for DeliverMail, the predecessor to SendMail. And at the time, we didn't have interprocess communication and so forth. So I had to use things called MPX files. and then IPC came along and I converted it to use the new technology and so forth. That's proven to have real legs. I mean, there's dozens of implementations of SISLog, all basically at their core the same thing that I did as part of the implementing SEMail. Yeah, that's a great point.

I mean, SISLog, SISLG, D, these are something that is keeping track of everything for the last, what now. It's 20, 50 years, 60 years. And now on top of that, we have new ideas like open telemetry. And I'm seeing people shuttle their logs around with things like that. That seems like a pretty successful project. Yeah, well, it wasn't a project in and of itself. It was really just part of a much larger project. But I'm just thinking if there's anything else, to be perfectly honest,

the Send Mail rewriting rules, which are the things that people complain about the most, because they're big and complicated. Yeah. I totally understand them. But that was very successful because it made Sendmail be the glue that could hold the universe together as it was still in this nebulous state and still, you know, an astral cloud as opposed to a solid planet. So I think the uptake of email would have been much slower if people had been stuck

with sitting in these pools that didn't talk to each other. And the fact that send mail rules are recursively applied, I think some people have found that to be somewhat mysterious and frustrating, but that's kind of the genius of it. Yeah, I mean, you can use recursion, but it's not necessarily the necessary in order to do the job. Okay. But that level of flexibility was kind of the secret sauce. Yeah, it was also part of the thing that made it sometimes really challenging. challenging to debug. ACM Bytecast is available on Apple Podcasts, Google Podcasts, Podbean, Spotify, Stitcher, and Tune In.

If you're enjoying this episode, please do subscribe and leave us a review on your favorite platform. You said that you were doing AI. Like, AI had a moment, and I think AI has had a branding moment, but you were thinking about AI and your compatriots and your peers in the space were thinking about AI a very, very long time ago. did you all in the creating and thinking about neural networks see transformers and generative pre-trained transformers like coming? Was this a inevitable thing that would hit the hockey stick and then take off? Or did you kind of like wake up when chat GPT happened?

You said, oh, crap, they did it. More the latter. When we were doing it, we were just trying to get it to run fast enough to implement a relatively small neural network. We weren't using AI in general. I don't think we even ever called it AI. It was just no networks, you know, a name that seems to have gone out of favor, but still there at the core. You know, the new models are so much more sophisticated. They've got callouts to engines that are not, you know, stochastic parrots and so forth.

So I've actually started playing with Claude to do some coding stuff. I do school code some at home. And it's really stunning. The thing that really became clear to me is I can only absorb so much stuff in my head. And asking Claude to do these things, it said, oh, yes, there's already a library to do that. Here's how to use it. It's like, I've never heard of that library before. And you're right.

It does exactly what I need. So that alone has me. is a bit of a fanboy these days. It is extraordinary. I feel like Opus last October was the moment. And Claude Opus is an extraordinary model. And I kind of go back and forth

and I get a little bit of an analysis paralysis because I think to myself, maybe I'm a stochastic parrot. And maybe what I'm about to say to you is the statistically most likely next token based on the last 50 years of my life in the context window that I carry around with me. Maybe I'm just saying the next obvious thing.

So then you get all in your head about, are they parrots and they're just saying code because they've seen code or is there more there? Because I like the stochastic parrot like analogy. I think it is a good one because I refuse to believe that it is in any way conscious or creative. Here we start getting into the realm of philosophy as opposed to computer science. You know, what is consciousness anyway? I think you're qualified to have an opinion, though. I'm qualified to have an opinion, but it's just my opinion. and hence it's worth the price you paid for.

I will take it, though. So it certainly presents as though it's got some kind of consciousness. It carries on a discussion with you and so forth. But for example, I had cases where Claude will say, oh, you know, to fix that bug, you do this. And then there's something else, and Claude fixes that that puts the other bug back in. And I don't think that it exhibits as consciousness.

You know, Claude is very helpful as long as you use it effectively, but I can't see doing vibe coding where you just say, here, throw me some code, I'll test it, and tell you if it works or not, and if it doesn't try again. It is so funny, though, that we made programming languages and syntax, and we worked so hard to make ourselves able to explain ourselves able to express our intent clearly and unambiguously to the computer. And now we've created the prose compiler where one can just talk in English or any language. But if there is a lack of clarity,

it will fill that lack of clarity with the statistical mean or just randomness. It'll come up with something. It'll vibe it. And then we are frustrated when it doesn't work out because were we not clear or was it that it filled our lack of clarity with its randomness? And then I kind of waffle back and forth between, I don't want to remember all the details and I don't want to type all this stuff. It's still fun. It's still great. It's frustrating. I waffle back and forth between love and hate for AI-assisted coding. I can certainly understand that. Do you code primarily just for projects? Do you have an idea and you think I'm going to code this? Or do you like, like, you know, I know you have a garden. Do you like, oh, I want to code some IoT Internet of

things for the garden? Because I have all kinds of projects that I'm working on just to make the house run better. Well, I think this counts as making the house run better. I mean, Kirk and I have a wine cellar. And so at some point, a long time ago, I started keeping a database, which was just a flat file, parsable, but flat file. And at some point, I want something fancier. So I built myself a wine database with a GUI interface and so forth and so on. And periodically we want to tweak that. So there's that. There's some home automation things,

which involve code. I find myself writing in C++ for the Arduino and usually some other higher level language for general coding, stuff that's going to run on my server and what not. I use MQTT a lot for getting data around, so things don't have to be all on one piece of hardware. You can just talk to the broker and get what you need.

So, you know, Python has been probably my most common language, even more so than C, which is a little shocking because I was a dedicated C programmer for most of my career. It is surprising. I'm a C-sharp programmer, but ultimately any curly brace in a storm, you know, honestly. I think we could probably argue about whether we should use the almond indent style or whether, you know, with the correct way to do indentation and do curly braces. So I do C-sharp, but I keep falling back into Python. It's just kind of simple and easy. And when I do my home automation,

even just as a point of note, I'm a type 1 diabetic and I have an insulin pump and a sensor, and it all kind of runs on Python, and I've got Python systems that will go and check my blood sugar and notify my wife and tell me if things are going to be okay. And certainly I could have done it in any of the Curly Brace C languages, but I keep falling back into Python these days. Well, Python's added enough, basically a type system, that it's becoming,

the problem with Python when it's in pure dynamic mode is you never know for sure whether your code's debugged or not. And, you know, a strong type system can really help that. So I haven't really made the switch to typed Python. I'm aware that it exists, but I haven't read up on it enough

to know how to use it effect. Yeah, the same thing, of course, happening in JavaScript with TypeScript, where you kind of go back and forth between how strongly type. There's kind of a slider bar of typedness and how much you want to care as you move from JavaScript to TypeScript. I've never been a JavaScript fan. Let's just put it that way. Well, so I've always felt like I like to joke that JavaScript is not the language that we deserve, but it is the one that we have. So it's an imperfect language, much like English, but it's the one that we're all speaking, unfortunately. Yeah, well, some of the automatic type conversions between things that, you know, they are strings, but they might be numbers. So we'll just, you know, oh, it's a number now. And that's not what I always want. No, it's not. So you might enjoy TypeScript.

TypeScript, of course, came from Anders Heilsberg, who made Delphi, and he made C-sharp. So he was basically finding JavaScript equally objectionable as you were finding it and said, what if I applied what we know about C-sharp and strong typedness to JavaScript and really locked it down? So I think most of the JavaScript that people are writing these days has some common sense typing, I think. Well, thank goodness for that. Thank goodness for that, indeed, sir. What have you been doing over the last five or ten years when it comes to coding in like your own learning? I'm just trying to plan for the remaining years of my career,

and I'm wondering, will I just become a tinkerer, or will I go back to school and teach? Because I feel like I know a lot of stuff, and I want to share it with folks. And I'm wondering when you were doing your work in academia, if you found that to be really satisfying. Well, I do have to say the best part of my last job, working on a research project, again, was the students.

The students are just so bright and so creative and so forth. That definitely there was one of the students, I usually came in and more in the morning, I'm more of a morning person, I guess, and he would wander in around noon and immediately start talking with me about whatever it was he had been thinking about. And it's like half the time I didn't know what he was talking about, but it was so great being bombarded with this pretty much every day. So I haven't been seriously trying to keep up on, you know, the absolute most current version of everything, partially because, you know, I'm traveling a lot more.

And, you know, that feels like too much work to be something you do on vacation. It's going to be fascinating. I have a number of friends that are telling me that I'm fooling myself into saying that I'll retire, and that I may fall in and out of retirement, depending on what feeds my spirit and what works well for my family at the time. So it's going to be interesting to see if I can rise to the challenge. Yeah, well, I actually did retire several years ago, or at least I thought I had retired, and at some point got bored. And actually, that was right about the time I went back to the university. I got a call from somebody I had worked with in the past who I really liked

working with and he called and said, so I'm working in a new lab up here on campus and you've got seminars that you might find interesting and oh, by the way, free lunch. So I started going to those and ended up hanging out in a research group. Just, you know, they said, hang out if you want, our meetings right after the seminar. And at some point they said, you know, if you're going to be here this much, we really ought to pay you. So that was the beginning of my last job. That's a pretty good gig. I mean, if you can get snacks and also be paid for it and you enjoy the work, that's kind of the optimal scenario. It is kind of, yes.

Well, I admire you very much. I think that I hope you appreciate how much people in the circles that we run in appreciate you. You, of course, were an ACM fellow. You've done a huge amount of work. Your sister is also well-known and has been doing a lot of open-source software since the 80s. I hope that you give her our best and also to your husband, Kirk. We appreciate you all and the work that you've offered us over so many years. Thank you.

I do find it amusing that, you know, my husband, myself, and my sister all have Wikipedia pages. That's kind of a pretty cool flex. I mean, you have to admit at Thanksgiving dinner, you know, with the number of Wikipedia pages is probably three for a long table. Is there anyone else we should know about with a Wikipedia page in the family? Not that I'm aware of. Well, they need to get on your level and work a little harder then, don't they? Yeah, well, I have to admit, I feel like I've played most of my career and not really worked much. And that is the goal.

And if you can say that with a straight face, then you have lived a blessed life, sir. Yeah, except for email standards. I was doing standards for a while and decided I really, really did not like doing standards. Standards committees are a lift, I will admit. That is a challenge. Yeah. So I retired from that, but not from my job at the time. Thank you so much for spending time with us today and for chatting with me. It was very nice to meet you, sir. Very nice meeting you. Thank you. We've been chatting with Eric Alman. This episode of Hansel Minutes is in association with the ACM Bytecast, and we'll see you again next week.

ACM Bytecast is a production of the Association for Computing Machinery's practitioner board. To learn more about ACM and its activities, visit ACM.org. For more information about this and other episodes, please do visit our website at learning.acm.org slash bytecast. That's B-Y-T-E-C-A-S-A-S-T. Learning.acm.org slash bytecast.