Email distribution lists

[janno42]

The page could hold the student's email lists administration (lists.myhpi).

[janno42]

Using Mailman and providing basic UI on 1327 for standard users.

[tzwenn]

Greetings from a pandemic future! In 2021 some @Paula-Kli and @MerlindlH took up this long-lasting issue and wrote down some basic requirements of a lists2.myhpi.de (copied from Slack, will translate when I find time):

• Admin Leute direkt in die Datenbank/auf Mailingliste packen können (ohne Bestätigungs-Klick)
  • Infoschleuder/gremieninfos/jobs
  • leise ohne Infomail an Erstis
• alle können eine Mailingliste erstellen
  • Login-protected mit OIDC
  • Anmeldelinks ohne OIDC nutzbar
  • Listen limitierbar auf Emailadressen bestimmter Domains?
• Definieren ob non-member posten können
• bounces gehen an FSR Admins
• Spamfiltern von den Admins, damit nicht die Mailserver geblacklistet werden
  • FSRler können global Mail-Header-Filter setzen
  • alternativ outgoing SPAM-Filter
• Unterliegendes Core System soll noch supported werden
• Explizites Reply-TO
• Aktuelle Listenliste exportiert (für Admins / mail transports)
• wenn man sich irgendwo auf einer Liste angemeldet hat, bekommt man eine Mail mit zb einem Bestätigungslink
• wir wollen lieber über links und nicht über Mailheader uns anmelden

Furthermore, these optional requirements where defined:

• Möglichkeit für Moderation/Shadow-Ban wäre schön?
• Updatability / Hardfork-Vermeidung in der unterliegenden Mailinglisten Software -> muss maintainable sein, auch wenn wir selbst nicht mehr da sind
• Archive (Tendenz: Nein! Datensparsam!)

For backwards-compatibility with the existing solution, these points were made:

• alte Links supporten-> wer ist Listowner einer alten Liste? -> Links redirecten
• Inaktive Mailadressen werden Listenanlegern ausgegraut, aber nicht gelöscht
• alte Adminlinks: wenn du den anklickst kommst du zu OIDC und musst dich anmelden -> wirst zum Owner, kannst potenziell mehr Owner anlegen um das weiter zu geben
• jede Liste hat dank OIDC eine Person als Owner und die wird auch gespeichert -> du brauchst nicht mehr Links weitergeben sondern kannst andere Admins anlegen
• Szenario: ich bin owner. hab ausversehen jemand falschen auch zum owner gemacht -> kann jeden Owner wieder entfernen, gleiches Recht wie alle Owner
• Owner können sich selbst demoten, außer sie sind der letzte Owner

[tzwenn]

Comparing (legacy) eemaill and the current favorite software (Mailman3), we found that mailman's feature set is almost a superset of eemaill's features. So, with minor tweaks mailman can be configured to emulated the desired behavior.

This (incomplete table) lists found distinctions and diverging default settings.

Feature	eemaill	Mailman3 + Postorius
Who are members?	address-oriented	account-oriented
Who can create lists	everyone	mailman (super?) users
List creators verified	No	Yes
Lists identified by	random number	list_id / fqdn
Admin authorized by	link knowledge	login + correct role
Existing roles	member, non-member	owner, moderator, member, non-member
Admin must be member of list?	No (joined on creation)	No
Own membership status visible?	No (only toggle)	Yes
Un/Subscriptions by	web form (no account)	web form (with account) / emails
Action Confirmations by	Visiting a link	Sending an e-mail
Address verifications by	Is confirmation action	Visiting a link when creating user
Welcome/Goodbye-Messages	No	Configurable (mandatory goodbye<3.3.3)
Subject prefix	[listname] (hardcoded)	[Listname] (can be changed)
Templates (footer/welcome mail)	Same for all lists	per list (set by admins)
Does Moderation exist?	No	Yes (dedicated role)
Can admins deny joining	No	Yes
Member posting modes	allow, reject	allow, reject, discard, moderate
Non-Member posting modes	allow, reject	allow, reject, discard, moderate
Memberlist on admin view	One long list	paginated list
Re-request a pending action	both accepted	second fails
Default action time-out	7d (hardcoded)	3d (per list setting)
Available lists advertised	No	Yes (opt-out)
Your memberships listed	No	Yes (per role, paginated)
Own Membership on a list	Not disclosed (toggle)	Visible
Munging on already set Reply-To	No Munging (bug?)	Retains Reply-To, adds list address

[tzwenn]

I wrote up a small wrapper around mailmanclient (official REST client) to nudge mailman towards an eemaill-like experience: https://github.com/tzwenn/tenca

Here is a flask-based web UI: https://github.com/tzwenn/tenca-webui

Just fooling around to find out how stuff works and discover corner cases. Specifically written with Flask, to let you rethink design-decisions when porting to 1327.

Might be valuable to check out the django-wrapper around the REST API. Nope, it's not for our case. The actual models are defined in Postorius, wrapping mailman client.

[tzwenn]

See PR #770

[tzwenn]

What's your take on "superuser" list management? Should the lists be editable in the admin view?

One simple implementation is to list all management sites on django's admin page and add a mass-subscription form. How does the workflow of adding first semester students look to 1327 like right now?