Friday, July 28, 2017

Introducing the Mailinator Real-Time Inbox

Mailinator is changing the way email works.

For most users, an inbox is an email’s final destination on a journey through the internet. It’s an endpoint, your endpoint, that holds your emails as they come to you. Checking your email, or refreshing your browser, is when your inbox asks if there’s anything new for you.

But Mailinator doesn’t see it that way because inboxes @mailinator.com don’t really belong to anyone. The public Mailinator system gets many (oh so many) millions of emails per day - and you can read any of them. So can anyone else. With Mailinator, you don’t even have to create an inbox. You can just start sending email to it.

One way to think about it is that all inboxes already exist. Another way to think about it is that Mailinator creates inboxes on-the-fly as email arrives.




From Mailinator’s point of view the email flow is relentless and constant. We call it the Mailinator Stream. Previously, inboxes got new mail the way all inboxes do - periodically they asked the server if there was any new email to display.

But now we’ve hooked you up to the stream. Directly. To every inbox. In real time.

Welcome to the Mailinator Real-time Inbox. 

The moment someone sends an email to Mailinator, it’ll show up on your screen (just as fast as the internet allows). There’s no delay. You’ll never again have to hit ‘refresh’ on a Mailinator inbox. (Go ahead and give it at try - pick an inbox @mailinator.com, send an email to it, and watch it arrive an instant later - be sure to turn off the "undo" feature of Gmail or it'll delay 30 seconds before sending)

Now, with Mailinator’s inbox page tapped into the stream, an inbox is a filter. Everything that matches your filter will show up in real time.

For most users, that won’t make much of a difference. You’ll get your anonymous, no-sign-up emails like always, except now they'll arrive instantly. An inbox will still act like an inbox.

But paid subscribers with private domains can query the stream at a deeper level. (For those who didn't know, you can upgrade your Mailinator account to get your own private, not-auto-deleting version of Mailinator pointing at at your own domain that your whole team can access simultaneously).

Subscribers can create more complex filters and persistent queries that capture more than just a single <inbox> from the stream. You can tap into multiple inboxes at the same time. You can also use a trailing asterisk as a wildcard. Asking your inbox to capture testing* will fill your inbox with all the emails sent to testing1, and testing99, and testing-xyz, and anything else which matches.

Mailinator has always been about providing public email addresses for anyone to use (no signup required), and now it does it in real-time with some great new features. Interested in your own private Mailinator where every inbox you can think up is yours (instantly and wildcard searchable)? Request a Trial today.


Thanks for using Mailinator!

Thursday, May 4, 2017

Mailinator and the Recent Google Docs Phishing Attack

Yesterday (Wednesday, May 3rd), someone launched a clever phishing attack against Google users.

They wrote a little application and falsely named it "Google Docs." Given the chance, it compromises your Gmail account and reads your contacts list. Then, using Google’s own email servers, it sends itself to all your contacts.

This kind of attack lives or dies by how successful it is at getting people to believe it and click through. If no one clicks, or if no one grants it the permissions it asks for, then it doesn't spread and nothing happens. But every time someone clicks through and grants the app the access it wants, the attack multiplies by the number of times it propagates.

The attack was very successful at getting people to click through and grant it permissions, and it spread very quickly.

But it did so in a quirky way, one that made Mailinator one of its victims. It emailed itself from one victim's account to the next set of targets by BCC (blind carbon-copy). If you received the email, it came to you that way. Your email address wasn't in the TO field, it was in the BCC field.

That's a little bit clever. Since the BCC: is blind, the victim doesn't see themselves included in a long list of recipients (many of whom they don't recognize), which is often a big clue that the email is nefarious (or some dumb joke that a clueless relative has forwarded to everyone they know). Any one attack email might have been BCC'd to dozens of new victims.


When you send an email, you can't just BCC people. To make it legit, there has to be something in the TO field. Since all the victim's contacts were in the BCC field, the address the emails are TO isn't part of the attack. The attacker just needs a dumping ground. Something that looks just-so to the target; not a name that stands out for being unfamiliar, but also a real address that works and won’t bounce. That will improve deliverability and believability. So who did the attacker choose to send these emails to?

hhhhhhhhhhhhhhhh@mailinator.com

What is the significance of that inbox? As far as we can tell, there isn't one. Since all addresses already exist at Mailinator, using your finger to hold down a key for a bit generates a completely innocuous - but usable - inbox name. The significance of using mailinator.com is clear: our well-deserved reputation for successfully handling high volumes of incoming email.

In effect, they were relying on Mailinator’s proven ability to receive lots of email.

From the attacker's perspective, it doesn't matter much what is in the TO field. They just need to make sure that the emails get out the door. Mailinator is very good at receiving emails, the attack spread very quickly, and very soon the hhhhhhhhhhhhhhhh inbox at Mailinator was getting thousands of emails.

We noticed the activity early on, and shut down the inbound stream of emails to the hhhhhhhhhhhhhhhh inbox. Unfortunately, this did nothing to stop the attack. That's because nothing about the attack was happening via Mailinator. Mailinator was simply another recipient of the email. The attack could not propagate itself via Mailinator but it sure could send us email when other people propagated it. By the time we shut down the inbound stream, hundreds of thousands of emails to hhhhhhhhhhhhhhhh had shoved their way through our system. Any one inbox at Mailinator only shows 50 emails, and that inbox was (at peak) receiving a few thousand emails per second. Because the volume was so large, it wasn’t possible to read any of these emails at Mailinator. Before anyone could have clicked on one to read it, Mailinator had expired it to make room for thousands more that were pouring in.

The emails to hhhhhhhhhhhhhhhh were of no consequence to the attack. Even the name was irrelevant.

Strangely, we've seen a few articles mentioning that that inbox was the sender. Most even showed a screenshot on the same page contradicting that idea with the Mailinator address clearly in the TO field and one of the victim's contacts as the sender.

Just to be clear: the Gmail phishing attack sent email to a victim’s contacts using Google’s email servers and all emails were FROM another Google user. Each time the attack propagated, it also emailed TO Mailinator as a receiver, nothing more. None of those emails came from Mailinator, they came from Gmail.

It's true that all of the attack emails were TO: hhhhhhhhhhhhhhhh@mailinator.com, but it seems pretty clear that if you're looking for where the emails came from, you'd want to look at the FROM: field.

Additionally, the emails can't be from Mailinator because Mailinator can't send email. It’s a receive-only service. The Mailinator system was not part of the attack - it was just a recipient like all the other victims. The only difference between us and the other recipients was that we received hundreds of thousands of these emails in a very short time.

If you visit that inbox now (here's a link to hhhhhhhhhhhhhhhh inbox - don't worry, it's safe to click, it will take you right to Mailinator), you’ll notice no such phishing emails. We turned the inbound stream of attack emails off very soon after the phishing scam started.

Service to our legitimate users was uninterrupted.

Mailinator remains, as always, the best place to get a free, disposable email. We can’t prevent people from sending email to us (receiving email is the whole point of the service!) and we still love our regular users: thousands of QA Teams that send us millions of test emails, and you - whenever you want to protect your real email address from spam.

Thursday, August 27, 2015

Mailinator's API : Closing the Loop for QA

Mailinator's API provides programmatic access to all email within the Mailinator system. If your QA department has a need for delivery testing, this is an unprecedented way to have immediate access to thousands of email inboxes.

Mailinator API docs

Since we launched the API a year ago, we've been constantly surprised about the uses people have found for the API. Testing signup systems (with a confirmation email) seems to be a popular choice, but other customers test marketing campaigns and test automated alert systems sending us thousands of emails each day.

The API works on both the public Mailinator system and the private domain system. For the public system you have instant access to any of Mailinator's millions of emails, obviously including the emails you send there.

If you're looking for more privacy, you can setup a private domain and only you (and your API token) can see emails that arrive for that domain.


If you're interested in accessing emails via API - Sign up at Mailinator today and try out the API!

Monday, September 22, 2014

Playing Wasteland 2? Find the Mailinator gun !

Mailinator has always been about vanquishing spam - and now in Wasteland 2, you can vanquish some Wasteland Wolves using "The Mailinator" gun !

Mailinator is proud to be a backer of the newly released Wasteland 2. If you're playing the game (and you should be!), be sure to lookout for the gun called "The Mailinator".

(hint: you might consider having one of your rangers specialize in Heavy Weapons !)

Saturday, November 9, 2013

Increasing Brand-Value of Mailinator.com with a Web Comic

[This is a guest post by Marketing/Growth-Hacking consultant Martha Andrews - contact her directly at martha@manybrain.com.  Follow Martha on Twitter @another_martha]

We have been doing some investigation in increasing brand awareness for Mailinator.com.

Mailinator has always been a useful site providing free, disposable email - but analysis of the usage patterns of Mailinator indicated that users tended to use it on a monthly or bi-weekly basis rather than weekly or daily. In some ways this makes sense – the site provides a utility, but the use case for the general public isn't necessarily needed on a daily basis. When it is needed however - our goal is to make sure you think of Mailinator.com!

In order to raise all usage levels of the site, we focused on public awareness of the site, expecting that an increased DAU (and MAU) would/should be an expected side effect.  I’ve frequented many trainings in the last year, and I cannot tell you how many times I’ve heard, “Create interesting and useful content and people will flock to your site…Its all about providing content.” 

But what content could we give to our users?  We already give away the service – we have a useful tool, and want more folks to know about it and use it.

Before creating content, something to consider is who is in our user base?  Web analytics told us the primary user base is male, ages 18-40 – think of the average Reddit user.  So how do we engage 18-40 year old men, and potentially other demographic groups?  How do we get them to think of Mailinator.com more often?  What could we provide that would be of use of them?  Getting folks to think of the site more often, and giving them content and reasons to visit the site would likely expand their current usage pattern.

We tried targeted ads through traditional web and social channels. Specifically - we experimented with Google Adwords, Reddit.com, Facebook, and Twitter.  The ads provided momentary increases in traffic to varying degrees but nothing long lasting.  We can get more users to Mailinator any day of the week by spending some money, but that cannot be sustained given that mailinator.com doesn not generate direct user revenue.

During a recent site redesign we incorporated a new mascot of sorts – an amiable looking caped crusader we dubbed “Mailinator Guy” - the Anti-Spam Superhero. 
The more we lived with Mailinator Guy, the more often we started asking: what if we launched a web comic based on Mailinator Guy?  Would a comic be appropriate content?  If you've ever read Mailinator's FAQ you know the tone of the site is already quite tongue-in-cheek - we at least amuse ourselves.  Frankly the thought of bringing Mailinator Guy to life was simply too fun an experiment not to try.

ComicRocket has over 35,000 web comics indexed on their site alone, so competition for user attention is stiff.  However we found Facebook ads for the comic to be highly successful in engaging a new audience.  We think it works well because they are demographically targetable, colorful, eye catching and fun.  A thumbnail or portion of the strip is always displayed in the posts and ads.

We also engage our existing audience through the Mailinator Facebook page (with >30000 likes). There is an announcement on the page when a new comic is published. Additionally, the colorful thumbnail version of the strip is shown on the landing page and on mailbox pages at mailinator.com.  We have found as we release a comic each week, we are slowly habituating our audience to check mailinatorguy.com on a weekly basis – and if they are following us on twitter or are a Facebook fan, we have an excuse to contact them.

The feedback loop of the two sites is strong. Mailinator.com provides the free disposable email utility that brings new users by itself. The site's design reinforces the Mailinator Guy character and encourages our primary demographic, arguably also the primary demographic for web comics, to follow the comic.  The MailinatorGuy.com site provides a weekly enticement for a visit. That visit keeps the Mailinator brand fresh in our user's mind causing the loop.

Of course some users of Mailinator will never care about the comic. And some users of the comic will never care about mailinator.com.  And that's just fine - both sites have inherent stand-alone value.

At the time of this writing we have published six episodes of The Adventures of Mailinator Guy. Our advertising efforts, both paid and direct referrals from mailinator.com, have driven traffic that averaged 1,500 unique weekly users the first three weeks, to over 3,000 unique weekly visitors the following three weeks.  The most traffic occurs on Mondays when we have usually posted and announced a new episode.  Along with an increase in users, producing the comic has become more efficient and economical, and still pretty darn fun.

Importantly - traffic to mailinator.com has increased 15% in the 6 weeks since the launch of the comic and continues to grow.

These numbers are very encouraging but honestly the most important outcome is the increase in Mailinator brand recognition. The site's brand value will continue to grow and that's the real goal of this exercise.  

At the end of the day - everyone is happy.  More people know about the Mailinator brand - this makes us happy - and have either avoided some spam by using our free disposable email service, have had a laugh at the expense of Mailinator Guy - and his sidekick (you'll have to read the strip to find out about him), or both.

If you're up for following the adventures of Mailinator Guy yourself - here's the link to get you started:

The Adventures of Mailinator Guy! 






Saturday, October 5, 2013

Introducing .... Mailinator Guy

Let me tell you a secret - if you want a positively sure way to get unfettered love and hate mail at the same time - just go redesign a website.

If you've used Mailinator for any length of time you see we changed the website design a few years back. We brought it from probably somewhere in Web 1.0 to current day.

The redesign was more than simply a redesign however - it changed how Mailinator worked. A great deal of internal code was added to prevent abuse of third-party sites using Mailinator.

Overall the redesign was a huge upgrade and success - and I promise you the lovers far outweigh the haters  :)  (site traffic got a significant and sustained increase too).

Our redesign this summer also served to introduce Mailinator.com's anti-spam superhero - Mailinator Guy !


He's here to save your inbox from spam. He can fly, has a magic envelope he carries with him everywhere, and of course has a neato secret lair.

Now - Mailinator Guy has his own webcomic !   So if you're a fan of Mailinator and like to read webcomics - what are you waiting for !

Check it out here:

http://www.mailinatorguy.com

Tuesday, April 16, 2013

Code Review for a String Lock Map

I recently needed a mechanism to lock on given Strings in a particular piece of code. As maybe a weak example, say I was doing disk file updates to files each with unique filenames (i.e. read, update, write-back). I could have synchronized the methods that modified the files, but I preferred to not lock at that level - in other words, only one file update could occur at a time then.

I'd prefer to simply lock on that file - or more specifically, that filename. Its a dubious proposition to lock on String objects in Java as different objects can represent the same set of characters. You can intern() all your strings (which makes sure the objects you have are the "one" system-wide representation of that String) but that is rather global. I wanted to do things locally - where I can control the scoping of the lock.

(The filename example is just an example, I've needed this structure in many different scenarios - so don't look to just solve that problem).

I might have missed it, but I didn't find any facilities in java.util.concurrent to help me (and to be fair, I haven't kept up with the happenings there. Long story short, I wrote my own.

Of course the best advice when writing concurrent locking datastructures is - DON'T.

But I did. And I probably plan on using it eventually, so I put it here for review. I'll update it as comments come in (so if you see a comment below that makes little sense it's probably because I heeded it and changed the code).

The use case I want:

public static final StringLock stringLock = new StringLock();

...

try {
     stringLock.lock(filename);

     // load disk file
     // change its contents a bit
     // rewrite it
     
} finally {
     stringLock.unlock(filename);
}

So.. find below the code I've come with so far. Its a bit heavy under contention but the normal case (no contention) it syncs 3 times (writes on ConcurrentHashMap being a sync). I could also use Cliff Click's NonBlockingHashMap to remove two of the syncs but and I'd be happy to be convinced that'd be superior for some reason.

public class StringLock {

 private final ConcurrentHashMap lockedStrings = new ConcurrentHashMap();

 public void lock(String s) { 
   Object lockObject = null; 
   while (true) { 
     lockObject = lockedStrings.get(s); 

     if (lockObject != null) { 
       synchronized (lockObject) { 
          Object lockObject2 = lockedStrings.get(s); 
          if (lockObject2 == lockObject) { 
            try { lockObject2.wait(); } catch (Exception e) { } 
          } 
        } 
     } else { 
        lockObject = new Object(); 
        Object lockObject1 = lockedStrings.putIfAbsent(s, lockObject); 
        if (lockObject1 == null) { 
          break; 
        } 
     } 
   } 
 } 

 public void unlock(String s) { 
    Object lockObject = lockedStrings.get(s); 
    synchronized (lockObject) { 
      lockedStrings.remove(s); 
      lockObject.notifyAll(); 
    } 
  }
}