On 11/02/17, Wilfred van Velzen pondered and said...

That was through Allen Prunty, where he apparently has a link too...

Is Allen about much Wilfred? I have not seen him very active for a while but
I may not be reading as much Fido as I should be :)

--- Mystic BBS v1.12 A36 (Windows/32)
* Origin: Agency BBS | telnet://agency.bbs.geek.nz (3:770/100)

Hi Paul,

On 2017-11-03 12:45:03, you wrote to me:

That was through Allen Prunty, where he apparently has a link too...

Is Allen about much Wilfred? I have not seen him very active for a while but I may not be reading as much Fido as I should be :)

I haven't seen him either. Maybe he lost interest? He is active on his facebook
page: https://www.facebook.com/alprunty

Bye, Wilfred.

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

Hello Mike!

06 Nov 17 23:19, you wrote to me:

More old messages... :( And the quilty one seems to be:

TID: SBBSecho 3.02-Win32 r3.51 Nov 6 2017 MSC 1800

My most sincere apologies for the spam.

These were not from your system. :)

So the error was corrected between r3.51 and r3.52. Nice.

'Tommi

---
* Origin: Off Topic here, Sorry Wilfred! (2:221/360)

Hi Tommi,

On 07 Nov 17 07:00, Tommi Koivula wrote to Wilfred van Velzen:
about: "New Files At War Ensemble BBS":

I just got a reply from Mike to my netmail. He was away for a week
and
he said it was a configuration error, that is now fixed....

More old messages... :( And the quilty one seems to be:

TID: SBBSecho 3.02-Win32 r3.51 Nov 6 2017 MSC 1800

Indeed. :-(

Wilfred.

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

Hello Wilfred!

More old messages... :( And the quilty one seems to be:

TID: SBBSecho 3.02-Win32 r3.51 Nov 6 2017 MSC 1800

Indeed. :-(

And now "a few" more...

TID: SBBSecho 3.02-Win32 r3.51 Nov 6 2017 MSC 1800
PATH: 266/404 203/0 221/1 360

'Tommi

---
* Origin: ================================== (2:221/360.8110)

Hi Tommi,

On 2017-11-07 16:03:58, you wrote to me:

And now "a few" more...

TID: SBBSecho 3.02-Win32 r3.51 Nov 6 2017 MSC 1800
PATH: 266/404 203/0 221/1 360

With Mike's batches they were filtered for a large part by Nicholas, so only newer messages were left through. But with these new systems we get the full blast. I already had to do emergency mainteance on my Hudson message base today, because it couldn't hold more, because of the thousands of messages that
ended up in my bad and dupe areas...

Bye, Wilfred.

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

07 Nov 17 15:12, you wrote to me:

And now "a few" more...

TID: SBBSecho 3.02-Win32 r3.51 Nov 6 2017 MSC 1800
PATH: 266/404 203/0 221/1 360

With Mike's batches they were filtered for a large part by Nicholas,
so only newer messages were left through. But with these new systems
we get the full blast.

My Hpt caught most of the old messages but that path has no Hpt's. :(

I already had to do emergency mainteance on my Hudson message base
today, because it couldn't hold more, because of the thousands of
messages that ended up in my bad and dupe areas...

Yep, HMB is a bit limited of size...

Did you know that Concord supports multiple hudson bases? You should implement that in FMail! Or maybe not... :-) End of the last century, when Concord was in
active development, I was running two parallel GEchos to test multiHMB. ;)

'Tommi

---
* Origin: [f360.n221.z2.fidonet.fi] (2:221/360)

Hi Tommi,

On 2017-11-07 17:01:30, you wrote to me:

I already had to do emergency mainteance on my Hudson message base
today, because it couldn't hold more, because of the thousands of
messages that ended up in my bad and dupe areas...

Yep, HMB is a bit limited of size...

Did you know that Concord supports multiple hudson bases?

I don't know what Concord is. ;)

You should implement that in FMail! Or maybe not... :-) End of the
last century, when Concord was in active development, I was running
two parallel GEchos to test multiHMB. ;)

