Postloop

What it is

A mail tool for local development that works in both directions. It runs an SMTP server on your machine, catches everything your app tries to send, and gives you somewhere to read it. That part is well-trodden. The part that isn’t: you can reply to those messages, and the reply gets delivered to your app as a properly formed RFC 5322 message, POSTed to your inbound webhook endpoint.

Why I built it

Catching outbound mail locally has been a solved problem for years. Testing inbound mail has not. If your product does anything with replies, whether that’s support threads, reply-to-comment, or commands over email, the local development story is grim. You either point a real domain at a tunnel into your laptop and send yourself actual emails, or you hand-craft a MIME payload and curl it at your own endpoint. The second one tests your endpoint against your own idea of what an email looks like, which is not the same thing as what one actually is.

Both options are slow enough that people stop doing them, and the parsing code quietly rots until something real breaks in production.

How it works

Two halves. The SMTP listener accepts whatever your app sends, with no auth ceremony, and holds it. The reply side takes what you type and assembles a genuine RFC 5322 message: correct headers, In-Reply-To and References set so threading actually threads, a real multipart body. Then it POSTs that to the inbound endpoint you’ve configured, in the shape your mail provider would use.

The message your parser sees in development is structurally the same as the one it’ll see in production, so the bugs you find are the bugs you’d have shipped.

Where it is now

Published on npm, installable and runnable with a single npx postloop. It’s a small tool with a narrow job, and I’d like to keep it that way.