Hello All,

w.r.t. the embedding of images I actually also consider a variant where the images are included in a more binary-style manner to conserver memory. The idea is, to introduce a Kludge for including Binary attachments directly in the mail similar to MIME but simpler to handle and more space-conserving:

@BIN <filename> <CRC32 in hex> <almost binary data>

Where <almost binary data> uses a simple encoding that essentially aims at avoiding $00, $0d and $0a so the resulting string still forms a valid line of 8-Bit characters. The checksum is also intended to detect any charset violence or 7-Bit fun that might have happend to the message on the way.

Admittedly, I still have the idea to make the most out of the 63k maximum message length I spuspect for unsplit messages. W.r.t. this, the above mechanism actually has the drawback of being incompatible with @SPLIT and this limiting the size of an attachment effectively to one 63k message.

One main benefit here is the space saving compared to base64. THis is a general thing: Do you think base64 (or the like) are still necessary or is betting on 8-bit binary transmission ok?

Regards,
Tim
--- WinPoint 398.3
* Origin: Original WinPoint Origin! (2:240/1120.29)

Tim,

Admittedly, I still have the idea to make the most out of the 63k maximum message length I spuspect for unsplit messages.

I fear a lot of software will barf on 63K messages ...

\%/@rd

--- DB4 - Feb 10 2022
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)

Hello Ward,

On Friday February 11 2022 17:03, you wrote to Tim Schattkowsky:

Admittedly, I still have the idea to make the most out of the 63k
maximum message length I spuspect for unsplit messages.

I fear a lot of software will barf on 63K messages ...

Especially if most of that 63K is only one "line".


Cheers, Michiel

--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

//Hello Ward,//

on *11.02.2022* at *16:03:11* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Re: Directly include binary data in messages"*.

Tim,

Admittedly, I still have the idea to make the most out of the 63k
maximum message length I spuspect for unsplit messages.

I fear a lot of software will barf on 63K messages ...

Okay. So any idea what they might handle. 31k so the integer-heroes dont die on signed offets?

Regards,
Tim
--- WinPoint 398.3
* Origin: Original WinPoint Origin! (2:240/1120.29)

Re: Directly include binary data in messages
By: Tim Schattkowsky to All on Fri Feb 11 2022 03:11 pm

Hello All,

w.r.t. the embedding of images I actually also consider a variant where the images are included in a more binary-style manner to conserver memory. The idea is, to introduce a Kludge for including Binary attachments directly in the mail similar to MIME but simpler to handle and more space-conserving:

@BIN <filename> <CRC32 in hex> <almost binary data>

Control paragraphs should begin with ^A<tag>:
ftsc.org/docs/fts-4000.001

So assuming '@' represents Ctrl-A, that would just mean putting a colon after "BIN". But why "BIN"? Wouldn't "IMAGE" be more approrpriate?

What purpose is the filename? Since you're using space-delimeters for this control paragraph, you couldn't have spaces in the filename unless you had some special escaping or quoting syntax support. I would recommend just eliminating the filename unless it provides some important function.

Is the CRC32 exactly 8 hex digits or not? (i.e. if the first n-hex-digits of the CRC value are 0, are they still included?). I assume you mean the IEEE-802.3 CRC-32 algo/polynominal? There *are* multiple 32-bit CRC algorithms, so it would best to be specific. en.wikipedia.org/wiki/Cyclic_redundancy_check

"<almost binary data>" is encoding what image format? JPEG, GIF, PNG or what? If you want to be flexible, include a mime-type string for the format of the decoded data (e.g. "image/jpeg"). Are you limiting this to bitmap images or are vector graphics (e.g. SVG) okay?

Where <almost binary data> uses a simple encoding that essentially aims at avoiding $00, $0d and $0a so the resulting string still forms a valid line of 8-Bit characters. The checksum is also intended to detect any charset violence or 7-Bit fun that might have happend to the message on the way.

I would go with base64 encoding to reduce interoperability issues.

Admittedly, I still have the idea to make the most out of the 63k maximum message length I spuspect for unsplit messages. W.r.t. this, the above mechanism actually has the drawback of being incompatible with @SPLIT and this limiting the size of an attachment effectively to one 63k message.

Is there really a "63k maximum message length" required by some FTSC standard? SBBSecho definitely doesn't recognize or impose any such limit.

One main benefit here is the space saving compared to base64. THis is a general thing: Do you think base64 (or the like) are still necessary or is betting on 8-bit binary transmission ok?

I could think of all kinds of character sequences that could cause issues with existing software. These issues would be avoided by just using base64-encoding. yEnc is another encoding that's more efficient than base64, but I would just stick with base64 as it's just going to avoid a lot of potential issues from the outset.
--
digital man (rob)

Synchronet/BBS Terminology Definition #41:
IBM = International Business Machines (Corporation)
Norco, CA WX: 84.3°F, 18.0% humidity, 0 mph NE wind, 0.00 inches rain/24hrs

Tim wrote (2022-02-11):

Hello All,

w.r.t. the embedding of images I actually also consider a variant where the images are included in a more binary-style manner to conserver
memory. The idea is, to introduce a Kludge for including Binary attachments directly in the mail similar to MIME but simpler to handle
and more space-conserving:

@BIN <filename> <CRC32 in hex> <almost binary data>

Where <almost binary data> uses a simple encoding that essentially aims
at avoiding $00, $0d and $0a so the resulting string still forms a valid line of 8-Bit characters. The checksum is also intended to detect any charset violence or 7-Bit fun that might have happend to the message on the way.

Hi Tim,

I was to about to reply to your first message with a very similar proposal / idea. I'm glad I didn't and you were faster. Saved me some time, redundant work and doubts to overcome ;-)

I do like the general idea of hiding binary data in kludge lines. I also would prefer ABD (Almost Binary Data) over base64 or other 7-bit encodings. (8-bit) Messages must not be changed or converted in Fidonet.

The biggest question is: would it work with current software?

Potential problems:
- kludge line too long
- tossers
- readers / editors
- message base formats (storage)
- message size too big
- maximum allowed size to small for many regular images / files
- much bigger messages
- only few programs / users can display it
- wasted bandwidth
- wasted hard disk storage
- file size limit of message bases
- gateways / NNTP server
- Internet Mail <-> FTN mail
- some software might barf on 8-bit X-FTN-BIN headers
if not properly escaped and wrapped at 998 chars
- no support for converting @BIN kludge <-> MIME attachment
- (8-bit corruption)


Then there are more general questions:
- will sysops support binaries in mail or is it annoying?
- how to display images in BBS / terminal / TUI


I haven't looked into the potential problems. Maybe we can setup an echo for testing and generate some test messages to see which software can or cannot handle it. Or create a set of VMs (Windows, Linux, DOS (?)) for a network simulation, which could also be useful for future experiments.

My gut feeling is, that it won't work satisfactory in a heterogeneous network with some old software still used on some hubs. Or there is some limitation in one of the message base formats. Or NNTP access / gateways would blow up.

Maybe we are stuck with HTTP URLs in mails and any more ambitious solution would need a new mail format.

---
* Origin: Birds aren't real (2:280/464.47)

On 2022 Feb 11 12:40:24, you wrote to Tim Schattkowsky:

Admittedly, I still have the idea to make the most out of the 63k
maximum message length I spuspect for unsplit messages. W.r.t. this,
the above mechanism actually has the drawback of being incompatible
with @SPLIT and this limiting the size of an attachment effectively
to one 63k message.

Is there really a "63k maximum message length" required by some FTSC standard?

there is not and FTS-0001 even states, in several places, that message bodies are "unbounded"... the limits seen on message bodies have been placed by "lazy coding" and not paging extra data to an overflow disk file during processing...

)\/(ark

"The soul of a small kitten in the body of a mighty dragon. Look on my majesty, ye mighty, and despair! Or bring me catnip. Your choice. Oooh, a shiny thing!"
... SPAM is like a canned luau, the true smell and taste of Aloha.
---
* Origin: (1:3634/12.73)

Hello mark,

On Saturday February 12 2022 07:37, you wrote to Rob Swindell:

Is there really a "63k maximum message length" required by some
FTSC standard?

there is not and FTS-0001 even states, in several places, that message bodies are "unbounded"... the limits seen on message bodies have been placed by "lazy coding" and not paging extra data to an overflow disk
file during processing...

There is theory and there is practice...


Cheers, Michiel
--- GoldED+/W32-MSVC 1.1.5-b20170303
* Origin: http://www.vlist.org (2:280/5555)

//Hello Rob,//

on *11.02.22* at *20:40:25* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Directly include binary data in messages"*.

@BIN <filename> <CRC32 in hex> <almost binary data>

Control paragraphs should begin with ^A<tag>: ftsc.org/docs/fts-4000.001 So assuming '@' represents Ctrl-A, that would just mean putting a colon after "BIN".

It does :)

But why "BIN"? Wouldn't "IMAGE" be more approrpriate?

Because the same mechanics might be employed for embedding arbitrary binary data and might be accompanied by a mechanism for referencing the data in the text (e.g., by file name).

What purpose is the filename?

The same as in MIME and further, if no content-type mechanism is added. In that case, the file extensions may come into play for identifying the file type.

Since you're using space-delimeters for this control paragraph, you couldn't have spaces in the filename unless you had some special escaping or quoting syntax support.

Indeed, could have URL-like encoding.

I would recommend just eliminating the filename unless it provides some important function.

I think it does, e.g., for attaching files.

Is the CRC32 exactly 8 hex digits or not? (i.e. if the first n-hex-digits of the CRC value are 0, are they still included?).

Probably.

I assume you mean the IEEE-802.3 CRC-32 algo/polynominal? There are multiple 32-bit CRC algorithms, so it would best to be specific. en.wikipedia.org/wiki/Cyclic_redundancy_check

Probably.

"<almost binary data>" is encoding what image format?

Thoug I have the application for images in my mind, this idea is about encoding arbitrary binary data. The semantics and further mechanics have to be defined elsewhere.

Where <almost binary data> uses a simple encoding that essentially aims at
avoiding $00, $0d and $0a so the resulting string still forms a valid line
of 8-Bit characters. The checksum is also intended to detect any charset
violence or 7-Bit fun that might have happend to the message on the way.

I would go with base64 encoding to reduce interoperability issues.

Yes and no. We have come a long way in getting rid of the base64 overhead all across the place (think web services) and it feels somewhat dated to still stick to it. Just like XML, it is something you basically don't want to have fresh going into something.

On the other hand, using base64 without MIME feels like going only half the way to doing it just the way we do in Emails. That would at least be compatible with something. However, the main issues I have with this is readability of the message on legacy systems and the size overhead.

Admittedly, I still have the idea to make the most out of the 63k maximum
message length I spuspect for unsplit messages. W.r.t. this, the above
mechanism actually has the drawback of being incompatible with @SPLIT and
this limiting the size of an attachment effectively to one 63k message.

