Brian Carpenter writes:
If you mean if they don't have a Django user account, they can't unsubscribe?
The Django user account is more or less a proxy for the underlying Mailman User object, which is what we're concerned with here because that's where the data you want deleted is stored.
I think that is true if they are wanting to unsubscribe via the web interface. But sending an email to listname-unsubscribe@listdomain allows them to unsubscribe without such user authentication. Isn't that correct?
They don't need a Django password or social auth, but they'll still have to do the OTK dance. I don't see a reason to distinguish the methods of authentication. They all reduce to the OTK dance to prove ownership of a mailbox, then optional *delegation* to a password in Django or social auth via Gmail etc.
I understand that your users don't understand this or care to. Thing is, some of *our* users care about the features that this architecture enables.
My intent in our changes is to give the list owner and member exactly what they expect: when they explicitly remove a subscription and/or user profile, that they expect their data to be totally removed.
That's fine, and you're welcome to implement that in Affinity. In fact, as I understand it, you have already done so. *I'm* not saying *nobody* should implement that.
I'm saying that *Mailman* shouldn't, because a lot of subscribers to Mailman lists won't like it. The whole point of Mailman 3 is to cater to users who want powerful control over their subscriptions. For Mailman (Postorius), prompting the user "If you delete this subscription, you will have no subscriptions linked to this account. Would you like to delete the account as well?" (as I have proposed three times now) is the right way to go. This can be implemented via email with a second OTK.
I can easily picture a scenario where an older list has a number of list members move to on to other things in life
And I can picture a scenario where they take a summer break and reactivate a decade later. I would be *pissed off* if my data got deleted in that scenario. (Yes, I've done that in the five year variant, if not the full decade.)
and even abandon their email accounts totally.
Which is a totally different scenario. I deny your "imperative" in the former case; inactivity from the point of view of a list owner is (usually) not abandonment. I question it in the latter, because "abandon" is an inference drawn from lack of activity or bounces, either of which could be inadvertant (respectively the "summer break" scenario, and separation from an employer).
In those cases it is imperative that those list addresses are removed either via bounce processing or list owner intervention and that no legacy data on such members remain.
But how do you propose to identify "legacy data"? In Mailman 3, members are *people*, not addresses. Do you really want it to be the case that if Albert signs up with albert@example.com, and later gets fired by example.com, then all his subscriptions get bounce-cancelled, and his User profile gets irreversibly trashed? Or some large email provider hosting lots of posters decides to suddenly implement some spam protection that causes a ton of bounces (as DMARC p=reject did in 2014) and hundreds of users have their accounts trashed?
You just can't know without asking Albert what he wants done in his case and you can be quite sure you're doing the wrong thing in the DMARC-like case. In either case, resubscribing is a click per list if his data is retained (and Albert needs an OTK confirmation of another address). It's an annoying session of duplicating his configuration (including passwords and social auth links) if not, and probably some months of discovering that a configuration that built up over years wasn't accurately reproduced for some lists.
List owners, of course, can do what they want with their lists. If they want to add automation for their subscribers that simplify the lives of people who have simple needs, that's not something Mailman can, should, or will try to stop. That's *why* I support efforts like Affinity, Empathy, and Harmony.
Steve