UUCP for VMS

[Bill Gunshannon]

Assuming at least some here saw my recent comments about UUCP,
I have a question.

I recently acquired an O'Reilly book on UUCP to refresh my memory
on setting up and running UUCP Systems. It has an interesting
comment in the appendix on "UUCP for Non-UNIX Platforms".

UUCP for VMS
DECUS UUCP is an implementation of UUCP for the DEC Vax system. We
mention it here for historical purposes only, since there has been
no new development since 1992 and the software does not run on OpenVMS.
The packagae is available at ftp://ftp.uu.net/systems/vms/uucp and
runs under VMS 5.4-x or VMS 5.5.

Just out of curiosity, is there really anything that drastic that
would have changed to make the software no longer usable under VMS?

I am thinking of taking a look at it with the hope of getting a VMS
system up on the network. And, who knows, maybe some VMS users might
be happy to move back to the days when SPAM wasn't a problem. The
number of VMS users worldwide is probably an easily manageable number
so that they could all communicate with each other using a network that
doesn't suffer from many of the "advantages" of SMTP.

bill

[Robert A. Brooks]

On 4/8/2017 12:17 PM, Bill Gunshannon wrote:


> UUCP for VMS
> DECUS UUCP is an implementation of UUCP for the DEC Vax system. We
> mention it here for historical purposes only, since there has been
> no new development since 1992 and the software does not run on OpenVMS.

> The packagae is available at ftp://ftp.uu.net/systems/vms/uucp and
> runs under VMS 5.4-x or VMS 5.5.

There is an inconsistency above. The name "OpenVMS" came about (I think)
around the time of VAX/VMS V5.4. Wikipedia claims that it first showed
up around VAX/VMS V5.4-2, which sounds about right.

So, it's likely that DECUS UUCP *will* run on OpenVMS VAX V5.5.

--
-- Rob

[Bill Gunshannon]

Yes, but would it run on any modern version of OpenVMS or has something
been changed that is likely to obsolete older software? I always thought
VMS prided itself on not obsoleting old systems.

In any event, if I find the time to setup one of my VAXStations with a
7.something version of VMS I might find it interesting to try a port of
Taylor UUCP (because I would want UUCP over IP and not over a telephone
line.)

bill

[Michael Moroney]

Bill Gunshannon <bill.gu...@gmail.com> writes:

>I recently acquired an O'Reilly book on UUCP to refresh my memory
>on setting up and running UUCP Systems. It has an interesting
>comment in the appendix on "UUCP for Non-UNIX Platforms".

Does anyone still use UUCP?

>Just out of curiosity, is there really anything that drastic that
>would have changed to make the software no longer usable under VMS?

I'm going to guess that they were thinking going from VMS->OpenVMS was
a huge step from a major OS overhaul or something. Or perhaps going
from VAX to Alpha was. VAX->Alpha was largely recompile and go for non
system software, with the major exception of Macro-32. You had to do a
lot of things to make the stricter Alpha compiler happy in many cases.

[Bill Gunshannon]

On 4/8/2017 12:44 PM, Michael Moroney wrote:
> Bill Gunshannon <bill.gu...@gmail.com> writes:
>
>> I recently acquired an O'Reilly book on UUCP to refresh my memory
>> on setting up and running UUCP Systems. It has an interesting
>> comment in the appendix on "UUCP for Non-UNIX Platforms".
>
> Does anyone still use UUCP?

Other than there the fact that there is a group (called HECNET for a
reason I don't know) who have a UUCP Network running much like the
people who have the DECNET Network running, there is also an effort
right now to setup a simulation of the original 80's USENET for the
upcoming (2019) 50th Anniversary of UNIX. It is going to be comprised
of mostly emulated system with historical names but is also accepting
modern, non-historical, systems. I have my first system up running
Taylor UUCP on FreeBSD. Not historical, but then my interests run
more along the lines of UUCP as practical solution to a real world
problem than just a museum artifact. I would hope people here would
also understand the notion that old does not necessarily mean bad and
sometimes a solution has been before our eyes for ages but jaundice
prevents us seeing it.

>
>> Just out of curiosity, is there really anything that drastic that
>> would have changed to make the software no longer usable under VMS?
>
> I'm going to guess that they were thinking going from VMS->OpenVMS was
> a huge step from a major OS overhaul or something. Or perhaps going
> from VAX to Alpha was. VAX->Alpha was largely recompile and go for non
> system software, with the major exception of Macro-32. You had to do a
> lot of things to make the stricter Alpha compiler happy in many cases.
>

Interesting. So you think no one actually tried it just assumed VMS
and OpenVMS were not necessarily the same OS. (I actually thought the
OpenVMS moniker came much later than V5.4 but if Wiki said it, it must
be true and accurate. :-)

I'll have to start by just trying the DECUS version to see what it does.

bill

[Arne Vajhøj]

On 4/8/2017 12:22 PM, Robert A. Brooks wrote:

> On 4/8/2017 12:17 PM, Bill Gunshannon wrote:
>> UUCP for VMS
>> DECUS UUCP is an implementation of UUCP for the DEC Vax system. We
>> mention it here for historical purposes only, since there has been
>> no new development since 1992 and the software does not run on OpenVMS.
>
>> The packagae is available at ftp://ftp.uu.net/systems/vms/uucp and
>> runs under VMS 5.4-x or VMS 5.5.
>
> There is an inconsistency above. The name "OpenVMS" came about (I think)
> around the time of VAX/VMS V5.4. Wikipedia claims that it first showed
> up around VAX/VMS V5.4-2, which sounds about right.

I thought it was 5.5-2 that got the "Open" when POSIX support was added!?

Arne

[Stephen Hoffman]

On 2017-04-08 21:04:32 +0000, Arne Vajh j said:

> I thought it was 5.5-2 that got the "Open" when POSIX support was added!?

"What became confusing is that the OpenVMS name was introduced first
for OpenVMS AXP V1.0 causing the widespread misimpression that OpenVMS
was for Alpha AXP only, while ‘‘regular VMS’’ was for VAX. In fact, the
official name of the VAX operating system was changed as of V5.5,
though the name did not start to be actually used in the product until
V6.0."



--
Pure Personal Opinion | HoffmanLabs LLC

[Scott Dorsey]

Bill Gunshannon <bill.gu...@gmail.com> wrote:
>Just out of curiosity, is there really anything that drastic that
>would have changed to make the software no longer usable under VMS?

A bunch of new protocols were added around that time to support some of
the high performance modems that became available around then. So there
were a lot of changes to the code base. If you just intend on using g
or i protocol and nothing else you might be fine.

I believe there were also a lot of changes made to MAIL-11 at the time
too, so compatibility with the mail system may be an issue.

>I am thinking of taking a look at it with the hope of getting a VMS
>system up on the network. And, who knows, maybe some VMS users might
>be happy to move back to the days when SPAM wasn't a problem. The
>number of VMS users worldwide is probably an easily manageable number
>so that they could all communicate with each other using a network that
>doesn't suffer from many of the "advantages" of SMTP.

I think you'll find that running uucp in this day and age is a nightmare,
in part because spam is a problem. And if you think it's a problem with
a fat pipe, it becomes a huge one when your fat pipe is run down into a
narrower one.

There are still reasons to run uucp today; we had a customer until about
two years ago who was served off a satellite in molnya orbit who only had
connectivity in short bursts, during which time we would batch transfer
mail to them. That customer now has a modern network connection, though,
and every day there are fewer and fewer reasons.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Bill Gunshannon]

On 4/8/2017 6:45 PM, Scott Dorsey wrote:
> Bill Gunshannon <bill.gu...@gmail.com> wrote:
>> Just out of curiosity, is there really anything that drastic that
>> would have changed to make the software no longer usable under VMS?
>
> A bunch of new protocols were added around that time to support some of
> the high performance modems that became available around then. So there
> were a lot of changes to the code base. If you just intend on using g
> or i protocol and nothing else you might be fine.

True, but all the other systems will still talk the old protocols so
that doesn't really break anything.

>
> I believe there were also a lot of changes made to MAIL-11 at the time
> too, so compatibility with the mail system may be an issue.

Unless it turned mail into something other than a 7bit clean text based
system it should not have affected it either. But as a side note, are
you saying VMS Mail is MAIL-11? I thought that was an RSX thing.

>
>> I am thinking of taking a look at it with the hope of getting a VMS
>> system up on the network. And, who knows, maybe some VMS users might
>> be happy to move back to the days when SPAM wasn't a problem. The
>> number of VMS users worldwide is probably an easily manageable number
>> so that they could all communicate with each other using a network that
>> doesn't suffer from many of the "advantages" of SMTP.
>
> I think you'll find that running uucp in this day and age is a nightmare,

Having run both SMTP based and UUCP based mail systems I think I can
safely say UUCP is a breeze. Took me less than an hour to have it
up and running. Taylor UUCP (not in the default FreeBSD installation)
and PostFix (also not in the default FreeBSD installation but much
better than Sendmail).

> in part because spam is a problem. And if you think it's a problem with
> a fat pipe, it becomes a huge one when your fat pipe is run down into a
> narrower one.

Ummmm... Spam isn't a problem at all on a UUCP network. It happens at
most once and then the peer is gone. It is also possible to actually
make the offender pay, which can not be done on the Internet as it
exists today. Why is it that intelligent people can't understand how
UUCP Networks actually function (compared to how email is moved on the
Internet using SMTP)?

