I wonder if newer versions of Mystic cut all long lines (paragraphs) after 255 characters. So I'm writing some more words until I reach 256 chars to test, if this is really the case. Bla bla bla bla .... If I'm right, this line should be
cut off right now. If I'm wrong, you still can read this.


* Origin: kakistocracy (2:280/464.47)

I wonder if newer versions of Mystic cut all long lines (paragraphs)
after 255 characters. So I'm writing some more words until I reach 256 chars to test, if this is really the case. Bla bla bla bla .... If I'm right, this line should be cut off right now. If I'm wrong, you still
can read this.

I don't have the /latest/ prealpha but have a relatively recent one.

--- Mystic BBS v1.12 A46 2020/03/18 (Linux/64)
* Origin: monterey bbs (1:218/820)

On 04-01-20 10:15, Oli wrote to All <=-

I wonder if newer versions of Mystic cut all long lines (paragraphs)
after 255 characters. So I'm writing some more words until I reach 256 chars to test, if this is really the case. Bla bla bla bla .... If I'm right, this line should be cut off right now. If I'm wrong, you still
can read this.

* Origin: kakistocracy (2:280/464.47)

Looks like it all came through. :)


... This tagline provided free of charge. Taxes may apply.
=== MultiMail/Win v0.51
--- SBBSecho 3.10-Linux
* Origin: Freeway BBS Bendigo,Australia freeway.apana.org.au (3:633/410)

01 Apr 20 01:57, you wrote to me:

I wonder if newer versions of Mystic cut all long lines
(paragraphs) after 255 characters. So I'm writing some more words
until I reach 256 chars to test, if this is really the case. Bla
bla bla bla .... If I'm right, this line should be cut off right
now. If I'm wrong, you still can read this.

I don't have the /latest/ prealpha but have a relatively recent one.

My suspicion is that it started with 2020/03/26 and it might even be fixed in the latest pre-alpha 2020/03/29. There is one Hub in fsxnet that is running this version, the others running 2020/03/12 and are still wrapping the long lines at 79 characters.

I'm not using Mystic, but people discovered that they receive dupes of my mails
and one copy of my mails has paragraphs that are cut at character 255. I think that we tracked the problem down to the hub running 2020/03/26.


* Origin: kakistocracy (2:280/464.47)

Re: > 255 character long lines (paragraphs)
By: Oli to All on Wed Apr 01 2020 10:15:56

I wonder if newer versions of Mystic cut all long lines (paragraphs) after

255 characters. So I'm writing some more words until I reach 256 chars to test, if this is really the case. Bla bla bla bla .... If I'm right,

this line should be
cut off right now. If I'm wrong, you still can read this.

i've not wrapped the above but yes, the long line is broken in two between "be"
and "cut" as you can see above... my terminal window is 226 columns wide...


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

On Wed, 1 Apr 2020, Oli wrote:

I wonder if newer versions of Mystic cut all long lines (paragraphs) after

255

characters. So I'm writing some more words until I reach 256 chars to test,

if

this is really the case. Bla bla bla bla .... If I'm right, this line should

be

cut off right now. If I'm wrong, you still can read this.

Yeah. Happens outside of the BBS-realm:

https://i.imgur.com/CfayWxW.png

I have 80 x 25-and-over terminals.

This is from Alpine running on FBSD goodness ...

But as you see, bad behaviours is easily rehabilated just by replying :D



/
Bud
/

a1=S0
b1=[1..2,'L0L']
a2=2*a1
a3=S1.4#b1
a4=(a2,a3)
a5=64*a4

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

01 Apr 20 09:58:14, mark lewis wrote to Oli:

I wonder if newer versions of Mystic cut all long lines (paragraphs) after 255 characters. So I'm
writing some more words until I reach 256 chars to test, if this is really

the case. Bla bla bla bla

.... If I'm right, this line should be cut off right now. If I'm wrong, you

still can read this.

i've not wrapped the above but yes, the long line is broken in two between

"be" and "cut" as you can

see above... my terminal window is 226 columns wide...

Thanks for the replies guys.

I think I haven't provided enough informations in my mail.

With cut after 255 characters I mean that everything from character 256 just vanishes into digital nirvana, it's not there anymore. I think truncated is the
better word. It seems to happen when a mail passes through Mystic pre-alpha from 2020/03/26 and maybe versions after that (unknown).

Everyone else who doesn't have a Mystic node with that version in their path or
running that version themself should see my messages intact :).


