"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)
"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?
I was wondering about packet passwords, are they case insensitive or not?
I was wondering about packet passwords, are they case insensitive or
not?
Packet passwords are treated case sensitive by some tossers.
I was wondering about packet passwords, are they case insensitive or
not?
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!
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 passwords are treated case sensitive by some tossers.
Do you know which ones?
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)
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.
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. ;)
In all my experience packet, areafix and filefix passwords have
been case insensitive.
this is because traditionally, all FTN software uppercased everything
;)
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...
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.
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.
don'tYou 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
know that rule and insist on setting mixedcase. Evil people. Smelly people. Ugly people...
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.
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. ;)
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?
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 ;).
I was wondering about packet passwords, are they case insensitive or not?mixed case passwords.
When I look at the packets I receive, there are some with lower or even
Why a PITA?
You have to configure it once. Check that it works and be done with
it...
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.
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.
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.
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. ;)
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.
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?
I had a downlink years ago who specifically needed a mixed-case password.
Was that a technical necessity? I can hardly imagine that.
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...
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?
Well there is no cure for stupidity. ;)
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 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?
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...
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 a (open source) mailer or tosser that support inbound fileboxes?
binkd supports inbound fileboxes... i'm not sure about tossers, though...
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 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.
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.
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.
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.
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?
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.
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:)
Luckily, with password-protected mail sessions the norm thesedays,
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.
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.
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.
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. ;)
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.
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.
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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 991 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 77:05:41 |
| Calls: | 12,949 |
| Calls today: | 3 |
| Files: | 186,574 |
| Messages: | 3,264,591 |