Dev here. Thanks to everyone for the comments, suggestions, and support. MailDrop is one of those nights-and-weekends projects that came together as a bit of an

Dev here. Thanks to everyone for the comments, suggestions, and support. MailDrop is one of those nights-and-weekends projects that came together as a bit of an experiment. Here's a few responses. The design at a wider width is, okay, let's call it suboptimal. Send me a pull request with a fix for 1600px screens and I'll gladly put it in. Testing was originally done on a non-maximized desktop, along with an iPad and iPhone. (If something looks strange on Android, send me a pull request for that fix, too.) MailDrop was designed to be a friendly clone of Mailinator, with a little different architecture. It isn't going to approach the speed of Mailinator, but I'd like to think the extra functionality makes up for it. You can point any CNAME or MX toward MailDrop and it will accept messages; the system doesn't care about the recipient domain at all. If you don't want to browse through the (poorly-formatted; what's up with that?) source, here's a quick roundup of the architecture. MailDrop runs in two JVMs and uses Redis as its datastore. One JVM runs the SMTP server (written in Scala, using the SubEthaSMTP Java library and a collection of custom Akka actors) and one JVM runs the webserver (written in Scala/Play). Performance should always be IO bound; the Akka actors use very little CPU overhead. If you're finding that you're running into bottlenecks, spinning up another JVM is pretty easy. Right now, maildrop.cc is running on one small EC2 instance for everything; if it explodes, I'd probably just add another instance for another SMTP server. You'll notice that there's no way to actually send mail from MailDrop. That's by design-- the moment you can send e-mail from a service without authentication, spammers are all over it. Hence, no forwarding messages, no forwarding inboxes, etc. MailDrop is designed to help fight spam. Thanks again for the responses!