That arrangement is normal in D&D tooling and it deserves more suspicion than it gets. If you’ve ever wondered whether a bot you’re about to install will spam your players, this post is the audit we ran on our own product, what we found, and the checklist we’d now hold any bot to, ours included.

What the audit found

On October 6th we sat down and traced every path by which Loracle sends a session reminder. The defaults at the time: a reminder one day before the session and another one hour before, delivered on email and Discord both, for every campaign member, on by default.

Count that out. Four pings per member per session. A table of six playing weekly generates about a hundred notifications a month, to people who opted into exactly none of them.

The emails themselves were worse than the volume. Each one was a single line of text. No unsubscribe link. No link to a settings page. No List-Unsubscribe header. A player who had never logged into the web app, which describes most players, since the DM does the setup, had no way to make the emails stop. Their options were asking the DM to remove them from the campaign, or clicking “report spam.”

That second option matters beyond the one annoyed player. Spam reports are scored against the sending domain. One player flagging a reminder they couldn’t turn off degrades deliverability for every table we serve, including the recap email someone else actually wants. An email you can’t decline is a liability to everyone sharing the pipe.

What we shipped

Five changes, aimed at the structure that produced the problem.

The default dropped to one reminder. An hour before the session, one slot, because that’s the reminder that changes behavior. The day-before slot still exists for tables that want it, as an opt-in in settings. Default volume is a statement about whose time you think you own, and the honest default for someone who never signed up is the minimum useful amount.

Every notification email now carries a signed one-click unsubscribe. The link holds a short-lived signed token naming the user and the event type. The token is the authentication. No account, no login, no password reset for an app you’ve never opened: one click and that category of email stops. For session reminders it goes further and cancels anything already queued for you, so the unsubscribe takes effect before the next send, immediately.

The headers went in too. List-Unsubscribe and List-Unsubscribe-Post, the RFC 8058 pair, so Gmail and Apple Mail render their own unsubscribe button at the top of the message. Most people who want out will never scroll to a footer. Meeting them where their mail client already looks is the difference between an unsubscribe and a spam report.

The link is attached at the dispatcher, not in each template. This is the structural fix, and it’s the part worth stealing. Every user-scoped email in the system flows through one dispatch function, and that function stamps the unsubscribe link onto the message before anything sends. A future feature can add a new email type while forgetting about unsubscribe entirely, and the link ships anyway. Per-template diligence decays; a chokepoint doesn’t.

Late reminders get dropped instead of sent. If the worker falls behind and a reminder comes due more than fifteen minutes late, it gets marked skipped and never sends. A reminder for a session that started twenty minutes ago is spam wearing a helpful costume. We’d rather miss one than send it.

The checklist, for any bot you’re about to install

The audit left us with a short list of what a bot owes an inbox it borrowed. You can’t read a vendor’s dispatch code before installing their bot, but you can check the output. Add a bot to a test server, trigger one email, and look at what arrives:

1. Is there an unsubscribe link, and does it work without an account? Forward the email to an address that has never logged in, click the link there, and see what happens. If the path to silence runs through “create an account,” the bot has decided your players owe it a signup.
2. Does Gmail show an unsubscribe button at the top? If yes, the headers are present and your least technical player can get out in one tap. If no, the vendor hasn’t thought about the person who never scrolls.
3. What’s the default volume for a member who configured nothing? Whatever you receive in that test is what every player at your table will receive. Judge it as if a stranger’s bot were sending it to you, because from your players’ side, that’s what it is.

A reminder bot sits in a strange trust position: the DM chooses it, the players live with it. The vendor’s incentives all point toward more email, since every message is an impression. Which is exactly why the unsubscribe machinery is the thing to check. A bot that makes leaving easy is a bot that expects you to want to stay.

Loracle’s reminders now pass all three checks. They didn’t three weeks ago, and nobody outside the codebase would have known either way. That’s the real argument for running this test on any bot that touches your table, ours included: the inbox behavior of a Discord bot is invisible right up until it’s annoying, and by then it’s annoying five people who never chose it.