It would appear that using the Blue Wave door results in only one
tear line!

Jay

... The older you get, the better you get, unless you're a banana.
--- MultiMail/Win v0.52
* Origin: Northern Realms Test (1:229/664)

Quoting Jay Harris to All at 06-05-20 15:00 <=-

It would appear that using the Blue Wave door results in only one
tear line!

Jay

... The older you get, the better you get, unless you're a banana.
-!- MultiMail/Win v0.52
! Origin: Northern Realms Test (1:229/664)

Working fine.


[]'s
�
����������� Mauro R. Veiga � abutre.no-ip.org:2323 �������� * ������
�

MeSSaGe SiTTeR 1.00 - Full Version
Live Long and Prosper

... BlueWave - Universe Tour - Stardate 47634.44
___ Blue Wave/386 v2.30
--- SBBSecho 3.06-Win32
* Origin: Ninho do Abutre 2 - Rio de Janeiro - Brasil * (4:801/194)

Hello Mauro,

On Saturday June 06 2020 19:56, you wrote to JAY HARRIS:

@MSGID: 5667.fidotest@4:801/194 23416b7c

"5667.fidotest@4:801/194" is not a valid return address in the originating network.

@REPLY: 1:229/664.0 5eda5e18
@TZUTC: -0300
@TID: SBBSecho 3.06-Win32 r3.101 Jan 1 2019 MSC 1800

No CHRS kludge.

ó
■■■■■■■■■■■ Mauro R. Veiga ■

abutre.no-ip.org:2323 ■■■■■■■■ *

■■■■■■
ó

Without a CHRS kludge, one can not expect non ASCII to be displayed correctly.


Cheers, Michiel

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

Re: Test From Blue Wave Door
By: Michiel van der Vlist to Mauro Veiga on Sun Jun 07 2020 15:21:34

@MSGID: 5667.fidotest@4:801/194 23416b7c

MvdV> "5667.fidotest@4:801/194" is not a valid return address in the originating network.

sure it is... the sysop gets those messages by default on all sbbs installations...

@REPLY: 1:229/664.0 5eda5e18
@TZUTC: -0300
@TID: SBBSecho 3.06-Win32 r3.101 Jan 1 2019 MSC 1800

MvdV> No CHRS kludge.

the OP is behind in his updates... sbbs and sbbsecho have been through a lot of changes and updates in the last 1.5 years...

SBBSecho 3.11-Linux r3.173 May 23 2020 GCC 7.5.0

and i'm behind a few weeks, too...


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

Hello Michiel!

** On Sunday 07.06.20 - 15:21, Michiel van der Vlist wrote to Mauro Veiga:

@MSGID: 5667.fidotest@4:801/194 23416b7c

MvdV> "5667.fidotest@4:801/194" is not a valid return address in the
MvdV> originating network.

Looks "valid" to me.

Whether another message using "5667.fidotest@4:801/194" for "To: "
actually reaches the eyes of any particular person is not a concern.

The sysop could have a catch-all bucket for those.


../|ug

--- OpenXP 5.0.44
* Origin: This is a test of the Emergency Tagline System (2:221/1.58)

Hello mark,

On Sunday June 07 2020 09:47, you wrote to me:

MvdV>> No CHRS kludge.

the OP is behind in his updates... sbbs and sbbsecho have been through
a lot of changes and updates in the last 1.5 years...

The point was that without a CHRS kludge one can not expect non ASCII to be correctly displayed at the reader's end.

Without a CHRS kludge, one is limited to ASCII only if one wants it readable at the other end.

Cheers, Michiel

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

Re: Test From Blue Wave Door
By: Michiel van der Vlist to mark lewis on Sun Jun 07 2020 16:18:20


MvdV>> No CHRS kludge.

the OP is behind in his updates... sbbs and sbbsecho have been through
a lot of changes and updates in the last 1.5 years...

MvdV> The point was that without a CHRS kludge one can not expect non ASCII
MvdV> to be correctly displayed at the reader's end.

yep... sbbs should be properly applying a CHRS control line to posted messages based on the message (and header) content...

MvdV> Without a CHRS kludge, one is limited to ASCII only if one wants it
MvdV> readable at the other end.

true... the point of my response was that the original system is behind in its updates... note the dates below and compare to the original post's sbbsecho TID line...

----- snip -----
rswindell
Tue May 05 2020 05:35 pm PDT

Modified Files:
src/sbbs3/qwktomsg.cpp 1.85 1.86 diff

