NNTP COMPRESS clients? RFC 8054
Eric Wong
e at 80x24.org
Sat Sep 21 20:35:25 UTC 2019
Julien ÉLIE <julien at trigofacile.com> wrote:
> Hi Eric,
>
> > git clone https://80x24.org/perl-libnet.git
> > (nntp-compress branch)
(oops, totally forgot about this for a few months :x)
<snip>
> https://80x24.org/perl-libnet.git/commit/?h=nntp-compress&id=0ab5c363a69702e586b7ef06be3ebff3e78656b7
>
> + croak("NNTP connection already compressed ($comp)") if $comp;
> + croak("$alg not supported (only 'DEFLATE')") if $alg ne 'DEFLATE';
>
> Note that these messages have different response codes: 502 for the first
> one, 503 for the last one.
I'm not sure if faking NNTP server error codes in a client is
appropriate if the failure is entirely on the client side(*).
Fwiw, Net::NNTP currently dies if ->starttls is repeated,
so I'm following that behavior.
(*) LWP fakes HTTP error codes, and it annoyed me to no end
back in the day...
> and
> + $err == Z_OK or die "Inflate->new failed: $err\n";
> and
> + $err == Z_OK or die "Deflate->new failed: $err\n";
>
> It should be a 403 response code, and then the connections goes on
> uncompressed (same remark found in your patch against public-inbox-nntpd).
Also, I most perl code (including core) just croaks/dies to
raise an exception on allocation failure. Bugs or ABI
mismatches in Compress::Raw::Zlib leading to failure are
probably to rare to do anything with besides croak/die.
> > My plan is to keep public-inbox-nntpd read-only; since (AFAIK)
> > NNTP lacks good spam filtering
>
> Isn't Cleanfeed good enough for your needs?
> http://www.mixmin.net/cleanfeed/
>
> I am also aware of a use of SpamAssassin with INN. Maybe it would better
> fit your expectations?
*shrug* I also wouldn't know how NNTP <-> mail would work for a
decentralized workflow where everybody is expected to To/Cc one
another and merely agree on some mailing list addresses as a
logging/archival channel (this is how Linux kernel and git
development works, at least).
I wouldn't want NNTP servers to become open relays, either...
I still think email has the best chance of being a federated
identity provider for Free software development.
More information about the inn-workers
mailing list