There are numerous variations of JamNNTPd going around, and I welcome them and support them all, but remember that the latest *official* release is still this one:

http://eljaco.se/FILES/Billing/jamnntpd.zip

No other project spawning from the original, has been approved by the author Johan Billing. Just to set matters straight...



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

Hello Bj”rn!

23 Jul 19 11:29, you wrote to All:

There are numerous variations of JamNNTPd going around, and I welcome
them and support them all, but remember that the latest *official*
release is still this one:

http://eljaco.se/FILES/Billing/jamnntpd.zip

No other project spawning from the original, has been approved by
the author Johan Billing. Just to set matters straight...

I'll download it and I'll try with it.

Many Thanks. :)

Ciao!
Fabio

--- GoldED+/LNX 1.1.5-b20180707
* Origin: ]\/[imac Rebirth Boss Point (2:335/364.1)

Hello Bj?rn!

23 Jul 19 13:36, I wrote to Bj”rn Felten:

http://eljaco.se/FILES/Billing/jamnntpd.zip

No other project spawning from the original, has been approved
by the author Johan Billing. Just to set matters straight...

I'll download it and I'll try with it.

Ok, I recognized that I tried it before downloading the 1.3, it has the same problem that I reported on the 1.3 and moreover it shows the from address in a wrong format. :(

Ciao!
Fabio

--- GoldED+/LNX 1.1.5-b20180707
* Origin: ]\/[imac Rebirth Boss Point (2:335/364.1)

it has the same problem that I reported on the 1.3 and moreover it shows the from address in a wrong format. :(

Well, then, I'm sorry to admit that I'm out of suggestions. Never tried it myself...



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

Hello Björn!

23 Jul 19 14:37, you wrote to me:

it has the same problem that I reported on the 1.3 and moreover
it shows the from address in a wrong format. :(

Well, then, I'm sorry to admit that I'm out of suggestions. Never
tried it myself...

Ok, I built the 1.3 on a 32bit linux (my primary point), same software of the node (Husky, HPT and so on) and it works fine, send the message and hpt when scan it doesn't crash and packs the message correctly.

So it's a 64 bit issue! :(

Any clue?

Thank you.

Ciao!
Fabio

--- GoldED+/LNX 1.1.5-b20180707
* Origin: ]\/[imac Rebirth Boss Point (2:335/364.1)

So it's a 64 bit issue! :(

So it seems, yes. Remember that it's originally an Amiga-program, that Johan and I converted to mainly Windows. XP at the time. We had a hell of a time preventing it from crashing on that 32-bit system.

Any clue?

Most likely a #define somewhere that depends on a max 32-bit line-up and bugs out in a 64-bit environment. But I'll leave that to the other experts here, that's dabbled with a 64-bit version (if any).

Did I mention that I hate C? The University of Berkeley, California is famous for three things: Unix, C and LSD. Go figure... 8-)



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

Ok, I built the 1.3 on a 32bit linux (my primary point), same software
of the node (Husky, HPT and so on) and it works fine, send the message
and hpt when scan it doesn't crash and packs the message correctly.

Yes. Works fine also in my Raspberry PI2 / Ubuntu 32bit. As well as in
OS/2. Of course. :)

So it's a 64 bit issue! :(

It is.

Have you tried SmapiNNTPd? Compiles and runs nice in 64bit LInux. :)

'Tommi

--- Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
* Origin: smapinntpd/linux @ nntps://news.fidonet.fi (2:221/6.0)

Hello Björn!

23 Jul 19 15:42, you wrote to me:

Any clue?

Most likely a #define somewhere that depends on a max 32-bit
line-up and bugs out in a 64-bit environment. But I'll leave that to
the other experts here, that's dabbled with a 64-bit version (if any).

I digged a bit and the problem should be the ulong type that differs in the 64 bit os.

https://usrmisc.wordpress.com/2012/12/27/integer-sizes-in-c-on-32-bit-and-64-bi
t-linux/

type \ executable[1] 32 bit 64 bit
short int 16 bit 16 bit
int 32 bit 32 bit
long int 32 bit 64 bit
long long int 64 bit 64 bit
size_t 32 bit 64 bit
void* [2] 32 bit 64 bit

and obviusly is present in both jamlib and jamnntpd server. :D

Did I mention that I hate C? The University of Berkeley, California
is famous for three things: Unix, C and LSD. Go figure... 8-)

C is the perfection, but who wants to be perfect? :P :P :P

Ciao!
Fabio

--- GoldED+/LNX 1.1.5-b20180707
* Origin: ]\/[imac Rebirth Boss Point (2:335/364.1)

Hello Tommi!

23 Jul 19 17:21, you wrote to me:

So it's a 64 bit issue! :(

It is.

Have you tried SmapiNNTPd? Compiles and runs nice in 64bit LInux. :)

