tl;dr I don't think this is worth thinking about until we get a request from users who actually are threatened with liability for their Mailman installations.

Suggestions from where we can obtain funding to do this stuff? The harder parts are non-trivial.

noskcaJ leahciM writes:

1. The term consent has a specific meaning within GDPR (i.e. one of a number of lawful bases on which personal data may be processed). The subscribe web flow and subscribe/confirm email exchanges should be edited to use the term "consent" rather than "confirm" where appropriate to make that consent explicit.

I don't think this is something we should do blindly. If a list owner or site affected by GDPR wants to consult a lawyer and contribute that knowledge, I think we should follow up with changes, but I can see issues that would involves potential liability for our users if we use a word that has legal meaning and our procedures aren't up to the standard.

2. The term restriction has a specific meaning within GDPR (in general it means suspending any use (processing) or disclosure of personal data. Nomail could usefully be renamed as "Restriction" and

No, it can't. I see no good reason to include both nomail and privacy protection in a single option. Nomail is very useful without being tied to privacy options.

Nomail  functionality  extended  made  to  operate  both  ways, i.e.
restricting  members  from  posting

This is not what nomail does. That's moderation. Nomail prevents a subscriber from receiving posts, and is primarily intended as a user option, not an admin option.

and restricting (suppresing) retrieval of a restricted member's
details in a list of [subscribed] members.

There's a separate user option for this, IIRC, as well as a global option restricting availability of lists to the list and site admins. I don't see a strong argument for combining these options, or combining retrieval suppression with moderation.

3. GDPR places strong record-keeping obligations on data controllers. It implies that audit trails of consent be maintained.

Patches welcome. I don't think this is reasonable to ask of most sites at present, and the security implications of "audit" (identifying and authenticating users and crypto signing said "trails" etc) seem daunting.

4. GDPR provides that the right of erasure (that has coloquially become known as the "right to be forgotten) be provided upon request. In addition ot unsubscribing from a list, a list subscriber Should be able to initiate automated erasure from the site archive of all posts of and from a given subscriber.

This is simply not feasible to guarantee in Mailman 3, since we deliberately separated the archiver and sites (even individual lists) may supply their own. This also raises hairy issues about authentication.

There seems no reason  for  erasure  to  be  moderated.   Using  the
existing  password  authentication  or a confirm string, subscribers
could be  provided  with  the  ability  themselves  to  erase  their
personal  details  from  the  site,

This is not necessarily under control of Mailman.

including all archived posts, without administrative
intervention or incurring the delays inherent with moderation.

I don't think the existing authentication features are sufficiently reliable for this. Specifically, I would imagine that the rights embodied in GDPR inhere in *human persons*, not in email mailboxes. Yet in fact in all current authentication done by Mailman only mailboxes are identified, not persons.

GDPR doesn't provide for selective erasure, for example in the  case
of  a  non-factual,  inflamatory  or libelous post that a subscriber
wishes to have removed; all-or-nothing will suffice  for  compliance
with  GDPR.   Erasure  is  required  to  uphold  a  right  so  is  a
Should-Have requirement.

5. GDPR enshrines 7 principles and 8, legally-enforceable, rights. While "Privacy by Design and by Default" is not actually one of the principles it is a mandatory approach. The default for list settings should be to

   i) to close lists, making posting to lists restricted to members;

This is something we should do anyway, since restricting posting to members is generally a regrettable but necessary spam-control practice.

 ii)  to hide or disguise identities in automatically-added elements
      of list members' posts (e.g.  in "From:");

That's not reasonable. The list does not "own" or add From (or To or Cc, for that matter); the author does. In the general case, identity can be concealed by the poster if they want to by acquiring an additional mailbox. Some effort to prevent address harvesting from archives by spammers is reasonable, but hiding identity is another matter entirely.

iii)  to hide or disguise identities inadvertently disclosed in list
      members'   posts   e.g.    from   quoting   others  etc.

That's not reasonable. As above, we don't own the text, the poster does. Again, discouraging harvesting is reasonable, but hiding identities in text is not a reasonable requirement.

 iv)  either  to  disallow  retrieval  of  list  members  to  [even]
      subscribed members, or to hide/disguise addresses in retrieved
      lists;

Options are present. Changing defaults if necessary is not a big deal.

  v)  to archive privately, requiring authentication

I don't like this (in my use cases, public archives are usually desirable), but it might be reasonable as a default.

      and and keeping records (logging) of to whom information
      on the archive was disclosed;

This is unreasonable. Of course HTTP accesses are logged, and with access limited to authenticated subscribers the relevant list user is known, but in general there is no *identification*. Furthermore, this is invading the *reader's* privacy in any case where personal information intended to be closely held is not disclosed.

 vi)  on closed lists (the default), disallow the posting of HTML by
      which  otherwise  members might seek to obtain the identity of
      others through inclusion of web bugs/beacons.

We already have an option to refuse HTML. But users don't like that. Accurately restricting what can be posted sounds difficult to me, but patches welcome.

Steve