Context
The current skill/SKILL.md doesn't mention share receive-email at all, even though it's a really nice feature once an agent knows it exists. I just got an agent end-to-end on the email pipeline and a few small things would have unblocked it earlier.
Filing as an issue rather than a PR because the inbound-email write-up has a few opinion calls (length, recipe-vs-pointer, where to slot it) that I'd rather defer to the maintainers — happy to send a PR if you'd like.
What an agent needs to know to be productive
Three facts that aren't in the skill today:
-
Address pattern is wildcard. *@<vm>.exe.xyz — any local-part routes to the same Maildir. The API response uses anything@<vm>.exe.xyz as the example local-part, which is easy to mis-read as a magic literal rather than a wildcard demo.
-
Mail lands in ~/Maildir/new/<sha256>.eml in standard Maildir format, dropped in by exe.dev's delivery infrastructure (no SMTP daemon runs on the VM). Standard email parsing tools (Python stdlib, etc.) work directly against the files.
-
A welcome email arrives within ~3 seconds of receive-email on — useful as a self-verification probe before pinging anyone for a real test send.
Bonus gotcha worth flagging: outbound :25 is blocked from most consumer ISPs and many cloud providers, so mail/sendmail/swaks from a laptop will silently queue and time out (Operation timed out to mail.exe.xyz[52.35.87.134]:25). Test sends should come from authenticated submission (a real mail client on :587/:465), not raw mail on the dev box.
Suggested skill snippet (drop-in if you want it)
## Inbound email
`ssh exe.dev share receive-email <vm> on` enables inbound mail at a wildcard address: `*@<vm>.exe.xyz`. Any local-part routes to the same Maildir at `~/Maildir/new/<sha256>.eml` on the VM. exe.dev verifies SPF + DKIM and stamps an `Authentication-Results` header; the message body is otherwise untouched (full MIME preserved, attachments included).
A welcome email arrives within seconds of toggling on — count files in `~/Maildir/new/` after enabling to confirm the pipeline is up before asking anyone for a real test.
Sending mail _from_ the VM requires installing your own MTA (`msmtp` against an external relay is a small footprint). And note that outbound :25 is widely blocked from laptops and cloud VMs, so `mail`/`sendmail` from a non-mail host will silently queue with `Operation timed out` errors against `mail.exe.xyz`.
Verified against
ssh exe.dev CLI on a Trial plan account, 2026-04-27. Real test send from Fastmail (poem + lists + inline JPEG attachment), parsed with Python stdlib, attachment extracted byte-identical.
Related
PR #193 covers the naming + non-interactive shell gotchas separately.
Context
The current
skill/SKILL.mddoesn't mentionshare receive-emailat all, even though it's a really nice feature once an agent knows it exists. I just got an agent end-to-end on the email pipeline and a few small things would have unblocked it earlier.Filing as an issue rather than a PR because the inbound-email write-up has a few opinion calls (length, recipe-vs-pointer, where to slot it) that I'd rather defer to the maintainers — happy to send a PR if you'd like.
What an agent needs to know to be productive
Three facts that aren't in the skill today:
Address pattern is wildcard.
*@<vm>.exe.xyz— any local-part routes to the same Maildir. The API response usesanything@<vm>.exe.xyzas the example local-part, which is easy to mis-read as a magic literal rather than a wildcard demo.Mail lands in
~/Maildir/new/<sha256>.emlin standard Maildir format, dropped in by exe.dev's delivery infrastructure (no SMTP daemon runs on the VM). Standardemailparsing tools (Python stdlib, etc.) work directly against the files.A welcome email arrives within ~3 seconds of
receive-email on— useful as a self-verification probe before pinging anyone for a real test send.Bonus gotcha worth flagging: outbound :25 is blocked from most consumer ISPs and many cloud providers, so
mail/sendmail/swaksfrom a laptop will silently queue and time out (Operation timed outtomail.exe.xyz[52.35.87.134]:25). Test sends should come from authenticated submission (a real mail client on :587/:465), not rawmailon the dev box.Suggested skill snippet (drop-in if you want it)
Verified against
ssh exe.devCLI on a Trial plan account, 2026-04-27. Real test send from Fastmail (poem + lists + inline JPEG attachment), parsed with Python stdlib, attachment extracted byte-identical.Related
PR #193 covers the naming + non-interactive shell gotchas separately.