Log Message:
Automatically detect the character set of QWK-imported messages (that don't already have a FidoNet "CHRS" header) and create/set the FIDOCHARS header field
accordingly (UTF-8, ASCII, or CP437). This should resolve the issue I observed of QWK-posted messages on FidoNet with the wrong CHRS header value (i.e. CP437,
when the message body in fact contained UTF-8).

-----

rswindell
Tue Sep 17 2019 03:29 am PDT

Modified Files:
src/sbbs3/echocfg.c 3.48 3.49 diff
src/sbbs3/rechocfg.c 3.40 3.41 diff
src/sbbs3/sbbsecho.c 3.140 3.141 diff
src/sbbs3/sbbsecho.h 3.35 3.36 diff

Log Message:
Added support for auto-detection of incoming UTF-8 messages (default: enabled).
If an incoming message contains no CHRS/CHARSET control line *and* the message text contains valid UTF-8 character encodings, set the FTN charset value to UTF-8 so the message will be displayed/handled accordingly.
I did not add checks for header fields (to/from/subject) - we should probably auto-detect UTF-8 in those as well, but for now, I don't see messages coming into FidoNet echoes with UTF-8 in the header fields.
Incremented SBBSecho/EchoCfg version to 3.10.

-----

rswindell
Thu Aug 22 2019 09:50 pm PDT

Modified Files:
src/sbbs3/js_msgbase.c 1.251 1.252 diff

Log Message:
Add ftn_charset property for message headers. This header field corresponds with the FTN (FTS-5003) "CHRS" control line/paragraph. The values recoginized by Synchronet are:
"ASCII 1"
"CP437 2"
"UTF-8 4"

These values indicate that header fields and body text of a message are
encoded with the specifiec charset. The default (assumed charset, if not specified), is CP437.

-----

rswindell
Sat Aug 03 2019 03:07 am PDT

Modified Files:
src/sbbs3/sbbsecho.c 3.126 3.127 diff

Log Message:
Export a default CHRS: (charset) value of "UTF-8" when any of the header fields
contain UTF-8 characters.

-----

rswindell
Fri Aug 02 2019 01:31 am PDT

Modified Files:
src/sbbs3/sbbsecho.c 3.124 3.125 diff

Log Message:
If SBBSecho imports a message with a "CHRS" control line with a value of "UTF-8", set the msg's auxattr MSG_HFIELDS_UTF8 flag because FTS-5003 states:
"The character set identifier applies to all parts of the message,
including the header information and the control lines like origin
and tear line."

----- snip -----

there are more CHRS and CHARACTERSET related commits to the repository...

one can go here for more information:

http://cvs.synchro.net/commitlog.ssjs?5000

drop/change the "?5000" from the URL for default or specific number of commits to list...


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

Hello August,

On Sunday June 07 2020 10:15, you wrote to me:

MvdV>> "5667.fidotest@4:801/194" is not a valid return address in the
MvdV>> originating network.

Looks "valid" to me.

"Looks valid" does not "make valid".

Whether another message using "5667.fidotest@4:801/194" for "To: " actually reaches the eyes of any particular person is not a concern.

The concern is if it reaches the /system/ in the originating network.

"5667.fidotest@4:801/194 23416b7c" is not and never was, a valid address in Fidonet.

The sysop could have a catch-all bucket for those.

The sysop of what system? What system in Fidonet has "5667.fidotest@4:801/194" as its address?


Cheers, Michiel

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

Hello Michiel!

** On Sunday 07.06.20 - 16:52, Michiel van der Vlist wrote to August Abolins:

MvdV> The sysop of what system? What system in Fidonet has
MvdV> "5667.fidotest@4:801/194" as its address?

4:801/194 exists in my nodelist.



../|ug

--- OpenXP 5.0.44
* Origin: This is a test of the Emergency Tagline System (2:221/1.58)

Re: Test From Blue Wave Door
By: August Abolins to Michiel van der Vlist on Sun Jun 07 2020 11:21:00


MvdV>> The sysop of what system? What system in Fidonet has
MvdV>> "5667.fidotest@4:801/194" as its address?

4:801/194 exists in my nodelist.

they are not thinking straight... they are certainly not recalling that the address is to the left of the '@'... they also have an extremely limited horizon when it comes to software used in FTNs... specifically they do not know about or understand software that uses "blahblah@address" style addressing for ALL addresses no matter if email, netmail, or news... with their limited horizon, they expect that all software used in FTNs splits the destination into two fields for presentation to the user... how little they know in their restricted worlds...


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

Hello mark,

On Sunday June 07 2020 10:57, you wrote to me:

MvdV>> The point was that without a CHRS kludge one can not expect non
MvdV>> ASCII to be correctly displayed at the reader's end.

yep... sbbs should be properly applying a CHRS control line to posted messages based on the message (and header) content...

I doubt adding a CHRS kludge after the fact is a good strategy.

MvdV>> Without a CHRS kludge, one is limited to ASCII only if one
MvdV>> wants it readable at the other end.

true... the point of my response was that the original system is
behind in its updates...

Then you were barking up the wrong tree. Puuting the name of the original poster in the To: field would have increased the chance it reached him. *I* can do nothing about it.

Log Message:
Automatically detect the character set of QWK-imported messages (that don't already have a FidoNet "CHRS" header) and create/set the
FIDOCHARS header field accordingly (UTF-8, ASCII, or CP437).

Determining the type of character encoding is tricky. In the case of UTF-8 it is doable because of the "well formed UTF-8 sequence" property. For the 8 bit encodings used in Fidonet, it requires a level of intelligence beyond what is normally available in Fidonet software. And FYI, encodings in use in Fidonet are not limited to UTF-8, ASCII or CP437.

Latin-1 is in widespread use in the Linux gang. CP850 is mostly used in Western Europe and of course most messages in Fidonet are written in CP866 these days.

It would not surprise me if sbbs marks CP850, Latin-1 and even CP866 as CP437...


Cheers, Michiel

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

Re: Test From Blue Wave Door
By: Michiel van der Vlist to mark lewis on Sun Jun 07 2020 17:26:29


MvdV>>> The point was that without a CHRS kludge one can not expect non
MvdV>>> ASCII to be correctly displayed at the reader's end.

yep... sbbs should be properly applying a CHRS control line to posted
messages based on the message (and header) content...

MvdV> I doubt adding a CHRS kludge after the fact is a good strategy.

i didn't say it did that... i said it should be adding it at the time the message is created and stored in the local message base... i certainly did not imply that it would apply it to all messages being imported...


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

Re: Test From Blue Wave Door
By: Michiel van der Vlist to mark lewis on Sun Jun 07 2020 17:26:29


MvdV>>> Without a CHRS kludge, one is limited to ASCII only if one
MvdV>>> wants it readable at the other end.

true... the point of my response was that the original system
is behind in its updates...

MvdV> Then you were barking up the wrong tree. Puuting the name of
MvdV> the original poster in the To: field would have increased the
MvdV> chance it reached him. *I* can do nothing about it.

my message was not supposed to be directed at the OP... it was absolutely directed at *you* as an informative message about why there was no CHRS control line...


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

Re: Test From Blue Wave Door
By: Michiel van der Vlist to mark lewis on Sun Jun 07 2020 17:26:29

Log Message:
Automatically detect the character set of QWK-imported messages
(that don't already have a FidoNet "CHRS" header) and create/set
the FIDOCHARS header field accordingly (UTF-8, ASCII, or CP437).

MvdV> Determining the type of character encoding is tricky.

you should reread the above more closely and note specifically "QWK-imported" and what it means ;)


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

Hello August,

On Sunday June 07 2020 11:21, you wrote to me:

MvdV>> The sysop of what system? What system in Fidonet has
MvdV>> "5667.fidotest@4:801/194" as its address?

4:801/194 exists in my nodelist.

It also exists in mine. But "5667.fidotest@4:801/194" does not. If you want to argue that it adresses a partular user:

1) user.name@zone:net/node.point is NOT an accepted way of getting mail to a paricular user. The accepted way is to put the user name in the To: field of a message and the zone:net/ node.point in the adress field.

2) "5667.fidotest" is not a user name. It obviously is some kind of mesaage number in the area : fidotest".

