The new sbbsecho is now rejecting messages as "unauthenticated" for areas
that exist in my AREAS.BBS file.

What does that mean?

Thanks.

---
þ SLMR 2.1a þ "You've stolen my soul!" - Granpa Simpson
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

It is also treating good packets as bad:

Packet /sbbs/fido/in/04163003.PKT from 454:1/1 - Incorrect password ('password' instead of '')
Bad packet detected: /sbbs/fido/in/04163003.PKT

[node:454:1/1]
Comment =
PacketPwd =
AreafixPwd = password
Notify = false
Passive = false
Direct = false
Status = normal
Archive = ZIP
Keys =

As you can see, I have no packetpwd set and never have for this node. Unless I am reading that error message backwards, sbbsecho seems to be attempting to use the areafixpwd as a packet password and is complaining when it does not match.

The new sbbsecho is now rejecting messages as "unauthenticated" for areas that exist in my AREAS.BBS file.

What does that mean?

Thanks.

---
þ SLMR 2.1a þ "You've stolen my soul!" - Granpa Simpson

---
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

Re: Unauthenticated echos
By: Dumas Walker to ALL on Sat Nov 04 2017 07:15 pm

The new sbbsecho is now rejecting messages as "unauthenticated" for areas that exist in my AREAS.BBS file.

What does that mean?

It means the node which is sending you those messages is not configured in your echocfg->Linked Nodes.

This is nothing new.

digital man

This Is Spinal Tap quote #8:
Derek Smalls: Making a big thing out of it would have been a good idea.
Norco, CA WX: 56.8øF, 86.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: bad packet passwords
By: Dumas Walker to All on Sat Nov 04 2017 07:38 pm

It is also treating good packets as bad:

Packet /sbbs/fido/in/04163003.PKT from 454:1/1 - Incorrect password ('password' instead of '')
Bad packet detected: /sbbs/fido/in/04163003.PKT

[node:454:1/1]
Comment =
PacketPwd =
AreafixPwd = password
Notify = false
Passive = false
Direct = false
Status = normal
Archive = ZIP
Keys =

As you can see, I have no packetpwd set and never have for this node.
Unless I am reading that error message backwards, sbbsecho seems to be attempting to use the areafixpwd as a packet password and is complaining when it does not match.

No. SBBSecho is telling you that the packet contains a password (the word "password") while the node is configured for *no* password.

digital man

Synchronet/BBS Terminology Definition #43:
SCFG = Synchronet Configuration Utility
Norco, CA WX: 56.8øF, 86.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

It means the node which is sending you those messages is not configured in your
echocfg->Linked Nodes.

Ummm, but this time it is, and the slashes and colons are in the right
places:

[node:1:261/38]
Comment =
PacketPwd =
AreafixPwd = password
Notify = false
Passive = false
Direct = false
Status = normal
Archive = ZIP
Keys =


jsexec update.js only converted part of the cfg file, so I had to manually enter several nodes. This might have been one of them, but I do not see a
typo this time.

---
þ SLMR 2.1a þ "Television! Teacher, Mother, Secret Lover..." - Homer
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

No. SBBSecho is telling you that the packet contains a password (the word "password") while the node is configured for *no* password.

It has always been configured for no password. I just checked my old cfg
file and my older squish.cfg file... no passwords and, until the upgrade yesterday, no trouble.

---
þ SLMR 2.1a þ "Don't make me put a dog heart in there!" - Dr. Hibbert
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

On 2017 Nov 05 01:19:38, you wrote to Dumas Walker:

As you can see, I have no packetpwd set and never have for this node.
Unless I am reading that error message backwards, sbbsecho seems to be
attempting to use the areafixpwd as a packet password and is
complaining when it does not match.

No. SBBSecho is telling you that the packet contains a password (the
word "password") while the node is configured for *no* password.

maybe you could reword the log entry to be clearer??

Packet /sbbs/fido/in/04163003.PKT from 454:1/1 - Incorrect password (received 'password' instead of '')
Bad packet detected: /sbbs/fido/in/04163003.PKT

just adding that one word would help :)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Life is a first draft with no rewrite.
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

