* Crossposted from: Argus


I'm not sure what is the source of my problem, so I am posting this
messages into the three echos that might be relevant.

My problem is that on the rare occasion when I enter a netmail, it is
not getting routed the way I think it should.

I enter the netmail using the program IE that comes with InterMail.
That part seems to work just fine, the message gets prepared and the
node number of the addressee gets put into the TO: field.

Next thing is that I process the message(s) using SQUISH via the
command sq386n.exe OUT SQUASH. It is my understanding that SQUISH
should read the ROUTE.CFG file which has as its last routing command
the line
Route Crash 1:123/500 1:All 2:All 3:All 4:All 5:All 6:ALL
There are some lines before that which direct mail to specific other
nodes to go directly to those nodes, e.g.
Send Crash 1:261/38

After I do the sq386 run, if I then look at the message using IE it
now says "sent" in the status field.

However, if I go to my ARGUS program and look at its outmail box, I
will often see a message just sitting there queued up to be sent to
whatever node was the original addressee. In order to make the mail
go out I have to manually modify it to be sent to my uplink which is
1:123/500.

FWIW, in my SQUISH.CFG a few possibly relevant lines are:

; ArcmailAttach
Routing Route.Cfg

I do not see anyplace in ARGUS configuration documentation that
implies how to route mail.

Can anyone help? Goal is to get such messages automatically routed
through 1:123/500 unless otherwise stated.

Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)


... Shipwrecked on Hesperus in Columbia, Maryland. 00:09:14, 24 Dec 2007
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

Replying to a message from Dale Shipp 1:261/1466 to All,

About Routing Problem, On Mon Dec 24 2007

Route Crash 1:123/500 1:All 2:All 3:All 4:All 5:All
6:ALL There are some lines before that which direct mail to
specific other nodes to go directly to those nodes, e.g.
Send Crash 1:261/38

I use the following for all my mail:
ROUTE Hold 1:140/1 1:ALL 2:ALL 3:ALL 4:ALL 5:ALL 6:ALL
I route everything.

Has worked just fine so far, of course YMMV.

For the squish command I use the following:
Squishp in out squash link -fechotoss.log

After it is complete everything is where it should be, and gets sent.

Hope this helps. Keep us posted.

We are a fine board trying to make it better.
http://www.pris.bc.ca/ghannah
ghannah@pris.bc.ca
Cheers! Gord
-=Team OS/2=-
--- timEd/2 1.10.y2k+
* Origin: Marsh BBS (c), Dawson Creek, BC Canada (1:17/23)

Gord Hannah wrote in a message to Dale Shipp:

Route Crash 1:123/500 1:All 2:All 3:All 4:All 5:All
6:ALL There are some lines before that which direct mail to
specific other nodes to go directly to those nodes, e.g.
Send Crash 1:261/38

I use the following for all my mail:
ROUTE Hold 1:140/1 1:ALL 2:ALL 3:ALL 4:ALL 5:ALL 6:ALL
I route everything.

I do too, either through my echomail feed or Janis. HOwever, I understand Dale's using an arcmail attach system such as fd. Iirc intermail is that type mailer. Iirc other than a few basic routing commands for squish ending with

send normal world

after that the mailer's routing controls take over. Not as familiar as I ran fd only briefly a few years ago to get familiar with it to help a downlink get set up. Otherwise I've run binkleyterm exclusively. Things are a bit different for dynamic mailers such as f


Regards,
Richard
... Braille: support true literacy for the blind.
--- timEd 1.10.y2k+
* Origin: Radio REscue net operations BBS (1:116/901)

On 12-24-07 07:24, Gord Hannah <=-
spoke to Dale Shipp about Routing Problem <=-

I use the following for all my mail:
ROUTE Hold 1:140/1 1:ALL 2:ALL 3:ALL 4:ALL 5:ALL 6:ALL
I route everything.

Except that I have ROUTE Crash ... looks the same as mine.

Has worked just fine so far, of course YMMV.

What is your mailer program? Are you using Argus?

Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)


... Shipwrecked on Hesperus in Columbia, Maryland. 23:48:57, 24 Dec 2007
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

On 12-24-07 17:03, Richard Webb <=-
spoke to Gord Hannah about Routing Problem <=-

I do too, either through my echomail feed or Janis. HOwever, I
understand Dale's using an arcmail attach system such as fd. Iirc intermail is that type mailer. Iirc other than a few basic
routing commands for squish ending with

I am using Argus as my mailer. I used to use intermail, but stopped
using that eons ago when I switched from OS/2 and could no longer have
my virtual modem attached.

Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)


... Shipwrecked on Hesperus in Columbia, Maryland. 23:50:48, 24 Dec 2007
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

Replying to a message from Dale Shipp 1:261/1466 to Gord Hannah,

About Re: Routing Problem, On Mon Dec 24 2007

Has worked just fine so far, of course YMMV.

What is your mailer program? Are you using Argus?

I have binkley style outbounds I use Irex to send everything out,used to use binklyterm in my DOS days OS/2 I used to use AdeptXBBS till it started barfing all over the place.

Hope this helps. Keep us posted.