Wow, this is a great new!!! :)

Where can I find it?

Many Thanks! ;)

Ciao!
Fabio

--- GoldED+/LNX 1.1.5-b20180707
* Origin: ]\/[imac Rebirth Boss Point (2:335/364.1)

Have you tried SmapiNNTPd? Compiles and runs nice in 64bit LInux. :)

Wow, this is a great new!!! :)

Where can I find it?

https://github.com/ftnapps/smapinntpd

Many Thanks! ;)

Ciao!
Fabio

No problem!

--- Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
* Origin: smapinntpd/linux @ nntps://news.fidonet.fi (2:221/6.0)

Il 23/07/19 15:08, 2221/6.0 ha scritto:

Where can I find it?

https://github.com/ftnapps/smapinntpd

It should work... ;)

Ciao.

Fabio.

--- Mozilla/5.0 (X11; Linux i686; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
* Origin: ]\/[imac Rebirth smapinntpd access nntp://mimac.bizzi.org

Hello, Fabio Bizzi.
On 24/07/2019 14.11 you wrote:

From Fabio Bizzi To

Il 23/07/19 15:08, 2221/6.0 ha scritto:

Where can I find it?

https://github.com/ftnapps/smapinntpd

It should work... ;)

+1 :)

Ciao.
Fabio.
--- Mozilla/5.0 (X11; Linux i686; rv:60.0) Gecko/20100101

Thunderbird/60.8.0

* Origin: ]\/[imac Rebirth smapinntpd access nntp://mimac.bizzi.org (2:335/364)

--
'Tommi

---
* Origin: nntp://rbb.fidonet.fi - Lake Ylo - Finland (2:221/360)

Hello, Tommi Koivula.
On 24/07/19 19:06 you wrote:

Where can I find it?

It should work... ;)

+1 :)

I think I have to read carfully the docs, the to: field is empty and I have to tune the access to the echo areas, but it's a good point to start. :)

Thank you again. ;)
--
Ciao! :)
Fabio.
--- Hotdoged/2.13.5/Android
* Origin: ]\/[imac boss android point (2:335/364.3)

Re: The latest official release
By: Tommi Koivula to Fabio Bizzi on Tue Jul 23 2019 05:21 pm

Have you tried SmapiNNTPd? Compiles and runs nice in 64bit LInux. :)

Nice! I just made my CentOS 7.6 smapinntpd.spec to compile it and am prepping to try it out myself.

I was considering trying jamnntpd on my server before, but when I did, I didn't
really have much luck. Didn't dig into why, but based on the conversations I've
been recently reading, I'm starting to understand a bit.

One thing I noted was that somewhere it said not to use hpt pack, which I understand that's only packing netmail, per hpt docs.

I wonder if this'll be any problem with sqpack...... Since it's being mentioned
about packing netmail already can be problematic. ;)

)))[Psi-Jack -//- Decker]
--- SBBSecho 3.07-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

On 2019 Jul 24 20:08:30, you wrote to Tommi Koivula:

One thing I noted was that somewhere it said not to use hpt pack, which I understand that's only packing netmail, per hpt docs.

the problem is that some mail management tools insist on renumbering the messages when the base is packed to reduce the diskspace consumed... if your message base maintenance tool can purge, pack, and renumber as three separate and distinct tasks, go ahead with the first two and just do not renumber...

when the bases are renumbered, the message numbers are changed... news clients are the ones that store the read pointers and not the server which we're used to as sysops running BBSes... when the server changes the message numbers, the client is out of sync and it is very troublesome for the users to have to resubscribe or redownload all the messages and try to find their place again...

the best and most simple thing to do is to not purge, pack, or renumber the message bases... just keep all the messages until the base corrupts itself... with JAM having such large constraints, things should be fine for a long time in most cases...

)\/(ark

Once men turned their thinking over to machines in the hope that this would set them free. But that only permitted other men with machines to enslave them.
... Thanks for your warning, but my cardiologist needs a new yacht.
---
* Origin: (1:3634/12.73)

the best and most simple thing to do is to not purge, pack, or renumber the message bases...

As a general rule, that is a very good one.

If however you feel adventurous you may try Johan Billing's crashmaint program (part of the CrashMail II program suite).

I run it from time to time, like once a year or so, mostly to make linking a wee bit faster. It hasn't corrupted anything yet (after ten years) I simply run it like this:

crashmaint MAINT PACK

Needless to say you have to use CrashMail II and tell it in the config how many messages you want to keep:

KEEPNUM 1000

This for every echo. If no KEEPNUM is defined, crashmaint will not touch the echo. It will of course *not* renumber any message base, but it will become much smaller.




..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

Hi Fabio.

24 Jul 19 18:37:18, you wrote to me:

Hello, Tommi Koivula.
On 24/07/19 19:06 you wrote:

Where can I find it?

It should work... ;)

