* Originally in ipv6
* Crossposted in fmail_help

31 Jan 18 09:05:00, you wrote to Michiel van der Vlist:

BTW...

@MSGID: 239.fido-ipv6@3:633/410 1ed58d3d

My software (Fmail, Golded) does not like your not FTS-0009 complient
MSGID. It breaks the reply linking.. :(

Complain to the author of Synchronet. ;)

It has been done. He doesn't care. ;(

When using JAM, the bad format of MSGID doesn't matter, JAM has MSGIDcrc and REPLYcrc, which can be used in reply linking. "hpt link -j".

How does Fmail handle the linking?

'Tommi

... he.net certified sage
---
* Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)

Hi Tommi,

On 31 Jan 18 07:45, Tommi Koivula wrote to Tony Langdon:
about: "ipv6":

BTW...

@MSGID: 239.fido-ipv6@3:633/410 1ed58d3d

My software (Fmail, Golded) does not like your not FTS-0009
complient MSGID. It breaks the reply linking.. :(

Complain to the author of Synchronet. ;)

It has been done. He doesn't care. ;(

He does care! Because if he does change it, it will break existing code. The none standard synchronet MSGID is used internally in it's messagebase, afaik.

In my opinion a wrong design decision to use the MSGID for this. But apparently
difficult to fix...

When using JAM, the bad format of MSGID doesn't matter, JAM has
MSGIDcrc and REPLYcrc, which can be used in reply linking. "hpt link
-j".

How does Fmail handle the linking?

It seems to work fine in jam messagebases when there are synchronet msgid's involved...


Wilfred.

--- FMail-W32 2.0.1.4
* Origin: point@work (2:280/464.112)

31 Jan 18 08:41, Wilfred van Velzen wrote to Tommi Koivula:

@MSGID: 239.fido-ipv6@3:633/410 1ed58d3d

My software (Fmail, Golded) does not like your not FTS-0009
complient MSGID. It breaks the reply linking.. :(

Complain to the author of Synchronet. ;)

It has been done. He doesn't care. ;(

He does care! Because if he does change it, it will break existing code. The none standard synchronet MSGID is used internally in it's messagebase, afaik. In my opinion a wrong design decision to use the MSGID for this. But apparently difficult to fix...

Ok..

When using JAM, the bad format of MSGID doesn't matter, JAM has
MSGIDcrc and REPLYcrc, which can be used in reply linking. "hpt link
-j".

How does Fmail handle the linking?

It seems to work fine in jam messagebases when there are synchronet

msgid's

involved...

So Michiel is not using JAM ? Or how come his reply-linking isn't working ?

'Tommi

--- hpt/os2-emx 1.9.0-cur 17-02-17
* Origin: 2001:470:1f15:cb0:f1d0:2:221:0 (2:221/0)

Hi Tommi,

On 2018-01-31 09:48:10, you wrote to me:

How does Fmail handle the linking?

It seems to work fine in jam messagebases when there are synchronet
msgid's involved...

So Michiel is not using JAM ?

He is, afaik.

Or how come his reply-linking isn't working ?

I don't know. ;)

There is the "Update reply chains" option, but if you turn that off, it wouldn't work at all, not just for messages generated by synchronet.

Bye, Wilfred.

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

Hello Wilfred,

On Wednesday January 31 2018 09:19, you wrote to Tommi Koivula:

So Michiel is not using JAM ?

He is, afaik.

I use JAM.

Or how come his reply-linking isn't working ?

I don't know. ;)

I think it is not Fmail that is the problem. The links were not worling when I reported it, but they are working now. It has happened before that links that do not work are restored the next day.

My guess is that it is Golded. It is supposed to udate the reply links when responding to a message, but that seems to fail with non FTS-0009 MSGID. The daily run of ftools maint corrects it. I think...


Cheers, Michiel

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

I use JAM.

Or how come his reply-linking isn't working ?

I don't know. ;)

I think it is not Fmail that is the problem. The links were not worling when I reported it, but they are working now. It has happened before that links that do not work are restored the next day.

My guess is that it is Golded. It is supposed to udate the reply links

when

responding to a message, but that seems to fail with non FTS-0009 MSGID. The daily run of ftools maint corrects it. I think...

My Golded updates the reply kludge just ok also with syncronet messages. And I can jump between messages with + and - .

'Tommi

---
* Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)

Hi! Tommi,

On 31 Jan 18 14:16, you wrote to Michiel van der Vlist:

My guess is that it is Golded. It is supposed to udate the reply
links when responding to a message, but that seems to fail with
non FTS-0009 MSGID. The daily run of ftools maint corrects it. I
think...

My Golded updates the reply kludge just ok also with syncronet
messages. And I can jump between messages with + and - .

Confirmed. Thread browsing around the IPv6 echo works a charm here too.

Cheers,
Paul.

... My other tagline is in the shop. This one is a loaner.
--- GoldED+/LNX 1.1.5-b20110213
* Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)

Paul Quinn wrote:

On 31 Jan 18 14:16, you wrote to Michiel van der Vlist:

MV>> My guess is that it is Golded. It is supposed to udate the reply
MV>> links when responding to a message, but that seems to fail with
MV>> non FTS-0009 MSGID. The daily run of ftools maint corrects it. I
MV>> think...

TK> My Golded updates the reply kludge just ok also with syncronet
TK> messages. And I can jump between messages with + and - .

Confirmed. Thread browsing around the IPv6 echo works a charm here too.

I meant "reply chain" when I wrote "reply kludge", but you got me right. :)

'Tommi

--- Sylpheed 3.6.0 (GTK+ 2.24.30; i686-pc-mingw32)
* Origin: jamnntpd/linux/2 (2:221/360)