Is there really a "63k maximum message length" required by some FTSC

Nope. It has been around in the past (also as a maximum message length requirement for some echos) simply to save some 16-Bit systems from trouble. Ich checked my only message base (dating back 25 years and including hundreds of thousands of messages) and the largest messages are 63k. These are actualy mostly split longer email messages from an email gateway 15 years ago. However, 63k makes sense at first hand, but surely the whole topic requires testing in both directions because its pure guesswork.

standard? SBBSecho definitely doesn't recognize or impose any such limit.

WinPoint surely doesnt bother as long as you stick below 2GB, which is however probably also the maximum size of the message base file for an area ;)

One main benefit here is the space saving compared to base64. THis is a
general thing: Do you think base64 (or the like) are still necessary or is
betting on 8-bit binary transmission ok?

I could think of all kinds of character sequences that could cause issues with existing software.

I doubt it. If anything causes trouble in the middle of the line that software should not exist. Can you give a plausible example?

These issues would be avoided by just using
base64-encoding. yEnc is another encoding that's more efficient than base64, but I would just stick with base64 as it's just going to avoid a lot of potential issues from the outset.

Doing anything beyond base64 actually eventually means to go beyond compatibility anyway.

Regards,
Tim
--- WinPoint 399.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

Re: Re: Directly include binary data in messages
By: Tim Schattkowsky to Rob Swindell on Sat Feb 12 2022 03:09 pm

I could think of all kinds of character sequences that could cause issues with existing software.

I doubt it. If anything causes trouble in the middle of the line that software should not exist. Can you give a plausible example?

Sure, line-feed (ASCII 10) characters can be stripped by receiving software. The charcter sequence "<ESC>[" can be stripped or transposed by receiving software.
Characters beyond ASCII 127 may be transposed by receiving software (e.g. converted to UTF-8 equivalent sequences).
The ASCII character sequences "--- ", " * Origin", the like may be transposed or incorrectly parsed by receiving software.

These are all just theoretical issues, but my experience says that some or all (and more) of these issues would likely arise if not immediately, eventually, by some receiving software that some FidoNet node would like to continue to use. And you could avoid them all from the outset by using Base64 encoding.
--
digital man (rob)

This Is Spinal Tap quote #36:
Bobbi Flekman: Money talks, and bullshit walks.
Norco, CA WX: 84.2°F, 11.0% humidity, 6 mph E wind, 0.00 inches rain/24hrs

Re: Re: Directly include binary data in messages
By: Tim Schattkowsky to Rob Swindell on Sat Feb 12 2022 03:09 pm

What purpose is the filename?

The same as in MIME and further, if no content-type mechanism is added. In that case, the file extensions may come into play for identifying the file type.

MIME includes a standardized type value that is non-ambiguous for a reason: filenames are not the best methods for determining a file's content type. Is it .jpeg, .JPEG, .jpg, .jpe, .jfif, or .jif? All of these are valid JPEG file extensions, but there's only *one* corresponding MIME-type (aka Internet media type): image/jpeg.
--
digital man (rob)

Rush quote #46:
One day I feel I'm on top of the world, and the next it's falling in on me Norco, CA WX: 84.2°F, 11.0% humidity, 6 mph E wind, 0.00 inches rain/24hrs

//Hello Rob,//

on *12.02.22* at *20:10:52* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Re: Directly include binary data in messages"*.

MIME includes a standardized type value that is non-ambiguous for a

I know. Still not related to your main point, that there should be no file name ;)

reason: filenames are not the best methods for determining a file's content type. Is it .jpeg, .JPEG, .jpg, .jpe, .jfif, or .jif? All of
these are valid JPEG file extensions, but there's only one corresponding MIME-type (aka Internet media type): image/jpeg.

From the past when I was implementing (among many other things) a web server, I also know that this is in fact not fully true because there are also a lot of ambiguities when it comes to MIME types in the real world.

Here, the clear intention would be to either go with the existing standards (maybe pick a subset) or do something very simple. The thing is, that using existing standards, DOS-based software will be practically not able to include such functionality as library support does not exist (for obvoious reasons) and MIME handling alone can easily be mode code that a whole simple approach to the problem.

Also, I am not sure that we really want to essentially deliver HTML email with embedded pictures over fido.

Regards,
Tim
--- WinPoint 399.1
* Origin: Original WinPoint Origin! (2:240/1120.29)

Re: Re^2: Directly include binary data in messages
By: Tim Schattkowsky to Rob Swindell on Sat Feb 12 2022 09:58 pm

//Hello Rob,//

on *12.02.22* at *20:10:52* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Re: Directly include binary data in messages"*.

MIME includes a standardized type value that is non-ambiguous for a

I know. Still not related to your main point, that there should be no file name ;)

I asked what the value of the filename was, and you said to determine the content-format of the <almost-binary-data>. I'm saying there's a better way to do that: standard mime/media types.

So... the other reason to have a filename would be to suggest a filename for the local storage system (e.g. if the reader wanted to extract the file from the message)? If that's the case, then I would propose a better tag for your control paragraph would be FILE, e.g.

<SOH>FILE: <name> <crc> <data>

But if you want message viewers to be able to potentially nicely handle (e.g. display) the content, then I would definitely suggest adding the mime/media type value as well. e.g.

<SOH>FILE: <name> <type> <crc> <data>

reason: filenames are not the best methods for determining a file's content type. Is it .jpeg, .JPEG, .jpg, .jpe, .jfif, or .jif? All of these are valid JPEG file extensions, but there's only one corresponding MIME-type (aka Internet media type): image/jpeg.

From the past when I was implementing (among many other things) a web server, I also know that this is in fact not fully true because there are also a lot of ambiguities when it comes to MIME types in the real world.

No ambiguities with the main/popular types and much *less* ambiguity than with filenames, for all media types.

Here, the clear intention would be to either go with the existing standards (maybe pick a subset) or do something very simple. The thing is, that using existing standards, DOS-based software will be practically not able to include such functionality as library support does not exist (for obvoious reasons) and MIME handling alone can easily be mode code that a whole simple approach to the problem.

I think you're depending on DOS-based software to most likely just ignore/skip-past this new control paragraph. So it doesn't really matter its format/content, so long as it is very backwards-compatible.

Also, I am not sure that we really want to essentially deliver HTML email with embedded pictures over fido.

I didn't mention HTML. I was just suggesting that if you want to insure compatibility with all existing standards-compliant FidoNet software, to use only US-ASCII non-control characters in your <almost-binary-data> encoding (base64 being the obvious best practice for this type of encoding). Whether or not DOS-based software has a base64 decoding library is pretty irrelevant. The critical thing is that it doesn't choke on a message or a packet due to the existance of your proposed/new control paragraph.
--
digital man (rob)

This Is Spinal Tap quote #41:
Ian Faith: It say's "Memphis show cancelled due to lack of advertising funds." Norco, CA WX: 86.4°F, 10.0% humidity, 4 mph SW wind, 0.00 inches rain/24hrs

Tim wrote (2022-02-11):

Hello All,

w.r.t. the embedding of images I actually also consider a variant where the images are included in a more binary-style manner to conserver
memory. The idea is, to introduce a Kludge for including Binary attachments directly in the mail similar to MIME but simpler to handle
and more space-conserving:

@BIN <filename> <CRC32 in hex> <almost binary data>

Where <almost binary data> uses a simple encoding that essentially aims
at avoiding $00, $0d and $0a so the resulting string still forms a valid line of 8-Bit characters. The checksum is also intended to detect any charset violence or 7-Bit fun that might have happend to the message on the way.

The JAM specification limits the length of and "FTSKLUDGE" to 255 bytes. It also would put the @BIN data in the .JHR file. JAM is not an "official" standard, but unfortunately half of Fidonet is based on this quirky format. (The specification is well written and easy to understand, but I never liked the way it separates header and kludge lines from the message body).

I have no idea how the different implementations would handle long (>255) kludge lines.

Quote from the spec:

The SubField structure is made up of an ID, a length specifier, and
a block of data. Zero or more subfields may follow the fixed-length
binary header. SubFields are not stored in any specific order and
are not terminated by any specific character unless otherwise
specified.

SubField:
ushort LoID; // Field ID, 0-65535
ushort HiID; // Reserved for future use
ulong datlen; // Length of buffer that follows
uchar Buffer[datlen]; // DATLEN bytes of data
end;

---------------------------------------------------------------------
Defined LoID codes
---------------------------------------------------------------------
[...]

ID=2000, Name=FTSKLUDGE

An FTS-compliant "kludge" line not otherwise represented here. All
data not relevant to the actual kludge line, including leading and
trailing white space and ^A (01H) characters should be removed.
DATLEN must not exceed 255 characters. The FTS kludges INTL, TOPT,
and FMPT must never be stored as separate SubFields. Their data must
be extracted and used for the address SubFields.

---
* Origin: Birds aren't real (2:280/464.47)

//Hello Oli,//

on *13.02.22* at *10:45:50* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Directly include binary data in messages"*.

The JAM specification limits the length of and "FTSKLUDGE" to 255 bytes.
It also would put the @BIN data in the .JHR file. JAM is not an "official" standard, but unfortunately half of Fidonet is based on this quirky
format. (The specification is well written and easy to understand, but I never liked the way it separates header and kludge lines from the message body).

I have no idea how the different implementations would handle long (>255) kludge lines.

Ouch, that is really nasty. It is always suprising how some things can also be implemented.

I already considered using a *combination of multiple Kludge lines* where each<256 Bytes (thinking of old school string handling) instead of producing one very long line. However, this would at least increase the overhead. Also in this case, it seems that the order of kludges is not preserved, so each line has to include something like a sequence number as well and even an object reference to distinguish between different binary objects in the same message.

Just walking that path (for the fun of it), *one could do something like*

@BLOB: <ID> <filename> <filesize> <CRC32>
@DATA: <ID> <Offset> <encoded binary data>
...
@DATA: <ID> <Offset> <encoded binary data>

Where ID,Filesize, Offset and CRC32 are 8 digit hex numbers. Filenames might be encoded in some way to allow for spaces (e.g., URL-Encoded UTF-8). The data chunks can be recombined to the original data.

The @DATA:-Lines may be of variable length and could easily be limited to at total of 255 chars. That would result in 234 chars encoded payload (assuming I am right and leaving place fuer a CRLF just in case) resulting in an overhead of ~10% compared to the 33% overhead of just using Base64. If that makes it worth it is subject to discussion as well as what the actualy encoding could be.

Mechanics may be:
1. find BLOB and allocate buffer
2. write all binary data chunks to buffer at defined offsets
3. verify chechksum to validate result
4. provide file

The *resulting file may (similar to MIME) service different purposes like being a simple binary attachment or an image referenced in the text* (e.g., by filename in an HTML mail).

