Re: inn, cleanfeed and ipv6

* nb wrote:

>
>
On Tue, 8 Apr 2025, Nigel Reed wrote:

I know I was shown inns cleanfeed few years back and its totally
different from dnews's cleanfeed which dnews has had internally since
day dot, I'm suspecting since the peers who accepted it, do binaries,
it might be in the detection of such messages, and is misclassifying
ipv6 addresses - but as not an inn operator, I'm only guessing.

JFTR: Cleanfeed is not part of INN (INN provides just provides a Perl hook
      that can be used for filtering incoming articles.
      Cleanfeed is just one implementation of such a filter and is available
      on the internet in several versions. In addition, Cleanfeed can be heavily
      customized outside the distributed executable, so the behaviour of the
      filter may vary considerably between servers claiming to use Cleanfeed.   

>

>
Some message id's might help?
>

>
Since I don't peer with you, and unless you peer with a few binary
services, you wont have any log records so MID's will be useless.
This is just a heads up and anyone who knows inn's cleanfeed rule
detection, might see where it happens, I've advised my people and users to
not use ipv6 addresses in usenet.

Do you mean the IPv6 protocol or just string representations of bare
IPv6 addresses contained somewhere in the article's headers?

If it's the former, example headers might be useful for testing this
issue locally.

I have a test script I wrote years ago to disprove to others our server
was eating their posts, it comes in handy for uses like this too, it
checks 10 or 11 open servers and  only ours had the article, as I'm away
for 10 days I can really run it and paste the outputs.

Does your script print the error code and reason it receives from the
misbehaving servers in response to the TAKETHIS command? That might indeed
shed some light on this issue.

The peers that reject your articles should have entries in their logs
showing the reason for rejecting the article (e.g. "439 Misplaced binary").

--
Пу́тін — хуйло́
https://www.eternal-september.org