There is Goldbase support in the FMail code. Goldbase is the 32 bits version of
the 16 bits Hudson messagebase, so it's limits are much harder to reach. But that part of the code hasn't been maintained, well since I took over FMail. So there are probably issues with it.

My intention is it to make FMail use Jam areas for bad and dupe areas. But that
is waiting for my time and motivation to start on it. ;)

Bye, Wilfred.

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

On 2017 Nov 07 15:12:40, you wrote to Tommi Koivula:

And now "a few" more...

TID: SBBSecho 3.02-Win32 r3.51 Nov 6 2017 MSC 1800 PATH: 266/404
203/0 221/1 360

With Mike's batches they were filtered for a large part by Nicholas,
so only newer messages were left through. But with these new systems
we get the full blast. I already had to do emergency mainteance on my Hudson message base today, because it couldn't hold more, because of
the thousands of messages that ended up in my bad and dupe areas...

this is why folks have been asking for JAM support for those areas...

but as for it being bad, my system ran out of drive space... not once but several times... spewages like this are reminiscent of "amplification attacks" seen on today's internet... especially on hub systems with large numbers of connections... eg: 1 PKT that's 2Meg in size becomes 200Meg on a system with 100 links that all get the area(s) contained inside the PKT... when you only have 200Meg to play with, that one PKT eats it all and then nothing else works...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... It's not an optical illusion. It just looks like one.
---
* Origin: (1:3634/12.73)

On 2017 Nov 07 16:13:34, you wrote to Tommi Koivula:

My intention is it to make FMail use Jam areas for bad and dupe areas.
But that is waiting for my time and motivation to start on it. ;)

it shouldn't be that hard if the code was written using decently proper object-oriented methods... i have a text file posting tool here that does this... we simply change the object used and everything just falls into place...

eg: instead of

instantiate(JAM)

we just

instantiate(MSG)

or which ever message base object we need at any time... no muss no fuss... none of the other code has to be changed at all...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Men are a pain in the @$$, women are a pain EVERYWHERE!
---
* Origin: (1:3634/12.73)

Hi mark,

On 2017-11-07 10:11:00, you wrote to me:

With Mike's batches they were filtered for a large part by Nicholas,
so only newer messages were left through. But with these new systems
we get the full blast. I already had to do emergency mainteance on my
Hudson message base today, because it couldn't hold more, because of
the thousands of messages that ended up in my bad and dupe areas...

this is why folks have been asking for JAM support for those areas...

Yeah, yeah, maybe this incident will inspire me to start working on it. ;)


Bye, Wilfred.

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

Hi mark,

On 2017-11-07 10:48:42, you wrote to me:

My intention is it to make FMail use Jam areas for bad and dupe
areas. But that is waiting for my time and motivation to start on it.
;)

it shouldn't be that hard if the code was written using decently proper object-oriented methods...

I wish that was the case...

What I understand is that at first fmail was only written for using the hudson message base. Support for JAM areas was only added later, and not in a clean way.

Bye, Wilfred.

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

Hi Wilfred!

07 Nov 2017 15:12, from Wilfred van Velzen -> Tommi Koivula:

I already had to do emergency mainteance on my Hudson message base
today, because it couldn't hold more, because of the thousands of
messages that ended up in my bad and dupe areas...

Time to switch to JAM then ;)

CU, Ricsi

--- GoldED+/LNX
* Origin: Diet: Eat as much as you want, but don't swallow it. (2:310/31)

Hi Tommi!

07 Nov 2017 17:01, from Tommi Koivula -> Wilfred van Velzen:

With Mike's batches they were filtered for a large part by
Nicholas, so only newer messages were left through. But with
these new systems we get the full blast.

My Hpt caught most of the old messages but that path has no Hpt's. :(

How have you configured??
I assume the tooold parameter? (or whatever it is called that tejects mails x days in the past or future)

CU, Ricsi

--- GoldED+/LNX
* Origin: My wife loves me, it is the computer she hates! (2:310/31)

My Hpt caught most of the old messages but that path has no Hpt's. :(

How have you configured??
I assume the tooold parameter?

You assume correct! But I don't remember the value of tooold right now...

'Tommi

--- Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
* Origin: *** nntp://rbb.bbs.fi *** Lake Ylo *** Finland *** (2:221/360)

Hi Tommi!

07 Nov 2017 21:25, from Tommi Koivula -> Richard Menedetter:

How have you configured??
I assume the tooold parameter?

You assume correct! But I don't remember the value of tooold right
now...

I am asking because I have not activated this ...
It may be a a good idea to add it in the future to my setup ;))

CU, Ricsi

--- GoldED+/LNX
* Origin: You need the trust of the people you lie to. (2:310/31)

Hi Richard,

On 2017-11-07 20:06:56, you wrote to me:

I already had to do emergency mainteance on my Hudson message base
today, because it couldn't hold more, because of the thousands of
messages that ended up in my bad and dupe areas...

Time to switch to JAM then ;)

Your the third or fourth to remark that...

Bye, Wilfred.

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

Hi! Richard,

On 11/08/2017 05:51 AM, you wrote to Tommi Koivula:

You assume correct! But I don't remember the value of tooold right
now...

I am asking because I have not activated this ...
It may be a a good idea to add it in the future to my setup ;))

That's another nice feature of FMail. Even with all the recent upstream filtering, my other node has pranged at least 600 old posts.

Cheers,
Paul.

--- Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
* Origin: Paul's Puppy 4.2.1 multiuser vBox - M'boro, Qld, OZ (3:640/384.125)

Hi Paul!

08 Nov 2017 07:03, from Paul Quinn -> Richard Menedetter:

You assume correct! But I don't remember the value of tooold
right now...

I am asking because I have not activated this ...
It may be a a good idea to add it in the future to my setup ;))

That's another nice feature of FMail. Even with all the recent
upstream filtering, my other node has pranged at least 600 old posts.

Yes ... indeed a nice feature of both HPT and FMail

CU, Ricsi

--- GoldED+/LNX
* Origin: No matter where you go... I'll hunt you down! (2:310/31)

Hello mark,

On Tue Nov 07 2017 10:11:00, mark lewis wrote to Wilfred van Velzen:

systems with large numbers of connections... eg: 1 PKT that's 2Meg in
size becomes 200Meg on a system with 100 links that all get the
area(s) contained inside the PKT... when you only have 200Meg to play with, that one PKT eats it all and then nothing else works...

This is 2017 (soon to be 2018). "200Meg" is a thing of the way distant past, which makes it nobody's fault but your own. ;)

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hello Tommi,

On Tue Nov 07 2017 21:25:10, Tommi Koivula wrote to Richard Menedetter:

How have you configured??
I assume the tooold parameter?

You assume correct! But I don't remember the value of tooold right
now...

I have mine set to 30, and I'm debating lowering it even further. 14 days seems
doable. If a system is down for 2 weeks it should probably be put on hold anyways.

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hello Wilfred,

On Tue Nov 07 2017 21:16:30, Wilfred van Velzen wrote to Richard Menedetter:

I already had to do emergency mainteance on my Hudson message
base today, because it couldn't hold more, because of the
thousands of messages that ended up in my bad and dupe areas...

Time to switch to JAM then ;)

Your the third or fourth to remark that...

FTools first, then JAM please. ;)

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hello Richard!

07 Nov 17 22:34, you wrote to Paul Quinn:

08 Nov 2017 07:03, from Paul Quinn -> Richard Menedetter:

You assume correct! But I don't remember the value of tooold
right now...

I am asking because I have not activated this ...
It may be a a good idea to add it in the future to my setup ;))

That's another nice feature of FMail. Even with all the recent
upstream filtering, my other node has pranged at least 600 old
posts.

Yes ... indeed a nice feature of both HPT and FMail

Yes, and if you find valid messages in your badecho, at least with hpt you can release them easily just with "hpt toss -b".

'Tommi

---
* Origin: [f360.n221.z2.fidonet.fi] (2:221/360)

Hello Nicholas!

07 Nov 17 17:38, you wrote to me:

How have you configured??
I assume the tooold parameter?

You assume correct! But I don't remember the value of tooold
right now...

I have mine set to 30, and I'm debating lowering it even further. 14
days seems doable.

