From Newsgroup: news.admin.peering

Ran a test today because every time there's any given error on one, it's
the same given error on the other, so I was suspicious.

So I posted an article (see below) to uk.telecom.mobile for hours.
I tried over and over. For hours today.
Failed with a read error every time.
It connected. But never posted due to the read error.

Both tcpreset and paganini, as always, are lock step in the same errors.
Every time. Same badword errors. Same article too-long errors.
Same multigroup errors.

It's uncanny.
The article below fails every time on both.

So I post here, and it works.
Why?

This failed on both even to this newsgroup so it's not the newsgroup.
It's the content.

I rot13'd it to see if that would finally send the content. _________________________________________
Fhowrpg: Unf nalbar va HX rire orra cebira thvygl va pbheg sbe qbjaybnqvat zbivrf ol gbeeragf?
Arjftebhcf: hx.gryrpbz.zbovyr

Unf nalbar va HX rire orra cebira thvygl va pbheg sbe qbjaybnqvat
zbivrf ol gbeeragf? (tvira gurer unf arire orra n fhpprffshy HFN pnfr)
Ab HFN pnfr unf rire znqr vg gb n shyy gevny (jvgubhg orvat qvfzvffrq). uggcf://jjj.grpuqveg.pbz/2021/12/16/znyvoh-zrqvn-beqrerq-gb-cnl-jebatshyyl-npphfrq-cvengr-rira-zber-zbarl-nsgre-snvyvat-gb-novqr-pbhegf-qrpvfvba/

Rira va HX, vg ybbxf yvxr gur yrtny gebyy snezf ner nyfb fnapgvbarq uggcf://jjj.pbzchgvat.pb.hx/arjf/1822175/fbyvpvgbe-chefhvat-svyr-funeref-qvfpvcyvanel-gevohany?hgz_fbhepr=pbcvybg.pbz

Tvira va HFN gurer unf arire orra n fvatyr fhpprffshy pnfr bs n pbheg
svaqvat gur qrsraqnag thvygl bs qbjaybnqvat zbivrf ol ovg gbeerag pyvragf, jung nobhg va gur HX jurer gur ehyrf bs ynj zvtug or irel qvssrerag?

Va H.F. pbclevtug ynj, nzbhag znggref (bar cntr bs n obbx irefhf gur jubyr obbx) ohg bayl sbe snve hfr vzcyvpngvbaf ohg OvgGbeerag ynjfhvgf ner
qvssrerag va gung gurl qb abg vaibyir snve hfr ng nyy. Gurl vaibyir hanhgubevmrq qvfgevohgvba, juvpu vf n fgevpg-yvnovyvgl bssrafr.

HFN ovggbeerag ynjfhvgf sbphf ba pbclevtug gebyyf yvxr Znyvoh Zrqvn,
Ibygntr Cvpgherf, Fgevxr 3 Ubyqvatf naq bguref jub trarengr gur gbeeragf.

HX Pbclevtug, Qrfvtaf naq Cngragf Npg 1988 frrzf fvzvyne ba gur fhesnpr
ohg unir gurer nyfb orra ab xabja fhpprffshy cebfrphgvbaf gung znqr vg gb gevny?
--
Regards,
Rudy Wieser
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

Il 29/06/2026 10:47, R.Wieser ha scritto:

Ran a test today because every time there's any given error on one, it's
the same given error on the other, so I was suspicious.

So I posted an article (see below) to uk.telecom.mobile for hours.
I tried over and over. For hours today.
Failed with a read error every time.
It connected. But never posted due to the read error.

Both tcpreset and paganini, as always, are lock step in the same errors. Every time. Same badword errors. Same article too-long errors.
Same multigroup errors.

It's uncanny.
The article below fails every time on both.

So I post here, and it works.
Why?

This failed on both even to this newsgroup so it's not the newsgroup.
It's the content.

I rot13'd it to see if that would finally send the content.

Nope, we're two completely different newsmasters.