On 2017 Nov 05 09:42:00, you wrote to DIGITAL MAN:

No. SBBSecho is telling you that the packet contains a password (the word
"password") while the node is configured for *no* password.

It has always been configured for no password. I just checked my old cfg file and my older squish.cfg file... no passwords and, until the upgrade yesterday, no trouble.

the problem is that in the past sbbsecho ignore pkt password problems so no one
ever knew there was a problem in the first place... as long as the mail moved they didn't care that it was insecure... now sbbsecho is much more secure and alerts you to these packet password problems... if they have a password for your PKTs, you need to have one, too...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... And quite honestly, we are not going to tell you what's in our sausage.
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: Unauthenticated echos
By: Dumas Walker to DIGITAL MAN on Sun Nov 05 2017 09:40 am

It means the node which is sending you those messages is not configured in your
echocfg->Linked Nodes.

Ummm, but this time it is, and the slashes and colons are in the right places:

[node:1:261/38]
Comment =
PacketPwd =
AreafixPwd = password
Notify = false
Passive = false
Direct = false
Status = normal
Archive = ZIP
Keys =

Then please post the full log entries related the problem you are having.

jsexec update.js only converted part of the cfg file, so I had to manually enter several nodes. This might have been one of them, but I do not see a typo this time.

Please send me your sbbsecho.cfg.old file and I'll test the conversion myself and what happens.

digital man

This Is Spinal Tap quote #28:
We've got Armadillos in our trousers. It's really quite frightening.
Norco, CA WX: 68.7øF, 64.0% humidity, 5 mph ENE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: bad packet passwords
By: Dumas Walker to DIGITAL MAN on Sun Nov 05 2017 09:42 am

No. SBBSecho is telling you that the packet contains a password (the word "password") while the node is configured for *no* password.

It has always been configured for no password. I just checked my old cfg file and my older squish.cfg file... no passwords and, until the upgrade yesterday, no trouble.

So set StrictPacketPaswords = false in your sbbsecho.ini file if you want the older, less secure, behavior. This is covered here: http://wiki.synchro.net/util:sbbsecho#changes_in_version_3

digital man

Synchronet/BBS Terminology Definition #14:
DOCSIS = Data Over Cable Service Interface Specification
Norco, CA WX: 68.7øF, 64.0% humidity, 5 mph ENE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

the problem is that in the past sbbsecho ignore pkt password problems so no one
ever knew there was a problem in the first place... as long as the mail moved >they didn't care that it was insecure... now sbbsecho is much more secure and >alerts you to these packet password problems... if they have a password for >your PKTs, you need to have one, too...

Thanks. SQUISH also never bothered me about it, either, FWIW. I got it set now but have not got to test it yet.

---
þ SLMR 2.1a þ "Get out & take your Sacagawea dollars with you!" - Moe
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

So set StrictPacketPaswords = false in your sbbsecho.ini file if you want the >older, less secure, behavior. This is covered here: >http://wiki.synchro.net/util:sbbsecho#changes_in_version_3

Done. I shall test it out once my echomail is flowing again.

---
þ SLMR 2.1a þ Dental plan...Lisa needs braces...dental plan...Lisa...
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

Then please post the full log entries related the problem you are having.