We are a fine board trying to make it better.
http://www.pris.bc.ca/ghannah
ghannah@pris.bc.ca
Cheers! Gord
-=Team OS/2=-
--- timEd/2 1.10.y2k+
* Origin: Marsh BBS (c), Dawson Creek, BC Canada (1:17/23)

HI Dale,

Dale Shipp wrote in a message to Richard Webb:

I do too, either through my echomail feed or Janis. HOwever, I
understand Dale's using an arcmail attach system such as fd. Iirc intermail is that type mailer. Iirc other than a few basic
routing commands for squish ending with

I am using Argus as my mailer. I used to use intermail, but
stopped using that eons ago when I switched from OS/2 and could no
longer have my virtual modem attached.

<Hmmm> Is argus a static mailer such as Binkley or a dynamic type such as fd etcetera? IF an arcmail attach type that does its own routing etc. THen my comment to Gord still may be applicable. IF it uses the static outbounds a la binkleyterm then ...

I had to do some major mods of squish config as well as route config to get desired results. For example, by default squish will zoznegate interzone messages. Well, only one zonegate is pots available, and he's in CAnada, outside my free calling plan. Hence, we comment out any ref to zone gates in squish config. then to clean up anything for which there's no routing command and isn't sent crash we have:

route normal NoArc <target> 1:all 2:all 3:all 4:all 5:all
HOpe that helps a bit.




Regards,
Richard
... Braille: support true literacy for the blind.
--- timEd 1.10.y2k+
* Origin: Radio REscue net operations BBS (1:116/901)

On 12-25-07 12:23, Richard Webb <=-
spoke to Dale Shipp about Routing Problem <=-

I am using Argus as my mailer. I used to use intermail, but
stopped using that eons ago when I switched from OS/2 and could no longer have my virtual modem attached.

<Hmmm> Is argus a static mailer such as Binkley or a

dynamic type such as fd etcetera? IF an arcmail attach

I do not really understand the differences, but from the help files
of Argus I see that it uses the Binkley-style outbound structure.
The line in SQUISH.CFG for ArcmailAttach is commented out.

I had to do some major mods of squish config as well as route config
to get desired results. For example, by default squish will
zoznegate interzone messages. Well, only one zonegate is
pots available, and he's in CAnada, outside my free calling
plan. Hence, we comment out any ref to zone gates in
squish config. then to clean up anything for which there's
no routing command and isn't sent crash we have:

route normal NoArc <target> 1:all 2:all 3:all 4:all 5:all
HOpe that helps a bit.

There are no references to zonegates remaining in my SQUISH.CFG, all
are commented out.

I am bothered by a comment in SQUISH.DOC with respect to the route
statement you quote above:
WARNING!
The NoArc modifier causes all 4D zone and point information
to be lost! Only net and node numbers will be maintained for
mail routed with the NoArc keyword.

Also, the same thing happens to me on netmail sent to a zone 1 node.
It sits in the Argus outbound box addressed to that node, and will not
get sent until I manually manipulate it unless I have previously
entered that nodes connection domain into my Argus tables. If Argus
would pick up the connection domain out of the nodelist -- that would
be great, but it does not do so for me.

Thanks for the response. I'm still looking for a solution though.

Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)


... Shipwrecked on Hesperus in Columbia, Maryland. 23:25:33, 25 Dec 2007
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

HI Dale,

Dale Shipp wrote in a message to Richard Webb:

I do not really understand the differences, but from the help
files of Argus I see that it uses the Binkley-style outbound
structure. The line in SQUISH.CFG for ArcmailAttach is commented
out.

AS it should be for a binkley style outbound system. guess you had me confused
as you mentioned that in your earlier post.

I had to do some major mods of squish config as well as route config
to get desired results. For example, by default squish will
zoznegate interzone messages. Well, only one zonegate is
pots available, and he's in CAnada, outside my free calling
plan. Hence, we comment out any ref to zone gates in
squish config. then to clean up anything for which there's
no routing command and isn't sent crash we have:

route normal NoArc <target> 1:all 2:all 3:all 4:all 5:all
HOpe that helps a bit.

There are no references to zonegates remaining in my SQUISH.CFG,
all are commented out.

I am bothered by a comment in SQUISH.DOC with respect to the route
statement you quote above:
WARNING!
The NoArc modifier causes all 4D zone and point information
to be lost! Only net and node numbers will be maintained
for mail routed with the NoArc keyword.

Also, the same thing happens to me on netmail sent to a zone 1
node. It sits in the Argus outbound box addressed to that node,
and will not get sent until I manually manipulate it unless I have previously entered that nodes connection domain into my Argus
tables. If Argus would pick up the connection domain out of the nodelist -- that would be great, but it does not do so for me.

I"m not at all familiar with that mailer and what it does so others might be able to more intelligently help you. However, I've used that line I quoted above with the NoArc modifier for years to just get everything out. POints whom I send routed mail still seem to get it. OR at least did in the old days.
I haven't netmailed a point of another system since I've been back up.

IN fact, I think mail addressed to points still has the requisite information.
I accidentally routed mail to one of my points through my uplink before I fixed
my route config earlier this year. HIs netmail tracker sent me a pointed automagic warning about it <g>. Squish assumes by default that you'll send directly to nodes in your own net, but I'm the only pots only in my net. Hence
I even have to route mail for net 116. I had a couple of other points designated with a send hold, but not the new point I added. HEnce I had to add
a line:

