I can confirm this is now working. Tests with Wilfred have been successful in getting a netmail into the unsecured directory

Wilfred's poll

[snip]

+ 16 Nov 09:18:00 [6112] call to 3:770/100@fidonet
16 Nov 09:18:00 [6112] trying ipv4.agency.bbs.geek.nz
[219.89.83.33]:24555...
16 Nov 09:18:00 [6112] connected
+ 16 Nov 09:18:00 [6112] outgoing session with ipv4.agency.bbs.geek.nz:24555 [219.89.83.33]
- 16 Nov 09:18:01 [6112] OPT CRAM-MD5-33d63ddc5fc5a828b8be0f7f3a42398b
+ 16 Nov 09:18:01 [6112] Remote requests MD mode
- 16 Nov 09:18:01 [6112] SYS Agency BBS
- 16 Nov 09:18:01 [6112] ZYZ Avon
- 16 Nov 09:18:01 [6112] VER Mystic/1.12A36 binkp/1.0
+ 16 Nov 09:18:01 [6112] addr: 46:3/203@agoranet (n/a or busy)
+ 16 Nov 09:18:01 [6112] addr: 39:970/1@AmigaNet
+ 16 Nov 09:18:01 [6112] addr: 3:770/100@fidonet
+ 16 Nov 09:18:01 [6112] addr: 24:400/100@sportnet (n/a or busy)
+ 16 Nov 09:18:01 [6112] addr: 21:1/101@fsxnet (n/a or busy)
+ 16 Nov 09:18:01 [6112] addr: 44:100/14@dorenet (n/a or busy)
+ 16 Nov 09:18:01 [6112] sending /home/fido/outbound.003/a0aa7041.pkt as a0aa7041.pkt (1182)
+ 16 Nov 09:18:02 [6112] sent: /home/fido/outbound.003/a0aa7041.pkt (1182, 1182.00 CPS, 3:770/100@fidonet)
+ 16 Nov 09:18:02 [6112] done (to 3:770/100@fidonet, OK, S/R: 1/0 (1182/0 bytes))
16 Nov 09:18:02 [6112] session closed, quitting...

[snip]

Agency BBS MIS2 logging

[snip]

