On 1/3/21 10:51 PM, John Goerzen wrote:
> Hey, the posts are outnumbering the spam (at least on Google Groups
> [yeah, I know, don't shoot me]) so I took that as a positive sign
> for Usenet :-)

;-)

> Thank you!

You're welcome.

> So a quick disclaimer that applies to all of my answers here: I'm
> not the author of NNCP, so I can speak to my understanding of it,
> but not necessarily with authority.

ACK

> There is a mailing list at
> https://lists.cypherpunks.ru/pipermail/nncp-devel/ and the author is
> active there.

I'll have to check that out. Thank you for the link.

> With that out of the way, yes, that is indeed my understanding.
>
>
> The NNCP usage of the word "daemon" is a little loose.

Okay.... I'm using "daemon" to mean a process that is running all the
time, independent of what it does.

> So in UUCP, there is uucico, which is both the outbound caller and
> the inbound listener/daemon.

I've not (yet) messed with UUCP which allows incoming TCP connections on
ports 540 / 4031.

All of the UUCP that I've done has been initiated via a cron job (thus
the cron daemon) and / or login shells and / or specifically executed
commands. Meaning that in an idle state, there was no daemon (running
process) specifically for UUCP.

> In NNCP, these roles are split into three separate programs:
>
> nncp-daemon - the listener (roughly uucico -l)

I presume this is the daemon (which runs all the time) that listens for
incoming TCP connections.

> nncp-call - an on-demand caller (uucico -S)
>
> nncp-caller - the caller with scheduling rules (uucico -s if memory
> serves?)
>
> The "daemon" can be run as a daemon (I run it under systemd [again,
> don't shoot me!] quite easily). But it also has an -inetd option
> that, of course, can run under inetd... but is really just a "speak
> the protocol on stdin/stdout" so it could just as easily be run under
> ssh as with uucico.

ACK

The daemon / (x)inetd aspect is just used to convert incoming TCP
connections to STDIN / STDOUT to / from the NNCP processes on the local
system.

> I think that would be an accurate characterization, yes. I mean,
> both programs fundamentally store packets in regular files, so as
> long as you are careful not to trip over race conditions in either
> direction, it should be reasonably simple.

ACK

> (I wonder if sequence numbers make it at all more complicated on the
> UUCP side?

I don't know. I somewhat doubt it. I think the sequence numbers are
more for the call. -- Seeing as how we're talking about moving files
between queues, which is independent of and after the call, I doubt that
they would be much of an issue. But it wouldn't be the first time that
I'm wrong.

> This is one article about doing something similar with UUCP:
> https://www.dumain.com/posts/Forward_to_the_1970s_with_UUCP.../
> and it wasn't super simple. TBH I've never tried it.

$ReadingList++

> The NNCP tools for this also have built-in support for grades/nice,
> preventing duplicate packets (I can't remember if UUCP does this
> anymore; I seem to recall not?).

My understanding is that the duplication ~> error detection and
recovery, was done as part of the line protocol. As such, I think it's
somewhat outside of UUCP's queued store-and-forward mechanism.

> Generally yes, but I play with long-distance low-power radios (think
> 20 miles with 500mW or less) so it isn't ALWAYS that way even now!

I'm not completely surprised by that.

Aside: I'd like to learn more about what you're doing. Please reply
with where I can learn more. Do you have a blog, Twitter, etc?
(Perhaps direct email is better.)

> True, though TBH I don't think anybody has tried NNCP over raw serial
> lines yet. Must put that on my list...

:-)

> So I made an inartful simplification there.
>
> One could, in both UUCP and NNCP worlds, handle multi-hop mail routing
> by either:
>
> 1) Having the MTA do it (presumably via a smarthost for leaf nodes)
> - in a manner similar to how things happen over the Internet now
>
> 2) Doing this at the UUCP/NNCP protocol level
>
> So basically if you are going to have the MTA on node1 execute
> something like "nncp-exec -via node2,node3,node4 node5 rmail janedoe"
> (aka uux node2!node3!node4!node5!rmail janedoe) then the sending node
> needs to have the keys for all four of those nodes since it needs to
> prepare all of the onion encryption layers.
>
> If, on the other hand, node1 knows that "meh, I just send all my mail
> to node2 and it figures it out", then it would be doing "nncp-exec
> node2 rmail janedoe@node5" or something similar; node2 presumably
> would know to route that via node3 and so forth.

This is effectively the difference of where you put the bulk of the logic.

You can either do more of the work at the email layer, with direct
node-to-node email routing. Or you can do more of the work at the
transport layer, with node-to-node(-to-node) transport routing.

Method A [email] [email] [email] [email] [email]
[node1]---[node2]---[node3]---[node4]---[node5]

vs

Method B [email] [email]
[node1]---[node2]---[node3]---[node4]---[node5]

I'm eliding the smart host aspect because that would likely be the same
conceptual configuration of originating systems and first hop in either
system.

> I have never set up an MTA with full bang-path routing (my UUCP
> uses were all late enough to be essentially Internet leaf sites with
> RFC822-style addressing routed over UUCP) so TBH I don't quite know
> how the MTAs handled that, but my understanding is that is was pretty
> much on the user to know the full bang path from the local system to
> the recipient and it just handed this over to uux.