There are actually *good reasons for readers to decode files to the file system* even for message display. This way, antivirus software gets a chance to scan the file and COTS for displaying file-based images or HTML off a folder can be employed if needed.

Essentially, this could be a way of *achieving something similar to multipart MIME without its overhead* and without it the resulting tool support in some places that currently probably don't care about fido anyway.

Still, I am particularly *worried about compatibility with message transport* and processing (also on gateways) and the the potential gain in storage efficiency is quite limited, which for me still makes *using a well-defined subset of MIME with Base64 more attractive* as it is likely to cause no issues on the way and may still provide limited readability on legacy systems.

Whether or not such mails might also *include HTML instead of plain text is IMHO a related but different debate*. I would tend to say for now, we are happy get a way of including images/binary data at all.

Regards,
Tim
--- WinPoint 399.1
* Origin: Original WinPoint Origin! (2:240/1120.29)

Tim wrote (2022-02-14):

//Hello Oli,//

on *13.02.22* at *10:45:50* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Directly include binary data in messages"*.

The JAM specification limits the length of and "FTSKLUDGE" to 255
bytes.

[...]

I have no idea how the different implementations would handle long

255) kludge lines.

Ouch, that is really nasty. It is always suprising how some things can also be implemented.

I already considered using a *combination of multiple Kludge lines* where each<256 Bytes (thinking of old school string handling) instead of producing one very long line.

[...]

Just walking that path (for the fun of it), *one could do something like*

@BLOB: <ID> <filename> <filesize> <CRC32>
@DATA: <ID> <Offset> <encoded binary data>
..
@DATA: <ID> <Offset> <encoded binary data>

Crashmail II truncates the FTSKLUDGE field at 100 chars, if I understand the C code correctly. I wouldn't mind fixing my local Crashmail tosser, but upgrading the Windows version or getting it in Debian is another thing.

Why not use a variation of yEnc now and then develop a modern (but still simple and easy to parse) message format for FTN? Or how many workarounds on top of workarounds we you want to put on the FTS-1 message format? I don't think there is much that can be done without breaking compatibility somewhere. That is what you get, if the organization for standardization only documents workarounds and hacks years or decades later instead of deliberately developing standards in the open. (The advantage is, that it is still a very simple format in comparison to Internet Mail).

---
* Origin: Birds aren't real (2:280/464.47)

//Hello Oli,//

on *15.02.22* at *11:55:18* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Directly include binary data in messages"*.

Just walking that path (for the fun of it), one could do something like

@BLOB: <ID> <filename> <filesize> <CRC32>
@DATA: <ID> <Offset> <encoded binary data>
..
@DATA: <ID> <Offset> <encoded binary data>

Crashmail II truncates the FTSKLUDGE field at 100 chars, if I understand the C code correctly. I wouldn't mind fixing my local Crashmail tosser,
but upgrading the Windows version or getting it in Debian is another
thing.

One could do 80 character lines to be on the ridicously safe side.

Why not use a variation of yEnc now and then develop a modern (but still simple and easy to parse) message format for FTN?

I think we can very well separate the payload from the message format in this discussion as long as we stick to a certain baseline. Wheter or not this baseline includes trust in 8-Bit transport as the de-facto standard is debatable, but might not be the deal breaker.

Or how many workarounds on top of workarounds we you want to put on the FTS-1 message format?

While there are a lot of shortcomings in FTS-1, I have doubt that breaking compatibility with the standard message format is a good idea since the few existing systems today still seem to use quite heterogeneous software configuration also on sometimes exotic operating systems that need to be kept interoperable. I think this is causing more problems than it solves.

I don't think there is much that can be done without breaking compatibility somewhere.

Depending. I would say, that using Email-style MIME would basically solve the thing and is a simple counterexample to your assertion. Actually, it has been in heavy use during the early years of the millenium (as fido email gatways where popular), but with limited to non-existent client support. I still store tens of thousands of such gated emails that all look ok to me. Some of the have been @SPLIT-victims, but look fine (for recombination).

I would also like to point out, that any discussion about message length is clearly misleading in this context as the current standard ist not limiting message length and citing actualy implementation shortcomings is no argument for overriding the standard, as any new standard would require new implementations anyway. So it is much simpler to say, that this time we actually MEAN that messages may be of arbitrary length, which in reality means that systems should be prepared at least for messages in the 10MB-range just like typical email severs are.

That is what you get, if the organization for standardization
only documents workarounds and hacks years or decades later instead of deliberately developing standards in the open. (The advantage is, that it is still a very simple format in comparison to Internet Mail).

While I agree with your dissatisfaction, I still think this is just managing the reality. Since there is only limited (if at all) maintennance for the software in use, any radical change needs to be backed by enough developers to keep everybody connected.

This brings us to an interesting point: interoperability between any old and new standard will probably be non-trivial, if the new standard adds significant new capabilities. However, if it does not, there is no good reason to introduce it!

Dont get me wrong. *I love the idea of getting rid of FTS-1*, but it is much easier to come up with a new message format idea than to actually implemented such a transition in the field. For now, I think the basic transport is operational and we should concentrate on the payload.

I think the major points are
- message size limitations
- line size limitations
- 8-Bit transport
- integrity of white space and control characters in messages (CR,LF,$9,ESC, ...)

For the latter, I really think we might give a try and see what happens. Any message format on top of FTS-1 can still add simple error detection to ensure message integrety und otherwise assume binary correct (or yenc-level) transport of content in non-kludge lines of a limited length as a baseline.

Regards,
Tim
--- WinPoint 399.2
* Origin: Original WinPoint Origin! (2:240/1120.29)

Am 15.02.22 schrieb Tim Schattkowsky@2:240/1120.29 in FTSC_PUBLIC:

Hallo Tim,

Dont get me wrong. *I love the idea of getting rid of FTS-1*, but it is much easier to come up with a new message format idea than to actually implemented such a transition in the field. For now, I think the basic transport is operational and we should concentrate on the payload.

Just a small idea concerning compatibility:

If there would be something like a replacement of FTS-1 (I would call
it FTS-2 - I hope this name isn't already taken), this would imply
that all software which handles mails would have to be adapted.

Could it be an option to make this software capable of accepting links
with old software, and convert (gate?) messages between FTS-1 and
FTS-2, so that users with retro software could still take part in the
net, just without some new-fangled stuff?
This would make it neccessary that all backbone/fidoweb/whatever-it-
is-called systems and other uplinks use software that is compatible
with FTS-1 and FTS-2 so that everyone could get a full feed.

Regards,
Anna

--- OpenXP 5.0.51
* Origin: Imzadi Box Point (2:240/5824.1)

Hi!

16 Feb 22 16:45, Anna wrote to Tim Schattkowsky:

Am 15.02.22 schrieb Tim Schattkowsky@2:240/1120.29 in FTSC_PUBLIC:

Hallo Tim,

Dont get me wrong. *I love the idea of getting rid of FTS-1*, but
it is much easier to come up with a new message format idea than
to actually implemented such a transition in the field. For now, I
think the basic transport is operational and we should concentrate
on the payload.

Just a small idea concerning compatibility:

If there would be something like a replacement of FTS-1 (I would call
it FTS-2 - I hope this name isn't already taken), this would imply
that all software which handles mails would have to be adapted.

Could it be an option to make this software capable of accepting links
with old software, and convert (gate?) messages between FTS-1
and FTS-2, so that users with retro software could still take part in
the net, just without some new-fangled stuff? This would make it neccessary that all backbone/fidoweb/whatever-it- is-called systems
and other uplinks use software that is compatible with FTS-1 and
FTS-2 so that everyone could get a full feed.

Just going along that line, but without rewriting FTS-1, or using the idea as a gating method from the new FTS to FTS-1:

We do have mails and we do have files. Both we can send quite fine currently (with the known limitations). How about working with "file areas" going parallel to the message areas holding files being referenced in the message areas? Same would work with netmails.
In this case you would just need a kludge linking one or multiple files and the editors, tossers, etc. supporting these method on the sending end need to handle the link between both correctly and incorporate the files with tics to the outbound, but no need to change mailers or any software on the receiving end (except an reader to know how to show the file links) or intermediate systems.
All old software (or maybe text-only editors) would either not recognize the attachment at all, or could provide just a (local) link to the attached file. If the file link is provided with a plain text mark in the message content, too, even those systems would work, but the user has to go manually looking for the file in the corresponding "file area".

Biggest issue with this would be routing of private files (attached to netmails), I think. Without consulting the docs I think that is non-default behaviour currently to route private files. But it would just need a change of handling, not of the protocol used.

Regards,
Anna

Regards,
Joachim


--- GoldED+/LNX 1.1.5--b20170303
* Origin: ----> FidoPI (2:240/6309)

Anna,

This would make it neccessary that all backbone/fidoweb/whatever-it- is-called systems and other uplinks use software that is compatible
with FTS-1 and FTS-2 so that everyone could get a full feed.

It is imperative to keep thinking and come-up with new ideas. Along the lines it is equally necessary to grasp which proposals stand no chance of making it and move-on without wasting too much time.

Change/evolution in Fidonet has only happened when "someone did it". So, are you available to work on this, not just propose it, take all the blame and see marc lewis take all the credit?

\%/@rd

--- DB4 - Feb 12 2022
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)

Am 17.02.22 schrieb Joachim Probst@2:240/6309 in FTSC_PUBLIC:

Hallo Joachim,

Just going along that line, but without rewriting FTS-1, or using the idea as a gating method from the new FTS to FTS-1:

We do have mails and we do have files. [...]

I like that idea. What do the software developers, like Rob or Tim,
think of that?

Regards,
Anna

--- OpenXP 5.0.51
* Origin: Imzadi Box Point (2:240/5824.1)

Am 17.02.22 schrieb Ward Dossche@2:292/854 in FTSC_PUBLIC:

Hallo Ward,

[...]

Change/evolution in Fidonet has only happened when "someone did it". So, are you available to work on this, not just propose it, take all the blame and see marc lewis take all the credit?

I know that 'someone has to do it'. And I'm no good software developer (concerning FTN software, I only added some functions to HatchIT, the hatching software of Synchronet), so I'm not available for such big
projects.

I thought that while the people who do write good software (like Rob
or Tim) are currently talking about this topic, I could add an idea to
that topic.

But as it doesn't seem to be appropriate to take part in such a
conversation without developing myself, I will leave this discussion
now.
Thank you for your reminder that this network is not the most
welcoming one.

Regards,
Anna

--- OpenXP 5.0.51
* Origin: Imzadi Box Point (2:240/5824.1)

Hello Anna,

Change/evolution in Fidonet has only happened when "someone did it". AC>WD> So, are you available to work on this, not just propose it, take all AC>WD> the blame and see marc lewis take all the credit?

Thank you for your reminder that this network is not the most
welcoming one.

Where have you read something negative in my words above? It's just an absolute fact without any negative connotation ... Change only happens because someone makes it happen ... if something's good, it will be picked-up by others; if it sucks...well...then it sucks.

If you read something else in there, you will need to make clear what you "interpreted" what I wrote because my text is |absolute|.

Take care,

\%/@rd

--- DB4 - Feb 20 2022
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)

