| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Re: Routing Problem |
-=> On 01-08-08 05:58, Mvan Le <=-
-=> spoke to Dale Shipp about Re: Routing Problem <=-
DS> I am ready to give up and resign myself to manually routing each
DS> netmail -- there really are not many.
ML> Ok.
ML> Do this,
ML> Route Hold 1:123/500 World
ML> #End Route.Cfg
DS> We are getting some where! Your suggestion resulted in a netmail
DS> addressed to you getting packed out addressed to (presumably routed
DS> through) 1:123/500, but because of the HOLD flag, it did not get sent
DS> -- 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.
DS> I tried changing that to
DS> Route Normal 1:123/500 World
DS> and the result was that Argus sent the mail on its way. Hopefully,
DS> the BBS you are using will deliver it to you by the time you read this
DS> 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) :)
DS> The question that now wonders me is why did
DS> Route Normal 1:123/500 World
DS> work when the previous command of
DS> Route Normal 1:123/500 1:All 2:All 3:All 4:All 5:All 6:All
DS> 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,
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).
DS> Thanks much for your continued patience and perserverance. I think
DS> that you have managed to solve the problem, although as I said above,
DS> I don't understand the difference and why what I had before did not
DS> 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)SEEN-BY: 10/1 3 11/201 14/300 34/999 90/1 103/105 120/228 123/500 134/10 140/1 SEEN-BY: 222/2 226/0 249/303 261/20 38 100 1381 1404 1406 1418 266/1413 SEEN-BY: 280/1027 320/119 633/104 260 262 267 690/682 734 712/848 800/432 SEEN-BY: 801/161 189 2222/700 2320/100 105 200 303 2905/0 @PATH: 343/41 138/146 140/1 261/38 633/260 267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.