>
> There are still reasons to run uucp today; we had a customer until about
> two years ago who was served off a satellite in molnya orbit who only had
> connectivity in short bursts, during which time we would batch transfer
> mail to them. That customer now has a modern network connection, though,
> and every day there are fewer and fewer reasons.

The availability of highspeed networks has eliminated the only downside
that UUCP ever had. How would you like to have a network that let you
discuss VMS, communicate with other VMS developers, users and VARS with
no possibility of Spam or phishing attacks or any kind of spoofed
emails or news articles? And, no, BITNET isn't coming back. (Although I
still wish I could find a copy of the J-Net software in source for
playing with.)

bill

[Bill Gunshannon]

Thank you, once again, Stephen. Much greater detail but closer to what
I remembered.

bill

[Scott Dorsey]

Bill Gunshannon <bill.gu...@gmail.com> wrote:
>On 4/8/2017 6:45 PM, Scott Dorsey wrote:
>
>> in part because spam is a problem. And if you think it's a problem with
>> a fat pipe, it becomes a huge one when your fat pipe is run down into a
>> narrower one.
>
>Ummmm... Spam isn't a problem at all on a UUCP network. It happens at
>most once and then the peer is gone. It is also possible to actually
>make the offender pay, which can not be done on the Internet as it
>exists today. Why is it that intelligent people can't understand how
>UUCP Networks actually function (compared to how email is moved on the
>Internet using SMTP)?

But we don't live on a uucp network. We live in the IP world, and unless
you are going to have an isolated mail system with no connection to the
real world, you're going to be taking mail from the big IP pipe and stuffing
it down that uucp connection.

And when you stuff spam from the big pipe into the little pipe, the little
pipe clogs up fast.

[Bill Gunshannon]

On 4/8/2017 8:12 PM, Scott Dorsey wrote:
> Bill Gunshannon <bill.gu...@gmail.com> wrote:
>> On 4/8/2017 6:45 PM, Scott Dorsey wrote:
>>
>>> in part because spam is a problem. And if you think it's a problem with
>>> a fat pipe, it becomes a huge one when your fat pipe is run down into a
>>> narrower one.
>>
>> Ummmm... Spam isn't a problem at all on a UUCP network. It happens at
>> most once and then the peer is gone. It is also possible to actually
>> make the offender pay, which can not be done on the Internet as it
>> exists today. Why is it that intelligent people can't understand how
>> UUCP Networks actually function (compared to how email is moved on the
>> Internet using SMTP)?
>
> But we don't live on a uucp network.

That's a choice that can be remedied. Why does everyone automatically
assume it has to be one or the other?

> We live in the IP world, and unless
> you are going to have an isolated mail system with no connection to the
> real world, you're going to be taking mail from the big IP pipe and stuffing
> it down that uucp connection.

Or, you could have two where one of them is loaded with spam which you
can't aggressively filter without the very real danger of missing emails
that me be important, especially if your a business. But you can have
two separate networks that allow some of your traffic, possibly your
most important traffic protected. Right now, the way I am reading and
replying to this I am using a mail client that shows me three different
"folders". Two of them are totally separate news servers. One carries
all the real stuff and periodically some spam slips thru even though
they do their best to prevent it. Of course that leaves open the
question, "What articles have I not seen because their spam filters
mistook it for spam and deleted it?" And then I have a third folder
is email on a machine that I use for mailing lists. I have two other
email servers I use and I could just as easily put them in there, too
but I prefer not to at this time. Accessing info from multiple sources
is common today. Why not put it to good use? The resources needed to
setup UUCP are trivial. As I stated, I setup a FreeBSD 11.0 box and
in one hour was on a UUCP network doing email and news. (both completely
separate from the Internet) At the FreeBSD site you can even get a
ready to run vhd file so that you could set it up on a VM anywhere.
(I have a copy running on VirtualBOX on the system with all my other
test and research systems.) Nothing to it.

How does this apply to c.o.v, you ask?

Simple, really. My concept of reviving UUCP works best in what one
would see as "Independant Email Domains". The VMS Community is one
such Domain. There are multiple ways of setting it all up but because
of the nature of the Domain it can be quite simple. Let's start by
having some soul volunteer to be a hub. (VSI? Island? Hoffman Labs?
or even some individual but preferably not someone at home using
dyndns.) And then all the other members of the VMS Community establish
a UUCP link with the hub. And you know have a private email domain
strictly for the business of discussing VMS, doing VMS business or any
other thing the Community sees as desired. No SPAM. Connectivity is
determined by the admin at the hub. You grant, restrict or remove users
based on the norms of the Community. You could even run news as well
with your own collection of groups. Instead of just c.o.v you could
have any number of finely targeted groups for discussing technical
issues, business issues, social issues (like who is buying the beer, not
what political system is best). Of course, it doesn't need to be single
hub. It an be multi-hub or even full-mesh, but the hub structure ends
out having the least overhead at the network level.

Think about it.

bill

[Paul Sture]

From the "VMS at 20" book.

1991

• OpenVMS name change announced.
• NVAX, DIGITAL’s fourth VAX microprocessor, implemented in 0.75-micrometer
CMOS technology; shipped in VAX 6600 systems.
• OpenVMS V5.5 shipped.
• DIGITAL and Microsoft Corporation announced alliance allowing
Microsoft Windows to retrieve and exchange data with local area
network servers running DIGITAL PATHWORKS software.
• DECnet Phase V announced.

and

OpenVMS/AXP V1.0 November 1992 - Alpha is here!

• Support for new Alpha processors DEC 3000 Models 400, 400S, 500 & 500S DEC
4000 Model 600 DEC 7000 Model 610
• Based on VMS V5.4
• DECmigrate for translating VAX images
• MACRO-32 compiler
• No clusters, no RMS journaling, no shadowing, no SMP

OpenVMS/VAX V6.0 June 1993
• Support for new processors – VAX 7000 Model 650/660, VAX 10000 Model
650/660
• Rationalized and Enhanced security (Level C2 compliance)
• Multiple queue managers across cluster
• HELP/MESSAGE utility
• Support for ISO 9660 CD-ROM format
• Adaptive Pool Management
• SYSMAN cluster wide SHUTDOWN and startup logging
• Cluster wide Virtual I/O cache
• Extended physical and virtual addressing
• Protected subsystems
• DECnet/OSI
• DECwindows XUI replaced by DECwindows Motif


--
The First of April: The only day of the year that people critically
evaluate news stories before believing them.

[Tom Allebrandi]

Bill Gunshannon <bill.gu...@gmail.com> wrote:
>
> UUCP for VMS
> DECUS UUCP is an implementation of UUCP for the DEC Vax system. We
> mention it here for historical purposes only, since there has been
> no new development since 1992 and the software does not run on OpenVMS.
> The packagae is available at ftp://ftp.uu.net/systems/vms/uucp and
> runs under VMS 5.4-x or VMS 5.5.

I was one of three people who worked on DECUS UUCP. One guy did the UUCP
'g' transport work, another guy hooked in a USEnet newsreader, and I did
the hooks to VAX Mail.

My suspicion is that it might still be possible to get the UUCP
transport up and running on the latest OpenVMS. I don't recall that
there was any kernel mode stuff in the transport.

I have no idea what shape the USEnet hooks and newreader are in. I'm
guessing that the newsreader we used has been long since abandoned.

From the work I did, I would tend to doubt that the hooks to VAX Mail
still work. VAX Mail at that time had a callout API that let you
provide alternate transports. The callout API was implemented kind of
like a Windows DLL or a *nix .so would be today. The hooks may still be
there, but I'd bet they changed over time.

I'm certain that DECUS UUCP ran on VMS 5.5-2. That's what is still on my
Microvax-II, and I got the MV2 so that I could work on DECUS UUCP and
some stuff I was doing on CMUIP towards the end of 1993. (I've got the
OpenVMS licenses from HP, I've just never gotten around to the upgrade.
I'm also not 100% sure that the version of CMUIP I have on there will
talk to anything. That would make things a little difficult to get the
installation packages onto the machine and moved off to TK50's.)

I've got a vague recollection that the guy who did the UUCP transport
did get it running on an Alpha. But I could be wrong. I did drop him a
note about this thread and maybe he'll check in.

For myself, and I think for the others, by the 1992/93 timeframe we had
simply moved on to other things. I went to a company that was not doing
any VAX work -- it was all PC based. The transport guy was in the
process of moving his focus from VMS to Windows NT and I don't recall
where the USEnet news guy ended up.

There are people still oferring UUCP service via dialup or over the
Internet. SDF Public Access UNIX in Seattle (sdf.org) is one such place.

I don't what parts I've still got laying around. (I've got 16 TK50's
with various things on them.) If anyone decides to take a crack a DECUS
UUCP, feel free to drop me a line.

Cheers!

--- tom allebrandi
wyr...@ytram.com or t...@sdf.org

[jamieeh...@gmail.com]

Wow, where to begin?

Of course DECUS uucp ran just fine on "OpenVMS" on VAX hardware. As far as I know, it was never ported to VMS on Alpha, let alone Itanium. (And I would like to think that if it had been, someone would have let me know, maybe even sent me a source tree...) So that's why the binaries won't run on modern hardware. I can't think of a reason why they shouldn't run on the latest version of VMS that runs on VAX hardware, or on emulated VAX hardware. Except that...

MAIL-11: The DECUS uucp interface to VMS Mail (developed by Tom Allebrandi as a fork of the PMDF foreign mail protocol interface by Kevin Carosso) does not directly participate in the MAIL-11 protocol, so changes to that protocol shouldn't affect it. (n.b.: If your VMS 5.5 system can still exchange DECnet email with a current VMS system, they're apparently compatible.)

