From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id B9D281F463; Sat, 21 Sep 2019 20:35:25 +0000 (UTC) Date: Sat, 21 Sep 2019 20:35:25 +0000 From: Eric Wong To: Julien =?utf-8?B?w4lMSUU=?= Cc: inn-workers@lists.isc.org, meta@public-inbox.org Subject: Re: NNTP COMPRESS clients? RFC 8054 Message-ID: <20190921203525.GA26535@dcvr> References: <20190706044942.wmgjwbfy4vwntogu@dcvr> <20190715012546.ljpdiavoesixy3sp@whir> <4a50b21c-bd8f-a0c6-a1f9-3ff23a30328b@trigofacile.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4a50b21c-bd8f-a0c6-a1f9-3ff23a30328b@trigofacile.com> List-Id: Julien ÉLIE wrote: > Hi Eric, > > > git clone https://80x24.org/perl-libnet.git > > (nntp-compress branch) (oops, totally forgot about this for a few months :x) > 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.