Hello Tommi,

On Wednesday January 31 2018 14:16, you wrote to me:

My guess is that it is Golded. It is supposed to udate the reply
links when responding to a message, but that seems to fail with
non FTS-0009 MSGID. The daily run of ftools maint corrects it. I
think...

My Golded updates the reply kludge just ok also with syncronet
messages. And I can jump between messages with + and - .

Windows vs Linux version?


Cheers, Michiel

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

31 Jan 18 22:02:42, you wrote to me:

My guess is that it is Golded. It is supposed to udate the reply
links when responding to a message, but that seems to fail with
non FTS-0009 MSGID. The daily run of ftools maint corrects it. I
think...

My Golded updates the reply kludge just ok also with syncronet
messages. And I can jump between messages with + and - .

Windows vs Linux version?

Windows. Pretty much the same version you use, but W64:

--- GoldED+/W32-MSVC 1.1.5-b20170303

'Tommi

--- GoldED+/W64-MSVC 1.1.5-b20170303
* Origin: IPv6 Point at [2001:470:1f15:cb0:2:221:1:1] (2:221/1.1)

01 Feb 18 09:06, Tommi Koivula wrote to Michiel van der Vlist:

My Golded updates the reply kludge just ok also with syncronet
messages. And I can jump between messages with + and - .

Windows vs Linux version?

Windows. Pretty much the same version you use, but W64:

--- GoldED+/W32-MSVC 1.1.5-b20170303

--- GoldED+/W64-MSVC 1.1.5-b20170303

I have test echoes as .msg and squish also. Copied syncrobad messages to those echoes, replied to them and Golded updates reply chains 100% ok.

Now with GoldED+/EMX 1.1.5-b20170303. :)

'Tommi

--- GoldED+/EMX 1.1.5-b20170303
* Origin: ============================================== (2:221/0)

Re: reply chains
By: Tommi Koivula to Michiel van der Vlist on Thu Feb 01 2018 09:30 am

I have test echoes as .msg and squish also. Copied syncrobad messages to those echoes, replied to them and Golded updates reply chains 100% ok.

"syncrobad" - oh that's so witty of you.

digital man

Synchronet "Real Fact" #50:
JAM and Squish were considered before developing Synchronet Message Base format.
Norco, CA WX: 69.5°F, 34.0% humidity, 5 mph ESE wind, 0.00 inches rain/24hrs

Hello,

On Sun, 4 Feb 2018 18:58:50 -0800, Rob Swindell -> Tommi Koivula wrote:

  Re: reply chains
  By: Tommi Koivula to Michiel van der Vlist on Thu Feb 01 2018 09:30 am

; I have test echoes as .msg and squish also. Copied syncrobad
messages to those  echoes, replied to them and Golded updates
reply chains 100% ok.

"syncrobad" - oh that's so witty of you.

Unfortunately, what most of these people don't realize is that Synchronet has far surpassed all of this software.

If only any of them could keep up. ;)

Regards,
Nick

--- Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52
* Origin: thePharcyde_ distribution system (1:154/10)

Re: reply chains
By: Nicholas Boel to Rob Swindell on Sun Feb 04 2018 10:57 pm

Hello,

On Sun, 4 Feb 2018 18:58:50 -0800, Rob Swindell -> Tommi Koivula wrote:

  Re: reply chains
  By: Tommi Koivula to Michiel van der Vlist on Thu Feb 01 2018 09:30 am

 >> I have test echoes as .msg and squish also. Copied syncrobad

messages to those  echoes, replied to them and Golded updates
reply chains 100% ok.

"syncrobad" - oh that's so witty of you.

Unfortunately, what most of these people don't realize is that Synchronet has far surpassed all of this software.

I'll write up a FAQ about the stupid FTN MSG-ID standard and why Synchronet and SBBSecho generate unique FTN message IDs the way it does.

Now there was a recent "bug" that was brought to my attention and fixed whereby SBBSecho was stripping trailing whitespace from imported kludge lines (including MSG-ID and REPLY control lines) and that caused a problem for some software when being exported back out to the net (a MSG-ID with a trailing space was considered *different* than another message with the same MSG-ID without a trailing space). Anway, that was "fixed" recently and really has nothing to do with the message-IDs generated by Synchronet/SBBSecho.

If only any of them could keep up. ;)

Competition is good but when the competitors just up and die on ya, what more can you do? :-)

digital man

Synchronet/BBS Terminology Definition #34:
LF = Line Feed (ASCII 10, Ctrl-J)
Norco, CA WX: 66.2°F, 42.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs

Hi Rob,

On 2018-02-04 21:51:17, you wrote to Nicholas Boel:

I'll write up a FAQ about the stupid FTN MSG-ID standard and why Synchronet and SBBSecho generate unique FTN message IDs the way it
does.

So you are the only sane person in this world of stupid people? Where did I hear that before? ;)

The MSGID standard is what it is. For whatever reason synchronet choose not to follow the standard. So don't be surprised that might cause some trouble on all
other systems. Standards are there for a reason! So don't blame the others that
follow it!

Bye, Wilfred.

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

Re: Re: reply chains
By: Wilfred van Velzen to Rob Swindell on Mon Feb 05 2018 09:50 am

Hi Rob,

On 2018-02-04 21:51:17, you wrote to Nicholas Boel:

I'll write up a FAQ about the stupid FTN MSG-ID standard and why Synchronet and SBBSecho generate unique FTN message IDs the way it does.

So you are the only sane person in this world of stupid people?

No, I think only one person wrote FTS-9. I doubt he's stupid, but it's stupid that the spec was never clarified or updated to address its short-sightedness.

Where did I hear that before? ;)

I don't know. Where?

