Hacker News Reader

Hi Zikes, I'm the developer of this service at Mailgun. Nice to meet you.

We've been using this service at Mailgun during testing and we've reduced bounce rates by 5%. That might not seem like a signficant number, and it may not be for a personal blog, but it can be significant number for a larger ecommerce website.

For someone like us, a service that sends billions of emails, it's huge and we wanted to provide additional value for our customer to help them reduce their bounce rates and improve conversion.

Plus we don't correct typos on local-parts, just domains. So we won't correct Jooohn@gmail.com, but would suggest a correction for john@gmaill.com.

Thanks for this service. There isn't any replacement for actually sending an email and having someone click a link to confirm receipt, but this is a step closer towards that.

UX improvement: highlight what you changed in the autocorrect suggestion: https://www.monosnap.com/image/OtGnn60OhykMAx9s3xsNXkyn5#

Maybe I'm an idiot but it took a while to see the 'user' actually entered "gmall" (I assumed it was correcting the spelling of Michael since the vowels in that name get mixed up so frequently).

Can you talk about why reducing bounce rate is important? For me, ensuring that the email address entered belongs to the user who entered it is the most important.

Hey, mailgunnner here. Thanks for the ux suggestions! On bounce rate, a bounce will happen when you collect an email address that is invalid, and then send to it. It is basically the symptom that you can measure to know that the email is indeed invalid. By measuring a reduction in bounce rate, we've been able to determine that the validator does its job catching invalid addresses. For determining whether the email address entered belongs to the user who entered it, you can (and should) use double opt-in, where you email a confirmation link to the users.

Hey Russ, thanks for your reply.

I think I've been a bit harsh and quick to judge, sorry about that. Obviously the service must have value, and it's my own failing not to have seen it.

I do wish you the best of luck with this new service, and I hope that many people are able to benefit from all the hard work you guys have put into it.

Could you confirm you won't store or otherwise log email addresses submited for check for any time longer then neccessary?

Hi airnomad, I'm the developer of the validation service here at Mailgun.

I can confirm that we do not store email addresses. The parser runs completely in memory and no address is persisted after the request is complete.

So tomorrow a national security letter shows up. Whaddyado?

This is probably a valid concern for some services. Do you keep the address in log files somewhere?

If national security letters are part of your threat model, nothing they can say can make the service acceptable to you.

You should also stop using EC2 or linode, stop injecting the google analytics JS into your pages, stop taking payments via Stripe, and so on.

The "did you mean" feature alone is gold. I talked to the guys in our customer service department about a "did you mean xvy@hotmail.com"/ "xvy@gmail.com" feature for a while. That one feature alone could cut our misdelivered emails in half. Forget adding two email fields to a format, people just copy paste anyway.

Honestly, to you and me, it may seem trivial, but your customers have a really had time entering their email address. Our customers are end users, really end users, these are people for whom their email address means VERY little, but at least they remember that their email isn't at gmalr.con, if you remind them.

I'm not a Mailgun customer, but I would pay for this service (but not to much).

I've been at a large web company where this feature provided a non-trivial bump in conversion.

this API's obvious intentions say it should also provide a non-trivial bump in conversions to Mailgun paying subscribers.

This has actually existed as an independent library called Mailcheck.js[1] for a long time and I have used it in quite a number of projects. So if that is the only reason you want to use this API it would be better to go with mailcheck.js, simply to remove an external dependency.

[1] https://github.com/Kicksend/mailcheck

It's a little bit more than a regex. From the documentation[0]:

Given an arbitrary address, we will validate the address based on:

Syntax checks (RFC defined grammar)

DNS validation

Spell checks

Email Service Provider (ESP) specific local-part grammar (if available).

[0] http://documentation.mailgun.com/api-email-validation.html

I know, it's a great deal more than a regex, and that's actually my point. It's dedicating tons of extra resources and time to a process that is ultimately redundant.

You can't truly validate someone's email address because you don't know what their email address actually is. Your only two options are:

1. Be omniscient

2. Send a validation email

It stops people from doing something like fake@lolthisisstupid.com at least though.

I wish more places would validate their email. In the past two days I've been informed that I know have a Playstation, EA, and Blizzard account because someone signed up with my email address (just without the dots.)

Only Blizzard tried to confirm the email address. The other two created the account, and now won't let me disown the accounts. I can go through the forgot password process and turn them off, but I'm not sure how kosher that is.

Have you ever crafted a sign-up form for a paid app though? Requiring users go and check their email before they can proceed is going to kill conversions. Mail providers (I use mandrill) also deliberately throttle outgoing email - I've seen them delayed by several minutes.

If someone's buying something from my site, I'm not going to send them a validation email during the checkout process.

Something like this greatly reduces the number customer support emails saying "I didn't get an order confirmation email from you!" when they typed in joe@yahoo.cm.

