i seem to have found another problem... connecting to one of my links kept saying "bad password"... we are only linked with one of my addresses, 1:3634/12... by that i mean that they only have my 1:3634/12 address listed in their config with a session password... they don't have any of my other addresses listed at all... i contacted the link and they reported that my 1:123/0 address was being presented first instead of my 1:3634/12... they are running argus...

Peer version: Argus/3.210/ binkp/1.0

my addresses are entered into scfg->networking->fidonet->system addresses like this...

System Addresses
Main 1:3634/12
AKA 1 1:3634/0
AKA 2 1:3634/1
AKA 3 1:18/0
AKA 4 1:18/1
AKA 5 1:120/0

but, BinkIT sends them in this (string sorted?) order...

Sending M_ADR command args: 1:123/0@fidonet 1:18/1@fidonet 1:18/0@fidonet 1:3634/12@fidonet 1:3634/1@fidonet 1:3634/0@fidonet

however, in sbbsecho.ini, if i specify

BinkpSourceAddress = 1:3634/12
or
BinkpSourceAddress = 1:3634/12@fidonet

they seem to be sent in a more "proper" order but still not like they are entered...

Sending M_ADR command args: 1:3634/12@fidonet 1:3634/1@fidonet 1:3634/0@fidonet 1:123/0@fidonet 1:18/1@fidonet 1:18/0@fidonet

i understand the desire/ability to choose a source address to be presented first... especially if one is in more than one FTN... but i don't understand why the rest of the address list is not sent in the order they are entered in the address list...

sorry to be such a PITA...

---
* Synchronet * SouthEast Star Mail HUB - SESTAR
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: BinkIT sorts addresses??
By: waldo kitty to DigitalMan on Mon Sep 24 2018 12:41 pm

i seem to have found another problem... connecting to one of my links kept saying "bad password"... we are only linked with one of my addresses, 1:3634/12... by that i mean that they only have my 1:3634/12 address listed in their config with a session password... they don't have any of my other addresses listed at all... i contacted the link and they reported that my 1:123/0 address was being presented first instead of my 1:3634/12... they are running argus...

Why would the order of the addresses matter? I don't see anything in the BinkP standard (http://ftsc.org/docs/fts-1026.001) about requiring a specific ordering of teh addresses in the M_ADR message.

Peer version: Argus/3.210/ binkp/1.0

my addresses are entered into scfg->networking->fidonet->system addresses like this...

System Addresses
Main 1:3634/12
AKA 1 1:3634/0
AKA 2 1:3634/1
AKA 3 1:18/0
AKA 4 1:18/1
AKA 5 1:120/0

but, BinkIT sends them in this (string sorted?) order...

Mind you, I didn't write BinkIT (Deuce did), but I see these lines in the binkit.js file that you might want to play around with:

/*
* We can't use the defaults since the defaults are only 4D addresses,
* and the address we're calling from needs to be first...
*/
bp.addr_list = [];
system.fido_addr_list.forEach(function(faddr){
bp.addr_list.push(FIDO.parse_addr(faddr, this.default_zone));
}, this);

and:

// Sort by "distance" from src_addr address.
FIDO.distance_sort(bp.addr_list, src_addr);

Sending M_ADR command args: 1:3634/12@fidonet 1:3634/1@fidonet 1:3634/0@fidonet 1:123/0@fidonet 1:18/1@fidonet 1:18/0@fidonet

i understand the desire/ability to choose a source address to be presented first... especially if one is in more than one FTN... but i don't understand why the rest of the address list is not sent in the order they are entered in the address list...

I don't know. If there's a specification regarding the ordering of the addresses in the BinkP M_ADR message, I'm not aware of it.

sorry to be such a PITA...

No problem. See if you can get Deuce involved in the discussion, that'd be helpful.

digital man

Synchronet/BBS Terminology Definition #42:
R0DENT = Derogatory reference to a young BBS user of the 1990's
Norco, CA WX: 78.0oF, 54.0% humidity, 9 mph NNE wind, 0.00 inches rain/24hrs --- SBBSecho 3.06-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2018 Sep 24 14:56:30, you wrote to waldo kitty:

i seem to have found another problem... connecting to one of my links
kept saying "bad password"... we are only linked with one of my
addresses, 1:3634/12... by that i mean that they only have my 1:3634/12
address listed in their config with a session password... they don't
have any of my other addresses listed at all... i contacted the link
and they reported that my 1:123/0 address was being presented first
instead of my 1:3634/12... they are running argus...

Why would the order of the addresses matter?

because generally the first one entered into the system is the main FTN address... all others are just AKAs... the problem is that some systems use the
main address when they set up session level passwords... AKAs may not be listed
and secured... as long as the mail flows to the main address, then things are ok... if an AKA is not secured and mail is sent to it, it may not proprocessed...

in this case, my 123/0 address was being listed first and the Z3 system didn't know about or have that address listed since we only communicate using my main address, 1:3634/12...

I don't see anything in the BinkP standard (http://ftsc.org/docs/fts-1026.001) about requiring a specific
ordering of teh addresses in the M_ADR message.

yeah, it isn't a binkp thing... it is a normal FTN thing... i don't know of any
mailer that sorts the addresses and transmits them in a different order than they are entered into the system's configuration...

[...]

but, BinkIT sends them in this (string sorted?) order...

Mind you, I didn't write BinkIT (Deuce did),

i understand...

but I see these lines in the binkit.js file that you might want to
play around with:

ahhh, yes, i did read something about some sort of aka-matching stuff... i'll see if i can figure it out...

sorry to be such a PITA...

No problem. See if you can get Deuce involved in the discussion,
that'd be helpful.

i've started posting my questions to the message base instead of IRC... things can be really slow there when one is seeking quick help right now... anyway, i've got a lot set up and am now hunting for certain particulars...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Forgive your enemies. It messes with their heads.
---
* Origin: (1:3634/12.73)