+ 21:17:54 BINKP > Connect on slot 1/6
+ 21:17:54 BINKP 1-Address 80.101.186.126
+ 21:17:54 BINKP 1-HostName vlzn.xs4all.nl
+ 21:17:54 BINKP 1-Country Netherlands
+ 21:17:54 BINKP 1-Unsecure True
+ 21:17:54 BINKP 1-ForceMD5 False
+ 21:17:54 BINKP 1-Rename 0
+ 21:17:54 BINKP 1-New frame detected
+ 21:17:54 BINKP 1-Begin receive command frame: NUL (Size=56)
+ 21:17:54 BINKP 1-Recv Frame: (56) NUL SYS FMail dev HQ, FKA Amiga O(n|ff)line BBS Lisse (AOBL)
+ 21:17:54 BINKP 1-Auth State:SendChallenge Have:True Need:False
+ 21:17:54 BINKP 1-System FMail dev HQ, FKA Amiga O(n|ff)line BBS Lisse (AOBL)
+ 21:17:54 BINKP 1-Sent Frame: NUL OPT CRAM-MD5-33d63ddc5fc5a828b8be0f7f3a42398b
+ 21:17:54 BINKP 1-New frame detected
+ 21:17:54 BINKP 1-Begin receive command frame: NUL (Size=22)
+ 21:17:54 BINKP 1-Recv Frame: (22) NUL ZYZ Wilfred van Velzen
+ 21:17:54 BINKP 1-Auth State:SendWelcome Have:True Need:False
+ 21:17:54 BINKP 1-SysOp Wilfred van Velzen
+ 21:17:54 BINKP 1-Sent Frame: NUL SYS Agency BBS
+ 21:17:54 BINKP 1-Sent Frame: NUL ZYZ Avon
+ 21:17:54 BINKP 1-Sent Frame: NUL VER Mystic/1.12A36 binkp/1.0
+ 21:17:54 BINKP 1-Sent Frame: ADR 46:3/203@agoranet 39:970/1@amiganet 3:770/100@fidonet 24:400/100@sportnet 21:1/101@fsxnet 44:100/14@dorenet
+ 21:17:54 BINKP 1-New frame detected
+ 21:17:54 BINKP 1-Begin receive command frame: NUL (Size=22)
+ 21:17:54 BINKP 1-Recv Frame: (22) NUL LOC Lisse, Netherlands
+ 21:17:54 BINKP 1-Auth State:WaitAddress Have:True Need:False
+ 21:17:54 BINKP 1-Location Lisse, Netherlands
+ 21:17:54 BINKP 1-New frame detected
+ 21:17:54 BINKP 1-Begin receive command frame: NUL (Size=22)
+ 21:17:54 BINKP 1-Recv Frame: (22) NUL NDL CM,MO,IBN,PING,ENC
+ 21:17:54 BINKP 1-Info NDL CM,MO,IBN,PING,ENC
+ 21:17:54 BINKP 1-New frame detected
+ 21:17:54 BINKP 1-Begin receive command frame: NUL (Size=36)
+ 21:17:54 BINKP 1-Recv Frame: (36) NUL TIME Thu, 16 Nov 2017 09:18:00 +0100 + 21:17:54 BINKP 1-Info TIME Thu, 16 Nov 2017 09:18:00 +0100
+ 21:17:54 BINKP 1-New frame detected
+ 21:17:54 BINKP 1-Begin receive command frame: NUL (Size=33)
+ 21:17:54 BINKP 1-Recv Frame: (33) NUL VER binkd/1.1a-95/Linux binkp/1.1
+ 21:17:54 BINKP 1-Mailer binkd/1.1a-95/Linux binkp/1.1
+ 21:17:54 BINKP 1-New frame detected
+ 21:17:54 BINKP 1-Begin receive command frame: ADR (Size=35)
+ 21:17:54 BINKP 1-Recv Frame: (35) ADR 2:280/464@fidonet 39:39/0@AmigaNet
+ 21:17:54 BINKP 1-New frame detected
+ 21:17:54 BINKP 1-Begin receive command frame: NUL (Size=27)
+ 21:17:54 BINKP 1-Recv Frame: (27) NUL OPT NDA EXTCMD CRYPT GZ BZ2
+ 21:17:54 BINKP 1-Auth State:WaitPW Have:True Need:False
+ 21:17:54 BINKP 1-Received challenge (33d63ddc5fc5a828b8be0f7f3a42398b)
+ 21:17:54 BINKP 1-Frame wait
+ 21:17:54 BINKP 1-Auth State:WaitPW Have:False Need:True
+ 21:17:54 BINKP 1-Frame wait
+ 21:17:55 BINKP 1-Frame wait
+ 21:17:55 BINKP 1-Frame wait
+ 21:17:55 BINKP 1-Frame wait
+ 21:17:55 BINKP 1-Frame wait
+ 21:17:55 BINKP 1-New frame detected
+ 21:17:55 BINKP 1-Begin receive command frame: NUL (Size=7)
+ 21:17:55 BINKP 1-Recv Frame: (7) NUL TRF 0 0
+ 21:17:55 BINKP 1-Auth State:WaitPW Have:True Need:False
+ 21:17:55 BINKP 1-Info TRF 0 0
+ 21:17:55 BINKP 1-New frame detected
+ 21:17:55 BINKP 1-Begin receive command frame: PWD (Size=41)
+ 21:17:55 BINKP 1-Recv Frame: Password
+ 21:17:55 BINKP 1-Sent Frame: OK non-secure
+ 21:17:55 BINKP 1-Unsecured session
+ 21:17:55 BINKP 1-Before Frame State R:WaitFile T:NextFile Have:False Need:True
+ 21:17:55 BINKP 1-Frame wait
+ 21:17:55 BINKP 1-Sent Frame: EOB
+ 21:17:55 BINKP 1-Before Frame State R:WaitFile T:Done Have:False Need:True
+ 21:17:55 BINKP 1-Frame wait
+ 21:17:55 BINKP 1-Frame wait
+ 21:17:55 BINKP 1-New frame detected
+ 21:17:55 BINKP 1-Begin receive command frame: FILE (Size=30)
+ 21:17:55 BINKP 1-Recv Frame: (30) FILE a0aa7041.pkt 1182 1510647556 0
+ 21:17:55 BINKP 1-After Frame State R:WaitFile T:Done Have:True Need:False
+ 21:17:55 BINKP 1-Receiving: a0aa7041.pkt (1,182 bytes)
+ 21:17:55 BINKP 1-Before Frame State R:GetData T:Done Have:False Need:True
+ 21:17:55 BINKP 1-Frame wait
+ 21:17:56 BINKP 1-Frame wait
+ 21:17:56 BINKP 1-Frame wait
+ 21:17:56 BINKP 1-New frame detected
+ 21:17:56 BINKP 1-Begin receive data frame (Size=1182)
+ 21:17:56 BINKP 1-Data Frame: 1,182/1,182
+ 21:17:56 BINKP 1-After Frame State R:GetData T:Done Have:True Need:False
+ 21:17:56 BINKP 1-Received 1,182 of 1,182
+ 21:17:56 BINKP 1-Sent Frame: GOT a0aa7041.pkt 1182 1510647556
+ 21:17:56 BINKP 1-Before Frame State R:WaitFile T:Done Have:False Need:True
+ 21:17:56 BINKP 1-Frame wait
+ 21:17:56 BINKP 1-Frame wait
+ 21:17:56 BINKP 1-Frame wait
+ 21:17:56 BINKP 1-New frame detected
+ 21:17:56 BINKP 1-Begin receive command frame: EOB (Size=0)
+ 21:17:56 BINKP 1-Recv Frame: (0) EOB
+ 21:17:56 BINKP 1-After Frame State R:WaitFile T:Done Have:True Need:False
+ 21:17:56 BINKP 1-Session ended (0 sent, 1 rcvd, 0 skip)
+ 21:17:56 BINKP 1-Client thread shutting down
+ 21:18:00 EVENT Detected semaphore: c:\bbs\mystic\semaphor\echomail.in
+ 21:18:00 EVENT Event begin: Toss Incoming (Mystic)