send hold 1:116/901.all

hOpe another argus user will chime in for you as you'll get more intelligent guidance there.

Regards,
Richard
--- timEd 1.10.y2k+
* Origin: Radio REscue net operations BBS (1:116/901)

<Hmmm> Is argus a static mailer such as Binkley or a

dynamic type such as fd etcetera? IF an arcmail attach

I do not really understand the differences, but from the help files
of Argus I see that it uses the Binkley-style outbound structure.
The line in SQUISH.CFG for ArcmailAttach is commented out.

There's a big difference between mailers that do Binkley-style and Arcmail Attach-style routing.

Binkley-style systems get their routing details set up by the tosser. The Tosser puts routing details into text-based *.*lo files, where even the filename extension has an associated routing meaning and/or directive.

Arcmail systems get their routing set up by the mailer. The mailer compiles routing information into a mailer proprietory formatted binary file. Inside the
binary file are pathnames of packets on your disk and their routing instructions.

The only clue I have is that Argus is a GUI mailer. So somewhere on the screen it should give details on outbound packets. So check if there's any indication that Argus actually sees pending outbound packets after they're created by Squish, which would be a good sign.

For example, if Argus displays your netmail packet with CRASH flag and nothing happens this suggests a problem with Argus, probably a scheduling or Argus configuration problem and not a Squish compatibility issue.

Good luck.

Squish, Binkleyterm, BinkD and Maximus forever baby ! -- These programs were made for eachother.


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

On 12-28-07 21:24, Mvan Le <=-
spoke to Dale Shipp about Re: Routing Problem <=-

Thanks for the responses.

The only clue I have is that Argus is a GUI mailer. So somewhere on
the screen it should give details on outbound packets. So check
if there's any indication that Argus actually sees pending
outbound packets after they're created by Squish, which
would be a good sign.

It does see them. If I log onto that machine and open up Argus, I
can see the packet sitting unsent in the outbound queue, addressed to
the node which is the ultimate recipient --- but not to the node
where the mail should go according to the ROUTE.CFG file. I can
mannually go to that outbound packet, and "readdress" it to my normal
uplink and it then goes out and is routed on its way.

I have asked in the ARGUS echo about this problem also. Somehow
either SQUISH is not seeing the routing info, or it is getting
readdressed when Argus picks it up. I've tried a number of things,
none with success yet.

Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)


... Shipwrecked on Hesperus in Columbia, Maryland. 23:07:29, 29 Dec 2007
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

It does see them. If I log onto that machine and open up Argus, I
can see the packet sitting unsent in the outbound queue, addressed to
the node which is the ultimate recipient --- but not to the node
where the mail should go according to the ROUTE.CFG file. I can
mannually go to that outbound packet, and "readdress" it to my normal
uplink and it then goes out and is routed on its way.

After you create a netmail message and run Squish Squash, can you do a directory listing in your outbound directory and paste here ? (you can sort by descending modified time if you like).

Also include the content of the *.*o file that should be created by Squish for that netmail packet.


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Squish, Binkleyterm, BinkD and Maximus forever baby ! -- These programs

were

made for eachother.

Yeah, that's cool software.. :) All the programs is solving a tiny task, which makes them work well together.

The only reason for I'm not using them, is that they is not unix-ish enough for me.

Bo


--- SBLink 0.1
* Origin: The Night Express! (2:236/100)

Hello, Dale...

Dec 29, 2007 at 23:07, Dale Shipp wrote to Mvan Le:

I have asked in the ARGUS echo about this problem also. Somehow
either SQUISH is not seeing the routing info, or it is getting
readdressed when Argus picks it up. I've tried a number of
things,
none with success yet.

One commonly-missed subtlety is that routing commands only apply to Normal-flavored mail. The order of the routing commands is critical. For example, if I flag a message Crash in my message editor, the routing commands in Squish's configuration won't do anything to it. (There are a couple of exceptions, like the Change command and, I think, the Leave command.)

Regards,

Jerry Schwartz

mailto:jerryschwartz@comfortable.com
http://www.writebynight.com

--- Msged/NT 6.0.1
* Origin: Write by Night (1:142/928)

On 12-30-07 00:03, Mvan Le <=-
spoke to Dale Shipp about Re: Routing Problem <=-

After you create a netmail message and run Squish Squash,
can you do a directory listing in your outbound directory
and paste here ? (you can sort by descending modified time
if you like).

Here is the DIR listing , piped it into a text file and pasted it
here. The 0 size files are left overs that haven't been purged.

Volume in drive H is BBS Serial number is 2BF9:841B
Directory of H:\argus\OUT\*

11/03/2002 0:29 <DIR> .
11/03/2002 0:29 <DIR> ..
6/21/2006 23:14 0 000005B9.TU0
6/21/2006 23:14 0 000005B9.WE0
12/30/2007 0:11 0 008A03C6.SU0
12/25/2007 0:11 0 00000055.MO0
4/22/2005 4:58 0 00000072.TH0
7/18/2006 23:02 0 00000594.TU0
12/05/2007 20:36 0 007905B9.WE0
12/30/2007 23:10 28 01130064.Flo
12/30/2007 23:11 2 dir.txt
12/30/2007 23:10 319 FFF20556.SU0
349 bytes in 10 files and 2 dirs 12,288 bytes
allocated
9,763,184,640 bytes free

