5

Is there a comprehensive way to test if two email addresses are equal? I know that I can universally LOWER both. But there are some other rules that differ from server to server. For example "william.burroughs@gmail.com", "will.iam.burroughs@gmail.com", and "williamburroughs@gmail.com" are all equivalent for gmail. But I don't think this is true in all cases. So given two email addresses I need to ensure they are equivalent. Currently my code does not consider "william.burroughs@gmail.com" and "williamburroughs@gmail.com" to be the same. I can start special casing something like "gmail" so they are but I was hoping there is a better approach.

robert_difalco
  • 4,821
  • 4
  • 36
  • 58
  • If gmail is the only provider that allows that, then you _will need_ a separate case unfortunately. – Joel Dec 17 '13 at 16:49
  • I would say that google is an exception. All other mail servers that are differnt email addresses. – rekire Dec 17 '13 at 16:49
  • Your case for gmail will be to ignore '.', other providers - don't ignore. – KevinDTimm Dec 17 '13 at 16:55
  • You can try something like [this](http://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-sending-an-email/) in addition to checking if the are valid/mostly equal. If one of the email addresses cannot be verified by the mail server, you know they are not equal. Not super helpful, but it can maybe help you determine which mail servers are special cases. – turbo Dec 17 '13 at 16:59
  • 1
    What do you mean with "equality"? If you mean messages sent to each address will reach the same mailbox, then you can't do it. – Ingo Dec 17 '13 at 17:04

4 Answers4

1

A part from a custom coded set of rules for given email providers (e.g gmail for your example) I don't think there is any other way...

Harry
  • 1,362
  • 12
  • 19
1

Gmail only really has two rules for customization

  1. Any periods ( . ) are ignored. This is easily overcome with a regex for gmail addresses.
  2. Anything after a + is ignored. Again. a regex will fix this for gmail addresses.

The biggest challenge as I see it is that Google hosts thousands of cloud based domains that do not end in googlemail.com or gmail.com. Your only way to recognize these would be to do a DNS lookup and see what MX record the domain points to. Here's a python example that works:

http://eran.sandler.co.il/2011/07/17/determine-if-an-email-address-is-gmail-or-hosted-gmail-google-apps-for-your-domain/

You could do the same in any other language. Look at the 'MX' record for gmail or googlemail.

For any non-google domains, you can do a lowercase string compare.

David S.
  • 6,567
  • 1
  • 25
  • 45
  • Not thrilled to except this answer as it just confirms my fears. Heh. But yeah, I think you are right. Unfortunately I have to process hundreds of thousands of users and checking this would be time prohibitive. – robert_difalco Dec 17 '13 at 17:07
  • 1
    You should add that the string compare can only establish that 2 addresses are equal. They can't establish that 2 addresses do not deliver to the same mailbox. So `xy@zzz.com` and `xavier.yuan@zzz.com` could still be "equal" in a sense. – Ingo Dec 17 '13 at 17:07
  • as these two rules does not come from Google, but from the mail protocol itself (Google is just the only (big) provider who implements this as i know ) - is it safe to match mail addresses from other providers also with these two rules, or are there providers, which give these mails with different "plus or dot separation" to different mailboxes / users ? – cyptus Dec 06 '17 at 07:56
1

If you're comparing 2 different e-mails addresses just as characters, you may want to consider using regex to split them up for comparisons. A simple enough one could work as "([\w\.]+)@([\w\.]+\.\w+)". You could run group 2 through a switch to compare group 1 appropriately, defaulting to a more general comparison.

boolean emailsEquals(String email1,String email2) {
    Pattern address=Pattern.compile("([\\w\\.]+)@([\\w\\.]+\\.\\w+)");
    Matcher match1=address.matcher(email1);
    Matcher match2=address.matcher(email2);
    if(!match1.find() || !match2.find()) return false; //Not an e-mail address? Already false
    if(!match1.group(2).equalsIgnoreCase(match2.group(2))) return false; //Not same serve? Already false
    switch(match1.group(2).toLowerCase()) {
    case "gmail.com":
        String gmail1=match1.group(1).replace(".", "");
        String gmail2=match2.group(1).replace(".", "");
        return gmail1.equalsIgnoreCase(gmail2);
    default: return match1.group(1).equalsIgnoreCase(match2.group(1));
    }
}

Hope it helps!

Fluxxdog
  • 11
  • 1
-2

Here this works but maybe I didnt understand your question

    String email1 = new String("william.burroughs@gmail.com");
    String email2 = new String("williamburroughs@gmail.com");

     Pattern emailFinder = Pattern.compile("gmail.com");
     Matcher emailmatcher = emailFinder.matcher(email1);
     Matcher emailmatcher1 = emailFinder.matcher(email2);
     if (emailmatcher.find() && emailmatcher1.find()) {

            email1 = email1.replaceAll(".","");
            email2 = email2.replaceAll(".","");

            if(email1.equals(email2)){
                System.out.println("The values match");
            }

     }
Joel
  • 4,732
  • 9
  • 39
  • 54
user2600629
  • 559
  • 6
  • 16
  • Apparently by gmail's conventions, string comparison is insufficient. This was stated pretty clearly in the question. – Joel Dec 17 '13 at 17:04
  • yeah I think I overlooked that – user2600629 Dec 17 '13 at 17:12
  • use of new String(""), x1.equals(s2) == true, bitwise And, and your variable names (starting with a capital letter) are all remarkably bad style. – Nathan Hughes Dec 17 '13 at 17:15
  • Can you go into more detail i dont understand Nathan? – user2600629 Dec 17 '13 at 17:18
  • 1) http://stackoverflow.com/questions/334518/java-strings-string-s-new-stringsilly 2) == true is redundant and useless because equals returns a boolean already 3) use && for booleans and 4) variables should start with lowercase letter. – Nathan Hughes Dec 17 '13 at 17:20
  • hope it helps. adhering to style conventions makes it easier for others to read your code. also & behaves differently from &&, && shortcircuits while & doesn't. – Nathan Hughes Dec 17 '13 at 17:25