* Origin: (2:280/464.47)

01 Apr 20 22:29:09, Bud Spencer wrote to Oli:

I wonder if newer versions of Mystic cut all long lines (paragraphs) after 255
characters. So I'm writing some more words until I reach 256 chars to test, if
this is really the case. Bla bla bla bla .... If I'm right, this line should

be

cut off right now. If I'm wrong, you still can read this.

Yeah. Happens outside of the BBS-realm:

https://i.imgur.com/CfayWxW.png

I have 80 x 25-and-over terminals.

This is from Alpine running on FBSD goodness ...

But as you see, bad behaviours is easily rehabilated just by replying :D

That looks like it went through Mystic, which applies word wrapping at column 79 (adding CRs) and then the nntp gateway or alpine wraps the lines again. That
is a known thing with Mystic, but it looks like something changed in the pre-alpha from 2020/03/26 and lines (=paragraphs in ftn) now get truncated after 255 characters. I'm not saying I'm 100% confident about it, it is just what our limited data suggests (we did some tests in fsxnet).

--- gossipEd-linux/arm .0.21-18496a58
* Origin: (2:280/464.47)

My suspicion is that it started with 2020/03/26 and it might even be
fixed in th e latest pre-alpha 2020/03/29. There is one Hub in fsxnet
that is running this v ersion, the others running 2020/03/12 and are
still wrapping the long lines at 7 9 characters.

There have been two versions of the tosser one that word wraps and one that doesn't since February, so the date itself wouldn't be a factor it would
depend on which tosser they are using.

Sometime during A46 in March I removed the optional non-wrapping tosser and
now its the only tosser available.

They shouldn't be getting cut off at 256 characters, the line length is unlimited (or at least that is the intention) with the latest pre-alpha. If you find otherwise please let me know because that would be a bug.

--- Mystic BBS v1.12 A46 2020/03/26 (Windows/64)
* Origin: Sector 7 (1:129/215)

Hello g00r00,

They shouldn't be getting cut off at 256 characters, the line length
is unlimited (or at least that is the intention) with the latest pre-alpha. If you find otherwise please let me know because that
would be a bug.

That does seem to be the case currently. I've seen it in my own testing and it's happened to a few messages in fsxNet.

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

On 03 Apr 2020 at 02:13a, g00r00 pondered and said...

They shouldn't be getting cut off at 256 characters, the line length is unlimited (or at least that is the intention) with the latest pre-alpha. If you find otherwise please let me know because that would be a bug.

What I'll work to do is update all three HUBs running Mystic to the latest pre-alpha so everything is on the same playing field. Then we can see what's happening and let you know. Cheers.

--- Mystic BBS v1.12 A46 2020/03/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

04 Apr 20 14:09, you wrote to g00r00:

On 03 Apr 2020 at 02:13a, g00r00 pondered and said...

They shouldn't be getting cut off at 256 characters, the line
length is unlimited (or at least that is the intention) with the
latest pre-alpha. If you find otherwise please let me know
because that would be a bug.

What I'll work to do is update all three HUBs running Mystic to the
latest pre-alpha so everything is on the same playing field. Then we
can see what's happening and let you know. Cheers.

Now everything's really messed up in fsxnet. I told you so ;)


* Origin: kakistocracy (2:280/464.47)

*** Answering a msg posted in area BAD_MSGS.

Hi Paul,

On 1980-01-01 00:00:00, you wrote to and:

Hmmm... :-(

AREA:MYSTIC
@FMAIL BAD: Message too old (2020-04-10 14:10:26)
@FMAIL SRC: 2:292/854
@FMAIL DEST: 2:280/464
@TID: Mystic BBS 1.12 A46
@MSGID: 3:770/100 651d79ff
@REPLY: 1:129/215 5faf9ad6
@TZUTC: 1300
@DATE: 00 00 03:00:00
On 03 Apr 2020 at 02:13a, g00r00 pondered and said...

[...]

--- Mystic BBS v1.12 A46 2020/03/26 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100) SEEN-BY: 203/0 221/1 229/426 261/38 280/464 292/140 854 8125 335/364 SEEN-BY: 801/188 189 190 194 197
@PATH: 770/100 1 317/3 229/426 292/854 261/38 801/189 188 292/854

Or is this a hickup on that system that shows up twice in the path?

Bye, Wilfred.

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

Hi Paul,