[snip]

Now of interest this packet contained a password so Mystic did not import the netmail from this unknown system.

[snip]

! Nov 16 21:18:00 Import from c:\bbs\mystic\echomail\in\
! Nov 16 21:18:00 Import from c:\bbs\mystic\echomail\in\unsec\
+ Nov 16 21:18:00 Importing a0aa7041.pkt (2:280/464 to 3:770/100)
! Nov 16 21:18:00 Invalid PKT password
+ Nov 16 21:18:00 Results: 0 echo, 0 net, 0 dupes, 0 tossed in 0.05s
+ Nov 16 21:18:00 Shutdown Normal (0)

[snip]

I think in cases like this where netmail is coming in from an unsecured node Mystic should toss the netmail in and ignore a packet password where none is expected.

If you think the current behaviour is correct then I still think the sysop needs to get some system generated alert (BBS email?) to let them know something is up, else they may never know a message arrived unless they instigate a regular regime of checking directories which I think is not very realistic for many...

Some further observations for pondering.

When Wilfred then turned on his BinkP session password and tried polling
Agency again (and he was still an unknown non-defined echonode at Agency)
this is what he saw

[snip]

+ 16 Nov 09:21:49 [6500] call to 3:770/100@fidonet
16 Nov 09:21:49 [6500] trying ipv4.agency.bbs.geek.nz
[219.89.83.33]:24555...
16 Nov 09:21:50 [6500] connected
+ 16 Nov 09:21:50 [6500] outgoing session with ipv4.agency.bbs.geek.nz:24555 [219.89.83.33]
- 16 Nov 09:21:50 [6500] OPT CRAM-MD5-3e82fe3654c60fa4c36cb9dc5c15265f
+ 16 Nov 09:21:50 [6500] Remote requests MD mode
- 16 Nov 09:21:50 [6500] SYS Agency BBS
- 16 Nov 09:21:50 [6500] ZYZ Avon
- 16 Nov 09:21:50 [6500] VER Mystic/1.12A36 binkp/1.0
+ 16 Nov 09:21:50 [6500] addr: 46:3/203@agoranet (n/a or busy)
+ 16 Nov 09:21:50 [6500] addr: 39:970/1@AmigaNet
+ 16 Nov 09:21:50 [6500] addr: 3:770/100@fidonet
+ 16 Nov 09:21:50 [6500] addr: 24:400/100@sportnet (n/a or busy)
+ 16 Nov 09:21:50 [6500] addr: 21:1/101@fsxnet (n/a or busy)
+ 16 Nov 09:21:50 [6500] addr: 44:100/14@dorenet (n/a or busy)
? 16 Nov 09:21:51 [6500] rerror:
+ 16 Nov 09:21:51 [6500] holding 3:770/100@fidonet (2017/11/16 11:21:51)
+ 16 Nov 09:21:51 [6500] done (to 3:770/100@fidonet, failed, S/R: 0/0 (0/0 bytes))
16 Nov 09:21:51 [6500] session closed, quitting...