Also include the content of the *.*o file that should be
created by Squish for that netmail packet.

And here is the Flo file:
#H:\argus\out\fff20556.su0

Hope that helps you help me:-}}

Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)


... Shipwrecked on Hesperus in Columbia, Maryland. 23:17:19, 30 Dec 2007
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

On 12-30-07 18:01, Jerry Schwartz <=-
spoke to Dale Shipp about Re: Routing Problem <=-

One commonly-missed subtlety is that routing commands only apply to Normal- flavored mail. The order of the routing commands is
critical. For example, if I flag a message Crash in my
message editor, the routing commands in Squish's
configuration won't do anything to it. (There are a couple
of exceptions, like the Change command and, I think, the
Leave command.)

The default flavor for new netmail is CRASH, but I have been changing
it to remove the CRASH flag before saving it. Only flag on it is
PVT.

Thanks for the response though.

Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)



... Shipwrecked on Hesperus in Columbia, Maryland. 23:24:52, 30 Dec 2007
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

12/05/2007 20:36 0 007905B9.WE0
12/30/2007 23:10 28 01130064.Flo
12/30/2007 23:11 2 dir.txt
12/30/2007 23:10 319 FFF20556.SU0
349 bytes in 10 files and 2 dirs 12,288 bytes
allocated
9,763,184,640 bytes free

Also include the content of the *.*o file that should be
created by Squish for that netmail packet.

And here is the Flo file:
#H:\argus\out\fff20556.su0

Ok. Based on the information above,

01130064.flo

means you're trying to send a "Normal" flavoured packet to 3:275/100 (the "01130064" part of 01130064.flo is 3275100 in hex, and the ".flo" part of 01130064.flo in Binkley-style outbound filenames means Normal routed mail).

If you want to to get Argus to send crash mail immediately, that filename has to have a ".clo" (crash) or ".ilo" (direct) extension (depending on mailer behaviour) eg.,

01130064.clo

Replicate this problem by creating a new crash netmail message. Then do this,

cd /d h:\argus\out
ren 01130064.flo 01130064.clo

Then wait a minute.

Argus should automatically send your net netmail packets (ie. the filename listed within the .clo file).

This test would confirm that

1. Argus works as expected (regarding Binkley-style outbound packets)
2. your route.cfg may be incorrect, or
3. that Squish isn't scanning out your netmail message as crashmail for some reason.

Hence we would focus troubleshooting efforts on your BBS and Squish, in which case post the contents of your route.cfg file.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Squish, Binkleyterm, BinkD and Maximus forever baby
! -- These programs were
made for eachother.

Yeah, that's cool software.. :) All the programs is
solving a tiny task, which
makes them work well together.

That pertains to the Unix philosophy of creating one tool that does one job well.

The only reason for I'm not using them, is that they is
not unix-ish enough for
me.

C'mon Bo. You know you want to.

Once a Maximus, always a Maximus.

Maybe you can port Maximus to Minix, and call it Miniximus-CBCS (c) By Jason Scott-"Bo"-dley !


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

of exceptions, like the Change command and, I think, the
Leave command.)

The default flavor for new netmail is CRASH, but I have been changing
it to remove the CRASH flag before saving it. Only flag on it is
PVT.

Where are you changing the flag ? Within the BBS or using Argus editor ?


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

On 12-31-07 02:19, Mvan Le <=-
spoke to Dale Shipp about Re: Routing Problem <=-

Ok. Based on the information above,

01130064.flo

means you're trying to send a "Normal" flavoured packet to
3:275/100 (the "01130064" part of 01130064.flo is 3275100
in hex, and the ".flo" part of 01130064.flo in Binkley-
style outbound filenames means Normal routed mail).

Took me a while to figure out how you got that. 0x113 = 275 and
0x064 = 100. Not sure where the 3 came from. The node the netmail
was addressed to was 1:275/100. That netmail was still sitting there
tonight. I had to readdress it using the Argus interface to make it
get routed to 1:123/500 -- which is how my ROUTE.CFG file says should
happen to almost all netmail. The fact that it does not get addressed
to 1:123/500 is the problem.

Argus should automatically send your net netmail packets
(ie. the filename listed within the .clo file).

Before I made Argus readdress it, I also tried to change the flavor to
crash. That caused Argus to attempt a poll to
f100.n275.z1.fidonet.org. I'm uncertain how that could have worked
since 1:275/100 is PVT and that DNS does not exist.

Hence we would focus troubleshooting efforts on your BBS
and Squish, in which case post the contents of your
route.cfg file.

My route.cfg file has a lot of standard comments in it. Here is what
remains after they are removed:

Send Normal World
Route normal 1:123/500 1:All 2:All 3:All 4:All 5:All 6:ALL
Send Crash 1:140/1
Send Crash 1:261/1
Send Crash 1:261/38
Send normal 1:123/500

I have tried altering the order, and changing the flavor to 1:123/500 to
crash instead of normal the two times it appears. No effect on
behavior -- mail still gets stuck without being routed.


Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)