The MSGID standard is what it is. For whatever reason synchronet choose not to follow the standard. So don't be surprised that might cause some trouble on all
other systems. Standards are there for a reason! So don't blame the others that
follow it!

Actually, I did follow the standard. I even followed some existing practices that had been place for many years before Synchronet and its utilities (e.g. SBBSecho) started sending messages with unique MSGIDs into FidoNets.

Here's my tired answer to this question: http://wiki.synchro.net/faq:misc#ftn_msgid

digital man

Synchronet/BBS Terminology Definition #30:
IP = Internet Protocol
Norco, CA WX: 61.8°F, 46.0% humidity, 0 mph SW wind, 0.00 inches rain/24hrs

Complain to the author of Synchronet. ;)

It has been done. He doesn't care. ;(

Question: What version of fmail are you using?

--- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
* Origin: Mystic.dynu.net 2310 (1:275/201)

Friday October 26 2018 20:53, Phil Taylor wrote to Tommi Koivula:

Question: What version of fmail are you using?

| FMail/2 1.60 ¿ Setup Utility
| Copyright (C) 1991, 2001 by Folkert J. Wijnstra ¿ All rights reserved

Why?

'Tommi

---
* Origin: rbb.fidonet.fi (2:221/360)

Hi Tommi,

On 2018-10-27 09:49:40, you wrote to Phil Taylor:

| FMail/2 1.60 ¨ Setup Utility
| Copyright (C) 1991, 2001 by Folkert J. Wijnstra ¨ All rights

That's the OS/2 version isn't it? Otherwise I would strongly advise to upgrade to the latest opensource version! ;)

Bye, Wilfred.

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

Saturday October 27 2018 11:53, Wilfred van Velzen wrote to Tommi Koivula:

On 2018-10-27 09:49:40, you wrote to Phil Taylor:

| FMail/2 1.60 Φ Setup Utility
| Copyright (C) 1991, 2001 by Folkert J. Wijnstra Φ All rights

That's the OS/2 version isn't it?

That's what the /2 means. ;D

Otherwise I would strongly advise to upgrade to the latest opensource version! ;)

I know. ;) Well, the old setup of my FMail is just there, it's not "in production".

'Tommi

---
* Origin: 2001:470:1f15:cb0:f1d0:2:221:360 (2:221/360)

Hi Tommi,

On 28 Oct 18 14:41, Tommi Koivula wrote to Wilfred van Velzen:
about: "ipv6":

Otherwise I would strongly advise to upgrade to the latest opensource
version! ;)

I know. ;) Well, the old setup of my FMail is just there, it's not "in production".

Pitty! ;)

Wilfred.

--- FMail-W32 2.0.1.4
* Origin: point@work (2:280/464.112)

On 29.10.2018 9:35, Wilfred van Velzen -> Tommi Koivula :

Otherwise I would strongly advise to upgrade to the latest opensource
version! ;)

I know. ;) Well, the old setup of my FMail is just there, it's not "in
production".

Pitty! ;)

No! I'm not going to delete it! :D

BTW. FMail was my first-ever tosser when I was just a point. ;) There
were fine offline readers like SLMR and QOmen, but the sysop of my
favorite bbs (Express) persuaded me to set up a point. :D

'Tommi

---
* Origin: SmapiNNTPd/Linux-Pi 1.12 (2:221/0.0)

Hi Tommi,

On 2018-10-29 17:24:58, you wrote to me:

BTW. FMail was my first-ever tosser when I was just a point. ;) There
were fine offline readers like SLMR and QOmen, but the sysop of my favorite bbs (Express) persuaded me to set up a point. :D

As did mine. But I was using Amiga software when I was still a point. At some point I took over the bbs system of my boss, and that included FMail. The rest is history. ;)

Bye, Wilfred.

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

Re: ipv6
By: Tommi Koivula to Wilfred van Velzen on Mon Oct 29 2018 05:24 pm

BTW. FMail was my first-ever tosser when I was just a point. ;) There
were fine offline readers like SLMR and QOmen, but the sysop of my favorite bbs (Express) persuaded me to set up a point. :D

Innocent until proven guilty! (LOL!)

xxcarol

PS my first tosser was CONFMAIL
--- SBBSecho 2.12-Win32
* Origin: Shenk's Express telnet://shenks.dyndns.org (1:275/100)

Hi Carol.

03 Nov 18 11:10:42, you wrote to me:

BTW. FMail was my first-ever tosser when I was just a point. ;) There
were fine offline readers like SLMR and QOmen, but the sysop of my
favorite bbs (Express) persuaded me to set up a point. :D

Innocent until proven guilty! (LOL!)

* Origin: Shenk's Express telnet://shenks.dyndns.org (1:275/100)

:-D

Anyways, the crime has expired in almost 30 years. :)

'Tommi

---
* Origin: 2001:470:1f15:cb0:f1d0:2:221:6 (2:221/6)

Re: ipv6
By: Tommi Koivula to Carol Shenkenberger on Sat Nov 03 2018 10:08 pm

of my favorite bbs (Express) persuaded me to set up a point. :D

Innocent until proven guilty! (LOL!)

* Origin: Shenk's Express telnet://shenks.dyndns.org (1:275/100)

:-D

Anyways, the crime has expired in almost 30 years. :)

Innocent still! I was feeding my first point in 1990.. oh dear!
--- SBBSecho 2.12-Win32
* Origin: Shenk's Express telnet://shenks.dyndns.org (1:275/100)

HI there

What is the latest version and where can it be obtained?

I looked at SF but am not sure that is the most recent one?

Do you know if tools that look at JAM bases created by Fastecho would also
work on JAM bases created by Fmail?