On 2020-04-10 14:13:52, I wrote to you:

@MSGID: 3:770/100 651d79ff

@PATH: 770/100 1 317/3 229/426 292/854 261/38 801/189 188 292/854

Or is this a hickup on that system that shows up twice in the path?

It was. I noticed there already was a message in this area with the above MSGID... Sorry for the noice. ;)

Bye, Wilfred.

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

10 Apr 20 14:18, you wrote to Paul Hayton:

Hi Paul,

On 2020-04-10 14:13:52, I wrote to you:

@MSGID: 3:770/100 651d79ff

@PATH: 770/100 1 317/3 229/426 292/854 261/38 801/189 188
292/854

Or is this a hickup on that system that shows up twice in the
path?

It was. I noticed there already was a message in this area with the
above MSGID... Sorry for the noice. ;)

Interesting. At least two nodes in fsxnet received bad packages with scrambled messages. The origin line of 292/854 were in the To, From or Subject field. There were also some empty messages in this area with 2:292/854 in the origin line, but otherwise completely empty. But how do we know that 292/384 is causing the problems? It could be 261/38 too (less likely though).

Btw, 4:801/189, which is in the path between 2:292/854 and 2:292/854, is running an older version of Mystic that
- writes incorrect SEEN-BY lines
- ignores SEEN-BYs
- modifies mails in-transit (line breaking)
- doesn't recognized modified and unmodified mails with the same MSGID as dupes.

Using something like this with fidoweb-style echo routing has to create some problems at some point. Like loops and dupes.


* Origin: kakistocracy (2:280/464.47)

Hi Oli,

On 2020-04-10 17:04:23, you wrote to me:

Interesting. At least two nodes in fsxnet received bad packages with scrambled messages. The origin line of 292/854 were in the To, From or Subject field. There were also some empty messages in this area with 2:292/854 in the origin line, but otherwise completely empty. But how do

we

know that 292/384 is causing the problems? It could be 261/38 too (less likely though).

It happend when 2:292/854 reset his PC earlier this week when he returned from the hospital, that caused some problematic pkts to be exported from his system. Today there was another event with the same symptoms. This happend before several times when he returned from his holidays in the states for example...

Using something like this with fidoweb-style echo routing has to
create some problems at some point. Like loops and dupes.

Some are caught on my system when they have an older date (like >60 days). And dupes are of course also caught. Everything else that is more or less a legit message (although from:, subject: and body are empty for instance) passes through... But this caused irex to crash on one of my downlinks.

Bye, Wilfred.

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

Hello g00r00,

They shouldn't be getting cut off at 256 characters, the line length
is unlimited (or at least that is the intention) with the latest pre-alpha. If you find otherwise please let me know because that
would be a bug.

This is indeed the case. I did some testing yesterday with..

Mystic BBS v1.12 A46 Linux/64 Compiled 2020/04/09 22:56:56.

Please let us know if you would like further testing/input.

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

This is indeed the case. I did some testing yesterday with..

Mystic BBS v1.12 A46 Linux/64 Compiled 2020/04/09 22:56:56.

Please let us know if you would like further testing/input.

Ttyl :-),
Al

what happened to the subject and your name?



* Origin: kakistocracy (2:280/464.47)

Hello Oli,

what happened to the subject

I'm not sure why suject lines get a little mixed up. It might be a slackware thing but I haven't been able to figure out why that happens.

and your name?

I haven't had any replies so I'm just trying to be sure my mail got through since it was in important feedback.

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

This is indeed the case. I did some testing yesterday with..

Mystic BBS v1.12 A46 Linux/64 Compiled 2020/04/09 22:56:56.

Please let us know if you would like further testing/input.

Thanks for letting me know.

I have uploaded a 4/11 version which should/may address this issue. I found a function that was using an old 255 character string type, so the line of text was accidentally getting cut off when passed to that function.

--- Mystic BBS v1.12 A46 2020/04/11 (Windows/64)
* Origin: Sector 7 (1:129/215)

Hello g00r00,

Thanks for letting me know.

No problem, thanks for looking into this.

I have uploaded a 4/11 version which should/may address this issue. I found a function that was using an old 255 character string type, so
the line of text was accidentally getting cut off when passed to that function.

I just tested this and long lines are still being truncated at about 255 characters.

Let us know if an update is available to test.

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

I have uploaded a 4/11 version which should/may address this issue. found a function that was using an old 255 character string type, so the line of text was accidentally getting cut off when passed to that function.

