pathalias program

[Radim Kolář]

Can you point me where can I get pathalias program?

[Grant Taylor]

On 8/24/19 12:36 PM, Radim Kolář wrote:
> Can you point me where can I get pathalias program?

I can't point you to it myself.

I have relatively recently been researching it. I know that I have come
across mentions of sources for it.

Everything I've seen has been for systems 20+ years old. So I have
serious questions about if it would actually compile and run on
contemporary OSs.

Can I ask what you are doing that you need pathalias for? — I've been
wondering what contemporary uses would be in the modern Internet.

Depending on how things interface with pathalias, it might be better to
create something new that will produce the same type of output. But I
can't even tell you what that is. I think that pathalias built a map,
specific to the local machine, of the best way to reach remote UUCP
destinations. I suspect that would be fairly static, simple, and easy
to manually generate on contemporary UUCP networks. (I say this
expecting most contemporary UUCP networks to be small and very few
systems to cross. ¿full mesh?)



--
Grant. . . .
unix || die

[Radim Kolář]

http://freebsd.sin.openmirrors.asia/pub/FreeBSD/ports/local-distfiles/dinoex/

[b...@ripco.com]

Grant Taylor <gta...@tnetconsulting.net> wrote:

> Depending on how things interface with pathalias, it might be better to
> create something new that will produce the same type of output. But I
> can't even tell you what that is. I think that pathalias built a map,
> specific to the local machine, of the best way to reach remote UUCP
> destinations. I suspect that would be fairly static, simple, and easy
> to manually generate on contemporary UUCP networks. (I say this
> expecting most contemporary UUCP networks to be small and very few

> systems to cross. ?full mesh?)


I was wondering about this myself, we used to do a lot of uucp around here
back in the 90's, both usenet and mail. It actually didn't taper off until
the early 2000's when the last feed we had got with the program and went
live on the net.

There was something in the back of my head with pathalias where it needed
some data, like the maps they used to post in comp.mail.maps, long dead.

I'm pretty sure for one machine to another, you just don't need it.

These days, I can't see why there would be more than 2 machines involved
with anything. The path would be a direct route, I think.

-bruce
b...@ripco.com

[Grant Taylor]

On 8/28/19 5:42 AM, b...@ripco.com wrote:
> There was something in the back of my head with pathalias where it
> needed some data, like the maps they used to post in comp.mail.maps,
> long dead.

That's my understanding as well.

> I'm pretty sure for one machine to another, you just don't need it.

No, you do not. I've configured and used UUCP between linked machines
multiple times without pathalias.

> These days, I can't see why there would be more than 2 machines
> involved with anything. The path would be a direct route, I think.

My use case was a bastion host acting as an intermediary between two
hosts that couldn't establish a direct link. It worked quite well.

[Radim Kolář]

I am working on pathalias program to make it compile without warnings:

https://gitlab.com/uucpnet/pathalias

I found another pathalias (more modern) in smail 3. I was not able to find historic smail 2.7.

Plan is to make distributed map file, so we do not need to have direct connections. Next scheduled work is to add SOCKS port to uucp.

[Grant Taylor]

On 9/1/19 12:40 AM, Radim Kolář wrote:
> I am working on pathalias program to make it compile without warnings:
>
> https://gitlab.com/uucpnet/pathalias

:-)

> Plan is to make distributed map file, so we do not need to have direct
> connections.

Okay.

How many people is "we" that are still using UUCP?

What's wrong with direct connections? Especially in the Internet age
where it's usually trivial to have direct connections?

What will a "distributed map" look like?

Don't people have to be willing to relay files / messages / packets /
?term? for other nodes to be able to route something through them?

> Next scheduled work is to add SOCKS port to uucp.

What does that mean? Are you talking about the SOCKS proxy server /
client? Or something else?

[Radim Kolář]

> How many people is "we" that are still using UUCP?

I know about several UUCP networks, each with 20-60 members.