Can I just import/migrate current JAM bases used in Fastecho across to Fmail?

Is there zone stripping of seen-bys?

Can netmail please be handled by Fmail using a JAM base, please :)

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

Hi Paul,

On 2018-11-29 22:36:16, you wrote to me:

What is the latest version and where can it be obtained?

I looked at SF but am not sure that is the most recent one?

That's currently the latest release. Sometimes there are newer development versions, but they aren't published.

Do you know if tools that look at JAM bases created by Fastecho would
also work on JAM bases created by Fmail?

JAM is a standardized public format. There are no opperational issues between golded and fmail on jam messagebases afaik, for instance.

There once was a report of someone that went from fastecho to fmail and back to
fastecho, where there was an issue with jam on the second step. But I don't remember the details, and if it was investigated and or resolved or not...

Can I just import/migrate current JAM bases used in Fastecho across to Fmail?

You should. But it doesn't hurt to have backups. ;)

Is there zone stripping of seen-bys?

No.

(However you can configure "Tiny Seenbys" for each area and/or each node, if you choose so. Should be off by default.)

Can netmail please be handled by Fmail using a JAM base, please :)

Not yet. ;)


Bye, Wilfred.

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

Hello everybody.

Recently (this week), I switched from Fastecho 1.46 to FMail 1.59b/Beta

I am using JAMAPI Tools that allow me to inspect all files and how they are interact with the four files. Anyway, just to help others who may be looking to
implement FMail, I can add fresh perspective.

FMail works great with the JAM and Fidonet. It works with BSO folders.

Only quirk(s) I have found:
FMailW32 SCAN /J /S

Works for getting messages out - that JAMNNTPD v1.2.3 is not always flaging posts as new, and updating the MODCOUNTER field in the header. (Which I assume FMail is using to know if there is anything to look for).

The other quirk is my "INBOUND" and "OUTBOUND" are network folders. FMail reports the drive/path do not exist, create Y/n? So I make fake IN/OUT folders locally and I move my files IN/OUT before TOSS and SCAN.

Other than that - I am using GoldED to also help me test. It has "I"nspect mode when you are scrolling through a message base (JAM, Fido/Opus, etc). Dumps
the variables, headers, and hexdump of the actual content. Great (amazing) feature to put into an EDITOR!

Ozz

--- FMail/Win32 1.59b/beta
* Origin: Richmond VA (RVA) Fidonet Support (1:275/362)

Hi Ozz,

On 2019-02-07 18:02:53, you wrote to All:

Recently (this week), I switched from Fastecho 1.46 to FMail
1.59b/Beta

Where did you even get that old beta version? You should switch to the latest and greatest!

https://sourceforge.net/projects/fmail/files/FMail/2.0/FMailW32-2.0.1.zip/download

But I'm collecting the old archives, so if you have the 1.59b release zip file I'm interested! ;)

FMail works great with the JAM and Fidonet. It works with BSO
folders.

We know! ;)

Only quirk(s) I have found:
FMailW32 SCAN /J /S

Works for getting messages out - that JAMNNTPD v1.2.3 is not always flaging posts as new, and updating the MODCOUNTER field in the header. (Which I assume FMail is using to know if there is anything to look for).

I would have to look into that...

The other quirk is my "INBOUND" and "OUTBOUND" are network folders. FMail reports the drive/path do not exist, create Y/n? So I make fake IN/OUT folders locally and I move my files IN/OUT before TOSS and SCAN.

If the latest version still does that, we can try to debug that.

But I'm using a N: drive which is a samba share on the linux side of my system from a virtual XP, which works flawlessly...

Bye, Wilfred.

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

Hi! Wilfred,

On 02/09/2019 06:28 AM, you wrote to Ozz Nixon:

FMail works great with the JAM and Fidonet. It works with BSO
folders.

We know! ;)

Still with a little too much Hudson. ;)

Only quirk(s) I have found:
FMailW32 SCAN /J /S

Works for getting messages out - that JAMNNTPD v1.2.3 is not
always flaging posts as new, and updating the MODCOUNTER field in
the header. (Which I assume FMail is using to know if there is
anything to look for).

I would have to look into that...

It may be directly unrelated but recall that "ftools maint" will renumber JAM messages, which up-fucks NNTP servers (JamNNTPd).

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Deja Booboo: The feeling you've screwed this up before. (3:640/1384.125)

Hi Paul,

On 2019-02-09 08:34:57, you wrote to me:

Only quirk(s) I have found:
FMailW32 SCAN /J /S

Works for getting messages out - that JAMNNTPD v1.2.3 is not
always flaging posts as new, and updating the MODCOUNTER field in
the header. (Which I assume FMail is using to know if there is
anything to look for).

I would have to look into that...

It may be directly unrelated but recall that "ftools maint" will renumber JAM messages, which up-fucks NNTP servers (JamNNTPd).

It's both about the jam messagebase, but that's where the similarities end. ;)

Bye, Wilfred.

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

Hello Wilfred.

08 Feb 19 21:28, you wrote to me:

Firstly, KUDOS! Unzip 2.0 over 1.59b - run FTOOLS MAINT (AWESOME REPLY CHAIN FEATURE!!!!!) ... then ran the Config EXE - everything aligned perfectly, no wacky characters in fields or anything that other packages do - AWESOME UPGRADE!

Per RETRO copies: http://archives.thebbs.org/ra53a.htm

I am developing a new JAMAPI (TP version had a few quirks - no longer). I have also modernized it to current class/object structure. I will be incorporating your "Reply Chain" feature into the JAMAPI (I call DXJAMAPI to avoid confusion). I am also recoding QuickBBS v3.0 to support JAM - dropping GB and HMB. And I have been asked to recompile PCBoard 15.4 source (I will be releasing potentially this year too) - dropping CNAME design for JAM.