I just tested this and long lines are still being truncated at about 255 characters.

Can you send me a pkt which you are using to test with to mysticbbs@gmail.com?

--- Mystic BBS v1.12 A46 2020/04/11 (Windows/64)
* Origin: Sector 7 (1:129/215)

Hello g00r00,

I just tested this and long lines are still being truncated at
about 255 characters.

Can you send me a pkt which you are using to test with to mysticbbs@gmail.com?

Can do, it'll be in your email shortly.

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Can you send me a pkt which you are using to test with to mysticbbs@gmail.com?

Can do, it'll be in your email shortly.

I didn't have a chance to run the packet through to test yet, but I did end up finding one more place that used an old DOS type where it would potentially cause it to get truncated at 255 characters. That should be fixed now in the latest build on the prealpha area.

I'll try to get a test done sometime soon as well, if you don't beat me to it.

--- Mystic BBS v1.12 A46 2020/04/13 (Windows/64)
* Origin: Sector 7 (1:129/215)

Hello g00r00,

I didn't have a chance to run the packet through to test yet, but I
did end up finding one more place that used an old DOS type where it
would potentially cause it to get truncated at 255 characters. That should be fixed now in the latest build on the prealpha area.

I'll try to get a test done sometime soon as well, if you don't beat
me to it.

The current prealpha v1.12 A46 Linux/64 Compiled 2020/04/13 15:00:48 is working
well in my tests.

Messages look good in Mystic when reading and replying and outgoing .pkt's also
look good to me.

Thank you for this and all you do with Mystic.

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

The current prealpha v1.12 A46 Linux/64 Compiled 2020/04/13 15:00:48 is working well in my tests.

Messages look good in Mystic when reading and replying and outgoing
.pkt's also look good to me.

Thanks for your help with this! Glad to have it fixed up!

I'm going to enable some tossing optimizations in the next build so if you notice anything weird coming from Mystic systems after the build you tested with please let me know.

Thanks again.

--- Mystic BBS v1.12 A46 2020/04/13 (Windows/64)
* Origin: Sector 7 (1:129/215)

*** Quoting John Smith from a message to g00r00 ***

The current prealpha v1.12 A46 Linux/64 Compiled 2020/04/13 15:00:48 i
well in my tests.

Messages look good in Mystic when reading and replying and outgoing .p
look good to me.

Just curious to see if the latest build has been compiled for OS/2 as well :)

--- Telegard/2 v3.09.g2-sp4/mL
* Origin: Omicron Theta/2 * Southaven, MS * os2bbs.org:2300 (1:261/20)

Hello g00r00,

I'm going to enable some tossing optimizations in the next build so if
you notice anything weird coming from Mystic systems after the build
you tested with please let me know.

We have noticed that when Mystic is tossing incoming mail to connected links it
doesn't seem to be looking in the seen-bys. Even if a link is listed in the SEEN+BYs Mystic is still tossing that mail to the linked node anyway.

Aside from that that though I think all is well.. :)

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

We have noticed that when Mystic is tossing incoming mail to connected links it doesn't seem to be looking in the seen-bys. Even if a link is listed in the SEEN+BYs Mystic is still tossing that mail to the linked node anyway.

It used to at one point but I believe people seemed to think it should be done using the PATH instead, which is what it does now.

It looks like I still have the SEEN-BY checking code in there commented out, although I have no idea if it still works with the current code.

Maybe one reason for this is that some systems and many tossers have the
option to modify or remove SEEN-BY?

--- Mystic BBS v1.12 A46 2020/04/17 (Windows/64)
* Origin: Sector 7 (1:129/215)

Hello g00r00,

It used to at one point but I believe people seemed to think it should
be done using the PATH instead, which is what it does now.

The path does have a role to play but path lines are not the same as seen-bys. Every node who has seen the message should be listed in the seen-bys but not necessarily the path lines. Once a node has seen a message we don't want to send that message there anymore.

Mystic doesn't seem to be looking at the path now either.

It looks like I still have the SEEN-BY checking code in there
commented out, although I have no idea if it still works with the
current code.

My details are sketchy at best. I'm sure there is an FTSC doc that talks about SEEN+BYs that could give you better direction that I can. I'll take a look and see what I can find and pass the filename to you.

Maybe one reason for this is that some systems and many tossers have
the option to modify or remove SEEN-BY?