... Shipwrecked on Hesperus in Columbia, Maryland. 01:27:00, 01 Jan 2007
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

On 12-31-07 02:13, Mvan Le <=-
spoke to Dale Shipp about Re: Routing Problem <=-

The default flavor for new netmail is CRASH, but I have been changing
it to remove the CRASH flag before saving it. Only flag on it is
PVT.

Where are you changing the flag ? Within the BBS or using Argus editor
?

I create netmail with the editor IE (part of Intermail program suite).
It has default of CRASH for netmail, and I often change it to NORMAL
there -- this is before the Squish is run to pack up the mail for
sending.

Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)


... Shipwrecked on Hesperus in Columbia, Maryland. 01:28:45, 01 Jan 2007
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

Quoting Dale Shipp to Mvan Le <=-

On 12-31-07 02:19, Mvan Le <=-
spoke to Dale Shipp about Re: Routing Problem <=-

Ok. Based on the information above,

01130064.flo

means you're trying to send a "Normal" flavoured packet to
3:275/100 (the "01130064" part of 01130064.flo is 3275100
in hex, and the ".flo" part of 01130064.flo in Binkley-
style outbound filenames means Normal routed mail).

Hmm. People are asleep in this echo ... I'm slacking off myself. I thought somebody would've fixed your problem by now because it seems pretty obvious to me.

Took me a while to figure out how you got that. 0x113 = 275 and
0x064 = 100. Not sure where the 3 came from. The node the netmail

Woops. Sorry. You're right. The zone is determined by the primary address defined in Squish.cfg and/or the domain in your BinkP compatible mailer. Files for other zones go into h:\argus\out.[23456789] etc (if your default domain is "1").

was addressed to was 1:275/100. That netmail was still sitting
there tonight. I had to readdress it using the Argus interface to
make it get routed to 1:123/500 -- which is how my ROUTE.CFG file
says should happen to almost all netmail. The fact that it does not
get addressed to 1:123/500 is the problem.

Argus should automatically send your net netmail packets
(ie. the filename listed within the .clo file).

Before I made Argus readdress it, I also tried to change the flavor
to crash. That caused Argus to attempt a poll to f100.n275.z1.fidonet.org. I'm uncertain how that could have worked
since 1:275/100 is PVT and that DNS does not exist.

This is normal (default) BinkP behaviour for unlisted nodes, and only works for
static IPs. You got to register your (or the target) net/node's static IP address with fidonet.org DNS for this behaviour to work.

Otherwise you will need to manually define a node & IP entry for 1:275/100 (et al) in Argus configuration so that if it finds a file named 01130064.*o it will
know where to send it.

Or disable unlisted node dialing in Argus.

Instructions on how to obtain a BinkP nodelist are posted in the BinkD echo. (I
don't know how to incorporate that nodelist into Argus (In BinkD you just use the "Include <nodelist file>" directive)).

Hence we would focus troubleshooting efforts on your BBS
and Squish, in which case post the contents of your
route.cfg file.

My route.cfg file has a lot of standard comments in it. Here is
what remains after they are removed:

Send Normal World
Route normal 1:123/500 1:All 2:All
3:All 4:All 5:All 6:ALL
Send Crash 1:140/1
Send Crash 1:261/1
Send Crash 1:261/38
Send normal 1:123/500

I have tried altering the order, and changing the flavor to 1:123/500
to crash instead of normal the two times it appears. No effect on behavior -- mail still gets stuck without being routed.

Order is important.

Try this,

=================
Send Normal World
#End Route.Cfg
=================

Ie. "Send Normal World" is the only command you need. You don't need all the other Send commands unless you want to specifically alter the flavour of the packet for those <node> <nodes ...> (in this case netmail message), for example
when you're a NC or hub and want to alter passthru messages.

For crash *netmail* messages that originate from your system, you don't need Send Crash in Route.cfg.

The reason why your crash netmail aren't sent immediately as expected is because Argus isn't configured to send to those nodes properly (eg. indicative from your f100.n275.z1.fidonet.org problem) and that you're altering the CRASH flag before saving the message -- Leave the CRASH flag alone.

The reason why Argus will only send to 1:123/500 is because it knows about 1:123/500 :) ...

When you create a Crash netmail message in IE (Intermail Editor (which I know nothing about)), I hope it behaves correctly by assuming it will create a packet in your outbound directory after Squish Squash is run.

For example, if a crash netmail created is addressed to 1:275/100 the following
steps should occur,

1. Squish Squash
2. The following file containing your message is created "H:\Argus\Out\01130064.cut"
3. If Argus has 1:275/100 configured in its nodelist, it will dial the IP and
establish a session

Nb. A *.?ut file means the Binkley-style packet is uncompressed, and a *.?lo file means it's a header file that contains further instructions inside.

The way you currently have Route.Cfg set up, ie.

==============================================
Send Normal World
Route normal 1:123/500 1:All 2:All
3:All 4:All 5:All 6:ALL
Send Crash 1:140/1
Send Crash 1:261/1
Send Crash 1:261/38
Send normal 1:123/500
==============================================

All your mail is getting re-addressed to 1:123/500, so the other Send commands have no effect.