But, the foreign mail protocol interface (the thing that's invoked by wrapping a To: address in uucp%"f...@bar.com", and that lets you receive mail from the UUCP transport with a replyable From: line, instead being "from" the account under which the transport runs) may well have changed. We did have an idea for how to do the mail interface differently, requiring nothing running with BYPASS and no funny mail interface code.

Also re. mail - the uucp mapping project was shut down long ago, so you'd be back to crafting bang-paths. Do you really wanna do that?

I frankly don't see the point of bringing up uucp today, but I certainly won't stand in anyone's way if they want to try it. I have no time for it and don't even have an Alpha or Itanium system to test it on.

Jamie Hanrahan
j...@cmkrnl.com

[jamieeh...@gmail.com]

On Saturday, April 8, 2017 at 5:39:38 PM UTC-7, Bill Gunshannon wrote:
> > But we don't live on a uucp network.
>
> That's a choice that can be remedied. Why does everyone automatically
> assume it has to be one or the other?

Because we have a tcp/ip network that is cheap, far faster, etc., etc.

> Simple, really. My concept of reviving UUCP works best in what one
> would see as "Independant Email Domains". The VMS Community is one
> such Domain. There are multiple ways of setting it all up but because
> of the nature of the Domain it can be quite simple. Let's start by
> having some soul volunteer to be a hub. (VSI? Island? Hoffman Labs?
> or even some individual but preferably not someone at home using
> dyndns.) And then all the other members of the VMS Community establish
> a UUCP link with the hub. And you know have a private email domain
> strictly for the business of discussing VMS, doing VMS business or any
> other thing the Community sees as desired. No SPAM. Connectivity is
> determined by the admin at the hub. You grant, restrict or remove users
> based on the norms of the Community.

But, see, you don't need the uucp transport layer for that at all. All you need are mail servers that only talk to certain other mail servers, for the mail traffic in their domain.

> You could even run news as well
> with your own collection of groups. Instead of just c.o.v you could
> have any number of finely targeted groups for discussing technical
> issues, business issues, social issues (like who is buying the beer, not
> what political system is best). Of course, it doesn't need to be single
> hub. It an be multi-hub or even full-mesh, but the hub structure ends
> out having the least overhead at the network level.

You can do this right now with news servers and news reader software. Again, the transport layer is irrelevant. ANU NEWS, the news reader that we pulled into the DECUS UUCP package (thanks to Mark Pizzolato for writing the "glue" to UUCP and figuring out how to hook it all up), is already also a fully fledged netnews server too. And (just like Unix news software) it didn't need uucp; in fact it was originally put on the DECUS tapes in a form that would exchange news over tcp/ip (with both other ANU NEWS systems and Unix news servers). The only reason to ever use uucp for news was if you didn't have tcp/ip internet available.

I don't know if it was ever built for Alpha binaries either.

And again, see, you don't need uucp to set up a "private news domain". You just configure your news clients and servers to only talk to the other clients and servers you choose.

(It also became a complete dog when the number of saved news items in a newsgroup became too large, thanks to some unfortunate dependencies on the implementations of Files-11. Again, I never heard word of an improved version.)

Jamie Hanrahan
j...@cmkrnl.com

[Bill Gunshannon]

I think I will. Probably try to get a VAXStation up early this week
and if I have success I will try something newer on an Alpha. But, if
I have any success at all it is still just a stepping stone as Taylor
UUCP would be the target. Phone modems are the dead issue in this
technology. Need to be able to do UUCP over IP.

bill

[Bill Gunshannon]

On 4/9/2017 4:01 AM, jamieeh...@gmail.com wrote:
> On Saturday, April 8, 2017 at 5:39:38 PM UTC-7, Bill Gunshannon wrote:
>>> But we don't live on a uucp network.
>>
>> That's a choice that can be remedied. Why does everyone automatically
>> assume it has to be one or the other?
>
> Because we have a tcp/ip network that is cheap, far faster, etc., etc.

I'm not talking about replacing tcp/ip. UUCP can run on top of it.
Just like SMTP, FTP and SSH.

>
>> Simple, really. My concept of reviving UUCP works best in what one
>> would see as "Independant Email Domains". The VMS Community is one
>> such Domain. There are multiple ways of setting it all up but because
>> of the nature of the Domain it can be quite simple. Let's start by
>> having some soul volunteer to be a hub. (VSI? Island? Hoffman Labs?
>> or even some individual but preferably not someone at home using
>> dyndns.) And then all the other members of the VMS Community establish
>> a UUCP link with the hub. And you know have a private email domain
>> strictly for the business of discussing VMS, doing VMS business or any
>> other thing the Community sees as desired. No SPAM. Connectivity is
>> determined by the admin at the hub. You grant, restrict or remove users
>> based on the norms of the Community.
>
> But, see, you don't need the uucp transport layer for that at all. All you need are mail servers that only talk to certain other mail servers, for the mail traffic in their domain.

In your example it becomes one or the other. Without massive white-
listing and black-listing (a major administrative nightmare) how do
you propose top keep trusted email separate from the rest of the
Internet with all its spam and malware?

>
>> You could even run news as well
>> with your own collection of groups. Instead of just c.o.v you could
>> have any number of finely targeted groups for discussing technical
>> issues, business issues, social issues (like who is buying the beer, not
>> what political system is best). Of course, it doesn't need to be single
>> hub. It an be multi-hub or even full-mesh, but the hub structure ends
>> out having the least overhead at the network level.
>
> You can do this right now with news servers and news reader software. Again, the transport layer is irrelevant. ANU NEWS, the news reader that we pulled into the DECUS UUCP package (thanks to Mark Pizzolato for writing the "glue" to UUCP and figuring out how to hook it all up), is already also a fully fledged netnews server too. And (just like Unix news software) it didn't need uucp; in fact it was originally put on the DECUS tapes in a form that would exchange news over tcp/ip (with both other ANU NEWS systems and Unix news servers). The only reason to ever use uucp for news was if you didn't have tcp/ip internet available.
>
> I don't know if it was ever built for Alpha binaries either.
>
> And again, see, you don't need uucp to set up a "private news domain". You just configure your news clients and servers to only talk to the other clients and servers you choose.
>
> (It also became a complete dog when the number of saved news items in a newsgroup became too large, thanks to some unfortunate dependencies on the implementations of Files-11. Again, I never heard word of an improved version.)
>
> Jamie Hanrahan
> j...@cmkrnl.com
>

I am merely offering an alternative with much less administrative
effort to clean up the morass that is the current status quo.

I would have commented more on what you said but working with the 500
character lines was just more than I could deal with today.

bill

[Simon Clubley]

On 2017-04-08, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>
> I am thinking of taking a look at it with the hope of getting a VMS
> system up on the network. And, who knows, maybe some VMS users might
> be happy to move back to the days when SPAM wasn't a problem. The
> number of VMS users worldwide is probably an easily manageable number
> so that they could all communicate with each other using a network that
> doesn't suffer from many of the "advantages" of SMTP.
>

$ set response/mode=good_natured

While you are at it, why don't you try resurrecting FidoNet, ARC file
compression, uuencode attachments and VT52 terminals ? :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Bill Gunshannon]

On 4/9/2017 7:49 PM, Simon Clubley wrote:
> On 2017-04-08, Bill Gunshannon <bill.gu...@gmail.com> wrote:
>>
>> I am thinking of taking a look at it with the hope of getting a VMS
>> system up on the network. And, who knows, maybe some VMS users might
>> be happy to move back to the days when SPAM wasn't a problem. The
>> number of VMS users worldwide is probably an easily manageable number
>> so that they could all communicate with each other using a network that
>> doesn't suffer from many of the "advantages" of SMTP.
>>
>
> $ set response/mode=good_natured
>
> While you are at it, why don't you try resurrecting FidoNet, ARC file
> compression, uuencode attachments and VT52 terminals ? :-)
>

Because FidoNET was never a good idea. It was yet another example of
someone doing something that already existed and doing it badly.

Arc isn't better than anything available today. UUCP is much better
than SMTP.

Uuencode is actually still used. Ships as part of the base of FreeBSD
and I would be surprised if the same wasn't true for Linux. It didn't
go away, MIME just added other forms of encoding that were better in
certain conditions.

I can't say about VT52 as by the time I stopped using Televideo the
VT100 was already the standard. I still use VT100 (in emulation) all
the time today. GUI's have never eliminated character cell terminals.
But then, anyone here would know that.

I am not trying to push old for the sake of old I am trying to
demonstrate that newer is not synonymous with better and sometimes
one needs to look to the past to find where they went off the path
and how to get back on it.

bill

[jamieeh...@gmail.com]

On Sunday, April 9, 2017 at 7:38:21 AM UTC-7, Bill Gunshannon wrote:
> On 4/9/2017 4:01 AM, jamieeh...@gmail.com wrote:
> > On Saturday, April 8, 2017 at 5:39:38 PM UTC-7, Bill Gunshannon wrote:
> >>> But we don't live on a uucp network.
> >>
> >> That's a choice that can be remedied. Why does everyone automatically
> >> assume it has to be one or the other?
> >
> > Because we have a tcp/ip network that is cheap, far faster, etc., etc.
>
> I'm not talking about replacing tcp/ip. UUCP can run on top of it.
> Just like SMTP, FTP and SSH.
>