[snip]

MIS2 is sending an empty error message which could be improved upon perhaps?

From the Agency end the transaction looked like this

[snip]

+ 21:21:44 BINKP 1-Address 80.101.186.126
+ 21:21:44 BINKP 1-HostName vlzn.xs4all.nl
+ 21:21:44 BINKP 1-Country Netherlands
+ 21:21:44 BINKP 1-Unsecure True
+ 21:21:44 BINKP 1-ForceMD5 False
+ 21:21:44 BINKP 1-Rename 0
+ 21:21:44 BINKP 1-New frame detected
+ 21:21:44 BINKP 1-Begin receive command frame: NUL (Size=56)
+ 21:21:44 BINKP 1-Recv Frame: (56) NUL SYS FMail dev HQ, FKA Amiga O(n|ff)line BBS Lisse (AOBL)
+ 21:21:44 BINKP 1-Auth State:SendChallenge Have:True Need:False
+ 21:21:44 BINKP 1-System FMail dev HQ, FKA Amiga O(n|ff)line BBS Lisse (AOBL)
+ 21:21:44 BINKP 1-Sent Frame: NUL OPT CRAM-MD5-3e82fe3654c60fa4c36cb9dc5c15265f
+ 21:21:44 BINKP 1-New frame detected
+ 21:21:44 BINKP 1-Begin receive command frame: NUL (Size=22)
+ 21:21:44 BINKP 1-Recv Frame: (22) NUL ZYZ Wilfred van Velzen
+ 21:21:44 BINKP 1-Auth State:SendWelcome Have:True Need:False
+ 21:21:44 BINKP 1-SysOp Wilfred van Velzen
+ 21:21:44 BINKP 1-Sent Frame: NUL SYS Agency BBS
+ 21:21:44 BINKP 1-Sent Frame: NUL ZYZ Avon
+ 21:21:44 BINKP 1-Sent Frame: NUL VER Mystic/1.12A36 binkp/1.0
+ 21:21:44 BINKP 1-Sent Frame: ADR 46:3/203@agoranet 39:970/1@amiganet 3:770/100@fidonet 24:400/100@sportnet 21:1/101@fsxnet 44:100/14@dorenet
+ 21:21:44 BINKP 1-New frame detected
+ 21:21:44 BINKP 1-Begin receive command frame: NUL (Size=22)
+ 21:21:44 BINKP 1-Recv Frame: (22) NUL LOC Lisse, Netherlands
+ 21:21:44 BINKP 1-Auth State:WaitAddress Have:True Need:False
+ 21:21:44 BINKP 1-Location Lisse, Netherlands
+ 21:21:44 BINKP 1-New frame detected
+ 21:21:44 BINKP 1-Begin receive command frame: NUL (Size=22)
+ 21:21:44 BINKP 1-Recv Frame: (22) NUL NDL CM,MO,IBN,PING,ENC
+ 21:21:44 BINKP 1-Info NDL CM,MO,IBN,PING,ENC
+ 21:21:44 BINKP 1-New frame detected
+ 21:21:44 BINKP 1-Begin receive command frame: NUL (Size=36)
+ 21:21:44 BINKP 1-Recv Frame: (36) NUL TIME Thu, 16 Nov 2017 09:21:50 +0100 + 21:21:44 BINKP 1-Info TIME Thu, 16 Nov 2017 09:21:50 +0100
+ 21:21:44 BINKP 1-New frame detected
+ 21:21:44 BINKP 1-Begin receive command frame: NUL (Size=33)
+ 21:21:44 BINKP 1-Recv Frame: (33) NUL VER binkd/1.1a-95/Linux binkp/1.1
+ 21:21:44 BINKP 1-Mailer binkd/1.1a-95/Linux binkp/1.1
+ 21:21:44 BINKP 1-New frame detected
+ 21:21:44 BINKP 1-Begin receive command frame: ADR (Size=35)
+ 21:21:44 BINKP 1-Recv Frame: (35) ADR 2:280/464@fidonet 39:39/0@AmigaNet
+ 21:21:44 BINKP 1-New frame detected
+ 21:21:44 BINKP 1-Begin receive command frame: NUL (Size=27)
+ 21:21:44 BINKP 1-Recv Frame: (27) NUL OPT NDA EXTCMD CRYPT GZ BZ2
+ 21:21:44 BINKP 1-Auth State:WaitPW Have:True Need:False
+ 21:21:44 BINKP 1-Received challenge (3e82fe3654c60fa4c36cb9dc5c15265f)
+ 21:21:44 BINKP 1-Frame wait
+ 21:21:44 BINKP 1-Auth State:WaitPW Have:False Need:True
+ 21:21:44 BINKP 1-Frame wait
+ 21:21:44 BINKP 1-Frame wait
+ 21:21:44 BINKP 1-Frame wait
+ 21:21:44 BINKP 1-Frame wait
+ 21:21:44 BINKP 1-Frame wait
+ 21:21:44 BINKP 1-New frame detected
+ 21:21:44 BINKP 1-Begin receive command frame: NUL (Size=7)
+ 21:21:44 BINKP 1-Recv Frame: (7) NUL TRF 0 0
+ 21:21:44 BINKP 1-Auth State:WaitPW Have:True Need:False
+ 21:21:44 BINKP 1-Info TRF 0 0
+ 21:21:44 BINKP 1-New frame detected
+ 21:21:44 BINKP 1-Begin receive command frame: PWD (Size=41)
+ 21:21:44 BINKP 1-Recv Frame: Password
+ 21:21:44 BINKP 1-Looking for matching address in Echomail nodes:
+ 21:21:44 BINKP 1-No match in client's address list for 3:770/1@fidonet
+ 21:21:44 BINKP 1-No match in client's address list for 46:3/103@agoranet
+ 21:21:44 BINKP 1-No match in client's address list for 39:970/0@amiganet
+ 21:21:44 BINKP 1-No match in client's address list for 24:400/1@sportnet
+ 21:21:44 BINKP 1-No match in client's address list for 21:1/100@fsxnet
+ 21:21:44 BINKP 1-No match in client's address list for 44:100/0@dorenet
+ 21:21:44 BINKP 1-No match in client's address list for 21:1/10@fsxnet
+ 21:21:44 BINKP 1-No matching AKA to authenticate
+ 21:21:44 BINKP 1-Cannot authenticate client
+ 21:21:44 BINKP 1-Sent Frame: ERR
+ 21:21:44 BINKP 1-Client thread shutting down

