Hi All,

I was wondering about packet passwords, are they case insensitive or not?

FMail has always forced them to uppercase on entry in the configuration, and does a case insensitive compare on the password contained in arrived packet files.

fts-0001.016 just says this about the password:

password (some impls)
eight bytes
null padded

"bytes": So it could be anything, including "high ascii".

When I look at the packets I receive, there are some with lower or even mixed case passwords.
(So it's a good thing FMail does a case insensitive compare, otherwise it wouldn't match against the configured uppercase password)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Wilfred,

On 21 Apr 20 13:58, you wrote to All:

"bytes": So it could be anything, including "high ascii".

When I look at the packets I receive, there are some with lower or
even mixed case passwords. (So it's a good thing FMail does a case insensitive compare, otherwise it wouldn't match against the
configured uppercase password)

This has been unsteady 'ground' for me. What is FMail doing when it's coding the forced uppercase, after having potential mixedcase entered in the setup?

Cheers,
Paul.

... Can I have what's behind curtain #2 instead?
--- GoldED+/LNX 1.1.5-b20130515
* Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)

Hi Paul,

On 2020-04-21 22:26:53, you wrote to me:

"bytes": So it could be anything, including "high ascii".

When I look at the packets I receive, there are some with lower or
even mixed case passwords. (So it's a good thing FMail does a case
insensitive compare, otherwise it wouldn't match against the
configured uppercase password)

This has been unsteady 'ground' for me. What is FMail doing when it's coding the forced uppercase, after having potential mixedcase entered in the setup?

You can't enter mixed or lowercase into the configuration program, only uppercase. And when someone updates the packet password through areafix it's converted to uppercase before storing in the configuration file. So on outgoing packet files the packet password is always uppercase only.

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

On 21 Apr 20 13:58:58, Wilfred Van Velzen said the following to All:

I was wondering about packet passwords, are they case insensitive or not?

Packet passwords are treated case sensitive by some tossers.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Hi Nick,

On 2020-04-21 10:19:55, you wrote to me:

I was wondering about packet passwords, are they case insensitive or
not?

Packet passwords are treated case sensitive by some tossers.

Do you know which ones?

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Wilfred,

I was wondering about packet passwords, are they case insensitive or
not?

In all my experience packet, areafix and filefix passwords have been case insensitive.

It has always been my hope that no one will write a tosser with case sensitive passwords!

Session passwords are case sensitive but I have never seen that with packet passwords.

Ttyl :-),
Al

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

Hi Alan,

On 2020-04-21 09:47:26, you wrote to me:

I was wondering about packet passwords, are they case insensitive or
not?

In all my experience packet, areafix and filefix passwords have been case insensitive.

Packet and areafix passwords are case insensitive in FMail. But according to Nick there are tossers that are not...

It has always been my hope that no one will write a tosser with case sensitive passwords!

What's the problem? You can always configure the case sensitive tosser with an all uppercase (or lowercase) password to communicate with a case insensitive tosser.

And that's what I'm trying to find out, if there could be a problem if I change FMails behaviour. I'm not seeing it, but I can't think of everything. ;)


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Re: Packet password case insensitive or not?
By: Alan Ianson to Wilfred van Velzen on Tue Apr 21 2020 09:47:26

I was wondering about packet passwords, are they case insensitive or
not?

In all my experience packet, areafix and filefix passwords have been
case insensitive.

this is because traditionally, all FTN software uppercased everything ;)


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

On 21 Apr 20 16:26:02, Wilfred Van Velzen said the following to Nick Andre:

Packet passwords are treated case sensitive by some tossers.

Do you know which ones?

Offhand... and I could be wrong... AdeptXBBS Gatekeeper, TBBS/Flame, Gecho 1.20/Pro... Possibly Viamail. I'm sure there are others. I had a downlink years ago who specifically needed a mixed-case password.

If two Sysops cannot troubleshoot packet-password problems then thats not a tosser problem. Just remove whatever uppercase-parse code in Fmail, be done.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Re: Packet password case insensitive or not?
By: Wilfred van Velzen to All on Tue Apr 21 2020 01:58 pm

