Building a Privacy-First Newsletter

Building a newsletter is a fairly common activity these days, with many creators, writers and thinkers making part of their living via subscribers willing to give small amounts of money out per year or month to get exclusive access. Beyond the paid subscriptions, there's an increasing demand for free, or for fun, newsletters to cut through algorithmic noise. People enjoy hearing directly from other people they trust or enjoy, seeking advice, insight, humor and information, which is why the interest in newsletters and podcasts has grown.

As there is a growing audience for these formats, you would think there would also be a wide array of newsletter platforms with different offerings. In Fall 2020 I started my newsletter Probably Private, on the intersection of privacy and data science and went on a quest that took until Spring 2023 -- to create a privacy-first newsletter.

Why?

A newsletter about privacy just seems like it should have privacy built in. For years now, I've been finding ways to manage my own online data, backups and even how I interact with social media -- finding a balance that fits my own political, cultural, social and individual idea of privacy. I think every human should have the ability to do this, and it should be fundamentally built into services that are offered, so that choice and consent are transparent and easily implemented in software, data and computing architectures.

It also made sense to offer readers of my newsletter the privacy they deserve. I didn't want them to be automatically tracked, in any way. I thought they should be able to open a newsletter, read to their hearts delight, click on links, save things for later, or immediately send to Spam should they see fit -- all without anyone knowing about it. Little did I know, this would turn out to be much more difficult than I originally thought.

My Journey Begins...

Earlier kjam: Let's figure out what service to use by looking at what's popular and has some privacy policies I can read and ways to toggle what data is tracked! Off we go...

Revue

I first started out on Revue in Fall 2020, as several folks recommended it to me and it was then a leader in newsletters, particularly those with supplemental paid options. It wasn't my intention to create a paid newsletter, but I thought if I ever did more newsletters, maybe one day there would be a paid one.

I signed up, wrote the first installment, toggled off all possible tracking settings I could find and sent it out to my, then, about 50 subscribers. Later that day, I got an email from a reader mentioning that the links they received were tracked (!). I took a look at the fine-tuned settings and found that there was literally no way for me to turn off click tracking on links. After some back and forth conversations on social media and via email with other privacy folks, I was recommended to migrate to Buttondown, a friendly and privacy-aware alternative. I picked up my content and migrated over...

Buttondown

I happily logged into Buttondown to see that I could turn off all tracking. I tested that no links were tracked. I tested that I couldn't see the views or opens, and I turned off emails to alert me of who was signing up or unsubscribing. Seemed that I was set!

I wrote several newsletters and received no more privacy feedback, just content feedback. Finally, I thought, it's solved!

But as I wanted to update and change the newsletter by setting up my DNS and integrated Buttondown into my own website. First, I would need to start paying for Buttondown. This was to help cover the costs of the mail service provider and hosting. Sounded very reasonable, but I wanted to look further into these services, just to confirm they were also privacy-respecting, considering I'd now be helping pay for them.

I first emailed the friendly Buttondown admin to confirm the services used. Then, I dug into the fine print from those services to figure out if tracking was somehow built in and what the options were for turning it off.

This sent me down a new rabbit hole: namely, the sad state of privacy in email.

The Plot Thickens: How does Email work?

Many newsletter providers use a third-party mail service provider. This is the service that actually takes the email template, turns it into an email-friendly format and mails it out to your subscribers. Sometimes you are using a service that does both, but many times, particularly for newsletter "front-ends" or management services, the actual sending will be outsourced to a service that your newsletter provider uses to send bulk email.

Let's walk through what normally then happens when this occurs.

With normal SMTP, like when sending an email from your Gmail account, you are usually sending email from one large email provider to another, or within the same organization. Therefore, the SMTP services that need to send several messages back and forth to confirm sender, recipient and message text will either all occur within an internal service (like Google Mail or Outlook) or will happen between those services. This usually means your mail lands in the other person's Inbox and not in the Spam folder. For a deeper dive into how SMTP works, check out Wikipedia.