[snip]

Hope this info / feedback is of help :)

Best, Paul

--- Mystic BBS v1.12 A36 2017/11/15 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 11/16/17, Avon pondered and said...

When Wilfred then turned on his BinkP session password and tried polling Agency again (and he was still an unknown non-defined echonode at Agency) this is what he saw

+ 16 Nov 09:21:50 [6500] addr: 44:100/14@dorenet (n/a or busy)
? 16 Nov 09:21:51 [6500] rerror:

From the Agency end the transaction looked like this

+ 21:21:44 BINKP 1-New frame detected
+ 21:21:44 BINKP 1-Begin receive command frame: PWD (Size=41)
+ 21:21:44 BINKP 1-Recv Frame: Password
+ 21:21:44 BINKP 1-Looking for matching address in Echomail nodes:
+ 21:21:44 BINKP 1-No match in client's address list for 3:770/1@fidonet + 21:21:44 BINKP 1-No match in client's address list for 46:3/103@agoranet + 21:21:44 BINKP 1-No match in client's address list for 39:970/0@amiganet + 21:21:44 BINKP 1-No match in client's address list for 24:400/1@sportnet + 21:21:44 BINKP 1-No match in client's address list for 21:1/100@fsxnet + 21:21:44 BINKP 1-No match in
client's address list for 44:100/0@dorenet + 21:21:44 BINKP 1-No match
in client's address list for 21:1/10@fsxnet + 21:21:44 BINKP 1-No matching AKA to authenticate + 21:21:44 BINKP 1-Cannot authenticate client + 21:21:44 BINKP 1-Sent Frame: ERR