Anyway, your problem is to do with Argus. You need to define the destination node & IP addresses in Argus. If it doesn't know about the destination, your packet will just get stuck in the outbound directory. And check that the crash netmail message is created in your outbound directory with *.cut extension.

As a comparison, here is my Binkd.cfg file:

====================================================================
# Your FTN domains:
# domain <name> <main-outbound> <default-zone>
# or
# domain <new-name> alias-for <name>
#

domain fidonet M:\\mailing\\mailer\\bt\\out\\ftn 3
domain fido alias-for fidonet
domain fidonet.org alias-for fidonet
domain fidonet.net alias-for fidonet

#
# Your addresses, 4D or 5D:
# address <addr1> ...
#

address 3:712/104@fidonet

...
...
...

#
# Define a link:
# node [[z:]n/]n[.p][@domain] [-nr|-nd] [-md] [-ip|-sip]
# [{hosts|-} [{pwd|-} [flavour [{obox|-} [{ibox|-}]]]]]
#

include nodelist.inc

node 3:712/0 -md sysgod.org mypassword

node 1:343/41 tophat.darktech.org

#
# Default node flags. Binkd will call unlisted node if "defnode"
# defined.
#
# The line below sets up default node settings for -nr (not
# reliable link) and instructs BinkD to do 1:2/3.4 -->
# p4.f3.n2.z1.fidonet.net translation.
#
#defnode -nr *
====================================================================

Based on the "defined links" section above, you can see that I only intend on sending crash mail to 3:712/0 and 1:343/41. I define these entries after the "include" so that my specs override the ones from nodelist.inc (because I don't
trust it). I also don't bother with unlisted nodes.

--- Maximus 3.01
* Origin: <Xaragmata>< - Adelaide, Australia +61-8-8351-7637 (3:800/432)

On 01-05-08 21:47, Mvan Le <=-
spoke to Dale Shipp about Re: Routing Problem <=-

I think that we have a mis-understanding of what I have been asking
and the intent of what I wish to happen. Much of what you said makes
sense, and would allow my Argus to send direct to multiple nodes if
that is what I desired -- but it is not what I desire.

Otherwise you will need to manually define a node & IP entry for
1:275/100 (et al) in Argus configuration so that if it finds a file named 01130064.*o it will know where to send it.

I have done that for a few nodes -- but the whole point of my
starting this discussion was that I want mail destined for any other
node to be routed out through 1:123/500. That is not happening, no
matter how I twiddle with the ROUTE.CFG that Squish is supposed to
look at.

My route.cfg file has a lot of standard comments in it. Here is
what remains after they are removed:

Send Normal World
Route normal 1:123/500 1:All 2:All
3:All 4:All 5:All 6:ALL
Send Crash 1:140/1
Send Crash 1:261/1
Send Crash 1:261/38
Send normal 1:123/500

I have tried altering the order, and changing the flavor to 1:123/500
to crash instead of normal the two times it appears. No effect on behavior -- mail still gets stuck without being routed.

Order is important.

Try this,

=================
Send Normal World
#End Route.Cfg
=================

Ie. "Send Normal World" is the only command you need. You
don't need all the other Send commands unless you want to
specifically alter the flavour of the packet for those

<node> <nodes ...> (in this case netmail message), for

example when you're a NC or hub and want to alter passthru
messages.

The problem is that I do want to alter the routing (not the flavor) of
packets for all other nodes not explicitly mentioned.

The way you currently have Route.Cfg set up, ie.

==============================================
Send Normal World
Route normal 1:123/500 1:All 2:All
3:All 4:All 5:All 6:ALL
Send Crash 1:140/1
Send Crash 1:261/1
Send Crash 1:261/38
Send normal 1:123/500 ==============================================

All your mail is getting re-addressed to 1:123/500, so the
other Send commands have no effect.

But the point is that it is *not* getting re-addressed to 1:123/500 as
I intend to happen.

Anyway, your problem is to do with Argus. You need to define the destination node & IP addresses in Argus. If it doesn't know about the destination, your packet will just get stuck in the
outbound directory. And check that the crash netmail
message is created in your outbound directory with *.cut
extension.

The destination node and IP address for 1:123/500 is defined in Argus.
The others are not, because I do not intend for mail to be sent
directly to them -- rather I intend for it to be routed through
1:123/500.




... Shipwrecked on Hesperus in Columbia, Maryland. 23:18:15, 05 Jan 2007
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

Otherwise you will need to manually define a node & IP entry for
1:275/100 (et al) in Argus configuration so that if it finds a file named 01130064.*o it will know where to send it.

I have done that for a few nodes -- but the whole point of my
starting this discussion was that I want mail destined for any other
node to be routed out through 1:123/500. That is not happening, no
matter how I twiddle with the ROUTE.CFG that Squish is supposed to
look at.

Oh ok. Why didn't you say that before.

For each area definition in Squish.Cfg, scan it out to 1:123/500. Eg.,

NetArea NETMAIL m:\base\Msgbase\Netmail -f -h 1:123/500
EchoArea TUB m:\base\msgbase\fdo\tub -$ 1:123/500
...
...
...

All mail originating from your system will be packed for 1:123/500.

Remove everything in Route.Cfg except for Send Normal World.


--- Maximus 3.01
* Origin: <Xaragmata>< - Adelaide, Australia +61-8-8351-7637 (3:800/432)