My experience is quite similar.

The experience I have with multi-node (bang) paths has more to do with
file copy (uucp / uuto) and command execution (uux).

From a purely efficiency point of view, it seems like it would be
better to have fewer MTA interactions with longer bang paths between them.

But none of that speaks to what a downstream MTA does with a message
that it won't accept.

> NNCP's config file actually lets you specify a default route to a
> known node, so there would be no need for explicit routing at the
> MTA level if you just do it all at the NNCP level.

Hum. I'd have to spend some time thinking about the implications of
such a default configuration on an MTA. Especially in idea of not being
an open relay. -- I guess that the MTA on the NNCP default could list
source nodes that it will allow relaying for.

As I think about it, by the time that rmail is invoked, it's too late to
actually reject a message and force the sending MTA to deal with it.
Instead, the receiving MTA will likely /need/ to /receive/ and then /
reject/ (bounce) the message. Lest messages make it to the receiving
MTA to only be dropped. Such drop behavior is antithetical to proper
operation of email.

> Doing it at the NNCP level would have a security benefit as well,
> since it would be neither necessary nor possible to decrypt it at
> MTAs along the way.

Agreed.

> Exim has an example config where you could send things to, eg,
> janedoe@node5.UUCP and it could have a routing lookup table --
> or just pass this to the lower level.

I feel like that the MTA should have access to the necessary information
to get to the next MTA in line.

> With NNCP's default "via" settings available in the config, the
> routing can be invisible to both the MTA and the user (but of course,
> the keys are needed).

Now I have to stop and ask: Does the user (human or MTA or other) have
any knowledge of the necessary public keys to make up the onion? Or is
that all handled by the NNCP transport layer? -- Much like the user
does not need to know the particulars about IPsec transport between two
systems as those details are handled at a lower layer and hidden from
the user.

> If the MTA were to call nncp-exec to a node that nncp-exec doesn't
> know about, it would get an immediate command failure from the pipe
> to nncp-exec and that would presumably turn into an immediate DSN.

One would hope.

> The difference is that with uux, the local system would only need
> to know about node2 and if, say, node3 doesn't know about node4,
> then that's an issue that surfaces later. (Technically this could
> still happen in NNCP; you could know about all those nodes but then
> node3 might not know about node4, but I'd think it would be more rare)

I think that this is highly dependent on if you're using Method A or
Method B above. The failures of each is different.

The MTAs of Method A would have the hard and fast error that the
{UUCP,NNCP} transport can't do it's job because of an unknown route.

The MTAs of Method B would not have a hard and fast error. They would
be dependent on some sort of {UUCP,NNCP} error message coming back and
being interpreted correctly.

Direct, single, and multiple intermediate systems (direct!user /
direct!single!user / direct!single!multiple!user) would probably all
have different types of errors.

> No. It would probably take an NNCP mapping project for this.

Hum.

> Also no.

Something to facilitate this might be interesting.

> They are essentially whatever you want them to be. Unlike with UUCP,
> an NNCP node name is essentially a convenience alias for the node's
> public key (akin to a hostname being a convenience alias for an IP
> address).

Okay.

> A node doesn't have to be known by the same name on every host,
> either, since the spool directories and all internal structures are
> based off the node's public key rather than its name.

IMHO aliases / a.k.a.s / nicknames can complicate things and possibly
cause routing loops.

Though, they may be able to be used to avoid a situation that I have yet
to find a solution for with UUCP. Node 2 going offline and never
returning in a node1!node2!node3!user situation. How does node1 manage
to re-route traffic to node3 which is online? This lack of redundancy /
re-routability has long bothered me.

> I don't think so. NNCP was designed primarily as a sort of private
> network of nodes - which is what I've most commonly seen UUCP evolved
> into (as there is no longer any global UUCP network) - but there is
> no particular reason it couldn't evolve in that direction.

I would advocate for some form of federation.

> This makes me happy somehow :-)

;-)

> Fair nitpick, yes.

:-)

> To be sure, I did bsmtp in that example because there weren't examples
> of doing it with UUCP already out there :-) rmail examples, otoh,
> are readily available.

Fair enough.

> I am not a total expert on either, but let's just say that email
> has security issues and both of those methods do also, particularly
> relating to spoofing.

I guess do to the nature of onion routing, the down stream system
doesn't have any knowledge of the upstream source, save for the previous
hop that sent the current packet / message / datagram / nomenclature?

So we are still reliant on things like DKIM to impose any form of
message authentication.

> Do I blindly receive? Pretty much yes :-)

See above. I now realize that it's blindly receive and then bounce -or-
loose mail.

> I've done both nncp-exec (uux) and nncp-file (uucp), actually. NNCP
> doesn't guarantee order of execution of packets. This happens to be
> fine for zfs receive, because it will detect when the incremental
> source makes a packet be un-receivable and exit with an error.
> nncp-toss (uuxqt) handles the error exit code as "try this again
> on the next run" so it will eventually converge on the appropriate
> solution even with a large backlog of packets to process.