* Only major wishlist I did not see (may be there) -- a drop file from FMail to
me ECHOLIST with new posts via TOSS. And what is the best way for me to pass such from BBS/NNTP/etc to you for SCAN?

Regards,
Ozz

--- FMail-W32 2.0.1.4
* Origin: Richmond VA (RVA) Fidonet Support (1:275/362)

Hello Ozz.

08 Feb 19 22:52, I wrote to Wilfred van Velzen:

FMail to me ECHOLIST with new posts via TOSS. And what is the best way

Realized that could also mean "NEW ECHO LIST"... but, mainly anything to shortcircuit time a BBS needs for "whats new" for users who actively read and write in the echos. I can then accumulate a list of ECHOS by DAY - and when a user logs back in - POOF there is almost real-time list of new ECHO POSTS, and I can use that for quickly FindNewByUser(UserCRC, UserID) which can pull from LastRead - or I could pre-create a list - all about making QuickBBS quicker...

Again, thanks! Keep up the work! I have racks of servers with different OSes and APPs if you need a test bed, let me know. (I am good at finding bugs, and making them too) ;-)

Ozz

--- FMail-W32 2.0.1.4
* Origin: Richmond VA (RVA) Fidonet Support (1:275/362)

Hi Ozz,

On 2019-02-08 22:52:26, you wrote to me:

Firstly, KUDOS! Unzip 2.0 over 1.59b

"Unzip"? ;)

- run FTOOLS MAINT (AWESOME REPLY CHAIN FEATURE!!!!!) ... then ran the Config EXE - everything aligned perfectly, no wacky characters in
fields or anything that other packages do - AWESOME UPGRADE!

Did the 1.59b do that? I don't think I ever used that beta version. The source I got from the original author was for 1.60. I did quite a bit of tweaking/improving/fixing/speeding-up on the maint code, but it's still based on the original by Folkert, so kudos must go to him too! ;)

Per RETRO copies: http://archives.thebbs.org/ra53a.htm

Thanks.

I am developing a new JAMAPI (TP version had a few quirks - no
longer). I have also modernized it to current class/object structure.
I will be incorporating your "Reply Chain" feature into the JAMAPI (I
call DXJAMAPI to avoid confusion).

Well good luck with the porting from C to Pascal! ;)

* Only major wishlist I did not see (may be there) -- a drop file from FMail to me ECHOLIST with new posts via TOSS.

You mean something like what is in the toss log file but in a more machine readable form?

And what is the best way for me to pass such from BBS/NNTP/etc to you
for SCAN?

Ehhrrr?

Bye, Wilfred.

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

Hi Ozz,

On 2019-02-08 23:04:26, you wrote to you:

FMail to me ECHOLIST with new posts via TOSS. And what is the best
way

Realized that could also mean "NEW ECHO LIST"... but, mainly anything to shortcircuit time a BBS needs for "whats new" for users who actively read and write in the echos. I can then accumulate a list of ECHOS by DAY - and when a user logs back in - POOF there is almost real-time list of new ECHO POSTS, and I can use that for quickly FindNewByUser(UserCRC, UserID) which can pull from LastRead - or I could pre-create a list - all about making QuickBBS quicker...

Isn't that what the .jlr files in the JAM message base are for? They contain the last read "pointers" for each user, and they are updated everytime fmail updates the jam area files, as far as I remember...?

Again, thanks! Keep up the work! I have racks of servers with
different OSes and APPs if you need a test bed, let me know. (I am
good at finding bugs, and making them too) ;-)

Currently I and the single other test node, only use FMail with Binkly Style Outbound (BSO), and Golded as editor. And no bbs. So it could use some testing in other environments...

Bye, Wilfred.

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

Hello Wilfred.

12 Feb 19 21:42, you wrote to me:

Hi Ozz,

I am developing a new JAMAPI (TP version had a few quirks - no
longer). I have also modernized it to current class/object
structure. I will be incorporating your "Reply Chain" feature
into the JAMAPI (I call DXJAMAPI to avoid confusion).

Well good luck with the porting from C to Pascal! ;)

I do it all day ;-)

* Only major wishlist I did not see (may be there) -- a drop file
from FMail to me ECHOLIST with new posts via TOSS.

You mean something like what is in the toss log file but in a more
machine readable form?

For example, d'Bridge tosser would let me know
FTSC_PUBLIC
FMAIL_HELP
FN_SYSOP

Which my BBS used to circumvent a full scan of 1000+ echos when someone would log in, that was on before the most recent toss - I limited their "NEW SCAN" to
those 3 echos listed above. I have a small DB of userID,array of areas - so it only searched the array of areas from JLR forward. *MUCH* faster for a user on my systems... especially when I start pulling in newsgroups and any other FTN(etwork) I can get coming in.

And what is the best way for me to pass such from BBS/NNTP/etc to
you for SCAN?

Same going out, I could drop SCANTHIS.LST and simply drop in:
AREA or AREA,MSG#

To short-circuit scanning for timestamp or modcounter changes in JAM.

Ozz

--- FMail-W32 2.0.1.4
* Origin: Richmond VA (RVA) Fidonet Support (1:275/362)

Hello Wilfred.

12 Feb 19 21:51, you wrote to me:

Hi Ozz,

Isn't that what the .jlr files in the JAM message base are for? They contain the last read "pointers" for each user, and they are updated everytime fmail updates the jam area files, as far as I remember...?

Yes, but hitting 1000+ JLR files all over a drive *is slow* versus, SCANTHIS.LST from me to you - you only hit 5 to 10 echos that have been active since I signaled FMAIL SCAN.