Hi All,

I was wondering about packet passwords, are they case insensitive or not?

FMail has always forced them to uppercase on entry in the configuration,

and

does a case insensitive compare on the password contained in arrived packet files.

fts-0001.016 just says this about the password:

password (some impls)
eight bytes
null padded

"bytes": So it could be anything, including "high ascii".

When I look at the packets I receive, there are some with lower or even mixed case passwords.
(So it's a good thing FMail does a case insensitive compare, otherwise it wouldn't match against the configured uppercase password)

SBBSecho has always treated packet passwords case-INsensitively. It is unfortuate that so many of the fido specifications were so badly written to begin with and the resulting ambiguities and contradictions have never been sufficiently addressed by the FTSC. Luckily, with password-protected mail sessions the norm these days, packet passwords are kind of moot and probably should just be deprecated. Doubt that'll happen though.

digital man

Synchronet/BBS Terminology Definition #16:
CVS = Concurrent Versioning System
Norco, CA WX: 70.6øF, 55.0% humidity, 8 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hi! Wilfred,

On 21 Apr 20 14:36, you wrote to me:

You can't enter mixed or lowercase into the configuration program,
only uppercase. And when someone updates the packet password through areafix it's converted to uppercase before storing in the
configuration file. So on outgoing packet files the packet password is always uppercase only.

Oh the horror! There are people out there that I interface with that don't know that rule and insist on setting mixedcase. Evil people. Smelly people. Ugly people...

Cheers,
Paul.

... ///\oo/\\\ There are no more bugs. ///\oo/\\\ ///\oo/\\\
--- GoldED+/LNX 1.1.5-b20130515
* Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)

Hello Wilfred,

What's the problem? You can always configure the case sensitive tosser with an all uppercase (or lowercase) password to communicate with a
case insensitive tosser.

It's not a problem, a PITA maybe.

And that's what I'm trying to find out, if there could be a problem if
I change FMails behaviour. I'm not seeing it, but I can't think of everything. ;)

My tosser isn't case sensitive so it wouldn't be a problem for me. If a link needed special treatment I can do that as long as I know that is needed.

From what I have read today Internet Rex is case sensitive for packet passwords. I haven't run into that but something to keep in mind.

Ttyl :-),
Al

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

Hello mark,

In all my experience packet, areafix and filefix passwords have
been case insensitive.

this is because traditionally, all FTN software uppercased everything
;)

I read that Internet Rex is case sensitive with packet passwords.

I have always entered passwords in my own config in upper case.. maybe that's why I never saw any issues. I can enter the password in lower or mixed case if needed by a link but no one has ever asked me to do this.. so far.. ;)

Ttyl :-),
Al

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

Hello Nick!

Tuesday April 21 2020 15:50, Nick Andre wrote to Wilfred Van Velzen:

Packet passwords are treated case sensitive by some tossers.

Do you know which ones?

Offhand... and I could be wrong... AdeptXBBS Gatekeeper, TBBS/Flame,
Gecho 1.20/Pro...

GEcho is a funny thing, GSetup forces uppercase Areamgr password but accepts mixedcase pkt password.

i New entry ================================================== Node manager
|
| Node address
| SysOp name SysOp
| Route via
| Packet password Zz######
| +-Check password Auto
| AreaMgr password ················

'Tommi

--- GoldED+/EMX 1.1.5-b20180707
* Origin: ---------------------------------->> (2:221/360)

Hi Nick,

On 2020-04-21 15:50:37, you wrote to me:

Packet passwords are treated case sensitive by some tossers.

Do you know which ones?

Offhand... and I could be wrong... AdeptXBBS Gatekeeper, TBBS/Flame,

Gecho

1.20/Pro... Possibly Viamail. I'm sure there are others.

That's an obscure list. ;)

Never heard of the first two, are they still used?

I had a downlink years ago who specifically needed a mixed-case
password.

Was that a technical necessity? I can hardly imagine that.

If two Sysops cannot troubleshoot packet-password problems then thats
not a tosser problem.