I was thinking where an intermediate snapshot was lost. You know, the
snapshot that the subsequent snapshot was based on.

Though I guess this is a higher ZFS application layer problem and not
something that needs to be handled by {UUCP,NNCP} directly.

Layering can be tricky.

> I switched to using nncp-file (uucp) with a cron job to process it
> because I discovered nncp-exec stores the stdin in RAM on the sending
> system (Sergey is planning to fix that shortly).

Oops!

> I encode the dataset to receive as part of the filename (with s,/,@,g
> basically) and use the date as the leading part of the filename. So I
> can minimize, but not eliminate, instances of out-of-order execution
> there.

ACK

Encode ZFS application layer details in the file name that's copied from
source to destination by the underlying transport, be it UUCP or NNCP.

> A non-ZFS backup is more complicated and will probably need to use
> something like a sequence number to ensure incrementals are applied
> in the correct order. An exception may be for setups that just send
> a full backup every day and dump them into a deduplicating store
> (borgbackup, for instance) but that is probably not super practical
> for most.

*nod*nod*

> Hey, there've been worse uses of Usenet :-)

#true

> Oh I actually pointed out on the mailing list that it would be quite
> possible for those that need robust error handling (protocol g,
> for instance) to run NNCP over uucp.

Agreed.

> nncp-bundle -delete -tx node2 | uux node2!nncp-bundle -rx
>
> would pretty much do it :-)

ACK

> The NNCP protocol is documented at http://www.nncpgo.org/Sync.html#Sync
> but I'm not immediately familiar enough with the low-level details
> of both it and UUCP's to have an effective conversation on their
> relative merits.

Nor am I. I'm merely an inquisitive idiot.

> I guess I could say that the NNCP protocol is designed to be
> self-securing and reasonably delay-tolerant, even on half-duplex links.
> It also does integrity checks of the whole of received packets. Of
> course you can run uucico over SSH, but SSH is rather difficult to get
> running over some high-latency links; it strongly wants a full-duplex
> link and has handshake timeouts that don't work well with some of them.

I wonder how well TCP will do over the links that SSH is less than happy
with.

Is NNCP truly half duplex capable when it uses nncp-{bundle,batch}? Or
is that more a gateway of sorts to an intermediate format?

> NNCP also has a mode where the connection is held open reasonably
> indefinitely, and new packets queued for the remote would then be
> transmitted essentially immediately.

That sounds like an optimization, re-use of open (cached) links.

> Some messing with window sizes in UUCP protocols can get some decent
> performance out of half-duplex links, but I haven't made a comparison.

*nod*

> Of course UUCP has far better support for noisy lines and modems
> and things.

I'd say those problems are quite atypical today.

> So the things that drew me to NNCP are:
>
> 1) Pervasive encryption

I'll give you encryption. But I don't see it as pervasive. Because
pervasive means opportunistic to me. IMHO such would require something
like the federation and auto-discovery like I was talking about.

> 2) First-class support for alternative transports

I think that UUCP shares many similar underlying transports.

> I started using it, and my feeling was pretty much, "hey! This is
> UUCP 2.0! I like this!"

Yep.

> In fact, 19 years ago I wrote a long-forgotten tool called grunt
> that was designed to be layered atop uux. grunt permitted both file
> sending and remote execution. It used gpg for both encryption and
> authentication. My last commit on it, though, was in 2006. I mean,
> it worked, but it was a bit of a pain and completely ruled out most
> of uux's intelligence.
>
> I guess I would put it this way, in a very rough sense: NNCP is to
> UUCP what ssh is to rsh.

I can see that.

> I feel like neighbor-level transport security in UUCP is solved
> reasonably easily (uucico over ssh, etc.) But in the example above,
> node5 can't really tell that the packet originated on node1 and arrived
> at node5 unmodified with any degree of certainty.

Maybe it's my lack of understanding of onion routing, but I don't see
how this is any different with NNCP vs UUCP.

Note: I'm assuming that:

node5 only sees correct packets as being from node4.
node4 only sees correct packets as being from node3 and to node5.
node3 only sees correct packets as being from node2 and to node4.
node2 only sees correct packets as being from node1 and to node3.
node1 generates the node2(node3(node4(node5))) onion and sends it node2.

IMHO node5 has no idea where the packet / onion originated from, just a
path back to the unknown source.

> NNCP exposes the origin node's public key via an environment variable
> so it's all right there.

Does the original node add additional identifying information to the packet?

Or do I have an incorrect understanding of onion routing?

> Basically you get end-to-end encryption with NNCP, as a fundamental
> part of the protocol. Intermediate hops can't even tell what the
> ultimate destination of a packet is, let alone what command it's
> going to run.

Agreed.

> It also makes some things easier (nncp-xfer/nncp-bundle). But it's
> not a drop-in replacement like ssh was for rsh.
>
> So it's not my intent to drop into a UUCP group and go "hey y'all
> should be using something else". That would not be cool, and would
> not be accurate anyhow. UUCP's still got its place too. I'm just
> trying to say "hey, there's another UUCP-ish thing out there now,
> you might be interested."

Understood.

That's how I took your message.

--
Grant. . . .
unix || die