Email Validation RFC 2821 using Java

Question

I am working on email Validation using java having RFC 2821 in mind. I have used following code to validate all my email address:

InternetAddress emailAddr = new InternetAddress(email);
emailAddr.validate();

Java api says its RFC-822 compliant. Is there a much difference between RFC 2821 and 822?

Also the above api is failing to validate email in below cases:

1. var@yahoo - validation returns true, but it is invalid email
2. var(comment)@yahoo.com - validation returns false, but it is valid email

Can you tell me any work around for this to get it done.

Answer 1

Looks to me that you want to validate email ids that are used nowadays and not really to be compliant to any RFC. For our project we made our own very simple email validator. Why ? The apache and java mail one use regex and there are some cases (I do not know which as we were not printing the email's in the log) that make regex go in to a forever loop. This means the client handler thread goes into a loop and the user sees a blank screen!

So what we do is essentially allow new email ids like they would look like at sites like google/ yahoo.

Meaning [email protected]

What we check for At most 1 @ Check for 1 or more chars before @ After @ have some chars + one dot atleast + chrs after dot

Did not get any complaints for the last two years. Also most of the times you need to send the person an email to make sure the domain exists etc and a link with a unique token (sign up confirm) to make sure the person owns the email id (with a message to real owner to only click if they came to your site)

    /**
     * minimum email [email protected]
     * */
    public static boolean checkEmail(final String emlId, int dbgPrint) {
        // ex:[email protected]
        if (emlId == null){
            return false;
        }
        final int lngth = emlId.length();
        if (lngth < 6) {
            if (dbgPrint > 1) {
                System.out.println(" lngth < 6");
            }
            return false;
        }
        final int locationAt = emlId.indexOf('@');
        if (locationAt < 1) {
            if (dbgPrint > 1) {
                System.out.println("locationAt < 1 : " + locationAt);
            }
            return false;//
        }
        final int postLastPeriod = emlId.lastIndexOf('.');
        if (postLastPeriod < 0) {
            if (dbgPrint > 1) {
                System.out.println("postLastPeriod < 0, locationAt " + locationAt);
            }
            return false;
        }
        if (dbgPrint > 1) {
            System.out.println(" locationAt " + locationAt + ", postLastPeriod :" + postLastPeriod + " lngth " + lngth);
        }
        if (lngth - postLastPeriod < 3) {
            if (dbgPrint > 1) {
                System.out.println(" lngth - postLastPeriod < 2");
            }
            return false;
        }
        if (postLastPeriod - locationAt < 1) {
            if (dbgPrint > 1) {
                System.out.println(" postLastPeriod - locationAt < 1");
            }
            return false;
        }
        return true;

    }

Answer 2

There are major differences between how modern e-mail addresses are handled vs the e-mail addresses in the original standards.

From what I've experienced setting up dns & bind addresses you can specify a domain name without a period, but when the resolver is queried it will add the . to the end of the domain name. You can also specify a straight mapping in a hosts file. Most hosts files contain resolve localhost like this:

127.0.0.1 localhost loopback

Meaning if you're on the server with the mail server you can send a valid e-mail to user@localhost.

According to RFC 822:

In the case of formal registration, an organization implements a (distributed) data base which provides an address-to-route mapping service for addresses of the form:

            [email protected]

Note that "organization" is a logical entity, separate from any particular communication network.

A mechanism for accessing "organization" is universally avail- able.
That mechanism, in turn, seeks an instantiation of the registry; its location is not indicated in the address specif- ication. It is assumed that the system which operates under the name "organization" knows how to find a subordinate regis- try. The registry will then use the "person" string to deter- mine where to send the mail specification.

The latter, network-oriented case permits simple, direct, attachment-related address specification, such as:

                 [email protected]

In the case of [email protected] on local systems as long as the email system is configured properly you can send emails to user@host. Even though this isn't the FQDN - Fully Qualified Domain Name that we're used to now, that standard didn't come around until much later. The mail system then uses the alias to send it to the correct local network translating the email to [email protected]. The problems with e-mail spoofing didn't come around until later when the ARPAnet became public.

About the comments in the address, that was not in RFC 822. According to the later email specification which allows comments (RFC 2822 Section 3.4):

Also, because some legacy implementations interpret the comment, comments generally SHOULD NOT be used in address fields to avoid confusing such implementations.

Meaning older systems do not allow comments in addresses. RFC 822 does not mention comments in the e-mail address.

The technical fix would be to not allow comments in the e-mail address unless you're accommodating them with custom code. You could always update Javamail. Newer implementations accommodate updated RFCs.