> In your example it becomes one or the other. Without massive white-
> listing and black-listing (a major administrative nightmare) how do
> you propose top keep trusted email separate from the rest of the
> Internet with all its spam and malware?

Simple: Your servers for your trusted sites don't gateway the email to the greater internet.

> I am merely offering an alternative with much less administrative
> effort to clean up the morass that is the current status quo.

I just don't see that manually configuring the systems. file, which is a
list of your "neighbor" systems, amounts to "much less
administrative effort". Same for the need to construct bang paths.

> I would have commented more on what you said but working with the 500
> character lines was just more than I could deal with today.

(You're still hitting return other than at paragraph breaks? Whatever
you're using for a newsreader doesn't autowrap long lines?)

> UUCP is much better than SMTP.

Um... uucp, _per se_, isn't a mail transfer protocol at all.
It's just a file transfer mechanism. It's far more akin to ftp than
to smtp. The uucp protocols (g, f, etc.) don't know a thing about email.
(Or netnews.)

uucp suites generally do include uux (which sends a command to a remote
system and requests that it execute it) and uuxqt (which is the command
server that runs on the remote system). Mail over uucp uses that. The details on how file transfers are made to perform as a mail transport mechanism, they're in the "UUCP 'g' Protocol Description" that I wrote -
I think it's bundled in the DECUS uucp package.

The DECUS uucp implementation of uuxqt never implemented anything
except the "rmail" and the equivalent news-import command, as the
security issues with remote command execution were something we
just didn't want to touch. Accordingly we had no uux at all - our
foreign mail protocol interface just hand-generates the necessary
"work files" ("X" and "D" files) and sends 'em over. Same for the
news interface.

If all you need to do is transfer a couple of files, and you have IP
connectivity, why bother running uucp (any uucp protocol, doesn't
matter) over IP? Why not just use ftp? (Heck, you could use Kermit
for that matter.)

If you uuxqt-style mail transfer is much better than SMTP,
why do you think it didn't replace SMTP/POP?

It sounds like your real goal is a private network of mail and news
servers. Well, again, you can have that right now with existing
internet protocols. I'm not sure why the configuration task would
be any more work than using uucp as the transport layer.

And, again, mail routing is going to be an issue for the users...
unless either a) you have one common hub and everyone else talks to them (would suck to be them) or b) everyone talks to literally everyone else.

Jamie Hanrahan
j...@cmkrnl.com

[Bill Gunshannon]

On 4/10/2017 1:37 AM, jamieeh...@gmail.com wrote:
> On Sunday, April 9, 2017 at 7:38:21 AM UTC-7, Bill Gunshannon wrote:
>> On 4/9/2017 4:01 AM, jamieeh...@gmail.com wrote:
>>> On Saturday, April 8, 2017 at 5:39:38 PM UTC-7, Bill Gunshannon wrote:
>>>>> But we don't live on a uucp network.
>>>>
>>>> That's a choice that can be remedied. Why does everyone automatically
>>>> assume it has to be one or the other?
>>>
>>> Because we have a tcp/ip network that is cheap, far faster, etc., etc.
>>
>> I'm not talking about replacing tcp/ip. UUCP can run on top of it.
>> Just like SMTP, FTP and SSH.
>>
>> In your example it becomes one or the other. Without massive white-
>> listing and black-listing (a major administrative nightmare) how do
>> you propose top keep trusted email separate from the rest of the
>> Internet with all its spam and malware?
>
> Simple: Your servers for your trusted sites don't gateway the email to the greater internet.

If you mean gateway the UUCP email, your right, they don't that's the
purpose of having a second, secure network.

>
>> I am merely offering an alternative with much less administrative
>> effort to clean up the morass that is the current status quo.
>
> I just don't see that manually configuring the systems. file, which is a
> list of your "neighbor" systems, amounts to "much less
> administrative effort". Same for the need to construct bang paths.

When I was doing UUCP (before there was an Internet) I didn't have to
manually figure out bang-paths. The system did it. And we had a lot
less resources in those days. Are you telling me a PDP-11 with 2 RD54
disks (159 MB each) running Ultrix-11 was somehow more capable than the
systems we are running today? Remember what I said? Many things have
gone away in the past not because of inherent design flaws but because
we lacked the technology to support them only to be re-invented later
(frequently in a form not as good as the original would have been if
development had just continued.)

Most of the "administrative effort" today is trying to say ahead of the
Spammers and cleaning up after the actions of these social misfits.

>
>> I would have commented more on what you said but working with the 500
>> character lines was just more than I could deal with today.
>
> (You're still hitting return other than at paragraph breaks? Whatever
> you're using for a newsreader doesn't autowrap long lines?)

I take it your not following the other thread on Usenet content. :-)
When I try to reply to your messages Thunderbird puts your entire
paragraph on a single line making it impossible to read, much lesas
comment to particular sentences.

>
>> UUCP is much better than SMTP.
>
> Um... uucp, _per se_, isn't a mail transfer protocol at all.

Very true. It handles mail as just another file. This allows a number
of other things that SMTP doesn't do. Like hiding all of the metadata
including the ultimate recipient of the email until that information is
actually needed. It also would allow the easy incorporation of end to
end encryption of the entire message including the meta data that was
in the headlines not so long ago.

> It's just a file transfer mechanism. It's far more akin to ftp than
> to smtp. The uucp protocols (g, f, etc.) don't know a thing about email.
> (Or netnews.)

Your point? UUCP can be used to move email in a more secure manner than
SMTP. And, it exists and it has been tested and debugged.

>
> uucp suites generally do include uux (which sends a command to a remote
> system and requests that it execute it) and uuxqt (which is the command
> server that runs on the remote system). Mail over uucp uses that. The details on how file transfers are made to perform as a mail transport mechanism, they're in the "UUCP 'g' Protocol Description" that I wrote -
> I think it's bundled in the DECUS uucp package.
>
> The DECUS uucp implementation of uuxqt never implemented anything
> except the "rmail" and the equivalent news-import command, as the
> security issues with remote command execution were something we
> just didn't want to touch. Accordingly we had no uux at all - our
> foreign mail protocol interface just hand-generates the necessary
> "work files" ("X" and "D" files) and sends 'em over. Same for the
> news interface.
>

I really don't know why your trying to explain how UUCP works to me as
I apparently know more about it than you do. None of what you said
in that paragraph means anything positively or negatively to the
question at hand.

> If all you need to do is transfer a couple of files, and you have IP
> connectivity, why bother running uucp (any uucp protocol, doesn't
> matter) over IP? Why not just use ftp? (Heck, you could use Kermit
> for that matter.)

FTP is as much of a security nightmare as SMTP. Kermit was a cute toy
but its only real value was for moving files between machines that did
not support a real TCP/IP suite. The advantage of UUCP is that all of
the hooks to do safe, reliable, secure email are already there and have
been extensively tested and proven.

>
> If you uuxqt-style mail transfer is much better than SMTP,
> why do you think it didn't replace SMTP/POP?

You have it backwards. SMTP replaced UUCP. The reason being that at
the time UUCP was expensive (using Ma Bells phone lines to send email)
and the world SMTP was introduced into was much different. (Many places
didn't even use passwords because just like we left our front doors
unlocked computer users assumed no one would walk in and do damage.
Society changed. We changed the way we protect our homes with things
like ADT. We now need a way to do the same for email and SMTP can't be
fixed because the flaws are inherent in the design. You can put
lipstick on a pig but it's still a pig.

>
> It sounds like your real goal is a private network of mail and news
> servers. Well, again, you can have that right now with existing
> internet protocols. I'm not sure why the configuration task would
> be any more work than using uucp as the transport layer.

Because if you try and do this using SMTP unless you build your own
private physical network you will be exposing your heavily flawed
system to the world and all the miscreants and script-kiddies out
there. It is the protocol design that is flawed.

>
> And, again, mail routing is going to be an issue for the users...
> unless either a) you have one common hub and everyone else talks to them (would suck to be them) or b) everyone talks to literally everyone else.

Funny, that. There were central hubs in the old days, and even given
the limited resources it worked really well. Ever heard of UUNET? Or
the system it replaced, seismo? But, as I said, one can do full-mesh
but as you said, it is more initial overhead. And I wouldn't recommend
it as the optimal design. But having some number of central servers for
specific Email Domains is very doable. And, the big thing that some
people always seem to miss is that this is not a one way or the other
system. The UUCP network can be setup as it is being done right now
(mostly for fun kinda like the DECNET Network). People can choose to
join it or not. Groups of people can do this creating their own hub
and then have the hub connect to the "backbone". Think of a all of the
large potential Email Domains out there. .EDU -- researchers being
able to do their collaboration without having to deal with all the spam.
.GOV -- .MIL -- .ORG Let grandma continue to send her picture of
dancing kitties using SMTP but give people who want to take email back
to the days when it was eminently usable for serious work that ability.
No one would be forced onto it, but it is usually considered a good
thing to have choices.

bill

[johnwa...@yahoo.co.uk]

Thank you.

Useful content, with context, and an attributed source (not
just Wikipedia). Always useful, not just round here.

Much better (usually) than an anonymous context-free quote
with no context.