However, when you are sending bulk email, like with a newsletter, you need to send many emails at once. This is usually not allowed by the large email providers unless you are emailing a large internal group (i.e. a large work list). These providers turned off bulk sending long ago to fight spammers, and that created the surge of bulk email providers you can see today. These providers help send bulk mail for newsletters, brands for direct marketing and advertisers and they can range from easy-to-use setups where you edit the email directly in the browser and hit send, to more complex, like using your cloud provider as an bulk email service, often requiring programmatic access.

Mail Service Providers & Privacy

You can see how these services are ranked and compared on sites like "Email Analytics" along with the delightful other articles that these types of sites feature, like how to track your employees and customers via email and other surveillance software.

In fact, the deeper I dove into trying to find a privacy-first bulk email service, with some help from networking friends, the more I realized there wasn't going to be many without tracking. Investigating mailgun, which Buttondown uses, dropped me into their Privacy Policies and Terms of service which uncovered data storage and retention periods that I did not expect. For example, below is an excerpt from their documentation:

Mailgun keeps track of every event that happens to every message (both inbound and outbound) and stores this data for at least 30 days for paid accounts and 2 days for free accounts.

Note that all of this would technically be stored centrally in the Buttondown admin account, meaning I couldn't verify access or retention in any way. Even if I chose to build my own newsletter to integrate directly with mailgun, there was no way to turn this off.

At the time, they also had fairly expansive privacy policies, that documented the data shared with their subprocessors (services and companies they use to process person-related data). They have since made their privacy policy more legible, but you can still see the wide array of data collected, processed and likely stored in the provider's account in their current DPA:

The types of Personal Data to be processed: The personal data submitted, the extent of which is determined and controlled by the Controller in its sole discretion, includes name, email, telephone numbers, IP address and other personal data included in the contact lists and message content.

Much of this is likely collected to fulfill customer demands (i.e. customers want tracking) or as a way to combat spammers. But there was no way to turn it off and there also wasn't a way to use the service for a given period of time or trial period, prove I am not a spammer and turn it off later. As a machine learning engineer and data scientist, I could think of a million other ways to detect spam activity than storing this history, but that's besides the point.

I was truly in uncharted territory, so I started asking networking friends how I could find a service that didn't actively track opens, reads and unanswered bounces. That's when I learned about SMTP relays...

What is SMTP Relay?

An SMTP relay is a way to handoff SMTP requests between SMTP servers. This happens when the sender and receiver aren't in the same email domain. Much like your internet requests are handed off across the internet, an SMTP relay service hands of incoming and outgoing mail until it reaches the appropriate recipient mail server. You can read more about SMTP relay from Ionos's explanatory article.

What I needed was a privacy-first SMTP relay, that allowed me to turn off tracking for the email as it got forwarded out to the emails. I put a cry out for help on Twitter (reminder: this was early 2022, pre-Emerald Emperor).

original tweet

My request was:

• Data hosted in Europe
• Data minimization built in (i.e. I can hold the emails, the service just does the send)
• Reasonable prices for small amount of emails per month (<$30/mo if possible)
• Clear privacy policy and data processing agreement

Unfortunately, no one could point me in a reasonable direction. I was getting desperate, and it seemed like I might need to host my own email somehow...

Just Host Your Own Email (said no one who has done it)

Of course there are many guides and articles on how to set up your own SMTP server. What none of these guides will tell you is what a pain maintenance is, and how you basically will be immediately marked as Spam until you prove yourself otherwise.

Since the last time I set up a mail server (circa 2010), email has changed a bit. The deeper I dove into hosting my own server, the more it seemed impossible to manage due to the way that reputation management is performed. Due to the rising sophistication of phishing and spam communication, email in those past 10 years became a true battleground between those parties. The victim of these battles are people or companies who would like to run their own email and who aren't going to send a lot of mail.

When you set up a mail service and start sending mail, your reputation will be tracked on mail services in relation to your domain and your servers' IP addresses. When you first start or are unknown, this is very difficult, because you are assumed to be Spam. You have to then spend time and energy to increase your reputation -- all that on top of also having to maintain the mail server and whatever it was you were trying to do with it in the first place -- run a business, write a newsletter, etc.

