10

I'm writing a software which will be used mostly by companies.

I then had the idea to give companies a way to register their email domain so that every user which registers with an email of the given domain will be automatically put in the company group.

I know Slack does something like this and it works, but there are some problems... for example I've just registered "live.it" (the live.com italian version by Microsoft).

I can't just assume that if an user has validated an email with a specific domain then it's safe to put every user with the same domain_mail in the same group.

For example, if I register with me@gmail.com I don't want to let user register "gmail.com" has its own domain.

I'd like to avoid use of methods like "put an html file in the root of the domain" or "set a TXT record" so I was wondering how should I do.

  • 11
    Why asking to put a file in the root of the domain is a problem for you? Google Webmaster Tools does exactly that. Moreover, you don't need to ask for a permanent file: user puts it on the server, you do the check, and the file can be removed. – Arseni Mourzenko Sep 25 '14 at 12:47
  • 9
    If your setup is so wrong that users from outside cannot reach your main website, you should be concerned by the setup and blame your sysadmins, instead of being concerned by adding your site to Google Webmaster Tools and blame Google. – Arseni Mourzenko Sep 25 '14 at 12:51
  • 1
    Instead of giving them a way which works and which they already have used many times before? – Arseni Mourzenko Sep 25 '14 at 12:53
  • 6
    @FezVrasta: Keep in mind that you have two goals: allowing access to authorized users and denying access to unauthorized users. Making it easier for authorized users generally makes it easier for unauthorized users too. – MSalters Sep 25 '14 at 14:05
  • 4
    In case you go the DNS record route, you should probably use TXT records, not MX. – Aaron Dufour Sep 25 '14 at 22:15
19

File in root directory

Don't discard the possibility of putting a file in a root directory of the corporate website. It works well and is widely used: Google Webmaster Tools is one example of such technique. This makes this approach attractive: since most users already know it, they won't be lost. Also, it doesn't require any technical knowledge, unlike modifying MX records (most small companies won't even know what an MX record is).

In order to avoid polluting the root directory, you should ask to put a file only when doing your checks. Once you've found the file, the user may be able to remove it.

Note that users who don't have any corporate website won't be able to access your service, but I don't think there are many customers in this case.

Note that:

  • You should check for both http://example.com/file and http://www.example.com/file, because some websites are configured in a way they don't support http://example.com/ form.

  • You may support HTTPS as well, given that I don't think there are a lot of companies with no redirection from HTTP to HTTPS.

  • You should not accept any other third-level domains such as http://mysite.example.com/, because this will make it possible for someone who bought an third-level domains to claim that he's the owner of the second-level domain example.com.

Sending an e-mail

Sending an e-mail with secret link is rather problematic. You can't do it to firstname.lastname@example.com, because a given person may not have a corporate e-mail address (this is often the case of startups, where people prefer using their personal address).

Using e-mails such as admin@example.com will not work in some cases.

  • First, there are always companies not having postmaster@example.com, admin@example.com etc., but having their particular "system" e-mail addresses you haven't whitelisted. Consider specifically foreign companies; for example, in France, it is not unusual to use "Administrateur" instead of "Administrator", including for e-mail addresses and account names.

  • Second, many small companies don't access and don't know how to access their system e-mails. They pay not even know they have abuse@example.com with hundreds of urgent e-mails waiting for their reply.

    For the same reason, you can't base yourself on WHOIS records for e-mail address.

  • What about send validation emails to users like "info@", "administrator@" "postmaster@"? – Fez Vrasta Sep 25 '14 at 12:59
  • @FezVrasta - email addresses are incredibly easy to spoof. – Oded Sep 25 '14 at 13:04
  • I mean "I send an email to info@ with a confirmation link inside it" – Fez Vrasta Sep 25 '14 at 13:04
  • 6
    @FezVrasta - a domain may not have any email servers associated with it, and if it does, there is no guarantee that an info@ (or any local address) would be defined on it, or that it will have a monitored catch-all address. – Oded Sep 25 '14 at 13:06
  • 3
    "register their email domain so that every user which registers with an email of the given domain will be automatically put in the company group.". Sorry, but the question makes it clear that you can assume an email server. This alternative assumes a web server, which is not a given. – MSalters Sep 25 '14 at 14:07
17

The question is in effect: "What does it mean to own an email domain?".

Owning a website is defined by the ability to put a file in the root. Ordinary users may be able to put a file on http://example.com/~user42/validation.txt but not on http://example.com/validation.txt.

For email, there's no such hierarchy. However, the postmaster address is special. (Reserved per RFC2142) You won't be able to create postmaster@gmail.com. Thus, the ability to create and/or access postmaster@ is the proof you need for email domain ownership.

  • 1
    Is that specialness part of a spec, a common built-in component of email servers, or just a convention? – DougM Sep 25 '14 at 14:20
  • 8
    @DougM: Reserved per RFC 2142 – MSalters Sep 25 '14 at 14:21
  • Thank you, so an additional options would be the use of postmaster@, thanks – Fez Vrasta Sep 25 '14 at 14:41
  • 5
    @MSalters: You should put that RFC in your answer – Bergi Sep 25 '14 at 16:00
  • 1
    For many postmaster@domain simply doesn't go to the right person or anyone at all. While it technically might supposed to be a way to determine domain ownership you could not practically use this. – JamesRyan Sep 26 '14 at 10:14
9

Seeing in your comments that you might not prefer to use the file-in-root-of-website method, an alternative which might work is to

Verify ownership using WHOIS

You would need to get the domain being requested (for example stackexchange.com), and one of the emails listed in the WHOIS output for that domain. (Note that this won't work for secret/private registrations, but if your audience is corporations this usually isn't a problem)

