GDPR is nearing the last 7 months of its 2 year transitional implementation before becoming part of the law in EU countries (inc., despite Brexit, the UK), affecting 0.5bn citizens together with US enterprises in under Privacy Shield (replacing Safe Harbour) as well as enterprises in EEA member countries and, outside of the EEA, countries whose privacy laws have been assessed for adequacy. Operators of lists such as MM are as much called-to-account as are the vast corporations behind popular social media that currently absolve themselves as being mere publishers.
Below is an initial impact assessment (vs. MM 2.1.14) of high priority impacts in bullet-point form for immediate consideration based on my current understanding. Where changes are required, they are required for continued use of MM in EU countries and in adequate countries (inc. EU-US Privacy Shield) where one or more list members is an identifiable EU citizen.
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.
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 the Nomail functionality extended made to operate both ways, i.e. restricting members from posting and restricting (suppresing) retrieval of a restricted member's details in a list of [subscribed] members.
GDPR places strong record-keeping obligations on data controllers. It implies that audit trails of consent be maintained. A per-subscriber report that shows how they were subscribed, keeping details of ip addresses of browser used if by web etc., log of all preference changes made etc. is a Should-Have requirement. A per-list-report perhaps showing less detail (e.g. method of subscription and time and date of consent) is a a Could-Have requirement.
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.
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, including all archived posts, without administrative intervention or incurring the delays inherent with moderation.
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.
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;
ii) to hide or disguise identities in automatically-added elements of list members' posts (e.g. in "From:");
iii) to hide or disguise identities inadvertently disclosed in list members' posts e.g. from quoting others etc. (My interpretation is that no risk arises to the operator of the list where member 2 quoting text of member 1 where member 1 intentionally included their contact details in a post, for example as a phone number or as "me -at- here"; meaning that it is sufficient to suppres/disguise headers and email addresses entered un-disguised by posters)
iv) either to disallow retrieval of list members to [even] subscribed members, or to hide/disguise addresses in retrieved lists;
v) to archive privately, requiring authentication and and keeping records (logging) of to whom information on the archive was 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.