Why am I getting this in SBBSECho v3.CVS? Gotta be something simple I changed.

WIN95: Unauthenticated WIN95 EchoMail from 1:218/700 ignored

FIDONEWS: Unauthenticated FIDONEWS EchoMail from 1:218/700 ignored

FN_SYSOP: Unauthenticated FN_SYSOP EchoMail from 1:218/700 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:218/700 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:218/700 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:218/700 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:218/700 ignored

HAM: Unauthenticated HAM EchoMail from 1:218/700 ignored

etc? My Areas.BBS file has:
FIDOHAMHAM1:218/700
...for example, for each echo.

Here's my SBBSECHO.INI:
CheckPathsForDupes = true
KillEmptyNetmail = false
AreaAddFromEcholistsOnly = false
SecureEchomail = false
BinkleyStyleOutbound = true
TruncateBundles = false
FuzzyNetmailZones = false
StripLineFeeds = false
ConvertTearLines = false

SysopAliasList = SYSOP,ANDROID8675
ZoneBlind = false
LogLevel = Debugging
BundleSize = 2000K
areafile = c:\sbbs\data\areas.bbs
logfile = c:\fido\_log\sbbsecho.log
inbound = c:\fido\_IN\
secureinbound = c:\fido\_inSEC\
outbound = C:\Fido\_OUT\
TempDirectory = c:\sbbs\temp\sbbsecho\
PacketSize = 250K
ZoneBlindThreshold = 65535
StrictPacketPasswords = true
EchomailNotify = true
BsyTimeout = 12H
BsoLockDelay = 10S
BsoLockAttempts = 60
MaxEchomailAge = 60D
MaxNetmailAge = 0Y
IgnoreNetmailDestAddr = false
IgnoreNetmailRecvAttr = false
IgnoreNetmailLocalAttr = false
DefaultRecipient = SYSOP
UseFTNDomains = false
LogTimeFormat = %m/%d/%y %H:%M:%S
RelayFilteredMsgs = false
IgnoreNetmailSentAttr = false


[node:1:218/700]
Comment = FidoNet, reality
AreafixPwd = NOTPASS
PacketPwd =
PacketType = 2+
Archive = ZIP
Inbox =
Outbox =
Passive = false
Direct = true
Notify = false
Keys =
Status = Normal

---
* Synchronet * Shodan's Core @ ShodansCore.com (Port 2323 for Nethack)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

On 3/27/2017 2:00 PM, Android8675 -> All wrote:

Why am I getting this in SBBSECho v3.CVS? Gotta be something simple I changed.

WIN95: Unauthenticated WIN95 EchoMail from 1:218/700 ignored

FIDONEWS: Unauthenticated FIDONEWS EchoMail from 1:218/700 ignored

FN_SYSOP: Unauthenticated FN_SYSOP EchoMail from 1:218/700 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:218/700 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:218/700 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:218/700 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:218/700 ignored

HAM: Unauthenticated HAM EchoMail from 1:218/700 ignored

etc? My Areas.BBS file has:
FIDOHAMHAM1:218/700
..for example, for each echo.

First, are you sure "FIDOHAMHAM" is a legit echotag? It doesn't seem like it would be.

The format of your areas.bbs file should be:

[SCFG INTERNAL CODE] [ECHOTAG] [LINK] [...]

So maybe something removed all the spaces on you? I could see the above being something more like:

FIDOHAM HAM 1:218/700