It wasn't intentional, but this basically pushed out a lot of self-hosted email providers or hobby projects. In another way, it's a bit terrifying for privacy, since most email is sent unencrypted and who knows what types of machine learning or other data "insights" are being run on/by most email providers (since now everyone has one or more email providers)... but I digress.

Self-hosting seemed like a lot of work and I also didn't really want to have one more thing to manage, I just wanted to run a privacy-first newsletter.

Back to Privacy-First Email Providers

I ended up routing completely back to email providers. Namely because my needs right now as a relatively small newsletter don't actually exceed normal email sending rates. This sets a newsletter growth constraint, but one I was willing to accept for now in order to provide more privacy for my readers.

I took a look at Proton Mail, who has a great track record with regard to privacy, but they actually don't provide programmatic interfaces very easily, and certainly not for sending many emails at once.

Finally, I found Runbox, a privacy- and security-first email provider based in Norway. Added bonus, they also prioritize green computing! It gave me warm fuzzies and I immediately signed up for a trial account. I tested using the API programmatically and didn't run into any problems, so I bought an enterprise account and migrated over probablyprivate.com.

My troubles were over... or were they?

Populating a Bare-Bones Newsletter

Now that I was ready to build the actual newsletter, it meant starting over. Since I wasn't able to find a newsletter provider with a privacy-first SMTP relay, it meant finding my own way to programatically send emails. At first, I had set up my newsletter to use Ghost.js, which I love as an editor, but it uses Node and the self-hosted and open-source version only allows integration with mailgun, which meant it wasn't something I was going to easily change, fork or fix.

I went in search of a python-based self-hosted newsletter.

django-newsletter

I found django-newsletter, with many users and fairly good support. As I started to work with it, however, I realized it was going to be a nightmare for the type of newsletter I imagined, namely because the code base was quite complex, it didn't support the latest Django and Python versions at that time. It seemed like administrative overkill for such a small newsletter, administered by just one person.

I would, however, recommend django-newsletter for folks that:

• have multiple newsletters and want to manage them in one interface
• have multiple authors/editors who need to work on posts together
• are already using Django as a web framework and might be able to contribute back upgrades and updates

Being that it didn't fit for me, I...

Gave up and wrote my own

Yes, I know. It's definitely "the hard way", but I wrote my Django models and administrative interfaces, along with the ability to manage posts myself. It took me about a day or two, as I already have experience using Django and also sending emails programatically.

I don't really recommend this route, as it's probably overkill if you aren't already someone familiar with the basics of backend and/or frontend web development. It's also a pain to maintain. Should you actually know of an easy-to-use open-source newsletter manager that is not Node.js based (yes, I have issues), please reach out!

To build out the site, I got pretty far myself with a Canva-based design that I edited, here's the original, and some help with CSS via Upwork. But I had reached my limit of being able to make the templates and front-end consistent.

Email templating & minimal loading calls

If you didn't already know, email templating is a complex problem. There are so many different email clients, different screen sizes, different ways to display email, one can get easily lost. This is why professionals often use a framework like MJML (from Mailjet) to ensure that the email works on as many readers as possible with some semblance of consistency.

I also had a requirement that I wanted the site to not load so many things. Not only does this hurt performance, it also leaks (more) information in the browsing and networking calls. I wanted to minimize calls per page load, which meant having a super lean CSS that could, at times, even be loaded on the page itself. To make this work was beyond my front-end depth, so I called a dear friend and colleague.

Žan has helped me on several engagements where I needed someone who does front-end work. Along with being a delightful human, he also knows back-end web development, making it easy to pass over my half-finished pile and scream help. (Thanks Žan!) He also figured out how to convert my poor HTML files into an actual email template using MJML and is, I think, only minorly scarred from the experience. ;)

Announcing the new Probably Private!

In the end, I now have a fairly no-frills but definitely privacy-first newsletter! It was a journey I did not expect, but I learned even more about privacy and the internet, which I'll be writing more about in an upcoming series diving into the technical details of internet privacy!

If this post was interesting to you, or if you want to learn more about privacy in data science, please subscribe!

I'm also always welcome to feedback (via mail: info /at probablyprivate / dot / com).