Your "first of April" sig cookie seems particularly
appropriate in the circumstances.

Have a lot of fun.

[Phillip Helbig (undress to reply)]

In article <el1du8...@mid.individual.net>, Bill Gunshannon

<bill.gu...@gmail.com> writes:

> >> I would have commented more on what you said but working with the 500
> >> character lines was just more than I could deal with today.
> >
> > (You're still hitting return other than at paragraph breaks? Whatever
> > you're using for a newsreader doesn't autowrap long lines?)
>

> I take it your not following the other thread on Usenet content. :-)
> When I try to reply to your messages Thunderbird puts your entire
> paragraph on a single line making it impossible to read, much lesas
> comment to particular sentences.

People just don't get it. People really think that because THEY see
wrapped lines on their screen, then everyone else will as well, even
though their newsreader sends one line per paragraph.

It doesn't matter if the line breaks are inserted by hand, like the one
at the end of this line, or inserted automatically by software, like the
one at the end of the second line in this paragraph. In both cases, the
resulting file---which is sent to the NNTP server---will have line
breaks there. (By the way, written in EDT.)

(To be fair, VMS MAIL with SEND/NOEDIT will wrap the lines on the screen
but send a long line, but a) I think that everyone who uses this knows
this and b) if there is more than one line to be sent /EDIT is the way
to go. I've certainly never had cause to complain about long lines sent
from VMS MAIL.)

[David Froble]

Bill Gunshannon wrote:

> I take it your not following the other thread on Usenet content. :-)
> When I try to reply to your messages Thunderbird puts your entire
> paragraph on a single line making it impossible to read, much lesas
> comment to particular sentences.

"Hilight", "Edit", and "Rewrap" works for me. Yeah, a PITA, but, it's not too
hard to "get there from here".

[Arne Vajhøj]

On 4/9/2017 8:02 PM, Bill Gunshannon wrote:
> Uuencode is actually still used. Ships as part of the base of FreeBSD
> and I would be surprised if the same wasn't true for Linux. It didn't
> go away, MIME just added other forms of encoding that were better in
> certain conditions.

uuencode is stille available in many software.

But I would deem it extremely rare in actual usage today.

Arne

[Bill Gunshannon]

Well, I know I stil use it once in a while. :-)

bill

[Bill Gunshannon]

And I probably should have mentioned the fact that it is still in
FreeBSD means something as there has been a lot of stuff removed
that was also still in use.

bill

[terry-...@glaver.org]

On Monday, April 10, 2017 at 8:59:54 AM UTC-4, Bill Gunshannon wrote:
> Your point? UUCP can be used to move email in a more secure manner than
> SMTP. And, it exists and it has been tested and debugged.

SMTP has beeen tested and debugged, and there are a variety of implementations
if you don't like Sendmail, or whatever the default is on your system. SMTP has
TLS extensions, username authentication extensions, etc. SMTP can reject that
100MB message because you don't like the sender, the message is too big, and
so on. UUCP has to receive the whole message (possibly going <Burp!> in the pro-
cess), and then discard it.

If your objection to SMTP is that random people can connect to your TCP port 25,
just put in some access rules, either on the system that is running SMTP or on
your firewall / router / etc. to limit access to only those systems you want to
talk to.

> I really don't know why your trying to explain how UUCP works to me as
> I apparently know more about it than you do. None of what you said
> in that paragraph means anything positively or negatively to the
> question at hand.

Ummm, you *DO* know who you are talking to on the other end of that conver-
sation, right? Just checking...

> And I probably should have mentioned the fact that it is still in FreeBSD
> means something as there has been a lot of stuff removed that was also still > in use.

You may want to familiarize yourself a little more with FreeBSD. Things that
are removed from the FreeBSD distribution (as opposed to the ports collection)
are generally removed for one of three reasons:

1) They have restrictive licenses and are replaced by equivalent packages
with more permissive licenses (ideally BSD 3-clause).
2) They are insecure, or are updated on a faster schedule than FreeBSD major
versions. In the latter case they usually get moved to ports.
3) They are larger or complicated to configure in relation to the function-
ality used by FreeBSD "as shipped". These get replaced with something
"leaner and meaner" and the original package moved to ports.

In the case of uuencode, it is in /usr/src/usr.bin/uuencode and uses the BSD
license. That means it is unlikely to ever be evicted. If it was in the
/usr/src/contrib area it might be replaced, but I doubt there's a smaller im-
plementation to be found.

sendmail and ntp are two possible /usr/src/contrib candidates for replacement
with more lightweight versions at some point in the future.

[Tom Allebrandi]

> Bill Gunshannon <bill.gu...@gmail.com> wrote:
>
> I think I will. Probably try to get a VAXStation up early this week
> and if I have success I will try something newer on an Alpha. But, if
> I have any success at all it is still just a stepping stone as Taylor
> UUCP would be the target. Phone modems are the dead issue in this
> technology. Need to be able to do UUCP over IP.

I am putting on my running shoes and headed out for an undisclosed
location as soon as I finish typing this...

I wonder if UUCP 'g' would run over telnet? Maybe even ssh if you wanted
encryption.

:-) :-)

--- tom

[Tom]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in
news:oceh9q$9b8$5...@dont-email.me:

>
> $ set response/mode=good_natured
>
> While you are at it, why don't you try resurrecting FidoNet, ARC file
> compression, uuencode attachments and VT52 terminals ? :-)
>
> Simon.
>

There are very active retro computing communities all around the world,
especially here in Seattle.

Next time you are up this way, be sure and visit the Living Computers
Museum + Labs, (http://www.livingcomputers.org/) They have all kinds of
vintage hardware running that people can sit down and play with.

Here's a link to their hardware page:
http://www.livingcomputers.org/Discover/At-The-
Museum/VintageComputers.aspx

Among other things they have

- the CDC6500 that was at Purdue University in the '70s. I think you can
request a login and connect to it over telnet.


- They also have a DECSYSTEM-10 and two DECSYSTEM-20s.Someone recently
claimed the bigger DEC 20 was the same machine that Microsoft used when
they were getting started. (In their early days, Microsoft cross
compiled a lot of their 808x products on a DEC 20 running TOPS-10.)

I'm not sure that the story is true, I thought Microsoft had the little
single cabinet 2020 in those days. That's why we had one where I worked,
But,that's a story for another day.

Cheers!

--- tom

[Tom]

Bill Gunshannon <bill.gu...@gmail.com> wrote in news:el00dbF8qgjU1
@mid.individual.net:

> I am not trying to push old for the sake of old I am trying to
> demonstrate that newer is not synonymous with better and sometimes
> one needs to look to the past to find where they went off the path
> and how to get back on it.

I probably should of mentioned that the DECUS UUCP project had two goals.

1) Bring a solid and reliable UUCP to VMS systems so that they could join
in the fun.

Even though we were on UUCP, Jamie and I used to have near real time
discussions using mail. (We were neighbors in the tree.)


2) Create a network of VMS systems using UUCP for discussions relevant to
VAXes and VMS. Originally, the VMSnet was intended to be seperate from the
USEnet. We started out doing our own email routing and newsgroup
distributions. (That's how we got the creation of the VMSnet newsgroup tree
past the "Gods of the USEnet.")

The VMSnet newsgroup tree is still there. It's pretty much descended into
garbage and spam.

But, I wonder if it would be worth it to prune the tree, and then see if we
could send out newgroup messages to convert the remaining groups from open
access to moderated.


--- tom

PS: I remember VT52's. I had to repair one once, and was able to track the
problem to a single bad IC out of the 30+ chips on the motherboard.

[Phillip Helbig (undress to reply)]

In article <och5t8$1jvb$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=

UUENCODE, say, a PDF file, then just email it from the command line or
include it in a message. Many email clients correctly interpret it as
an attachment. Some (notable Outlook) don't.

There was a discussion a while back on how best mail attachments from
VMS MAIL. This is by far the easiest if the mail client interprets it
correctly.

[Jan-Erik Soderholm]

It is my prefered way to send something from VMS to my mail.

ZIP the file.
UUencode th ZIP file.
MAIL the UUE file to myself.

It always ends up as a normal attachment in my (Outlook) mail.

[Phillip Helbig (undress to reply)]

In article <ocicfi$6dl$2...@news.albasani.net>, Jan-Erik Soderholm

<jan-erik....@telia.com> writes:

> It is my prefered way to send something from VMS to my mail.
>
> ZIP the file.

Not necessary if PDF (already compressed).

> UUencode th ZIP file.
> MAIL the UUE file to myself.
>
> It always ends up as a normal attachment in my (Outlook) mail.

Interesting. Did you have to configure something to get this to work?

[Bill Gunshannon]

On 4/11/2017 1:19 AM, terry-...@glaver.org wrote:
> On Monday, April 10, 2017 at 8:59:54 AM UTC-4, Bill Gunshannon wrote:
>> Your point? UUCP can be used to move email in a more secure manner than
>> SMTP. And, it exists and it has been tested and debugged.
>
> SMTP has beeen tested and debugged, and there are a variety of implementations

That's true, but nobody is saying its shortcomings are bugs. It works
exactly as it was designed. And that is the problem.

> if you don't like Sendmail, or whatever the default is on your system. SMTP has
> TLS extensions, username authentication extensions, etc. SMTP can reject that
> 100MB message because you don't like the sender, the message is too big, and
> so on.

