Hi everyone,
A few days ago Marco Mook contacted me after noticing binary articles >appearing in text-only newsgroups.
Like many other news administrators, I rely on Cleanfeed to keep transit >feeds as clean as possible. After investigating the issue, I discovered
that the latest public version of Cleanfeed (available from Steve
Crook's GitHub repository) still contains a number of long-standing
issues, including some that have already been reported over the years.
Since the project has seen little activity for quite some time, I
decided to start a maintenance update for my own servers. What initially >started as a small fix quickly turned into a much larger cleanup, so I >thought it might be useful to share it with other INN administrators.
You can download the package here:
http://www.bofh.team/software/cleanfeed-2026.zip
This is intended to be a **maintenance fork**.
My goal is to preserve Cleanfeed's original philosophy while fixing
bugs, modernizing the code where appropriate and keeping it usable on >current INN installations, without turning it into a heavyweight
filtering framework.
For the time being I simply renamed the package to avoid confusion with
the original Cleanfeed distribution. My intention is not to replace the >original project, but to keep it maintained and usable on modern INN >installations. If development of the original Cleanfeed project resumes
in the future, I would be happy to see any useful changes merged
upstream whenever possible.
##################
### Highlights ###
##################
* Numerous bug fixes throughout the Perl code.
* Improved detection of misplaced binary articles (yEnc, MIME, Base64, >uuencode and related cases).
* Fixed several long-standing bugs and inconsistencies.
* Added configuration validation and consistency checks.
* Added optional peer-based and hierarchy-based policies.
* Added lightweight operational features (configuration fingerprinting,
rule inventory, diagnostics, standalone configuration checker and
article tester).
* Improved logging and rejection reporting with stable reason codes.
* Updated the bundled Python helper tools from Python 2 to Python 3 and >removed obsolete dependencies.
* Reorganized and simplified the documentation. The example
configuration files are now extensively commented and intended to serve
as the primary and complete reference.
* General code cleanup and removal of obsolete historical references.
* Many smaller fixes and maintenance improvements, see README and .md file.
The package has been tested on one of my transit servers as well as on
my text-only server and has been running without issues so far. But pay >attention, the package is provided "as is", without any warranty.
Particular attention has been paid to performance. Since this filter
runs in the article transit, I tried to keep every new feature as >lightweight as possible, avoiding unnecessary overhead on busy servers.
This is certainly not a perfect release, but I believe it provides a
solid foundation for keeping Cleanfeed alive on modern systems.
Questions, bug reports, suggestions and patches are all welcome, either
here or by email.
Although I don't currently have a public Git repository, I am more than >happy to review and integrate contributions sent by email.
The goal of this project is not to reinvent Cleanfeed, but to keep a
proven and widely deployed filter healthy, maintainable and compatible
with today's INN installations.
#######################
## Special thanks to ##
#######################
* Ray Banana (Eternal September), for pointing me in the right direction
and helping identify where the first fixes were needed.
* Marco d'Itri and Steve Crook (Linux and Mixmin), for creating and >maintaining Cleanfeed over many years.
* Julien |elie (Trigofacile), for continuing to develop and maintain
INN2.*, and for the passion and dedication he puts into the project
every day.
* Russ Allbery (Eyrie.org|ISC), for his outstanding Perl documentation,
the INN documentation and the many technical resources that made this
work considerably easier.
I also want to thank everyone who reported bugs, discussed Cleanfeed
over the years and kept Usenet alive. Their reports and discussions were >invaluable while reviewing and modernizing the code.
I hope this maintenance release proves useful to other newsmasters.
Sincerely
----
Ivo Gandolfo
Hi everyone,
A few days ago Marco Mook contacted me after noticing binary articles >appearing in text-only newsgroups.
Like many other news administrators, I rely on Cleanfeed to keep transit >feeds as clean as possible. After investigating the issue, I discovered
that the latest public version of Cleanfeed (available from Steve
Crook's GitHub repository) still contains a number of long-standing
issues, including some that have already been reported over the years.
Since the project has seen little activity for quite some time, I
decided to start a maintenance update for my own servers. What initially >started as a small fix quickly turned into a much larger cleanup, so I >thought it might be useful to share it with other INN administrators.
You can download the package here:
http://www.bofh.team/software/cleanfeed-2026.zip
This is intended to be a **maintenance fork**.
My goal is to preserve Cleanfeed's original philosophy while fixing
bugs, modernizing the code where appropriate and keeping it usable on >current INN installations, without turning it into a heavyweight
filtering framework.
For the time being I simply renamed the package to avoid confusion with
the original Cleanfeed distribution. My intention is not to replace the >original project, but to keep it maintained and usable on modern INN >installations. If development of the original Cleanfeed project resumes
in the future, I would be happy to see any useful changes merged
upstream whenever possible.
##################
### Highlights ###
##################
* Numerous bug fixes throughout the Perl code.
* Improved detection of misplaced binary articles (yEnc, MIME, Base64, >uuencode and related cases).
* Fixed several long-standing bugs and inconsistencies.
* Added configuration validation and consistency checks.
* Added optional peer-based and hierarchy-based policies.
* Added lightweight operational features (configuration fingerprinting,
rule inventory, diagnostics, standalone configuration checker and
article tester).
* Improved logging and rejection reporting with stable reason codes.
* Updated the bundled Python helper tools from Python 2 to Python 3 and >removed obsolete dependencies.
* Reorganized and simplified the documentation. The example
configuration files are now extensively commented and intended to serve
as the primary and complete reference.
* General code cleanup and removal of obsolete historical references.
* Many smaller fixes and maintenance improvements, see README and .md file.
The package has been tested on one of my transit servers as well as on
my text-only server and has been running without issues so far. But pay >attention, the package is provided "as is", without any warranty.
Particular attention has been paid to performance. Since this filter
runs in the article transit, I tried to keep every new feature as >lightweight as possible, avoiding unnecessary overhead on busy servers.
This is certainly not a perfect release, but I believe it provides a
solid foundation for keeping Cleanfeed alive on modern systems.
Questions, bug reports, suggestions and patches are all welcome, either
here or by email.
Although I don't currently have a public Git repository, I am more than >happy to review and integrate contributions sent by email.
The goal of this project is not to reinvent Cleanfeed, but to keep a
proven and widely deployed filter healthy, maintainable and compatible
with today's INN installations.
#######################
## Special thanks to ##
#######################
* Ray Banana (Eternal September), for pointing me in the right direction
and helping identify where the first fixes were needed.
* Marco d'Itri and Steve Crook (Linux and Mixmin), for creating and >maintaining Cleanfeed over many years.
* Julien |elie (Trigofacile), for continuing to develop and maintain
INN2.*, and for the passion and dedication he puts into the project
every day.
* Russ Allbery (Eyrie.org|ISC), for his outstanding Perl documentation,
the INN documentation and the many technical resources that made this
work considerably easier.
I also want to thank everyone who reported bugs, discussed Cleanfeed
over the years and kept Usenet alive. Their reports and discussions were >invaluable while reviewing and modernizing the code.
I hope this maintenance release proves useful to other newsmasters.
Sincerely
--
Ivo Gandolfo
Julien please add.
Like many other news administrators, I rely on Cleanfeed to keep transit feeds as clean as possible. After investigating the issue, I discovered
that the latest public version of Cleanfeed (available from Steve
Crook's GitHub repository) still contains a number of long-standing
issues, including some that have already been reported over the years.
Since the project has seen little activity for quite some time, I
decided to start a maintenance update for my own servers. What initially started as a small fix quickly turned into a much larger cleanup, so I thought it might be useful to share it with other INN administrators.
http://www.bofh.team/software/cleanfeed-2026.zip
My goal is to preserve Cleanfeed's original philosophy while fixing
bugs, modernizing the code where appropriate and keeping it usable on current INN installations, without turning it into a heavyweight
filtering framework.
##################
### Highlights ###
##################
* Improved detection of misplaced binary articles (yEnc, MIME, Base64, uuencode and related cases).
* Added optional peer-based and hierarchy-based policies.
* Reorganized and simplified the documentation. The example
configuration files are now extensively commented and intended to serve
as the primary and complete reference.
Another request: you can send me via email your news.notice log file (filtered of course, I'm only intrested to "filter:" line, for debug pourpouse)?
Il 12/07/2026 21:05, The Doctor ha scritto:
Julien please add.
Hey Doc, I see in your innreport stat some trouble:
Jul 12 13:10:09 gallifrey innd[55794]: filter: Ignoring invalid bad_from >regex; keeping previous compiled value: Unterminated \g... pattern in
regex; marked by <-- HERE
Check the config :D Some rules you put it's invalid and the filter
warning you.
Another request: you can send me via email your news.notice log file >(filtered of course, I'm only intrested to "filter:" line, for debug >pourpouse)?
Thanks
Sincerely
--
Ivo Gandolfo
Hi Ivo,
Regarding the log lines: rejection logging is enabled by default, and
the new policy and anomaly checks that use `audit` or `reject` mode are
also intended to produce diagnostic events when they match. the `audit`
it's born just to test if everything working fine before switching to `reject` mode (just-in-case if you put something wrong in the config,
the filter warning you something is wrong into the log's, and don't
apply it but using latest working rules or nothing if no previous rules
was applied).
No additional INN setting should normally be required if Cleanfeed
messages are already reaching `news.notice`.
The current release still supports both files, and the new `mtime`-based reload mechanism can detect an atomic replacement and load the updated
rules without requiring changes to the main filter.
The difficult part is not the updater itself but deciding who maintains
the lists, defining inclusion and removal criteria and avoiding stale entries and false positives, same as for the NoCEM notice.
Unfortunately the original central lists from Mixmin are no longer maintained, so the real challenge is finding a reliable source for them.
If the newsmaster community is interested this is definitely something
we could work on together.
Hi Ivo,..
The criteria can be mentioned in the same GitHub page (put a README.md
file in the subdirectory).
Wouldn't it suit the needs?
Il 13/07/2026 17:29, Julien |eLIE ha scritto:
Hi Ivo,..
The criteria can be mentioned in the same GitHub page (put a README.md
file in the subdirectory).
Wouldn't it suit the needs?
Hi Julien,
So... are you trying to trick me into becoming the Cleanfeed maintainer? >*sigh* :-)
Regarding the log messages: if you want to see the additional
diagnostics generated by my version, you can have a look at one of The >Doctor innreport pages:
https://gallifrey.nk.ca/news-notice.2026.07.12-01.00.00.html
There are already several examples from the new filter there.
I suspect your logging configuration simply routes these messages
somewhere else (perhaps `news.debug` or another syslog destination). It >would be interesting to compare our configurations and find out where
they go.
For reference, I'm simply using the standard syslogd on Ubuntu,
installed by package manager apt and never changed.
As for GitHub... you caught me there :-)
To be completely honest, I have never really used GitHub. The most
advanced thing I've ever done there was clicking the "Download ZIP"
button *hrhr* :-P
I've always written software for my own infrastructure and never
maintained a public open-source project. My day job is as a system >administrator, not as a software developer, so this whole "project >maintainer" role is rather new to me.
That said, I understand your point. A public repository would certainly
make collaboration, bug reporting and maintaining the central lists much >easier than exchanging ZIP files by email.
So perhaps it's time for me to learn. I can't promise I'll become a
GitHub expert overnight, but I'm certainly willing to give it a try if >that's the best way to keep the project alive and make it easier for
others to contribute.
Many thanks again for your suggestions. They are greatly appreciated.
Sincerely
--
Ivo Gandolfo
I wonder if we need an INN / cleanfeed development committee / committers.
http://www.bofh.team/software/cleanfeed-2026.zipWith the exception of badurls_tool, I've noticed that new configuration directives
* Numerous bug fixes throughout the Perl code.
* Improved detection of misplaced binary articles (yEnc, MIME, Base64, > uuencode and related cases).
* Fixed several long-standing bugs and inconsistencies.
* Added configuration validation and consistency checks.
* Added optional peer-based and hierarchy-based policies.
* Added lightweight operational features (configuration fingerprinting,
rule inventory, diagnostics, standalone configuration checker and
article tester).
* Improved logging and rejection reporting with stable reason codes.
* Updated the bundled Python helper tools from Python 2 to Python 3 and removed obsolete dependencies.
* Reorganized and simplified the documentation. The example
configuration files are now extensively commented and intended to serve
as the primary and complete reference.
* General code cleanup and removal of obsolete historical references.
* Many smaller fixes and maintenance improvements, see README and .md file.
So... are you trying to trick me into becoming the Cleanfeed maintainer? *sigh* :-)
Regarding the log messages: if you want to see the additional
diagnostics generated by my version, you can have a look at one of The Doctor innreport pages:
https://gallifrey.nk.ca/news-notice.2026.07.12-01.00.00.html
There are already several examples from the new filter there.
I suspect your logging configuration simply routes these messages
somewhere else (perhaps `news.debug` or another syslog destination). It would be interesting to compare our configurations and find out where
they go.
For reference, I'm simply using the standard syslogd on Ubuntu,
installed by package manager apt and never changed.
I've always written software for my own infrastructure and never
maintained a public open-source project. My day job is as a system administrator, not as a software developer, so this whole "project maintainer" role is rather new to me.
That said, I understand your point. A public repository would certainly
make collaboration, bug reporting and maintaining the central lists much easier than exchanging ZIP files by email.
So perhaps it's time for me to learn. I can't promise I'll become a
GitHub expert overnight, but I'm certainly willing to give it a try if that's the best way to keep the project alive and make it easier for
others to contribute.
I finally created my very first GitHub repository.
Actually, I don't see this project as being limited to Cleanfeed
anymore. I'm also working on modernizing "postfilter", previously
maintained by Paolo Amoroso (Aioe) the NNRP-side filter for INN, which I expect to release in the next few days. So the idea is gradually
evolving into a small collection of maintained filters for INN rather
than a single standalone project.
So, for now, I'd rather keep things simple: one repository, open discussions, bug reports, pull requests and contributors. If, over time, these projects attract contributors and prove useful to the wider INN community, then having a small group of maintainers or committers would probably be the natural next step. A committee should be the consequence
of an active project, not its starting point.
Let's first make the software solid, useful and well tested. If the community grows around it, the governance can grow naturally as well.
Hi everyone,
With the exception of badurls_tool, I've noticed that new configuration directives
have been implemented starting with the version I'm running on my server... Do I need to update right away, or can I wait for new guidelines?
diff file from my version of cleanfeed: https://news.corradoroberto.it/diff_cleanfeed.html https://news.corradoroberto.it/diff_local.html
Thank you for all your hard work!
OK I see.
I will add an innreport rule so that they do not appear in the reports. innreport currently filters:
[...]
would probably do the job.
Do you happen to see other strings that should be discarded in daily
Usenet reports?
I understand.
I am not a software developer either. I just do a bit of development
for the pleasure on my spare time.
My day job consists in meetings, mails and PowerPoint ^^ :-)
Various things in project management, people coordination, functional
and technical roadmaps, requirements specifications in the domain of
public transport in Paris.
Following the encouraging feedback received over the past few days, I am pleased to announce that the project has now officially moved to GitHub
under its definitive name:
-a-a-a cleanfeed-ng
-a-a-a https://github.com/infybofh/cleanfeed-ng
The project is intended to be a community-maintained continuation of the historical Cleanfeed project, originally created by Marco d'Itri and
later maintained by Steve Crook.
What initially started as a small maintenance update to investigate
reports of misplaced binary articles in text-only newsgroups quickly
evolved into a much more extensive review of the entire codebase.
Starting with cleanfeed-ng, the project adopts a date-based versioning
scheme inspired by Ubuntu releases:
-a-a-a YYYY-MM-VV
where:
-a-a-a YYYY-a = release year
-a-a-a MM-a-a-a = release month
-a-a-a VV-a-a-a = incremental release number for that month
Examples:
-a-a-a 2026-07-01
-a-a-a 2026-07-02
-a-a-a 2026-07-03
Release Candidates append the "RC" suffix (for example 2026-07-03 RC1),
while stable releases simply use the version number.
The goal is to make the age and evolution of every release immediately obvious.
-a-a-a The codebase has also been simplified by removing obsolete
-a-a-a compatibility code and historical workarounds that are no longer
-a-a-a relevant on current INN installations and modern Perl releases.
Do you happen to see other strings that should be discarded in daily
Usenet reports?
Why discard or hide them?-a Let's give them their own section instead!
https://www.bofh.team/software/cleanfeed-ng-innreport-patch.zip
The new section provides:
* a total count of cleanfeed-ng events;
* counters grouped by action and rule;
* a configurable number of representative event samples.
Ainsi, la prochaine fois que je serai |a Paris, je saurai |a qui demander quel m|-tro prendre pour aller chercher un pain au chocolat et un bon
verre de vin. :D
* Improved detection of misplaced binary articles, including yEnc, MIME,
Base64, uuencode and related encodings.
Ivo Gandolfo wrote:
* Improved detection of misplaced binary articles, including yEnc, MIME,
Base64, uuencode and related encodings.
Is the update working as expected? The following misplaced binaries
showed up in my news reader.
If you're referring to articles on paganini, yes, I'm aware of that.
Since it's the only server I have, it's also my "test" server (I'll have
to make one sooner or later), so when I'm programming or testing the
filter might shut down, and any article might get through.
"Cleanfeed was originally developed by Jeremy Nixon who maintained it
until 1998.-a At that time, futher developments were taken on by Marco d'Itri who produced the last release in August 2001 with a beta version following in May 2002.-a [Then Steve Crook] produced a couple of updates
in December 2007."
If I may say, 2026-07-01 looks a bit confusing to my mind; I understand
July 1st.-a Wouldn't a naming closer to Ubuntu releases (as you mention them) be less confusing?
For example "cleanfeed-ng 26.07.1" etc. "cleanfeed-ng 26.07.3 RC1"?
Just a remark in case some other admins of servers other than INN would
be interested?
If nobody cares any longer, then let's go with INN only.-a It will be
easier to maintain and test!
On Jul 16, 2026 at 1:22:08rC>PM CDT, "Ivo Gandolfo" <usenet@bofh.team> wrote:
* Diablo *: The last stable release (5.1) from the official maintainer
was released in 2007. It was unofficially patched by engineer Miquel van
Smoorenburg, who worked for XS4ALL (a Dutch provider) until 2009.
Version 6.0 from 2013 (I think it only includes XS4ALL patches and small
changes, probably released by the same engineer) is still in
circulation, dating back to 2017, this version patched seems in use on
XS4ALL servers. Too many years have passed without further development,
even though the official website continues to take snapshots every day,
but no changes have been made. I think this too can be considered
"abandonware" if no one is thinking of continuing development. I
checked, and it also still has some active CVEs (although they don't
seem too dangerous, but you never know).
Some newsmaster here use them (Jesse Bluewordhosting I know) and alot of
USP (Abavia, XSNews, etc) as transit server, see:
I think Jesse compiled the version himself, and USP use latest "stable
and ancient" version.
Diablo isn't publicly maintained, but the commercial NSPs seem to have furthered development/fixed bugs, but no contribution has been made public (that I'm aware of). Which is really sad, because it is a beast in terms of throughput capabilities compared to INN.
* Highwings Cyclone and Typhoon *: NNTP software (proxy reader and
transit server) developed by Highwings Media, closed source and under a
pay license, and used by it and all its USP resellers. Cleanfeed
probably supported this type of server, but reading the manual,
unfortunately, reveals that external Perl filters are barely (if at all)
supported. It's full-blown abandonware. Don't laugh: it doesn't even
support IPv6, and the latest release is from 2010 and requires Linux
Kernel 2.6 (!!!) or Solaris 10 (!!!!!!). I wouldn't install a Solaris
server today even if they showered me with gold.
Highwinds doesn't publish any current information about Cyclone or Typhoon, but I believe it is still actively maintained, but is commercial only. (Also, don't be afraid of Solaris, it's quite a nice operating environment IMHO.) I'm
currently using OmniOS, an illumos-based distribution, which is a fork from OpenSolaris.
*NNTPSwitch*: It's an NNTP proxy, not an NNTP server (it uses INN or
Diablo servers as a backend for the articles, see the manual itself).
Starting out as closed-source, after NVE news-service.com's court defeat
against the RIAA, one of the developers released the sources. Some USPs
(and their resellers) still use it, but I think they've continued
developing in-house, in fact, some support IPv6 and have other features
that the version I found doesn't have. Regardless, it can be considered
abandonware or closed-source, but no longer officially developed.
I used NNTPSwitch for several years when it would compile on RHEL 5/6. I really enjoyed it and its features, but was unable to successfully compile on newer versions of Linux. I would *love* to see someone pick this project up.
However, if Jesse could read and tell us if he uses upstream filters, maybe we
could work
on it.
Steve Crook's version of Cleanfeed works with Diablo. I'm not currently using it on my Diablo transit server, but did at one time.
I'd be happy to setup a Diablo instance and give your filter a try.
Diablo isn't publicly maintained, but the commercial NSPs seem to have furthered development/fixed bugs, but no contribution has been made public (that I'm aware of). Which is really sad, because it is a beast in terms of throughput capabilities compared to INN.
Highwinds doesn't publish any current information about Cyclone or Typhoon, but I believe it is still actively maintained, but is commercial only. (Also, don't be afraid of Solaris, it's quite a nice operating environment IMHO.) I'm
currently using OmniOS, an illumos-based distribution, which is a fork from OpenSolaris.
I used NNTPSwitch for several years when it would compile on RHEL 5/6. I really enjoyed it and its features, but was unable to successfully compile on newer versions of Linux. I would *love* to see someone pick this project up.
I'd be happy to setup a Diablo instance and give your filter a try.
I was looking into these servers a bit to see how they worked, and one interesting thing in Typhoon and Diablo wrt CleanFeed:-a both daemons
share the same filter ABI, although Diablo doesn't have the FastFilter
shm option.-a Typhoon is heavily threaded, per connection and some helper pools, so filter and auth run in helper pools so you don't have to wait
for exec perl every time.
I guess cleanfeed could regrow that support.-a Not sure it matters on inn (currently) because perl is embedded and single process/thread but
something to consider if that changes.
Il 16/07/2026 23:12, Kevin Bowling ha scritto:
I was looking into these servers a bit to see how they worked, and one
interesting thing in Typhoon and Diablo wrt CleanFeed:-a both daemons
share the same filter ABI, although Diablo doesn't have the FastFilter
shm option.-a Typhoon is heavily threaded, per connection and some
helper pools, so filter and auth run in helper pools so you don't have
to wait for exec perl every time.
Al lot of difference between INN and that.
I guess cleanfeed could regrow that support.-a Not sure it matters on
inn (currently) because perl is embedded and single process/thread but
something to consider if that changes.
this is much more interesting than I initially expected.
If Diablo and Typhoon really share that FastFilter ABI, then supporting
them does not look like a complete port of cleanfeed-ng.-a The filtering engine itself only needs an article, its headers and body, and must eventually produce an accept or reject decision.
The main difference is therefore not the filtering logic, but the host adapter:
* INN embeds Perl inside innd and directly provides the article data and
-a INN logging functions;
* FastFilter runs as an external persistent process, retrieves the raw
-a article from shared memory and returns a 335 or 435 response.
A possible design would be to keep one common cleanfeed-ng engine and
provide two adapters:
-a-a-a INN adapter
-a-a-a FastFilter adapter for Diablo/Typhoon
The FastFilter adapter would handle the handshake, shared-memory access,
raw article parsing, logging and conversion of the cleanfeed-ng result
into the 335/435 wire response.
There are a few details that still need investigation.
Does the FastFilter interface expose the identity of the incoming
peer/feed, or only the raw article and Message-ID?
That matters because cleanfeed-ng has optional peer-based policies.
Audit mode can easily be implemented by logging a finding and returning
335, but quarantine may not have a direct equivalent if the ABI only
supports accept and reject.
Another point is worker state.-a If Diablo or Typhoon runs several filter helpers, each process would have its own caches, counters, EMP state and rate-limit data.-a Local caches are fine, but global state and persistent files would need to be handled carefully without adding expensive IPC to
the article path.
If the Diablo adapter works cleanly, Typhoon compatibility may follow
from the shared ABI, although it should still be tested on a real installation before being documented as supported, but in one case it's
need to pay, and I don't think it's necessary to spend time and money on that, HW don't filter anything.
Sincerely,
--
Ivo Gandolfo
Hi everyone,
Il 12/07/2026 16:03, Ivo Gandolfo ha scritto:
Hi everyone,
Hello again,
a small update about cleanfeed-ng after last patch.
The repository has now been public for a little over a week:
-a-a-a https://github.com/infybofh/cleanfeed-ng
According to GitHub's traffic statistics for the last 14 days, it has received:
-a-a-a 72 repository clones
-a-a-a 46 unique cloners
-a-a-a 283 page views
There was also a new peak on July 23, with 19 clones from 14 unique
cloners whn I released the latest patch.
For a project as specialized as a Perl transit filter for INN, these
numbers are honestly much higher than I expected.
There is, however, a slightly worrying discrepancy:
-a-a-a quite a few clones,
-a-a-a almost no feedback.
Apart from the invaluable testing and comments from Julien, The Doctor
and a few other people, I have very little idea whether the people who
cloned the repository:
-a-a-a installed it successfully;
-a-a-a only looked at the source;
-a-a-a found it unusable;
-a-a-a are running it without problems;
-a-a-a encountered false positives;
-a-a-a encountered false negatives;
-a-a-a or silently threw it into /dev/null.
So, before begging for feedback, here are some production results from
the RC2 series.
Production test 1: large backfill server ----------------------------------------
The first server is processing a large historical backfill containing
both text and binary traffic.
During one complete 24-hour period:
-a-a-a Articles passed to the Perl filter:-a-a-a-a 4,726,375
-a-a-a Average processing rate:-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a 54.70 articles/second
-a-a-a Cleanfeed average processing time:-a-a-a-a-a-a-a-a-a 8.67 ms/article
-a-a-a Lowest measured hourly average:-a-a-a-a-a-a-a-a-a-a-a-a-a 7.86 ms/article
-a-a-a Highest measured hourly average:-a-a-a-a-a-a-a-a-a-a-a-a 9.52 ms/article
Cleanfeed verdicts during the same period:
-a-a-a Rejected articles:-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a 547,158
-a-a-a Structured cleanfeed_event reject lines:-a-a 547,158
-a-a-a INN rejecting[perl] lines:-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a 547,158
The three numbers matched exactly.-a No duplicated reject events and no missing reject events were found.
There were also no occurrences of:
-a-a-a filter_art died
-a-a-a SERVER perl filtering disabled
-a-a-a cleanfeed-ng fatal
-a-a-a incomplete initialization
-a-a-a uninitialized-value errors
-a-a-a file descriptor exhaustion
-a-a-a CNFS errors
-a-a-a overview errors
-a-a-a history errors
The server was operating near its ingestion limit.-a The measured time
was divided approximately as follows:
-a-a-a Cleanfeed Perl filtering:-a-a-a-a-a-a 47.38%
-a-a-a INN history operations:-a-a-a-a-a-a-a-a 47.19%
-a-a-a Overview processing:-a-a-a-a-a-a-a-a-a-a-a-a 3.20%
-a-a-a Everything else:-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a 2.23%
Article storage itself accounted for only about 0.21% of the measured processing time, so the storage subsystem was not the bottleneck.
The backfill averaged about 4.7 million articles per day while applying
the complete filter.
Production test 2: normal text-only server ------------------------------------------
The second server has much lighter, ordinary transit traffic and is configured to reject binary payloads categorically.
During the measured day:
-a-a-a Calls to filter_art:-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a 7,424
-a-a-a Reject verdicts:-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a 1,184
-a-a-a Audit events:-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a 98
For ordinary text traffic:
-a-a-a Weighted average processing time:-a-a-a-a 2.79 ms/article
-a-a-a Median processing time:-a-a-a-a-a-a-a-a-a-a-a-a-a-a 2.77 ms/article
-a-a-a Approximate 95th percentile:-a-a-a-a-a-a-a-a-a 6.00 ms/article
A batch containing large binary articles took substantially longer,
typically about 80-100 ms per article, because the bodies had to be
parsed and classified.
Even during the worst ten-minute binary burst, Cleanfeed consumed only
about 5.4% of the interval and the INN server remained approximately
92.6% idle.
Across the complete period, the server was about 99.5% idle.
Again, no Cleanfeed crashes or automatic disabling of the Perl filter
were observed.
Problems found through production testing -----------------------------------------
Real-world testing has already uncovered and fixed several issues,
including:
-a-a-a correct multipart yEnc size validation;
-a-a-a restoration of the historical allexclude behaviour;
-a-a-a prevention of duplicate policy reject events;
-a-a-a correct rule identifiers for policy rejects;
-a-a-a protection against an undefined MID history queue;
-a-a-a explicit logging when the embedded Perl version is too old;
-a-a-a correct statistics generation immediately after a filter reload;
-a-a-a correct accounting for articles accepted through allexclude;
-a-a-a a dedicated binary.image reason code;
-a-a-a warnings when INN has dontrejectfiltered enabled;
-a-a-a documentation for CLEANFEED_CONFIG_DIR;
-a-a-a automatic checking and preparation of statistics and metrics paths.
INN's innreport support and documentation have also been updated to
recognize cleanfeed-ng events.
And now the shameless request
-----------------------------
Please send feedback.
Seriously. Even a one-line reply such as:
-a-a-a "Installed on INN 2.x / Perl 5.x / operating system X.
-a-a-a-a Running for N days.-a No problems found."
would be extremely useful.
I am especially interested in:
-a-a-a installation or migration problems;
-a-a-a INN and Perl versions being used;
-a-a-a text-only versus binary-capable servers;
-a-a-a false positives;
-a-a-a false negatives;
-a-a-a performance under real traffic;
-a-a-a confusing configuration options;
-a-a-a missing documentation;
-a-a-a unusual MIME or yEnc articles;
-a-a-a behaviour on systems other than Debian or Ubuntu;
-a-a-a successful installations with no issues at all.
A minimal report could simply be:
-a-a-a Operating system:
-a-a-a INN version:
-a-a-a Perl version:
-a-a-a cleanfeed-ng version:
-a-a-a Server type: text-only / binary / mixed
-a-a-a Time in production:
-a-a-a Result:
-a-a-a Problems or suspicious behaviour:
Please do not assume that silence means I know everything is working.
At the moment I have considerably more clone statistics than human
reports, which is a slightly unsettling way to maintain a transit
filter.
The RC2 series is now running successfully on real production servers.
If no further discrepancies appear during the next few days, I intend
to promote it to the first non-RC cleanfeed-ng release.
So please: if you cloned it, installed it, tested it, disliked it,
removed it, or merely discovered that one of my comments contains a
typo, tell me.
Positive feedback is useful.
Negative feedback is more useful.
Bug reports are extremely useful.
Even "it works here" is useful.
Silence is the only result from which I cannot learn anything.
Thanks in advance to everyone who has already tested it, and especially
to those who have taken the time to inspect logs and report actual results.
Sincerely,
--
Ivo Gandolfo
bofh.team
I haven't had time to consider it, but I do plan to package it for
FreeBSD ports once you hit a stable version.
LLM-assisted code generally does not hit those kinds of issues once you [cut]
Welcome to Open Source maintainership, it can be a lonely place :)
According to GitHub's traffic statistics for the last 14 days, it has received:
-a-a-a 72 repository clones
-a-a-a 46 unique cloners
-a-a-a 283 page views
For a project as specialized as a Perl transit filter for INN, these
numbers are honestly much higher than I expected.
Even during the worst ten-minute binary burst, Cleanfeed consumed only
about 5.4% of the interval and the INN server remained approximately
92.6% idle.
Across the complete period, the server was about 99.5% idle.
INN's innreport support and documentation have also been updated to
recognize cleanfeed-ng events.
It will indeed be shipped with the next 2.7.5 release.
cleanfeed-ng events [Top 50]:
Action-a-a-a-a-a-a-a Rule -aCount
audit-a-a-a-a-a-a-a-a policy.binary -a-a-a 81
reject-a-a-a-a-a-a-a binary.mime -a-a-a 81
audit-a-a-a-a-a-a-a-a binary.byte_profile -a-a-a-a 8
TOTAL: 3-a-a-a-a-a - -a-a 170
As for the naming, cleanfeed-ng is currently used.-a If the project eventually keeps the Cleanfeed name, I will naturally change it.
NB: Why NG in uppercase for Postfilter?-a (because of the uppercase P?)
It will indeed be shipped with the next 2.7.5 release.
That is excellent news.-a Thank you again for integrating cleanfeed-ng support into innreport and for including it in the next INN release.
cleanfeed-ng events [Top 50]:
Action-a-a-a-a-a-a-a Rule -aCount
audit-a-a-a-a-a-a-a-a policy.binary -a-a-a 81
reject-a-a-a-a-a-a-a binary.mime -a-a-a 81
audit-a-a-a-a-a-a-a-a binary.byte_profile -a-a-a-a 8
TOTAL: 3-a-a-a-a-a - -a-a 170
This output looks coherent.
The matching counts probably refer to the same 81 articles. I'm
intrested to the timing too, if you have on your log (verbose 4 or
greater).
The policy engine detected binary content and reported it in audit mode, while the historical MIME check independently rejected the misplaced
binary payload.-a The eight binary.byte_profile events are additional diagnostic signals for a subset of the processed articles.
This is also a useful reminder that the total represents cleanfeed-ng
events, not necessarily unique articles: one article may generate an
audit event and then a reject event from another detector.
It is exactly the kind of real-world reporting behaviour that I wanted innreport to make visible.
So there is no need to change the name used by innreport for INN 2.7.5.
Thank you again, Julien.-a Your testing, suggestions and INN integration
have been invaluable.
Hi Ivo,
Thanks for it!
Incidentally, would there also be something similar to do for
Postfilter-NG logs?
Incidentally, would there also be something similar to do for
Postfilter-NG logs?
As requested :-)
I used patch against INN2.8-main branch from Github. Feel free to move
the sections around as you like.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 54:42:54 |
| Calls: | 1,101 |
| Calls today: | 1 |
| Files: | 1,339 |
| Messages: | 276,383 |