Hello All.

From what I am given to understand, BBBS's tosser cannot route point addresses. This seems to be unacceptable behaviour.

Here is what my main link at 1:261/38 told me:

201024 20:30 Processing packet f94c5fd9.pkt from 1:396/45.0, 1070
bytes.
201024 20:30 BOGUS: Packet /home/bbbs/tmpin/f94c5fda.pkt is not for us (2:333/808.7) This clip above I believe is saying that your netmail to 2:333/808.7 was seen by bbbs as lacking proper "routing" verbs (or
whatever the heck <g>) BBBS is looking for to route to another node.
I also know part of the problem is that BBBS will not deliver mail to _point_ addresses (they are points, not nodes).

I have had to change my netmail routing to another node that doesn't exhibit this aberrant behaviour.

Any views on this?

Best regards,
Marc

--- timEd/2 1.10.y2k+
* Origin: Sursum Corda! BBS-Huntsville,AL-bbs.sursum-corda.com (1:396/45)

I have had to change my netmail routing to another node that doesn't exhibit this aberrant behaviour.

I haven't looked at the input .pkt so here is my guess.

Any views on this?

Was the packet addressed to 1:261/38? The packet header I mean. The messages within the packet could have been echomail or netmail addressed to any node and those message will be forwarded on as usual.

Some tossers will toss any old packet you send there but most look for packets addressed to itself (1:261/38 in this case) and will then do what it needs to do with those messages. Some tossers can/will pass on packets as they are to another node if it is so addressed but that usually requires an agreement and extra configuration.

If that packet was addressed to 1:261/38 (the packet, not the messages inside) the tosser there will likely act on it as needed.

--- BBBS/Li6 v4.10 Toy-4
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757.2)

Hello Alan.

<On 27Oct2020 17:34 Alan Ianson (1:153/757.2) wrote a message to Marc Lewis regarding No routing of point addresses. >

I have had to change my netmail routing to another node that doesn't
exhibit this aberrant behaviour.

I haven't looked at the input .pkt so here is my guess.

Any views on this?

Was the packet addressed to 1:261/38? The packet header I mean. The messages within the packet could have been echomail or netmail
addressed to any node and those message will be forwarded on as
usual.

The mail bundle was addressed to 261/38 for forwarding purposes. The packet would have been addressed to 2:333/808.7. In yet another case the mail bundle was again addressed to 1:261/38 and the packet would have been addressed to 2:221/360. Those two were never delivered until I resent them to a different node with international connections and a different tosser. Those were promptly delivered to their destinations by whatever group of intervening nodes.

[snip]

If that packet was addressed to 1:261/38 (the packet, not the
messages inside) the tosser there will likely act on it as needed.

If by packet you actually mean the mail bundle, then yes the affected bundles went to 1:261/38.

Best regards,
Marc

--- timEd/2 1.10.y2k+
* Origin: Sursum Corda! BBS-Huntsville,AL-bbs.sursum-corda.com (1:396/45)

Hello Marc,

The mail bundle was addressed to 261/38 for forwarding purposes. The packet would have been addressed to 2:333/808.7.

If you sent a packet (a *.pkt file) to 261/38 for processing the packet needs to be addressed to 261/38 even though that packet may contain one or more netmail messages for any nodes. If not there will be an error like this.

201024 20:30 Processing packet f94c5fd9.pkt from 1:396/45.0, 1070 bytes. 201024 20:30 BOGUS: Packet /home/bbbs/tmpin/f94c5fda.pkt is not for us (2:333/808.7)

That makes me believe the packet was addressed to 2:333/808.7 and that is why 261/38 didn't open it.

If that packet was addressed to 1:261/38 (the packet, not the
messages inside) the tosser there will likely act on it as
needed.

If by packet you actually mean the mail bundle, then yes the affected bundles went to 1:261/38.

A compressed mail bundle is a different thing, it may contain one or more packets (*.pkt files). If you want any node to open a .pkt file and toss it those packets need to be addressed to that node even though the messages inside are destined for other nodes.

Ttyl :-),
Al

--- GoldED+/LNX 1.1.5-b20180707
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Hello Alan.

<On 28Oct2020 21:10 Alan Ianson (1:153/757) wrote a message to Marc Lewis regarding No routing of point addresses. >

If by packet you actually mean the mail bundle, then yes the affected bundles went to 1:261/38.

A compressed mail bundle is a different thing, it may contain one
or more packets (*.pkt files). If you want any node to open a .pkt
file and toss it those packets need to be addressed to that node
even though the messages inside are destined for other nodes.

With all due respect, there's something wonky about that. Nobody else's mail processor seems to have any problem appropriately forwarding netmail. E.g., I now send all out-of-zone netmail to 1:229/426. He's using D'Bridge; messages going to Z2 are delivered promptly. Same format - message bundle addressed to 1:229/426 containing pkts bound for various Z2 addresses - all handled w/o problem... Or perhaps I don't properly understand what's inside that outbound mail bundle.<?> I have never attempted to open one and examine the contents as they're usually gone from the system in very short order.