Re: Re: Directly include binary data in messages
By: Anna Christina Nass to Joachim Probst on Tue Feb 22 2022 12:18 pm

Am 17.02.22 schrieb Joachim Probst@2:240/6309 in FTSC_PUBLIC:

Hallo Joachim,

Just going along that line, but without rewriting FTS-1, or using the idea as a gating method from the new FTS to FTS-1:

We do have mails and we do have files. [...]

I like that idea. What do the software developers, like Rob or Tim,
think of that?

Pretty trivial. In fact, any echomail program that supports multiple packet formats (e.g. SBBSecho supports packet types 2.0, 2+, 2e, and 2.2) can be used as a gateway between old and even older technology systems. :-)
--
digital man (rob)

Synchronet/BBS Terminology Definition #6:
BBS = Bulletin Board System
Norco, CA WX: 54.7°F, 57.0% humidity, 2 mph ESE wind, 0.00 inches rain/24hrs

//Hello Anna,//

on *22.02.22* at *11:22:00* You wrote in Area *FTSC_PUBLIC*
to *Ward Dossche* about *"Re: Directly include binary data in messages"*.

I thought that while the people who do write good software (like Rob or Tim) are currently talking about this topic, I could add an idea to that topic.

Actually I appreciate and share your idea, but I am currently not certain about the technical implications. Needs a while to digest and get comfortable with / or find reasons why this wont work (I have some candidates).

Regards,
Tim

--- WinPoint 400.2
* Origin: Original WinPoint Origin! (2:240/1120.29)

//Hello Rob,//

on *22.02.22* at *19:22:28* You wrote in Area *FTSC_PUBLIC*
to *Anna Christina Nass* about *"Re: Directly include binary data in messages"*.

Pretty trivial. In fact, any echomail program that supports multiple packet formats (e.g. SBBSecho supports packet types 2.0, 2+, 2e, and 2.2) can be used as a gateway between old and even older technology systems. :-)

IMHO this is lacking the total system perspective. There are open questions at that level. How is the sending system supposed to know what packet format a receiver expects?

This could be done in a lot of ways:
- explicit configuration
- nodelist flags
- dynamically during the mail session (i.e., the mailer eventually triggers the final packet format in some way depending on session handshake information)
- ...

The most important question for me is still, WHY is there any need for a new packet format? Other than the lack of zone (or even 5D) information, what are the points?

Regards,
Tim

--- WinPoint 400.2
* Origin: Original WinPoint Origin! (2:240/1120.29)

Re: Re^2: Directly include binary data in messages
By: Tim Schattkowsky to Rob Swindell on Tue Feb 22 2022 09:55 pm

//Hello Rob,//

on *22.02.22* at *19:22:28* You wrote in Area *FTSC_PUBLIC*
to *Anna Christina Nass* about *"Re: Directly include binary data in messages"*.

Pretty trivial. In fact, any echomail program that supports multiple packet formats (e.g. SBBSecho supports packet types 2.0, 2+, 2e, and 2.2) can be used as a gateway between old and even older technology systems. :-)

IMHO this is lacking the total system perspective. There are open questions at that level. How is the sending system supposed to know what packet format a receiver expects?

In SBBSecho, each link can be configured with a preferred packet format. Of course, that only works for explicitly-configured links. Otherwise, it just defaults to stone-age type 2 packet generation.

This could be done in a lot of ways:
- explicit configuration
- nodelist flags
- dynamically during the mail session (i.e., the mailer eventually triggers the final packet format in some way depending on session handshake information)
- ...

The most important question for me is still, WHY is there any need for a new packet format? Other than the lack of zone (or even 5D) information, what are the points?

<shrug> I'm not saying there is a need. I can theorize packet and packed-message header improvements all day long, but I don't know if that means there's a factual "need".
--
digital man (rob)

Sling Blade quote #19:
Doyle: I can't so much as drink a damn glass of water around a midget
Norco, CA WX: 53.5°F, 66.0% humidity, 5 mph SSE wind, 0.00 inches rain/24hrs

Hey Tim!

WHY is there any need for a new packet format?

There isn't and wasn't.

Other than the lack of zone (or even 5D) information, what are
the points?

It depends totally on the bossnode. I have successfully sent the type 2 pkts from a point to a suitable bossnode that knows what it's doing. If anything the pktHeader - no matter which type - acts more like drag on systems rather than providing any useable data worth the effort of extracting it. There are much better ways methinks.

Life is good,
Maurice

... Ne læt ðin ellen nu gyt gedreosan to dæge.
Do not now allow your courage to fail on this day.
--- GNU bash, version 5.1.16(1)-release (x86_64-moosile-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

//Hello Maurice,//

on *23.02.2022* at *9:37:29* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Re^2: Directly include binary data in messages"*.

WHY is there any need for a new packet format?

There isn't and wasn't.

Ok, seems we all agree here.

So while I enjoy the discussion, it seems really more benefitial to talk about actually advancing the functionality of fidonet to keep it sort of relevant compared to other platforms. IMHO, fidonet eventually has to some extent to compare to social media platforms and particularly to reddit, as reddit seems to do for a lot of people what fido did for them in the past. And no, I certainly see no way of competing with such platforms and surely thats not the intent here. Still, each user compares the provided capabilites and that is where I see fundamental technical shortcomings.

It is my belief (in line with some of the points brought up recently), that the fidonet infratstucture should be improved (also on the software side) to
- make large messages (in the order of magnitude of up to a few MB) a non-issue for most users,
- enable embedding of images and (small) binary data in messages in a compatible way,

and later on

- enable private communication between endpoints (i.e., encrypted authenticated netmail)
- maybe support (well-defined?) HTML mail (quite debateable) or the like

Regards,
Tim

--- WinPoint 400.3
* Origin: Original WinPoint Origin! (2:240/1120.29)

Hi Tim,

On 2022-02-24 13:15:02, you wrote to Maurice Kinal:

It is my belief (in line with some of the points brought up recently), that the fidonet infratstucture should be improved (also on the
software side) to

- make large messages (in the order of magnitude of up to a few MB) a non-issue for most users,

- enable embedding of images and (small) binary data in messages in a compatible way,

and later on

- enable private communication between endpoints (i.e., encrypted authenticated netmail)

- maybe support (well-defined?) HTML mail (quite debateable) or the
like

This already exists. It's called email. ;)

Bye, Wilfred.

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

Hi Tim!

24 Feb 2022 13:15, from Tim Schattkowsky -> Maurice Kinal:

- enable private communication between endpoints (i.e., encrypted authenticated netmail)

That can be done by the use of GPG (or PGP).

This is for example the way used by the big german E-Mail provider gmx.de

Golded supports this by using GPG externally:

EXTERNOPTIONS -pauseonerror -nokeepctrl -wipe
EXTERNUTIL 1 gpg +force -sa @tmpfile -u "@oname" -o @file ;sign
EXTERNUTIL 2 gpg +force -ea @tmpfile "@dname" -u "@oname" -o @file ;encrypt
EXTERNUTIL 3 gpg +force -eas @tmpfile "@dname" -u "@oname" -o @file ;enc & sign
EXTERNUTIL 4 -pause gpg +force @tmpfile -o @file -u "@dname" ;decrypt
EXTERNUTIL 5 -noreload gpg +force -ka @file -u "@dname" ;add key
EXTERNUTIL 6 c:\fido\golded\mykey.bat @file ;add mykey

EDITSAVEUTIL 1 "S PGP Sign the msg"
EDITSAVEUTIL 2 "E PGP Encrypt the msg"
EDITSAVEUTIL 3 "Y PGP EncrYpt & Sign the msg"
EDITSAVEUTIL 6 "M add My PGP key"

CU, Ricsi

... In its natural state, tofu is good for minor driveway repairs.
--- GoldED+/LNX
* Origin: Don't use time or words carelessly! (2:310/31)

//Hello Wilfred,//

on *24.02.2022* at *12:32:20* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Re^3: Directly include binary data in messages"*.

It is my belief (in line with some of the points brought up recently),
that the fidonet infratstucture should be improved (also on the software
side) to

- make large messages (in the order of magnitude of up to a few MB) a
non-issue for most users,

- enable embedding of images and (small) binary data in messages in a
compatible way,

and later on

- enable private communication between endpoints (i.e., encrypted
authenticated netmail)

- maybe support (well-defined?) HTML mail (quite debateable) or the
like

This already exists. It's called email. ;)

Fully agree, but that probably wont help fidonet users (other than moving them away). It might make sense to consistently apply exactly these technologies (MIME messages with HTML text, encryption ...) also for fidonet, in particular also for improving echo mail capabilities.

For private messages, there is little sense in competing with email. Surely fidonet netmail is not going to replace email during the next 5 years. However, it makes a lot of sense to provide comparable capabilities just to enable users to make consistent use of netmail and echomail while having basic capabilities that are just not worse than email 20 years ago. Currently thats not remotely the case.

Regards,
Tim

--- WinPoint 400.3
* Origin: Original WinPoint Origin! (2:240/1120.29)

Tim,

It is my belief (in line with some of the points brought up recently),
that the fidonet infratstucture should be improved (also on the software side) to
- make large messages (in the order of magnitude of up to a few MB) a non-issue for most users,
- enable embedding of images and (small) binary data in messages in a compatible way,

Hmmmmm ... would a totally different zone help? Even just as a test-platform?

\%/@rd

--- DB4 - 20220222
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)

Hey Tim!

Ok, seems we all agree here.

That isn't the problem. The problem is getting things done.

Anyhow you have interesting ideas that probably don't require many, if any, changes to existing standards in order to be successful.

Life is good,
Maurice