So the first value is the internal code of the sub-board used in SCFG, which I believe is limited to 8 characters (although it seems you're using the prefix FIDO also, so it can be more in that case all of your sub-board codes in that group will be prefixed with FIDO also. The second value is the actual fidonet echotag as shown in your echolist. Then the third (and concurrent fields thereafter) are for your links. All three (or more) fields need at least one space between them.

If your areas.bbs is messed up, you may want to try exporting a new one, named something else so you don't overwrite your old one. Then check to make sure it exported properly before renaming it back to areas.bbs.

--
Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45
* Origin: thePharcyde_ distribution system (1:154/10)

Re: SBBSEcho v3.daily Unauthenticated?
By: Nicholas Boel to Android8675 on Mon Mar 27 2017 02:52 pm

etc? My Areas.BBS file has:

FIDOHAMHAM1:218/700

..for example, for each echo.

First, are you sure "FIDOHAMHAM" is a legit echotag? It doesn't seem like it

would be.

It is, I copied and pasted into syncterm, it didn't translate the TABs. That

line is actually



FIDOHAM HAM 1:218/700



If I run sbbsecho -a (I think it's a, it's the command that spits out the

areas.bbs data after it's parsed in) it spits out the areas.bbs data correctly.



I've used the same areas.bbs for a LONG time with different mailers, and binkit

was working for a while as situated. I found some old posts from nolageek, I

think it has something to do with the .pkts not going to the InboundSecure

folder (_IN is unsecured, _INSec is secured). Maybe BinkIt is the problem. I

don't know where binkit logs are saved.
--- SBBSecho 3.00-Win32
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Android8675 to All on Mon Mar 27 2017 12:00 pm

Why am I getting this in SBBSECho v3.CVS? Gotta be something simple I changed.

WIN95: Unauthenticated WIN95 EchoMail from 1:218/700 ignored

You need to either utilize a packet password or a secure mailer session. Apparently you're not utilizing a packet password for 1:218/700 and receiving bundles/packets in a non-secure mailer session.

digital man

Synchronet/BBS Terminology Definition #8:
BSO = Binkley Style Outbound
Norco, CA WX: 81.0oF, 19.0% humidity, 15 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.00-Win32
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Nicholas Boel to Android8675 on Mon Mar 27 2017 14:52:08

On 3/27/2017 2:00 PM, Android8675 -> All wrote:

Why am I getting this in SBBSECho v3.CVS? Gotta be something simple I
changed.

WIN95: Unauthenticated WIN95 EchoMail from 1:218/700 ignored

FIDONEWS: Unauthenticated FIDONEWS EchoMail from 1:218/700 ignored

FN_SYSOP: Unauthenticated FN_SYSOP EchoMail from 1:218/700 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:218/700 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:218/700 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:218/700 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:218/700 ignored

HAM: Unauthenticated HAM EchoMail from 1:218/700 ignored

etc? My Areas.BBS file has:
FIDOHAMHAM1:218/700
..for example, for each echo.

First, are you sure "FIDOHAMHAM" is a legit echotag? It doesn't seem like it would be.

The format of your areas.bbs file should be:

[SCFG INTERNAL CODE] [ECHOTAG] [LINK] [...]

So maybe something removed all the spaces on you? I could see the above being something more like:

FIDOHAM HAM 1:218/700

So the first value is the internal code of the sub-board used in SCFG, which I believe is limited to 8 characters (although it seems you're using the prefix FIDO also, so it can be more in that case all of your sub-board codes in that group will be prefixed with FIDO also. The second value is the actual fidonet echotag as shown in your echolist. Then the third (and concurrent fields thereafter) are for your links. All three (or more) fields need at least one space between them.

If your areas.bbs is messed up, you may want to try exporting a new one, named something else so you don't overwrite your old one. Then check to make sure it exported properly before renaming it back to areas.bbs.

I got Same problem , with other Network too, but if i rename the PKT
from *.bad to *.pkt and Try Again it's Working

none of my network have password except one

Problem Seem to be intermitant

"... Success is one unpardonable sin against one's fellows."
--- SBBSecho 3.00-Win32
* Origin: SpaceSST BBS Gateway <> Fidonet Usenet (1:249/206)

On 4/1/2017 6:14 AM, Luc Mccarragher -> Nicholas Boel wrote:

I got Same problem , with other Network too, but if i rename the PKT
from *.bad to *.pkt and Try Again it's Working

none of my network have password except one

Problem Seem to be intermitant

Is the one link this is occurring with by chance a D'Bridge system?

One thing that has changed since sbbsecho v3 is that it does not allow for packet passwords to "slip by" any more.

If you're linked to a D'Bridge system, and they have a "Session Password" setup

with them, it (D'Bridge) will indeed also send that same password as a packet password - which sbbsecho will mark as bad until you manually add in the packet

password for that link to your config.

As far as I know D'Bridge has always done this, but it wasn't until sbbsecho v3

that it was noticed and other measures had to be taken. I think sbbsecho v2 used to ignore incoming packet passwords, and now it doesn't any more.

--
Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45
# Origin: thePharcyde_ distribution system (723:1/1)
* Synchronet * thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Digital Man to Android8675 on Wed Mar 29 2017 03:28 pm

Why am I getting this in SBBSECho v3.CVS? Gotta be something simple I
changed.

WIN95: Unauthenticated WIN95 EchoMail from 1:218/700 ignored

You need to either utilize a packet password or a secure mailer session. Apparently you're not utilizing a packet password for 1:218/700 and receiving bundles/packets in a non-secure mailer session.

Yeah, no packet password, never had one of those before, but we use a session password which starts a secure session, so shouldn't the packets just go to the secure folder?

You said we need one OR the other... or is it AND?

Poll connect log...
4/1 04:04:00p Attempting poll for node 1:218/700@fidonet
4/1 04:04:00p Callout to 1:218/700@fidonet started.
4/1 04:04:03p Sent M_NUL command args: OPT CRYPT
4/1 04:04:03p Sent M_NUL command args: SYS Shodan's Core
4/1 04:04:03p Sent M_NUL command args: ZYZ Android8675
4/1 04:04:03p Sent M_NUL command args: LOC Prunedale, CA
4/1 04:04:03p Sent M_NUL command args: NDL 115200,TCP,BINKP
4/1 04:04:03p Sent M_NUL command args: TIME Sat Apr 01 2017 16:04:03 GMT-0700 (Pacific Daylight Time)
4/1 04:04:03p Sent M_NUL command args: VER BinkIT/1.44,JSBinkP/1.69/Win32 binkp/1.1
4/1 04:04:03p Sent M_ADR command args: 1:218/600@fidonet 46:1/121@agoranet 201:1000/10@dbnet 618:300/26@micronet
4/1 04:04:04p Got M_NUL command args: OPT CRAM-MD5-dd3b42b2413f8d03eb694a9aae815a5f
4/1 04:04:04p Got M_NUL command args: OPT PLZ CRYPT
4/1 04:04:04p Will encrypt session.
4/1 04:04:04p Got M_NUL command args: SYS realitycheckBBS
4/1 04:04:04p Got M_NUL command args: ZYZ Kurt Weiske
4/1 04:04:04p Got M_NUL command args: LOC Santa Cruz County, CA USA
4/1 04:04:04p Got M_NUL command args: PHN realitycheckbbs.org
4/1 04:04:04p Got M_NUL command args: NDL CM,TCP,BND
4/1 04:04:04p Got M_NUL command args: TIME Sat, 01 Apr 2017 16:04:04 -0700
4/1 04:04:04p Got M_NUL command args: VER Radius/4.010/21.01.2005,13:56(Final-Release)/Win32 binkp/1.1
4/1 04:04:04p Got M_ADR command args: 618:300/1@micronet 46:1/115@agoranet 9:91/4@survnet 1:218/700@fidonet 1:10/1@fidonet 1:10/0@fidonet 1:102/0@fidonet 1:143/0@fidonet 1:143/1@fidonet 1:218/0@fidonet 1:218/1@fidonet 618:300/16@micronet
4/1 04:04:04p Sent M_PWD command args: CRAM-MD5-fa28fdfc7acb4bc22d591aaa43ec99fd
4/1 04:04:04p Got M_OK command args:
4/1 04:04:04p Unconfigured address 46:1/115@agoranet
4/1 04:04:04p Unconfigured address 9:91/4@survnet
4/1 04:04:04p Unconfigured address 1:10/1@fidonet
4/1 04:04:04p Unconfigured address 1:10/0@fidonet
4/1 04:04:04p Unconfigured address 1:102/0@fidonet
4/1 04:04:04p Unconfigured address 1:143/0@fidonet
4/1 04:04:04p Unconfigured address 1:143/1@fidonet
4/1 04:04:04p Unconfigured address 1:218/0@fidonet
4/1 04:04:04p Unconfigured address 1:218/1@fidonet
4/1 04:04:04p Unconfigured address 618:300/16@micronet
4/1 04:04:04p Adding outbound files for 618:300/1@micronet
4/1 04:04:04p Adding outbound files for 1:218/700@fidonet
4/1 04:04:04p Initializing crypt keys.
4/1 04:04:04p Sent M_EOB command args:
4/1 04:04:05p Got M_EOB command args:
4/1 04:04:05p Unlocking C:\Fido\_OUT\00da02bc.bsy.

---
* Synchronet * Shodan's Core @ ShodansCore.com (Port 2323 for Nethack)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Nicholas Boel to Luc Mccarragher on Sat Apr 01 2017 08:42 am

On 4/1/2017 6:14 AM, Luc Mccarragher -> Nicholas Boel wrote:

I got Same problem , with other Network too, but if i rename the PKT from *.bad to *.pkt and Try Again it's Working

none of my network have password except one

Problem Seem to be intermitant

Is the one link this is occurring with by chance a D'Bridge system?

One thing that has changed since sbbsecho v3 is that it does not allow for packet passwords to "slip by" any more.

If you're linked to a D'Bridge system, and they have a "Session Password" setup
with them, it (D'Bridge) will indeed also send that same password as a packet password - which sbbsecho will mark as bad until you manually add in the packet
password for that link to your config.

As far as I know D'Bridge has always done this, but it wasn't until sbbsecho v3
that it was noticed and other measures had to be taken. I think sbbsecho v2 used to ignore incoming packet passwords, and now it doesn't any more.

Let me clarify: with SBBSecho v2, if the local link/node was not configured with a packet password, then the incoming packet passwords were ignored (for that node). Otherwise (a password was configured), then the packet password had to match (was not ignored).

Now, with SBBSecho v3, the packet password always has to match the local configuration. If there's no local link/node configuration or the configured password is blank, then the packet password must also be blank.

digital man

Synchronet/BBS Terminology Definition #34:
MODEM = Modulator/Demodulator
Norco, CA WX: 74.0oF, 29.0% humidity, 15 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.00-Win32
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Android8675 to Digital Man on Sat Apr 01 2017 04:06 pm

Re: SBBSEcho v3.daily Unauthenticated?
By: Digital Man to Android8675 on Wed Mar 29 2017 03:28 pm

Why am I getting this in SBBSECho v3.CVS? Gotta be something simple I
changed.

WIN95: Unauthenticated WIN95 EchoMail from 1:218/700 ignored

You need to either utilize a packet password or a secure mailer session. Apparently you're not utilizing a packet password for 1:218/700 and receiving bundles/packets in a non-secure mailer session.

Yeah, no packet password, never had one of those before, but we use a session password which starts a secure session, so shouldn't the packets just go to the secure folder?

Yes, they should.

You said we need one OR the other... or is it AND?

It's 'OR'.

digital man

Synchronet "Real Fact" #74:
Vertrauen went online (as a WWIV BBS running on a 10MHz PC-XT clone) in 1988. Norco, CA WX: 74.0oF, 29.0% humidity, 15 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.00-Win32
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Digital Man to Android8675 on Sat Apr 01 2017 04:49 pm

Yeah, no packet password, never had one of those before, but we use a
session password which starts a secure session, so shouldn't the
packets just go to the secure folder?

Yes, they should.

They are not. After receiving a bunch of bundles from my uplink, sbbsecho processes the files and they end up as .bad files in the unsecure inbound folder.

If I rename the .bad files back to .pkt, move them to the inboundsecure folder, and run sbbsecho then they are tossed correctly.

So for whatever reason binkit seems to be saving the files in the unsecure inbound folder even though I'm pretty sure they should be going into the secure folder.

Here's a debug log from binkit showing encrypted conn and files moving to _in instead of _insec

4/2 07:10:51a Callout to 1:218/700@fidonet started.
4/2 07:10:55a Sent M_NUL command args: OPT CRYPT
4/2 07:10:55a Sent M_NUL command args: SYS Shodan's Core
4/2 07:10:55a Sent M_NUL command args: ZYZ Android8675
4/2 07:10:55a Sent M_NUL command args: LOC Prunedale, CA
4/2 07:10:55a Sent M_NUL command args: NDL 115200,TCP,BINKP
4/2 07:10:55a Sent M_NUL command args: TIME Sun Apr 02 2017 07:10:55 GMT-0700 (Pacific Daylight Time)
4/2 07:10:55a Sent M_NUL command args: VER BinkIT/1.44,JSBinkP/1.69/Win32 binkp/1.1
4/2 07:10:55a Sent M_ADR command args: 1:218/600@fidonet 46:1/121@agoranet 201:1000/10@dbnet 618:300/26@micronet
4/2 07:10:56a Got M_NUL command args: OPT CRAM-MD5-9fd55ead4a6db2248cfb3778bfd9719e
4/2 07:10:56a Got M_NUL command args: OPT PLZ CRYPT
4/2 07:10:56a Will encrypt session.
4/2 07:10:56a Got M_NUL command args: SYS realitycheckBBS
4/2 07:10:56a Got M_NUL command args: ZYZ Kurt Weiske
4/2 07:10:56a Got M_NUL command args: LOC Santa Cruz County, CA USA
4/2 07:10:56a Got M_NUL command args: PHN realitycheckbbs.org
4/2 07:10:56a Got M_NUL command args: NDL CM,TCP,BND
4/2 07:10:56a Got M_NUL command args: TIME Sun, 02 Apr 2017 07:10:54 -0700
4/2 07:10:56a Got M_NUL command args: VER Radius/4.010/21.01.2005,13:56(Final-Release)/Win32 binkp/1.1
4/2 07:10:56a Got M_ADR command args: 618:300/1@micronet 46:1/115@agoranet 9:91/4@survnet 1:218/700@fidonet 1:10/1@fidonet 1:10/0@fidonet 1:102/0@fidonet 1:143/0@fidonet 1:143/1@fidonet 1:218/0@fidonet 1:218/1@fidonet 618:300/16@micronet
4/2 07:10:56a Sent M_PWD command args: CRAM-MD5-252c4cf49c14ac8537fee9e569179e80
4/2 07:10:56a Got M_OK command args:
4/2 07:10:56a Unconfigured address 46:1/115@agoranet
4/2 07:10:56a Unconfigured address 9:91/4@survnet
4/2 07:10:56a Unconfigured address 1:10/1@fidonet
4/2 07:10:56a Unconfigured address 1:10/0@fidonet
4/2 07:10:56a Unconfigured address 1:102/0@fidonet
4/2 07:10:56a Unconfigured address 1:143/0@fidonet
4/2 07:10:56a Unconfigured address 1:143/1@fidonet
4/2 07:10:56a Unconfigured address 1:218/0@fidonet
4/2 07:10:56a Unconfigured address 1:218/1@fidonet
4/2 07:10:56a Unconfigured address 618:300/16@micronet
4/2 07:10:56a Adding outbound files for 618:300/1@micronet
4/2 07:10:56a Adding outbound files for 1:218/700@fidonet
4/2 07:10:56a Adding 'C:\Fido\_OUT\00da02bc.dut' as '2sjl1ozb.pkt'
4/2 07:10:56a Initializing crypt keys.
4/2 07:10:56a Sent M_FILE command args: 2sjl1ozb.pkt 905 1491142172 0
4/2 07:10:56a Sending 905 bytes of data
4/2 07:10:56a Sent M_EOB command args:
4/2 07:10:57a Got M_NUL command args: TRF 0 2002167
4/2 07:10:58a Got M_FILE command args: 00000064.SA0 1256 1491088350 0
4/2 07:10:58a Got data frame length 512
4/2 07:10:58a Got M_GOT command args: 2sjl1ozb.pkt 905 1491142172
4/2 07:10:58a Got data frame length 744
4/2 07:10:58a Moving 'C:\SBBS\temp\event\00000064.SA0' to 'c:\fido\_IN\00000064.SA0'.
4/2 07:10:58a Sent M_GOT command args: 00000064.SA0 1256 1491088350
4/2 07:10:59a Got data frame length 0
4/2 07:10:59a Data packet outside of file!
4/2 07:10:59a Got M_FILE command args: 00000064.SU0 132093 1491116425 0 (stiped got data 1024 lines)
4/2 07:11:02a Moving 'C:\SBBS\temp\event\00000064.SU0' to 'c:\fido\_IN\00000064.SU0'.
4/2 07:11:02a Sent M_GOT command args: 00000064.SU0 132093 1491116425

---
* Synchronet * Shodan's Core @ ShodansCore.com (Port 2323 for Nethack)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

On 4/1/2017 6:48 PM, Digital Man -> Nicholas Boel wrote:

Let me clarify: with SBBSecho v2, if the local link/node was not

configured

with a packet password, then the incoming packet passwords were ignored (for that node). Otherwise (a password was configured), then the packet password had to match (was not ignored).

Yes. This is/was and has been understood.

Now, with SBBSecho v3, the packet password always has to match the local configuration. If there's no local link/node configuration or the configured password is blank, then the packet password must also be

blank.

Once we found out that sbbsecho v2 had ignored incoming packet passwords if it was on configured on the sbbsecho end.. and sbbsecho v3 was released for us to use, it was realized that D'Bridge, when configured with a SESSION password, would automatically use that session password as a packet password as well, without any further configuration (obviously not the proper thing to do, but it

apparantly has always done it - and wasn't even realized until it was pointed out). sbbsecho v3 was marking these packets as bad, until a packet password was

configured on the sbbsecho v3 end.

It is of NO fault of sbbsecho v3. Just an extra configuration step to work around an oddity with D'Bridge links.

--
Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45
# Origin: thePharcyde_ distribution system (723:1/1)
* Synchronet * thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

On 4/2/2017 9:26 AM, Android8675 -> Digital Man wrote:

They are not. After receiving a bunch of bundles from my uplink, sbbsecho processes the files and they end up as .bad files in the unsecure inbound folder.

If I rename the .bad files back to .pkt, move them to the inboundsecure folder,
and run sbbsecho then they are tossed correctly.

So for whatever reason binkit seems to be saving the files in the unsecure inbound folder even though I'm pretty sure they should be going into the secure
folder.

Here's a debug log from binkit showing encrypted conn and files moving
to _in
instead of _insec

I would check sbbsecho.ini since that's where binkIT pulls the information from. What do you have for "SecureInbound" and "Inbound"?

I think you also have to make sure ftn_domains.ini lists all of your networks (which with your log snippet it seems you have this done already) and that those domains in ftn_domains.ini match what you have in binkit.ini.

Also, does this happen for both incoming connections as well as outgoing polls?

Or do you only do it one way?

--
Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45
# Origin: thePharcyde_ distribution system (723:1/1)
* Synchronet * thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Android8675 to Digital Man on Sun Apr 02 2017 07:26 am

Re: SBBSEcho v3.daily Unauthenticated?
By: Digital Man to Android8675 on Sat Apr 01 2017 04:49 pm

Yeah, no packet password, never had one of those before, but we use a
session password which starts a secure session, so shouldn't the
packets just go to the secure folder?

Yes, they should.

They are not.

Then there is something wrong with your mailer (or its configuration), not SBBSecho.

So for whatever reason binkit seems to be saving the files in the unsecure inbound folder even though I'm pretty sure they should be going into the secure folder.

Here's a debug log from binkit showing encrypted conn and files moving to _in instead of _insec

Did you double check your configuration? I did not write binkit and I haven't run it (yet), so I'm not really in a position to say "I know it works", but it apparently is working as expected for others.

digital man

Synchronet/BBS Terminology Definition #29:
IP = Internet Protocol
Norco, CA WX: 76.0oF, 29.0% humidity, 13 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.00-Win32
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Nicholas Boel to Digital Man on Sun Apr 02 2017 08:25:54

It is of NO fault of sbbsecho v3. Just an extra configuration step to work around an oddity with D'Bridge links.

If I remember correctly, then Mystic also did the same thing. Messages comming from Mystic were also bounced here.


Joe
--- SBBSecho 3.00-Win32
* Origin: The Lions Den BBS, Trenton, On, CDN (1:249/303)

Re: SBBSEcho v3.daily Unauthenticated?
By: Nicholas Boel to Android8675 on Sun Apr 02 2017 02:48 pm

So for whatever reason binkit seems to be saving the files in the
unsecure inbound folder even though I'm pretty sure they should be
going into the secure
folder.

I would check sbbsecho.ini since that's where binkIT pulls the information from. What do you have for "SecureInbound" and "Inbound"?

.ini file Directories:
areafile = c:\sbbs\data\areas.bbs
logfile = c:\fido\_log\sbbsecho.log
inbound = c:\fido\_IN\
secureinbound = c:\fido\_inSEC\
outbound = C:\Fido\_OUT\
TempDirectory = c:\sbbs\temp\sbbsecho\

I think you also have to make sure ftn_domains.ini lists all of your networks (which with your log snippet it seems you have this done already) and that those domains in ftn_domains.ini match what you have in binkit.ini.

ftn_domains.ini:
[fidonet]
Zones=1,2,3,4,5,6
DNSSuffix=binkp.net
OutboundRoot=C:\Fido\_OUT\
NodeList=C:\Fido\nodelist\nodelist.338

[micronet]
Zones=618
OutboundRoot=C:\Fido\_OUT\
NodeList=C:\Fido\nodelist\micronet.267

[agoranet]
Zones=46
OutboundRoot=C:\Fido\_OUT\
NodeList=C:\Fido\nodelist\agoranet.337

[dbnet]
Zones=201
OutboundRoot=C:\Fido\_OUT\
NodeList=C:\Fido\nodelist\DBNETLST.015

Also, does this happen for both incoming connections as well as outgoing polls? Or do you only do it one way?

Incomming only. Keep in mind this setup was working for a brief time, but something changed. I'm talking with Kurt, he doesn't seem to be around this weekend, but I'm gonna have him set a packet password and see if that makes a difference, the only issue is the packets are ending up in unsecure, even though I'm connecting with a session password to my uplink.

TIC files aren't getting moved because they DO have a password, and since the packet password for my uplink is blank (True), then tickit doesn't toss the .tic files because they DO have a password.

I don't know, it seems wrong, but if adding a password to the packet fixes the problem I'm gonna run with that. In the meantime I'm just moving anything that lands in Inbound to SecureInbound, then running SBBSECHO.

I'm not bothering testing outbound, but I've sent netmail and that goes through just fine, No reason echomail packets wouldn't get through OK.

---
* Synchronet * Shodan's Core @ ShodansCore.com (Port 2323 for Nethack)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Android8675 to Digital Man on Sun Apr 02 2017 07:26 am

Then there is something wrong with your mailer (or its configuration), not SBBSecho.

Did you double check your configuration? I did not write binkit and I haven't run it (yet), so I'm not really in a position to say "I know it works", but it apparently is working as expected for others.

Yeah, double-checked. I don't know why packets are getting dropped in non-secure. everything seemed ok early on, and now it's having this issue. I could cheat and just set the inbound and secureinbound to the same folder (I think someone mentioned doing that), but that sounds like it could circumvent security in some way.

I don't think sbbsecho v3 is the problem. Binkit may not be the problem either. Once I get a hold of my uplink, if I can assign a packet password I think the problem will go away.

So lets drop this for now, I'll start a new thread if changing the packet pw doesn't help.

-A.

---
* Synchronet * Shodan's Core @ ShodansCore.com (Port 2323 for Nethack)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

On 4/2/2017 6:40 PM, Joe Delahaye -> Nicholas Boel wrote:

If I remember correctly, then Mystic also did the same thing. Messages comming from Mystic were also bounced here.

I'm not exactly sure what you mean by "bounced". But Mystic has different issues (ie: sending dupes by zeroing out seconds in the timestamp, and I'm sure

there are others by now), but I don't believe any of them has to do with a packet password being added.

--
Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45
# Origin: thePharcyde_ distribution system (723:1/1)
* Synchronet * thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

On 4/2/2017 6:23 PM, Android8675 -> Nicholas Boel wrote:

Also, does this happen for both incoming connections as well as
outgoing polls? Or do you only do it one way?

Incomming only. Keep in mind this setup was working for a brief time, but something changed. I'm talking with Kurt, he doesn't seem to be around this weekend, but I'm gonna have him set a packet password and see if that
makes a difference, the only issue is the packets are ending up in unsecure, even though I'm connecting with a session password to my uplink.

It's possible Kurt changed up something, but since he's using Radius, and not D'Bridge, what I was referring to is probably not the case here.

Maybe it's possible he has always had a packet password setup for you, but switching to sbbsecho v3 is now seeing that and stopping it.

I would imagine if he did originally set you up with a packet password, it would be the same as your other passwords. If he's gone for the week, you could

always give that a try.

That fails, you'll probably have to wait till he comes back and can look at his

settings.

TIC files aren't getting moved because they DO have a password, and
since the packet password for my uplink is blank (True), then tickit doesn't toss the .tic files because they DO have a password.

As I said above, try adding a packet password (using what you used to use as your tic password). It's possible one, or both of you have upgraded to sbbsecho

v3 recently. So when you send tics, you have to use a packet password (this was

Deuce's choice, and I argued it because of this very reason).

I don't know, it seems wrong, but if adding a password to the packet
fixes the problem I'm gonna run with that. In the meantime I'm just
moving anything that lands in Inbound to SecureInbound, then running SBBSECHO.

It's sounding more and more like this is indeed your issue. Deuce strongly argued that if you are going to use a TIC password, you should be using a packet password as well, so kept them as one in the same. My only real argument

was that it was going to mess up anyone's current configurations if they weren't using a packet password, but were using a tic password, once they upgraded.

Sorry it bit ya! ;)

--
Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45
# Origin: thePharcyde_ distribution system (723:1/1)
* Synchronet * thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Nicholas Boel to Android8675 on Mon Apr 03 2017 05:35 pm

Maybe it's possible he has always had a packet password setup for you, but switching to sbbsecho v3 is now seeing that and stopping it.

I would imagine if he did originally set you up with a packet password, it would be the same as your other passwords. If he's gone for the week, you could always give that a try.

I used pktdump.exe on the .bad packets, they have no password. My .TIC files have a password (in plain text). It's kind of a bummer because Tickit and SBBSECHO both use the same packet password field, so if the packet password isn't the same on both, then one or the other won't toss (unless I specify a different .cfg file for one or the other. (but I'm lazy)


---
* Synchronet * Shodan's Core @ ShodansCore.com (Port 2323 for Nethack)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

On 4/3/2017 9:07 PM, Android8675 -> Nicholas Boel wrote:

I used pktdump.exe on the .bad packets, they have no password. My .TIC files have a password (in plain text). It's kind of a bummer because
Tickit and SBBSECHO both use the same packet password field, so if the packet password isn't the same on both, then one or the other won't
toss (unless I specify a different .cfg file for one or the other.
(but I'm lazy)

If Kurt is using Radius, I'm assuming he's probably using a third party program

for your .tic files as well (Allfix, probably). This would be the only way to create TIC passwords without a packet password when the new sbbsecho comes into

play.

So I would assume if Kurt added a packet password matching your TIC password, things would start working normally again for echomail.

However, with this all said.. you *SHOULD* be seeing an error about the matter in sbbsecho.log if it were the case. If there is nothing regarding a packet password error in sbbsecho.log, then this is not the issue, and it would be something to do with your mailer connection (which a packet password has absolutely nothing to do with).

--
Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45
# Origin: thePharcyde_ distribution system (723:1/1)
* Synchronet * thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Nicholas Boel to Android8675 on Tue Apr 04 2017 07:21 am

OK, let me try to approach this in a different way...

What's happening:

Kurt's system calls me and BinkIT/P Connects!
BinkP establishes a secure, encrypted session!
Kurt's system sends my system 1 or more compressed .pkt files

(Where I suspect is the error) BinkIT saves the files to non-secure inbound< SBBSEcho runs

Compressed .pkt files are found in non-secure folder, are extracted.
.pkt files are analyzed, found to have no password.
.pkt files renamed to .bad because they are in non-secure AND have no packet pw

Now, if I rename the .bad files back to .pkt and MOVE them to the secureinbound folder, then run SBBSECHO, the messages get tossed (into the message base)!

So to me it seems like one of these things:

1. BinkIT is saving the files in the wrong place. Assuming that an encrypted session is all you need for delivered packets to be placed into SecureInbound, then in this situation the files are being placed in the wrong location.

2. BinkIT takes the packet AND session password into account when determining if a packet/file should go into the SecureInbound folder, in which case I can just setup a packet password from my provider, and maybe suggest adding a note to the WIKI that BinkIT requires both passwords for files to be delivered securely.

3. ??? I'm overlooking something.

I'm working on #2, going to have Kurt set a packet password and see if that fixes anything. In the meantime, it's Fidonet. I'm not sweating it.

Nicholas, are you my Agoranet connection? I'd like to get that network reconnected. Should I just drop you another application?

Here's a SBBSECHO .log, it's working correctly, so I'm not worried.
04/03/17 00:00:01 Unpacking bundle: c:\fido\_IN\0000ffe7.SU0 (1.2KB)
04/03/17 00:00:01 Executing: 7z e -y -oc:\fido\_IN\ c:\fido\_IN\0000ffe7.SU0 04/03/17 00:00:01 Deleting c:\fido\_IN\0000ffe7.SU0 (from line 2114)
04/03/17 00:00:01 Importing c:\fido\_IN\58e1cb58.pkt (Type 2e, 6.2KB) from 618:300/1 to 618:300/26
04/03/17 00:00:01 Unauthenticated L618_SCR EchoMail from 618:300/1 ignored 04/03/17 00:00:01 Unauthenticated L618_SCR EchoMail from 618:300/1 ignored 04/03/17 00:00:01 Unauthenticated L618_SCR EchoMail from 618:300/1 ignored 04/03/17 00:00:01 Unauthenticated L618_SCR EchoMail from 618:300/1 ignored 04/03/17 00:00:01 Unauthenticated L618_SCR EchoMail from 618:300/1 ignored 04/03/17 00:00:01 Unauthenticated L618_SCR EchoMail from 618:300/1 ignored 04/03/17 00:00:01 Unauthenticated L618_SCR EchoMail from 618:300/1 ignored 04/03/17 00:00:01 Bad packet detected: c:\fido\_IN\58e1cb58.pkt

---
* Synchronet * Shodan's Core @ ShodansCore.com (Port 2323 for Nethack)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Android8675 to Nicholas Boel on Tue Apr 04 2017 10:45 am

(Where I suspect is the error) BinkIT saves the files to non-secure

inbound

What version of binkit.js are you running?

Assuming you're running rev 1.44 (the latest), the following is the code in question (in binkit.js):

if (bp.authenticated === 'secure') {
if (secure_inbound === undefined)
log(LOG_ERROR, "No secure inbound configured in sbbsecho! Leaving secure file as '"+fname+"'.");
else {
log(LOG_INFO, "Moving '"+fname+"' to '"+secure_inbound+file_getname(fname)+"'.");
if (!rename_or_move(fname, secure_inbound+file_getname(fname)))
return false;
}
}

This "bp.authenticatd" is set by exec/load/binkp.js, so make sure you're using the latest version of that file too.

Anyway, you could add some more log() commands here to see if bp.authenticated is indeed 'secure', like you think it should be. Something like this:
log(LOG_DEBUG, "BinkP auth = " + bp.authenticated);
... just before that first if (bp.authenticated) part.
Then in your log output (next time you run binkit and get a connection and bundles), you should see that "BinkP auth = " and the value - is it secure or non-secure?


digital man

Synchronet/BBS Terminology Definition #20:
FDSZ = FOSSIL DSZ (by Chuck Forsberg)
Norco, CA WX: 77.0oF, 34.0% humidity, 7 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.00-Win32
* Origin: Vertrauen - vert.synchro.net (1:103/705)

On 4/2/2017 6:23 PM, Android8675 -> Nicholas Boel wrote:

It's possible Kurt changed up something, but since he's using Radius, and not D'Bridge, what I was referring to is probably not the case here.

Maybe it's possible he has always had a packet password setup for you, but switching to sbbsecho v3 is now seeing that and stopping it.

I would imagine if he did originally set you up with a packet password, it would be the same as your other passwords. If he's gone for the week, you could
always give that a try.

That fails, you'll probably have to wait till he comes back and can look at his
settings.

As I said above, try adding a packet password (using what you used to use as your tic password). It's possible one, or both of you have upgraded to sbbsecho
v3 recently. So when you send tics, you have to use a packet password (this was
Deuce's choice, and I argued it because of this very reason).

It's sounding more and more like this is indeed your issue. Deuce strongly argued that if you are going to use a TIC password, you should be using a packet password as well, so kept them as one in the same. My only real argument
was that it was going to mess up anyone's current configurations if they weren't using a packet password, but were using a tic password, once they upgraded.

Sorry it bit ya! ;)

That's exactly it, disregard my last message.

---
* Synchronet * Shodan's Core @ ShodansCore.com (Port 2323 for Nethack)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Digital Man to Android8675 on Tue Apr 04 2017 01:59 pm

Assuming you're running rev 1.44 (the latest), the following is the code in question (in binkit.js):

1.45 was just pushed, using that, but I was on 1.44 earlier today.

This "bp.authenticatd" is set by exec/load/binkp.js, so make sure you're using the latest version of that file too.

yep...

Anyway, you could add some more log() commands here to see if bp.authenticated is indeed 'secure', like you think it should be. Something like this:
log(LOG_DEBUG, "BinkP auth = " + bp.authenticated);

OK, so tried this, and the line is reporting " = <blank>" or nothing, which I assume means it's NOT secure.

The message pops up after receiving a packet and just before it determines where to place it I assume.

4/5 12:12:20p Callout to 1:218/700@fidonet started.
4/5 12:12:27p Sent M_NUL command args: OPT CRYPT
4/5 12:12:27p Sent M_NUL command args: SYS Shodan's Core
4/5 12:12:27p Sent M_NUL command args: ZYZ Android8675
4/5 12:12:27p Sent M_NUL command args: LOC Prunedale, CA
4/5 12:12:27p Sent M_NUL command args: NDL 115200,TCP,BINKP
4/5 12:12:27p Sent M_NUL command args: TIME Wed Apr 05 2017 12:12:27 GMT-0700 (Pacific Daylight Time)
4/5 12:12:27p Sent M_NUL command args: VER BinkIT/1.45,JSBinkP/1.70/Win32 binkp/1.1
4/5 12:12:27p Sent M_ADR command args: 1:218/600@fidonet 46:1/121@agoranet 201:1000/10@dbnet 618:300/26@micronet
4/5 12:12:27p Got M_NUL command args: OPT CRAM-MD5-e7ddd594f2cda8a030df1fb50447d01b
4/5 12:12:27p Got M_NUL command args: OPT PLZ CRYPT
4/5 12:12:27p Will encrypt session.
4/5 12:12:27p Got M_NUL command args: SYS realitycheckBBS
4/5 12:12:27p Got M_NUL command args: ZYZ Kurt Weiske
4/5 12:12:27p Got M_NUL command args: LOC Santa Cruz County, CA USA
4/5 12:12:27p Got M_NUL command args: PHN realitycheckbbs.org
4/5 12:12:27p Got M_NUL command args: NDL CM,TCP,BND
4/5 12:12:27p Got M_NUL command args: TIME Wed, 05 Apr 2017 12:12:30 -0700
4/5 12:12:27p Got M_NUL command args: VER Radius/4.010/21.01.2005,13:56(Final-Release)/Win32 binkp/1.1
4/5 12:12:27p Got M_ADR command args: 618:300/1@micronet 46:1/115@agoranet 9:91/4@survnet 1:218/700@fidonet 1:10/1@fidonet 1:10/0@fidonet 1:102/0@fidonet 1:143/0@fidonet 1:143/1@fidonet 1:218/0@fidonet 1:218/1@fidonet 618:300/16@micronet
4/5 12:12:27p Sent M_PWD command args: CRAM-MD5-6f75b5c7e7f552e7bdd37412a2afdae0
4/5 12:12:27p Got M_OK command args:
4/5 12:12:27p Unconfigured address 46:1/115@agoranet
4/5 12:12:27p Unconfigured address 9:91/4@survnet
4/5 12:12:27p Unconfigured address 1:10/1@fidonet
4/5 12:12:27p Unconfigured address 1:10/0@fidonet
4/5 12:12:27p Unconfigured address 1:102/0@fidonet
4/5 12:12:27p Unconfigured address 1:143/0@fidonet
4/5 12:12:27p Unconfigured address 1:143/1@fidonet
4/5 12:12:27p Unconfigured address 1:218/0@fidonet
4/5 12:12:27p Unconfigured address 1:218/1@fidonet
4/5 12:12:27p Unconfigured address 618:300/16@micronet
4/5 12:12:27p Adding outbound files for 618:300/1@micronet
4/5 12:12:27p Adding outbound files for 1:218/700@fidonet
4/5 12:12:27p Initializing crypt keys.
4/5 12:12:27p Sent M_EOB command args:
4/5 12:12:28p Got M_NUL command args: TRF 0 95717
4/5 12:12:28p Got M_FILE command args: 00000064.WE0 82169 1491419130 0
4/5 12:12:28p Got data frame length 512
4/5 12:12:28p Got data frame length 1024
...
4/5 12:12:31p Got data frame length 761
@0E@ 4/5 12:12:31p **** BinkP auth =@07@
4/5 12:12:31p Moving 'C:\SBBS\temp\event\00000064.WE0' to 'c:\fido\_IN\00000064.WE0'.
4/5 12:12:31p Sent M_GOT command args: 00000064.WE0 82169 1491419130
4/5 12:12:31p Got data frame length 0
4/5 12:12:31p Data packet outside of file!
4/5 12:12:31p Got M_FILE command args: 00000064.WE0 3137 1491419276 0


... BEWARE - Tagline Thief is in the area...

---
* Synchronet * Shodan's Core @ ShodansCore.com (Port 2323 for Nethack)
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Android8675 to Digital Man on Wed Apr 05 2017 01:10 pm

Re: SBBSEcho v3.daily Unauthenticated?
By: Digital Man to Android8675 on Tue Apr 04 2017 01:59 pm

Assuming you're running rev 1.44 (the latest), the following is the code in question (in binkit.js):

1.45 was just pushed, using that, but I was on 1.44 earlier today.

Yeah, I just added the $Id tags to make it easier to know what rev you have.

This "bp.authenticatd" is set by exec/load/binkp.js, so make sure you're using the latest version of that file too.

yep...

Anyway, you could add some more log() commands here to see if bp.authenticated is indeed 'secure', like you think it should be. Something like this:
log(LOG_DEBUG, "BinkP auth = " + bp.authenticated);

OK, so tried this, and the line is reporting " = <blank>" or nothing, which I assume means it's NOT secure.

The message pops up after receiving a packet and just before it determines where to place it I assume.

4/5 12:12:31p **** BinkP auth =

That is really odd. Looking at binkp.js, the 'authenticated' property should be either 'secure' or 'non-secure'. If we could get Deuce in here (that's his code), he could likely point out why and fix it easily if it's an issue in binkp.js (or binkit.js). *** hailing Deuce ***


digital man

Synchronet "Real Fact" #86:
Stephen and Rob have a fledgling podcast at http://techdorks.net (also iTunes). Norco, CA WX: 63.8oF, 51.0% humidity, 0 mph W wind, 0.00 inches rain/24hrs
--- SBBSecho 3.00-Win32
* Origin: Vertrauen - vert.synchro.net (1:103/705)

Re: SBBSEcho v3.daily Unauthenticated?
By: Digital Man to Android8675 on Thu Apr 06 2017 01:40 am

Re: SBBSEcho v3.daily Unauthenticated?
By: Android8675 to Digital Man on Wed Apr 05 2017 01:10 pm

Assuming you're running rev 1.44 (the latest), the following is
the code in question (in binkit.js):

1.45 was just pushed, using that, but I was on 1.44 earlier today.

Yeah, I just added the $Id tags to make it easier to know what rev you have.

This "bp.authenticatd" is set by exec/load/binkp.js, so make sure
you're using the latest version of that file too.

yep...

Anyway, you
could add some
more log()
commands here
to see if

OK, so tried this, and the line is reporting " = <blank>>bp.authenticat
OK, so tried this, and the line is reporting " = <blank>>ed is indeed
OK, so tried this, and the line is reporting " = <blank>>'secure', like
OK, so tried this, and the line is reporting " = <blank>>you think it
OK, so tried this, and the line is reporting " = <blank>>should be.
OK, so tried this, and the line is reporting " = <blank>>Something like
OK, so tried this, and the line is reporting " = <blank>>this:
OK, so tried this, and the line is reporting " = <blank>>log(LOG_DEBUG,
OK, so tried this, and the line is reporting " = <blank>>"BinkP auth =
OK, so tried this, and the line is reporting " = <blank>>" +
OK, so tried this, and the line is reporting " = <blank>>bp.authenticat
OK, so tried this, and the line is reporting " = <blank>>ed); " or
OK, so tried this, and the line is reporting " = <blank>>nothing, which

I assume means it's NOT secure.

The message pops up after receiving a packet and just before it
determines where to place it I assume.

4/5 12:12:31p **** BinkP auth =

That is really odd. Looking at binkp.js, the 'authenticated' property should be either 'secure' or 'non-secure'. If we could get Deuce in here (that's his code), he could likely point out why and fix it easily if it's an issue in binkp.js (or binkit.js). *** hailing Deuce ***

Deuce, gonna look at this today, see if it's still mucking about. I don't know if you commented on this yet.

Thanks much,
-An.


... Waiter, this chicken's rubbery! Oh, fank you velly much! More fly lice?

---
* Synchronet * Shodan's Core @ ShodansCore.com (Port 2323 for Nethack)
* Origin: Vertrauen - vert.synchro.net (1:103/705)