Replying to a message from Dale Shipp 1:261/1466 to Mvan Le,

About Re: Routing Problem, On Sat Jan 05 2008

Otherwise you will need to manually define a node & IP entry for
1:275/100 (et al) in Argus configuration so that if it finds a file named 01130064.*o it will know where to send it.

node to be routed out through 1:123/500. That is not happening,

The destination node and IP address for 1:123/500 is defined in

Just a question Dale is it defined in the areas in your squish.cfg?

Hope this helps. Keep us posted.

We are a fine board trying to make it better.
http://www.pris.bc.ca/ghannah
ghannah@pris.bc.ca
Cheers! Gord
-=Team OS/2=-
--- timEd/2 1.10.y2k+
* Origin: Marsh BBS (c), Dawson Creek, BC Canada (1:17/23)

On 01-06-08 07:15, Gord Hannah <=-
spoke to Dale Shipp about Routing Problem <=-

The destination node and IP address for 1:123/500 is defined in

Just a question Dale is it defined in the areas in your squish.cfg?

I don't understand the question. Squish.cfg has echo areas defined,
and the nodes for which I am connected for each echo. It does not
have routing information nor IP addresses for netmail messages I might
address to other nodes.

Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)



... Shipwrecked on Hesperus in Columbia, Maryland. 23:06:40, 06 Jan 2007
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

On 01-07-08 00:35, Mvan Le <=-
spoke to Dale Shipp about Re: Routing Problem <=-

I have done that for a few nodes -- but the whole point of my
starting this discussion was that I want mail destined for any other
node to be routed out through 1:123/500. That is not happening, no
matter how I twiddle with the ROUTE.CFG that Squish is supposed to
look at.

Oh ok. Why didn't you say that before.

I thought that I had said that at the beginning of the thread.

For each area definition in Squish.Cfg, scan it out to 1:123/500. Eg.,

NetArea NETMAIL m:\base\Msgbase\Netmail -f -h 1:123/500

Except for the -f and -h flags, that is what my NETMAIL area looks
like in SQUISH.CFG. The -f flag is redundant, and -h has to do with
PVT flag, not routing.

EchoArea TUB m:\base\msgbase\fdo\tub -$ 1:123/500

All mail originating from your system will be packed for 1:123/500.

That is how most of the echomail areas look, except for a few echos
that I am picking up from other nodes.

Remove everything in Route.Cfg except for Send Normal World.

Tried that also, no effect. Composed a netmail message to you and it
still got put into the ARGUS outbound addressed to 3:800/432 instead
of being routed as I would have wanted it to. After checking that, I
killed it -- so you needn't look for it.

I am ready to give up and resign myself to manually routing each
netmail -- there really are not many.

Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)



... Shipwrecked on Hesperus in Columbia, Maryland. 23:17:43, 06 Jan 2007
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

Replying to a message from Dale Shipp 1:261/1466 to Mvan Le,

About Re: Routing Problem, On Sun Jan 06 2008

I am ready to give up and resign myself to manually routing each netmail -- there really are not many.

Or you might want to consider going to (back to) binkleyterm. Just a thought.

Hope this helps. Keep us posted.

We are a fine board trying to make it better.
http://www.pris.bc.ca/ghannah
ghannah@pris.bc.ca
Cheers! Gord
-=Team OS/2=-
--- timEd/2 1.10.y2k+
* Origin: Marsh BBS (c), Dawson Creek, BC Canada (1:17/23)

Remove everything in Route.Cfg except for Send Normal World.

Tried that also, no effect. Composed a netmail message to you and it
still got put into the ARGUS outbound addressed to 3:800/432 instead
of being routed as I would have wanted it to. After checking that, I
killed it -- so you needn't look for it.

I am ready to give up and resign myself to manually routing each
netmail -- there really are not many.

Ok.

Do this,

Route Hold 1:123/500 World
#End Route.Cfg

Do not attach any Crash flag to your netmail.


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

On 01-08-08 05:58, Mvan Le <=-
spoke to Dale Shipp about Re: Routing Problem <=-

I am ready to give up and resign myself to manually routing each
netmail -- there really are not many.

Ok.

Do this,

Route Hold 1:123/500 World
#End Route.Cfg

We are getting some where! Your suggestion resulted in a netmail
addressed to you getting packed out addressed to (presumably routed
through) 1:123/500, but because of the HOLD flag, it did not get sent
-- even when I polled 1:123/500.

I tried changing that to
Route Normal 1:123/500 World
and the result was that Argus sent the mail on its way. Hopefully,
the BBS you are using will deliver it to you by the time you read this
message.

The question that now wonders me is why did
Route Normal 1:123/500 World
work when the previous command of
Route Normal 1:123/500 1:All 2:All 3:All 4:All 5:All 6:All
not work?

Thanks much for your continued patience and perserverance. I think
that you have managed to solve the problem, although as I said above,
I don't understand the difference and why what I had before did not
work.

Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)



Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)



... Shipwrecked on Hesperus in Columbia, Maryland. 23:47:38, 08 Jan 2007
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

On 01-08-08 05:58, Mvan Le <=-
spoke to Dale Shipp about Re: Routing Problem <=-

