E-Mail Address Validation Reasoning Table

Evading Temporary E-Mail Address Rejection in Account Registration

Derek Callaway
Aug 8, 2017 · 6 min read

After spending some time rummaging through the “Hacktivity” pages on the bug bounty site HackerOne, I’ve noticed that on occasion some sites will reject the registration of accounts that are associated with temporary e-mail addresses. This is perfectly understandable, especially if it’s the type of site that needs to require both unique and legitimate PII (Personally Identifiable Information) because it’s offering a financial service, for example. The ability to create accounts with false registration info will facilitate the activities of attackers wishing to test the site’s behavior patterns. I’ve also noticed that there’s several ways to avoid such rejection and force the account registration function to be carried out regardless — in spite of the fact that it’s being registered with a temporary e-mail address.

Before proceeding, we need to declare some jargon that will be used throughout the remainder of this article which you’ll also see in the technical standards specification documents for e-mail. Fundamentally, e-mail addresses consist of three very easily distinguishable parts. There’s the case-sensitivelocal part” which is often simply called a user name. After that, is the “field separator” (a term used in computer science for parsers) or the at sign “@”. Finally, there’s the case-insensitivedomain”.

More specifically, the reason that such an account registration is being rejected is because the domain of the submitted e-mail address falls within a list of domains known to provide temporary e-mail address services or perhaps belong to spammers. However, the way the DNS domain name’s text is being matched against that list might not always cause the site to act how the developer originally intended it to. I’ll be detailing here several techniques I attempt when testing the data verification code executed by a web site’s account registration feature.

The first technique I’m going to present doesn’t often work, but due to its sheer simplicity it still deserves to be at the top of the list of things to try. Those of you that have read my blog article entitled “Leveraging Malicious DNS Records For The Subversion of Hardened Web Redirect Code” will already be familiar with this technique which takes advantage of FQDN (Fully Qualified Domain Name) notation. All you have to do is simply add a period after an e-mail address that would typically be rejected. For example, if “user@mailinator.com” should be rejected, then perhaps “user@mailinator.com.” will not. The reason this works is that appending a period to an e-mail address is syntax which doesn’t invalidate the address, yet the domain is no longer likely to match the list of known temporary e-mail address domains that it’s being compared against — even in a case-insensitive manner.

The next technique is much more likely than the first to actually work, but to understand why requires an understanding of the IN MX RR (Internet Mail Exchange Resource Record) in DNS. Mail exchange records essentially specify the host name at which a mail service daemon will be listening for connections that will be used to route incoming e-mail traffic. Take note that I stated “host name” because numeric IP addresses cannot be used in MX records. An understanding of wildcard DNS records is also helpful here. In the case of mailinator.com, I believe it has a wildcard MX record that looks something like the following:

* 1 IN MX test.mailinator.com.

The asterisk means match any host name under the mailinator.com domain and numeric value of 1 signifies the TTL (Time-To-Live.) The host name of test.mailinator.com. is the fully qualified host name of the actual mail exchanger where the Postfix software is listening for ESMTP (Extended Simple Mail Transfer Protocol) connections on TCP port number 25. In short, what all of this means is that the domain part of e-mail addresses can be almost arbitrary and Internetwork traffic containing e-mail will still be routed to the correct destination. For example, an account can probably be registered with an e-mail address of “user@test.mailinator.com” and it will reach the same inbox as messages destined for “user@mailinator.com”.

The commercial API for verifying addresses provided by block-disposable-email.com does not seem to fall for that trick, but this is no endorsement as such.

Something else that I test for is registering with one e-mail address and then attempting to change that address to something completely different. Of course, this is based on the fact that the server-side code responsible for the address change may not run data verification procedures that are identical to the account registration code. Be sure to take into account that there might be more than one code block being exposed via the user interface that has the ability to update the e-mail address column of the user table in the associated database. It’s worth noting that this issue is significantly less prevalent than the aforementioned sub-domain insertion issue permitted by wildcard MX records in DNS.

So far, I’ve only covered issues that occur in the syntax of an e-mail address domain — that’s about to change. If you were reading the first few paragraphs of this article carefully, then you would’ve taken notice that I put a few words in bold text which separated between the local part and domain being respectively case sensitive and insensitive. Why is this so important? It means that applications should not be treating addresses that have equivalent letters in their local part as identical e-mail addresses when the actually differ between upper and lower-case. For example, these are all individual inboxes:

jdoe@host.com

JDOE@host.com

JDoe@host.dom

The use of plus signs in email addresses is another syntactical discrepancy that can be introduced within the local part. According to the original RFC822 (published by my alma matter), anything after and including a plus sign in the local part is to be ignored. In other words, the e-mail addresses shown below all direct mail to the same inbox:

jdoe@host.com

jdoe+@host.com

jdoe+test@host.com

There’s also a technique known as “commenting”. Like the plus sign, this is another syntax variation (among several others that I can’t all cover here) that causes mail to be delivered to the same inbox. The only significant difference from the plus sign is that parenthesized comments will work in both the local part and/or the domain as specified by a rather interesting example in RFC2822 Appendix A.5. That means all of the e-mail addresses below will again deliver to the same inbox:

(this is the local part)jdoe@host.com

jdoe@(this is the domain)host.com

jdoe(local)@host.com

jdoe@host.com(domain)

jdoe(nested(comments))@host.com

jdoe(foo)@(bar)host.com(baz)

I’m going to conclude with the fact that one or more of the above techniques can be combined to produce more sophisticated attempts at evading a web application’s e-mail address verification code. There are going to be times when addresses that should have been marked valid were rejected. However, it’s much worse to accept an address that should have been rejected.

There are a variety of syntactical idiosyncrasies that can occur in the text representation of e-mail addresses (they can also be specified as URI’s using the mailto: scheme.) This StackExchange article is a deep-dive on the decision process that unfolded when a developer was considering whether or not to allow plus signs in the local part of an e-mail address. For more extensive coverage, I suggest referring to the Examples section of the Wikipedia article for Email address. For a full rundown including the official BNF parser rules, take some time out to review the entire specification in the IETF’s RFC document for Internet Message Format, although it covers more than just e-mail address formats. Regardless of what the specs say, the final parsing and validation decisions rest with the webmasters, application developers and system administrators for how to treat a given address.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade