Project

General

Profile

Feature #16886

Stop spam on our public mailing lists

Added by sajolida about 1 month ago. Updated 14 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Infrastructure
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:

Description

I can't believe that some of this is hard to block on the server side. For example:

I tried myself to block some of this from configuration of the mailing list and failed by lack of knowledge. I'm happy to try again if I'm provided more instructions but this won't be a systemic solution for most of this spam.

I think that improving our infrastructure to prevent spam, and the associated trust and security issues, should be part of the responsibilities of our sysadmins.

Activate moderation on all our public mailing lists

Until we can fight the root cause, it might help to activate moderation on all our public mailing lists. It could then be the responsibility of different core teams to moderate different mailing lists:

  • tails-dev & tails-testers: Foundations team
  • tails-ux: UX team
  • tails-l10n: ???
  • tails-project: Help desk

:sajolida: is watching this.

History

#1 Updated by sajolida about 1 month ago

  • Target version set to Hole in the Roof

#2 Updated by sajolida about 1 month ago

  • Description updated (diff)

#3 Updated by sajolida about 1 month ago

  • Status changed from New to Confirmed

Today I put generic_nonmember_action to Hold on tails-ux. Let's see how it goes in fighting spa

I also realized that the Help desk mission includes "Administer and moderate our general purpose public mailing lists", so if we decide to moderate non-members messages on them the moderation requests will end up in their mailbox. We could either:

  • Keep it this way, which could mean acknowledging that Help desk should moderate all this spam.
  • Remove this line from their responsibility. It seems to me like a remaining from when Help desk was a general purpose Front desk (or even the "Welcome and Annoying Nitpicker") but it's today quite far away from their mission.

I'll tell them about this and that meanwhile they can ignore the moderation work on tails-ux.

#4 Updated by sajolida 22 days ago

  • Description updated (diff)

#5 Updated by intrigeri 15 days ago

  • Description updated (diff)

sajolida wrote:

I can't believe that some of this is hard to block on the server side. […]
I tried myself to block some of this from configuration of the mailing list and failed by lack of knowledge. I'm happy to try again if I'm provided more instructions […]

Let's try (again?) to get help from our sysadmins. They'll need a raw copy of the spam message(s) you want to block (a link to the archive is not enough) and the administration password for the corresponding list.

I think that improving our infrastructure to prevent spam, and the associated trust and security issues, should be part of the responsibilities of our sysadmins.

Given your repeated usage of "our infrastructure" here, I'd like to clarify something for other readers: we don't host cleartext mailing lists on our infrastructure. So the best Tails sysadmins can do is:

  • help list admins configure their mailing lists' anti-spam settings ← this sounds doable
  • encourage A/I to improve their anti-spam ← provided enough samples of spam that makes it through, this sounds doable
  • migrate our lists to another ISP ← I don't see our sysadmin team taking responsibility for such a project this year
  • take over our cleartext list hosting, do a better job than A/I wrt. anti-spam, and do a not-too-worse job than A/I at everything else ← same, unrealistic this year (and FWIW, it would make very little sense to me)

#6 Updated by sajolida 14 days ago

Let's try setting generic_nonmember_action to Hold for now.

I've used "our infrastructure" on purpose because for me, the fact that some pieces of our infrastructure are outsourced doesn't move it outside of their realm of responsibility of our sysadmins. Outsourcing has pros and cons: it's less work and cost when everything goes fine but it might become less comfortable to fix when things go bad. Here, these are bits of infrastructure that have become hostile (insecure and unwelcoming) and I think it's our sysadmins' responsibility to solve this whether or not their are root on the machine. Of course, as always, putting each problem in the perspective of the availability of our workers, the cost and benefit, etc.

For example, in your writing "They'll need" and "provided": if sysadmins need spam samples I think it's their responsibility to gather them, subscribing to the affected mailing lists for some time if needed.

Also available in: Atom PDF