Any combination of case (in)sensitive tossers should be able to communicate, I think. Unless a tosser sends out packet passwords in one case, and expects to receive it in the other case. But I would call that a bug. ;)

Just remove whatever uppercase-parse code in Fmail, be done.

I'm leaning in that direction...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Rob,

On 2020-04-21 16:12:07, you wrote to me:

SBBSecho has always treated packet passwords case-INsensitively. It is unfortuate that so many of the fido specifications were so badly
written to begin with and the resulting ambiguities and contradictions have never been sufficiently addressed by the FTSC.

There is no ambiguity for packet password case sensitivity. It's just not specified, so anything goes...

Luckily, with password-protected mail sessions the norm these days,
packet passwords are kind of moot and probably should just be
deprecated. Doubt that'll happen though.

I don't agree here. Packet passwords provide an extra layer of security. For instance without it, anyone can drop a .pkt file in your insecure inbound with a falsified source address and echomail in it. If you process .pkt files from your inbound automatically, it will get tossed, if there is no packet password agreeded upon for the falsified source...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Paul,

On 2020-04-22 12:22:58, you wrote to me:

You can't enter mixed or lowercase into the configuration program,
only uppercase. And when someone updates the packet password through
areafix it's converted to uppercase before storing in the
configuration file. So on outgoing packet files the packet password is
always uppercase only.

Oh the horror! There are people out there that I interface with that

don't

know that rule and insist on setting mixedcase. Evil people. Smelly people. Ugly people...

On FMails side that's not a problem because it checks the passwords case insensitive.

How they deal with it on their side is their problem. ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Alan,

On 2020-04-21 21:13:54, you wrote to me:

What's the problem? You can always configure the case sensitive
tosser with an all uppercase (or lowercase) password to communicate
with a case insensitive tosser.

It's not a problem, a PITA maybe.

Why a PITA? You have to configure it once. Check that it works and be done with it...

And that's what I'm trying to find out, if there could be a problem
if I change FMails behaviour. I'm not seeing it, but I can't think of
everything. ;)

My tosser isn't case sensitive so it wouldn't be a problem for me. If a link needed special treatment I can do that as long as I know that is needed.

Indeed.

From what I have read today Internet Rex is case sensitive for packet passwords. I haven't run into that but something to keep in mind.

Indeed.

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

21 Apr 20 20:39, you wrote to Alan Ianson:

I was wondering about packet passwords, are they case
insensitive or not?

In all my experience packet, areafix and filefix passwords have
been case insensitive.

I remember that we always used uppercase packet passwords. I assumed that passwords are case insensitive, but I think I never tried to use lowercase in the config.

Packet and areafix passwords are case insensitive in FMail. But
according to Nick there are tossers that are not...

Crashmail and Squish use stricmp() for the packet passwords -> case insensitive.

How does stricmp compare strings with high ascii characters?

It has always been my hope that no one will write a tosser with
case sensitive passwords!

What's the problem? You can always configure the case sensitive tosser with an all uppercase (or lowercase) password to communicate with a
case insensitive tosser.

Right, uppercase passwords should work with every tosser.

And that's what I'm trying to find out, if there could be a problem if
I change FMails behaviour. I'm not seeing it, but I can't think of everything. ;)

I would say in theory there should be less problems, if FMail were able to send mixed case passwords.

Maybe we should use hex notation for the passwords, so all 255 characters can be used for better security ;).


* Origin: kakistocracy (2:280/464.47)

Hi Oli,

On 2020-04-22 10:14:54, you wrote to me:

I remember that we always used uppercase packet passwords. I assumed
that passwords are case insensitive, but I think I never tried to use lowercase in the config.

There seems to be different kind of implementations in different tossers...

Packet and areafix passwords are case insensitive in FMail. But
according to Nick there are tossers that are not...

Crashmail and Squish use stricmp() for the packet passwords -> case insensitive.

FMail currently is too.

How does stricmp compare strings with high ascii characters?

On linux that depends on the locale that's set on the computer. So you can get different results on different computers.