... Eþel byþ oferleof æghwylcum men.
Home is very dear to every man.
--- GNU bash, version 5.1.16(1)-release (x86_64-moosile-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Ward!

Hmmmmm ... would a totally different zone help? Even just as a test-platform?

I seem to recall something like that being proposed back in the late 1990's in order to facillitate the new-fangled ip based nodes. Later the idea was to give all ip nodes their own zone. To be honest I am glad that never happened. A test zone might be something worth investigation but given the numbers I think it would be wise to stick together as much as possible.

Life is good,
Maurice

... It comes in, it must go out.
- Teslacle's Deviant to Fudd's Law.
--- GNU bash, version 5.1.16(1)-release (x86_64-moosile-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Maurice,

Hmmmmm ... would a totally different zone help? Even just as a
test-platform?

I seem to recall something like that being proposed back in the late
1990's in order to facillitate the new-fangled ip based nodes.

I don't think I was involved in that...

\%/@rd

--- DB4 - 20220222
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)

//Hello Maurice,//

on *24.02.22* at *16:06:18* You wrote in Area *FTSC_PUBLIC*
to *Ward Dossche* about *"Re^3: Directly include binary data in messages"*.

A test zone might be something worth investigation
but given the numbers I think it would be wise to stick together as much as possible.

That is a valid point at least when actually introducing that technology in the field. It might still be of value to have a small test zone for validation before. But that is something that can be seen clearer, when we know how the system works.

Regards,
Tim

--- WinPoint 400.3
* Origin: Original WinPoint Origin! (2:240/1120.29)

For private messages, there is little sense in competing with email. Surely fidonet netmail is not going to replace email during the next 5 years. However, it makes a lot of sense to provide comparable
capabilities just to enable users to make consistent use of netmail and echomail while having basic capabilities that are just not worse than email 20 years ago. Currently thats not remotely the case.

We do have some additional security being used today, some of which could be refined and adopted. Between you, Rob, and I we have a substancial user base that gives us the power to create positive change.

Synchronet and Mystic support direct BINKP over SSL natively which is a good start to securing transmission. At one point I had a opportunistic SSL version of BinkP as well.

Of course SSL doesn't stop routed netmail from being read by a SysOp in the middle though, so in this case Mystic does AES-256 encrypted netmail if its setup with an encryption key for the address being netmailed.

... Kilometers are shorter than miles. Save gas, take your trip in kilometers

--- Mystic BBS v1.12 A48 2022/02/17 (Windows/32)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Hello Tim!

24 Feb 22 15:19, you wrote to Wilfred van Velzen:

For private messages, there is little sense in competing with email. Surely fidonet netmail is not going to replace email during the next 5 years. However, it makes a lot of sense to provide comparable capabilities just to enable users to make consistent use of netmail and echomail while having basic capabilities that are just not worse than email 20 years ago. Currently thats not remotely the case.

E-mail has not changed either in te last 20 years. The only thing that has
changed are the user clients that can now display mime encapsulated messages.

Designing a different way of encapsulation for fidonet is hardly productive.
Mime encapsulation is not hostile to the content section of fidonet messages.

No changes have to have to be made to Fidonet. The only changes
are at the presentation layer, wich is not subject to fidonet standards.

Kees

--- GoldED+/LNX 1.1.5--b20180707
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Hey Ward!

I don't think I was involved in that...

I forget now who spearheaded the ip fidonet stuff but he was definetly European with a Zone 2 address. mark might have a better memory of this.

Life is good,
Maurice

... Getreowan freond... deorweorðeste ðyng eallra þissa woruldgesælþa.
True friends are the most precious of all this world's joys.
--- GNU bash, version 5.1.16(1)-release (x86_64-moosile-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Maurice,

I don't think I was involved in that...

I forget now who spearheaded the ip fidonet stuff but he was definetly European with a Zone 2 address.

That seems to be correct, someone (but I forgot who) briefed me on discussions that were had in an ad-hoc workgroup and IP-flags were introduced on Nov 11 1998.

Somewhere on the internet you can read a text by David Moufarrege, and I really can't believe he actually wrote it himself:

"My thanks go to Bob Satti and Ward Dossche - for having the vision to
permit and promote the use of IP - Mailers, Flags and Nodelist entries in
their respective zones."

Bob was actually against it and wanted Fido to remain PSTN-only. He was pretty pissed when I facilitated those flags in the nodelist and had no option but jump on the bandwagon.

\%/@rd

--- DB4 - 20220222
* Origin: Hou het veilig, hou vol. Het komt allemaal weer goed (2:292/854)

Hey Ward!

an ad-hoc workgroup and IP-flags were introduced on Nov 11 1998.

That all sounds familiar.

He was pretty pissed when I facilitated those flags in the
nodelist

Them were the days. You were such a badass. What happened?

Life is good,
Maurice

... Seoc se biþ þe to seldan ieteð.
The one who eats too seldom will be sick.
--- GNU bash, version 5.1.16(1)-release (x86_64-moosile-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Good ${greeting_time}, James!

24 Feb 2022 12:01:32, you wrote to Tim Schattkowsky:

Synchronet and Mystic support direct BINKP over SSL natively which
is a good start to securing transmission.

It's the most stupid thing that could be done.

The SSL was good 15...20 years ago, but now it doesn't conform to modern requirements. Also, it is almost useless in a peer-to-peer environment.

Of course SSL doesn't stop routed netmail from being read by a SysOp
in the middle though, so in this case Mystic does AES-256 encrypted

Rijndael? Bwa-ha-ha-ha...

Using the artifically weakened cryptography is a very, very unwise idea.

netmail if its setup with an encryption key for the address being netmailed.

If you want to secure the messages, use GPG: although it also has similar problems with cryptographic strength, the bundle of RSA-4096, SHA2-256 and Twofish-256 still may be considered safe enough.

For securing the communications (binkd does that for years, and only my resignment from FTSC had stopped promoting that to a standard) some other techniques had been invented and implemented. And the most funny thing is implementing your "binkp+SSL" setup with binkd would require just a small editing of the config file.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... :wq!
--- /bin/vi
* Origin: ::1 (2:5020/545)

Synchronet and Mystic support direct BINKP over SSL natively which
is a good start to securing transmission.

It's the most stupid thing that could be done.

The SSL was good 15...20 years ago, but now it doesn't conform to modern

Okay so tell me what is better than TLS 1.3 then since you seem to think you know more about security than the entire security industry. Every enterprise on the planet uses an iteration of secure socket layer most commonly TLS 1.2 in 2022.

Of course SSL doesn't stop routed netmail from being read by a SysOp in the middle though, so in this case Mystic does AES-256 encrypted

Using the artifically weakened cryptography is a very, very unwise idea.

If the widespread enterprise-level adoption of AES-256 is inferior and very very unwise for two-way encryption, then please let us (and the rest of the security world) know what should be used instead?

How will be ever protect our highly classified FidoNet netmail with the never-been-compromised AES-256? lolol

Assuming there is no future flaw discovered in the algorithm, it would take every single computer on the planet thousands of years to brute force a single AES key.

I don't think you could have possibly missed the mark any more than you did with this post lol.

... Some people have no idea what they're doing, and are really good at it!

--- Mystic BBS v1.12 A48 2022/02/17 (Windows/32)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Re: Re: Directly include binary data in messages
By: James Coyle to Alexey Vissarionov on Fri Feb 25 2022 01:10 am

Synchronet and Mystic support direct BINKP over SSL natively which is a good start to securing transmission.

It's the most stupid thing that could be done.

The SSL was good 15...20 years ago, but now it doesn't conform to modern

Okay so tell me what is better than TLS 1.3 then since you seem to think you know more about security than the entire security industry.

You both mentioned SSL, not TLS.
--
digital man (rob)

Synchronet "Real Fact" #91:
Captured chat with Wayne Bell: http://wiki.synchro.net/history:waynebell_chat Norco, CA WX: 42.9°F, 64.0% humidity, 0 mph N wind, 0.00 inches rain/24hrs

Good ${greeting_time}, James!

25 Feb 2022 01:10:58, you wrote to me:

Synchronet and Mystic support direct BINKP over SSL natively

Your software fails to quote the text correctly. For example, this word:

which

^^^^^
wasn't written by me.

When quoting, the correctly written software should add one '>' character to _the_ _tail_ of existing quote prefix, so /^ XY>>/ should become /^ XY>>>/

It's the most stupid thing that could be done.
The SSL was good 15...20 years ago, but now it doesn't conform to
modern

Okay so tell me what is better than TLS 1.3 then

SSH is a really good example.

since you seem to think you know more about security than the entire security industry.

I'm _in_ that industry.

Every enterprise on the planet uses an iteration of secure socket
layer most commonly TLS 1.2 in 2022.

Here you said "enterprise"... Most of them have no other option than HTTPS.

Of course SSL doesn't stop routed netmail from being read by a

SysOp

in the middle though, so in this case Mystic does AES-256

encrypted

Using the artifically weakened cryptography is a very, very unwise
idea.

If the widespread enterprise-level adoption of AES-256 is inferior
and very very unwise for two-way encryption, then please let us (and
the rest of the security world) know what should be used instead?

For the standard: second finalist and the real winner - Twofish.
For the practical purposes: Twofish, Threefish or Grasshopper.

That's about the symmetric ciphers. Also there are hash functions much more efficient and stronger than SHA family (Skein, Streebog). And finally, the public-key algorithms I can recommend are the old good RSA (with at least 8192-bit keys, of course) and the elegant ED25519 (based on Edwards curve).

How will be ever protect our highly classified FidoNet netmail with
the never-been-compromised AES-256? lolol

AES is the standard (what a shame... american standard is based on a foreign development) prescribing the use of Rijndael algorithm.

Also, what mode do you prefer for it? CBC, CFB, CTR, ECB, GCM, XTS, or?

Assuming there is no future flaw discovered in the algorithm, it
would take every single computer on the planet thousands of years to
brute force a single AES key.

You mean the 20-years-old SP-net with fixed non-random S-blocks? I have some really bad forecast for you...

I don't think you could have possibly missed the mark any more than
you did with this post lol.

"é« Γπ»««⌐..."


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... that's why I really dislike fools.
--- /bin/vi
* Origin: ::1 (2:5020/545)

You both mentioned SSL, not TLS.

They are used interchangably in the security industry as TLS is an interation of SSL. I've worked in cyber security for decades and never once heard anyone refer to a "TLS certificate" even though technically thats what they are.

https://www.websecurity.digicert.com/security-topics/what-is-ssl-tls-https

The post he made was a "pass it around the office of cyber security exports so everyone can get a laugh" moment.

... This virus requires Microsoft Windows 3.x

--- Mystic BBS v1.12 A48 2022/02/17 (Windows/32)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Synchronet and Mystic support direct BINKP over SSL natively

When quoting, the correctly written software should add one '>'
character to _the_ _tail_ of existing quote prefix, so /^ XY>>/ should become /^ XY>>>/

Can you show me where the committee for BBS standards made this law? Because I can show you a massive history of 30 years of BBS software that disagree with you.

You can show me that right after you tell me why TLS 1.3 is unsafe to use to secure transmission via sockets which you seemed to ignore. Or why AES-256 is unsafe to use to secure FidoNet netmail despite it literally being the current recommended standard that has never been compromised.

A bogus complaint about quote format is what people do when they jump into something and are horribly off the mark. They refer with childish tactics like this because what their comments on the actual subject are complete nonsense.

... Why is the man who invests all your money called a broker?

--- Mystic BBS v1.12 A48 2022/02/17 (Windows/32)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Your software fails to quote the text correctly. For example, this word:

which

^^^^^
wasn't written by me.

Even more hilarious than your out of nowhere uninformed combative posts is that its YOUR software that quoted wrong despite you trying to be petty about a quote.

My message was properly associated to the proper initials followed by a linefeed as you can see here:

https://postimg.cc/Vdbf6GpN

I can clearly see why FTN isn't getting anywhere taking itself out of the stoneage with the posts here lol

... I know a good tagline when I steal one!

--- Mystic BBS v1.12 A48 2022/02/17 (Windows/32)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Good ${greeting_time}, James!

25 Feb 2022 12:13:30, you wrote to me:

When quoting, the correctly written software should add one '>'
character to _the_ _tail_ of existing quote prefix, so /^ XY>>/
should become /^ XY>>>/

Can you show me where the committee for BBS standards made this law?

As we are in FTSC_PUBLIC echoarea, the FTSC publication should be enough: http://ftsc.org/docs/fsc-0032.001


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... god@universe:~ # cvs up && make world
--- /bin/vi
* Origin: ::1 (2:5020/545)

//Hello James,//

on *24.02.22* at *17:01:33* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Re: Re^4: Directly include binary data in messages"*.

Synchronet and Mystic support direct BINKP over SSL natively which is a good start to securing transmission. At one point I had a opportunistic SSL version of BinkP as well.

That already helps a lot. Have to add this. However, this in the end requires some additional information for the clients to connect to be aware of SSL/TLS support !?

Of course SSL doesn't stop routed netmail from being read by a SysOp in

Thats the point. Still, it keeps the direct listeners away.

the middle though, so in this case Mystic does AES-256 encrypted netmail if its setup with an encryption key for the address being netmailed.

The key distribution is the interesting part. Also, probably one should probably employ a combination of asym/sym (e.g., RSA+AES) as usal, so the symmetric keys are used only once.

Regards,
Tim

--- WinPoint 401.1
* Origin: Original WinPoint Origin! (2:240/1120.29)

//Hello Kees,//

on *24.02.22* at *14:41:38* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Directly include binary data in messages"*.

Hello Tim!

24 Feb 22 15:19, you wrote to Wilfred van Velzen:

For private messages, there is little sense in competing with email.
Surely fidonet netmail is not going to replace email during the next 5
years. However, it makes a lot of sense to provide comparable
capabilities just to enable users to make consistent use of netmail and
echomail while having basic capabilities that are just not worse than
email 20 years ago. Currently thats not remotely the case.

E-mail has not changed either in te last 20 years. The only thing that has changed are the user clients that can now display mime encapsulated messages.

Designing a different way of encapsulation for fidonet is hardly productive. Mime encapsulation is not hostile to the content section of fidonet messages.

No changes have to have to be made to Fidonet. The only changes are at the presentation layer, wich is not subject to fidonet standards.

Kees

--- GoldED+/LNX 1.1.5--b20180707
* Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)

Regards,
Tim

--- WinPoint 401.1
* Origin: Original WinPoint Origin! (2:240/1120.29)

That already helps a lot. Have to add this. However, this in the end requires some additional information for the clients to connect to be aware of SSL/TLS support !?

Yes you are right for direct SSL connections there would need to be some way for a node to know if the connection is compatible with SSL when transmitting netmail via unsecure connections.

Maybe a nodelist flag, or if not then just "trial and error" by attempting to connect to a default SSL port first before falling back to the standard BINKP port.

For these reasons, I was experimenting with opportunistic SSL for BINKP. With opportunistic SSL the connection is always on the same port and if both clients support SSL it will convert the connection prior to any authentication.

It also gives us the capability to decide if a connection should be accepted in real-time. For example, if unsecure node then maybe SSL is required otherwise known nodes can use cleartext. BINKP would be able to make decisions as to what it will and won't allow in "real-time" and then gracefully accept or refuse connections with a proper error message.

We would not require any broader changes (nodelist flags, etc) outside of BINKP client that supports opportunistic SSL extension and it is fully backwards compatible with BINKP that does not support the extension.

A nodelist flag that states that a node may require SSL would still be ideal in the long run, but we would not depend on it for this to work well.

The key distribution is the interesting part. Also, probably one should probably employ a combination of asym/sym (e.g., RSA+AES) as usal, so the symmetric keys are used only once.

I agree this would be where the challenge is for unsecure transfer. The AES in Mystic was done a while back and is a bit outdated. It does not have any way to circulate a keystore in a peer-to-peer way so it only works for known nodes.

One thing I found is that many end users didn't really seem to grasp the SSL keystores/certs/keys concepts all that well, so in Mystic I present an "Encryption password" and when that is set for a known node, Mystic will AES256 encrypt.

Behind the scenes it takes that password and then uses SHA256 to create the actual 256-bit key that is used. It uses AES256-CBC which today isn't as ideal, but it does use a randomized IV and it does have authentication of the decrypted data to help secure tampering. In 2022 a GCM version would be better though instead of using proprietary means to secure CBC.

One benefit of using this approach is that there is a lot of AES256 code available for just about any language that people can leverage, and I think that would be highly important for adoption.

... Condense soup, not books!

--- Mystic BBS v1.12 A48 2022/02/17 (Windows/32)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

//Hello James,//

on *28.02.22* at *15:15:12* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Re: Re^2: Re^4: Directly include binary data in messages"*.

That already helps a lot. Have to add this. However, this in the end
requires some additional information for the clients to connect to be
aware of SSL/TLS support !?

Yes you are right for direct SSL connections there would need to be some way for a node to know if the connection is compatible with SSL when transmitting netmail via unsecure connections.

Maybe a nodelist flag,

That was my first thought as well.

or if not then just "trial and error" by attempting to connect to a default SSL port first before falling back to the standard BINKP port.

Better than the nodelist flag. Should be another "unused" port ...

For these reasons, I was experimenting with opportunistic SSL for BINKP. With opportunistic SSL the connection is always on the same port and if both clients support SSL it will convert the connection prior to any authentication.

Before it comes up (there is always a troll): probably TLS rather than SSL, but admittedly I also someimes keep talkin about SSL when referring whatever session layer protocol is actually in charge. Educated people know what its about ...

It also gives us the capability to decide if a connection should be accepted in real-time. For example, if unsecure node then maybe SSL is required otherwise known nodes can use cleartext.

I am not sure if this makes sense. So you want to use an unsecured connection to have the session password transmitted? ;)

BINKP would be able to make decisions as to what it will and won't allow in "real-time" and then gracefully accept or refuse connections with a proper error message.

This brings us to a potential integration into BinkP itself. That would server the above issues, but overall it is more compliated to implement and does not hide the nature of the communication itself, which maybe a point. (I already see VPN arguments coming up ...)

We would not require any broader changes (nodelist flags, etc) outside of BINKP client that supports opportunistic SSL extension and it is fully backwards compatible with BINKP that does not support the extension.

Not relying on the nodelist would be a big plus. I also think, it is more desirable to have something that works out-of-the-box if both systems are compatible without any additional infrastructure/metadata/explicit configuration.

A nodelist flag that states that a node may require SSL would still be ideal in the long run, but we would not depend on it for this to work well.

Having it for information purpose is fine.

The key distribution is the interesting part. Also, probably one should
probably employ a combination of asym/sym (e.g., RSA+AES) as usal, so
the symmetric keys are used only once.

I agree this would be where the challenge is for unsecure transfer. The AES in Mystic was done a while back and is a bit outdated. It does not have any way to circulate a keystore in a peer-to-peer way so it only works for known nodes.

One thing I found is that many end users didn't really seem to grasp the SSL keystores/certs/keys concepts all that well, so in Mystic I present
an "Encryption password" and when that is set for a known node, Mystic will AES256 encrypt.

Behind the scenes it takes that password and then uses SHA256 to create the actual 256-bit key that is used. It uses AES256-CBC which today
isn't as ideal, but it does use a randomized IV and it does have authentication of the decrypted data to help secure tampering. In 2022 a GCM version would be better though instead of using proprietary means to secure CBC.

One benefit of using this approach is that there is a lot of AES256 code available for just about any language that people can leverage, and I think that would be highly important for adoption.

Jep, straightforward. However, it is not ideal from a security and usability perspective. (No, I have no better proposal at hand for now).

Regards,
Tim

--- WinPoint 401.1
* Origin: Original WinPoint Origin! (2:240/1120.29)

Hello Tim!

28 Feb 22 17:54, you wrote to James Coyle:

A nodelist flag that states that a node may require SSL would
still be ideal in the long run, but we would not depend on it for
this to work well.

Having it for information purpose is fine.

You could use an oportunistic approach and use the nodelist flag to (if you with your system want to) enforce the use of SSL on a system, that claims to support it on outgoing calls.

Regards,
Tim

Regards,
Joachim


--- GoldED+/LNX 1.1.5--b20170303
* Origin: ----> FidoPI (2:240/6309)

or if not then just "trial and error" by attempting to connect to a default SSL port first before falling back to the standard BINKP TS> JC> TS> JC> TS> JC> port

Better than the nodelist flag. Should be another "unused" port ...

Agreed! Current Mystic defaults to port 24553 for direct SSL. I believe Synchronet may use the same default but Rob could probably clarify.

Before it comes up (there is always a troll): probably TLS rather than SSL, but admittedly I also someimes keep talkin about SSL when referring whatever session layer protocol is actually in charge. Educated people know what its about ...

Fair enough. To be clearer Mystic only supports TLS 1.2 in its SSL BINKP implementation and it should be the minimum version allowed as per current security recommendations.

I am not sure if this makes sense. So you want to use an unsecured connection to have the session password transmitted? ;)