For example:

WHOIS information for stackexchange.com:**
...
Domain Name: STACKEXCHANGE.COM 
Registrar WHOIS Server: whois.name.com 
Registrar URL: http://www.name.com 
Updated Date: 2014-05-14T16:49:02-06:00 

Registrant Name: Sysadmin Team 
...
Registrant Email: sysadmin-team@stackoverflow.com 
Admin Name: Sysadmin Team 
Admin Organization: Stack Exchange, Inc. 
...
Admin Email: sysadmin-team@stackoverflow.com 
Tech Name: Sysadmin Team 
...
Tech Email: sysadmin-team@stackoverflow.com 
Name Server: cf-dns02.stackexchange.com 
Name Server: cf-dns01.stackexchange.com 
DNSSEC: NotApplicable 

You could even do the whois lookup interactively and provide a dropdown list of the valid emails (in this case, just sysadmin-team@stackoverflow.com). You would then send a verification code/link to the chosen email.

  • This is what is done when validating certain ssl certs. Its likely not an automatic approach. But would make a good secondary option. – GrandmasterB Sep 25 '14 at 18:45
  • @GrandmasterB I don't see why it couldn't be automated: whois lookup, grep the emails, let the user choose one, send validation code in email. – Digital Chris Sep 25 '14 at 19:38
  • I've tested this way with two of my biggest customers and both have not a valid email in the whois (one has not emails, the other has the email of the tech support of the domain registrant... – Fez Vrasta Sep 26 '14 at 7:02
  • 1
    By the way this one could be added as an alternative. – Fez Vrasta Sep 26 '14 at 11:51
6

Ask your users to add a TXT record to their domain with a reference to their user account on your site (their username, ID, or an arbitrary token generated when asking the user to verify their domain).

I remember adding a record called adn_verification=<my user name> on a social network to display my domain as verified, and I thought that's pretty neat and doesn't require you to have the domain pointing to a web server.

  • A large part of the users won't know what TXT record is, and those who know won't necessarily be knowledgeable enough to set it. – Arseni Mourzenko Sep 25 '14 at 23:17
  • 1
    @MainMa it's still a good feature to implement. – user150273 Sep 26 '14 at 1:01
  • 1
    +1. Just because you have a domain, doesn't mean you have a web server running on it (although in this particular instance, a company will probably always have a website :)). – Matt Sep 26 '14 at 13:10
  • FWIW, this is the approach Microsoft uses if you want a custom domain for Office 365. – Casey Sep 26 '14 at 15:12
2

To add to the suggestions already on the page: I recommend to give the user options in how he validates his domain. The other suggestions on the page are all perfectly usable, but sometimes you are in the situation where someone who wants to verify their domain only has limited access to their server or even their website. For example, your user might not be able to add domain records or files in the domain root.

For example, Troy Hunt allows users to search for an entire domain in his database of compromised accounts, but you need to verify first. He gives the user the choice of 4 methods:

  1. Via email;
  2. through a meta tag;
  3. A file upload;
  4. a TXT record.

In all 4 of these cases, he requires the user to enter a specific value somewhere which he verifies against.

The explanation is at http://www.troyhunt.com/2014/01/im-pwned-youre-pwned-were-all-pwned.html.

  • thanks but how the email verification works? How can they prevent me from validate a "gmail.com" or "hotmail.com" domain? (or better, some unknow free webmail service). – Fez Vrasta Sep 26 '14 at 9:42
  • No matter what you do, unless you explicitly say "these addresses can NEVER be validated", the chance always exists that the webmail provider registers their own domain, and there's not much you can really do about it. The only thing you can do is prevent some domains from being validated entirely. You don't need to prevent validation of mailprovider.com, you just need to prevent that joe.shmuck@mailprovider.com manages to validate the entire mailprovider.com domain on his name. – Nzall Sep 26 '14 at 9:57
  • ok but I've not way to know if an email is part of a company or of a free webmail service. – Fez Vrasta Sep 26 '14 at 10:07
  • 1
    You'll have to maintain a whitelist for that, I'm afraid. another option is that every domain has to be approved by a human being. I know this makes it more troublesome for new applicants, but an approval only needs to happen once. Afterwards, you know that that domain is approved and not a free webmail service. – Nzall Sep 26 '14 at 10:11
0

Could you afford avoiding the use of free webmails for registration?

That's what Brium does: you can't sign-in with an @gmail.com, @live.com, etc e-mail - you have to use your own.

And it clusters you by this.

If you are targeting businesses, that should be a good way to go.

You could still have the problem of knowing who the boss is (say, the admin of that group), but it may not be that important - the boss should probably have the tools for telling any employee to transfer the ownership to him, provided someone registered before the boss.

  • 3
    How would you check that a domain is a free webmail? There are at least hundreds of them. – svick Sep 25 '14 at 16:58
  • I was writing the same thing :) – Fez Vrasta Sep 25 '14 at 16:58
  • Here's a not-so-active project that lists a bunch of them: github.com/tarr11/Webmail-Domains. Is it that critical having any of them slip? Is it not enough to cover the great majority of users (Gmail, Live, Yahoo, and the like)? I don't know what your software does, but - will it be useful for someone to try to avoid this limitation? Would the software be useful if he is alone in a group - or without his colleagues? – mgarciaisaia Sep 25 '14 at 17:45
  • It would allow a basic access to the informations uploaded to my software so having some unwanted user in the wrong group could cause problems. By the way it could be a solution because will be a problem of the owner of the data if he register a domain not own... I think – Fez Vrasta Sep 25 '14 at 17:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.