Yes, the Tops-20 mail transport system is designed to do exactly what your RSX mailer does. Some history:

At the time of the DECnet SMTP work, we were getting multiple 20's (we got up to six of them), and needed to send email between them. The vast majority of the systems on CCnet at the time were 20's, CMU had five of them and Case Western had at least one.

Another consideration was that you couldn't (directly) use the ARPAnet (NCP) or early Internet (TCP/IP) unless you had some sort of a DoD contract. As a result, many 20's were running versions without ARPAnet (or Internet) support to save on memory. So you could route email, but you couldn't directly send it from certain hosts.

The most mature, robust and featureful email system at that time was SMTP. To this day, a great deal of infrastructure uses a variant of it, ESMTP. The sole VAX on CCnet at the time only spoke MAIL11 and, after some analysis, the feeling was that it was lacking certain functionality as a platform, although at this juncture, I don't recall what that would have been and I'm wondering if some of it was just plain NIH, anyway. There was blistering, virulent ill-will going around.

Having the 20 speak MAIL11 would have required an entirely new component to crack the protocol and convert everything and, at the time, there was no local knowledge to do this nor any to be found on any ARPA/Internet host.

Enhancing the 20's email system to handle DECnet was straightforward enough. It was changed to use primary input (.PRIIN) and output (.PRIOU) instead of handling the JFN directly. These are special JFN's to refer to the user's logged in terminal, so they are equivalent to Unix's STDIN and STDOUT, respectively. A small server (SMTJFN) was written to catch the incoming Internet email requests, fork a MAISER and perform an SPJFN% to change its console. All that had to happen was another small server for DECnet, which was also done (SMTDCN).

At some point, the Tops-20 MAIL11 component was written, VMAIL.MAC.

What changed everything was DNS, which came along very late in the game. I don't recall that the last DEC release of Tops-20 has DNS. PANDA has the MIT implementation, CHIVES and another module was written called HSTNAM to handle the different transports. This is what uses that .#Internet suffix, which I've never been particularly fond of. As a matter of fact, I think it is, dare I say it, kind of a hack.

The obvious place to put the hosts' transport capabilities is in a resource record (RR) in CHIVES, which already knows about CHAOS. Well, at seemed obvious... Except, I couldn't find any documentation on it at all and I stared at the C source code for days. I was shocked to not even be able to find the places where it parsed the value. I couldn't even figure out what a RR should look like. I mean, I've written entire embedded file systems in C, it's not like I don't know the language (which I've used for going on five decades, now)...

Another problem was that PANDA really expects a host to be in the DNS and if it doesn't find it, it waits about three minutes before CHIVES times out the GTDOM% JSYS and HSTNAM falls back to using the pre-DNS JSYS interface (GTHST%) to look in SYSTEM:HOSTS.TXT. This is the inverse of what Windows and Unix do, which is check the hosts file, first. I spoke to MRC about it several times but got nowhere. My options to get fast email were: set up my own DNS server and use that, come up with and document RR's or do some coding. I eventually tracked down the CHIVES author and found out enough to set up my own local RR's.

But this all seemed too complex, too arcane and just plain cruel to a beginning hobbyist. So, since I couldn't do it the 'right way', I fixed it by doing what I did know how to do:

I changed HSTNAM to prefer SYSTEM:HOSTS.TXT (GTHST%) over CHIVES (GTDOM%) for Internet host name resolution,
I enhanced Tops-20 to return some additional information for .NDVFY (creating the .NDVFX function),
I changed HSTNAM to prefer NODE% .NDVFX name resolution over CHIVES,
I changed HSTNAM to prefer DECnet transport to TCP/IP, and
Made some other modifications to handle simple pre-DNS addresses, so I could type SLOGIN@VENTI2 instead of SLOGIN@VENTI2.something.somethingelse.mobettasomethingelse.#Internet.

I mean, who wants to be bothered with all that baloney, even if it is right? Yech!! And that three minute wait which was driving me nucking futz was gone.

It triggered a bug in MMAILR which I needed to modify the debugger to fix and while I've fixed DDT, I haven't finished up some other things to turn back to MMAILR. I'm getting closer, though.

I can't send Internet email from a 20 anymore, all my ISP's want ESMTP because of the spam 'problem'. So it goes...

On 9/30/23 6:59 PM, Johnny Billquist wrote:

Thing is - nothing else does SMTP over DECnet, so that feature is not very useful.

But for the rest of it, sounds like T20 would be possible to use the same way I use my mail daemon under RSX.

But notation is a bit easier with the RSX host involved. Sending a mail from anywhere on HECnet to anywhere on the internet:

MIM::user@host.domain

Sending mail from anywhere on the Internet to a host on DEChet:

node::name@mim.stupi.net

But with all that said, unfortunately Google is broken, and you cannot send mails from nodes on HECnet to any gmail account. Google refuses mails where the from-address have '::' in the username. And mails will have a from address of the form "node::user"@mim.stupi.net

Johnny

On 2023-09-30 19:55, Thomas DeBellis wrote:
Tops-20 will do both MAIL11 and SMTP over DECnet (which I use every day). It will also route email between the two mail transport types as well as route SMTP from DECnet to Internet and the other transports it can use. Columbia routed a lot of email this way.

It recognizes what to do based on the address specification. If you do FOO@BAR.#DECnet, then it will use SMTP. If you do BAR::FOO, then it will use MAIL11. It will also route Internet mail to DECnet; let's suppose you have user FOO on VMS DECnet host BAR, which has connectivity to Tops-20 Internet host BAZ, domain EDU. To send email to from an Internet host, you'd specify "BAR::FOO"@BAZ.EDU.#Internet"., or something along those lines (I forget). Same thing with BITnet and (somehow) with Unix "!" (Bang) addresses.

The modules which do this are MAISER, MMAILR and HSTNAM. Locally, there was a split at some point to modules name DMAISER (or some such) for the DECnet related functionality, part of which was first done at Columbia. Not all that code made it back into the PANDA sources and the monitor needed some minor enhancements to provide some information that HSTNAM wanted.

It's on my list of things to finish debugging, one problem being that doing so tickled a limitation in the debugger (DDT) that I had to fix. Typical rabbit hole.

On 9/30/23 12:54 PM, Johnny Billquist wrote:

I should probably mention that it's possible to get mails both over HECnet, using DECnet MAIL-11, and Internet, using SMTP. (I do like to promote the silly software that I've written, including that mail package for RSX that talks both, and acts as a gateway between them...)

Johnny

On 2023-09-30 17:59, Wilm Boerhout wrote:

Thanks Johnny! Sign me up for the updates mail please. It really simplifies my update scripts.