From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 374B41382C5 for ; Fri, 22 May 2020 19:20:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4B891E08EB; Fri, 22 May 2020 19:20:38 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0E8D6E087C for ; Fri, 22 May 2020 19:20:38 +0000 (UTC) Date: Sat, 23 May 2020 07:20:22 +1200 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Anti-spam for goose Message-ID: <20200523072022.5eb5e4e1@katipo2.lan> In-Reply-To: <496f9d713dc1d890d8af717c77429faac20912e1.camel@gentoo.org> References: <496f9d713dc1d890d8af717c77429faac20912e1.camel@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/KZMVk.6kaVrPbprzpMSoX0d"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Archives-Salt: 90768aa9-7dd2-421e-a9ca-ca6c17a53073 X-Archives-Hash: 7f4360a2fd92c46aa31e9e6d1c9b823e --Sig_/KZMVk.6kaVrPbprzpMSoX0d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 21 May 2020 10:47:07 +0200 Micha=C5=82 G=C3=B3rny wrote: > Other ideas > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Do you have any other ideas on how we could resolve this? And a question I'd like to revisit, because nobody responded to it: - What are the incentives a would-be spammer has to spam this service. Services that see spam *typically* have a definable objective. *Typically* it revolves around the ability to submit /arbitrary text/, which allows them to hawk something, and this becomes a profit motive. If we implement data validation so that there's no way for them to profit off what they spam, seems likely they'll be less motivated to develop the necessary circumvention tools. ( as in, we shouldn't accept arbitrary CAT/PN pairs as being valid until something can confirm those pairs exist in reality ) There may be people trying to jack the data up, but ... it seems a less worthy target. So it seems the largest risk isn't so much "spam", but "denial of service", or "data pollution". Of course, we should still mitigate, but /how/ we mitigate seems to pivot around this somewhat. --Sig_/KZMVk.6kaVrPbprzpMSoX0d Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEgdrME8Lrmai3DXYJda6SGagVg7UFAl7IJfcACgkQda6SGagV g7XINxAAvX5SKqy+2sjNOQeU8nhgbZH3+cFL1JYX6pd83xOpsmCNE9HaTI4j83Xs d+et7BlRZwcNVZyK9RuOurwDVUnJ5YAi6gqG2ZKloHRJQqdtNlMoPdL+kBXQRfcp iJdHJpERVvSAO589z0DybSZtdkb9grmppvXr9fpHUXZ+hr3jmuDqrJQ7w9JVfetH DmNNbmN46FbgyFD7rQvO2ioHFoB9QcLJY7mTM7v5Py6NrU8i6JTPOUH9c2kbN99X ijEYTeW5mbvydK23EgRXgcAxXmoeOrCg3oBtruwzEDycmL/rnskyUhk6lW2zsJGE /yPrkeW7TR+jPSCYbRjyea0FWie0GfOxz/mvvIAdt4dCEA50DDSD7DsAU067+bUO 2kARtMwvDKtrcrrESUXyTFnzk7M+hiv0Vb4Vb6bM2k4XZouusOeko7DjGWQEVlgm WXea5TG4I7NrbN5EMNLD1+afTNeocphkVUe4lALqrY46hO4HBBwtNbl23AM4Kel8 2cSFa80JPuemsrelr+zloc3vla8wYi1mAgupNXMR0MvK7zNeouzA+iGXtl0ZiLyr N4i+sbo04TA6IUh7qGfi+C1tSvKcb0XyZPlLXq6k7Kn5c5Dl2LvPZJjMVJUD/b29 guW70kYLE5A7AGJa1sLvnc5KuAtnRQmkMBEKV3DqWlxZs8uN/lU= =v+Z+ -----END PGP SIGNATURE----- --Sig_/KZMVk.6kaVrPbprzpMSoX0d--