mailr
a self-hosted email automation platform for managing bulk public records requests
00
problem
Researchers who file public records requests at scale face a logistics problem disguised as a communications problem. The work is straightforward — send a templated request to hundreds of government agencies, then wait, follow up, and collect the documents that come back — but no off-the-shelf email client handles it well. Gmail and Outlook are built for conversations, not campaigns with structured follow-up. Dedicated bulk-send tools fire outbound traffic and stop there. What was missing was a single tool that could dispatch from multiple institutional addresses, track which agencies had replied, distinguish an acknowledgment from the actual records, and organize hundreds of incoming attachments — without maintaining a parallel spreadsheet by hand.
solution
Mailr is a self-hosted web application that unifies outbound campaign management, inbound response tracking, and AI-powered reply classification in a single dashboard. A bulk-send engine dispatches templated emails from multiple sender addresses using a Google Sheets recipient list. A receiver service monitors a central inbox for replies, threads them back to the original outbound message, and passes each through an LLM that classifies its status. Statuses and attachment summaries are written back to the originating Google Sheet automatically, giving the researcher a living tracker without leaving the spreadsheet.
The client is a professor at the University of Chicago whose research requires filing large volumes of Freedom of Information and public records requests via email. The requests go to government offices across the country, each with its own response timeline, procedural quirks, and attachment formats. Before Mailr, the workflow involved sending from personal and institutional addresses in parallel, manually scanning an inbox for replies, and maintaining a spreadsheet by hand to track which agencies had responded and what they sent. At the scale of hundreds of concurrent requests, that manual loop was the binding constraint on the research itself.
The architectural trick is Gmail's "Send mail as" feature: a single intermediary Gmail account sends on behalf of multiple institutional addresses, and those same addresses forward inbound replies back to the one inbox. This means one SMTP credential and one IMAP connection serve the entire multi-address workflow without running separate mail servers. The platform is Dockerized — PostgreSQL, a Flask web server, an IMAP receiver service, and a Caddy reverse proxy — and sized for a single small EC2 instance.
The researcher manages campaigns from a Google Sheet: each row is a recipient with variables that get substituted into subject and body templates. After a send, the sheet updates with a status. As replies come in, the platform threads each one back to its original request, saves attachments, and extracts text from PDFs. An LLM classifies each reply into categories tuned to the public-records workflow and writes the result back to the sheet alongside any extracted document content — so the spreadsheet becomes a live tracker of what has been sent, who has responded, and what they sent back. The dashboard adds a conversation view, a response list grouped by sender, and an attachment browser with bulk download.
Client: University of Chicago.
.say hello
always glad to talk research software, data tooling, or ai. drop me a line and let's find something to build together.