So another good reason to use case sensitive passwords.

And that's what I'm trying to find out, if there could be a problem
if I change FMails behaviour. I'm not seeing it, but I can't think of
everything. ;)

I would say in theory there should be less problems, if FMail were able

to

send mixed case passwords.

It becomes more flexible what you can use. But maybe needs a bit more tweaking to get it right when talking to a case insensitive tosser.

Maybe we should use hex notation for the passwords, so all 255
characters can be used for better security ;).

FTS-0001 Doesn't rule that out. (It just says 8 bytes for the packet password). ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

I was wondering about packet passwords, are they case insensitive or

not?

When I look at the packets I receive, there are some with lower or even

mixed case passwords.

Crashmail sends the (mixed-case) password string exactly as configured, no conversion to uppercase.

* Origin: (2:280/464.47)

Hello Wilfred,

Why a PITA?

I've had issues with session passwords because folks has told me to use a password (lower case) but they enter it in their setup in upper case. That's a PITA.

You have to configure it once. Check that it works and be done with
it...

As long as folks understand the need for this at setup it should pose no problems.

Ttyl :-),
Al

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

Hello Oli!

Wednesday April 22 2020 10:44, Oli wrote to Wilfred van Velzen:

When I look at the packets I receive, there are some with lower or even
mixed case passwords.

Crashmail sends the (mixed-case) password string exactly as configured,

no

conversion to uppercase.

GEcho does the same.

=== Begin OS/2 Clipboard ===

Pkt-Name: 63C3463A.PKT
OrigAddr: 2:221/360.0
DestAddr: 2:221/1234.0
pkt created: Wed Apr 22 12:54:48 2020
pkt Password: Test123
prodCode: 0061
prodRevision 1.20
-+--------------------------------------
Msg: 221/360 -> 221/1234

=== End OS/2 Clipboard ===

'Tommi

--- GoldED+/EMX 1.1.5-b20180707
* Origin: ---------------------------------->> (2:221/360)

Hi Oli,

On 2020-04-22 10:44:22, you wrote to me:

I was wondering about packet passwords, are they case insensitive or
not?

When I look at the packets I receive, there are some with lower or
even mixed case passwords.

Crashmail sends the (mixed-case) password string exactly as configured,

no

conversion to uppercase.

Good to know...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Alan,

On 2020-04-22 01:47:08, you wrote to me:

Why a PITA?

I've had issues with session passwords because folks has told me to use a password (lower case) but they enter it in their setup in upper case. That's a PITA.

Well there is no cure for stupidity. ;)

But that's not a reason to limit security and do case insensitive compares on passwords.

You have to configure it once. Check that it works and be done with
it...

As long as folks understand the need for this at setup it should pose no problems.

That's what I mean...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi! Wilfred,

On 22 Apr 20 10:17, you wrote to me:

On FMails side that's not a problem because it checks the passwords
case insensitive.
How they deal with it on their side is their problem. ;)

Not a problem. I recall having trouble with -some- other packages but I cannot cite anything with certainty. Go ahead and make a new rule and I'll toe the line.

Cheers,
Paul.

... Blonde Borgs all have the same fun.
--- GoldED+/LNX 1.1.5-b20130515
* Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)

22 Apr 20 01:47, you wrote to Wilfred van Velzen:

Hello Wilfred,

Why a PITA?

I've had issues with session passwords because folks has told me to
use a password (lower case) but they enter it in their setup in upper case. That's a PITA.

And they were using the case sensitive tosser?

* Origin: kakistocracy (2:280/464.47)

On 22 Apr 20 09:46:12, Wilfred Van Velzen said the following to Nick Andre:

Offhand... and I could be wrong... AdeptXBBS Gatekeeper, TBBS/Flame, 1.20/Pro... Possibly Viamail. I'm sure there are others.

That's an obscure list. ;)
Never heard of the first two, are they still used?

They are 90's products. I doubt anyone uses them anymore. But you asked...

I had a downlink years ago who specifically needed a mixed-case password.

Was that a technical necessity? I can hardly imagine that.

