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.
It's not the amount of text it's the 100% width that's giving it that "giant wall of text" look. The text is all over the place.
If they switched to a fixed width it would look a lot better and easier to read and scan through. You can try this in Google Chrome. Right-click on their page and select "inspect element". Then in the developer tools window find the <body> element and click on that. The body {} selector should come up on the right hand pane of the developer tools window, click to the right of the last bracket } and it'll let you add another rule, put in width:1000px; and then margin:auto; now go back and see the changes on the page. (refreshing the page will return it to normal btw). See. Much better.
There's a reason why most websites use a fixed width. People complained about fixed widths in the early 2000s because they used to be only 800px wide and they weren't used to the white bars on the side of their websites. Now that our monitors are about 1600 pixels wide fluid 100% widths are just too stretched out and it's harder to read and scan through text.
You can also use CSS3 media querries to change the width according to window size (I made a site using this http://timeforzen.com (resize the window and watch the layout change))
Reading it full width on 1600x900 and it's fine. The only thing I would change is the contrast. I am having trouble reading some of the font. If it was a bit lighter or bolder I would be able to read it better.
This is a really good move. I've ran into several websites that check against the most popular temporary email services and the domain names that they use.
FYI, my understanding is that you can also set up the MX record for a domain you own to point to the Mailinator service if you want to get around this problem.
Looks neat, but I think I would prefer (or have available as an alternative) a service that lets me create (and possibly manage) "throw away" forwarding addresses to my real address.
Absolutely. I'm currently using the paid version of leemail.me for this exact thing. Unfortunately it seems development has stopped and leemail still needs considerable features to make it THE "email forwarding" and "throw away" service. I can't wait for some other company to come in and make it happen.
Is there a way to use your own domains with Leemail (or alternative services, if any)? I'd love a way to be able to shut off addresses when a provider's email database gets hacked. Right now I'm just making do with a Google Apps catchall.
I have used Spamgourmet for years, and I'm finding now that even on some of the more obscure domains alternatives that they offer, I'm starting to have websites block mail to them. As in, they don't reject the addresses on the site, but I just do not get any mail.
Forums and websites get lists of throw away email address domains and block them...how are you going to combat this problem? spamgourmet.com still has it, and it dozens to choose from and you only have one...
Suggest you update the "We Do Not Track our Visitors." part of your privacy policy to state that whilst you yourself don't track your users, you do allow Google to do so (google-analytics.com)
Also, where you say "the only cookie we use is to keep track of the most recent inbox that you've visited" - This isn't true. You use Google Analytics, so there is a cookie in use there too.
I saw http://www.otherinbox.com take care of this a few years ago, was nice in theory, but I never kept up with my account. Bigger issue, your splash page has an enormous amount of text.
EDIT: Hmm, I probably should have mentioned this before, but if you visit that URL, the XSS that happens will lead to your IP address being displayed on a public page.
I'm conflicted; on one hand, obviously protecting against the HTML sent in an e-mail is a good idea. I seriously considered having all e-mail bodies run through https://code.google.com/p/owasp-java-html-sanitizer/ to strip out bad elements. On the other hand, MailDrop obviously isn't meant to be secure-- if you're worried about a truly private, secure inbox, MailDrop is not that application.
Got a good compromise between the two? Send a pull request and I'll get it in.
You might find a 100KB email size limit blocks a lot of email. You want to be making it easy for email to get into these temporary email addresses, not difficult.
The thing I like about mailinator is that I know I'll be able to pick up the message that gets sent to it...
This is a really beautiful solution to an obnoxious problem. If you aren't adverse to the idea I think you should add some share links to get some viral traffic I know plenty of non hners who would use this.
Why are you greylisting? That just delays the email arriving... It makes sense to greylist normal email accounts, but for a temporary email addresses it doesn't...
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!