Whatever way you twist it, "5667.fidotest@4:801/194" is NOT the address of a system in Fidonet.


Cheers, Michiel

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

Hello Michiel!

** On Sunday 07.06.20 - 19:43, Michiel van der Vlist wrote to August Abolins:

4:801/194 exists in my nodelist.

MvdV> It also exists in mine. But "5667.fidotest@4:801/194" does not. If you
MvdV> want to argue that it adresses a partular user:

MvdV> 1) user.name@zone:net/node.point is NOT an accepted way of getting mail
MvdV> to a paricular user. The accepted way is to put the user name in the
MvdV> To: field of a message and the zone:net/ node.point in the adress
MvdV> field.

OpenXP has no problem with that. ;)

If I want to quote/reply, Ctrl-P generates this:

�� Private message (quote) ��������������������������������������������Ŀ
� �
� To Michiel van der Vlist@2:280/5555 �
� �
� Subject Test From Blue Wave Door �
� � �������������������������������������������������������������������������

It would have no problem with:

�� Private message (quote) ��������������������������������������������Ŀ
� �
� To 5667.fidotest@4:801/194 �
� �
� Subject Test From Blue Wave Door �
� � �������������������������������������������������������������������������

I do not have two fields to worry about. "To" above has some smarts built into it and simplified for me.

This will VERY MUCH get to sent to 4:801/194, no problem.


MvdV> 2) "5667.fidotest" is not a user name. It obviously is some kind of
MvdV> mesaage number in the area : fidotest".

The user name is irrelevant. There is no public list of all users on a BBS akin to no public list of all users at @vandervlist.com

All that matters is that the message to 5667.fidotest gets delivered to 4:801/194. What happens to it is up to the sysop.


MvdV> Whatever way you twist it, "5667.fidotest@4:801/194" is NOT the address
MvdV> of a system in Fidonet.

Correct. 4:801.194 is the "address", and 5667.fidotest is the "name".

No problem. ;)


../|ug

--- OpenXP 5.0.44
* Origin: This is a test of the Emergency Tagline System (2:221/1.58)

Hello mark,

On Sunday June 07 2020 12:39, you wrote to me:

yep... sbbs should be properly applying a CHRS control line to
posted messages based on the message (and header) content...

MvdV>> I doubt adding a CHRS kludge after the fact is a good strategy.

i didn't say it did that... i said it should be adding it at the time
the message is created and stored in the local message base... i
certainly did not imply that it would apply it to all messages being imported...

Let me refrase. I doubt adding a CHRS kludge after it was out of the hands of the writer is a good strategy.


Cheers, Michiel

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

Hello mark,

On Sunday June 07 2020 12:43, you wrote to me:

MvdV>> Then you were barking up the wrong tree. Putting the name of
MvdV>> the original poster in the To: field would have increased the
MvdV>> chance it reached him. *I* can do nothing about it.

my message was not supposed to be directed at the OP... it was
absolutely directed at *you* as an informative message about why there
was no CHRS control line...

Why did you think that information was of any use to me? There is nothing I can do about it.

Or are you trying to flood me with useless information?


Cheers, Michiel

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

Hello mark,

On Sunday June 07 2020 12:45, you wrote to me:

Log Message:
Automatically detect the character set of QWK-imported messages
(that don't already have a FidoNet "CHRS" header) and create/set
the FIDOCHARS header field accordingly (UTF-8, ASCII, or CP437).

MvdV>> Determining the type of character encoding is tricky.

you should reread the above more closely and note specifically "QWK-imported" and what it means ;)