I can't remember but I seriously doubt it.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Hi Nick,

On 2020-04-22 08:29:48, you wrote to me:

Offhand... and I could be wrong... AdeptXBBS Gatekeeper,

TBBS/Flame, G

1.20/Pro... Possibly Viamail. I'm sure there are others.

That's an obscure list. ;)
Never heard of the first two, are they still used?

They are 90's products. I doubt anyone uses them anymore. But you

asked...

Well, yes, it's good to know there already were case sensitive tossers out there in the past...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Oli,

I've had issues with session passwords because folks has told me
to use a password (lower case) but they enter it in their setup
in upper case. That's a PITA.

And they were using the case sensitive tosser?

Not that I know of. I have never run into a case sensitive tosser, at least not that I know of.

In the case of my own tosser HPT, I don't think it is case sensitive. It is happy with upper, lower or mixed case. That's an assumption on my part I have never tested. It's been my habit to enter passwords in upper case and that has never caused problems or confusion, at least not for me.

If I enter a packet password in my config in mixed case it writes that password in the .pkt in mixed case but I don't think it checks password case senitively. Given a bit of spare time I am going to have to test that out to be sure given what I have read in the last few days.. :)

Ttyl :-),
Al

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

Re: Re: Pssword ord ord case insensitive or not?
By: Wilfred van Velzen to Alan Ianson on Wed Apr 22 2020 11:26:58

Well there is no cure for stupidity. ;)

sure there is but it isn't very nice or generally acceptible...

the cure? hot lead at high velocity ;) O:)


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

22 Apr 20 09:58, you wrote to me:

Hello Oli,

I've had issues with session passwords because folks has told me
to use a password (lower case) but they enter it in their setup
in upper case. That's a PITA.

And they were using the case sensitive tosser?

Not that I know of. I have never run into a case sensitive tosser, at least not that I know of.

I missed the "session" before the "password" and thought you were still talking about packet passwords. Now I get it.

I wonder why we still use packet passwords. Why not create a inbound filebox for every node/point that calls and rely on the session password? Is there any (open source) mailer or tosser that support inbound fileboxes?


* Origin: kakistocracy (2:280/464.47)

Re: Pssword ord ord case insensitive or not?
By: Oli to Alan Ianson on Wed Apr 22 2020 21:37:31

I wonder why we still use packet passwords.

at one time, fidonet has had some folks that like to ""play games""... one of their games was to take messages from another (adult-oriented) network, replace their headers with message headers from legitimate fidonet messages, and then drop those bogus messages off in unsuspecting systems inbounds... they generally used someone else's node number for these injections... at that time, packet passwords were not as widely used and figuring out how to get a system's session password was (and still is) fairly easy to do... one of the suspected goals of these pranksters(??) was to try to increase security in fidonet... so the victim systems, saw the mail from a supposedly legitimate link and tossed it... the result was chaos...

Why not create a inbound filebox for every node/point that calls
and rely on the session password?

two layers of protection are better than one... at least, that's the current thought... witness today's internet logins using a password as well as an authentication token sent via SMS or similar...

Is there any (open source) mailer or tosser that support inbound fileboxes?

binkd supports inbound fileboxes... i'm not sure about tossers, though...

when i was using inbound fileboxes on my previous system, i had a script that located inbound traffic in the inbound fileboxes and moved it to a central processing directory where the tosser could find it... in addition to moving the traffic, the script did some additional processing to attempt to validate the traffic as being authentic before the tosser was allowed to process it... the traffic was also archived for later analysis if needed... it wasn't really pretty but it worked ;)


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

On 22 Apr 20 21:37:31, Oli said the following to Alan Ianson:

I wonder why we still use packet passwords. Why not create a inbound

filebox

for every node/point that calls and rely on the session password? Is there (open source) mailer or tosser that support inbound fileboxes?

Because non-passworded Echomail packets are a tad bit more suspicious than non-passworded Netmail packets.

Nick

--- Renegade vY2Ka2
* Origin: Joey, do you like movies about gladiators? (1:229/426)

