I've had a few reports of select users posts not getting out to all
servers, and experienced it myself in a group last night, running one
of my scripts that checks open servers, verified my suspicions, there
seems to be something in the cleanfead script inn servers not liking
(all?) ipv6 addresses.
I resent my message 3 times, and inn servers declined the takethis
every time, I removed only the ipv6 address in it, and the message
was taken by the peers who operate inn, I asked 2 of who complained
about this I know are not dummies to try it, same exact message,
resend, wait an hour then resend removing only ipv6 address, they
reported back to me this morning there ipv6-less messages can be seen
on the inn based servers.
all the ipv6 addresses -mine and the examples they sent me, were all different, nowhere near each other entirely. Now I know I've seen
some in the past, I've sent some in the past that have propogated,
perhaps its not all address es that trigger this.
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.
On 8 Apr 2025 11:32:21 +1000
noel <deletethis@invalid.lan> wrote:
I've had a few reports of select users posts not getting out to all
servers, and experienced it myself in a group last night, running one
of my scripts that checks open servers, verified my suspicions, there
seems to be something in the cleanfead script inn servers not liking
(all?) ipv6 addresses.
I resent my message 3 times, and inn servers declined the takethis
every time, I removed only the ipv6 address in it, and the message
was taken by the peers who operate inn, I asked 2 of who complained
about this I know are not dummies to try it, same exact message,
resend, wait an hour then resend removing only ipv6 address, they
reported back to me this morning there ipv6-less messages can be seen
on the inn based servers.
all the ipv6 addresses -mine and the examples they sent me, were all
different, nowhere near each other entirely. Now I know I've seen
some in the past, I've sent some in the past that have propogated,
perhaps its not all address es that trigger this.
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.
Some message id's might help?
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.
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.
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.
I've had a few reports of select users posts not getting out to all
servers, and experienced it myself in a group last night, running one of
my scripts that checks open servers, verified my suspicions, there seems
to be something in the cleanfead script inn servers not liking (all?)
ipv6 addresses.
if ($hdr{'Injection-Info'} =~ /^$hws*($Hostname)[ \t;]/) {
$state{injection_host} = "$1"
} elsif ($hdr{'X-Trace'} =~ /^$hws*($Hostname)$hws/) {
$state{injection_host} = "$1"
} else {
$state{injection_host} = first_path_host($hdr{Path});
};
“2a01:4f8:c0c:2f94::1”), the regex will not match it correctly.
Gabx
This is excerpted from cleanfeed
if ($hdr{'Injection-Info'} =~ /^$hws*($Hostname)[ \t;]/) {
$state{injection_host} = "$1"
} elsif ($hdr{'X-Trace'} =~ /^$hws*($Hostname)$hws/) {
$state{injection_host} = "$1"
} else {
$state{injection_host} = first_path_host($hdr{Path});
};
The pattern defined in $Hostname is designed to match traditional hosts
– composed of letters, numbers and dots – or IPv4 addresses.
However, IPv6 addresses, which include hexadecimal characters and the
“:” character, do not fall into this set.
So, if an Injection-Info header contains an IPv6 address (e.g. “2a01:4f8:c0c:2f94::1”), the regex will not match it correctly.
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.
1. What happens if the regex doesn't match?
2. How do you set a reverse DNS name for your IPv6 IP address with Hetzner? 3. What happens when the IPv6 address of your peer has a reverse DNS name?
Ray Banana wrote:
1. What happens if the regex doesn't match?
2. How do you set a reverse DNS name for your IPv6 IP address with
Hetzner?
3. What happens when the IPv6 address of your peer has a reverse DNS
name?
Risolto !
Ops! in italian !!!
Gabx
* 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
Do you mean the IPv6 protocol or just string representations of bare
IPv6 addresses contained somewhere in the article's headers?
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").
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").
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 33:08:37 |
| Calls: | 10,391 |
| Calls today: | 2 |
| Files: | 14,064 |
| Messages: | 6,417,128 |