Then widen your horizon. The problem of letting software determine the character encoding of text is tricky. Independant of the source.

Cheers, Michiel

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

Hello August,

On Sunday June 07 2020 14:40, you wrote to me:

MvdV>> 1) user.name@zone:net/node.point is NOT an accepted way of getting
MvdV>> mail to a paricular user. The accepted way is to put the user name
MvdV>> in the To: field of a message and the zone:net/ node.point in the
MvdV>> adress field.

OpenXP has no problem with that. ;)

Good for OpenXP, but that still does not make it a valid Fdionet address.

It would have no problem with:

┌─ Private message (quote)

──────────────────────────� ��──────────────────┐ │

│ │ To 5667.fidotest@4:801/194

So OpenXP has something extra intelligence build in. Good. But it does not make it a valid Fidonet address.

MvdV>> 2) "5667.fidotest" is not a user name. It obviously is some
MvdV>> kind of mesaage number in the area : fidotest".

The user name is irrelevant.

There is no public list of all users on a
BBS akin to no public list of all users at @vandervlist.com

vandervlist.com belongs to a transport company. It has nothing to do with me, it isn't even family. But even if it were it it has nothing to with Fidonet. user.name@vandervlist.com will never arrive at my fdionet system, because it is not a valid address recognised by my fdionet system.

MvdV>> Whatever way you twist it, "5667.fidotest@4:801/194" is NOT the
MvdV>> address of a system in Fidonet.

Correct. 4:801.194 is the "address", and 5667.fidotest is the "name".

No problem. ;)

FTS-0009 says "valid return address in the orignating network". At best "5667.fidotest@4:801/194" is the concatenation of a (fake) name and an address.


Cheers, Michiel

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

Hello August,

On Sunday June 07 2020 14:40, you wrote to me:

@CHRS: IBMPC 2

BTW pse note that the use of "IBMPC" is not recommended as it has evolved from the original meaning of "the character set of the original IBM PC" to "any codepage supported by the IBM PC clone's hardware."

So it can mean CP850 or CP866. You can not expect to have the expected result in an international forum.

See FTS-5003.

Cheers, Michiel

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

Re: Test From Blue Wave Door
By: Michiel van der Vlist to Mauro Veiga on Sun Jun 07 2020 03:21 pm

Hello Mauro,

On Saturday June 06 2020 19:56, you wrote to JAY HARRIS:

@MSGID: 5667.fidotest@4:801/194 23416b7c

"5667.fidotest@4:801/194" is not a valid return address in the originating network.

It is. Send a netmail there and it'll reach the sysop.

@REPLY: 1:229/664.0 5eda5e18
@TZUTC: -0300
@TID: SBBSecho 3.06-Win32 r3.101 Jan 1 2019 MSC 1800

No CHRS kludge.

The OP needs to upgrade his version of SBBSecho to get auto-generated CHRS control lines.

digital man

This Is Spinal Tap quote #28:
We've got Armadillos in our trousers. It's really quite frightening.
Norco, CA WX: 72.3�F, 52.0% humidity, 7 mph SE wind, 0.00 inches rain/24hrs
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Re: Test From Blue Wave Door
By: Michiel van der Vlist to mark lewis on Sun Jun 07 2020 04:18 pm

Hello mark,

On Sunday June 07 2020 09:47, you wrote to me:

MvdV>> No CHRS kludge.

the OP is behind in his updates... sbbs and sbbsecho have been through a lot of changes and updates in the last 1.5 years...

The point was that without a CHRS kludge one can not expect non ASCII to be correctly displayed at the reader's end.

Without a CHRS kludge, one is limited to ASCII only if one wants it

readable

at the other end.

Yup. And the solution is a software-update. :-)

digital man

Synchronet "Real Fact" #31:
The Synchronet IRC server (ircd) was written in JS by Randy Sommerfeld (Cyan). Norco, CA WX: 72.3�F, 52.0% humidity, 7 mph SE wind, 0.00 inches rain/24hrs
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hello Michiel!

** On Sunday 07.06.20 - 21:39, Michiel van der Vlist wrote to August Abolins:

OpenXP has no problem with that. ;)

MvdV> Good for OpenXP, but that still does not make it a valid Fdionet
MvdV> address.

Sure it does! Read on.


MvdV> So OpenXP has something extra intelligence build in. Good. But it does
MvdV> not make it a valid Fidonet address.

:) Read on.


MvdV>> Whatever way you twist it, "5667.fidotest@4:801/194" is NOT the
MvdV>> address of a system in Fidonet.

Correct. 4:801.194 is the "address", and 5667.fidotest is the "name".

No problem. ;)

MvdV> FTS-0009 says "valid return address in the orignating network". At best
MvdV> "5667.fidotest@4:801/194" is the concatenation of a (fake) name and an
MvdV> address.

Ah... you are ASSUMING that a "valid return address" = "valid real name "+"address". But that is not what FTS-0009 says at all.

It just says that info on that line can be constructed so that it can be returned in a valid way.

And that is what OpenXP can do.

I have no doubt that a message to user 5667.fidotest at 4:801/194 will get validly returned. All the "parts" are there.


../|ug

--- OpenXP 5.0.44
* Origin: This is a test of the Emergency Tagline System (2:221/1.58)

Hello Michiel!

** On Sunday 07.06.20 - 21:52, Michiel van der Vlist wrote to August Abolins:

@CHRS: IBMPC 2

