My newsletter is your email client, too | Andros Fenollosa

Skip to content

My newsletter has no subscription form, no double opt-in with a magic link, and it doesn't live in a third-party service with its tracking pixel. And yet, any reader can subscribe, receive the bulletin and unsubscribe whenever they want. The trick is the same one I already used with comments: email as the user interface.

This article is the natural continuation of My comment box is your email client. There I turned a mailbox into a comment system; today we'll turn it into a newsletter. My goal isn't to teach you code, but to give you a design guide: the pieces, the decisions and their whys.

Subscription

The instruction a reader sees on my site fits in one sentence:

Send an email to newsletter@andros.dev with the subject SUBSCRIBE and you're in.

No text boxes, no captchas, no confirmation pages. A mailto: with the subject already filled in, and their email client does the rest.

Behind the scenes, the pieces will already sound familiar:

A filter at the email provider moves everything arriving at newsletter@ from the inbox to the website/newsletter folder. My personal inbox stays clean and the folder works as a work queue.

A scheduled task reads that folder over IMAP at whatever interval you like: this isn't a chat.

Each email becomes a new subscriber in the database and is then deleted from the mailbox.

It also has a hidden advantage: I don't need to send a confirmation email, nor keep a "pending confirmation" state in the database. The sign-up email is itself the confirmation. An elegant, simple solution that avoids the complexity of a double opt-in and the frustration of a link that expires.

Unsubscription

Unsubscribing is symmetric to subscribing:

To unsubscribe, send UNSUBSCRIBE to the same address.

This mechanism is stated in the footer of every bulletin.

The same filter moves the email to the same folder, and the same task processes it: if the subject is UNSUBSCRIBE, it removes the address from the database and deletes the email.

There's a design decision hidden in the previous logic: any subject that isn't exactly UNSUBSCRIBE is treated as a subscription. It may seem cavalier, but it's deliberate. The alternative would be to leave in the folder the emails with unexpected subjects ("subscribe", "Please subscribe me", the empty subject of someone who hit send too fast), piling up unprocessed messages that I'd have to review by hand. With this rule, the folder always ends up empty, the most likely intention wins, and the worst-case cost is minimal: anyone subscribed by mistake has unsubscribing one email away, explained in the footer of the first bulletin they receive.

Sending the bulletin

Before handing anything out, the bulletin has to be written and its send time decided. I do it by writing an email to myself. I send an email to my own address with the subject NEWSLETTER, and a scheduled task picks it up at the set time each day, takes its body and hands it out to the subscribers. The first line is the bulletin's subject; the rest, the content. Then it deletes the email, just as it does with sign-ups. There's no admin panel, no editor, no form to paste the text into: if I can write an email, I can publish a newsletter. What's more, if I change my mind, I just delete the email and the bulletin doesn't go out.

So I reuse the mailbox and the task I already had. The only truly new piece is the sending service, and with it an important warning: don't send the bulletin from your personal email account. Conventional providers forbid bulk sending in their terms of use, and rightly so: their delivery reputation is shared among all their users. Before you know it your account will be limited or suspended. That's what bulk or transactional sending services are for; any of them will do.

And precisely because any of them will do, the key to the design isn't which one you pick, but that picking doesn't matter. The sending provider is an infrastructure detail, and infrastructure details are isolated behind a minimal interface. If tomorrow the provider raises prices, its delivery gets worse or you simply stop liking it, you write another twenty-line class and the rest of the system doesn't even notice.

As for which option to use to send, whether the provider's SMTP or its API, my recommendation is the API. Not only is it simpler to use, but it also tends to offer more precise delivery and error metrics than SMTP. And on top of that it lets you send batches of emails in parallel (for example, you can send to 100 subscribers at once), whereas SMTP is sequential.

The content

My bulletin is plain text. It's not a technical limitation, it's a considered preference:

Plain text is cheap on design: there are no HTML templates to maintain, no hours fighting each email client's rendering engine.

There are no images or resources to attach or store externally: the bulletin is self-contained and weighs nothing.

It reads just as...