What implications do GDPR have on Mailman, and how to requiring members to accept registration
In regards to GDPR*) I am wondering if there is any ways I can require my current and future subscribers, members and list administrators to accept registration.
I am also concerned that new lists are created with a subscription policy "Confirm" as default, rather than at least "Moderate", which can cause people to be subscribed by others against there will. Also, regardless of this setting, administrators can subscribe people without their knowledge.
Away from Gravatar, mentioned in another post, what implications do GDPR have on Mailman?
*) http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1510481733260&uri=CELEX%3A32016R0679
Henrik Rasmussen
On 5/17/18 3:35 AM, Henrik Rasmussen wrote:
I am also concerned that new lists are created with a subscription policy "Confirm" as default, rather than at least "Moderate", which can cause people to be subscribed by others against there will.
I'm confused. Confirm sends a confirmation request to the subscribed address which must be acted upon by the user before she is added to the list. Moderate just means approval by an owner/moderator which, it seems to me is more susceptible to a 3rd party subscribe succeeding - i.e., subscription requires membership in some organization. A subscribes B who is a member of the organization but doesn't want to be on the list. The moderator verifies that B is an organization member and approves the subscription.
Granted, it may be possible for some brain-dead vacation responder to confirm a subscription request, but that's a separate issue.
Also, regardless of this setting, administrators can subscribe people without their knowledge.
Granted that this can be abused, but not allowing admins to directly add members will probably create more problems than it solves.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
I'm confused. Confirm sends a confirmation request to the subscribed address which must be acted upon by the user before she is added to the list. Moderate just means approval by an owner/moderator
Oh sorry, you're right, I mixed up those two.
which, it seems to me is more susceptible to a 3rd party subscribe succeeding - i.e., subscription requires membership in some organization. A subscribes B who is a member of the organization but doesn't want to be on the list. The moderator verifies that B is an organization member and approves the subscription.
What I meant was, that the list admin may be able to set the list to Open or Moderate, making it possible to subscribe others, and I was told by our GDPR folks that we have to make the subscribers re-confirm, so I was just trying to figure out a way to do it. I don't know very much about GDPR yet.
Granted that this can be abused, but not allowing admins to directly add members will probably create more problems than it solves.
I agree, I wouldn't remove it either, but I just have to be concerned about the possibility that someone may have been subscribed against their will.
Is there a way to resend a confirmation request to either those who haven't been requested to confirm or alternately to all subscribers?
Henrik Rasmussen
On 05/18/2018 03:50 AM, Henrik Rasmussen wrote:
What I meant was, that the list admin may be able to set the list to Open or Moderate, making it possible to subscribe others, and I was told by our GDPR folks that we have to make the subscribers re-confirm, so I was just trying to figure out a way to do it. I don't know very much about GDPR yet.
Setting the policy to Confirm or Confirm, then Moderate will do that as long as admins don't use the mass subscribe feature without a confirmed request from the user.
Is there a way to resend a confirmation request to either those who haven't been requested to confirm or alternately to all subscribers?
Manually. I.e.post a request to the list with a deadline for response and remove those that don't respond. Or, post to the list that everyone will need to resubscribe and then remove everyone.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thank you Mark.
I browsed the Django Admin web interface (https://[list server]/admin) (which is actually partly in Danish for some reason) and found that in "Accounts" > "E-mail address" it is possible to uncheck "Verified", but it doesn't seem to do anything. When that user logs in again, the "Verified" check box is re-checked, but no confirmation request mail was sent to the user.
Also in the Django Admin web interface under Authorization -> Users it is possible to add "account | email confirmation | Can change email confirmation" to the user's rights, but I am not sure what those do. I suppose it is to add the right to do the above mentioned.
If removing the "Verified" does not make the user reconfirm, what is it for then (just trying to understand)?
Thank you Mark.
I browsed the Django Admin web interface (https://[list server]/admin) (which is actually partly in Danish for some reason) and found that in "Accounts" > "E-mail address" it is possible to uncheck "Verified", but it doesn't seem to do anything. When that user logs in again, the "Verified" check box is re-checked, but no confirmation request mail was sent to the user.
Also in the Django Admin web interface under Authorization -> Users it is possible to add "account | email confirmation | Can change email confirmation" to the user's rights, but I am not sure what those do. I suppose it is to add the right to do the above mentioned.
If removing the "Verified" does not make the user reconfirm, what is it for then (just trying to understand)? That is part of allauth. My guess is that the confirmation is overridden by Mailman's setting for
On 05/22/2018 02:12 PM, Henrik Rasmussen wrote: the email before allauth get's a chance to reconfirm it.
The second thing is relating to the django admin. If you give people staff privileges (in the admin under Users), you can theoretically fine-grain control what they are allowed to change using the admin.
Henrik Rasmussen writes:
What I meant was, that the list admin may be able to set the list to Open or Moderate, making it possible to subscribe others, and I was told by our GDPR folks that we have to make the subscribers re-confirm, so I was just trying to figure out a way to do it. I don't know very much about GDPR yet.
I think Mark misinterpreted "re-confirm". I assume you mean forcing the *existing* subscribers to perform some action to confirm that they still want to be subscribers. This is not currently a feature of Mailman 2 or Mailman 3. We only can require confirmation at initial subscription, except by something like unsubscribing or no-mail'ing everybody as Mark suggested.
I agree, I wouldn't remove [the mass subscription feature] either, but I just have to be concerned about the possibility that someone may have been subscribed against their will.
I think you would hear about that. Re-confirmation in light of new rights for subscribers and responsibilities for providers seems reasonable to me, but I think it's reasonable to assume list admins are not malevolent.
In light of GDPR, we may need to develop ways to enforce site policy about subscription confirmation and ability of users to unsubscribe themselves at will.
Is there a way to resend a confirmation request to either those who haven't been requested to confirm or alternately to all subscribers?
It seems to me that what most organizations are doing is not to force reconfirmation, but rather informing their users of
- their GDPR rights
- what PII is present in the relevant databases
- how to terminate the relationship if desired
In the case of Mailman, you might also want to
- require SSL to access the website
- advise the users to change their passwords if you had been allowing access via HTTP or sending password reminders
For stock Mailman 2, this is not a big deal (I don't think any of the subscriber configuration information is PII except display name and address), but for Mailman 3 I believe there's some profile information in HyperKitty that might be considered PII, and Mailman 3 will be easier to extend using plugins etc to potentially incorporate even more.
Mark Sapiro writes:
Or, post to the list that everyone will need to resubscribe and then remove everyone.
Note that this means that people who resubscribe late will miss mail. That may or may not be a big deal.
Steve
participants (4)
-
Henrik Rasmussen -
Mark Sapiro -
Simon Hanna -
Stephen J. Turnbull