Thanks to the work of Johnny and others, I’d like to say how impressed I am with the smoothness of the transition of the mailing list and HECnet bridge services. No bumps, no duplicates, and no loss of data. Great work Team! Ian

To be clear: Update runs only the mailing list server, not the network... -:) -P ----- Original Message -----

What kind of goodies where on (or supposed to be on) the machine? On 1/24/22 1:45 PM, Johnny Billquist wrote:

Any idea of how much storage?  I'd be happy to put it up on HECnet on one of my 20's. On 1/24/22 2:57 PM, Johnny Billquist wrote:

On 2022-01-24 19:45, Johnny Billquist wrote: The not-working-for-the-moment part is my fault, and sorry for that. The plan is to have the old archive available there, but there were other things that I considered to be higher priority (such as finishing up the the physical part of the move (the actual moving part, there's still a lot of work to do at Updates new place), new job etc). /Jesper

Where did the time go?  Well, for one thing, unless this is your full time job, it is far too easy to find other things that need doing.  This can be especially true about those pesky domestic chores that you can't seem to get off your 'Honey Do' list.  Also, being threatened with payment has a way of promoting focus, particularly when keeping the lights on and food on the table is involved. I keep toying with the idea of having some portion of the HECnet mailing list being implemented on HECnet.  What I mean is that most machines can run SMTP over DECnet.  At one point CU20B was forwarding a very large amount of Internet messages over CCnet.  I know that because I helped maintain the code.  Of course, I have not finished putting my changes back into MMAILR and friends, so I can't volunteer to do this.  Sigh... I know DEC could have done something similar for the internal corporate DECnetwork, but this wasn't in place when I was at Marlboro.  You had to go to a specific machine which had Internet access and send the email from there.  At one point, it was 2102, but that got moved to a 2020 in the Federal Systems group, which was a real hike from the Galaxy group.  I believe the general feeling at the time was that there was too much risk of DEC industry secrets being electronically exfiltrated.

Yes, connectivity issues could be a problem.  I would assume that, at a minimum, you'd have to know the email address of the person responsible for the area router.  And Johnny's... Regarding the email itself, what could happen is that the Internet email gateway could forward the email to an alias on whatever machine was doing the DECnet forwarding. To take the only example that I can remember well, the Tops-20-Wizards mailing list on SU-SCORE had a large list of subscribers.  One such member was Tops-20-Wizards(a)CU20B.COLUMBIA.EDU.#Internet.  Entries in that list (on CU20B) had some members like GG(a)CUCHEM.#DECnet, which was the system administrator on Columbia's Chemistry department's VAX, at the time which did not have either TCP/IP or SMTP.  CU20B (and any 20) can convert to and from VAXmail format. I think it's actually called MAIL11. It's completely unremarkable, doable and it handled a rather large amount of traffic without a lot of tinkering.  One nice thing about DECnet based SMTP/MAIL11 transport could be that your chances of getting spammed on HECnet are probably *a lot* lower.

I think that the mention of knowing about owners was in reference to knowing other ways to reach certain people when one's HECnet connection is broken, so that one can't receive HECnet list mail over the HECnet network for help in debugging one of the other. If I were to use an address on the HECnet network for my HECnet mailing list subscription, then I'd be putting all of my eggs in one basket when things stop working, if I didn't keep note of how to contact Johnny and my upstream connection's owner without using HECnet itself. -- Mark J. Blair <nf6x(a)nf6x.net> Blog: https://www.nf6x.net Git: https://gitlab.com/users/NF6X/groups HECnet: DOGPAK::MBLAIR Twitter: @nf6x

For the Tops-20 mailer, depending on the length of the outage, it might not require manual intervention.  This is true even for MAIL11 routing.  MMAILR contains three queues: 1. What to do now, 2. What to do 'later' and 3. What to do 'much later'. I believe 'later' is tomorrow and I know that 'much later' is at least a week.  It is only after failing out of all three queues that the delivery is failed.  The sender gets a message on each re-queue and on the 3rd failure, the entire message is dequeued and returned to the sender.  These notifications can also be copied internally to the person or group responsible for the mail system so they can investigate and remediate if the problem is local or otherwise notify network operations. If you are running my monitor patches, then the internal DECnet header will have the correct area.node number in it.  Otherwise, the mailer makes something up to put in the field.  That's right, it makes it up.  It doesn't matter what is actually in there because the number isn't used for anything when doing DECnet transport.  This is just to make integration with the other transport layers (such as TCP/IP, PUP and CHAOS) more straightforward. The DECnet node name is resolved at the time of the connection attempt.  If you are running my monitor patches and my rewritten monitor node table updater (SETND2), then the regular batch job should update the node to the new number in time for queue three to work if the failure is because of a node renumber. CCnet went through frequent additions, area splits and sometimes re-numberings within areas.  I can't remember how the node list was passed around. ------------------------------------------------------------------------ On 1/24/22 5:00 PM, Johnny Billquist wrote:

On 2022-01-24 20:08, Thomas DeBellis wrote: Yeah... I'm certainly toying with the idea of eventually having this handled on MIM. But no, I doubt most machines can run SMTP over DECnet. VMS, RSX and RSTS/E atleast had mail products talking over DECnet, but they use a protocol informally named MAIL11. No SMTP anywhere you could see. You've mentioned this before. It might be that TOPS-20 have such a thing, but it would only be able to talk this way with other TOPS-20 machines in that case. I'm fairly sure there were MAIL11-SMTP gateways at DEC. Maybe not when you were there, but I've seen plenty of evidence since. And VMS certainly had the capability of forwarding between the two protocols, as did Ultrix. That's when you see IN%"foo(a)bar.com" mail addresses in VMS. RSX, with my BQTCP suite can also forward mails between MAIL11 and SMTP, as people might have seen. If not, here it is again: If you want to send mail somewhere on the internet from HECnet, send the mails to: MIM::user@domain.name If you want to send mail from somewhere on the internet to a user on a machine on HECnet, sent the mails to: USER::HOST@mim.update.uu.se With the caveat that gmail incorrectly refuse to receive mails from HECnet because gmail looks at the sender address, and thinks "FOO::BAR" is an illegal username. Which is bad by gmail, since RFC 5321 explicitly says that receiving mail systems should not try to look at, or understand the username of the sender. And gmail also have the nerve of giving an error message back in this case claiming that the sending is violating RFC 5321 (while it in fact is gmail that is violating the RFC...) Most other systems do work, though. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol