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