Re: Re: Packet password case insensitive or not?
By: Wilfred van Velzen to Rob Swindell on Wed Apr 22 2020 09:52 am

Hi Rob,

On 2020-04-21 16:12:07, you wrote to me:

SBBSecho has always treated packet passwords case-INsensitively. It is unfortuate that so many of the fido specifications were so badly written to begin with and the resulting ambiguities and contradictions have never been sufficiently addressed by the FTSC.

There is no ambiguity for packet password case sensitivity. It's just not specified, so anything goes...

Yeah, that's the definition of ambiguity.

Luckily, with password-protected mail sessions the norm these days, packet passwords are kind of moot and probably should just be deprecated. Doubt that'll happen though.

I don't agree here. Packet passwords provide an extra layer of security.

For

instance without it, anyone can drop a .pkt file in your insecure inbound with a falsified source address and echomail in it. If you process .pkt files from your inbound automatically, it will get tossed, if there is no packet password agreeded upon for the falsified source...

SBBSecho will not import echomail from an insecure inbound directory.

digital man

This Is Spinal Tap quote #14:
The Boston gig has been cancelled. [Don't] worry, it's not a big college town. Norco, CA WX: 81.9øF, 43.0% humidity, 6 mph ESE wind, 0.00 inches rain/24hrs --- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Pssword ord ord case insensitive or not?
By: mark lewis to Oli on Wed Apr 22 2020 03:57 pm

binkd supports inbound fileboxes... i'm not sure about tossers, though...

SBBSecho supports inbound fileboxes. Not sure if any one has actually used/tested them yet.

digital man

This Is Spinal Tap quote #41:
Ian Faith: It say's "Memphis show cancelled due to lack of advertising funds." Norco, CA WX: 82.4øF, 39.0% humidity, 5 mph ENE wind, 0.00 inches rain/24hrs --- SBBSecho 3.10-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hello Oli,

I wonder why we still use packet passwords. Why not create a inbound filebox for every node/point that calls and rely on the session
password? Is there any (open source) mailer or tosser that support
inbound fileboxes?

I use binkd and it does support in and out fileboxes. I have only ever used an outbound filebox for one node and that does what I need it to do. I have never used an inbound filebox so I'm not sure how that would work in practice or if it would fill any real need. I'm not sure my tosser knows how to use an inbound filebox for a link.

What I would like to see is a proper binkps protocol. We could drop the CRYPT option (when using binkps) and have a fully secure session, regardless of inbound or outbound directories.

Ttyl :-),
Al

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

Re: Pssword ord ord case insensitive or not?
By: Rob Swindell to mark lewis on Wed Apr 22 2020 13:21:23

binkd supports inbound fileboxes... i'm not sure about tossers, though...

SBBSecho supports inbound fileboxes. Not sure if any one has actually used/tested them yet.

ahh! nice to know... something else added to the TODO list ;)


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

22 Apr 20 13:10, you wrote to me:

Hello Oli,

I wonder why we still use packet passwords. Why not create a
inbound filebox for every node/point that calls and rely on the
session password? Is there any (open source) mailer or tosser
that support inbound fileboxes?

I use binkd and it does support in and out fileboxes. I have only ever used an outbound filebox for one node and that does what I need it to
do. I have never used an inbound filebox so I'm not sure how that
would work in practice or if it would fill any real need. I'm not sure
my tosser knows how to use an inbound filebox for a link.

But you have to define the filebox for every node in advance. I thougt it would be nice to create a filebox for every incoming connection automatically. Argus is very flexible (search for filebox):

http://www.artur.pl/hack/ritlabs.ii.pl/argus/hlp/eng/index.html

What I would like to see is a proper binkps protocol. We could drop
the CRYPT option (when using binkps) and have a fully secure session, regardless of inbound or outbound directories.

I don't understand how this is connected to packet passwords and inbound dirs.

* Origin: kakistocracy (2:280/464.47)

Hello Oli,

But you have to define the filebox for every node in advance. I thougt
it would be nice to create a filebox for every incoming connection automatically. Argus is very flexible (search for filebox):