Just pondering this aspect some more. Do you think if a mailer sends an unexpected password, that Mystic should accept the connection but place all received traffic in the unsecured directory instead of just rejecting the incoming connection?

I'm leaning towards 'yes it should allow the connection to take place' to ensure communications between nodes do happen - with the caveats in place of rules around how unsecured traffic is treated by Mystic.

If my understanding of MUTIL is correct the [ImportEchoMail] stanza has the switch

[snip]

; Toss packets from unsecure directory in addition to inbound?

unsecure_dir = true

[snip]

to allow the sysop to define if echomail is to be tossed from the unsecured directory BUT that netmail will always be tossed in regardless of that switch.... is that correct / how you intended things to run?

If so then allowing the BinkP connection scenario discussed above to take place, would be a good move I think :)

Best, Paul

--- Mystic BBS v1.12 A36 2017/11/15 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

Hello Avon,

Moments ago my 21:1/128 polled you at 21:1/101.

The results were:

171116 04:39 Calling Agency BBS, ipv4.agency.bbs.geek.nz:24555
171116 04:39 CONNECT 57600/RAW
171116 04:39 BinkP mail session
171116 04:39 Agency BBS, 46:3/203
171116 04:39 AKA: 39:970/1
171116 04:39 AKA: 3:770/100
171116 04:39 AKA: 24:400/100
171116 04:39 AKA: 21:1/101
171116 04:39 AKA: 44:100/14
171116 04:39 SysOp: Avon
171116 04:39 Using: Mystic/1.12A36 binkp/1.0
171116 04:39 Mail session completed
171116 04:39 --------------------------

Does your end show a successful connection?


Jeff

--- BBBS/Li6 v4.10 Toy-3
* Origin: FsxNet: The Ouija Board - bbs.ouijabrd.net (21:1/128)

Hope this info / feedback is of help :)

I've changed it to send a message reading "Bad address or password" now in
that situation.

--- Mystic BBS v1.12 A36 2017/11/15 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

Just pondering this aspect some more. Do you think if a mailer sends an unexpected password, that Mystic should accept the connection but place all received traffic in the unsecured directory instead of just
rejecting the incoming connection?

I am thinking about this and I am leaning towards disagreeing. If someone is attempting to authenticate with a password and they don't correct supply a valid password, then I think the connection needs to be refused. That is what authentication is for.

If the remote client requests a *proper* unsecure session, and you are configured to allow it, then things should work as expected.

There is no real world situation where a unsecure node would call your BBS
and supply a password, outside of the time in which that person is actually configuring your information so that the connection *IS* secure. In that
case, the connection should be refused so the error in password configuration can be addressed.

Regardless of opinions I believe this is already covered just by looking at the BINKP specifications. If a bad password is sent, the proper response is to send the error frame and close the connection (exit), as shown below:

| R4 | PwdAck | Yes, the password | Send M_OK frame | R5 |
| | | matches | Report secure | |
| | | | session | |
| | |---------------------+----------------------+----+
| | | No password and got | Send M_OK frame | R5 |
| | | M_PWD "-" frame | Report unsecure | |
| | | | session | |
| | |---------------------+----------------------+----|
| | | No, password does | Report password error|exit|
| | | not match | Send M_ERR | |

to allow the sysop to define if echomail is to be tossed from the unsecured directory BUT that netmail will always be tossed in regardless of that switch.... is that correct / how you intended things to run?

Yes, I believe this is how it works.

