What is the latest version of Internet Rex for linux?

I got a hold of a version 2.31 not too long ago. I installed it, but it
will not run. It keeps giving me a "segmentation fault," which, in
researching on the interwebs, seems to mean there is a code error. As IREX
is not open source, there is no way for me to fix that one, if that is
right.

The version I have on my OS/2 box is 2.29, which I assume is the latest
version for that platform.

I would like to get IREX working on my debian box so that I can finish
moving the board to that box & finally retire the OS/2 box.

The other alternative is to get a few email lists that I am porting into my echos moved from IREX to another package. That is really all I am using it
for now... well, that and FTN ftp connections that I have not been able to
get working using fidopoll.

Mike

##Mmr 2.61(beta).


--- GTMail 1.26
* Origin: CCO BBS * 502/875-8938 * capcity2.synchro.net (1:2320/105.1)

What is the latest version of Internet Rex for linux?

I got a hold of a version 2.31 not too long ago. I installed it, but
itwill not run. It keeps giving me a "segmentation fault," which, in researching on the interwebs, seems to mean there is a code error. As
IREX
is not open source, there is no way for me to fix that one, if that is right.

The version I have on my OS/2 box is 2.29, which I assume is the latest version for that platform.

As I understand things, any version above 2.29 (irregardless of OS) is most likely a very unstable beta. Irex is NOT open source, nor is the source code available, although I have been assured by the author that the source is NOT lost. I understand that 'life' got in the way of it's development, so the project got shelved.

I would like to get IREX working on my debian box so that I can finish moving the board to that box & finally retire the OS/2 box.

The other alternative is to get a few email lists that I am porting into
my
echos moved from IREX to another package. That is really all I am using
it
for now... well, that and FTN ftp connections that I have not been able
to
get working using fidopoll.

All *I* use irex for is the binkd protocol, nothing else, and 2.29 has been rock stable her for many years under OS/2. *I* never saw any need for any other use of iRex on my system.







.....Bob

--- GEcho/32 & IM 2.50
* Origin: http://www.fidonet.ca (1:140/12)

* An ongoing debate between Mike Powell and All rages on ...

What is the latest version of Internet Rex for linux?

v2.29 is the last released version, v2.31 is the last Beta (IF you find that you need it, most DON'T)

See http://cmech.dynip.com/filebase.bbs/irex for the 2.29 archives (file IREXL229.ZIP is for linux, unzip to lower case names!), and check the beta directory there for v2.31 if needed.

NOTE!!! Current linux versions use a kernel that is incompatible with the DNS lookup logic somehow, so you HAVE to specify absolute IP addresses, as nothing gets resolved. :(


.- Keep the faith, --------------------------------------------------.
| |
| Ben aka cMech Web: http|ftp|binkp|telnet://cmech.dynip.com |
| Email: fido4cmech(at)lusfiber.net |
| Home page: http://cmech.dynip.com/homepage/ | `----------- WildCat! Board 24/7 +1-337-984-4794 any BAUD 8,N,1 ---'

... It grows the potatoes of defiance, which flourish underground.
--- GoldED+/W32-MSVC v1.1.5-b20161221 ... via Mystic BBS!
* Origin: FIDONet - The Positronium Repository (1:393/68)

Re: Latest version for linux?
By: Mike Powell to All on Sat Feb 18 2017 12:01:00

I got a hold of a version 2.31 not too long ago. I installed it, but it will not run. It keeps giving me a "segmentation fault," which, in researching on the interwebs, seems to mean there is a code error. As IREX is not open source, there is no way for me to fix that one, if that is right.

The version I have on my OS/2 box is 2.29, which I assume is the latest version for that platform.

I would like to get IREX working on my debian box so that I can finish moving the board to that box & finally retire the OS/2 box.

Irex has a problem working in any Nix environment. It is hard wired to some old packages as I recall.

The other alternative is to get a few email lists that I am porting into my echos moved from IREX to another package. That is really all I am using it for now... well, that and FTN ftp connections that I have not been able to get working using fidopoll.

--- SBBSecho 3.00-Win32
* Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)

* An ongoing debate between Mike Powell and All rages on ...

I got a hold of a version 2.31 not too long ago. I installed it, but
it will not run. It keeps giving me a "segmentation fault," which, in

FYI ... from the Beta change log:

=== Cut ===
! Point of information
+ New feature
- Bug fix

Version 2.31
------------

! only the first 32K of message headers are scanned when applying rules
- fix updating of bundle counters for compressed mail
- make Rex more resistent to miscompiled nodelists
- Rex wasn't correctly removing local copies of files when MIRRORing an
FTP directory
- change reporting an M_ERR during file receive as an unexpected command
to an error
- request CRC and MD5 mode on connection for BinkP server
- DOS style T-Mail fileboxes for points weren't being properly read
- numbered packed archives under Linux weren't getting named properly
- POP3 logins could return invalid strings when no local hostname was
configured under OS/2
- CAPA sent before login gave a spurious CAPA response in the POP3 server
- Rexcfg was crashing when configuring new newsgroups with no email addresses
setup

Version 2.30
------------
! There is *no*... version 2.30.

Version 2.29
------------
October 21, 2001

+ dupe detection on gated messages can now be set at the gate itself instead
of relying on the mail tosser
! UUCP processing in Rex's SMTP daemon can now handle infinite (limited by
available memory) email address on one C rmail line
! Rex now lingers on the sockets for certain servers to allow clients
which incorrectly blast data through to still work properly
- Rex wasn't properly constructing nodelist information for BinkP nodes
which listed the site address after the flag instead of in the BBS name
- resend requests would result in queue entries which never got removed
when they expired
- outbound FTP client connections now bind to port 20 locally in PASV mode
- Rex could crash if it couldn't create a new packet for inbound gated mail
- a SEAT message with only 2 of 3 required SEAT lines would crash Rex
- updated packing info was not being saved in 32 bit versions
- Rex now correctly processes multi-section UUencoded files with additional
information between the section line and beginning of the file
- seems to fix an unreproducible problem where PX queue entries remained
locked after unsuccessful connection attempts
- long subject lines in gated netmail messages could result in random message
chunk sizes for attached files