+1 :)

I think I have to read carfully the docs, the to: field is empty and I

have to tune the access

to the echo areas, but it's a good point to start. :)

The "from -> to" -field still has problems with Thunderbirds after v31. :(

'Tommi

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

Hi Eric.

24 Jul 19 20:08:30, you wrote to me:

Re: The latest official release
By: Tommi Koivula to Fabio Bizzi on Tue Jul 23 2019 05:21 pm

Have you tried SmapiNNTPd? Compiles and runs nice in 64bit LInux. :)

Nice! I just made my CentOS 7.6 smapinntpd.spec to compile it and am

prepping

to try it out myself.

+1

One thing I noted was that somewhere it said not to use hpt pack, which I understand that's only packing netmail, per hpt docs.

Yes, there's nothing wrong with packing jamnntpd netmail. :)

I wonder if this'll be any problem with sqpack...... Since it's being mentioned about packing netmail already can be problematic. ;)

You can pack and purge message bases as long as you make sure the messages do not get renumbered. I studied this some time ago. One of the husky programs, hptutil or sqpack, is ok to pack squish base but not jam. I cannot remember which one. :)

'Tommi

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

Re: The latest official release
By: Tommi Koivula to Eric Renfro on Sat Jul 27 2019 10:04 am

Nice! I just made my CentOS 7.6 smapinntpd.spec to compile it and am

prepping

to try it out myself.

+1

Yeah. I can RPM package just about everything. For .deb, I'm going to restrict myself to using "fpm" or, Freaking Package Manager, to make those, because they're such a PITA trying to do it their native way.

One thing I noted was that somewhere it said not to use hpt

pack, which I understand that's only packing netmail, per hpt docs.

Yes, there's nothing wrong with packing jamnntpd netmail. :)

Hmmm, well, why would the jamnntpd/smapinntpd say that about hpt pack then, which only does pack netmail? heh. Granted my netmail is JAM (and Netmail2 is fido *.msg)..

You can pack and purge message bases as long as you make sure the

messages

do not get renumbered. I studied this some time ago. One of the husky programs, hptutil or sqpack, is ok to pack squish base but not jam. I cannot remember which one. :)

I'd be curious more about that. I specifically originally chose to have JAM message bases because I wanted the ability to use JamNNTPd specifically, but now that I know of and have SmapiNNTPD, I could go through the idea of changing
that, rescanning the messages to re-populate, to switch between them.

If you could recall specifics on that that could be quite helpful for me, since.. Well, SmapiNNTPD supports Squish and JAM and *.msg because of SMAPI. :)

)))[Psi-Jack -//- Decker]
--- SBBSecho 3.08-Linux
* Origin: Decker's Heaven -//- bbs.deckersheaven.com (1:135/371)

On 2019 Jul 27 10:02:54, you wrote to Fabio Bizzi:

I think I have to read carfully the docs, the to: field is empty and
I have to tune the access to the echo areas, but it's a good point to
start. :)

The "from -> to" -field still has problems with Thunderbirds after v31.

:(

IIRC, that's a tbird problem in that they are forcing compliance with the spec for the address format... the right side of the address doesn't appear as a valid internet domain...

)\/(ark

Once men turned their thinking over to machines in the hope that this would set them free. But that only permitted other men with machines to enslave them.
... Krushchev credited SPAM with the survival of the WWII Russian army.
---
* Origin: (1:3634/12.73)

Saturday July 27 2019 14:16, Eric Renfro wrote to Tommi Koivula:

Yes, there's nothing wrong with packing jamnntpd netmail. :)

Hmmm, well, why would the jamnntpd/smapinntpd say that about hpt pack

then,

which only does pack netmail? heh. Granted my netmail is JAM (and

Netmail2 is

fido *.msg)..

"Packing" netmail in hpt is really "sending" netmail. :)

Packing msgbase is something else.

I'd be curious more about that. I specifically originally chose to have

JAM

message bases because I wanted the ability to use JamNNTPd specifically,

but

now that I know of and have SmapiNNTPD, I could go through the idea of

changing

that, rescanning the messages to re-populate, to switch between them.

If you could recall specifics on that that could be quite helpful for me, since.. Well, SmapiNNTPD supports Squish and JAM and *.msg because of

SMAPI. :)

I re-tested. Sqpack always renumbers, but "hptutil pack" does not renumber squish base.

I still prefer not to purge/pack my messagebases that are used by smapi/jamnntpd.

'Tommi

---
* Origin: ---------------------------------->> (2:221/360)