And vise versa, FMAIL and Rhenium run in a seperate thread/window from the BBS which is actually running right now behind GameSrv.exe in dynamic windows. * This will *SERIOUSLY* change when I migrate this to my Linux rack. However, in either case, I do not "SCAN" after every caller, and I do not "TOSS" after every mailer session. I am currently doing it on the 5's (every 5th minute I check if SCANTHIS.LST exists then I do a FMAIL SCAN) and if /BinkPDOS/IN/ has anythign other than . and .. then I call FMAIL TOSS.

I do this, as I get 100's of port scans a minute that would normally trigger a "FMAIL TOSS" and really eat CPU... and depending upon their script - could cross-fire FMAIL SCAN if I ran it in the STARTBBS.BAT for GameSrv.exe

Currently I and the single other test node, only use FMail with Binkly Style Outbound (BSO), and Golded as editor. And no bbs. So it could
use some testing in other environments...

If you do not mind *crazy* ideas to steamline my systems across the US - I will
gladly share ideas. I can even share how d'Bridge does its folders - I call DBO
for my environment (which supports both BSO and DBO concurrently)... MODEM vs BINKP. I am currently looking at scheduling a rewrite on Portal of Power, and merging my BinkPDOS code into it giving me EMSI/WAZOO/BINKP all on a single codebase (DOS/WINDOWS/MAC/LINUX).

Ozz

--- FMail-W32 2.0.1.4
* Origin: Richmond VA (RVA) Fidonet Support (1:275/362)

Hi Ozz,

On 2019-02-14 10:09:08, you wrote to me:

* Only major wishlist I did not see (may be there) -- a drop file
from FMail to me ECHOLIST with new posts via TOSS.

You mean something like what is in the toss log file but in a more
machine readable form?

For example, d'Bridge tosser would let me know
FTSC_PUBLIC
FMAIL_HELP
FN_SYSOP

Which my BBS used to circumvent a full scan of 1000+ echos when someone would log in, that was on before the most recent toss - I limited their "NEW SCAN" to those 3 echos listed above. I have a small DB of

userID,array

of areas - so it only searched the array of areas from JLR forward. *MUCH* faster for a user on my systems... especially when I start pulling in newsgroups and any other FTN(etwork) I can get coming in.

There's already this option in the config:

Tossed Areas List

Writes a list of echomail areas in which mail has been
tossed to the specified file.

I don't use it myself, but it seems just what you want.

And what is the best way for me to pass such from BBS/NNTP/etc to
you for SCAN?

Same going out, I could drop SCANTHIS.LST and simply drop in:
AREA or AREA,MSG#

To short-circuit scanning for timestamp or modcounter changes in JAM.

There is the "echomail.jam" that's read by fmail scan. Golded for instance creates it.

Scan always

If set to "Yes", the messages base will always be
completely scanned for outgoing messages. If set to
"No", FMail relies on the files ECHOMAIL.BBS and
NETMAIL.BBS for Hudson and/or ECHOMAIL.JAM for JAM areas
to indicate new messages. If these files are found to be
pointing to a message that does not qualify for export,
a complete scan of the message base (or JAM base) will
be performed.

(I hate to quote the docs, but there you go ;)).

Bye, Wilfred.

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

Hi Ozz,

On 2019-02-14 10:14:50, you wrote to me:

Isn't that what the .jlr files in the JAM message base are for? They
contain the last read "pointers" for each user, and they are updated
everytime fmail updates the jam area files, as far as I remember...?

Yes, but hitting 1000+ JLR files all over a drive *is slow*

And would probably less then a second on a modern ssd drive. ;)

versus, SCANTHIS.LST from me to you - you only hit 5 to 10 echos that
have been active since I signaled FMAIL SCAN.

And the options I mentioned in my previous message will do for this?

And vise versa, FMAIL and Rhenium run in a seperate thread/window from
the BBS which is actually running right now behind GameSrv.exe in
dynamic windows. * This will *SERIOUSLY* change when I migrate this to
my Linux rack. However, in either case, I do not "SCAN" after every caller, and I do not "TOSS" after every mailer session.

I think you could. I don't run a bbs, so scan after a caller isn't an issue on my system. But I do run a toss after each mailer session. It's so fast, I don't
have to give it another thought:

wilnux5:/home/fido/log # grep 'Toss Active' fmail.log | tail
21:10:08.860 Toss Active: 0.025 sec.
21:12:17.939 Toss Active: 0.080 sec.
21:13:15.650 Toss Active: 0.021 sec.
21:14:39.782 Toss Active: 0.0051 sec.
21:38:05.132 Toss Active: 0.030 sec.
21:39:15.685 Toss Active: 0.030 sec.
21:40:21.420 Toss Active: 0.044 sec.
21:42:20.530 Toss Active: 0.0074 sec.
21:59:15.780 Toss Active: 0.041 sec.
22:03:12.721 Toss Active: 0.036 sec.

I do this, as I get 100's of port scans a minute that would normally trigger a "FMAIL TOSS" and really eat CPU...

I get hardly any port scans on the binkp port. And binkd only triggers a toss if there was a true mailer session, and pkt's received...

Currently I and the single other test node, only use FMail with Binkly
Style Outbound (BSO), and Golded as editor. And no bbs. So it could
use some testing in other environments...

If you do not mind *crazy* ideas to steamline my systems across the US - I will gladly share ideas.

Ideas are ok, but I've very little time for working on fmail. Work, living, etc... ;)


Bye, Wilfred.

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

Hello Wilfred.

14 Feb 19 22:43, you wrote to me:

There's already this option in the config:

Tossed Areas List

Writes a list of echomail areas in which mail has been
tossed to the specified file.