MvdV> BTW pse note that the use of "IBMPC" is not recommended as it has
MvdV> evolved from the original meaning of "the character set of the original
MvdV> IBM PC" to "any codepage supported by the IBM PC clone's hardware."

Yes.. I noticed that little niggly detail. :(

At this time, I cannot do anything about it.


MvdV> So it can mean CP850 or CP866. You can not expect to have the expected
MvdV> result in an international forum.

MvdV> See FTS-5003.

Noted!


../|ug

--- OpenXP 5.0.44
* Origin: This is a test of the Emergency Tagline System (2:221/1.58)

Re: Test From Blue Wave Door
By: Michiel van der Vlist to August Abolins on Sun Jun 07 2020 19:43:06


MvdV> 1) user.name@zone:net/node.point is NOT an accepted way of getting
MvdV> mail to a paricular user. The accepted way is to put the user name
MvdV> in the To: field of a message and the zone:net/ node.point in the
MvdV> adress field.

there is no such thing as two fields for To name and destination address in sbbs... they are combined into the standard blahblah@foo format...

MvdV> 2) "5667.fidotest" is not a user name. It obviously is some kind
MvdV> of mesaage number in the area : fidotest".

where is it stated in FTS-0009 that there is a user name required in the MSGID string?

MvdV> Whatever way you twist it, "5667.fidotest@4:801/194" is NOT the
MvdV> address of a system in Fidonet.

why don't you try it and see if you get a response or bounce instead of arguing about something you don't know about with your limited horizon? i mean, you don't even run a BBS which is what fidonet is based on ;)


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

Re: Test From Blue Wave Door
By: Michiel van der Vlist to mark lewis on Sun Jun 07 2020 21:28:44

i didn't say it did that... i said it should be adding it at the time
the message is created and stored in the local message base... i
certainly did not imply that it would apply it to all messages being
imported...

MvdV> Let me refrase. I doubt adding a CHRS kludge after it was out of
MvdV> the hands of the writer is a good strategy.

when does your editor add the CHRS line? can it properly do it before or after you have written your message? think about it ;)


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

Re: Test From Blue Wave Door
By: Michiel van der Vlist to mark lewis on Sun Jun 07 2020 21:30:52

my message was not supposed to be directed at the OP... it was
absolutely directed at *you* as an informative message about why
there was no CHRS control line...

MvdV> Why did you think that information was of any use to me?

who said it was to be of any use to you? it was just information that you might should be aware of... being so aware, you could have informed the OP they were behind in their updates instead of simply complaining about a flaw in their software that has been fixed alread...

MvdV> There is nothing I can do about it.

mmmhummm... you complained... that's a negative... you could have been positive and pointed them to the need to update...

MvdV> Or are you trying to flood me with useless information?

RLY? after all these years, you still don't know me...


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

Re: Test From Blue Wave Door
By: Michiel van der Vlist to mark lewis on Sun Jun 07 2020 21:34:06

you should reread the above more closely and note specifically
"QWK-imported" and what it means ;)

MvdV> Then widen your horizon.

my horizon is much wider than your's... at least i run a BBS ;)

MvdV> The problem of letting software determine the character
MvdV> encoding of text is tricky. Independant of the source.

says he who doesn't even code for this stuff any more...


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

Re: Test From Blue Wave Door
By: August Abolins to Michiel van der Vlist on Sun Jun 07 2020 16:48:00


MvdV>> FTS-0009 says "valid return address in the orignating network".
MvdV>> At best "5667.fidotest@4:801/194" is the concatenation of a
MvdV>> (fake) name and an address.

Ah... you are ASSUMING that a "valid return address" = "valid real name
"+"address". But that is not what FTS-0009 says at all.

but WAIT!!! he's a scientist! he has degrees! he knows how to program! he's never wrong! just ask him! :lol:

It just says that info on that line can be constructed so that it
can be returned in a valid way.

exactly... it doesn't say "be returned to the original poster" ;)


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

Hello Rob,

On Sunday June 07 2020 13:23, you wrote to me:

"5667.fidotest@4:801/194" is not a valid return address in the
originating network.

It is. Send a netmail there and it'll reach the sysop.

I can not send netmail "there" as it is not a valid FTN address.


Cheers, Michiel

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

Hello August,

On Sunday June 07 2020 16:48, you wrote to me:

MvdV>>> Whatever way you twist it, "5667.fidotest@4:801/194" is NOT
MvdV>>> the address of a system in Fidonet.

Correct. 4:801.194 is the "address", and 5667.fidotest is the
"name".

So "5667.fidotest@4:801/194" is NOT and address.

MvdV>> FTS-0009 says "valid return address in the orignating network".
MvdV>> At best "5667.fidotest@4:801/194" is the concatenation of a
MvdV>> (fake) name and an address.

Ah... you are ASSUMING that a "valid return address" = "valid real
name "+"address".

On the contrary. What I am saying is that "real name"+"address" is NOT an address.

But that is not what FTS-0009 says at all.

Indeed. It says "valid returm address in the originating network" "5667.fidotest@4:801/194" is not a vaild ADDRESS!

It just says that info on that line can be constructed so that it can
be returned in a valid way.

It sats nothing about "construed". All it says is "valid return address".

I have no doubt that a message to user 5667.fidotest at 4:801/194 will
get validly returned. All the "parts" are there.

1) "5667.fidotest at 4:801/194" != "5667.fidotest@4:801/194"

2) 5667.fidotest is not the name of the user that wrote the message. So it will never reach the user that wrote te message.