Size isn't a problem. Content is the problem. And SMTP falls very
short of being able to control that. Otherwise, we wouldn't have a
SPAM or malware problem with email.

> > UUCP has to receive the whole message (possibly
going <Burp!> in the pro-
> cess), and then discard it.

Again. looking at UUCP as it was 30 years ago. Connections today are
over IP and totally reliable. No more burps. And no more 3 hour phone
connections to move a file.

>
> If your objection to SMTP is that random people can connect to your TCP port 25,
> just put in some access rules, either on the system that is running SMTP or on
> your firewall / router / etc. to limit access to only those systems you want to
> talk to.

How do you know who to restrict? Which addresses are spammers and
which are legitimate potential email patrons?

>
>> I really don't know why your trying to explain how UUCP works to me as
>> I apparently know more about it than you do. None of what you said
>> in that paragraph means anything positively or negatively to the
>> question at hand.
>
> Ummm, you *DO* know who you are talking to on the other end of that conver-
> sation, right? Just checking...

About as much as he knows who I am (or what my background is.)

>
>> And I probably should have mentioned the fact that it is still in FreeBSD
>> means something as there has been a lot of stuff removed that was also still > in use.
>
> You may want to familiarize yourself a little more with FreeBSD. Things that
> are removed from the FreeBSD distribution (as opposed to the ports collection)
> are generally removed for one of three reasons:
>
> 1) They have restrictive licenses and are replaced by equivalent packages
> with more permissive licenses (ideally BSD 3-clause).
> 2) They are insecure, or are updated on a faster schedule than FreeBSD major
> versions. In the latter case they usually get moved to ports.
> 3) They are larger or complicated to configure in relation to the function-
> ality used by FreeBSD "as shipped". These get replaced with something
> "leaner and meaner" and the original package moved to ports.
>
> In the case of uuencode, it is in /usr/src/usr.bin/uuencode and uses the BSD
> license. That means it is unlikely to ever be evicted. If it was in the
> /usr/src/contrib area it might be replaced, but I doubt there's a smaller im-
> plementation to be found.

OK. I can buy that. but, uuencode isn't really a part of the
conversation and was only posted to emphasis the point that UUCP
is old. I never denied that. But old doesn't mean bad and it doesn't
mean not usable. It also doesn't mean it can't be the solution to a
particular problem.

>
> sendmail and ntp are two possible /usr/src/contrib candidates for replacement
> with more lightweight versions at some point in the future.
>

I would hope that other than on "vintage" systems nobody was running
Sendmail any more as better choices have been available for a long
time.

bill

[Simon Clubley]

On 2017-04-11, Tom Allebrandi <wyr...@ytram.com> wrote:
>
> I am putting on my running shoes and headed out for an undisclosed
> location as soon as I finish typing this...
>
> I wonder if UUCP 'g' would run over telnet? Maybe even ssh if you wanted
> encryption.
>

I once tried to run SLIP or PPP (I don't remember which) over LAT.
The performance left something to be desired (which if you know how
LAT works, you will understand why). :-)

[Bill Gunshannon]

I haven't actually tried it yet but running UUCP over SSH is one of
my targets. But, as I said earlier, because email is just a file
being moved between peers and doesn't appear as email except at the
originating and terminating points it would be trivial to throw in
the hooks needed to encrypt the payload providing even better security
because not only the text of the message would get encrypted but also
all the metadata like who the ultimate receiver of the email is.

bill

[Bill Gunshannon]

But... But.. It's old. It can't possibly be usable or the correct
solution to a problem, right?

bill

[Jan-Erik Soderholm]

Den 2017-04-11 kl. 14:02, skrev Phillip Helbig (undress to reply):
> In article <ocicfi$6dl$2...@news.albasani.net>, Jan-Erik Soderholm
> <jan-erik....@telia.com> writes:
>
>> It is my prefered way to send something from VMS to my mail.
>>
>> ZIP the file.
>
> Not necessary if PDF (already compressed).

Yes, it does depend on the actuall file, of course...

>
>> UUencode th ZIP file.
>> MAIL the UUE file to myself.
>>
>> It always ends up as a normal attachment in my (Outlook) mail.
>
> Interesting. Did you have to configure something to get this to work?
>

Configure where? But no, I did nothing. The VMS files behaves just as
any other attachment from any other source. I can either preview
within Outlook or double-click to in some application.

[Simon Clubley]

On 2017-04-11, Tom <wyr...@ytram.com> wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in
> news:oceh9q$9b8$5...@dont-email.me:
>>
>> $ set response/mode=good_natured
>>
>> While you are at it, why don't you try resurrecting FidoNet, ARC file
>> compression, uuencode attachments and VT52 terminals ? :-)
>>
>

> There are very active retro computing communities all around the world,
> especially here in Seattle.
>

Yes, I know and it's something I actively encourage.

The point I was making is that Bill is in danger of thinking something
is better simply because he's more comfortable with it, instead of
considering whether the newer solution might be designed to solve
a different problem and to do that in a better way than the older
problem can.

In this case, SMTP and the underlying protocols are designed to be used
on a global scale by a vast number of machines that don't know each other.
Can UUCP scale to that level ?

[Jan-Erik Soderholm]

> But... But.. It's old. It can't possibly be usable...

It is *very* usable...

> or the correct solution to a problem, right?

To what problem? To view a file that is not othervise viewable
on VMS, it works perfectly well. Or what is "a problem"?


>
> bill
>

[Bill Gunshannon]

On 4/11/2017 8:31 AM, Simon Clubley wrote:
> On 2017-04-11, Tom Allebrandi <wyr...@ytram.com> wrote:
>>
>> I am putting on my running shoes and headed out for an undisclosed
>> location as soon as I finish typing this...
>>
>> I wonder if UUCP 'g' would run over telnet? Maybe even ssh if you wanted
>> encryption.
>>
>
> I once tried to run SLIP or PPP (I don't remember which) over LAT.
> The performance left something to be desired (which if you know how
> LAT works, you will understand why). :-)
>
> Simon.
>

I can't imagine why. I thought PPP was designed for doing just such
gyrations. I know I ran connections between the IBM Mainframe and
some IBM remote box over PPP when I set up the initial network at the
University to support all the 3270 terminals (over leased lines) and
it seemed to work. Didn't last long, though, as the IBM went away in
favor of a big VAX.

As for UUCP. I ran it quite successfully over 1200 baud AX.25 in
research. Never found anyone interested in actually using it. But
then, I found nothing but resistance to TCP/IP over AX.25, too. And
just look at what happened to running OSI over AX.25. There was a
case of the opposite problem I am finding. They refused anything new.

bill

[Bill Gunshannon]

On 4/11/2017 8:39 AM, Simon Clubley wrote:
> On 2017-04-11, Tom <wyr...@ytram.com> wrote:
>> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in
>> news:oceh9q$9b8$5...@dont-email.me:
>>>
>>> $ set response/mode=good_natured
>>>
>>> While you are at it, why don't you try resurrecting FidoNet, ARC file
>>> compression, uuencode attachments and VT52 terminals ? :-)
>>>
>>
>> There are very active retro computing communities all around the world,
>> especially here in Seattle.
>>
>
> Yes, I know and it's something I actively encourage.
>
> The point I was making is that Bill is in danger of thinking something
> is better simply because he's more comfortable with it,

Comfort has nothing to do with it. I looked a t a problem (one that
some consider a very serious problem and growing every day) and looked
at solutions. One solution rises rapidly to the top with its only
real anchor being the fact that it is not new.

> instead of
> considering whether the newer solution might be designed to solve
> a different problem and to do that in a better way than the older
> problem can.

A newer solution could be designed. But, how long would you estimate
it would take to come up with a new email protocol that does not have
the problems of the current system, design it, implement it, field it.
(We won't go into getting it accepted because you can see from this
conversation how hard getting anything accepted is likely to be!)

I think we need to come up with something new. But the problem exists
now and a solution exists now. And, it can all be done transparently
to the user, which is one of the major requirements of any such system.

>
> In this case, SMTP and the underlying protocols are designed to be used
> on a global scale by a vast number of machines that don't know each other.

And that last phrase is a major part of the problem. In order to
function you have to accept email from people you don;t know and who's
identity you can can not verify or even have any reasonable hope of
trusting.

> Can UUCP scale to that level ?

I think a network based on UUCP, if done properly can. And at the same
time provide the needed security to prevent joe script-kiddie or even
serious spammers from reducing it to the level of the current system.


bill

[Bill Gunshannon]

I guess I was too subtle again. :-)

bill

[David Froble]

Me thinks in this case the "problem" is perhaps an inability to recognize sarcasm?

[Jan-Erik Soderholm]

Ah, right. I think I see Bills point know... :-)
Yes, you are right Bill, how can this possibly be usable... :-)

[Stephen Hoffman]

On 2017-04-11 13:15:04 +0000, David Froble said:

> Me thinks in this case the "problem" is perhaps an inability to
> recognize sarcasm?

Wait... Sarcasm? I thought the whole thread was satire?


--
Pure Personal Opinion | HoffmanLabs LLC

[terry-...@glaver.org]

On Tuesday, April 11, 2017 at 8:33:03 AM UTC-4, Bill Gunshannon wrote:
> Size isn't a problem. Content is the problem. And SMTP falls very
> short of being able to control that. Otherwise, we wouldn't have a
> SPAM or malware problem with email.

> How do you know who to restrict? Which addresses are spammers and
> which are legitimate potential email patrons?

The same way you build a UUCP map, by knowing who connects to who. Except
instead of needing to build a full graph via pathalias, all you need is a
list of the IP addresses of the hosts in your little walled garden.

And unless you can convince everybody else that they want to be in the
walled garden too, at least somebody is going to have a MTA that will
accept SMTP mesages and gateway them into UUCP, which kind of defeats the
point.

> Again. looking at UUCP as it was 30 years ago. Connections today are
> over IP and totally reliable. No more burps. And no more 3 hour phone
> connections to move a file.

Way up at the top of this thread, you did say you wanted to start with
DECUS UUCP, right? It was wonderful software for its time, but it was al-
ways a bit twitchy, particularly when interfacing with software outside of
its control, like VMS Mail and ANU News. And regardless of the underlying
transport, UUCP is still going to receive the whole file and then decide
to discard it (what is your home Internet usage capped at?), while SMTP
can just look at the from/to during the connection setup and go "Nope, I
don't want that. <click>"

> > Ummm, you *DO* know who you are talking to on the other end of that conver-
> > sation, right? Just checking...
>
> About as much as he knows who I am (or what my background is.)

We may be a bunch of old geezers, but I still remember both of you. Do you re-
member me? uunet!rutgers!spcvxb!spcvxa!terry

[Phillip Helbig (undress to reply)]

In article <el40nr...@mid.individual.net>, Bill Gunshannon

<bill.gu...@gmail.com> writes:

> > If your objection to SMTP is that random people can connect to your TCP
> > port 25, just put in some access rules, either on the system that is
> > running SMTP or on your firewall / router / etc. to limit access to only
> > those systems you want to talk to.

> How do you know who to restrict? Which addresses are spammers and
> which are legitimate potential email patrons?

I have found that dropping (not rejecting with some error message, which
can cause backscatter spam) email connections to non-existent addresses
and using zen.spamhaus.org as a real-time black-hole list gets rid of
probably 99 per cent or more of spam. What is left is much less than
legitimate email.

DISK$USER:[SYSTEM.TCPIP_SMTP]TCPIP$SMTP.CONF;1 <--- cluster-common

Symbiont-Checks-Deliverability: FALSE
RBLs : zen.spamhaus.org

One could argue that one should be polite and provide proper error
messages and also allow connections from anyone, but both are just not
practical. However, the price is low. People mis-typing an email
address must be really far down on the list of computer problems, and
anyone can send email through an official SMTP relay server for at most
a small fee.

Alternate gateway: SMTP-RELAY.DYNACCESS.DE

Incoming mail comes directly to my cluster:

217.250.203.222 10 multivax.dynaccess.net
217.114.73.109 15 mail-reject.DE
185.17.144.141 20 backup-mx1.DE
80.83.115.219 21 backup-mx2.DE

I've been running my own SMTP server on VMS for 20 years. While Hoff
has pointed out that some things about the setup are not RFC-conforming,
in practice there don't seem to be any problems (and, yes, I would
otherwise notice at least most of them).

[Paul Sture]

On 2017-04-11, Tom <wyr...@ytram.com> wrote:

> PS: I remember VT52's. I had to repair one once, and was able to track the
> problem to a single bad IC out of the 30+ chips on the motherboard.

The VT52s we had died at regular intervals, always from the same
problem. PSU or a capacitor, I forget the details now, but it was a
lengthy process to get to the offending part[1], and the same time to
reassemble everything afterwards.

The VT100 and subsequent VTs were a lot easier to get into, and I don't
readily recall any of them failing. In comparison certain OEM models
had the life of a fruit fly.

[1] my memory says 45 minutes to disassemble, 45 minutes to reassemble,
and those were official DEC book times, which seems hard to believe
nowadays, but even halving it comes out at 45 minutes for the full job.

--
The First of April: The only day of the year that people critically
evaluate news stories before believing them.

[Chris Scheers]

Tom wrote:
>
> - They also have a DECSYSTEM-10 and two DECSYSTEM-20s.Someone recently
> claimed the bigger DEC 20 was the same machine that Microsoft used when
> they were getting started. (In their early days, Microsoft cross
> compiled a lot of their 808x products on a DEC 20 running TOPS-10.)
>
> I'm not sure that the story is true, I thought Microsoft had the little
> single cabinet 2020 in those days. That's why we had one where I worked,
> But,that's a story for another day.

Since Paul Allen is the driving force behind the LCM, it is quite possible.

I know that they have Mr. Allen's DECSYSTEM, but I don't know details
about it.

--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ch...@applied-synergy.com
Fax: 817-237-3074

[Arne Vajhøj]

On 4/11/2017 6:51 AM, Jan-Erik Soderholm wrote:

> Den 2017-04-11 kl. 01:53, skrev Arne Vajhøj:
>> On 4/9/2017 8:02 PM, Bill Gunshannon wrote:
>>> Uuencode is actually still used. Ships as part of the base of FreeBSD
>>> and I would be surprised if the same wasn't true for Linux. It didn't
>>> go away, MIME just added other forms of encoding that were better in
>>> certain conditions.
>>
>> uuencode is stille available in many software.
>>
>> But I would deem it extremely rare in actual usage today.
>

> It is my prefered way to send something from VMS to my mail.
>
> ZIP the file.
> UUencode th ZIP file.
> MAIL the UUE file to myself.
>
> It always ends up as a normal attachment in my (Outlook) mail.

But wouldn't B64 also work?

And maybe even just /FOREIGN?

Arne

[Simon Clubley]

On 2017-04-11, Bill Gunshannon <bill.gu...@gmail.com> wrote:
> On 4/11/2017 8:31 AM, Simon Clubley wrote:
>>
>> I once tried to run SLIP or PPP (I don't remember which) over LAT.
>> The performance left something to be desired (which if you know how
>> LAT works, you will understand why). :-)
>>
>

> I can't imagine why. I thought PPP was designed for doing just such
> gyrations. I know I ran connections between the IBM Mainframe and
> some IBM remote box over PPP when I set up the initial network at the
> University to support all the 3270 terminals (over leased lines) and
> it seemed to work. Didn't last long, though, as the IBM went away in
> favor of a big VAX.
>

I said LAT, not PPP. :-)

LAT buffers data and sends it in packets at fixed intervals (usually
10s of milliseconds apart). It's also a multiplexing protocol so each
data slot is much smaller than an Ethernet frame. It's design goal
to handle terminal traffic only.

It's been a long time since I did this, but I also vaguely seem to
remember some issues around it being all too easy to cause data
overrun type issues when routing PPP/SLIP over LAT but I don't
remember if that was a PPP/SLIP to LAT VMS driver interface issue
or a terminal server issue.

[Paul Sture]

On 2017-04-10, johnwa...@yahoo.co.uk <johnwa...@yahoo.co.uk> wrote:
> On Sunday, 9 April 2017 03:57:07 UTC+1, Paul Sture wrote:
>> On 2017-04-08, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> > On 4/8/2017 12:22 PM, Robert A. Brooks wrote:
>> >> On 4/8/2017 12:17 PM, Bill Gunshannon wrote:
>> >>> UUCP for VMS
>> >>> DECUS UUCP is an implementation of UUCP for the DEC Vax system. We
>> >>> mention it here for historical purposes only, since there has been
>> >>> no new development since 1992 and the software does not run on OpenVMS.
>> >>
>> >>> The packagae is available at ftp://ftp.uu.net/systems/vms/uucp and
>> >>> runs under VMS 5.4-x or VMS 5.5.
>> >>
>> >> There is an inconsistency above. The name "OpenVMS" came about (I think)
>> >> around the time of VAX/VMS V5.4. Wikipedia claims that it first showed
>> >> up around VAX/VMS V5.4-2, which sounds about right.
>> >
>> > I thought it was 5.5-2 that got the "Open" when POSIX support was added!?
>>
>> From the "VMS at 20" book.
>>
>> 1991
>>
>> • OpenVMS name change announced.
>> • NVAX, DIGITAL’s fourth VAX microprocessor, implemented in
>> 0.75-micrometer
>> CMOS technology; shipped in VAX 6600 systems.
>> • OpenVMS V5.5 shipped.
>> • DIGITAL and Microsoft Corporation announced alliance allowing
>> Microsoft Windows to retrieve and exchange data with local area
>> network servers running DIGITAL PATHWORKS software.
>> • DECnet Phase V announced.
>>
>> and
>>
>> OpenVMS/AXP V1.0 November 1992 - Alpha is here!
>>
>> • Support for new Alpha processors DEC 3000 Models 400, 400S, 500
>> & 500S DEC
>> 4000 Model 600 DEC 7000 Model 610
>> • Based on VMS V5.4
>> • DECmigrate for translating VAX images
>> • MACRO-32 compiler
>> • No clusters, no RMS journaling, no shadowing, no SMP
>>
>> OpenVMS/VAX V6.0 June 1993
>> • Support for new processors – VAX 7000 Model 650/660, VAX 10000 Model
>> 650/660
>> • Rationalized and Enhanced security (Level C2 compliance)
>> • Multiple queue managers across cluster
>> • HELP/MESSAGE utility
>> • Support for ISO 9660 CD-ROM format
>> • Adaptive Pool Management
>> • SYSMAN cluster wide SHUTDOWN and startup logging
>> • Cluster wide Virtual I/O cache
>> • Extended physical and virtual addressing
>> • Protected subsystems
>> • DECnet/OSI
>> • DECwindows XUI replaced by DECwindows Motif

