Replies welcome.

digital man

Synchronet "Real Fact" #49:
Synchronet program was named 'sbbs' instead of 'sync' to avoid conflict w/Unix. Norco, CA WX: 50.5oF, 75.0% humidity, 6 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hi Rob.

01 Mar 18 20:01:56, you wrote to All:

Replies welcome.

=== Cut ===
07:55 [7652] BEGIN, binkd/1.1a-96/CYGWIN_NT-6.1 -p -P 1:103/705 binkd.cfg
07:55 [7652] creating a poll for 1:103/705@fidonet (`d' flavour)
07:55 [7652] clientmgr started
+ 07:55 [3972] call to 1:103/705@fidonet
07:55 [3972] trying vert.synchro.net [71.95.196.34]...
07:55 [3972] connected
+ 07:55 [3972] outgoing session with vert.synchro.net:24554 [71.95.196.34]
- 07:55 [3972] OPT CRAM-MD5-093c975edb2db8401522f7100689992a7509cc84ebfe827 3d3cdff9644d061a00e449bdb73b77fb196b995236c8fc52a71b82f2eb461fa2ed932d728b6 49acb7 CRYPT
+ 07:55 [3972] Remote requests MD mode
+ 07:55 [3972] Remote requests CRYPT mode
- 07:55 [3972] SYS Vertrauen
- 07:55 [3972] ZYZ digital man
- 07:55 [3972] LOC Riverside County, California
- 07:55 [3972] NDL 115200,TCP,BINKP
- 07:55 [3972] TIME Thu Mar 01 2018 21:55:24 GMT-0800 (Pacific Standard Time)
- 07:55 [3972] VER BinkIT/1.46,JSBinkP/1.72/Win32 binkp/1.1
+ 07:55 [3972] addr: 1:103/705@fidonet
+ 07:55 [3972] done (to 1:103/705@fidonet, OK, S/R: 0/0 (0/0 bytes))
07:55 [3972] session closed, quitting...
07:55 [7652] rc(3972)=0
07:55 [7652] the queue is empty, quitting...
=== Cut ===

'Tommi

---
* Origin: Point One. Ylojarvi, Finland. (2:221/1.1)

Re: Testing a new mailer (BinkIT)
By: Tommi Koivula to Rob Swindell on Fri Mar 02 2018 07:56 am

+ 07:55 [3972] outgoing session with vert.synchro.net:24554 [71.95.196.34]

Thank you,

digital man

This Is Spinal Tap quote #5:
Nigel Tufnel: Authorities said... best leave it... unsolved.
Norco, CA WX: 48.0oF, 78.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hi Rob,

On 2018-03-01 20:01:57, you wrote to All:

Replies welcome.

It looks good:

Incomming:

+ 02 Mar 05:07:36 [26260] incoming session with vert.synchro.net [71.95.196.34] - 02 Mar 05:07:36 [26260] OPT CRYPT
+ 02 Mar 05:07:36 [26260] Remote requests CRYPT mode
- 02 Mar 05:07:36 [26260] SYS Vertrauen
- 02 Mar 05:07:36 [26260] ZYZ digital man
- 02 Mar 05:07:36 [26260] LOC Riverside County, California
- 02 Mar 05:07:36 [26260] NDL 115200,TCP,BINKP
- 02 Mar 05:07:36 [26260] TIME Thu Mar 01 2018 20:07:27 GMT-0800 (Pacific Standard Time)
- 02 Mar 05:07:36 [26260] VER BinkIT/1.46,JSBinkP/1.72/Win32 binkp/1.1
+ 02 Mar 05:07:36 [26260] addr: 1:103/705@fidonet
+ 02 Mar 05:07:36 [26260] pwd protected session (MD5)
- 02 Mar 05:07:36 [26260] session in CRYPT mode
- 02 Mar 05:07:36 [26260] receiving 5a98cc4a.pkt (658 byte(s), off 0)
+ 02 Mar 05:07:37 [26260] rcvd: 5a98cc4a.pkt (658, 658.00 CPS, 1:103/705@fidonet)
- 02 Mar 05:07:37 [26260] receiving 5a98ccc3.pkt (720 byte(s), off 0)
+ 02 Mar 05:07:37 [26260] rcvd: 5a98ccc3.pkt (720, 720.00 CPS, 1:103/705@fidonet)
+ 02 Mar 05:07:37 [26260] done (from 1:103/705@fidonet, OK, S/R: 0/2 (0/1378 bytes))
02 Mar 05:07:47 [26239] session closed, quitting...

Outgoing:

+ 02 Mar 05:08:33 [26310] call to 1:103/705@fidonet
02 Mar 05:08:34 [26310] trying vert.synchro.net [71.95.196.34]...
02 Mar 05:08:34 [26310] connected
+ 02 Mar 05:08:34 [26310] outgoing session with vert.synchro.net:24554 [71.95.196.34]
- 02 Mar 05:08:35 [26310] OPT CRAM-MD5-093c...
+ 02 Mar 05:08:35 [26310] Remote requests MD mode
+ 02 Mar 05:08:35 [26310] Remote requests CRYPT mode
- 02 Mar 05:08:35 [26310] SYS Vertrauen
- 02 Mar 05:08:35 [26310] ZYZ digital man
- 02 Mar 05:08:35 [26310] LOC Riverside County, California
- 02 Mar 05:08:35 [26310] NDL 115200,TCP,BINKP
- 02 Mar 05:08:35 [26310] TIME Thu Mar 01 2018 20:08:26 GMT-0800 (Pacific Standard Time)
- 02 Mar 05:08:35 [26310] VER BinkIT/1.46,JSBinkP/1.72/Win32 binkp/1.1
+ 02 Mar 05:08:35 [26310] addr: 1:103/705@fidonet
+ 02 Mar 05:08:35 [26310] pwd protected session (MD5)
- 02 Mar 05:08:35 [26310] session in CRYPT mode
+ 02 Mar 05:08:35 [26310] sending /home/fido/outbound.001/a98ce407.pkt as a98ce407.pkt (718)
+ 02 Mar 05:08:35 [26310] sent: /home/fido/outbound.001/a98ce407.pkt (718, 718.00 CPS, 1:103/705@fidonet)
+ 02 Mar 05:08:36 [26310] done (to 1:103/705@fidonet, OK, S/R: 1/0 (718/0 bytes))
02 Mar 05:08:36 [26310] session closed, quitting...

Before:

+ 22 Feb 10:49:59 [14811] incoming session with vert.synchro.net [71.95.196.34] - 22 Feb 10:50:05 [14811] SYS Vertrauen
- 22 Feb 10:50:05 [14811] ZYZ Rob Swindell
- 22 Feb 10:50:05 [14811] LOC Riverside County, California
- 22 Feb 10:50:05 [14811] NDL 115200,TCP,BINKP
- 22 Feb 10:50:05 [14811] TIME Thu, 22 Feb 2018 01:46:42 -0800
- 22 Feb 10:50:05 [14811] VER binkd/1.0.4/Win32 binkp/1.1
+ 22 Feb 10:50:05 [14811] addr: 1:103/705@fidonet
- 22 Feb 10:50:05 [14811] OPT NDA EXTCMD CRYPT
+ 22 Feb 10:50:05 [14811] Remote supports asymmetric ND mode
+ 22 Feb 10:50:05 [14811] Remote supports EXTCMD mode
+ 22 Feb 10:50:05 [14811] Remote requests CRYPT mode
- 22 Feb 10:50:06 [14811] TRF 0 4072
+ 22 Feb 10:50:06 [14811] Remote has 0b of mail and 4072b of files for us
+ 22 Feb 10:50:06 [14811] pwd protected session (MD5)
- 22 Feb 10:50:06 [14811] session in CRYPT mode
- 22 Feb 10:50:07 [14811] receiving 5a8e913b.pkt (4072 byte(s), off 0)
+ 22 Feb 10:50:07 [14811] rcvd: 5a8e913b.pkt (4072, 4072.00 CPS, 1:103/705@fidonet)
+ 22 Feb 10:50:07 [14811] done (from 1:103/705@fidonet, OK, S/R: 0/1 (0/4072 bytes))
22 Feb 10:50:07 [14811] session closed, quitting...

The OPT line is in a different position. But I don't know if there is any significance to that...


Bye, Wilfred.

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

On 2018 Mar 01 20:01:56, you wrote to All:

@TZUTC: -0800
@MSGID: 3839.fidotest@1:103/705 1efe11b4
@PID: Synchronet 3.17a-Win32 Debug Feb 20 2018 MSC 1800
@TID: SBBSecho 3.03-Win32 r3.70 Feb 22 2018 MSC 1800
Replies welcome.

digital man

Synchronet "Real Fact" #49:
Synchronet program was named 'sbbs' instead of 'sync' to avoid conflict w/Unix. Norco, CA WX: 50.5oF, 75.0% humidity, 6 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
SEEN-BY: 11/0 103/705 114/485 116/116 120/302 340 419 544 546 601 640 123/25
SEEN-BY: 123/141 150 135/300 153/7715 154/10 203/0 218/700 220/0 40 50 70 SEEN-BY: 221/0 226/70 301 350 227/0 60 70 229/426 240/1661 5832 261/38 SEEN-BY: 280/464 5003 5555 310/31 331/51 423/120 712/848 770/1 2215/15 300 SEEN-BY: 2215/1701 2320/0 1 100 102 103 200 3634/12 15 22 24 27 50 119 666 SEEN-BY: 5020/830
@PATH: 103/705 280/464 2320/100 120/544 3634/15 12

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... How can I be over the hill when I never got to the top?
---
* Origin: (1:3634/12.73)

On 2018 Mar 01 20:01:56, you wrote to All:

Replies welcome.

+ 02 Mar 10:38:10 [9092] call to 1:103/705@fidonet
02 Mar 10:38:11 [9092] trying vert.synchro.net [71.95.196.34]...
02 Mar 10:38:11 [9092] connected
+ 02 Mar 10:38:11 [9092] outgoing session with vert.synchro.net:24554 [71.95.196.34]
- 02 Mar 10:38:12 [9092] OPT CRAM-MD5-093c975edb2db8401522f7100689992a7509cc84ebfe8273d3cdff9644d061a00e449bdb73b77fb196b995236c8fc52a71b82f2eb461fa2ed932d728b649acb7 CRYPT
+ 02 Mar 10:38:12 [9092] Remote requests MD mode
+ 02 Mar 10:38:12 [9092] Remote requests CRYPT mode
- 02 Mar 10:38:12 [9092] SYS Vertrauen
- 02 Mar 10:38:12 [9092] ZYZ digital man
- 02 Mar 10:38:12 [9092] LOC Riverside County, California
- 02 Mar 10:38:12 [9092] NDL 115200,TCP,BINKP
- 02 Mar 10:38:12 [9092] TIME Fri Mar 02 2018 07:38:06 GMT-0800 (Pacific Standard Time)
- 02 Mar 10:38:12 [9092] VER BinkIT/1.48,JSBinkP/1.72/Win32 binkp/1.1
+ 02 Mar 10:38:12 [9092] addr: 1:103/705@fidonet
+ 02 Mar 10:38:12 [9092] done (to 1:103/705@fidonet, OK, S/R: 0/0 (0/0 bytes))
02 Mar 10:38:13 [9092] session closed, quitting...
02 Mar 10:38:13 [3314] rc(9092)=0


FWIW: that's the longest CRAM-MD5 i've seen since i started using binkd/binkp... all the others we've seen (grepped 2015-2018 binkd logs just because) have been 32 characters long... i just found it interesting :)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... There is no God, it's just Satan when he's sober!
---
* Origin: (1:3634/12.73)

Rob Swindell wrote in a message to All:

Replies welcome.

digital man

Synchronet "Real Fact" #49:
Synchronet program was named 'sbbs' instead of 'sync' to avoid
conflict w/Unix. Norco, CA WX: 50.5?F, 75.0% humidity, 6 mph E
wind, 0.00 inches rain/24hrs --- SBBSecho 3.03-Win32
- Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Got it here :)

Peace,
Robert

--- timEd/2 1.30+
* Origin: Omicron Theta/2 * Southaven, MS * os2bbs.org:2300 (1:261/20)

@TZUTC: -0800

@MSGID: 3839.fidotest@1:103/705 1efe11b4

@PID: Synchronet 3.17a-Win32 Debug Feb 20 2018 MSC 1800

@TID: SBBSecho 3.03-Win32 r3.70 Feb 22 2018 MSC 1800

Replies welcome.

digital man


Synchronet "Real Fact" #49:

Synchronet program was named 'sbbs' instead of 'sync' to avoid conflict

w/Unix.

Norco, CA WX: 50.5oF, 75.0% humidity, 6 mph E wind, 0.00 inches

rain/24hrs

--- SBBSecho 3.03-Win32

* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
SEEN-BY: 222/2 261/38 263/1
ATH: 103/705 280/464 2320/100 261/38 222/2 263/1

Looks good here

Sean
--- AfterShock/Android 1.6.7
* Origin: TheCivvie on the move (2:263/1.950)

Re: Testing a new mailer (BinkIT)
By: mark lewis to Rob Swindell on Fri Mar 02 2018 10:59 am

On 2018 Mar 01 20:01:56, you wrote to All:

Replies welcome.

+ 02 Mar 10:38:10 [9092] call to 1:103/705@fidonet
02 Mar 10:38:11 [9092] trying vert.synchro.net [71.95.196.34]...
02 Mar 10:38:11 [9092] connected
+ 02 Mar 10:38:11 [9092] outgoing session with vert.synchro.net:24554 [71.95.196.34]
- 02 Mar 10:38:12 [9092] OPT CRAM-MD5-093c975edb2db8401522f7100689992a7509cc 84ebfe8273d3cdff9644d061a00e449bdb73b77fb196b995236c8fc52a71b82f2eb461fa2ed9 32d728b649acb7 CRYPT

FWIW: that's the longest CRAM-MD5 i've seen since i started using binkd/binkp... all the others we've seen (grepped 2015-2018 binkd logs just because) have been 32 characters long... i just found it interesting :)

That was a helpful observation. As it turns out, although the spec (FTS-1027) allows for CRAM challeges up to 64 bytes (128 hex-nibbles) in length, Internet Rex only uses the first 16 bytes (32 hex-nibbles) of the challenge. So we've had to reduce the challege size down to 16-bytes because it's unlikely IRex is going to be fixed anytime soon. :-(

digital man

Synchronet/BBS Terminology Definition #27:
HTTP = Hypertext Transfer Protocol
Norco, CA WX: 60.5oF, 22.0% humidity, 0 mph S wind, 0.00 inches rain/24hrs
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2018 Mar 06 23:55:34, you wrote to me:

- 02 Mar 10:38:12 [9092] OPT
CRAM-MD5-093c975edb2db8401522f7100689992a7509cc
84ebfe8273d3cdff9644d061a00e449bdb73b77fb196b995236c8fc52a71b82f2eb461f
a2ed932d728b649acb7 CRYPT

FWIW: that's the longest CRAM-MD5 i've seen since i started using
binkd/binkp... all the others we've seen (grepped 2015-2018 binkd logs
just because) have been 32 characters long... i just found it
interesting :)

That was a helpful observation.

i'm glad i wrote the post about it... i started not to but then got curious and
ran the grep to see... out of 388450 samples, none were shorter than 32 characters and only one, the one above, was longer... kinda makes one wonder "why?" and "what language limitations caused this?"...

As it turns out, although the spec (FTS-1027) allows for CRAM
challeges up to 64 bytes (128 hex-nibbles) in length, Internet Rex
only uses the first 16 bytes (32 hex-nibbles) of the challenge. So
we've had to reduce the challege size down to 16-bytes because it's unlikely IRex is going to be fixed anytime soon. :-(

i think, i'm not sure and i don't know if i agree with the following or not but, there is at least one mailer that has a selection in each contact's record
(aka linked node in sbbsecho speak) where you can say that the remote is using mailer X so your mailer will use limited/ranged capabilities with the remote when negotiation a connection... in other words, a true/false setting in binkit
that the binkit operator would set if the remote system is using IREX... this is useful for outbound connections to those nodes... for inbound connections, the local mailer would need to decipher the mailer id line (VER) to see if the inbound is from an IREX mailer and then go from there...

the following example cobbled together from echocfg "Linked Nodes" definition screen because i've not seen binkit yet and don't know where it gets all its information from...


Linked Node - 1:23/45
====================================
Address 1:23/45
Comment
IREX Mailer Yes
Archive Type None
Packet Type 2+
Packet Password
AreaFix Password
AreaFix Keys
Status Normal
Direct Yes
Passive No
Send Notify List No
Route To Disabled
Inbox Directory
Outbox Directory


if the setting is true, a reduced/chopped CRAM-MD5 is sent otherwise the full form is sent... this is also handy for binkp 1.0 vs 1.1 which IREX has a partial implementation of 1.1, IIRC...

like i say above, i don't know if i agree with it or not but it is a workable idea... it could turn into a selection from a list if more mailers are found to
be flawed in similar fashion...

it would be really really really huge if charles were to come back with a fixed
IREX...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... You win a DVD of Richard Simmons Sweating to the Oldies: XXX Version.
---
* Origin: (1:3634/12.73)

Re: Testing a new mailer (BinkIT)
By: mark lewis to Rob Swindell on Wed Mar 07 2018 08:30 am

On 2018 Mar 06 23:55:34, you wrote to me:

- 02 Mar 10:38:12 [9092] OPT
CRAM-MD5-093c975edb2db8401522f7100689992a7509cc
84ebfe8273d3cdff9644d061a00e449bdb73b77fb196b995236c8fc52a71b82f2eb461f
a2ed932d728b649acb7 CRYPT

FWIW: that's the longest CRAM-MD5 i've seen since i started using
binkd/binkp... all the others we've seen (grepped 2015-2018 binkd logs
just because) have been 32 characters long... i just found it
interesting :)

That was a helpful observation.

i'm glad i wrote the post about it... i started not to but then got curious and
ran the grep to see... out of 388450 samples, none were shorter than 32 characters and only one, the one above, was longer... kinda makes one wonder "why?" and "what language limitations caused this?"...

Here's my guess:

It's not a language limitation. Binkd is the reference implementation and likely Irex just followed Binkd's example, which was to send a 16-byte (32-char) CRAM-MD5 challenge - always. Now Binkd will *accept* a longer CRAM-MD5 challege from the binkp-peer (when making outgoing connections), but it'll never generate one.

So either Irex's binkp implementation was written before any formal specification was published or the author just didn't read the spec and instead just testd with binkd and only ever *expected* a 16-byte challenge and only used the first 16-bytes (32 hex-chars) when calculating the HMAC response.

(aka linked node in sbbsecho speak) where you can say that the remote is using mailer X so your mailer will use limited/ranged capabilities with the remote when negotiation a connection... in other words, a true/false setting in binkit

if the setting is true, a reduced/chopped CRAM-MD5 is sent otherwise the full form is sent... this is also handy for binkp 1.0 vs 1.1 which IREX has a partial implementation of 1.1, IIRC...

like i say above, i don't know if i agree with it or not but it is a workable idea... it could turn into a selection from a list if more mailers are found to
be flawed in similar fashion...

We just went with the shorter challenge for all links. It's not like this protocol is very secure anyway. :-)

it would be really really really huge if charles were to come back with a fixed
IREX...

If there are other issues with it that I'm not aware of. This one particular flaw isn't really all that critical. Perhaps the FTSC specifications should be updated with a caveat however (e.g. "16-byte CRAM challenges should be sent for maximum binkp-mailer compatiblity"). Right now the specs just saw between 8 and 64 bytes with no direction on what a typical implementation *should* use for a challenge length (hint: it's not 8 and it's not 64!).

digital man

Synchronet/BBS Terminology Definition #57:
XON = Transmit On (ASCII 17, Ctrl-Q)
Norco, CA WX: 66.9oF, 26.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs --- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2018 Mar 07 11:24:20, you wrote to me:

That was a helpful observation.

i'm glad i wrote the post about it... i started not to but then got
curious and ran the grep to see... out of 388450 samples, none were
shorter than 32 characters and only one, the one above, was longer...
kinda makes one wonder "why?" and "what language limitations caused
this?"...

Here's my guess:

It's not a language limitation.

i was thinking of 32bit vs 64bit... old pascal and C stuffings can't do 64bit numbers all that well, what with signed longints and such... i don't know what IREX is written in but i remember trying to do MD5 in TP6 and not having much luck...

Binkd is the reference implementation and likely Irex just followed Binkd's example, which was to send a 16-byte (32-char) CRAM-MD5
challenge - always. Now Binkd will *accept* a longer CRAM-MD5 challege from the binkp-peer (when making outgoing connections), but it'll
never generate one.

yes, i suspect that IREX and others followed binkd... it is the reference, as you say... ISTR charles was on the frontdoor beta team for a while...

So either Irex's binkp implementation was written before any formal specification was published or the author just didn't read the spec
and instead just testd with binkd and only ever *expected* a 16-byte challenge and only used the first 16-bytes (32 hex-chars) when
calculating the HMAC response.

as i recall, there was discussion and folks implementing what was discussed to test and refine it as/before the spec was actually finalized and written... something happened and IREX didn't stay up to date with things...

(aka linked node in sbbsecho speak) where you can say that the remote
is using mailer X so your mailer will use limited/ranged
capabilities with the remote when negotiation a connection... in
other words, a true/false setting in binkit

if the setting is true, a reduced/chopped CRAM-MD5 is sent otherwise
the full form is sent... this is also handy for binkp 1.0 vs 1.1
which IREX has a partial implementation of 1.1, IIRC...

like i say above, i don't know if i agree with it or not but it is a
workable idea... it could turn into a selection from a list if more
mailers are found to be flawed in similar fashion...

We just went with the shorter challenge for all links. It's not like
this protocol is very secure anyway. :-)

there is that but (read on)...

it would be really really really huge if charles were to come back
with a fixed IREX...

If there are other issues with it that I'm not aware of.

i've been trying to remember the other one... IIRC, it is something to do with the turn-around in binkp 1.1... when a batch is sent to the remote, a scan is done to see if new mail has been created... if there is new mail, it goes ahead
and sends it in this session rather than terminating and connecting again... Mystic's author ran into it when he implemented binkp 1.1... so you might want that switch to be able to control this, too... "this" being that with IREX, binkit only does binkp 1.0 with IREX even if it advertises binkp 1.1 capability... that is if/when binkit gets binkp 1.1 capability if it doesn't have it already -=B-)

This one particular flaw isn't really all that critical. Perhaps the
FTSC specifications should be updated with a caveat however (e.g.
"16-byte CRAM challenges should be sent for maximum binkp-mailer compatiblity"). Right now the specs just saw between 8 and 64 bytes
with no direction on what a typical implementation *should* use for a challenge length (hint: it's not 8 and it's not 64!).

yes, it probably should... we (TINW) probably should toss this into the FTSC-PUBLIC echo and see what sticks to the wall :)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... People forget how fast you did a job just how well you did it.
---
* Origin: (1:3634/12.73)

Re: Testing a new mailer (BinkIT)
By: mark lewis to Rob Swindell on Wed Mar 07 2018 03:32 pm

i've been trying to remember the other one... IIRC, it is something to do with the turn-around in binkp 1.1... when a batch is sent to the remote, a scan is done to see if new mail has been created... if there is new mail, it goes ahead
and sends it in this session rather than terminating and connecting again... Mystic's author ran into it when he implemented binkp 1.1... so you might want that switch to be able to control this, too... "this" being that with IREX, binkit only does binkp 1.0 with IREX even if it advertises binkp 1.1 capability... that is if/when binkit gets binkp 1.1 capability if it doesn't have it already -=B-)

Binkit already does BinkP 1.1. I'm not really sure how backward compatible it may or may not be with a strictly 1.0 implementation.

yes, it probably should... we (TINW) probably should toss this into the FTSC-PUBLIC echo and see what sticks to the wall :)

Yeah, "we" should do that. :-)

digital man

This Is Spinal Tap quote #29:
I find lost luggage. I locate mandolin strings in the middle of Austin!
Norco, CA WX: 63.0oF, 36.0% humidity, 4 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2018 Mar 07 18:42:58, you wrote to me:

i've been trying to remember the other one... IIRC, it is something to
do with the turn-around in binkp 1.1... when a batch is sent to the
remote, a scan is done to see if new mail has been created... if there
is new mail, it goes ahead and sends it in this session rather than
terminating and connecting again... Mystic's author ran into it when he
implemented binkp 1.1... so you might want that switch to be able to
control this, too... "this" being that with IREX, binkit only does
binkp 1.0 with IREX even if it advertises binkp 1.1 capability... that
is if/when binkit gets binkp 1.1 capability if it doesn't have it
already -=B-)

Binkit already does BinkP 1.1. I'm not really sure how backward
compatible it may or may not be with a strictly 1.0 implementation.

we haven't gotten to that point yet... max wants to wait a little longer for the dust to settle before updating her SBBS installation to the new stuff...

yes, it probably should... we (TINW) probably should toss this into the
FTSC-PUBLIC echo and see what sticks to the wall :)

Yeah, "we" should do that. :-)

and the first response over there seems to totally miss the point of the post... that's rather normal :rolleyes:

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Walking on water is NOT part of my job description!
---
* Origin: (1:3634/12.73)

Re: Testing a new mailer (BinkIT)
By: mark lewis to Rob Swindell on Thu Mar 08 2018 09:08 am

yes, it probably should... we (TINW) probably should toss this into the
FTSC-PUBLIC echo and see what sticks to the wall :)

Yeah, "we" should do that. :-)

and the first response over there seems to totally miss the point of the post... that's rather normal :rolleyes:

Yup. Could've predicted that. And then he goes on about MD5 collisions. What'evs. :-)

digital man

This Is Spinal Tap quote #19:
Oh then, maybe it's not green. Anyway this is what I sleep in sometimes.
Norco, CA WX: 56.6oF, 48.0% humidity, 0 mph S wind, 0.00 inches rain/24hrs
--- SBBSecho 3.03-Win32
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

On 2018 Mar 08 23:19:08, you wrote to me:

yes, it probably should... we (TINW) probably should toss this into
the FTSC-PUBLIC echo and see what sticks to the wall :)

Yeah, "we" should do that. :-)

and the first response over there seems to totally miss the point of
the post... that's rather normal :rolleyes:

Yup. Could've predicted that. And then he goes on about MD5
collisions. What'evs. :-)

IKR? ROTFL -=B-)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Too many people think a potato tastes like a Pringle.
---
* Origin: (1:3634/12.73)