max / makenotwork

Say who holds a subscriber's address, and who decided the mail MNW and the creator are joint controllers for a project mailing list, ruled by Max 2026-08-27 on 80d4ee1e. We hold the addresses, run the send and hold the Postmark contract; the creator picks the audience and writes the mail. Neither decides both, which is the Article 26 test. Three surfaces say it, and they say the same thing: - A new legal page carries the arrangement Article 26 requires us to publish: who answers access, erasure, rectification and objection, and what happens when a creator closes an account with a list still on it. Erasure is set out in full because it is the request a vague arrangement leaves bouncing between two parties. - The privacy policy gains a Project Mailing Lists section. The email provider stays where it was in Data Sharing: a processor is not a joint controller and the two roles are kept in separate sentences. - The preferences page names both parties, and each row now says which creator sends that list. One contact answers for both of us, privacy@makenot.work, which Article 26 permits and which is the mechanism that stops the bouncing. No new address: that bucket is already GDPR access and deletion in the role-address list. SubscriptionRow gains owner_name, left-joined from the list's owner. It is None for a platform list, because receipts and security mail have no second controller to name.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Max Johnson <me@maxj.phd> · 2026-08-28 19:23 UTC

Signed with PGP, not checked

Commit: 8108bd2b1ffe48a86e16f68b0dca9fe07eab1b8e

Parent: d7cd21e

4 files changed, +148 insertions, -2 deletions

M server/src/db/lists.rs +10 -1

			@@ -303,6 +303,13 @@
303	303		/// send, but it carries no toggle: there is no opting out of a receipt.
304	304		pub required: bool,
305	305		pub state: String,
	306	+	/// The creator who owns the list, if one does.
	307	+	///
	308	+	/// `None` for a platform list (receipts, security, account mail), which
	309	+	/// nobody but us decides. Present for a project list, where the creator is
	310	+	/// the other joint controller of the address and the preferences page has
	311	+	/// to be able to say so. See `site-docs/public/legal/mailing-list-data-processing.md`.
	312	+	pub owner_name: Option<String>,
306	313		}
307	314
308	315		impl SubscriptionRow {
			@@ -328,9 +335,11 @@
328	335		WITH peer AS (
329	336		SELECT user_id, email FROM list_subscriptions WHERE id = $1
330	337		)
331		-	SELECT ls.id AS subscription_id, l.id AS list_id, l.title, l.required, ls.state
	338	+	SELECT ls.id AS subscription_id, l.id AS list_id, l.title, l.required, ls.state,
	339	+	COALESCE(NULLIF(u.display_name, ''), u.username) AS owner_name
332	340		FROM list_subscriptions ls
333	341		JOIN lists l ON l.id = ls.list_id
	342	+	LEFT JOIN users u ON u.id = l.owner_id
334	343		CROSS JOIN peer
335	344		WHERE (peer.user_id IS NOT NULL AND ls.user_id = peer.user_id)
336	345		OR (peer.email IS NOT NULL AND LOWER(ls.email) = LOWER(peer.email))

M server/templates/pages/email_preferences.html +21 -1

			@@ -20,7 +20,14 @@
20	20		<ul class="prefs-list">
21	21		{% for sub in subscriptions %}
22	22		<li class="prefs-row{% if sub.subscription_id == origin_subscription %} prefs-row--origin{% endif %}">
23		-	<span class="prefs-name">{{ sub.title }}</span>
	23	+	<span class="prefs-name">{{ sub.title }}
	24	+	{%- if let Some(owner) = sub.owner_name %}
	25	+	{# Who decided this mail, said on the row it belongs to. A
	26	+	project list has two parties behind it and the subscriber
	27	+	should not have to guess which one wrote to them. #}
	28	+	<span class="prefs-owner">Sent by {{ owner }}</span>
	29	+	{%- endif %}
	30	+	</span>
24	31		{% if sub.required %}
25	32		{# Receipts, security and account mail. Listed so the page is an
26	33		honest inventory of what we send, with no toggle, because there
			@@ -51,6 +58,19 @@
51	58		</form>
52	59		{% endif %}
53	60
	61	+	{# Article 26 attribution. A subscriber landing here from a creator's mail
	62	+	has two parties holding their address, and the page is where they find
	63	+	out who, and that one contact answers for both. #}
	64	+	<p class="prefs-attribution">
	65	+	Makenotwork holds your address and sends this mail. For a project list,
	66	+	the creator who owns it decides who is on it and what it says, which
	67	+	makes us joint controllers of your address. One contact answers for
	68	+	both of us: <a href="mailto:privacy@makenot.work">privacy@makenot.work</a>.
	69	+	The full arrangement is on the
	70	+	<a href="/docs/mailing-list-data-processing">Mailing List Data Processing</a>
	71	+	page.
	72	+	</p>
	73	+
54	74		<p><a href="/">Back to Makenotwork</a></p>
55	75		</div>
56	76		{% endblock %}

M server/site-docs/public/legal/privacy-policy.md +19

			@@ -72,6 +72,22 @@
72	72
73	73		We don't sell or share data for advertising.
74	74
	75	+	Everyone in that list is a processor: they act on our instructions and decide nothing about why your data is held. Project mailing lists are the one place where a second party decides something, and that is a different role. See below.
	76	+
	77	+	## Project Mailing Lists
	78	+
	79	+	When you subscribe to a project's mailing list, Makenotwork and the creator of that project are joint controllers of your address.
	80	+
	81	+	We hold the address, run the send, and hold the contract with the email provider. The creator decides who is on the list and what the mail says. Neither of us decides both, which is what joint controllership means.
	82	+
	83	+	This does not give you two places to write to. One contact answers everything: privacy@makenot.work. Access, correction and erasure requests about a mailing list are fulfilled by us and take effect on the creator's list at the same time.
	84	+
	85	+	The email provider is still a processor here, listed above. Sub-processor and joint controller are separate roles, and the provider holds neither of the decisions that make a controller.
	86	+
	87	+	The full arrangement, including what happens when a creator closes their account with a list still on it, is on the [Mailing List Data Processing](./mailing-list-data-processing.md) page.
	88	+
	89	+	Account mail is not covered by any of this. Receipts, security notices and password resets are ours alone, and no creator is involved in them.
	90	+
75	91		## Your Rights
76	92
77	93		### Access
			@@ -85,6 +101,8 @@
85	101		- Transaction records (legal requirement)
86	102		- If you have completed sales, purchased content remains accessible to buyers for 90 days after deletion, then is removed
87	103
	104	+	Subscribed to a mailing list without an account? Write to privacy@makenot.work. You do not need an account to have your address erased.
	105	+
88	106		### Portability
89	107		Export includes all content, metadata, and transaction history in standard formats.
90	108
			@@ -134,6 +152,7 @@
134	152
135	153		## See Also
136	154
	155	+	- [Mailing List Data Processing](./mailing-list-data-processing.md): Joint controllership for project mailing lists
137	156		- [Terms of Service](./terms-of-service.md): Full legal terms
138	157		- [Acceptable Use Policy](./acceptable-use.md): Content rules
139	158		- [What We Guarantee](../about/guarantees.md): Data export and portability commitments

A server/site-docs/public/legal/mailing-list-data-processing.md +98

		@@ -1,0 +1,98 @@
1	+	# Mailing List Data Processing
2	+
3	+	Who is responsible for a subscriber's address when a creator sends mail through a project mailing list, and who answers when that subscriber asks a question about it.
4	+
5	+	This page covers project mailing lists specifically. For everything else we hold, see the [Privacy Policy](./privacy-policy.md).
6	+
7	+	---
8	+
9	+	## The Arrangement
10	+
11	+	Makenotwork and the creator are joint controllers for a project mailing list.
12	+
13	+	Neither party alone decides both what the list is for and how it runs:
14	+
15	+	- Makenotwork holds the addresses, runs the send, and holds the contract with the email provider.
16	+	- The creator decides who is on the list and what the mail says.
17	+
18	+	Joint controllership is what that split is called under GDPR Article 26. It is not a processor relationship, and describing it as one would put the whole responsibility on Makenotwork for decisions the creator makes.
19	+
20	+	This page is the summary of the arrangement that Article 26 requires us to make available to subscribers.
21	+
22	+	---
23	+
24	+	## One Contact for Every Request
25	+
26	+	privacy@makenot.work.
27	+
28	+	Article 26 lets joint controllers name a single point of contact, and we have. A subscriber can also go to either party directly, and a request that arrives anywhere gets handled rather than forwarded with instructions to try the other one.
29	+
30	+	Nothing below changes that. The division of responsibility is between us and the creator; a subscriber never has to work out which of us to write to.
31	+
32	+	---
33	+
34	+	## Who Answers What
35	+
36	+	\| Request \| Answered by \| Why \|
37	+	\|---------\|-------------\|-----\|
38	+	\| Access: what do you hold about me \| Makenotwork \| We hold the record. The creator sees a subscriber list, not our database. \|
39	+	\| Erasure: delete my address \| Makenotwork, and it takes effect on the creator's list \| See below. \|
40	+	\| Rectification: fix my address \| Makenotwork \| Same record. \|
41	+	\| Objection: stop sending me this \| Either. The unsubscribe link is the fastest route. \| Unsubscribing is instant and needs no request at all. \|
42	+	\| Why did I get this mail \| The creator, with our help if they need it \| The creator decided the content and the audience. \|
43	+
44	+	### Erasure, in detail
45	+
46	+	Erasure is the request that a badly drawn arrangement leaves bouncing between two parties, so it is settled here.
47	+
48	+	An erasure request against a project mailing list is fulfilled by Makenotwork, and it removes the address from the creator's list at the same time. The creator does not hold a separate copy to be chased down: the subscriber list a creator sees is a view of our database, and an erased address is gone from both at once.
49	+
50	+	A creator can export their subscriber list, which puts a copy of the addresses on their own machine. That copy is outside our database, so it is worth being exact about it. Under this arrangement a creator must not keep mailing an address after it is erased, and must delete the exported copy when we tell them an erasure covers it. A subscriber does not have to chase that: write to privacy@makenot.work and we pass it on and follow it up.
51	+
52	+	Suppression records are the exception, and they are the same exception the Privacy Policy already makes. If an address bounced or filed a complaint, we keep a one-way record that we must not mail it again. Erasing that record would mean mailing the address again the next time somebody adds it.
53	+
54	+	---
55	+
56	+	## When a Creator Leaves
57	+
58	+	A creator can close their account with a list still on it. Three things happen, in this order:
59	+
60	+	1. Sending stops immediately. A closed account cannot trigger a broadcast or an automatic notification.
61	+	2. The list stops being a list. Subscribers are not transferred anywhere, not sold, and not folded into another creator's audience.
62	+	3. The addresses are deleted within 30 days, on the same schedule as the rest of the account's data.
63	+
64	+	Makenotwork remains reachable at privacy@makenot.work for the whole of that window and afterwards. A departing creator does not take the obligation with them, which is the point of naming a single contact.
65	+
66	+	Subscribers are not notified that a list has closed. The mail simply stops.
67	+
68	+	---
69	+
70	+	## The Email Provider
71	+
72	+	Our email provider is a processor, not a joint controller. It sends what we tell it to send and holds the addresses to do it. The current provider is named in [Infrastructure & Vendors](../tech/infrastructure.md).
73	+
74	+	Processor and joint controller are different roles and this page keeps them apart. The creator decides who gets mailed; the provider decides nothing.
75	+
76	+	---
77	+
78	+	## What This Does Not Cover
79	+
80	+	- Account mail. Receipts, security notices and password resets are ours alone. No creator is involved and no creator can stop them. See [Email you cannot turn off](../guide/email-you-cannot-turn-off.md).
81	+	- Lists a creator runs somewhere else. If a creator exports their subscribers and mails them from another service, that service and that creator are the parties involved, and we are not one of them.
82	+
83	+	---
84	+
85	+	## Contact
86	+
87	+	Subscriber requests about a project mailing list: privacy@makenot.work
88	+
89	+	Formal data protection inquiries: dpo@makenot.work
90	+
91	+	---
92	+
93	+	## See Also
94	+
95	+	- [Privacy Policy](./privacy-policy.md): Everything else we hold
96	+	- [Mailing Lists](../guide/mailing-lists.md): How lists work for creators
97	+	- [Email you cannot turn off](../guide/email-you-cannot-turn-off.md): The mail that ignores every preference
98	+	- [Terms of Service](./terms-of-service.md): Full legal terms