| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 27 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 40:26:58 |
| Calls: | 631 |
| Calls today: | 2 |
| Files: | 1,187 |
| D/L today: |
24 files (29,813K bytes) |
| Messages: | 174,392 |
Onion: peannyjkqwqfynd24p6dszvtchkq7hfkwymi5by5y332wmosy5dwfaqd.onion
On Thu, 3 Apr 2025 07:11:42 +0200
Gabx <info@tcpreset.invalid> wrote:
Onion: peannyjkqwqfynd24p6dszvtchkq7hfkwymi5by5y332wmosy5dwfaqd.onion
Hmm, I didn't know about this. Being on an anonymous network leaves it
well open to abuse. Do you limit public posting to people you know and
have approved accounts?
ipv6: 2a01:4f8:c0c:2f94::1
On 03.04.2025 07:11 Uhr Gabx wrote:
ipv6: 2a01:4f8:c0c:2f94::1
Connection refused from my system. Please investigate.
Nigel Reed wrote:
On Thu, 3 Apr 2025 07:11:42 +0200No,
Gabx <info@tcpreset.invalid> wrote:
Onion: peannyjkqwqfynd24p6dszvtchkq7hfkwymi5by5y332wmosy5dwfaqd.onion
Hmm, I didn't know about this. Being on an anonymous network leaves it
well open to abuse. Do you limit public posting to people you know and
have approved accounts?
our server intentionally operates as an open-access system: we do not require registration or explicitly limit posting privileges only to
known users or pre-approved accounts.
However, to prevent abuse and spam effectively, we've implemented strong automated anti-abuse measures, including Cleanfeed, SpamAssassin, and a Hashcash-based proof-of-work mechanism.
A Hashcash token generation mechanism is designed to prevent automated
spam by requiring users to perform computational work (proof-of-work).
The higher the bits value, the greater the effort needed, significantly deterring spammers.
It should work now!
Nigel Reed wrote:
On Thu, 3 Apr 2025 07:11:42 +0200No,
Gabx <info@tcpreset.invalid> wrote:
Onion: peannyjkqwqfynd24p6dszvtchkq7hfkwymi5by5y332wmosy5dwfaqd.onion
Hmm, I didn't know about this. Being on an anonymous network leaves it
well open to abuse. Do you limit public posting to people you know and
have approved accounts?
our server intentionally operates as an open-access system: we do not require registration or explicitly limit posting privileges only to
known users or pre-approved accounts.
However, to prevent abuse and spam effectively, we've implemented strong automated anti-abuse measures, including Cleanfeed, SpamAssassin, and a Hashcash-based proof-of-work mechanism.
A Hashcash token generation mechanism is designed to prevent automated
spam by requiring users to perform computational work (proof-of-work).
The higher the bits value, the greater the effort needed, significantly deterring spammers.
We are currently evaluating PyClean https://github.com/crooks/PyClean/tree/master and NoCeM to further
enhance these protections.
Additionally, we will soon implement secure NNTP connections via port
563, supporting TLS v1.2 and v1.3 with mandatory authentication.
Additionally, we actively monitor and moderate public postings to
maintain high standards without sacrificing user privacy or openness.
I understand your suggestion about requiring, for example, email-based authentication and registration as a means of identifying potential
abusers.
However, relying solely on email addresses doesn't necessarily guarantee
a clear or reliable identification of malicious users.
Email addresses are trivially easy for abusers to obtain anonymously or through disposable services, and thus cannot unequivocally distinguish legitimate users from abusers.
Consequently, our technical anti-abuse strategies and active moderation policies offer more practical, robust, and privacy-respecting protection against spam and malicious activities than email-based identification
alone.
Moreover, I believe there's a fundamental misunderstanding regarding the Onion network and spam: spam activities typically rely heavily on
clearnet due to the ease of automated bulk distribution and openness to
mass harvesting techniques.
Conversely, the Onion network, by design, introduces *latency* and complexityrCoconditions fundamentally incompatible with large-scale spam operations.
Far from facilitating abuse, Tor's nature often discourages spam and
mass attacks by making automated, high-volume transmissions costly and impractical.
I'd be happy to further discuss alternative strategies or enhancements
to address your concerns effectively.
I apologize for my lengthy explanations; however, i anticipated concerns being raised about the onion address and wanted to address them clearly.
Best regards
Gabx
Given that you provide access via TOR and anonymous remailers using a mail2news gateway, how and where would you implement your "hashcash
proof of work", when there is no direct interaction between the users
and your server infrastructure?
I would suggest that you take a closer look at hashcash implementations, because they can slightly differ from the original. Maybe also useful for you, if you check how Omnimix does it.
https://www.danner-net.de/omom/tutorremailhashcash.htm
Stefan Claas wrote:
I would suggest that you take a closer look at hashcash implementations, because they can slightly differ from the original. Maybe also useful for you, if you check how Omnimix does it.
https://www.danner-net.de/omom/tutorremailhashcash.htm
BTW. I guess you changed something. My article was quoted at the beginning and shows now only the last paragraph. It also seems that you changed something
with the Newsgroups: header, so that it must appears first.
Before these changes, everything worked perfectly.
* Gabx wrote:
Nigel Reed wrote:
On Thu, 3 Apr 2025 07:11:42 +0200No,
Gabx <info@tcpreset.invalid> wrote:
Onion:
peannyjkqwqfynd24p6dszvtchkq7hfkwymi5by5y332wmosy5dwfaqd.onion
Hmm, I didn't know about this. Being on an anonymous network leaves
it well open to abuse. Do you limit public posting to people you
know and have approved accounts?
our server intentionally operates as an open-access system: we do not
require registration or explicitly limit posting privileges only to
known users or pre-approved accounts.
However, to prevent abuse and spam effectively, we've implemented
strong automated anti-abuse measures, including Cleanfeed,
SpamAssassin, and a Hashcash-based proof-of-work mechanism.
A Hashcash token generation mechanism is designed to prevent
automated spam by requiring users to perform computational work
(proof-of-work). The higher the bits value, the greater the effort
needed, significantly deterring spammers.
Given that you provide access via TOR and anonymous remailers using a mail2news gateway, how and where would you implement your "hashcash
proof of work", when there is no direct interaction between the users
and your server infrastructure?
On 03.04.2025 07:11 Uhr Gabx wrote:
ipv6: 2a01:4f8:c0c:2f94::1
Connection refused from my system. Please investigate.
Marco Moock wrote:
On 03.04.2025 07:11 Uhr Gabx wrote:
ipv6: 2a01:4f8:c0c:2f94::1
Connection refused from my system. Please investigate.
????
gabriel1@victor:~$ ping6 2a01:4f8:c0c:2f94::1
PING 2a01:4f8:c0c:2f94::1(2a01:4f8:c0c:2f94::1) 56 data bytes
64 bytes from 2a01:4f8:c0c:2f94::1: icmp_seq=1 ttl=53 time=5.16 ms
64 bytes from 2a01:4f8:c0c:2f94::1: icmp_seq=2 ttl=53 time=2.85 ms
64 bytes from 2a01:4f8:c0c:2f94::1: icmp_seq=3 ttl=53 time=3.20 ms
And there is a typo for the Web Interface. It sends as MIME UTF-8 7bit, instead of 8bit.
Es schrieb einmal Stefan Claas:
And there is a typo for the Web Interface. It sends as MIME UTF-8 7bit, instead of 8bit.
7bit or 8bit depends on whether 8-bit characters appear in the body or not. The charset is irrelevant.
Alfred Peters wrote:
Es schrieb einmal Stefan Claas:
And there is a typo for the Web Interface. It sends as MIME UTF-8 7bit,
instead of 8bit.
7bit or 8bit depends on whether 8-bit characters appear in the body or not. >> The charset is irrelevant.
In the Web Interface it displays UTF-8 characters properly but then the Usenet posting does not display the charaters correctly in a News Reader.
Es schrieb einmal Stefan Claas:
Alfred Peters wrote:
Es schrieb einmal Stefan Claas:
And there is a typo for the Web Interface. It sends as MIME UTF-8 7bit, instead of 8bit.
7bit or 8bit depends on whether 8-bit characters appear in the body or not.
The charset is irrelevant.
In the Web Interface it displays UTF-8 characters properly but then the Usenet posting does not display the charaters correctly in a News Reader.
Message-ID?
Es schrieb einmal Stefan Claas:
In the Web Interface it displays UTF-8 characters properly but then the
Usenet posting does not display the charaters correctly in a News Reader.
<vsoprv$pbto$1@news.tcpreset.net>