Yep, we don't want any of that.

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Hello g00r00,

I'm sure there is an FTSC doc that talks about SEEN+BYs that could
give you better direction that I can. I'll take a look and see what I
can find and pass the filename to you.

There is fts-0004.001. It's quite an old document from around 1987!

It talks about the old conference mail system that I think is more or less what
we still use today.

That and other docs can be found at the FTSC website..

http://ftsc.org

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

We have noticed that when Mystic is tossing incoming mail to connecte links it doesn't seem to be looking in the seen-bys. Even if a link i listed in the SEEN+BYs Mystic is still tossing that mail to the linke node anyway.

It used to at one point but I believe people seemed to think it should
be done using the PATH instead, which is what it does now.

It looks like I still have the SEEN-BY checking code in there commented out, although I have no idea if it still works with the current code.

I uploaded "seenbytosser.zip" to the Prealpha area which has a Win32 and Linux64 version of the tosser which has the SEEN-BY checking on if you'd like to test it. This also leaves on the PATH checking too so it does both plus
the typical CRC stuff.

--- Mystic BBS v1.12 A46 2020/04/17 (Windows/64)
* Origin: Sector 7 (1:129/215)

The path does have a role to play but path lines are not the same as

Thanks for the explaination, but please realize I wrote a tosser and multiple mailers from scratch that implement these things so I do understand what they are. :)

Mystic doesn't seem to be looking at the path now either.

It does check path when tossing against the address associated to the message base being processed, as long as the address associated is a 3D address only. I can see the logging in my test network from circular PATH checking. If you have a specific situation where you think that isn't the case then let me know.

My details are sketchy at best. I'm sure there is an FTSC doc that talks about SEEN+BYs that could give you better direction that I can. I'll
take a look and see what I can find and pass the filename to you.

I am not looking for any direction on SEEN-BY lines at the moment.

They are implemented correctly in Mystic, but as said the dupe checking based on them was intentionally disabled a while back (a long long time ago). They don't work well past 3D addresses and at least back in the day they were commonly stripped or trimmed.

The PATH checking and CRC is mostly sufficient in dupe loops unless you're intentionally setting up a situation (which I think you guys are) that creates a "bad topology" as defined in FTSC. Ironically the FTSC for SEEN-BY and PATH will actually tell you that their purpose is to identify and dissolve those "bad" topologies.

Anyway I don't mind re-enabling it though if you're willing to test it.

--- Mystic BBS v1.12 A46 2020/04/17 (Windows/64)
* Origin: Sector 7 (1:129/215)

Hello g00r00,

The path does have a role to play but path lines are not the same
as

Thanks for the explaination, but please realize I wrote a tosser and multiple mailers from scratch that implement these things so I do understand what they are. :)

No one is questioning your knowledge or experience.

The PATH checking and CRC is mostly sufficient in dupe loops unless
you're intentionally setting up a situation (which I think you guys
are) that creates a "bad topology" as defined in FTSC. Ironically the FTSC for SEEN-BY and PATH will actually tell you that their purpose is
to identify and dissolve those "bad" topologies.

I'm talking about the fsxNet hubs. They are linked together and meshing. I think they are doing all that right?

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Re: Re: >er ter ter ter long lines (paragraphs)
By: g00r00 to John Smith on Sun Apr 19 2020 16:21:01

It used to at one point but I believe people seemed to think it should be

done using the PATH instead, which is what it does now.

It looks like I still have the SEEN-BY checking code in there commented out,

although I have no idea if it still works with the current code.

tossers should do both... path checking is the CPD (Circular Path Detection) which was implemented to prevent dupe loops... it also works with VIA lines in netmail to detect and stop netmal routing loops...

the seenby should always be checked to prevent sending dupes... always...

seenbys should also be sorted in net order and the list of seenbys rewritten each time addresses are added to it...

this is old school common knowledge... i don't know if there's a document covering it or not... possibly the only one is FTSC-0004 but it is possible there may be something in the historical library along the line of "this is what i found out"...


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

the seenby should always be checked to prevent sending dupes... always...

They shouldn't *always* be checked when tossing, but I agree with what you're getting at. Its good to apply it to all 3D scenarios. If its applied to point systems, 5D scenarios, or gating then it will break things.

seenbys should also be sorted in net order and the list of seenbys rewritten each time addresses are added to it...

Yep yep, I'm aware of how it works! :)