Version 2.28 & below snipped ... see file History.Txt in any Beta archive.

=== Cut ===

.- Keep the faith, --------------------------------------------------.
| |
| Ben aka cMech Web: http|ftp|binkp|telnet://cmech.dynip.com |
| Email: fido4cmech(at)lusfiber.net |
| Home page: http://cmech.dynip.com/homepage/ | `----------- WildCat! Board 24/7 +1-337-984-4794 any BAUD 8,N,1 ---'

... Tagline affixed in compliance with Stuffed Articles Act.
--- GoldED+/W32-MSVC v1.1.5-b20161221 ... via Mystic BBS!
* Origin: FIDONet - The Positronium Repository (1:393/68)

| Irex has a problem working in any Nix environment. It is hard wired to some | old packages as I recall.

Now that you mention that, I remember reading that before. :( Thanks!

Mike

##Mmr 2.61(beta). !link JD 02-18-17 22:33


--- GTMail 1.26
* Origin: CCO BBS * 502/875-8938 * capcity2.synchro.net (1:2320/105.1)

Re: Latest version for linux?
By: Mike Powell to Joe Delahaye on Sat Feb 25 2017 10:43 am

Now that you mention that, I remember reading that before. :( Thanks!

Hey Mike,

I see you are no longer using the 271 (i think) zone to gate in your weather echo and have it in zone 1.

Is it possible to have internet rex insert an origin line on your incoming messages? It's been brought to my attention that Origin lines are required per FTSC rules... plus without origin lines some tossers will tag it with another BBS's origin line and pass it on causing other dupe problems.

Thanks much

Allen


... A rolling stone gathers momentum.
--- SBBSecho 3.00-Win32
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

On 2017 Mar 05 21:04:22, you wrote to Mike Powell:

Now that you mention that, I remember reading that before. :( Thanks!

Hey Mike,

I see you are no longer using the 271 (i think) zone to gate in your weather echo and have it in zone 1.

it wasn't being gated properly... if it were, there would have been two origin lines and other control lines to enable netmail replies across the zone boundry
to work...

Is it possible to have internet rex insert an origin line on your
incoming messages? It's been brought to my attention that Origin
lines are required per FTSC rules... plus without origin lines some tossers will tag it with another BBS's origin line and pass it on
causing other dupe problems.

i don't think i've seen what you are speaking of in relation to mike's postings
in fidonet...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... "REP.. REP.. REP.." - Frog with a QWK packet stuck in his throat
---
* Origin: (1:3634/12.73)

Re: Latest version for linux?
By: mark lewis to Allen Prunty on Sun Mar 05 2017 10:00 pm

i don't think i've seen what you are speaking of in relation to mike's postings in fidonet...

Look in the weathe echo... the recent postings are coming from a point off of his new node 1:2320/107.99 with no origin line at all.

Allen


... Freedom is for everyone. Or no one.
--- SBBSecho 3.00-Win32
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

* An ongoing debate between Allen Prunty and mark lewis rages on ...

Look in the weathe echo... the recent postings are coming from a point
off of his new node 1:2320/107.99 with no origin line at all.

I see the point address but they all have a Tearline and proper Origin :) What reader are you using? {shrug}


.- Keep the faith, --------------------------------------------------.
| |
| Ben aka cMech Web: http|ftp|binkp|telnet://cmech.dynip.com |
| Email: fido4cmech(at)lusfiber.net |
| Home page: http://cmech.dynip.com/homepage/ | `----------- WildCat! Board 24/7 +1-337-984-4794 any BAUD 8,N,1 ---'

... Pick two: 1)Fast 2)Right 3)Cheap 4)Windows (counts as 2)
--- GoldED+/W32-MSVC v1.1.5-b20161221 ... via Mystic BBS!
* Origin: FIDONet - The Positronium Repository (1:393/68)