I was just making an example, but what I meant was you could configure if you accept non-SSL connections for unknown (unsecured) echomail nodes vs known (secured) echomail nodes. This would not be something we could do with a direct SSL connection.

Just trying to outline some of the benefits of the opportunistic approach :)

This brings us to a potential integration into BinkP itself. That would server the above issues, but overall it is more compliated to implement and does not hide the nature of the communication itself, which maybe a point. (I already see VPN arguments coming up ...)

True it does not hide the initial nature of the communication as you have said, and this I would agree is probably its only real flaw. But I feel the trade off is that it will work without user awareness or configuration.

Even with direct-connection TLS 1.2 BINKP in Mystic many people still do not use it. Realistically if we want the network to be more secure, then making it opportunistic and automatic may be the best compromise?

I think we may have to decide if we care about hiding the fact that a FidoNet node even exists, or if (instead) we want widely adopted better security within the network.

Jep, straightforward. However, it is not ideal from a security and usability perspective. (No, I have no better proposal at hand for now).

Can you expand on why you think AES-256 is not ideal from a security perspective? Or did you just mean the CBC + random IV + authentication workaround?

There are alternatives but none of them have had huge enterprise adoption and decades of scruinty from the best cryptographers in the world. There is something to be said about anything in the security industry that has had that type of exposure and is still regarded as safe.