Cheers, Michiel

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

Thats better!

Hello August,

On Sunday June 07 2020 17:47, you wrote to me:


That's better!

MvdV>> BTW pse note that the use of "IBMPC" is not recommended as it
MvdV>> has evolved from the original meaning of "the character set of
MvdV>> the original IBM PC" to "any codepage supported by the IBM PC
MvdV>> clone's hardware."

Yes.. I noticed that little niggly detail. :(

At this time, I cannot do anything about it.

Of course you can do something about it. You can stop using the outdated software.

MvdV>> So it can mean CP850 or CP866. You can not expect to have the
MvdV>> expected result in an international forum.

MvdV>> See FTS-5003.

Noted!

Good . ;-)


Cheers, Michiel

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

Hello mark,

On Sunday June 07 2020 20:21, you wrote to me:

there is no such thing as two fields for To name and destination
address in sbbs... they are combined into the standard blahblah@foo format...

That's sbbs. sbbs is not part of Fidonet. Fidonet starts and ends with the *.pkt. In the *.pkt name and address are not combined in one field.

MvdV>> 2) "5667.fidotest" is not a user name. It obviously is some
MvdV>> kind of mesaage number in the area : fidotest".

where is it stated in FTS-0009 that there is a user name required in
the MSGID string?

It does not. It mentions "address". A "what looks like a name"+"address" is not an address.

MvdV>> Whatever way you twist it, "5667.fidotest@4:801/194" is NOT the
MvdV>> address of a system in Fidonet.

why don't you try it

I am unable to try it. My software will not generate a *.pkt where name and address are combined in one field.

you don't even run a BBS which is what fidonet is based on ;)

Fidonet is based on mailers sending messages from one system to another. What happens when the messages arrive at the recieving system is not part of Fidonet.

When I learned about pointing some thirty years ago and climbed the learning curve, I quicky lost interest in BBSs. Exchanging messages via a point system is much more comfortable than doing it via a BBS. On top of that running a point system is half way up the hill to running a fully fledged Fidonet node.

So indeed, I dropped bothering with the outdated concept of exchanging messages via the detour of a BBSs some 30 years ago. There are better ways to participate in Fidonet.


Cheers, Michiel

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

Hello mark,

On Sunday June 07 2020 20:27, you wrote to me:

when does your editor add the CHRS line? can it properly do it before
or after you have written your message? think about it ;)

Why do you ask? You can see in my tearline what editor I am using. It is in widespread use in Fidonet. Are you not familiar with it? If not, widen your horizon.


Cheers, Michiel

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

Hello mark,

On Sunday June 07 2020 20:31, you wrote to me:

my message was not supposed to be directed at the OP... it was
absolutely directed at *you* as an informative message about why
there was no CHRS control line...

MvdV>> Why did you think that information was of any use to me?

who said it was to be of any use to you?

If you did not think it was of any use to me than why address it to me?

it was just information that you might should be aware of...

The information is of no use to me, I am not using that software.

being so aware, you could have informed the OP they were behind in
their updates

It would have been more efficient if you had informed the OP directly instead of via me.

instead of simply complaining about a flaw in their software that has
been fixed alread...

I was not complaining, I was reporting an anomaly and warning the OP that his writings may not show on the receiver's sceen as desired.

MvdV>> There is nothing I can do about it.

mmmhummm... you complained... that's a negative... you could have been positive and pointed them to the need to update...

At the time I was not aware that an update would fix it. But you were, you could have told him directly.

MvdV>> Or are you trying to flood me with useless information?

RLY? after all these years, you still don't know me...

I know lots of your tricks by now. Flooding is one of them..

Cheers, Michiel

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

Hello mark,

On Sunday June 07 2020 20:35, you wrote to me:

you should reread the above more closely and note specifically
"QWK-imported" and what it means ;)

MvdV>> Then widen your horizon.

my horizon is much wider than your's... at least i run a BBS ;)

You run a BBS, I run a set of solar panels. What has it got to do with Fidonet?

MvdV>> The problem of letting software determine the character
MvdV>> encoding of text is tricky. Independant of the source.

says he who doesn't even code for this stuff any more...

Wrong. I am still coding, though not at the same pace as 20 years ago.


Cheers, Michiel

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

Re: Test From Blue Wave Door
By: Michiel van der Vlist to mark lewis on Mon Jun 08 2020 14:17:44

when does your editor add the CHRS line? can it properly do it before
or after you have written your message? think about it ;)

MvdV> Why do you ask?

because you stated that it is wrong to add the CHRS after the message is written... how can the editor/bbs know which CHRS is proper to add if it adds it before the text is written?

MvdV> You can see in my tearline what editor I am using. It is in
MvdV> widespread use in Fidonet. Are you not familiar with it? If not,
MvdV> widen your horizon.

you know i am familiar with it... don't act so stupid... it is not becoming...


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

Re: Test From Blue Wave Door
By: Michiel van der Vlist to mark lewis on Mon Jun 08 2020 14:20:17


MvdV>>> Or are you trying to flood me with useless information?

RLY? after all these years, you still don't know me...

MvdV> I know lots of your tricks by now. Flooding is one of them..

no, it is not... i never play games or pull ""tricks"" like you are trying to attribute to me... you definitely do not know me... instead you try to project your's and other's tricks on me... you lose... again...


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

Hello Michiel!

** On Monday 08.06.20 - 11:15, Michiel van der Vlist wrote to August Abolins:

But that is not what FTS-0009 says at all.

MvdV> Indeed. It says "valid returm address in the originating network"
MvdV> "5667.fidotest@4:801/194" is not a vaild ADDRESS!

It just says that info on that line can be constructed so that it can
be returned in a valid way.

MvdV> It sats nothing about "construed". All it says is "valid return
MvdV> address".

I think your eyes are crossed or something. I never wrote "construed". I think this might explain some of what you are not understanding.

I have no doubt that a message to user 5667.fidotest at 4:801/194 will
get validly returned. All the "parts" are there.

MvdV> 1) "5667.fidotest at 4:801/194" != "5667.fidotest@4:801/194"

Sure, in a purely literal text-based sense.

Why don't you give us YOUR example of what FTS-0009's "^AMSGID: origaddr serialno" should look like for the message we were discussing?


MvdV> 2) 5667.fidotest is not the name of the user that wrote the message. So
MvdV> it will never reach the user that wrote te message.

Good grief. :( The FTS-0009 never says that the particular message has be returned to the user. It just has to be returnable based on the info in
the msgid.

I'm outta here.

../|ug

--- OpenXP 5.0.44
* Origin: This is a test of the Emergency Tagline System (2:221/1.58)

Hello Michiel!

** On Monday 08.06.20 - 11:26, Michiel van der Vlist wrote to August Abolins:

MvdV>> BTW pse note that the use of "IBMPC" is not recommended as it

At this time, I cannot do anything about it.

MvdV> Of course you can do something about it. You can stop using the
MvdV> outdated software.

ROTFL

(Ooops. Now I need help to get up.)


../|ug

--- OpenXP 5.0.44
* Origin: This is a test of the Emergency Tagline System (2:221/1.58)

Hello mark,

On Monday June 08 2020 09:39, you wrote to me:

when does your editor add the CHRS line? can it properly do it
before or after you have written your message? think about it ;)

MvdV>> Why do you ask?

because you stated that it is wrong to add the CHRS after the message
is written...

You are twisting my words. I did not say it was wrong. What I wrote was that automatically determining the character encoding of text is tricky. And that therefore it may not be a good strategy to automatically add a CHRS kludge once it is out of the hands of the writer

how can the editor/bbs know which CHRS is proper to add if it adds it before the text is written?

It doesn't know and can not know and that is not how it works here. The character encoding is selected by the /user before/ writing the message.

MvdV>> You can see in my tearline what editor I am using. It is in
MvdV>> widespread use in Fidonet. Are you not familiar with it? If
MvdV>> not, widen your horizon.

you know i am familiar with it... don't act so stupid... it is not becoming...

So why did you ask if you already know the answer?

......

Cheers, Michiel

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

Hello mark,

On Monday June 08 2020 09:42, you wrote to me:

MvdV>> I know lots of your tricks by now. Flooding is one of them..

no, it is not... i never play games or pull ""tricks"" like you are
trying to attribute to me... you definitely do not know me... instead
you try to project your's and other's tricks on me... you lose...
again...

And a good night to you too Roy.


Cheers, Michiel

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

Re: Test From Blue Wave Door
By: Michiel van der Vlist to mark lewis on Mon Jun 08 2020 23:29:52

you know i am familiar with it... don't act so stupid... it is not

becoming...

MvdV> So why did you ask if you already know the answer?

because i didn't/don't know the answer... i've never attempted to select a character set before writing a message in golded... i've only attempted to change the character set to READ messages... every editor/BBS that i've used has put CP437, IBMPC, or UTF-8 without my knowledge or prompting... 99% of the people in FTNs operate the same way, too... they expect the software to put in the proper CHRS line *IF* they even know about it...


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

On 08 Jun 20 23:39:11, Michiel Van Der Vlist said the following to Mark Lewis:

no, it is not... i never play games or pull ""tricks"" like you are trying to attribute to me... you definitely do not know me... instead you try to project your's and other's tricks on me... you lose... again...

And a good night to you too Roy.

Don't you ever get tired of being right all the time?

Nick

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

Re: Test From Blue Wave Door
By: August Abolins to Michiel van der Vlist on Mon Jun 08 2020 10:17 am