I don't use it myself, but it seems just what you want.

* I didn't see that one, I saw:

There is the "echomail.jam" that's read by fmail scan. Golded for
instance creates it.

Just not sure of the format - is that in the DOCs too???

(I hate to quote the docs, but there you go ;)).

I skimmed the DOCs, and had seen ECHOMAIL.JAM statement - but, assumed that was
a RA 2.x feature and didn't want to go back through their STRUCT files to find it... thus, I asked. ;-)

*I* do not mind making my products seamless with other solutions. My mailer has
4 setting you change and d'Bridge becomes the tosser/manager. Since FMail is multi-platform also, I do not mind making the BBS and the MAILER work seamlessly with FMail...


Ozz

--- FMail-W32 2.0.1.4
* Origin: Richmond VA (RVA) Fidonet Support (1:275/362)

Hello Wilfred.

14 Feb 19 22:56, you wrote to me:

wilnux5:/home/fido/log # grep 'Toss Active' fmail.log | tail

C:\BBS\FMAIL>grep "Toss Active" TOSSER.LOG
22:45:11 Toss Active: 0.015 sec.
22:46:00 Toss Active: 0.171 sec.
13:30:16 Toss Active: 2.125 sec.
13:52:33 Toss Active: 0.172 sec.
14:09:49 Toss Active: 0.171 sec.
16:16:57 Toss Active: 0.203 sec.
18:45:29 Toss Active: 0.203 sec.
18:58:05 Toss Active: 0.218 sec.
18:58:19 Toss Active: 0.203 sec.
19:09:40 Toss Active: 7.884 sec.
13:46:53 Toss Active: 0.313 sec.
13:54:08 Toss Active: 4.218 sec.
14:00:51 Toss Active: 0.218 sec.
14:01:46 Toss Active: 1.859 sec.
10:04:48 Toss Active: 1.860 sec.
18:23:26 Toss Active: 1.781 sec.
18:24:20 Toss Active: 0.406 sec.
10:20:22 Toss Active: 1.616 sec.

As you can see, it is not as fast as your Linux system, it is not bad though. The biggest delay is unpacking my daily digest of FSXNET. Those are the times FMail exceed a 1000ms.

I do this, as I get 100's of port scans a minute that would
normally trigger a "FMAIL TOSS" and really eat CPU...

I get hardly any port scans on the binkp port. And binkd only triggers
a toss if there was a true mailer session, and pkt's received...

Correct, however, if I put FMail Scan in my STARTBBS.BAT - I would scan way too
often. ;-)

** Off to research ECHOMAIL.JAM....

Ozz

--- FMail-W32 2.0.1.4
* Origin: Richmond VA (RVA) Fidonet Support (1:275/362)

On 15 Feb 2019 at 10:43a, Ozz Nixon pondered and said...

though. The biggest delay is unpacking my daily digest of FSXNET. Those are the times FMail exceed a 1000ms.

That kind of makes me smile :)

Best, Paul

--- E:avon@bbs.nz ------ W:bbs.nz ---
--- K:keybase.io/avon --------------

--- Mystic BBS v1.12 A43 2019/02/15 (Windows/32)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (3:770/100)

Hi Ozz,

On 2019-02-15 10:36:32, you wrote to me:

There is the "echomail.jam" that's read by fmail scan. Golded for
instance creates it.

Just not sure of the format - is that in the DOCs too???

I skimmed the DOCs, and had seen ECHOMAIL.JAM statement - but, assumed that was a RA 2.x feature and didn't want to go back through their
STRUCT files to find it... thus, I asked. ;-)

It's not in the fmail of golded docs. And my guess is, it's a RA thing...


Bye, Wilfred.

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

Hi Ozz,

On 2019-02-15 10:43:23, you wrote to me:

wilnux5:/home/fido/log # grep 'Toss Active' fmail.log | tail

C:\BBS\FMAIL>grep "Toss Active" TOSSER.LOG
22:45:11 Toss Active: 0.015 sec.
22:46:00 Toss Active: 0.171 sec.
13:30:16 Toss Active: 2.125 sec.
13:52:33 Toss Active: 0.172 sec.
14:09:49 Toss Active: 0.171 sec.
16:16:57 Toss Active: 0.203 sec.
18:45:29 Toss Active: 0.203 sec.
18:58:05 Toss Active: 0.218 sec.
18:58:19 Toss Active: 0.203 sec.
19:09:40 Toss Active: 7.884 sec.
13:46:53 Toss Active: 0.313 sec.
13:54:08 Toss Active: 4.218 sec.
14:00:51 Toss Active: 0.218 sec.
14:01:46 Toss Active: 1.859 sec.
10:04:48 Toss Active: 1.860 sec.
18:23:26 Toss Active: 1.781 sec.
18:24:20 Toss Active: 0.406 sec.
10:20:22 Toss Active: 1.616 sec.

As you can see, it is not as fast as your Linux system, it is not bad though. The biggest delay is unpacking my daily digest of FSXNET. Those

are

the times FMail exceed a 1000ms.

This might also be influenced by periodic tossing. In my case when I toss immediately after the mailer session. The received files are almost certainly still in memory caches. When you toss periodic, depending on how busy your system is, and the resources available, that might not be the case...

Bye, Wilfred.

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

Hi! Wilfred,

On 16 Feb 19 12:04, you wrote to Ozz Nixon:

There is the "echomail.jam" that's read by fmail scan. Golded
for instance creates it.

Just not sure of the format - is that in the DOCs too???

I skimmed the DOCs, and had seen ECHOMAIL.JAM statement - but,
assumed that was a RA 2.x feature and didn't want to go back
through their STRUCT files to find it... thus, I asked. ;-)