As luck would have it :( my log entries only go back to 9/25? The log is massive, so I did a 'tail' on it to confirm this.

Thanks to an email from cron, I do have the output from sbbsecho:

Importing /sbbs/fido/in/31c9ff54.pkt (Type 2e, 5.5KB) from 1:261/38 to 1:2320/10
RBERRYPI: Unauthenticated RBERRYPI EchoMail from 1:261/38 ignored

RBERRYPI: Unauthenticated RBERRYPI EchoMail from 1:261/38 ignored

Bad packet detected: /sbbs/fido/in/31c9ff54.pkt
Importing /sbbs/fido/in/31ca4341.pkt (Type 2e, 3.9KB) from 1:261/38 to 1:2320/10
ASIAN_LINK: Unauthenticated ASIAN_LINK EchoMail from 1:261/38 ignored

ASIAN_LINK: Unauthenticated ASIAN_LINK EchoMail from 1:261/38 ignored

Bad packet detected: /sbbs/fido/in/31ca4341.pkt
Importing /sbbs/fido/in/31cacb34.pkt (Type 2e, 84.5KB) from 1:261/38 to 1:2320/1
COOKING: Unauthenticated COOKING EchoMail from 1:261/38 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:261/38 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:261/38 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:261/38 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:261/38 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:261/38 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:261/38 ignored

COOKING: Unauthenticated COOKING EchoMail from 1:261/38 ignored etc.

I will run it again to get a log entry. I have log level set to 7.

jsexec update.js only converted part of the cfg file, so I had to manually >> enter several nodes. This might have been one of them, but I do not see a >> typo this time.

Please send me your sbbsecho.cfg.old file and I'll test the conversion myself and what happens.

I shall send both the old file and the new ini, via email, shortly. Will
also send the log file. Am sending to digital.man@vert.synchro.net so I
hope that is the right address. I could not find one on synchro.net.

To answer a question in advance, there are three USEPACKER ZIP lines in the
cfg file because the echocfg program that came with 3.15 would mangle and/or remove nodes if I let a line get too long. Splitting it into multiple lines seemed to prevent this behavior. I thought maybe the conversion did not
like the multiple lines, but the nodes I had to add manually did not seem
to follow any pattern as far as what line they came from.

Thanks!

---
þ SLMR 2.1a þ "I'm cold, and there are wolves after me!"-Granpa Simpson
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * 1-502-875-8938

Re: Unauthenticated echos
By: Dumas Walker to DIGITAL MAN on Sun Nov 05 2017 06:21 pm

Then please post the full log entries related the problem you are having.

As luck would have it :( my log entries only go back to 9/25? The log is massive, so I did a 'tail' on it to confirm this.

Thanks to an email from cron, I do have the output from sbbsecho:

Importing /sbbs/fido/in/31c9ff54.pkt (Type 2e, 5.5KB) from 1:261/38 to 1:2320/10
RBERRYPI: Unauthenticated RBERRYPI EchoMail from 1:261/38 ignored

Your sbbs/fido/in directory is your non-secure inbound directory (as I saw from further up in the log file and in the sbbsecho.ini that you emailed me) and the packet has no password, so therefore the source cannot be authenticated. You need remedy one of these security issues (use secure sessions or password-protected packets, or both).

jsexec update.js only converted part of the cfg file, so I had to manually >> enter several nodes. This might have been one of them, but I do not see a >> typo this time.

Please send me your sbbsecho.cfg.old file and I'll test the conversion myself and what happens.

I shall send both the old file and the new ini, via email, shortly.

In looking at the sbbsecho.ini and the sbbsecho.cfg file you sent, I'm not seeing any missing nodes from the sbbsecho.ini. Which nodes did not get converted?

To answer a question in advance, there are three USEPACKER ZIP lines in the cfg file because the echocfg program that came with 3.15 would mangle and/or remove nodes if I let a line get too long. Splitting it into multiple lines seemed to prevent this behavior. I thought maybe the conversion did not like the multiple lines, but the nodes I had to add manually did not seem
to follow any pattern as far as what line they came from.

I think it should work fine with multiple USEPACKER lines.

digital man

This Is Spinal Tap quote #29:
I find lost luggage. I locate mandolin strings in the middle of Austin!
Norco, CA WX: 60.5øF, 77.0% humidity, 2 mph E wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Your sbbs/fido/in directory is your non-secure inbound directory (as I saw from
further up in the log file and in the sbbsecho.ini that you emailed me) and the
packet has no password, so therefore the source cannot be authenticated. You >need remedy one of these security issues (use secure sessions or >password-protected packets, or both).

Yeah, I do have secure connections but had the mailer pointed to /in. I
just moved all the /in/*.bad files to /inbound/*.pkt and ran sbbsecho. I
have echomail now. :) Have the mailer repointed, too. Thanks!

---
þ SLMR 2.1a þ If she won't live forever, why give a diamond?
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * 1-502-875-8938