Re: Re: Latest version for linux?
By: Ben Ritchey to Allen Prunty on Sun Mar 05 2017 11:47 pm

* An ongoing debate between Allen Prunty and mark lewis rages on ...

I see the point address but they all have a Tearline and proper Origin :) What reader are you using? {shrug}

I'm only reporting what someone has asked me as NC to inquire about (should not take you long to figure out who).

I noticed some did import into synchronet without origin lines and it is comign from INternet Rex. Maybe they are working now.

They are from the list that is imported in.

Allen


... But, He has not one redeeming vice.
--- SBBSecho 3.00-Win32
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

On 2017 Mar 05 23:35:32, you wrote to me:

i don't think i've seen what you are speaking of in relation to
mike's postings in fidonet...

Look in the weathe echo... the recent postings are coming from a point
off of his new node 1:2320/107.99 with no origin line at all.

i hadn't caught the missing origin line... i was the one that told mike about the improper gating being done so it was switched back to a point address... have you let him know about the missing origin line? i hate being the bad guy all the time :/

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Y'all are a pretty crazy bunch of people, like myself.
---
* Origin: (1:3634/12.73)

Re: Latest version for linux?
By: mark lewis to Allen Prunty on Mon Mar 06 2017 11:55 am

i hadn't caught the missing origin line... i was the one that told mike about the improper gating being done so it was switched back to a point address... have you let him know about the missing origin line? i hate being the bad guy all the time :/

And I know what it is to catch flames over a bad kludge or missing origin.

Allen
--- SBBSecho 3.00-Win32
* Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)

Is it possible to have internet rex insert an origin line on your incoming messages? It's been brought to my attention that Origin lines are required per
FTSC rules... plus without origin lines some tossers will tag it with another BBS's origin line and pass it on causing other dupe problems.

It already does.

Mike

---
* SLMR 2.1a * My grubby halo, a vapour trail in the empty air...


--- GTMail 1.26
* Origin: CCO BBS * 502/875-8938 * capcity2.synchro.net (1:2320/105.1)

it wasn't being gated properly... if it were, there would have been two origin >lines and other control lines to enable netmail replies across the zone boundr >to work...

No, No, No, because it wasn't being gated at all. The whole dang problem was caused because IREX would only pass mail to a "host" system with a full net node, not a point. When I switched my systems around and couldn't get IREX
to work under linux, I got stuck. The fake zone was a temporary work around until I got it working (impossible because it is hard-wired to some old, old dependencies) or until I got a full node number for what is really just
"half" of the BBS.

Basically, it was getting "gated" from one part of my bbs to another, but it wasn't going anywhere else.

And I still don't understand how we are able to have a multi-zone net if all
of our software has so many issues with zone boundaries. I see messages from Zones 2 and 3 all the time that are not "gated" into Zone 1. Unless there is also some restrictions on what net #s each zone can use (which, IMHO, makes zones really, really pointless), it does not make any sense to me why it matters if the node is in Zone 1, 2, 3, or 123. :)

Mike

---
* SLMR 2.1a * A restless eye across a weary room...


--- GTMail 1.26
* Origin: CCO BBS * 502/875-8938 * capcity2.synchro.net (1:2320/105.1)

On Mon, 06 Mar 2017, Mike Powell wrote to Mark Lewis:

it wasn't being gated properly... if it were, there would have
been two origin lines and other control lines to enable netmail
replies across the zone boundry to work...