Newer things may in theory be technically better, but its only theoretical. These do not have the adoption or decades of scrutiny and could be exposed at any time. It is risky to assume newer is better when the "old" hasn't been broken.

Similar arguements could be made for using hashes like SHA256 vs others, for example. Mystic uses a PBKDF2 with SHA512 for user passwords for example and I still question if using SHA512 was a mistake for those reasons.

In terms of Netmail the subject line in a Mystic encrypted netmail contains version levels, flags, and some verification data which could be used to support multiple types of encryption in the future while still being backwards compatible.

... If you choose not to decide, you still have made a choice

--- Mystic BBS v1.12 A48 2022/02/28 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Re: Re: Re^2: Re^4: Directly include binary data in messages
By: James Coyle to Tim Schattkowsky on Mon Feb 28 2022 10:15 am

For these reasons, I was experimenting with opportunistic SSL for BINKP. With opportunistic SSL the connection is always on the same port and if both clients support SSL it will convert the connection prior to any authentication.

FYI, a few years ago, I applied for an IANA sanctioned TCP port number assignment for BINKPS (BINKP over implicit TLS, e.t port 24553). After a few back-and-forths, this was their final answer:
-=-=-=-=-=-
We have a response from the expert:

The reviews for port assignments is subject to RFCs 6335 and 7605. We have provided advice according to those docs.

The way forward that has been chosen and deployed is not consistent with those docs; we therefore do not recommend approval of the request.
-=-=-=-=-=-

So it looks like explicit/opportunistic TLS (e.g. STARTTLS) is the future for BINKP if it's going to become any kind of Internet standard.
--
digital man (rob)

Synchronet "Real Fact" #86:
Stephen and Rob have a fledgling podcast at http://techdorks.net (also iTunes) Norco, CA WX: 78.8°F, 11.0% humidity, 8 mph W wind, 0.00 inches rain/24hrs

Re: Re^2: Re^2: Re^4: Directly include binary data in messages
By: Tim Schattkowsky to James Coyle on Mon Feb 28 2022 05:54 pm

That was my first thought as well.

or if not then just "trial and error" by attempting to connect to a default SSL port first before falling back to the standard BINKP port.

Better than the nodelist flag. Should be another "unused" port ...

That method is called "implicit TLS" and is frowned upon by the Internet-powers-that-be, likely because of the finite number of available TCP ports. See my previous post on this topic. :-(
--
digital man (rob)

Synchronet/BBS Terminology Definition #87:
XJS = External JavaScript (SSJS embedded within HTML/CSS)
Norco, CA WX: 78.8°F, 11.0% humidity, 8 mph W wind, 0.00 inches rain/24hrs

FYI, a few years ago, I applied for an IANA sanctioned TCP port number assignment for BINKPS (BINKP over implicit TLS, e.t port 24553). After a few back-and-forths, this was their final answer:

Well the answer sucks, but your foresight in this issue was awesome :)

So it looks like explicit/opportunistic TLS (e.g. STARTTLS) is the
future for BINKP if it's going to become any kind of Internet standard.

I hadn't considered the IANA aspect of this. I have no experience with that stuff so naturally I yield to those who do. Is it a dead end to try again?

I can see BINKPS not having a large enough use-case to warrant a port. But if they did give us BINKP port then I feel there is a case to be made that they must also support the secure version of it.

If you are still willing to support a STARTTLS BINKP I am down to pick that up again and work on something together (and with whoever else wants to join in). I can look for a backup of the code that did it (this weekend) and send something your way, or we can start from scratch... Whatever works for you.

... Just another prisoner of gravity!

--- Mystic BBS v1.12 A48 2022/02/28 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Good ${greeting_time}, Rob!

28 Feb 2022 12:58:50, you wrote to James Coyle:

FYI, a few years ago, I applied for an IANA sanctioned TCP port
number assignment for BINKPS (BINKP over implicit TLS, e.t port
24553). After a few back-and-forths, this was their final answer:

The reviews for port assignments is subject to RFCs 6335 and 7605.
We have provided advice according to those docs. The way forward
that has been chosen and deployed is not consistent with those
docs; we therefore do not recommend approval of the request.

Very predictable. There are only 65534 ports, and reserving them to some specific applications is very unwise.

That's why SRV NS RRs were invented (and documented by FTSC since 2013).

So it looks like explicit/opportunistic TLS (e.g. STARTTLS) is
the future for BINKP if it's going to become any kind of Internet standard.

For now, we have two working implementations for encrypted connection - SSH, supported by binkd since version 1.1a-22 released in 2013, and SSL/TLS, supported by binkd since the same version (requires a companion software to accept incoming connections, but may run on HTTPS port in conjunction with nginx) and Mystic (as JC wrote earlier).

The use of SSH and HTTPS ports has an advantage of multiplexing the incoming connections among different applications.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... that's why I really dislike fools.
--- /bin/vi
* Origin: ::1 (2:5020/545)

Re: Re: Re^2: Re^4: Directly include binary data in messages
By: James Coyle to Rob Swindell on Mon Feb 28 2022 05:05 pm

FYI, a few years ago, I applied for an IANA sanctioned TCP port number assignment for BINKPS (BINKP over implicit TLS, e.t port 24553). After a few back-and-forths, this was their final answer:

Well the answer sucks, but your foresight in this issue was awesome :)

It was worth a try. :-)

So it looks like explicit/opportunistic TLS (e.g. STARTTLS) is the future for BINKP if it's going to become any kind of Internet standard.

I hadn't considered the IANA aspect of this. I have no experience with that stuff so naturally I yield to those who do. Is it a dead end to try again?

Yeah, I think so. Their protecting the assigned port numbers like they're Fort Knox and their ammunition is RFCs 6335 and 7605. :-)

I can see BINKPS not having a large enough use-case to warrant a port. But if they did give us BINKP port then I feel there is a case to be made that they must also support the secure version of it.

That's the case I was trying to make (along with all the other "prior art" of insecure Internet protocols that have an alternate/secure port for implicit TLS connections, e.g. telnets) - but they weren't buying it.

If you are still willing to support a STARTTLS BINKP I am down to pick that up again and work on something together (and with whoever else wants to join in). I can look for a backup of the code that did it (this weekend) and send something your way, or we can start from scratch... Whatever works for you.

Yeah, we should do that. :-) I have a number of STARTTLS implementations in Synchronet already (e.g. SMTPS, FTPS), so I don't expect it'd be much different, thought I suppose this would be the first one I'd do in JavaScript (since BinkIT is written in JS).
--
digital man (rob)

Synchronet/BBS Terminology Definition #90:
UTF-8 = 8-bit Unicode Transformation Format
Norco, CA WX: 72.2°F, 13.0% humidity, 0 mph ENE wind, 0.00 inches rain/24hrs

That's the case I was trying to make (along with all the other "prior
art" of insecure Internet protocols that have an alternate/secure port
for implicit TLS connections, e.g. telnets) - but they weren't buying it.

Sounds like you gave them really the only legs we had to stand on and it failed. Thats a shame, but at least we know.

Yeah, we should do that. :-) I have a number of STARTTLS implementations in Synchronet already (e.g. SMTPS, FTPS), so I don't expect it'd be much different, thought I suppose this would be the first one I'd do in JavaScript (since BinkIT is written in JS).

Yep it shouldn't be too difficult. I also have it working for some protocols like POP3/SMTP in Mystic. I don't think my FTP does it though so maybe I can look into that after this since it'd also probably benefit DoveNet security.

I have a document with an outline and some requirements/notes for TLS BINKP that I can e-mail you. It might save us a little time not having to reinvent the entire wheel, assuming you think its usable of course :)

Maybe once we agree on what we want to do and have it working then we can clean it up and circulate it or make a proposal or whatever?

Is there a preferred e-mail you like to use? Or I could Netmail whatever works best.

... The person who snores the loudest will fall asleep first

--- Mystic BBS v1.12 A48 2022/02/28 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Re: Re: Re^2: Re^4: Directly include binary data in messages
By: James Coyle to Rob Swindell on Tue Mar 01 2022 05:53 pm

Yeah, we should do that. :-) I have a number of STARTTLS implementations in Synchronet already (e.g. SMTPS, FTPS), so I don't expect it'd be much different, thought I suppose this would be the first one I'd do in JavaScript (since BinkIT is written in JS).

Yep it shouldn't be too difficult. I also have it working for some protocols like POP3/SMTP in Mystic. I don't think my FTP does it though so maybe I can look into that after this since it'd also probably benefit DoveNet security.

I never bothered with FTPS in my ftp client modules (e.g. for QWK packet transfers) that's a thought for a future enhancement though.

I have a document with an outline and some requirements/notes for TLS BINKP that I can e-mail you. It might save us a little time not having to reinvent the entire wheel, assuming you think its usable of course :)

Yeah, absolutely.

Maybe once we agree on what we want to do and have it working then we can clean it up and circulate it or make a proposal or whatever?

Yeah, I think that's what this FTSC thing is all about. :-)

Is there a preferred e-mail you like to use? Or I could Netmail whatever works best.

Sure, either way. rob at synchro dot net or FTN netmail. They end up in the same inbox.
--
digital man (rob)

Sling Blade quote #1:
Karl: I've killed Doyle with a lawn mower blade. Yes, I'm right sure of it. Norco, CA WX: 70.5°F, 25.0% humidity, 10 mph SE wind, 0.00 inches rain/24hrs

Sure, either way. rob at synchro dot net or FTN netmail. They end up in the same inbox.

Cool deal I will send it along.

I ended up having a backup of the code and the document so I put it all back into Mystic this evening. I am in the process of putting up a build for anyone to test that supports the STARTTLS implementation of the document I will send.

I haven't tested it much though just enough to see it actually work once between a Mystic client/server.

The documentation is a bit sloppy, not really intended to be anything formal.

... This virus requires Microsoft Windows 3.x

--- Mystic BBS v1.12 A48 2022/03/01 (Windows/32)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Re: Re^2: Directly include binary data in messages
By: Tim Schattkowsky to Anna Christina Nass on Tue Feb 22 2022 09:40 pm

//Hello Anna,//

on *22.02.22* at *11:22:00* You wrote in Area *FTSC_PUBLIC*
to *Ward Dossche* about *"Re: Directly include binary data in messages"*.

I thought that while the people who do write good software (like Rob o Tim) are currently talking about this topic, I could add an idea to th topic.

Actually I appreciate and share your idea, but I am currently not certain ab the technical implications. Needs a while to digest and get comfortable with or find reasons why this wont work (I have some candidates).

Regards,
Tim

Good thoughts Tim. Sorry for the late message. I'd sidelined this echo for a bit by accident, while checking fr messages for me and working on setups for some nodes in my net.

xxcarol
--- SBBSecho 2.11-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Re^2: Directly include binary data in messages
By: Tim Schattkowsky to Rob Swindell on Tue Feb 22 2022 09:55 pm