--- Mystic BBS v1.12 A36 2017/11/15 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 11/16/17, g00r00 pondered and said...

I am thinking about this and I am leaning towards disagreeing. If
someone is attempting to authenticate with a password and they don't correct supply a valid password, then I think the connection needs to be refused. That is what authentication is for.

The table supplied and your preceding reasoning I do agree with.. all good points.

to allow the sysop to define if echomail is to be tossed from the unsecured directory BUT that netmail will always be tossed in regardl of that switch.... is that correct / how you intended things to run?

Yes, I believe this is how it works.

Good stuff, thanks... was just confirming in my mind the intended processes.

Best, Paul

--- Mystic BBS v1.12 A36 2017/11/15 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 11/16/17, g00r00 pondered and said...

Hope this info / feedback is of help :)

I've changed it to send a message reading "Bad address or password" now
in that situation.

Thank you :) Just to clarify, send a message where?

Best, Paul

--- Mystic BBS v1.12 A36 2017/11/15 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

I've changed it to send a message reading "Bad address or password" n in that situation.

Thank you :) Just to clarify, send a message where?

You asked for BINKP to print a message along with the error frame in BINKP during authentication, so I added that message.

--- Mystic BBS v1.12 A36 2017/11/15 (Windows/32)
* Origin: Sector 7 [Mystic BBS WHQ] (21:1/108)

On 11/16/17, g00r00 pondered and said...

You asked for BINKP to print a message along with the error frame in
BINKP during authentication, so I added that message.

Gotcha.. thanks :)

--- Mystic BBS v1.12 A36 2017/11/15 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

On 11/16/17, g00r00 pondered and said...

I've changed it to send a message reading "Bad address or passwo in that situation.

Thank you :) Just to clarify, send a message where?

You asked for BINKP to print a message along with the error frame in
BINKP during authentication, so I added that message.

Tested and confirmed :) Thanks.

[snip]

- 20 Nov 20:48:57 [24137] OPT CRAM-MD5-4d2687f08396382e86d161fb44322f1b
+ 20 Nov 20:48:57 [24137] Remote requests MD mode
- 20 Nov 20:48:57 [24137] SYS fsxHUB [fsxNet WHQ]
- 20 Nov 20:48:57 [24137] ZYZ Paul Hayton
- 20 Nov 20:48:57 [24137] VER Mystic/1.12A36 binkp/1.0
+ 20 Nov 20:48:57 [24137] addr: 21:1/100@fsxnet
+ 20 Nov 20:48:57 [24137] addr: 21:1/3@fsxnet
+ 20 Nov 20:48:57 [24137] addr: 21:1/2@fsxnet
+ 20 Nov 20:48:57 [24137] addr: 21:1/0@fsxnet
+ 20 Nov 20:48:57 [24137] addr: 21:0/0@fsxnet
? 20 Nov 20:48:57 [24137] rerror: Bad address or password
+ 20 Nov 20:48:57 [24137] done (to 21:1/100@fsxnet, failed, S/R: 0/0 (0/0 bytes))
20 Nov 20:48:57 [24137] session closed, quitting...
20 Nov 20:48:57 [1216] rc(24137)=0
! 20 Nov 20:49:41 [1213] got signal #2. Killing 1216 and quitting...
! 20 Nov 20:49:41 [1216] got signal #15.

[snip]

Best, Paul

--- Mystic BBS v1.12 A36 2017/11/19 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (21:1/101)

g00r00 wrote to Avon <=-

Just pondering this aspect some more. Do you think if a mailer sends an unexpected password, that Mystic should accept the connection but place all received traffic in the unsecured directory instead of just
rejecting the incoming connection?

I can only see one reason to allow this, and that would be in the instance something bad happened and you're rebuilding your system from scratch (maybe the backup is toast). Having the (obscure option) to allow insecure sessions with an authentication attempt might help one get their links back up - at least get netmail through to exchange the correct information`. While people would normally have email, one can't assume, or one might not remember the email address for their feeds.


... Reality is for those who can't handle computers.
___ MultiMail/Win32 v0.49

--- Mystic BBS/QWK v1.12 A35 (Raspberry Pi/32)
* Origin: The Bridge - bridge.vkradio.com (21:1/143)