No, No, No, because it wasn't being gated at all. The whole dang
problem was caused because IREX would only pass mail to a "host"
system with a full net node, not a point.

ahhhh... i've never worked with IREX and didn't know it was even involved... i'd be doing this with GIGO like i do with the the TeamOS2 mailing list and the
two OS/2 related yahoo groups i gate to fidonet... the SMTP takes the inbound messages and stores them in .BAG files which GIGO then converts into PKTs with those messages now carrying an AREA line for the destination echo they belong in... but this is an OS/2 only solution... i don't think that GIGO has been ported to any other OSes and i have no idea what could be done for winwhatever with any other gating tools...

it should be also noted that there's a difference between gating emails to netmails, gating mailing lists to echos and gating news groups to echos... then
there's the other gating that's done between different FTN networks and even FTN networks and other networks that use a completely different means of packaging and transportation than what FTNs and the internet use... RIME/PCRelay used a form of QWK which is why QWK offline readers were so easy for the users to use... i'm not sure what WWIV used but it was similar to internet, IIRC... at least its moderated areas operated like moderated news groups where posts were sent via private email to the moderator for approval and posting to the area or they were rejected... proactive moderation vs fidonet's reactive moderation...

When I switched my systems around and couldn't get IREX to work
under linux, I got stuck. The fake zone was a temporary work
around until I got it working (impossible because it is hard-wired
to some old, old dependencies) or until I got a full node number
for what is really just "half" of the BBS.

ohhh... yeah, i can feel the pain...

Basically, it was getting "gated" from one part of my bbs to
another, but it wasn't going anywhere else.

what i'd do is to just get another node number from your NC and list it as another AKA on your BBS... then IREX should be able to operate fine... then for
that echo you use the new AKA as the origin address and all your other areas stay using the existing origin AKA...

i'm not sure why IREX couldn't just gate the mailing list to your existing node
number?? that should be a straight forward gating process like i do here with GIGO...

And I still don't understand how we are able to have a multi-zone
net if all of our software has so many issues with zone
boundaries. I see messages from Zones 2 and 3 all the time that
are not "gated" into Zone 1.

because they are not gated line domain crossing stuff... there did used to be zonegates in fidonet and they handled throwing netmail over the ponds... they might have also handled echomail but there was nothing special needed to be done since the fidonet domain compromises more than one zone... when calls got cheaper, many folks started biting the bullet for their international connections and went direct during the cheapest time they could find in their billing... then the internet came along and cost for long distance comms is now
negligable...

Unless there is also some restrictions on what net #s each zone
can use (which, IMHO, makes zones really, really pointless),

there was a math formula to use... it didn't get explained very well or in time
when other zones came along so they kinda did their own thing with their numbering... Z2 went through a huge row when they did a complete renumbering of
net numbers at one time to conform to policy's "local telephone calling area" stuff... but nets can be duplicated across zones... there's no problem with that... for echomail you just strip out the seenbys when you cross the zone boundry so that duplicate net/node systems will be able to receive the messages... you have to do this crossing domains with proper FTN<->FTN gating anyway...

the ""problem"", such as it is, is that today some people are specifically trying to "kill off" the traditional FTN distribution format which is backbone oriented... they are, instead, connecting to one echo from several different systems and eventually there's several huge dupe loops... the so-called goal is
to eliminate a SPOF (single point of failure) but in reality it is eliminating a lot more and taking away moderator's rights in their echos since now it is impossible to remove a problem user from an echo for a time period...

it does not make any sense to me why it matters if the node is in
Zone 1, 2, 3, or 123. :)