//Hello Rob,//

on *22.02.22* at *19:22:28* You wrote in Area *FTSC_PUBLIC*
to *Anna Christina Nass* about *"Re: Directly include binary data in messages"*.

Pretty trivial. In fact, any echomail program that supports multiple packet formats (e.g. SBBSecho supports packet types 2.0, 2+, 2e, and 2. can be used as a gateway between old and even older technology systems. :-)

IMHO this is lacking the total system perspective. There are open questions that level. How is the sending system supposed to know what packet format a receiver expects?

This could be done in a lot of ways:
- explicit configuration
- nodelist flags
- dynamically during the mail session (i.e., the mailer eventually triggers final packet format in some way depending on session handshake information) - ...

The most important question for me is still, WHY is there any need for a new packet format? Other than the lack of zone (or even 5D) information, what ar the points?

Regards,
Tim

I can't answer as to why we need a new packet format, but of your 3 options above Explicit configuration, possibly triggered by nodelist flags.

Say 2 softwares 'pop up' capable of both. One will autoconfigure from the nodelist, the other doesn't. Both can be manually setup though.

I don't think option 3 is viable because it means at time of connection to repack *.pkt into another format. Once packed in one, you'd probably have to touch the actual message base to repack right? That or there wouldn't be much point in it that I can see? LOL, ok, I may be missing something!

xxcarol
--- SBBSecho 2.11-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

Re: Re: Directly include binary data in messages
By: James Coyle to Alexey Vissarionov on Fri Feb 25 2022 12:13 pm

Synchronet and Mystic support direct BINKP over SSL natively

When quoting, the correctly written software should add one '>' character to _the_ _tail_ of existing quote prefix, so /^ XY>>/ should become /^ XY>>>/

Can you show me where the committee for BBS standards made this law? Because can show you a massive history of 30 years of BBS software that disagree wit you.

You can show me that right after you tell me why TLS 1.3 is unsafe to use to secure transmission via sockets which you seemed to ignore. Or why AES-256 unsafe to use to secure FidoNet netmail despite it literally being the curre recommended standard that has never been compromised.

A bogus complaint about quote format is what people do when they jump into something and are horribly off the mark. They refer with childish tactics l this because what their comments on the actual subject are complete nonsense

... Why is the man who invests all your money called a broker?

OH NO! Not the quoting police again!

xxcarol
--- SBBSecho 2.11-Win32
* Origin: SHENK'S EXPRESS telnet://shenks.synchro.net (1:275/100)

//Hello James,//

on *02.03.22* at *4:36:01* You wrote in Area *FTSC_PUBLIC*
to *Rob Swindell* about *"Re: Re^2: Re^4: Directly include binary data in messages"*.

Sure, either way. rob at synchro dot net or FTN netmail. They end up in
the same inbox.

Cool deal I will send it along.

I ended up having a backup of the code and the document so I put it all back into Mystic this evening. I am in the process of putting up a build for anyone to test that supports the STARTTLS implementation of the document I will send.

I haven't tested it much though just enough to see it actually work once between a Mystic client/server.

The documentation is a bit sloppy, not really intended to be anything formal.

So is there now any implementation BinkP implementation using STARTTLS and what are the details?

BTW: RFC8314 suggests already in the introduction that for email, implicit TLS should be preferred over STARTTLS :)

Regards,
Tim

--- WinPoint 407.1
* Origin: Original WinPoint Origin! (2:240/1120.29)

So is there now any implementation BinkP implementation using STARTTLS
and what are the details?

BTW: RFC8314 suggests already in the introduction that for email,
implicit TLS should be preferred over STARTTLS :)

I've been following this thread for some time, and I don't understand how it concerns our FTN network.

Isn't it a simple matter of how the FTN editors can handle it?

More and more of us are using e.g. Thunderbird as the editor of choice, the only editor I know that has thousands of people still working to perfect it.

I can easily copy an image into a message of mine here, and so can you when you reply to an email from your friend. The only reason I'll not demonstrate how easy it is here, is I don't want to cause any problems for all those still using archaic BBS FTN editors, often BASIC based creations by teenagers from the Fidonet heydays.

Methinks that you are trying to fix an FTN problem from 30+ years ago, and that'll only concern those who insist on using editors from that time. Why would we concern ourselves with that, rather than looking into the future?

..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se:4119 (2:203/2)

So is there now any implementation BinkP implementation using STARTTLS
and what are the details?

BTW: RFC8314 suggests already in the introduction that for email,
implicit TLS should be preferred over STARTTLS :)

Yes there is. I did a STARTTLS-enabled BINKP a few years ago and its currently available in Mystic that you can download here:

http://www.mysticbbs.com/downloads/prealpha/

I have sent the documentation over to Rob for implementation and/or feedback but I didn't want to post it here yet to avoid trolling. I'd be happy to e-mail it along to you as well if you're interested in supporting it!

BTW: RFC8314 suggests already in the introduction that for email,
implicit TLS should be preferred over STARTTLS :)

Implicit would be great (and Mystic actually implements both implicit and opportunistic TLS v1.2 with BINKP), but the problem with implicit is two-fold:

1) For mass adoption, having a self-upgrading connection is probably the most realistic to be used. In other words, existing setups wouldn't have to be changed in order to support it. No additional nodelist flags, etc, would be needed. It wouldn't break any existing systems while those that support it would simply just work.

2) The IANA has denied officially giving us a port for BINKPS, which means that implicit SSL can never be an official standard unless they were to some how be persuaded to change their mind.

Mostly due to #2 it seems to me like the best approach for us to move forward would be to adopt Mystic's opportunistic TLS or some variation of it. Or to support both, ideally?

... That's not a bug, it's an undocumented feature

--- Mystic BBS v1.12 A48 2022/03/14 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

//Hello Bjoern,//

on *21.03.22* at *19:04:14* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Directly include binary data in messages"*.

So is there now any implementation BinkP implementation using STARTTLS
and what are the details?

BTW: RFC8314 suggests already in the introduction that for email,
implicit TLS should be preferred over STARTTLS :)

I've been following this thread for some time, and I don't understand how it concerns our FTN network.

You probably missed that we (no matter what the subject says) actually discussed, how BinkP connections can be secured by TLS?

Unless I missed something, the messages people write are currently mostly transported using BinkP, which makes this sort of relevant.

Regards,
Tim

--- WinPoint 408.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

You probably missed that we (no matter what the subject says) actually discussed, how BinkP connections can be secured by TLS?

The conversation in here has bounced back and forth between secure transport and embedding things like images. So I can see how he replied to something different than the message he actually replied to.

I'm still baffled by the "more and more of us are using Thunderbird."


- Andre
--- SBBSecho 3.15-Linux
* Origin: Radio Mentor BBS - bbs.radiomentor.org (1:154/70)

Good ${greeting_time}, Tim!

21 Mar 2022 22:33:52, you wrote to Björn Felten:

BTW: RFC8314 suggests already in the introduction that for
email, implicit TLS should be preferred over STARTTLS :)

I've been following this thread for some time, and I don't
understand how it concerns our FTN network.

You probably missed that we (no matter what the subject says)
actually discussed, how BinkP connections can be secured by TLS?

TLS is not about the security - it is (really "was") mostly about the mutual authentification. It could work as designed (in the era of SSL 2.0 and before), but the emerge of HTTPS killed some key features of it.

Unless I missed something, the messages people write are currently
mostly transported using BinkP, which makes this sort of relevant.

You appear to be missing the key point: binkp is defined by its' reference implementation (binkd), and the FTS-1026 plays the secondary role.

#include <FTA-1006>

Yes, it _may_ support SSL/TLS.
Yes, it _may_ even share the inbound port with HTTPS.
Yes, it _may_ be set up to circumvent most barriers in the modern Internet.

But if you want to implement some of these features somewhere else, you _must_ know how that's implemented in binkd.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... :wq!
--- /bin/vi
* Origin: ::1 (2:5020/545)

//Hello Alexey,//

on *21.03.22* at *22:55:50* You wrote in Area *FTSC_PUBLIC*
to *Tim Schattkowsky* about *"Directly include binary data in messages"*.

TLS is not about the security - it is (really "was") mostly about the mutual authentification. It could work as designed (in the era of SSL 2.0 and before), but the emerge of HTTPS killed some key features of it.

- TLS (Transport Layer *Security*) is besides authentication about establishing an encrypted connection between endpoints, just like its predecessor SSL (*Secure* Socket Layers)
- HTTPS (Hypertext Transfer Protocol *Secure*) is HTTP over a secured connection (SSL or TLS)

Unless I missed something, the messages people write are currently
mostly transported using BinkP, which makes this sort of relevant.

You appear to be missing the key point: binkp is defined by its'
reference implementation (binkd), and the FTS-1026 plays the secondary role.

Totally not helpful comment ;)

Regards,
Tim

--- WinPoint 408.0
* Origin: Original WinPoint Origin! (2:240/1120.29)

Re: Re: Re^8: Directly include binary data in messages
By: James Coyle to Tim Schattkowsky on Mon Mar 21 2022 03:16 pm

So is there now any implementation BinkP implementation using STARTTLS and what are the details?

BTW: RFC8314 suggests already in the introduction that for email, implicit TLS should be preferred over STARTTLS :)

Yes there is. I did a STARTTLS-enabled BINKP a few years ago and its currently available in Mystic that you can download here:

http://www.mysticbbs.com/downloads/prealpha/

I have sent the documentation over to Rob for implementation and/or feedback but I didn't want to post it here yet to avoid trolling. I'd be happy to e-mail it along to you as well if you're interested in supporting it!

I haven't made the time to experiment with STARTTLS support in Synchronet's BinkIT yet. I will and get back to you.

BTW: RFC8314 suggests already in the introduction that for email, implicit TLS should be preferred over STARTTLS :)

Implicit would be great (and Mystic actually implements both implicit and opportunistic TLS v1.2 with BINKP), but the problem with implicit is two-fold:

1) For mass adoption, having a self-upgrading connection is probably the most realistic to be used. In other words, existing setups wouldn't have to be changed in order to support it. No additional nodelist flags, etc, would be needed. It wouldn't break any existing systems while those that support it would simply just work.

2) The IANA has denied officially giving us a port for BINKPS, which means that implicit SSL can never be an official standard unless they were to some how be persuaded to change their mind.

Mostly due to #2 it seems to me like the best approach for us to move forward would be to adopt Mystic's opportunistic TLS or some variation of it. Or to support both, ideally?

Yeah, there's really no downside to supporting both, unless the STARTTLS implementation is somehow determined to be less secure. But we'll work to make sure that's not the case.
--
digital man (rob)

Synchronet/BBS Terminology Definition #67:
SCFG = Synchronet Configuration Utility
Norco, CA WX: 85.7°F, 21.0% humidity, 12 mph SE wind, 0.00 inches rain/24hrs