I will however, send netmail to one of my contacts in Z2, routed through 229/426, but I will stop the BinkP server long enough to do an exam of the message bundle.

Best regards,
Marc

--- timEd/2 1.10.y2k+
* Origin: Sursum Corda! BBS-Huntsville,AL-bbs.sursum-corda.com (1:396/45)

Hello Alan.

<<Following up a message from Marc Lewis to Alan Ianson about Re: No routing of point addresses. >>

With all due respect, there's something wonky about that. Nobody
else's mail processor seems to have any problem appropriately
forwarding netmail. E.g., I now send all out-of-zone netmail to
1:229/426. He's using D'Bridge; messages going to Z2 are delivered promptly. Same format - message bundle addressed to 1:229/426
containing pkts bound for various Z2 addresses - all handled w/o problem... Or perhaps I don't properly understand what's inside
that outbound mail bundle.<?> I have never attempted to open one
and examine the contents as they're usually gone from the system in
very short order.

I will however, send netmail to one of my contacts in Z2, routed
through 229/426, but I will stop the BinkP server long enough to do
an exam of the message bundle.

I have 2 examples of the outbound message bundle contents. The bundle was addressed to 1:229/426 for forwarding. Here's the contents of the bundle containing 2 separate netmails for 2 separate Z2 addresses as seen by InspectA:

-o-o-o-o-o-o-o-o-CUT-o-o-o-o-o-o-o-o-o-
=-=-=-=-=-=-=-=-=-=-=-2nd MESSAGE PKT=-=-=-=-=-=-=-=-=-=-=-=-=-
PKT INFO:
1/1 396/45 333/808 0000003a NETMAIL
Type 2+ Maximus-CBCS v1.11 O=1:396/45 D=2:333/808

=-=-=-=-Message content:
From: Marc Lewis 396/45 29 Oct 20 20:18:46
To: August Abolins 333/808
Subj: 2nd Test Size: 246b Stat: Pvt Ofs: 58b-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-
xTOPT 7
xMSGID: 1:396/45.0 f9b69dc1
xINTL 2:333/808 1:396/45
xCHRS: IBMPC 2

=-=-=-=-=-=-=-=-=-=-=-1st MESSAGE PKT=-=-=-=-=-=-=-=-=-=-=-=-=-
PKT INFO:
1/1 396/45 221/360 0000003a NETMAIL
Type 2+ Maximus-CBCS v1.11 O=1:396/45 D=2:221/360

=-=-=-=-Message content:
From: Marc Lewis 396/45 29 Oct 20 20:17:02
To: August Abolins 221/360
Subj: Test message Size: 243b Stat: Pvt
Ofs: 58b-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-
xMSGID: 1:396/45.0 f9b69dc0
xINTL 2:221/360 1:396/45
xCHRS: IBMPC 2
-o-o-o-o-o-o-o-o-CUT-o-o-o-o-o-o-o-o-o-

As you can see, although the message bundle is addressed to 1:229/426, the two packets contained therein are addressed to their respective Z2 addresses. Both these pkts will be delivered w/o problem by the forwarding node (229/426). It's always worked like this in the past, even before 1:261/38 was my feed - - years ago.

Please, when you have the opportunity, explain why BBBS's tosser/packer has issues with this.
Best regards,
Marc

--- timEd/2 1.10.y2k+
* Origin: Sursum Corda! BBS-Huntsville,AL-bbs.sursum-corda.com (1:396/45)

Hello Marc,

-o-o-o-o-o-o-o-o-CUT-o-o-o-o-o-o-o-o-o-
=-=-=-=-=-=-=-=-=-=-=-2nd MESSAGE PKT=-=-=-=-=-=-=-=-=-=-=-=-=-
PKT INFO:
1/1 396/45 333/808 0000003a NETMAIL Type 2+ Maximus-CBCS v1.11 O=1:396/45 D=2:333/808

This packet has a DestAddr of 2:333/808.

Please, when you have the opportunity, explain why BBBS's
tosser/packer has issues with this.

Because BBBS is operating in secure mode. There is a toggle in BBBS's setup to disable that and this is what the BBBS documentaion has to say about that.

=== Cut ===
Global: FidoNet: BOGUS: Disable security _______________________________________________________________________________

If this option is enabled, BOGUS will not pay any attention to echomail or netmail destinations or packet passwords. This is useful when a downlink
has you setup incorrectly and you want to toss the mail anyway.

WARNING: This is a very dangerous option to enable! You are very likely to get and generate duplicate messages or experience other problens with this enabled. Please be sure you know what you are doing before you turn this on! === Cut ===

If you routed that netmail to BBBS in a .pkt with a DestAddr of 1:261/38 then it would be tossed as expected and forwarded on toward the destination.

Ttyl :-),
Al

--- GoldED+/LNX 1.1.5-b20180707
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)