It's not in the fmail of golded docs. And my guess is, it's a RA
thing...

It's known more widely. From what I've been able to find out in 5 minute's checking distro archives tossers like: CrahMail, FastEcho, FMail 1.22, GEcho, and the TimEd editor were aware of the file(s). Strangely Squish didn't. ;)

Cheers,
Paul.

... Whenever I get a grip on reality, the handle falls off.
--- GoldED+/LNX 1.1.5-b20130515
* Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)

On 2019 Feb 16 12:04:48, you wrote to Ozz Nixon:

I skimmed the DOCs, and had seen ECHOMAIL.JAM statement - but,
assumed that was a RA 2.x feature and didn't want to go back through
their STRUCT files to find it... thus, I asked. ;-)

It's not in the fmail of golded docs. And my guess is, it's a RA thing...

no... RA/FD/FE implemented it since they added it as part of a feature request... it was taken up by many others as well... the problem is that there are two or three similar files that provide the information but in slightly different ways... echomail.jam and netmail.jam are for _outbound_ local posts that need to be scanned out of the message base... some try to use this file for inbound which is the exact opposite of what it is intended for...

the other files have another name and may be more generally used for "sole occupant" type setups like single user BBSes or point systems... especially those that use local sysop reader/editor setups like golded, timed, msged and similar... those can use those inbound files to sort those areas to the top of the mail listing if you want to see them first... i don't see them working very
well for multi-user setups like a BBS with multiple users... the last read pointers of the users still need to be consulted no matter what mail arrived recently...

on searching for new messages since a user's last visit, it should be easy enough for any JAM capable package to maintain the two lastread pointers for each user... it should also be able to quickly scan through the JLR files picking up and comparing the lastread pointers for each user with the number of
messages in the area the JLR file is for... if a system is too slow doing that,
they may want to examine their algorithm and/or system setup...

i do recall, on DOS systems, that there was a major slowdown of scanning files which JAM brought to the forefront... the problem was actually in the file system and the way that the OS managed FAT* areas with large numbers of files... folks thought they were putting (eg) 400 message areas in one directory but they didn't realize they were really putting 1600 files in one directory... splitting the areas into directories with less than 255 _files_ (63 JAM areas) per directory sped the processing up by at least a magnitude...

access speed problems may also be seen on networked drive shares... JAM really should be used from local fast HDs, IMHO...

i like the OOP aspect of the pascal JAM library i used in my code... it was fast and did everything i needed... i don't know how non-OOP linear procedural code would work... if it would gather the needed information from the message base files as quickly or if additional requests would need to be made which could slow the scanning process down...

FWIW: when i was using JAM, i was splitting my areas into a structured directory tree something like this...

\FTNs\
\FTNs\Fidonet\
\FTNs\Fidonet\messages\
\FTNs\Fidonet\messages\netmail\
\FTNs\Fidonet\messages\echomail\
\FTNs\Fidonet\messages\echomail\backbone\
\FTNs\Fidonet\messages\echomail\backbone\1\
\FTNs\Fidonet\messages\echomail\backbone\1\10th_amd.j*
\FTNs\Fidonet\messages\echomail\backbone\A\
\FTNs\Fidonet\messages\echomail\backbone\A\Alaska\Chat.j*
\FTNs\Fidonet\messages\echomail\backbone\A\All\Politics.j*
\FTNs\Fidonet\messages\echomail\backbone\A\Allfix\File.j*
\FTNs\Fidonet\messages\echomail\backbone\A\Allfix\Help.j*
[...]
\FTNs\Fidonet\messages\echomail\backbone\B\
\FTNs\Fidonet\messages\echomail\backbone\B\Bash.j*
\FTNs\Fidonet\messages\echomail\backbone\B\Binkd.j*
[...]
\FTNs\Fidonet\messages\echomail\backbone\C\
[...]
\FTNs\Fidonet\files\FDNs\NODELIST\NODELIST.*
\FTNs\Fidonet\files\FDNs\DAILYLIS.T\DAILYLST.*
[...]
\FTNs\Foobar\messages\netmail\
\FTNs\FooBar\messages\echomail\backbone\A[...]
\FTNs\FooBar\messages\echomail\backbone\B[...]
\FTNs\FooBar\messages\echomail\backbone\C[...]
\FTNs\FooBar\messages\echomail\backbone\D[...]

it made things faster and also easier to maintain... autoadded areas were placed into a special directory for them until their record was updated in the tosser configuration program at which time it was moved to the proper directory
in the above tree... i used whatever splitter was used between words as a divider... the ALLFIX_FILE and ALLFIX_HELP areas are good examples of that above... same with gated news groups where you use the dots between the portions of the group name as the directory splitter...

eg: alt.bbs.ads -> [...]\alt\bbs\ads
alt.comp.anti.virus -> [...]\alt.comp.anti.virus

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... You say I'm a bastard like it's a bad thing.
---
* Origin: (1:3634/12.73)

On 2019-02-16 19:24:56 +0000, mark lewis -> Wilfred van Velzen said:

i do recall, on DOS systems, that there was a major slowdown of
scanning files which JAM brought to the forefront... the problem was
actually in the file system and the way that the OS managed FAT* areas
with large numbers of files... folks thought they were putting (eg) 400 message areas in one directory but they didn't realize they were really putting 1600 files in one directory... splitting the areas into
directories with less than 255 _files_ (63 JAM areas) per directory
sped the processing up by at least a magnitude...

Luckily those limitations no longer exist :-)

--
+++ Are we having fun yet? I am!
ATZ|ATDT911|1,2~555

--- FMail-W32 2.0.1.4
* Origin: ExchangeBBS WHQ (1:275/362.0)