Re: NNTP COMPRESS clients? RFC 8054

[Eric Wong <e@80x24.org>]

Julien ÉLIE <julien@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.