--- Mystic BBS v1.12 A46 2020/04/19 (Windows/64)
* Origin: Sector 7 (1:129/215)

On 19 Apr 2020 at 06:13p, g00r00 pondered and said...

I uploaded "seenbytosser.zip" to the Prealpha area which has a Win32 and Linux64 version of the tosser which has the SEEN-BY checking on if you'd like to test it. This also leaves on the PATH checking too so it does both plus the typical CRC stuff.

Thank you, I am testing this with the fsxNet NET 1 HUB.

--- Mystic BBS v1.12 A46 2020/04/13 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Hello g00r00,

I uploaded "seenbytosser.zip" to the Prealpha area which has a Win32
and Linux64 version of the tosser which has the SEEN-BY checking on if you'd like to test it. This also leaves on the PATH checking too so
it does both plus the typical CRC stuff.

One of the hubs is running this version. Currently mail passing through that hub loses all it kludges. There are no header kludges at all, no msgid, no tzutc, nothing.

The path line doesn't mention the originating node after that, it seems to originate at the hub.

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

I uploaded "seenbytosser.zip" to the Prealpha area which has a Win32 Linux64 version of the tosser which has the SEEN-BY checking on if yo like to test it. This also leaves on the PATH checking too so it doe both plus the typical CRC stuff.

Thank you, I am testing this with the fsxNet NET 1 HUB.

Make sure you have the one dated 4/20. I made a mistake in the first one - the old code required a little update so the 4/19 dated one is probably horribly broken.

Hopefully all of that happened while you were asleep though!

Keep in mind if this is enabled, things like FidoNet or anything past 2D addressing will be problematic. For example a message in Fido that passes through 1:1/1 will never toss to 2:1/1 or 3:1/1 because "1/1" will be seen as already sent. I suspect this is one of the reasons we ended up turning it off to begin with.

I will try to have another update that will detect that scenario when tossing and be smart enough to let those messages go through but the current version only does that for point systems (not intra-zone).

--- Mystic BBS v1.12 A46 2020/04/20 (Windows/64)
* Origin: Sector 7 (1:129/215)

One of the hubs is running this version. Currently mail passing through that hub loses all it kludges. There are no header kludges at all, no msgid, no tzutc, nothing.

I have also been running the same tosser. Are you seeing those issues here?

--- Mystic BBS v1.12 A46 2020/04/20 (Windows/64)
* Origin: Sector 7 (1:129/215)

One of the hubs is running this version. Currently mail passing through that hub loses all it kludges. There are no header kludges at all, no msgid, no tzutc, nothing.

Rather than wait to hear back from the test message I sent you, I decided to set up a test here and I can see the issue.

Its unrealted to the SEEN-BY changes, it was related to some optimizations I did before that. I've backed out those optimizations for now and they're showing up again.

I am going to update the prealphas now which will have the tosser it in with the seen-by and this fix.

--- Mystic BBS v1.12 A46 2020/04/20 (Windows/64)
* Origin: Sector 7 (1:129/215)

Hello g00r00,

One of the hubs is running this version. Currently mail passing
through that hub loses all it kludges. There are no header
kludges at all, no msgid, no tzutc, nothing.

I have also been running the same tosser. Are you seeing those issues here?

No, I don't see that here. Hopefully Paul can check the date of the one he is using and will be able to update.

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Hello g00r00,

I am going to update the prealphas now which will have the tosser it
in with the seen-by and this fix.

Awesome. Let us know when those are ready.

Ttyl :-),
Al

--- GoldED+/LNX
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

I am going to update the prealphas now which will have the tosser it in with the seen-by and this fix.

Awesome. Let us know when those are ready.

Sorry I might not have been clear but they were uploaded right when I posted that! The should be dated 4/20/2020.

--- Mystic BBS v1.12 A46 2020/04/20 (Windows/64)
* Origin: Sector 7 (1:129/215)

On 20 Apr 2020 at 11:56a, g00r00 pondered and said...

Make sure you have the one dated 4/20. I made a mistake in the first
one - the old code required a little update so the 4/19 dated one is probably horribly broken.

Hopefully all of that happened while you were asleep though!

I'd just pulled down the stand alone zip that had the x 2 MUTIL's in them James.. so yeah perhaps I did get an earlier one. Just reading some of the threads here and I'll look to pull down the latest pre-alpha and update the
HUB to that ASAP. Thanks for looking at this.

--- Mystic BBS v1.12 A46 2020/04/13 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)