Now I checked, it is set to 90 days at 2:221/6 and 366 days (!) at 2:221/0.

2 weeks sounds ok to me too because:

If a system is down for 2 weeks it should probably
be put on hold anyways.

'Tommi

---
* Origin: [f360.n221.z2.fidonet.fi] (2:221/360)

Hi Nicholas,

On 07 Nov 17 17:39, Nicholas Boel wrote to Wilfred van Velzen:
about: "New Files At War Ensemble BBS":

I already had to do emergency mainteance on my Hudson message
base today, because it couldn't hold more, because of the
thousands of messages that ended up in my bad and dupe areas...

Time to switch to JAM then ;)

Your the third or fourth to remark that...

FTools first, then JAM please. ;)

What should be done to FTools first?

Wilfred.

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

Hi Tommi,

On 08 Nov 17 10:07, Tommi Koivula wrote to Richard Menedetter:
about: "New Files At War Ensemble BBS":

Yes, and if you find valid messages in your badecho, at least with hpt
you can release them easily just with "hpt toss -b".

FMail has about the same function:

"The -B switch may be added to let FMail check all messages in the
bad messages directory to see whether they are valid echomail
messages or not. This may necessary if you are receiving a new
conference from your uplink but forgot to enter it in the area
manager."

Wilfred.

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

Hello Wilfred,

On Wed Nov 08 2017 09:50:42, Wilfred van Velzen wrote to Nicholas Boel:

FTools first, then JAM please. ;)

What should be done to FTools first?

Completing what you've already started, Wilfred. The port to linux would be nice prior to JAM areas. And you're already 2/3 the way there! ;)

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

Hi Nicholas,

On 08 Nov 17 16:21, Nicholas Boel wrote to Wilfred van Velzen:
about: "New Files At War Ensemble BBS":

FTools first, then JAM please. ;)

What should be done to FTools first?

Completing what you've already started, Wilfred. The port to linux would be nice prior to JAM areas. And you're already 2/3 the way there! ;)

Oh you mean FConfig! FTools has already been converted to linux! ;)

I estimate that converting FConfig to linux is a lot more work, than implementing the bad and dupe area as Jam areas. Because I probably have to rewrite most of the screen interface routines. Plus the latter is also usefull for windows users. So it's more logical to do that first...

Wilfred.

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

Hello Wilfred,

On Thursday November 09 2017 10:58, you wrote to Nicholas Boel:

I estimate that converting FConfig to linux is a lot more work, than implementing the bad and dupe area as Jam areas. Because I probably
have to rewrite most of the screen interface routines. Plus the latter
is also usefull for windows users. So it's more logical to do that first...

Secunded.


Cheers, Michiel

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

Hi! Michiel,

On 09 Nov 17 11:15, you wrote to Wilfred van Velzen:

I estimate that converting FConfig to linux is a lot more work,
than implementing the bad and dupe area as Jam areas. Because I
probably have to rewrite most of the screen interface routines.
Plus the latter is also usefull for windows users. So it's more
logical to do that first...

Secunded.

That's a very precise word, Michiel. I applaud you on two counts for its use; the second of which is that in my 59th year of learning something of the English language, you have introduced yet another new word for me to ponder over.

Cheers,
Paul.

... Illegitimi non carborundum.
--- GoldED+/LNX 1.1.5-b20110213
* Origin: Quinn's Rock - Live from Paul's Xubuntu desktop! (3:640/1384)

Hello Wilfred,

On Thu Nov 09 2017 10:58:46, Wilfred van Velzen wrote to Nicholas Boel:

Completing what you've already started, Wilfred. The port to
linux would be nice prior to JAM areas. And you're already 2/3
the way there! ;)

Oh you mean FConfig! FTools has already been converted to linux! ;)

Ah, yes. Sorry about that. Haven't looked at it in a bit.

I estimate that converting FConfig to linux is a lot more work, than implementing the bad and dupe area as Jam areas. Because I probably
have to rewrite most of the screen interface routines. Plus the latter
is also usefull for windows users. So it's more logical to do that first...

Doing it all at once (since you'd obviously be motivated at the time) would be even better! ;)

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20170303
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)