http://www.artur.pl/hack/ritlabs.ii.pl/argus/hlp/eng/index.html

That's an interesting idea but you'd have to communicate the location of that inbound filebox to your tosser somehow.

What I would like to see is a proper binkps protocol. We could
drop the CRYPT option (when using binkps) and have a fully secure
session, regardless of inbound or outbound directories.

I don't understand how this is connected to packet passwords and
inbound dirs.

If we had a reliable/secure session we wouldn't need packet passwords or inbound directories randomly placed around the file system.

Ttyl :-),
Al

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

Re: Pssword ord ord case insensitive or not?
By: Oli to Alan Ianson on Wed Apr 22 2020 22:34:47

What I would like to see is a proper binkps protocol. We could drop
the CRYPT option (when using binkps) and have a fully secure session,
regardless of inbound or outbound directories.

I don't understand how this is connected to packet passwords and
inbound dirs.

it is simply an "aside comment" and could be the beginning of a branch off of this topic ;)


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)

Hi Oli.

22 Apr 20 21:37:30, you wrote to Alan Ianson:

I wonder why we still use packet passwords. Why not create a inbound filebox for every node/point that calls and rely on the session
password? Is there any (open source) mailer or tosser that support
inbound fileboxes?

BinkD :) I have different inboxes for some of my links.

Hpt can handle multiple inbound dirs, it just needs some tweaking by env vars. Or included configs.

'Tommi

---
* Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)

22 Apr 20 14:12, you wrote to me:

Hello Oli,

But you have to define the filebox for every node in advance. I
thougt it would be nice to create a filebox for every incoming
connection automatically. Argus is very flexible (search for
filebox):

http://www.artur.pl/hack/ritlabs.ii.pl/argus/hlp/eng/index.html

That's an interesting idea but you'd have to communicate the location
of that inbound filebox to your tosser somehow.

It could be like BSO for inbound. You just need a good specification for the format.
E.g. Node 7:8/9 calls and received files are put into

inbound/othernet.7.8.9.0/trusted/

or if there is no session password into

inbound/othernet.7.8.9.0/unknown/

No need to specifiy an inbox for every node and point in the mailer's config.

What I would like to see is a proper binkps protocol. We could
drop the CRYPT option (when using binkps) and have a fully
secure session, regardless of inbound or outbound directories.

I don't understand how this is connected to packet passwords and
inbound dirs.

If we had a reliable/secure session we wouldn't need packet passwords
or inbound directories randomly placed around the file system.

I still don't understand how that helps. What exactly do you have in mind?

The problem is the interface between mailer and tosser. Everyone with a session password can drop anything in my shared "secure" inbound. So now we need a packet password, because the information about the session is thrown out the window and isn't communicated to the tosser. We wouldn't need a packet password, if the tosser did know that the packet was delivered in an authenticated session with node 7:8/9.


* Origin: kakistocracy (2:280/464.47)

Hi mark,

On 2020-04-22 14:25:45, you wrote to me:

Well there is no cure for stupidity. ;)

sure there is but it isn't very nice or generally acceptible...

the cure? hot lead at high velocity ;) O:)

It's a permanent solution. I would call it a cure. ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Rob,

On 2020-04-22 13:15:19, you wrote to me:

Luckily, with password-protected mail sessions the norm these

days,

packet passwords are kind of moot and probably should just be
deprecated. Doubt that'll happen though.

I don't agree here. Packet passwords provide an extra layer of security.
For instance without it, anyone can drop a .pkt file in your insecure
inbound with a falsified source address and echomail in it. If you
process .pkt files from your inbound automatically, it will get tossed,
if there is no packet password agreeded upon for the falsified source...

SBBSecho will not import echomail from an insecure inbound directory.

Not every system works that way...

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hello Oli,

That's an interesting idea but you'd have to communicate the
location of that inbound filebox to your tosser somehow.

It could be like BSO for inbound. You just need a good specification
for the format. E.g. Node 7:8/9 calls and received files are put into