But we use the same Perl filter for our INN2 servers to prevent abuse.
From what I see, he's using the "basic" version available on GitHub
(I've heavily modified it on my server because it contained some bugs).

Anyway, to keep things short, this filter checks for a few things, such
as multiposting, prohibited words/phrases, and much more.

If you encounter multiple consecutive errors, the server itself will ban
you from posting further messages (for 10 minutes the first time, 24
hours for subsequent ones if you insist). So when you see "errors,"
don't persist, because you may be stubborn, but the server is more
stubborn than you are (especially if you see "Too many errors from...").
Wait at least 10 minutes and then try again, but not with the exact same message, otherwise you'll fall back into multiposting.

Sincerely
--
Ivo Gandolfo


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

Ivo Gandolfo

prohibited words/phrases

Thanks for the explanation because the behavior seems exactly the same.
The error was a read timeout.
That means, I think, you took too long on your side.

I don't know why, but it was NOT "multiple consequitive errors".
There were no errors.

Your server simply had no intention of posting the article.
And you don't have to.

But it was none of what you said it might be.

There was no "badword" error although that was the actual problem.


If I rot13 the failed articles, they work instantly every time.
That proves it wasn't "too many errors from".

It was simply keywords your filter doesn't like.
But it didn't report that it was keywords.

But that's what it was.
The previous post proves it beyond any doubt.

Anyway, its not a complaint.
It's just a question.

You've answered the question.
Which is you both use similar filters.

That's good enough for me.
--
Regards,
Rudy Wieser

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

Il 29/06/2026 12:44, R.Wieser ha scritto:

Ivo Gandolfo

prohibited words/phrases

Thanks for the explanation because the behavior seems exactly the same.
The error was a read timeout.
That means, I think, you took too long on your side.

In case of reject, my server save a local copy on the harddisk of the
rejected message (so I can investigate futher) but I don't find you
message (clear or rot13) into the rejected directory. So, you're sure
you send the message via my server?

Just told me when (HH:mm GTM or UTC and day) you try to send this
message and I can investigate.


Sincerely
--
Ivo Gandolfo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

Ivo Gandolfo

In case of reject, my server save a local copy on the harddisk of the rejected message (so I can investigate futher) but I don't find you
message (clear or rot13) into the rejected directory. So, you're sure
you send the message via my server?

Just told me when (HH:mm GTM or UTC and day) you try to send this
message and I can investigate.

It's so easy to reproduce that it's obvious what the problem is.
I just sent this message and it failed on the bofh server.
Date: Mon, 29 Jun 2026 20:51:51 +0100
Organization: To protect and to server
Message-ID: <111uicl$3k5uv$1@paganini.bofh.team>

It takes nothing whatsoever to reproduce reliably every single time.
Anyone can instantly reproduce it so it's no mystery.
It isn't the newsgroup because it happens with every newsgrou.

1. Send the original article (not the rot13 translation)
2. It will fail. Every time. My error is a read error.
3. What happens is the paganini server simply won't respond back.

Yet, rot13 the exact article, and it sends without any problem.
You can test it in seconds. So can anyone. It's trivial to reproduce.

Clearly, obviously, there is a keyword the server doesn't like.
Even though there is no error other than paganini never responds.

Exact same thing happens with tcpreset.
--
Regards,
Rudy Wieser

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

Il 29/06/2026 21:55, R.Wieser ha scritto:

Exact same thing happens with tcpreset.

Gotcha, I found you.

I see you're using a VPN and you're getting the error because I found
you in the logs. The error is 73, Ttoo many bytes from your IP in short
time." FYI the filter has over 110 errors.

So I don't know why your client doesn't display it but the error
returned is crystal clear.
Let me explain: the goal of us "open" servers is to prevent abuse as
much as possible, meaning people don't send massive amounts of posts (spamming, trolling, etc.) so there's a limit on the number of posts per day/number of bytes per single post/number of bytes of total messages sent.

As you may have already realized those who use VPNs, TOR, and similar anonymization and protection systems share IPs. By sharing IP for the
server, it's as if you were all the same person sending the posts and
thus the limits are triggered.

The error isn't showing up because of your client not because the server
isn't responding (and therefore throwing out a generic error). Your
client is probably so old that it doesn't support displaying errors. Try
using another client, or telnet if you encounter this issue again. next
time just wait few minutes (at least 10, and with some modification in
the text, same message trigger another rule: multipost) and try again.


Sincerely
--
Ivo Gandolfo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

Ivo Gandolfo

Exact same thing happens with tcpreset.

Gotcha, I found you.

I see you're using a VPN and you're getting the error because I found
you in the logs. The error is 73, Ttoo many bytes from your IP in short time." FYI the filter has over 110 errors.

I appreciate your honesty. And I appreciate your willingness to check.
Thank you for providing this free server avenue sans authentication.

If I disagree with your statements, it's only because I'm applying logic.

You explanation makes no sense when looked at logically. I almost certainly tried to send the same article multiple times, but it's only a few
paragraphs. And it failed on the first send. And it worked if I rot13'd it.

That means it's impossible for "too many bytes" to be a correct error.
(1) Send it (and it fails with a read error)
(2) Immediately rot13 and send it and it works.

It's impossible for *that* to be "too many bytes".
It's just not possible.

(see below where I see you explained it may have been due to conflation
with other users on the same VPN service but even then it can't be too many bytes because the subsequent rot13 proto article does not fail to send)

So I don't know why your client doesn't display it but the error
returned is crystal clear.

The error is that the server took too long to respond, where I have the response time set to a whoppingly high two minutes, so paganini didn't
respond within two minutes but only on the cleartext proto artice.

Paganini responded within seconds on the rot13 proto article.

Clearly there was NO RESPONSE from Paganini, but I can't prove that as
easily as I can prove that it's impossible for it to be too many bytes.

But it's highly likely that paganini did not respond within 2 minutes.

Let me explain: the goal of us "open" servers is to prevent abuse as
much as possible, meaning people don't send massive amounts of posts (spamming, trolling, etc.) so there's a limit on the number of posts per day/number of bytes per single post/number of bytes of total messages sent.

I appreciate your honesty and your largesse and your kindness and even that you're taking the time and energy to respond to this discussion because I
know that you don't have to.

I really do appreciate it. I'm not attacking you. The original question was merely that the two servers act similarly. The only reason we're talking
about what the specific error was is that you asked me to let you know.

If I show up as "too many bytes", you must be conflating me with every
person combined who uses that particular VPN server, as I rarely send an article using paganini. SOme4times I do. Maybe once a week. Maybe less. Sometimes more. But 'too many bytes' is not something I'm going to do.

(See below where you agreed in principle to what I just said above.)

As you may have already realized those who use VPNs, TOR, and similar anonymization and protection systems share IPs. By sharing IP for the server, it's as if you were all the same person sending the posts and
thus the limits are triggered.

See above. I agree with you. If you're lumping me with everyone using any
given VPN server, then I can easily believe a "too many bytes", but think
of the original issue. It can't be too many bytes. It's impossible.

Remember, I can send the proto article using VPN and it fails.
Then I rot13 it and send it again using the same VPN and it works.

It's impossible for *that* to be "too many bytes".

What would be interesting is if someone else uses your server to send the
exact same article. I suspect they will see the same thing I saw.

I think your badword filters are chewing on the proto article forever.
The best way to test it is for someone else to send the same article.

The error isn't showing up because of your client not because the server isn't responding (and therefore throwing out a generic error).

That might be true. I'm not disputing that. I'm disputing that the error
could possibly be "too many bytes" for the reasons I explained above.

It's too easy to prove that "too many bytes" is impossible to believe it.

Your
client is probably so old that it doesn't support displaying errors. Try using another client, or telnet if you encounter this issue again. next
time just wait few minutes (at least 10, and with some modification in
the text, same message trigger another rule: multipost) and try again.

Let's be clear I'm not complaining. In fact I'm thanking you. I appreciate
that you responded. I appreciate that you answered the main question. I appreciate that you asked for more information. And I appreciate that you explained what you think happened. You're being honest with me.

Don't get me wrong. I like that you're doing all that. But in the same
sense of honesty, I have to say that "too many bytes" is impossible given
how easy it is to prove it's the content of the proto article, not the
bytes.

It's easy to prove.

Can we ask someone else to send the original proto article?
If it fails, then they should send a rot13 of the original proto article.

I think that will prove what's happening.
Don't you?
--
Regards,
Rudy Wieser

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

Il 01/07/2026 03:05, R.Wieser ha scritto:

I think that will prove what's happening.
Don't you?

For the IP I found you I have see only this error, nothing else. The max amount of byte for single post it's 32K (header + body).

Se I think we have 2 type of problem:

- Latency
- Your client problem sometime (randomly)

For the latency/hiccup must be probably, you see from mtr we loose a lot
of packet and ping is very worst (I redacted the transit and destination
IP's):

My traceroute [v0.95]
paganini.bofh.team (94.23.43.182) -> IP-REDACTEDFINAL
2026-07-01T06:23:44+0000
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 10.17.12.18 0.0% 13 0.4 0.4 0.3 0.6 0.1
2. 10.17.35.42 0.0% 13 0.6 0.6 0.5 0.7 0.1
3. 10.73.240.2 0.0% 13 0.3 0.4 0.3 0.5 0.0
4. 172.20.8.40 0.0% 13 2.4 2.5 1.4 3.6 0.6
5. 172.20.8.64 0.0% 13 1.9 2.9 1.9 3.9 0.6
6. IP-REDACTED 0.0% 13 0.6 0.7 0.6 0.9 0.1
7. IP-REDACTED 0.0% 13 3.9 4.0 3.9 4.3 0.1
8. IP-REDACTED 0.0% 13 82.1 82.0 81.8 82.2 0.1
9. IP-REDACTED 0.0% 13 86.2 85.1 84.0 86.7 0.9
10. (waiting for reply)
11. IP-REDACTED 0.0% 13 151.0 150.9 150.7 151.1 0.1
12. IP-REDACTED 66.7% 13 246.4 247.0 246.4 248.0 0.7
13. IP-REDACTED 0.0% 13 251.1 251.1 251.0 251.3 0.1
14. IP-REDACTED 0.0% 13 244.6 244.5 244.5 244.7 0.0
15. IP-REDACTED 0.0% 13 245.2 245.1 245.1 245.3 0.1
16. IP-REDACTED 0.0% 13 247.7 247.6 247.6 247.7 0.0
17. IP-REDACTED 0.0% 13 248.4 248.4 248.3 248.5 0.1
18. IP-REDACTED 91.7% 13 3835. 4287. 3835. 4450. 210.9
19. IP-REDACTEDFINAL 14.3% 13 457.6 391.0 273.7 595.5 108.1


If the case it's not network hiccup I think it's your client, or both
same time.


Sincerely
--
Ivo Gandolfo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

On Wed, 01 Jul 2026 08:37:41 +0200, Ivo Gandolfo wrote:

13 248.4 248.4 248.3 248.5 0.1
18. IP-REDACTED 91.7% 13 3835. 4287. 3835. 4450. 210.9
19. IP-REDACTEDFINAL 14.3% 13 457.6 391.0 273.7 595.5 108.1

If the case it's not network hiccup I think it's your client, or both
same time.

Sincerely

not really wanting to derain the thread, but a FYI... transit carriers
often give icmp types low priority, this is easily done in Cisco with
class and policy maps, or if your mikrotik, firewall mangle and a queue
tree
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

noel

On Wed, 01 Jul 2026 08:37:41 +0200, Ivo Gandolfo wrote:

13 248.4 248.4 248.3 248.5 0.1
18. IP-REDACTED 91.7% 13 3835. 4287. 3835. 4450. 210.9
19. IP-REDACTEDFINAL 14.3% 13 457.6 391.0 273.7 595.5 108.1


If the case it's not network hiccup I think it's your client, or both
same time.


Sincerely

not really wanting to derain the thread, but a FYI... transit carriers
often give icmp types low priority, this is easily done in Cisco with
class and policy maps, or if your mikrotik, firewall mangle and a queue
tree

I don't disagree latency & client matter greatly but I also can't ignore
the elephant in the room which is sending the exact article twice is definitive.

Send the proto article at any time using any VPN, and it always fails.
Rot13 it moments later, and send it the same way, and it always works.

That is a badword filter mastication 99% of the time.

But I'm OK with dropping this as I never asked to debug.
I only asked why tcpreset does EXACTLY the same thing.
--
Regards,
Rudy Wieser

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

Il 01/07/2026 20:14, R.Wieser ha scritto:

I only asked why tcpreset does EXACTLY the same thing.

We use same perl filter on own INN2 server. And I think same setup (+/-)



Sincerely
--
Ivo Gandolfo
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

Ivo Gandolfo

I only asked why tcpreset does EXACTLY the same thing.

We use same perl filter on own INN2 server. And I think same setup (+/-)

Key question, does that perl filter do the badword filtering?
If so, that's the problem.

Whatever engine is doing the badword mastication is likely hanging up.

When it hangs up, it reports nothing.

When it reports nothing, the newsreader gives up after a few minutes wait.
--
Regards,
Rudy Wieser

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: news.admin.peering

On Wed, 01 Jul 2026 19:14:23 +0100, R.Wieser wrote:

That is a badword filter mastication 99% of the time.

But I'm OK with dropping this as I never asked to debug.
I only asked why tcpreset does EXACTLY the same thing.

You will probably find most operators using INN, run the exact, or much
the same filters, is it perfect? Of course not, anybody who tells you
they have an iron clad solution is full of sh#t, but newsmasters tend to
tweak the rules when they're proved... shall we say... over reaching.

I've saw a similar problem when our (non INN based) server propagated
articles with ipv6 addresses in them, one variant was ok, but more in
same article caused grief with INN servers filtering, so some peers
accepted, some didn't (don't know if it was just that address style or
all ipv6 in article).

Problem is the guy who was maintaining INN's cleanfeed (Steve Crook)
vanished from usenet, someone told me he went into politics so let his
usenet rot, no idea if anyone has taken it over, Russ or Julien are
probably better to answer that one.

Cheers
--- Synchronet 3.22a-Linux NewsLink 1.2