because zones 1,2 and 3 are all in the Fidonet FTN (fidonet technology network)... zone 123 is a completely different FTN with their own policy and rules and maybe even their own set of multiple zone numbers...

)\/(ark


* Origin: (1:3634/12)

On Mon, 06 Mar 2017, Mike Powell wrote to Mark Lewis:

it wasn't being gated properly... if it were, there would have
been two origin lines and other control lines to enable netmail
replies across the zone boundry to work...

No, No, No, because it wasn't being gated at all. The whole dang
problem was caused because IREX would only pass mail to a "host"
system with a full net node, not a point.

ahhhh... i've never worked with IREX and didn't know it was even

I have used Irex to feed net, echo mail, and files to a point, with absolutely no problems, so whoever is telling you this story is wrong, and probably has not configured his Irex properly. I als know others who have done as I have, if that helps.

involved... i'd be doing this with GIGO like i do with the the TeamOS2 mailing list and the two OS/2 related yahoo groups i gate to fidonet...
the SMTP takes the inbound messages and stores them in .BAG files which
GIGO then converts into PKTs with those messages now carrying an AREA
line for the destination echo they belong in... but this is an OS/2 only solution... i don't think that GIGO has been ported to any other OSes
and i have no idea what could be done for winwhatever with any other
gating tools...

it should be also noted that there's a difference between gating emails
to netmails, gating mailing lists to echos and gating news groups to echos... then there's the other gating that's done between different FTN networks and even FTN networks and other networks that use a completely different means of packaging and transportation than what FTNs and the internet use... RIME/PCRelay used a form of QWK which is why QWK offline readers were so easy for the users to use... i'm not sure what WWIV used
but it was similar to internet, IIRC... at least its moderated areas operated like moderated news groups where posts were sent via private
email to the moderator for approval and posting to the area or they were rejected... proactive moderation vs fidonet's reactive moderation...

When I switched my systems around and couldn't get IREX to work
under linux, I got stuck. The fake zone was a temporary work
around until I got it working (impossible because it is hard-wired
to some old, old dependencies) or until I got a full node number
for what is really just "half" of the BBS.

ohhh... yeah, i can feel the pain...

Basically, it was getting "gated" from one part of my bbs to
another, but it wasn't going anywhere else.

what i'd do is to just get another node number from your NC and list it
as another AKA on your BBS... then IREX should be able to operate
fine... then for that echo you use the new AKA as the origin address and
all your other areas stay using the existing origin AKA...

i'm not sure why IREX couldn't just gate the mailing list to your
existing node number?? that should be a straight forward gating process
like i do here with GIGO...

And I still don't understand how we are able to have a multi-zone
net if all of our software has so many issues with zone
boundaries. I see messages from Zones 2 and 3 all the time that
are not "gated" into Zone 1.

because they are not gated line domain crossing stuff... there did used
to be zonegates in fidonet and they handled throwing netmail over the ponds... they might have also handled echomail but there was nothing
special needed to be done since the fidonet domain compromises more than
one zone... when calls got cheaper, many folks started biting the bullet
for their international connections and went direct during the cheapest
time they could find in their billing... then the internet came along
and cost for long distance comms is now negligable...

Unless there is also some restrictions on what net #s each zone
can use (which, IMHO, makes zones really, really pointless),

there was a math formula to use... it didn't get explained very well or
in time when other zones came along so they kinda did their own thing
with their numbering... Z2 went through a huge row when they did a
complete renumbering of net numbers at one time to conform to policy's "local telephone calling area" stuff... but nets can be duplicated
across zones... there's no problem with that... for echomail you just
strip out the seenbys when you cross the zone boundry so that duplicate net/node systems will be able to receive the messages... you have to do
this crossing domains with proper FTN<->FTN gating anyway...

the ""problem"", such as it is, is that today some people are
specifically trying to "kill off" the traditional FTN distribution
format which is backbone oriented... they are, instead, connecting to
one echo from several different systems and eventually there's several
huge dupe loops... the so-called goal is to eliminate a SPOF (single
point of failure) but in reality it is eliminating a lot more and taking away moderator's rights in their echos since now it is impossible to
remove a problem user from an echo for a time period...

it does not make any sense to me why it matters if the node is in
Zone 1, 2, 3, or 123. :)