inbound/othernet.7.8.9.0/trusted/

or if there is no session password into

inbound/othernet.7.8.9.0/unknown/

No need to specifiy an inbox for every node and point in the mailer's config.

I think that's an interesting idea and as Tommi suggested it could be made to work with environment variables or include files.

I'm happy with my inbound as it is and can't think of any reason to make it more complicated.

If we had a reliable/secure session we wouldn't need packet
passwords or inbound directories randomly placed around the file
system.

I still don't understand how that helps. What exactly do you have in
mind?

I don't actually have anything in mind. I dunno how we got on this topic. :)

The problem is the interface between mailer and tosser. Everyone with
a session password can drop anything in my shared "secure" inbound. So
now we need a packet password, because the information about the
session is thrown out the window and isn't communicated to the tosser.
We wouldn't need a packet password, if the tosser did know that the
packet was delivered in an authenticated session with node 7:8/9.

Isn't that the difference between a secure and unsecure inbound?

It is a shared inbound but it is secure.

Ttyl :-),
Al

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

Hi! Wilfred,

On 23 Apr 20 11:31, you wrote to mark lewis:

Well there is no cure for stupidity. ;)

sure there is but it isn't very nice or generally acceptible...

the cure? hot lead at high velocity ;) O:)

It's a permanent solution. I would call it a cure. ;)

OTOH low velocity is a wakeup call you're not likely to forget. ;)

Cheers,
Paul.

... I used up all my sick days, so I'm calling in dead.
--- GoldED+/LNX 1.1.5-b20130515
* Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)

23 Apr 20 02:36, you wrote to me:

It could be like BSO for inbound. You just need a good
specification for the format. E.g. Node 7:8/9 calls and received
files are put into

inbound/othernet.7.8.9.0/trusted/
[...]
No need to specifiy an inbox for every node and point in the
mailer's config.

I think that's an interesting idea and as Tommi suggested it could be
made to work with environment variables or include files.

I'm happy with my inbound as it is and can't think of any reason to
make it more complicated.

The goal would be to have support for something like this in the mailer _and_ tosser software and have a solution that is less complicated. Realistically it would be just another format with limited support ;). On the other hand it is not that complicated.

If we had a reliable/secure session we wouldn't need packet
passwords or inbound directories randomly placed around the file
system.

I still don't understand how that helps. What exactly do you have
in mind?

I don't actually have anything in mind. I dunno how we got on this
topic. :)

You said binkps could make packet passwords obsolete. I still want to know how that would work ;).

The problem is the interface between mailer and tosser. Everyone
with a session password can drop anything in my shared "secure"
inbound. So now we need a packet password, because the
information about the session is thrown out the window and isn't
communicated to the tosser. We wouldn't need a packet password,
if the tosser did know that the packet was delivered in an
authenticated session with node 7:8/9.

Isn't that the difference between a secure and unsecure inbound?

It is a shared inbound but it is secure.

There is a difference between

1) this pkt/file is from some authenticated node (we don't know which one)
2) this pkt/file is from node 7:8/9

For 1) you have to use packet passwords (if you have more than one uplink/downlink).
With 2) the packet password would be redundant.


* Origin: kakistocracy (2:280/464.47)

Re: Pssword ord ord case insensitive or not?
By: Oli to Alan Ianson on Thu Apr 23 2020 09:57:10

The problem is the interface between mailer and tosser. Everyone
with a session password can drop anything in my shared "secure"
inbound. So now we need a packet password, because the information
about the session is thrown out the window and isn't communicated
to the tosser. We wouldn't need a packet password, if the tosser
did know that the packet was delivered in an authenticated session
with node 7:8/9.

so how are you going to provide that information if you are doing FTN via pigeon, tape, or sneakernet transfers?

the tosser is the tosser... it doesn't need to know anything about *how* packets arrived on system... it only needs to know if they are in the secure or insecure inbound and make its decision to process or not from that information...


)\/(ark
--- SBBSecho 3.10-Linux
* Origin: SouthEast Star Mail HUB - SESTAR (1:3634/12)