Good grief. :( The FTS-0009 never says that the particular message has be returned to the user. It just has to be returnable based on the info in
the msgid.

FTS-9 doesn't really say that either.

And I think we all now the *purpose* of the Message-ID: to uniquely identify a message (e.g. for use in duplicate message detection and reply-linking). It's not a "return address" and should not be used as one.

digital man

Synchronet/BBS Terminology Definition #69:
SMTP = Simple Message Transfer Protocol
Norco, CA WX: 77.7�F, 10.0% humidity, 0 mph SSE wind, 0.00 inches rain/24hrs --- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

Hello Rob!

** On Monday 08.06.20 - 20:47, Rob Swindell wrote to August Abolins:

Good grief. :( The FTS-0009 never says that the particular message has be
returned to the user. It just has to be returnable based on the info in
the msgid.

FTS-9 doesn't really say that either.

OK.. I get it. "The originating address should be specified in a form
that constitutes a valid return address for the originating network."

The key phrase is "in a form that".

Did an effen lawyer write this shit? LOL I mean.. many of these
writings don't give clear examples.

And I think we all now the *purpose* of the Message-ID: to uniquely identify a message (e.g. for use in duplicate message detection and reply-linking). It's not a "return address" and should not be used as
one.

OK. But the word "purpose" doesn't even enter the document. :/


../|ug

--- OpenXP 5.0.44
* Origin: This is a test of the Emergency Tagline System (2:221/1.58)

Hello August,

On Monday June 08 2020 10:17, you wrote to me:

It just says that info on that line can be constructed so that
it can be returned in a valid way.

MvdV>> It sats nothing about "construed". All it says is "valid return
MvdV>> address".

I think your eyes are crossed or something. I never wrote
"construed". I think this might explain some of what you are not understanding.

OK, my fingers were faster than my brain. They typed "construed" were "contructed" was meant.

Why don't you give us YOUR example of what FTS-0009's "^AMSGID:
origaddr serialno" should look like for the message we were
discussing?

See the MSGID in this message.


Cheers, Michiel

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

Hello mark, �ਢ�� ��ઠ

On Monday June 08 2020 19:06, you wrote to me:

MvdV>> So why did you ask if you already know the answer?

because i didn't/don't know the answer... i've never attempted to
select a character set before writing a message in golded...

If your horizon regarding 8 bit encodings is limited to CP437, you would indeed not need to do that...

i've only attempted to change the character set to READ messages...

Normally one would not have to do that. If the message has a proper CHRS kludge.

every editor/BBS that i've used has put CP437, IBMPC, or UTF-8 without
my knowledge or prompting...

If they are limited to those three encoding that might work. The world of Fidonet is bigger than that howver.

99% of the people in FTNs operate the same way, too...

Unfortunately there is not much sofware around in Fidonet that can properly deal with more than CP437. :(

they expect the software to put in the proper CHRS line *IF* they even know about it...

It may work for those who limit themselves to ASCII, CP437 and UTF-8.

However, as I wrote before, automatically detecting the encoding is tricky. So if more than CP437 is needed, the user needs to interfere to tell the software what the encoding is.


Cheers, Michiel

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

Re: Test From Blue Wave Door
By: August Abolins to Rob Swindell on Tue Jun 09 2020 00:13:00

And I think we all now the *purpose* of the Message-ID: to uniquely
identify a message (e.g. for use in duplicate message detection and
reply-linking). It's not a "return address" and should not be used
as one.

OK. But the word "purpose" doesn't even enter the document. :/

is it really needed with the title written the way it is?

MSGID / REPLY
A standard for unique message identifiers
and reply chain linkage

that seems to state the entire purpose right there ;)


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

Re: Test From Blue Wave Door
By: Michiel van der Vlist to mark lewis on Tue Jun 09 2020 09:23:07


MvdV> However, as I wrote before, automatically detecting the encoding is
MvdV> tricky. So if more than CP437 is needed, the user needs to interfere
MvdV> to tell the software what the encoding is.

so umm... here's an idea... scan the message when/while it is written... the software has to do this anyway, right? so if all the characters are <128, then use CHRS: ASCII otherwise, convert to and use CHRS: UTF-8... poof! no more crazy unsupported unmaintained illogical competing controversial character set muckity muck...


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

Hi August!

08 Jun 2020 10:17, from August Abolins -> Michiel van der Vlist:

Why don't you give us YOUR example of what FTS-0009's "^AMSGID:
origaddr serialno" should look like for the message we were
discussing?

Take a look at your own for an example:
@MSGID: 2:221/1.58@fidonet e53bb3cb

origadr is a 3d/4d/5d Fidonet address.

CU, Ricsi

... The world is coming to an end! Repent and return those library books!
--- GoldED+/LNX
* Origin: Those who can, do. Those who can't, criticize. (2:310/31)

Hello mark,

On Tuesday June 09 2020 08:17, you wrote to me:

MvdV>> However, as I wrote before, automatically detecting the
MvdV>> encoding is tricky. So if more than CP437 is needed, the user
MvdV>> needs to interfere to tell the software what the encoding is.

so umm... here's an idea... scan the message when/while it is
written... the software has to do this anyway, right? so if all the characters are <128, then use CHRS: ASCII otherwise, convert to and
use CHRS: UTF-8... poof! no more crazy unsupported unmaintained
illogical competing controversial character set muckity muck...

Spledid idea. Why do you think I have been advocating UTF-8 in Fidonetr for over a decade?

Just this:

1) To automatically convert from encoding A to UTF-8 one has to know what encoding A is. This may be a problem in some setups.

2) ASCII is a subset of UTF-8. So labeling everything as UTF-8 is no technical problem. But then if all messages are endoded in UTF-8, we can do away with the CHRS kludge all together.

3) Fidonet is not ready yet for a complete move to UTF-8, There is still too much software around that can not handle it. Especially the Russians will not go along.

4) So it is a good idea, in maybe 5 or 10 years...


Cheers, Michiel

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

Re: Test From Blue Wave Door
By: August Abolins to Rob Swindell on Tue Jun 09 2020 12:13 am

And I think we all now the *purpose* of the Message-ID: to uniquely identify a message (e.g. for use in duplicate message detection and reply-linking). It's not a "return address" and should not be used as one.

OK. But the word "purpose" doesn't even enter the document. :/

Right. It's a clearly-established badly-written document that should never have been rubber-stamped. Oh well.

digital man

Synchronet "Real Fact" #80:
85 SBBSecho registrations were sold (at $49) between 1994 and 1996.
Norco, CA WX: 80.3�F, 23.0% humidity, 4 mph E wind, 0.00 inches rain/24hrs
--- SBBSecho 3.11-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)