> What's wrong with direct connections? Especially in the Internet age
> where it's usually trivial to have direct connections?

Firewalls, NAT, you have to be always online.

> What will a "distributed map" look like?

It will be like it always was. Nobody is forcing you to be always online, using ssh transport, pgp encrypted rmail packets or something like that. Only centralised thing will be map file. You want to join - find somebody who is willing to be connected with you, make agreement about protocol and register uucp name at send map entry.

https://groups.google.com/forum/#!msg/comp.mail.maps/Oj6Y2yUlMk4/nwmH6oh6JMcJ

> Don't people have to be willing to relay files / messages / packets /
> ?term? for other nodes to be able to route something through them?

You can choose if you want to route mail, you dont have to, but you need to maintain correct map entry.

> > Next scheduled work is to add SOCKS port to uucp.
> What does that mean? Are you talking about the SOCKS proxy server /
> client? Or something else?

SOCKS client

[Andy Valencia]

=?UTF-8?B?UmFkaW0gS29sw6HFmQ==?= <kolar...@gmail.com> writes:
> > What's wrong with direct connections? Especially in the Internet age=20

> > where it's usually trivial to have direct connections?

> Firewalls, NAT, you have to be always online.

It'd nice if your peers were known quantities. The whole "hey, anybody,
drop mail in port 25" thing has turned out pretty ugly. If each
node vets its connections, and if you had some crypto signing so
paths can't be spoofed, seems like you could push back on some
systemic misbehaviors.

-----------------
Andy Valencia
Home page: https://vsta.org/andy/
Contact: https://vsta.org/contact/andy.html

[Grant Taylor]

On 9/3/19 12:54 PM, Radim Kolář wrote:
> I know about several UUCP networks, each with 20-60 members.

Interesting.

I'd be interested in learning about them.

> Firewalls, NAT, you have to be always online.

I would think that firewalls and NAT would be overcome as part of
establishing connections. Or are you implying that using things like
outbound UUCP through a stateful (NATing) firewall is a non-issue for UUCP?

Yes, UUCP's store-and-forward is nice.

> It will be like it always was.

Thank you for the link to an old map.

> Nobody is forcing you to be always online, using ssh transport,
> pgp encrypted rmail packets or something like that.

Nothing about SMTP strictly /requires/ you to be always online. You do
need /a/ receiving server to be accessible while the sending server is
trying to connect. But I think the same thing can be said about UUCP.

I get optionally using SSH as a transport.

I'm ignorant of people using PGP, et al., to encrypt rmail packets.

> Only centralised thing will be map file. You want to join - find
> somebody who is willing to be connected with you, make agreement
> about protocol and register uucp name at send map entry.

:-)

> https://groups.google.com/forum/#!msg/comp.mail.maps/Oj6Y2yUlMk4/nwmH6oh6JMcJ

>
> You can choose if you want to route mail, you dont have to, but you
> need to maintain correct map entry.

ACK

> SOCKS client

Are you wanting to add SOCKS client to the uucp binaries?

What sort of connections are you supporting?

Are you wanting to be able to route them through SOCKS?

I'd be inclined to put the SOCKS connectivity part in other things
around uucp binaries. E.g. something that presents a virtual serial
port and gateways to remote TCP connections which are routed through
something like TUN-to-SOCKS. STDIO is even easier. socat is a
wonderful tool. Admittedly, socat supports acting as a SOCKS client.

[Grant Taylor]

On 9/3/19 6:34 PM, Andy Valencia wrote:
> It'd nice if your peers were known quantities.

I'll agree that it would be /nice/ to know things about peers. But I
don't think that's a /requirement/.

I think it largely depends if you view your peers as terminal (B2B type)
connections, or transit.

> The whole "hey, anybody, drop mail in port 25" thing has turned out
> pretty ugly.

Yep.

> If each node vets its connections,

What does "vet" mean to you in this context? Are you relaying
everything / anything to and / or from a peer? Does this include things
that they relay for other peers? Are you selectively relaying known
addresses to avoid Joe Jobs? What?

