Expected date of availability: January 2023 (Beta)Great news!
You can access it here : news.spitfire-nntp.fr:119
- Native support for SSL/TLS
Work finished
I'm glad to see a fresh new news server :-)
- Native support for SSL/TLSIsn't there support for STARTTLS or connection on port 563 in your
testing server?
Work finished
The beginning of a long road!
Maybe it's worth saying that it natively supports 64-bit article
numbers. I don't remember if it can be enabled by the news admin with a configurable option or if it needs a new release which allows that
(possibly with a yet-not-standardized "bignum" capability to advertise).
Yes, SNS is ready for 64-bit articles numbers but I haven't implemented
a way to activate this feature because BIGNUM is not officialy
standardized and because I don't even know if a reader suppport this!
Maybe it's worth saying that it natively supports 64-bit article
numbers. I don't remember if it can be enabled by the news admin with a configurable option or if it needs a new release which allows that (possibly with a yet-not-standardized "bignum" capability to advertise).
Yes, SNS is ready for 64-bit articles numbers but I haven't implemented
a way to activate this feature because BIGNUM is not officialy
standardized and because I don't even know if a reader suppport this!
I think that needing to check or activate the capability by a client
command is not useful, and if there are any such articles then either
way, older clients will not work, but if it is disactivated by default
then it is unclear what to do if there are too many articles and
possibly there will be no indication of anything wrong, while if it is
always activated then it is likely that there will be an error message
or something else happening that you can see that something is wrong.
Do to this, my own server and client implementation always support
64-bit article numbers, without any command to activate this
feature. (Although, my server is unlikely to ever have so many articles
that it matters, but the software supports it if necessary.)
tin can handle these since version 2.1.0 from 2011-12-24
bignumbers 1
202 2147483647 is our mutual maximum.
But if there are clients that explode if LIST ACTIVE data is 64-bit
numbers (which seems quite possible to me), the server could just hide
groups with too-large article numbers from LIST and GROUP from clients
that don't enable the extension, which allows graceful degredation of
service to those clients, allowing them to keep reading all the groups
with smaller numbers.
If anyone does implement this in the above way, the client will need to
send the extension command, or otherwise you won't see groups that are present on the server.
Just for testing purpose, I implemented an extension on my server.
group local.test.bignumbers
411 no such newsgroup.
head <BZLQGoHgm1M@news.spitfire-nntp.fr>
430 no article with that message-id.
I think the primary way the extension would be useful would be to handle clients that will misbehave if the article numbers in LIST ACTIVE are too large.
But if there are clients that explode if LIST ACTIVE data is 64-bit
numbers (which seems quite possible to me), the server could just hide
groups with too-large article numbers from LIST and GROUP from clients
that don't enable the extension, which allows graceful degredation of
service to those clients, allowing them to keep reading all the groups
with smaller numbers.
Given the fact that no ideas, not disruptive to existing clients, and
easier to implement had been found for 2 decades, maybe it's now time to
go ahead and use it.
We should find the best name for that extension. Instead of BIGNUM or BIGNUMBERS, why not call it MAXARTNUM which is more meaningful?
On 06/12/2022 22:22, Julien ÉLIE wrote:
Hi Franck,
Expected date of availability: January 2023 (Beta)Great news!
I'm glad to see a fresh new news server :-)
What is there to be glad of when it is likely to be another private
hobby server for somebody to satisfy his ego. Public servers for anybody
to use are almost gone and this is partly because of censorship imposed
by silly server administrators.
This is a welcome feat and your hard work is appreciated. Keep on
truckin', hacker.
I hope that more open NNTP servers will be established in the wake of
your project.
Hello Julien,
Given the fact that no ideas, not disruptive to existing clients, and
easier to implement had been found for 2 decades, maybe it's now time to
go ahead and use it.
[1] Two decades later, servers still have to complexify their code to be "cool" with some "readers" who have had enough time to be updated.
[1] Two decades later, servers still have to complexify their code to be
"cool" with some "readers" who have had enough time to be updated.
I still have users using trn. :)
[1] Two decades later, servers still have to complexify their code to be "cool" with some "readers" who have had enough time to be updated.
Le 07/12/2022 20:20, Franck a crit :
This is a test message with a BIGNUMBER.An a reply.
It seems that Urs Janßen is testing "BIGNUMBERS" with "tin".
So, I'll have a look on how to implement suggestions made by Julien ASAP.
Given the fact that no ideas, not disruptive to existing clients, and
easier to implement had been found for 2 decades, maybe it's now time
to go ahead and use it.
[1] Two decades later, servers still have to complexify their code to be "cool" with some "readers" who have had enough time to be updated.
BIGNUMBERS was just a proof of concept, quickly implemented, to show SNS source code is BIGNUM ready. It's in no way an "extension" that will
stay active at release date.
For "MAXARTNUM", it's a good name, even if I'm not sure point [1] is a
good idea.
The best thing to do in a server implementation would probably an option
to activate/deactivate this extension (globally or per reader or groups
of readers).
Let's keep MAXARTNUM then.
I'll open another thread with a proposal of functional rules to discuss,
in an Internet-Draft style. Sorry for having polluted this thread about Spitfire!
So, I'll have a look on how to implement suggestions made by Julien ASAP.
I think you shouldn't bother with the "MAXARTNUM ^31" notation; it is extra-complexity for nothing. The most interesting point is the 401 reply. Kudos to Clive for it!
At this stage, if you use MAXARTNUM then NEXT, you will receive (by
error) the same response code. I'll fix this by the end of the day.
MAXARTNUM is now available for testing in Spitfire News Server.
If you find an error or have a suggestion, please let me know. > Most of the job is done, at least for :
GROUP / LISTGROUP
OVER / HDR
NEXT
and so on.
MAXARTNUM accept a number, ^31 and ^63, as stated in HELP :-)
The maximum negotiated article number should apply to the high water
mark, the low water mark and the estimated article count. I've not
checked how Spitfire behaves but all of these 3 numbers must not exceed
the limit.
If a newsgroup has 2^40 articles, the estimated article count is 2^31-1.
The articles below 2^31-1 are available, and those above return "401 MAXARTNUM" if the MAXARTNUM has not been used. And if MAXARTNUM has
already been used with 2^31-1, I think the easiest thing is to go on
sending 401.
The estimated article count sums all the articles (below and above the limit).
NEWNEWS news.software.nntp yyyymmdd hhmmss
should return all the Message-IDs since their last connection, and a
bunch of ARTICLE <mid> should return them!
So old legacy news clients could be parametered to use NEWNEWS (if of
course they offer that level of setting) on news servers with large
article numbers.
And not ^50 for instance?
I am unsure that notation should be kept, but anyway it could if you
think it is easier to read. (It adds more hassle to the developer in
order to parse and check that syntax.)
It should be a syntax error (501) if < ^31 and recognized after ^31.
We could also define MAXARTNUM without any argument to say that the
server or client complies with the specification and has no limit in the maximum number it handles.
Good idea, but for the moment, SNS can only handle up to ^63.Source code improved, MAXARTNUM updated to use ^31-64.
If a newsgroup has 2^40 articles, the estimated article count is
2^31-1. The articles below 2^31-1 are available, and those above
return "401 MAXARTNUM" if the MAXARTNUM has not been used. And if
MAXARTNUM has already been used with 2^31-1, I think the easiest thing
is to go on sending 401.
It's coded like that execpt 401 is "401 maximum article number reached".
As it is often dispayed to user, we can set it something more explicit
like : 401 maximum article number reached, use MAXARTNUM for next article.
Once used, MAXARTNUM never change during all the session and 202 with
the same value is sent.
It should be a syntax error (501) if < ^31 and recognized after ^31.
Coded like that. And also syntax error if > ^63.
You can't do that for a 401 answer.
You really need:
401 MAXARTNUM
From RFC 3977:
I think 502 could be better (like what is done if you try a second
STARTTLS, AUTHINFO, COMPRESS..).
502 Mutual maximum article number already negotiated
It should normally not be a syntax error if > ^63.
The mutual maximum number will just be 2^63-1.
It should normally not be a syntax error if > ^63.
The mutual maximum number will just be 2^63-1.
And an error if set < ^31-1?
Sounds strange to me, why not to use the "minimal" 2^31-1 in this case?
Hello,
In order to test all the features implemented so far in "Spitfire News Server" (see below) the "fr" hierarchy is freely available on my server
(read and write without prior registration).
You can access it here : news.spitfire-nntp.fr:119
Please report any problems or suggestions only in the local group : local.spitfire.news.server
-----------------------------------------------------------------------
SPITFIRE NEWS SERVER
An IPv4/IPv6, multi-threaded news server for Windows platforms (64 bits only).
In a nutshell: An all-in-one, script-free, hassle-free news server for everyone. -----------------------------------------------------------------------
Work finished:
-------------
- All NNTP v2 commands implemented for both 'Readers' and 'Servers', including CHECK & TAKETHIS (RFC 3977, 4643, 4644, 6048),
- Built-in feeds module (Incoming and outgoing),
- Built-in accounting module,
- Built-in usage limitations module (Per minute and/or day),
- Built-in bans module (Works in conjunction with usage limitations),
- Built-in expiration module.
No external software or library required:
- Native support for IPv4/IPv6,
- Native support for SSL/TLS,
- Native support for Cancel-Locks (RFC 8315), including MD5, SHA1,
SHA256, SHA384 & SHA512 hashes,
- Native but limited SASL support.
Work in progress (Available in first release): ---------------------------------------------
- Graphical user interface (English and French),
- Built-in module to sync active newsgroups list,
- Built-in MTA module,
- Various tools to maintain database and generate 'Cancels',
- Installer,
- Minimal documentation.
Work in progress (Available in future releases): -----------------------------------------------
- Support for Proxy SOCKS5,
- Built-in filters module (Does not require Postfilter/Cleanfeed),
- Various tools to search and display logged data,
- Full detailled documentation.
Planed features:
---------------
- Detection and action against nymshifting (Works with limitations and
bans),
- Built-in statistics module,
- Built-in suck-feeds module,
- Web user interface,
- Full native SASL support,
- Full native OpenPGP support.
Licence: Freeware.
Expected date of availability: January 2023 (Beta)
I would say try for a linux version as well.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 60:21:03 |
| Calls: | 6,712 |
| Files: | 12,243 |
| Messages: | 5,355,758 |