But no validation in the world will catch that. Only a round-trip email would.

EDIT: I was wrong. Interesting.

... not with 100% accuracy, but it's totally plausible that you can do substantially better than random (or a simple regex). So there is incremental value here.

That's the point: Mailgun's Validation API does catch that joe@yahoo.cm is incorrect and suggests a correction. Try it: http://mailgun.github.io/validator-demo/

I see that as the only valuable part of this service, and I can instead use it statically via mailcheck JavaScript: https://github.com/Kicksend/mailcheck

thanks for the link. this is actually true considering the email validation embedded in HTML5.

> 2. Send a validation email

The big three providers all have OpenID or OAuth endpoints that return email addresses, so you also have the option of asking the domain directly.

(You can outsource that whole thing, too... * coughs something about Mozilla Persona *)

DNS Validation

I wonder if they will also be able to tag domains/addresses as potential spam-bots.

It flagged my favorite fake email that does have valid A record, but no MX record 'example@example.com' as invalid.

The email spec allows for missing MX records, it should fallback to use the A record to deliver instead.

Hopefully they aren't invalidating domains that don't have an MX record.

Hi fsckin, example@example.com fails because while we do fallback to A records, no mail exchanger responds to us, so no one can actually receive mail at that inbox which is why we mark it as invalid.

Just curious: is this a one-time immediate check for an MX that responds?

Say, for example, that example.com has only a single MX and for whatever reason (server is down, network connectivity is broken, etc.) it is unreachable or unresponsive at the exact time you test. Would that constitute a "fatal error" in your validation process?

If there is a single MX RR but it "expands" to multiple hosts (multiple A RRs), do you test a second one if the first doesn't respond?

TIA!

Anything @example.com is actually invalid due to it being reserved by RFC 2606.

It does a DNS lookup, advanced parsing (which can be hard [1]) and common typo-fixing suggestions.

Not a useless service, to be sure; you have to make your customers aware that their email is submitted to a third party for validation though. Usually people don't care all that much (and have that same emails addresses listed in public profiles), but a relevant bit of fine print should be there.

[1] http://www.codinghorror.com/blog/2005/02/regex-use-vs-regex-...

It only implements a subset of DNS functionality, so I'd argue its giving a false sense of security and false negatives. mailtest@пример.испытание fails, for example, even though it is a valid email address.

This was my first response too; there's been a CLI tool (called vrfy) for a while that I've given up on using because it almost always says "send some mail, i'll try my best". That tends to be the ultimate test, which you can probably already do pretty quickly with a backend for a web form.

EDIT: That being said, making a potential customer wait for thorough verification, on top of "spamming" them before they've (technically) bought from you would be unwise; I can see how this would have merit.

Have you ever worked on e-commerce sites? Bad email validation or the requirement for a confirmation email can kill business. If a user buys a product but types `sally@yahhhoo.com` and then doesn't get their purchase or shipping confirmation, you can bet there will be long labor-intensive interactions with customer service. Getting a high confidence value in an email address without a confirmation email has great value.

Did you read beyond #1 in the post?

Yes, and none of those extra steps actually have a significant effect over simple regex checking to confirm the validity of the email, because there is no way to know what the user's correct email address actually is besides sending them a validation email. None.

The domain may exist, the mailbox may exist, it may match all the rules for that particular mail exchange, it can pass this validator with flying colors, but you still have to send that validation email because I could just as easily have entered your email as my own, and that makes this a moot step.

I don't think anyone is claiming that this can replace the function that a validation email serves.

What this allows you to do is give feedback to users quicker. If a user signs up for your service and mistypes the domain name for their email address, they'll never hear anything from you. And if they don't know they made a typo, they'll just think that you have a flaky service. This lets you prevent that from happening.

I think you're missing the intended use case. It's meant to keep people from fat-fingering their address on an email signup form (think mailing list, not web app).

Mailgunner here. Perhaps we should have given it a different name? We do not guarantee that the address is valid. But we surely beat your regexp. Why?

Simply because we're an ESP and have a huge database of valid MX hosts and the most common misspellings for them that are NOT valid MX hosts. And we give you suggestions to implement autocompletion/autocorrection.

Besides, many of our customers reach out to our support asking for regexp suggestions. So we figured it would be cool to offer this to everyone for free, so we launched it.

Actually I think you've got the name spot on, I had the wrong term. What I was looking for was confirmation email, not validation.

And yes, your service is a pretty big step up from regular validation regexps. I didn't see the value in that before, but that's my own fault. I now see there's a lot of potential for a service like this, and I hope it's put to good use.

Even if it's just a regex, handling the fully-general case is surprisingly complex: http://stackoverflow.com/questions/201323/using-a-regular-ex...

This doesn't even count domain validation, what with new TLDs coming online constantly, etc.

I don't see how your reply addresses OP's point. Can you elaborate?