Skip to main content

max / makenotwork

Record the imported-subscriber decision where the code called it open GoingsOn 04a882b4 asked three things. The one that gated the step-2 backfill is answered: no re-confirmation pass, imported addresses carry over sendable with marketing included, and the existing signups count as valid consent. It is a deliberate acceptance that nothing recorded what any given subscriber was told they were signing up for, taken against the cost of losing most of the list. No behaviour changes. SENDABLE_STATES already had 'imported' in it, which is the decision, so this is the comments and the test message catching up with it. The filed leaning was the opposite, so each site says what was chosen and why rather than leaving the next reader to reopen it as an oversight. `Imported` stays a distinct state. It is provenance now, not a quarantine: "we carried this over" is worth being able to say years later, and nothing gates on it. Also names the email provider in the privacy policy's Data Sharing list, which had the payment processor and the infrastructure providers but not the vendor that receives every subscriber's address and the message body. Worded like the payment-processor line, pointing at the Infrastructure page rather than hardcoding Postmark, so a provider change is one edit and not two. The other two questions (controller versus processor, per-list rate limits) gate nothing being written now and are split into their own tasks, as 04a882b4 asked.
Co-Authored-By
Claude Opus 5 (1M context) <noreply@anthropic.com>
Author: Max Johnson <me@maxj.phd> · 2026-08-07 02:54 UTC
Signed with PGP, not checked
Commit: 16f104fcad9de997007667f72a062b8f9fe73965
Parent: f660e08
3 files changed, +34 insertions, -13 deletions
@@ -1262,9 +1262,15 @@
1262 1262 /// `Imported` is its own state on purpose. Everything the step-2 backfill
1263 1263 /// carried over predates any consent record: calling it `Confirmed` would
1264 1264 /// manufacture evidence we do not have, and calling it `Pending` would assert a
1265 - /// double-opt-in is in flight when none is. Whether an imported subscriber may
1266 - /// be mailed is an open decision, and until it is answered the state says
1267 - /// exactly what is known and no more.
1265 + /// double-opt-in is in flight when none is. The state says exactly what is
1266 + /// known and no more.
1267 + ///
1268 + /// It is provenance, not a quarantine. Whether an imported subscriber may be
1269 + /// mailed was the open question, and it was answered yes (GoingsOn 04a882b4,
1270 + /// 2026-08-06): they are sendable, marketing included, and no re-confirmation
1271 + /// pass is coming. See `db::lists::SENDABLE_STATES` for the reasoning. The
1272 + /// state stays distinct because "we carried this over" is worth being able to
1273 + /// say years later, not because anything gates on it.
1268 1274 #[derive(Debug, Clone, Copy, PartialEq, Eq)]
1269 1275 pub enum SubscriptionState {
1270 1276 Pending,
@@ -1282,9 +1288,13 @@
1282 1288 Bounced => "bounced",
1283 1289 });
1284 1290
1285 - /// How the subscription was created. Recorded so a later re-confirmation pass
1286 - /// can tell a page subscribe from a bulk import, which the table this replaces
1287 - /// could not.
1291 + /// How the subscription was created, which the table this replaces could not
1292 + /// say.
1293 + ///
1294 + /// Recorded for a re-confirmation pass that was then decided against (GoingsOn
1295 + /// 04a882b4). It stays because "where did this address come from" is the first
1296 + /// question asked of a complaint, and answering it is worth one column whether
1297 + /// or not anything ever filters on it.
1288 1298 #[derive(Debug, Clone, Copy, PartialEq, Eq)]
1289 1299 pub enum SubscriptionSource {
1290 1300 LandingForm,
@@ -166,10 +166,18 @@
166 166 /// evidence of consent for those rows. Before the unified tables, everyone in
167 167 /// `mailing_list_subscribers` was mailed, and a refactor whose side effect is
168 168 /// that some subscribers silently stop receiving mail is worse than one that
169 - /// changes nothing. Whether imported subscribers should keep receiving
170 - /// marketing is the open decision in GoingsOn 04a882b4; answering it "no" is
171 - /// this constant minus one entry, and the test below is what makes that a
172 - /// deliberate edit rather than a drift.
169 + /// changes nothing.
170 + ///
171 + /// DECIDED 2026-08-06 (Max, GoingsOn 04a882b4): imported subscribers stay
172 + /// sendable, marketing included, and there is no re-confirmation pass. The
173 + /// existing signups are treated as valid consent. That is a deliberate
174 + /// acceptance of the fact that nothing recorded what any given subscriber was
175 + /// told they were signing up for, taken against the cost of losing most of the
176 + /// existing list. The filed leaning was the opposite, so it is written down
177 + /// here rather than left to read as an oversight.
178 + ///
179 + /// `Imported` therefore survives as provenance only: it says how the row got
180 + /// here, not whether the row may be mailed. Nothing gates on it.
173 181 const SENDABLE_STATES: &[&str] = &["confirmed", "imported"];
174 182
175 183 /// One deliverable recipient.
@@ -910,7 +918,7 @@
910 918 );
911 919 }
912 920
913 - /// Which states receive mail is a policy, and an open one. Changing this
921 + /// Which states receive mail is a policy, and a settled one. Changing this
914 922 /// set changes who gets email, so it should be an edit somebody made on
915 923 /// purpose rather than a line that moved during a refactor.
916 924 #[test]
@@ -918,8 +926,10 @@
918 926 assert_eq!(
919 927 SENDABLE_STATES,
920 928 &["confirmed", "imported"],
921 - "dropping 'imported' is the GoingsOn 04a882b4 decision; if that is \
922 - what happened, update this test with it"
929 + "'imported' is sendable by decision (GoingsOn 04a882b4, 2026-08-06): no \
930 + re-confirmation pass, the existing signups count as consent. Dropping it \
931 + silently stops mail for most of the list, so it needs a new decision and \
932 + not just a diff"
923 933 );
924 934 }
925 935
@@ -66,6 +66,7 @@
66 66 We share data only with:
67 67
68 68 - **Payment processor**: Payment processing (see [Infrastructure & Vendors](../tech/infrastructure.md) for current provider)
69 + - **Email provider**: Sending the mail you receive, which means your address and the message itself (see [Infrastructure & Vendors](../tech/infrastructure.md) for current provider)
69 70 - **Infrastructure providers**: Hosting, CDN (they process but don't access your data)
70 71 - **Legal authorities**: Only when legally required, and we'll notify you unless prohibited
71 72