>>
>>
>> --
>> The First of April: The only day of the year that people critically
>> evaluate news stories before believing them.
>

> Thank you.
>
> Useful content, with context, and an attributed source (not
> just Wikipedia). Always useful, not just round here.

Thank you. I have quoted from that source so many times over the years
that it would have been worth my while sticking it into a bunch of
editor buffers (or wherever), preformatted for usenet posting.

I might just do that for next time :-)

> Much better (usually) than an anonymous context-free quote
> with no context.

> Your "first of April" sig cookie seems particularly
> appropriate in the circumstances.
>
> Have a lot of fun.

You too.

[Kerry Main]

Re: VMS at 20 ..

A nice VMS at 20 brochure for those that like to walk down memory lane: (great read, really shows the creativity of those involved, importance of Fortran/Cobol in design and lots of great pics - including Ronald Regan with Ken Olsen!)

<http://h20565.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04623368>

A few extracts:
"Creativity with discipline. From its inception, DIGITAL realized the importance of creativity, and sought to create an environment in which individual creativity would thrive within a disciplined environment. The strategy was to hire talented people and empower them to develop plans, have those plans reviewed and approved, and to accept ownership of the project. The company believed that people would be most productive when they had to meet milestones and stay within a budget—this is where the discipline factor came in. Each product line group was responsible for meeting its plan within time and budget constraints."

"Dave Cutler started the first VMS April Fool’s jokes. One year, Andy Goldstein replaced the line printer driver so that everything printed out backwards. On another April 1, the entire system message file was replaced with joke messages—including ones like “File not found. Where did you leave it?”

"The DEC-10 was used to compile the VMS modules written in Bliss because at the time the Bliss compiler only ran on a DEC-10. The Bliss code had to be transported by tape to the PDP-11 to be linked."

And something related to what Steve has been pushing-
"As the technical writer, my belief was that the technical writer is the advocate for the customer. So I always put myself in the shoes of someone who is trying to learn how to use the system, and wrote the documentation accordingly. The VMS Documentation Group grew from five people in 1977 to 45 in 1987, and the documentation set grew from 9,000 to 20,000 pages. It was a massive effort.”

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Phillip Helbig (undress to reply)]

In article <mailman.1.1492087945.3...@rbnsn.com>,

"Kerry Main" <kemain...@gmail.com> writes:

> A nice VMS at 20 brochure for those that like to walk down memory lane:

I don't know if this is the same one I am familiar with. There is a
scene where a manager says "Our three goals on this project are: time to
market, time to market, time to market." An engineer then asked "What
about quality?" The reply was: "Quality is not a goal; it is a given."

Those were the days.

[Rich Alderson]

[ DISCLAIMER: I currently hold the title of Sr. Systems Engineer at
Living Computers: Museum + Labs, and have the honor to be the first
person employed by the project what turned into that museum, in 2003.
In that time, I have been curator, collections manager, exhibit designer,
systems programmer, developer, systems administrator for our online
offerings, hardware maintenance technician, web site designer, etc.
Prior to that, I worked for XKL, LLC, for ~10 years, doing customer
advocacy, pre- and post-sales support, and systems administration for
the company. I know a thing or two about the history. --rma]

Tom <wyr...@ytram.com> writes:

> There are very active retro computing communities all around the world,
> especially here in Seattle.

> Next time you are up this way, be sure and visit the Living Computers
> Museum + Labs, (http://www.livingcomputers.org/) They have all kinds of
> vintage hardware running that people can sit down and play with.

> Here's a link to their hardware page:
> http://www.livingcomputers.org/Discover/At-The-Museum/VintageComputers.aspx

> Among other things they have

> - the CDC6500 that was at Purdue University in the '70s. I think you can
> request a login and connect to it over telnet.

Indeed. On the home page for Living Computers, under "Get Involved" on the
menu bar (not where I'd have put it), there is a "Request a Login" item which
will take you to a form which offers accounts on 8 systems (with more coming
in the future):

XKL Toad-2 TOPS-20 v7.1
DEC 2065 Tops-10 v7.04
VAX-11/780-5 VMS 7.3
PDP-11/70 Unix v7
VAX-11/730 BSD 4.3
WE 3B2 Unix SVR3
Xerox Sigma 9 CP-V
CDC 6500 NOS

> - They also have a DECSYSTEM-10 and two DECSYSTEM-20s.Someone recently
> claimed the bigger DEC 20 was the same machine that Microsoft used when
> they were getting started. (In their early days, Microsoft cross
> compiled a lot of their 808x products on a DEC 20 running TOPS-10.)

Well, technically ;-) there are 3 Decsystem-10s in the big computer room on
the 2nd floor, since the difference between a Dec-10 and a DEC-20 was which
operating system was running on the hardware. The orange system (DEC-2065)
is running Tops-10 v7.04; the DEC-1070 (KI-10 processor, big blue boxes) is
running Tops-10 v6.03A; and the blue KL-10 (not painted by DEC but by a
previous owner) is running WAITS, the Stanford Artificial Intelligence
Labortory's OS which descended from the PDP-6 monitor and diverged from
Tops-10 at the 4S72 monitor release.

There is a Toad-1 and a pair of Toad-2 systems running TOPS-20 v7.1 (the XKL
release of the OS); there are also a pair of DECSYSTEM-2020s awaiting my time
to get ITS running on one (the former MIT-AI KS-10) and TOPS-20 v4.1 (on a
system previously owned by my late friend Mark Crispin.

None of these particular systems was ever in use at Microsoft. In point of
fact, the 2065 was the development machine at XKL until we had enough Toad-1
systems to eat our own dog food.

> I'm not sure that the story is true, I thought Microsoft had the little
> single cabinet 2020 in those days. That's why we had one where I worked,
> But,that's a story for another day.

Until the move from Albuquerque (the return from exile?), Microsoft leased time
on Tops-10 systems owned by other organizations. Paul Allen moved to Seattle
two weeks earlier than the rest of the company to take delivery of a 2020; this
brought about a move from Tops-10 to TOPS-20 as the development platform for
the company. They acquired at least one KL-10 system as the company grew, as
well as a pair of PDP-11/70s dubbed Kermit and Miss Piggy for Xenix development
(and Miss Piggy is the system listed above as running Unix v7).



Rich Alderson
Sr. Systems Engineer
Living Computers: Museum + Labs
2245 1st Avenue S
Seattle, WA 98134

http://www.LivingComputers.org/


--
Rich Alderson ne...@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

[Steven Schweda]

> The packagae is available at
> ftp://ftp.uu.net/systems/vms/uucp
> and runs under VMS 5.4-x or VMS 5.5.

You tried that link? It failed for me.

> Just out of curiosity, is there really anything that drastic
> that would have changed to make the software no longer usable
> under VMS?

The C compiler is one thing which might.

Knowing nothing, I looked around and found some 'Version
2.0 of DECUS uucp (formerly "VMSnet software")' from (mostly)
1992, at:
ftp://ftp.decuserve.org/decus/vms/sig_tapes/vax92a/uucp/

After some "wget -r" action (and plenty of "set file
/attr" action on the text files), I got some readable files.

Gzip can un-compress the ".bkp-z" files, and the usual
tools for BACKUP save-set adjustment can make the results
usable. (The apparent expectation in 1992 was that the
supplied VAX executables like [.BIN]COMPRESS.EXE and
[.BIN]MODATT.EXE would be adequate to handle these tasks.
They're less directly useful on an Alpha system.)

I spent some time looking for how-to-build instructions,
but found only how-to-use instructions. (They could be in
there somewhere, and I've missed the obvious before.)
Lacking direction, I began by trying to build the "make"
program ([UUCP.TOOLS.MAKE.V33]). After some hours of
pounding on the source code to clear numerous/various
compiler complaints -- I'll guess that VAX C didn't do
%CC-W-PTRMISMATCH -- I actually got it to work well enough to
build itself (which is the only test I've tried):

ALP $ mcr [-]make /verify
$ @ALP$DKC100:[UUCP.TOOLS.MAKE.V33]MAKE39066134.COM;1
$ On Control_Y Then Goto The_Exit
$ On Error Then Goto The_Exit
$ cc make.c/obj=make.obj
$ cc mstring.c/obj=mstring.obj
$ cc cmdline.c/obj=cmdline.obj
$ set command makecmd.cld/object=makecmd.obj
$ cc dates.c/obj=dates.obj
$ link make.obj,-
mstring.obj,-
cmdline.obj,-
makecmd.obj,-
dates.obj
$The_Exit:
$ Save_Status = $STATUS
$ Delete/NoLog ALP$DKC100:[UUCP.TOOLS.MAKE.V33]MAKE39066134.COM;1
$ Verify_Flag = F$Verify(Verify_Flag)

Not having written much 25-year-old C code lately, I
hesitate to criticize the coding style of this stuff, but HP
C V7.3-010 suffers from no such reticence. If this one
program is representative of the remainder, then I'd say that
someone trying to whip this stuff into shape for a modern C
compiler would have some serious work ahead of him. (And I
wouldn't expect the result to cope well with ODS5, either.)

My quick guess would be that if there's any (more) modern
UUCP software out there, then porting that to VMS would be
smarter (and easier) than trying to resurrect this fossil.

Only one man's opinion, of course.