I am ready to give up and resign myself to manually routing each
netmail -- there really are not many.

Ok.

Do this,

Route Hold 1:123/500 World
#End Route.Cfg

We are getting some where! Your suggestion resulted in a netmail
addressed to you getting packed out addressed to (presumably routed
through) 1:123/500, but because of the HOLD flag, it did not get sent
-- even when I polled 1:123/500.

That shouldn't happen. When you polled 1:123/500, your mailer should have looked for a file named 007B01F4.HLO and renamed it to *.flo and send it off to
1:123/500, or create a *.ilo file in the outbound directory to trigger the poll.

Maybe your uplink is not advertising 1:123/500 as an alias ... (?) Check your mailer's session log.

I tried changing that to
Route Normal 1:123/500 World
and the result was that Argus sent the mail on its way. Hopefully,
the BBS you are using will deliver it to you by the time you read this
message.

Dunno. I suggested Hold instead of Normal, to allow time for you to inspect your outbound directory. I also use Hold myself on my system because I observe ZMH (04:00 AEST) :)

The question that now wonders me is why did
Route Normal 1:123/500 World
work when the previous command of
Route Normal 1:123/500 1:All 2:All 3:All 4:All 5:All 6:All
not work?

Well, the #:All syntax should work.

My guess is your Route.Cfg was set up like this,

1: Send Normal World
2: Route normal 1:123/500 1:All 2:All 3:All 4:All 5:All 6:ALL
3: Send Crash 1:140/1
4: Send Crash 1:261/1
5: Send Crash 1:261/38
6: Send normal 1:123/500

The problem is that the first line scans for all normal flavoured, uncompressed
mail from any host, and then processes the mail according to your specified rule (ie. compresses them as Normal).

When the second line runs, it finds no mail to process because Squish looks for
Normal *Uncompressed* mail to process. Since all mail has been compressed by the first rule, nothing beneath it will be processed properly.

Refer to "The Route Command" section of Squish.doc,

<nodes> is the optional list of network addresses for which
Squish should readdress mail. Squish will look for normal-
flavoured, uncompressed packets for these nodes, and then route
them through the specified target.

Try reordering your route.cfg to run the Route command first.

As better practice, apply specific node rules before sweeping nodes with widlcards; like how you would set up a DENY policy firewall Eg.,

1: Send Crash 1:140/1
2: Send Crash 1:261/38
3: Send Crash 1:261/1
4: Send normal 1:123/500
5: Route normal 1:123/500 1:All 2:All 3:All 4:All 5:All 6:ALL
6: Send Normal World

albeit the last line will do nothing unless you're catching mail from othernets
(ie. outside zones 1-6).

Thanks much for your continued patience and perserverance. I think
that you have managed to solve the problem, although as I said above,
I don't understand the difference and why what I had before did not
work.

When you attach a crash flag to a message, it no longer is a Normal flavoured mail so is not processed by Squish hence typically handled by the mailer. So only give priviledged users Crash mail access on your BBS.

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

On 01-09-08 06:46, Mvan Le <=-
spoke to Dale Shipp about Re: Routing Problem <=-

Thanks much for your continued patience and perserverance. I think
that you have managed to solve the problem, although as I said above,
I don't understand the difference and why what I had before did not
work.

When you attach a crash flag to a message, it no longer is
a Normal flavoured mail so is not processed by Squish hence
typically handled by the mailer. So only give priviledged
users Crash mail access on your BBS.

I think that this observation about the effect of a crash flag is what
I was not taking into account.

It now seems to be working the way I would want, Thanks again.

Dale Shipp
fido_261_1466 (at) comcast (dot) net
(1:261/1466)


... Shipwrecked on Hesperus in Columbia, Maryland. 23:10:34, 09 Jan 2007
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

When you attach a crash flag to a message, it no longer is
a Normal flavoured mail so is not processed by Squish hence
typically handled by the mailer. So only give priviledged
users Crash mail access on your BBS.

I think that this observation about the effect of a crash flag is what
I was not taking into account.

It now seems to be working the way I would want, Thanks again.

Ok.

Do this,

Change Crash Normal World
Route Normal 1:123/500 World

The above will deal with Intermail's default Crash netmail (ie. you won't have to fuss over changing message flavours from Crash to Normal due to Intermail's default behaviour for netmail). However the problem with the above configuration is that all crash flavoured mail will be converted to normal -- therefore you lose the flexibility of explicitly creating any on-the-fly crash netmail.

To fix that, based on your original route.cfg (ie. judging your intentions),

1: Send Normal World
2: Route normal 1:123/500 1:All 2:All 3:All 4:All 5:All 6:ALL
3: Send Crash 1:140/1
4: Send Crash 1:261/1
5: Send Crash 1:261/38
6: Send normal 1:123/500

you probably want to turn it into something like this:

1: Change Crash Normal World
2: Change Normal Crash 1:140/1 1:261/1 1:261/38
3: Route Normal 1:123/500 World

which will allow you to send real Crash mail to 1:140/1, 1:261/1 and 1:261/38 while routing everything else through 1:123/500.

You could get creative with Squish schedules if you like :)

--- Maximus 3.01
* Origin: <Xaragmata>< - Adelaide, Australia +61-8-8351-7637 (3:800/432)