reliverator
Sometimes I want to send some mail. Sometimes I want to receive some mail. (Much less often than it typically happens, as it were.) But mostly I want to not think too much about it.
Alas, the history of email is rife with people thinking about it, and inventing new problems for their solutions. My needs are much simpler than that. I want to have email that arrives at port 25 go in my maildir. I want email that I send to port 587 to go wherever it should go. That’s about it. I don’t need fancy filtering before it goes in the maildir; I can always do that later. I don’t need fine grained authentication to send; it’s my computer, if I want to send it I’m going to send it.
But nobody makes a mail server just for me. The self hosted email market is kinda small already, because Big Evil has decided that’s bad for you, but it’s also quite a chore just reading the documentation for even simple server setups. How about an smtp server that doesn’t require documentation because it doesn’t have any features? If it doesn’t do anything, it can’t do anything wrong.
Enter the reliverator. It receives email. It delivers email. It’s a deliverator, not written in D.
When an email is received, it goes in the user’s maildir. If there is no maildir, it doesn’t.
When an email is submitted, it goes in the database until it goes somewhere else. There’s no access control because it only listens on localhost and I’ve already got an ssh tunnel open from my laptop.
Mostly I just wanted to see how hard can it possibly be. And after some bludgeoning and tear soaked stackoverflow copy pasta, it kinda came together. There’s a fine mess of a little of everything. It’s about 25% unsafe, though that’s not the part that worries me most. I even used some tokio for bonus points, though it seems overkill for sending and receiving a single UDP packet, but I don’t pack the crates.
If I really wanted to write an smtp server, I’d have made some very different decisions.