Ask HN: How does Experian determine whether a given Gmail address exists?
To test this, I tested the result for a non-existing dummy address was 'invalid', then registered a gmail account with that dummy address, then re-checked the result to be 'valid'. As far as I could tell, there was nothing sent to the new account (so e.g. they aren't just checking for a bounce from a test email)
How can this work? This basically allows for user existence enumeration, which I would expect Google might frown upon. Reckon they are abusing some Google API in some way? (e.g. I'm having fuzzy thoughts about calendar invites, doc sharing, etc.) I am working under the assumption that they have special-cased detection for Google accounts; I haven't checked other email providers. Obviously their service could not possibly work in the general case.
10 comments
[ 3.1 ms ] story [ 32.9 ms ] threadThere are examples of successful and unsuccessful RCPT attempts here (scroll down to the second sample SMTP session):
https://en.wikipedia.org/wiki/List_of_SMTP_server_return_cod...
This is an entirely valid use of the SMTP protocol (getting back that status code is how you find out if a message to an address was undeliverable), but I suppose that if an e-mail provider wanted to prevent this kind of validation, they could stop accepting connections from subdomains of Experian that repeatedly aborted their SMTP sessions.
The setup behind it looks malicious. All of these reverse to subdomains of random, nonsensical two-word domains such as "motley-row.com" with no indication what-so-ever about the company behind it.
If they were operating a legitimate service I wonder why they go through all this trouble of obfuscation? Unless they're white-labelling some third-party service and that third-party might not only be used for legitimate purposes? I'd assume sysadmins might be more tolerating of these attempts if they were forthcoming about who they were and what their purpose was instead of looking like a black-hat scanner or spammer (in fact all these IPs are on spam blacklists already).
Hypothesis: thus, my valid e-mail address will be declared invalid.
Experimental result: Experian fucking lies!
I tried two addresses, a valid one and invalid. Their user interface claims that it was not able to determine the status because "[t]he request timed out due to the host domain not responding in time".
This is complete horseshit.
Both requests resulted in a prompt access to my mail server and a swift and clear SMTP rejection. Nothing timed out.
This one was rejected because the IP address is listed by Spamhaus:
This one was rejected by a rule of my own, "too many digits in domain name": Hiding the fact that their probe attempt was rejected due to looking like spam, by claiming that the request timed out, is egregiously dishonest. They are insinuating that they could validate an address in my domain, if only my domain would respond on time, covering up the fact that it did, and no they could not.I reported it as a bug once as its open to abuse but they came back and said its a feature.
There are different approaches. As a sibling comment mentioned, you can use any login protocol that responds with a different message for users vs. non-users.
Off the top of my head, you have POP, IMAP, SMTP, OAuth, Gmail's undocumented HTTP API, Gmail's documented HTTP API, and web scraping.
You probably can't do any of those at scale.
To solve the scale issue, you could buy databases of verified email addresses, which are not expensive. For any address found in those databases, you know it's registered.
If it's not in your database, you can do a live check.
Alternatively, you could make a business arrangement with Google, which is also possible for a company like Experian.