I would think that most entities would have a UUCP gateway, be it theirs
or outsourced, and that said gateway would be able to establish direct
connections with other UUCP systems. Such a UUCP gateway would
inherently be configured to (selectively) relay as part of it's gateway
role.

I'm having trouble understanding why / how many entities would need
multi-hop UUCP paths that can't form a direct connection. Think
external bastion hosts / gateways for organizations. I get why things
behind such gateways would need to pass through it and couldn't
establish direct inbound (or possibly outbound) connections.

I can also see why organizations might not want the hosts behind such
gateways to be public knowledge. — There's no point in advertising
something publicly if the public doesn't need the information.
Especially when you can give the information to the peers that need it.

> and if you had some crypto signing so paths can't be spoofed, seems
> like you could push back on some systemic misbehaviors.

That sounds like you're fundamentally altering how various UUCP
implementations operate.

I would think that a modern UUCP path would be relatively short.

hostA1\ /hostB1
hostA2-gatewayA-(internet)-gatewayB-hostB2
hostA3/ \hostB3

As such, I'd think that gatewayA and gatewayB could relatively easily
configure filtering of what hosts they will allow inbound and / or
outbound relaying for.

Admittedly, it's been a few years since I looked at the filtering syntax
of Taylor UUCP (no known relation) to say for sure, but I *REALLY*
thought that it was possible to do such filtering. … Skimming the
documentation, it looks like forward-to and forward-from in the sys file
are what I'm talking about. I'd have to play with things to learn what
the fan-out is and how it relates to the connecting host vs further away
hosts passing through said host.

I feel like gatewayA and gatewayB can judiciously configure their UUCP
such that it would be nearly impossible for spoofing. E.g. gatewayA
trusts that gatewayB has properly configures things such that gatewayB
will only forward from hostB1–hostB3 and that each of those hosts is not
doing any forwarding of their own. And vice versa.

[Andy Valencia]

Grant Taylor <gta...@tnetconsulting.net> writes:
> What does "vet" mean to you in this context?

I mean: I'll let you route through me because I have confidence in you,
and what you accept.

> Does this include things
> that they relay for other peers? Are you selectively relaying known
> addresses to avoid Joe Jobs? What?

The former was mostly in my mind. If paths are signed, you can actually
filter a host beyond a peer. But I'm thinking of the UUCP graph of
connections because creates an environment where you will de-peer a peer
of yours which has gone bad. If you don't, you might be de-peered
yourself.

> I'm having trouble understanding why / how many entities would need
> multi-hop UUCP paths that can't form a direct connection.

I'm thinking "all". Anybody (in the Internet sense) _can_ reach to
you. But then each node has to globally judge each submission. (Thus
my comment about port 25.) Thus connectivity is viewed in the UUCP
style, as a graph. Each node answers to their peers.

Within that, you can certainly optimize. Using crypto techniques, one
node can reach to another and say "here's the mail which would have
traversed x!y!z, but I have transitively signed it so you know it
_could_ have traversed that path, even though physically it didn't".
And the recipient node is free--for any reason--to say "nah, I don't
buy your crypto hashes, so send it Old School". Then x, y, and z
will see (and forward) it. Or "y" might have written you off,
which is why your signed shortcut wasn't accepted. And "y" will
decline to forward.

So direct mail delivery is an optimization, rather than at the core of
the architecture. When you're thinking about consequences of bad
behavior, you're thinking about the graph of peers, and how that
graph will change as one part of the graph becomes a bad actor.

> That sounds like you're fundamentally altering how various UUCP
> implementations operate.

Yes, embrace the classic model, then add complexity to reach an
optimization. The fundamental change--crypto sigs for short
cuts--is such an optimization.

That said, I think the path should be augmented with something using
crypto signature hardening--we all saw the hijinks which
otherwise could be played. kremvax was funny, but hard-to-hunt
spam and hate mail was not funny at all.

Andy