because zones 1,2 and 3 are all in the Fidonet FTN (fidonet technology network)... zone 123 is a completely different FTN with their own policy
and rules and maybe even their own set of multiple zone numbers...

)\/(ark

* Origin: (1:3634/12)

--- GEcho/32 & IM 2.50
* Origin: http://www.fidonet.ca (1:140/12)

ahhhh... i've never worked with IREX and didn't know it was even involved... i'd be doing this with GIGO like i do with the the TeamOS2 mailing list and

th

two OS/2 related yahoo groups i gate to fidonet... the SMTP takes the inbound messages and stores them in .BAG files which GIGO then converts into PKTs

with

those messages now carrying an AREA line for the destination echo they belong in... but this is an OS/2 only solution... i don't think that GIGO has been ported to any other OSes and i have no idea what could be done for

winwhatever

with any other gating tools...

GIGO, eh? Well, that wouldn't help me get everything moved to linux, but
IREX (and "half" the board) are still running under OS/2 Warp 4. Is it still supported?

FTN networks and other networks that use a completely different means of packaging and transportation than what FTNs and the internet use... RIME/PCRelay used a form of QWK which is why QWK offline readers were so easy for the users to use... i'm not sure what WWIV used but it was similar to internet, IIRC... at least its moderated areas operated like moderated news groups where posts were sent via private email to the moderator for approval and posting to the area or they were rejected... proactive moderation vs fidonet's reactive moderation...

I am familiar with non-FTN. GT Power, which is my main BBS software, used to have its own network with its own network software. Similar to FTN in that
it used net/node numbers and had netmail... not-so-similar in that all echo mail went to the moderator's system first before echoing back out to the network. Supposedly, the GT author did it that way because he did not like
how FIDO echoes did not have the ability to be completely moderated... or proatively moderated, as you put it.

I like it, but it pretty much died some time after support for the product died. We did get some Y2K patches, but the echomail system in the past
couple of years "rolled-over" to 5-digit julian dates, which broke
everything for GT echomail 8.3-based file naming format. No worries because
I was the only system left bagging mail that way anyway, and supplying no
one. <GRIN>

I actually started on writing a utility that would fix the echomail packets, but since I was the only one who would use it, I decided I had better things
to do.

what i'd do is to just get another node number from your NC and list it as another AKA on your BBS... then IREX should be able to operate fine... then

fo

that echo you use the new AKA as the origin address and all your other areas stay using the existing origin AKA...

We did. The system IREX sits on is 1:2320/107, while the linux system where binkp, the web interface, ftp, etc., sit on is the original 1:2320/105.
Works now!

i'm not sure why IREX couldn't just gate the mailing list to your existing node number?? that should be a straight forward gating process like i do here with GIGO...

What happened was that I had IREX running as .99, the system it is on was the boss, and the web/etc. system was .1. When I got binkp running on the linux box, I set it as the boss and made the system that IREX runs on .1. IREX
would not pass mail to a point node (.1) that could be passed along to the boss. Probably a topology goof on my part... I also could not get IREX to route the mail to the boss system and have it route back to the .1. So,
either the boss (and the network) did not get the messages, or .1 didn't.

Thinking I could get it to eventually work the right way, I set up a
temporary "fix"... now it is running a different right way, but it at least works now. :D

the ""problem"", such as it is, is that today some people are specifically trying to "kill off" the traditional FTN distribution format which is

backbone

oriented... they are, instead, connecting to one echo from several different systems and eventually there's several huge dupe loops... the so-called goal

i

to eliminate a SPOF (single point of failure) but in reality it is

eliminating

a lot more and taking away moderator's rights in their echos since now it is impossible to remove a problem user from an echo for a time period...

I suspect that is why some echo tossers get blamed for behaving badly... because they were not written to work on a non-backbone/redundant topology.

Thanks for your assistance and explanations!

Mike

---
* SLMR 2.1a * I can't pretend a stranger is a long-awaited friend...


--- GTMail 1.26
* Origin: CCO BBS * 502/875-8938 * capcity2.synchro.net (1:2320/105.1)

I have used Irex to feed net, echo mail, and files to a point, with absolutely >no problems, so whoever is telling you this story is wrong, and probably has >not configured his Irex properly. I als know others who have done as I have, >if that helps.

It would feed it to the point without issue... just not to any other node beyond the point.

Mike

---
* SLMR 2.1a * "Now who's laughing?! Now who's laughing?!" - Pagans


--- GTMail 1.26
* Origin: CCO BBS * 502/875-8938 * capcity2.synchro.net (1:2320/105.1)

I have used Irex to feed net, echo mail, and files to a point, with

absolutely

no problems, so whoever is telling you this story is wrong, and

probably has

not configured his Irex properly. I als know others who have done as I

have,

if that helps.

It would feed it to the point without issue... just not to any other
node beyond the point.

This makes no sense. A point should only link with his bossnode, and not act in the chain of echomail distribution, which means there is no "node beyond the
point". If anyone were to be in this position, he should be a full node, NOT a
point.





.....Bob

--- GEcho/32 & IM 2.50
* Origin: http://www.fidonet.ca (1:140/12)

On 03/07/17, Mike Powell said the following...

IREX (and "half" the board) are still running under OS/2 Warp 4. Is it still supported?

Wait for it. OS/2 Warp 5 (aka ArcaOS 5) will be here soon!!! :)

--- Mystic BBS v1.12 A31 (Linux)
* Origin: Neptune's Lair/X * Olive Branch, MS (1:116/18.662)