All,

I switched from a Windows system (using fmail) to a linux system (using husky), and kept all my message bases. This might cause a problem for dupe checking, since husky starts with an empty dupe history file. Is there a way to generate this dupe history from the existing messagebases?



Tom

--- GoldED+/LNX 1.1.5-b20230304
* Origin: BrainDeath BBS (2:292/8125)

Hello Wilfred,

On Monday May 22 2023 at 10:26, you wrote to Tom De Puysseleyr:

I switched from a Windows system (using fmail) to a linux system
(using husky), and kept all my message bases. This might cause a
problem for dupe checking, since husky starts with an empty dupe
history file. Is there a way to generate this dupe history from
the existing messagebases?

Most dupes happen within a couple of hours, so I wouldn't worry about it... ;-)

Sometimes a bunch of old dupes arrive, when somebody does a rescan
without taking precautions, but that is not your problem! ;-) And
maybe husky has a setting for disregarding old arriving mail?

Yes: the -tooOld option for a message area definition!

Best regards,
Niels

--- GoldED+/LNX 1.1.5-b20220504
* Origin: The Millennium BBS - fido.joncheere.be (2:292/789)

Hi Niels,

On 2023-05-22 10:42:23, you wrote to me:

Sometimes a bunch of old dupes arrive, when somebody does a rescan
without taking precautions, but that is not your problem! ;-) And
maybe husky has a setting for disregarding old arriving mail?

Yes: the -tooOld option for a message area definition!

And you can (probably?) make that a default for all areas with 'echoareadefaults'...

Bye, Wilfred.

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

Wilfred,

22 May 23 10:26, you wrote to me:

Most dupes happen within a couple of hours, so I wouldn't worry about it... ;-)

Sometimes a bunch of old dupes arrive, when somebody does a rescan
without taking precautions, but that is not your problem! ;-)

I thought it would be a good idea to not participate in distributing dupes in that case. And it would keep my own messagebase cleaner!



Tom

--- GoldED+/LNX 1.1.5-b20230304
* Origin: BrainDeath BBS (2:292/8125)

Niels,

22 May 23 10:42, you wrote to Wilfred van Velzen:

Yes: the -tooOld option for a message area definition!

Thanks for the hint! What value would you recommend? I think a few days should be enough?



Tom

--- GoldED+/LNX 1.1.5-b20230304
* Origin: BrainDeath BBS (2:292/8125)

Hi Tom,

On 2023-05-22 11:18:36, you wrote to Niels Joncheere:

Yes: the -tooOld option for a message area definition!

Thanks for the hint! What value would you recommend? I think a few
days should be enough?

You sometimes see some days/week old legit mails, when mail gets stuck somewhere. Shit happens. So a value of a month (or 2) is probably better...

Bye, Wilfred.

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

Yes: the -tooOld option for a message area definition!

Thanks for the hint! What value would you recommend? I think a few
days should be enough?

You sometimes see some days/week old legit mails, when mail gets stuck somewhere. Shit happens. So a value of a month (or 2) is probably better...

Yes, I use -tooOld 60 in my EchoAreaDefaults line.

I also use -sbkeepAll on my EchoAreaDefaults line so seen-bys are not stripped when linking with nodes outside of my own zone.

--- BBBS/Li6 v4.10 Toy-6
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)

Hi Alan,

On 2023-05-22 13:08:34, you wrote to me:

I also use -sbkeepAll on my EchoAreaDefaults line so seen-bys are not stripped when linking with nodes outside of my own zone.

Yes, very important!


Bye, Wilfred.

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

Hello Tom!

22 May 23, Tom De Puysseleyr wrote to All:

problem for dupe checking, since husky starts with an empty dupe
history file. Is there a way to generate this dupe history from the existing messagebases?

I think so. For the same reason why there is no need for a messagebase format converter. hpt does generate the dupe database for inbound pkt, just use it.

The magic word for system migration is PKT.

Setup the new husky system as a migration point number of your fmail node.
Link all echos to the point number.
Do a rescan from node to point AKA.

Your messagebase should be exported to pkt, including path and seen-by information. Because points are a part of your node they will not appear in the SEEN+BY lines.

When done and all messages are tossed over to the migration point then remove the point number from the husky config and your migration point AKA will become your node AKA. And your new husky node does have an actual dupe database.

For failsafe reason backup/clear your new nodes outbound, do a hpt scan to all echos and check for dupes in your outbound.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hello Tom!

22 May 23, Tom De Puysseleyr wrote to Niels Joncheere:

Yes: the -tooOld option for a message area definition!

Thanks for the hint! What value would you recommend? I think a few
days should be enough?

It blocks incoming mails if they are tooOld. A few days may result in droping mails from slow points or holiday afks that didn't sent all mail before or those node systems went into lock condition shortly after departure.

For todays low traffic condition in fidonet no mail should be dropped because of age. Fidonet is a _store_ and forward network. The tooOld switch was built to protect against amok running systems where the usual dupe detection fails (eg. msgid modification).

Regards

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Monobox (2:240/77)

Hi Tom,

On Monday May 22 2023, Tom De Puysseleyr said to Niels Joncheere:

Yes: the -tooOld option for a message area definition!

Thanks for the hint! What value would you recommend? I think a few
days should be enough?

What happens when a system has internet issues, and it takes the provider a week to fix? You'll be droping real messages.

My hub system has the -tooold set at 60. Most dupes come in from systems
that have some type of failure, or configuration issue.



-- Stephen --

Rocking Fidonet with an Amiga 4000 and Zeus BBS.


--- Zeus BBS 1.5
* Origin: -:-- Dragon's Lair --:- dragon.vk3heg.net Prt: 6800 (3:633/280.5)

Alan,

22 May 23 13:08, you wrote to Wilfred van Velzen:

Yes, I use -tooOld 60 in my EchoAreaDefaults line.

That's what I added as well a few days ago!

I also use -sbkeepAll on my EchoAreaDefaults line so seen-bys are not stripped when linking with nodes outside of my own zone.

Makes sense. Added that one now...


Tom

--- GoldED+/LNX 1.1.5-b20230304
* Origin: BrainDeath BBS (2:292/8125)

Kai,

23 May 23 01:19, you wrote to me:

The magic word for system migration is PKT.

Wow, thanks, that is a nice procedure! Wish I knew about about that one before I made the switch...
I had the messagebase in jam format, so no conversion needed. I just copied it over to the linux vm. Works fine! (fingers crossed about the dupes)



Tom

--- GoldED+/LNX 1.1.5-b20230304
* Origin: BrainDeath BBS (2:292/8125)

Kai,

23 May 23 01:54, you wrote to me:

For todays low traffic condition in fidonet no mail should be dropped because of age. Fidonet is a _store_ and forward network. The tooOld switch was built to protect against amok running systems where the
usual dupe detection fails (eg. msgid modification).

I see what you mean. But I think I'll keep the parameter at 60 days. Mail that arrives 60 days too late, is a bit suspicious.


Tom

--- GoldED+/LNX 1.1.5-b20230304
* Origin: BrainDeath BBS (2:292/8125)

Stephen,

23 May 23 10:19, you wrote to me:

My hub system has the -tooold set at 60. Most dupes come in from
systems that have some type of failure, or configuration issue.

I have it at 60 now too :-)



Tom

--- GoldED+/LNX 1.1.5-b20230304
* Origin: BrainDeath BBS (2:292/8125)