• pathalias program

    From =?UTF-8?B?UmFkaW0gS29sw6HFmQ==?=@21:1/5 to All on Sat Aug 24 11:36:21 2019
    Can you point me where can I get pathalias program?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Tue Aug 27 15:54:06 2019
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?UmFkaW0gS29sw6HFmQ==?=@21:1/5 to All on Tue Aug 27 22:33:07 2019
    http://freebsd.sin.openmirrors.asia/pub/FreeBSD/ports/local-distfiles/dinoex/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bje@ripco.com@21:1/5 to Grant Taylor on Wed Aug 28 11:42:19 2019
    Grant Taylor <gtaylor@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
    bje@ripco.com

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to bje@ripco.com on Wed Aug 28 20:25:28 2019
    On 8/28/19 5:42 AM, bje@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.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?UmFkaW0gS29sw6HFmQ==?=@21:1/5 to All on Sat Aug 31 23:40:22 2019
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Mon Sep 2 10:18:05 2019
    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?



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?UmFkaW0gS29sw6HFmQ==?=@21:1/5 to All on Tue Sep 3 11:54:49 2019
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Valencia@21:1/5 to kolar.radim@gmail.com on Tue Sep 3 17:34:53 2019
    =?UTF-8?B?UmFkaW0gS29sw6HFmQ==?= <kolar.radim@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Wed Sep 4 08:58:20 2019
    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. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to Andy Valencia on Wed Sep 4 11:01:56 2019
    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.



    --
    Grant. . . .
    unix || die

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andy Valencia@21:1/5 to Grant Taylor on Thu Sep 5 11:38:49 2019
    Grant Taylor <gtaylor@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)