On 2017 Nov 16 20:33:28, you wrote to Zazz:
2. Define and use a session password to use for your BinkP sessions (your hub will need the same password), and then in the packets will come into your secure inbound and not require a password in the packet, or:
on this...
you have a session and packet level passwords.
remote has session level only - PKT should be renamed .BAD even
if it is in trusted* inbound.
in other words, no password should be ignored... it is possible for someone to figure out another system's session level password and emulate them while dropping off packets without packet level passwords... legitimate packets from the legitimate source would pass because of both passwords... if they figure out the packet password but not the session one, it won't matter because the mail would end up in the untrusted* inbound...
or am i misreading something?
FWIW: one could use other extensions, as well... maybe .PAS for bad or invalid passwords... .BAD for just missing passwords... .WRG for packets delivered to the wrong system... just tossing some ideas out there... i forget what all various extensions are that are used by various tossers but .BAD is only one of
them and has a specific meaning...
* i'm using the terms "trusted" and "untrusted" instead of "secure" and "insecure" because anything from remote is not really "secure"... it is trusted
or not... in my frontdoor/fastecho setup, i have untrusted, trusted and secure inbounds... the untrusted and trusted inbounds are managed by the mailer... connections with valid session level passwords have their files placed into the
"trusted" inbound... all others go to the "untrusted" inbound... the "secure" inbound is accessed by the mail tosser and other local packet generating tools /only/... nothing remote is allowed access to the "secure" inbound... "secure" is the only one where (packet) passwords don't matter (to the mailer) but i still cringe at that... the "secure" directory would be where one's new file announcement PKTs would be placed if one's system generated PKTs for them that had to be tossed into the local message base and passed on to other systems... the "secure" inbound might also be where different tools place PKTs with status
messages... the key thing being that the mailer and these local tools are the only ones that know about the "secure" inbound...
)\/(ark
Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... A pedestrian hit me and went under my car.
---
* Origin: (1:3634/12.73)
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net