bbottema / email-rfc2822-validator Goto Github PK

I get the error The prefix "Xlint" for element "Xlint:all" is not bound. while building with Gradle 6.1.1 and Android Gradle Plugin 3.6.1. To reproduce, create a new project in Android Studio and add implementation 'com.github.bbottema:emailaddress-rfc2822:2.1.4' to the app-level build.gradle. The project syncs, but does not build. The error occurs during the build process.

Here's what I have in my build.gradle:

apply plugin: 'com.android.application'

android {
    compileSdkVersion 29
    buildToolsVersion "30.0.0"

    defaultConfig {
        applicationId "com.example.myapplication"
        minSdkVersion 16
        targetSdkVersion 29
        versionCode 1
        versionName "1.0"

        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    implementation fileTree(dir: "libs", include: ["*.jar"])
    implementation 'androidx.appcompat:appcompat:1.1.0'
    implementation 'androidx.constraintlayout:constraintlayout:1.1.3'
    testImplementation 'junit:junit:4.12'
    androidTestImplementation 'androidx.test.ext:junit:1.1.1'
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.2.0'
    implementation 'com.github.bbottema:emailaddress-rfc2822:2.1.4'

}

We've long known that regex-based email validation is far from ideal. It is difficult to implement and maintain correctly, error-prone and not necessarily performant.

EmailValidator4J seems to implement a proper lexer to parse the RFC vocabulary. Perhaps it is time to deprecate email-rfc2822-validator in favor of EmailValidator4J. It seems to support the newer RFC's as well, including 5322 which updates and superseeds the older 2822 (supported by email-rfc2822-validator).

I can't say anything about the quality of EmailValidator4J (does it implement the RFC properly) or how flexible EmailValidator4J is (can you validate in varying degrees of compliancy, as we can with email-rfc2822-validator?) So we need to do some investigation into this.

Can we finally put regex email validation in Java to rest? @lhazlewood @chconnor

From bbottema/simple-java-mail#32

Version: 2.1

Issue: The Email validation goes into an infinite loop while trying to build the pattern matcher for the following email address: ewiuhdghiufduhdvjhbajbkerwukhgjhvxbhvbsejskuadukfhgskjebf@gmail.net (Obviously a random test case but, the behavior is surprising)

Trace: EmailValidationUtil line: 55

Version: 3.0 worked (this maybe due to the default behavior to skip the validator)

With the original Les version, there was a big performance issue (bbottema/simple-java-mail#3) where some addresses would make the regex parser freeze and blow up the server.

The below address should be parsed without issues, if this library is to have any merit in production-like environments:

[email protected]

Surrounding quotes (") in local part are removed when parsing to an instance of javax.mail.internet.InternetAddress. Found no EmailAddressCriteria that might avoid this behaviour.

Is it removed by intention? Removing unnecessary quotes from personal part makes sense, but dropping from local part results in a different E-Mail address.

var address = EmailAddressParser.getInternetAddress(
    "\"Bob\" <[email protected]>", DEFAULT, /* cfws */ true);
System.out.println(l.getAddress());

results in Bob, not the expected [email protected]. This means if the personal name is not provided then the email is null, which is what caused my code to NPE unexpectedly :)

The library doesn't validate email addresses that contain international domain names

How to parse following address for example?

"ßoµ" <[email protected]>

Current version throws exception while parsing above email address.

And EmailAddressParser.getAddressParts returns null

Published JARs for versions 2.2.0 and 2.3.0 have an invalid module name in MANIFEST.MF.

Both contain this line:

Automatic-Module-Name: emailaddress-rfc2822

Because it contains a - character, it is not a valid identifier. Running jar --describe-module --file emailaddress-rfc2822-2.2.0.jar gives output:

Unable to derive module descriptor for: emailaddress-rfc2822-2.2.0.jar
Automatic-Module-Name: emailaddress-rfc2822: Invalid module name: 'emailaddress-rfc2822' is not a Java identifier

After updating from 1.1.3 to 2.1.3 it is no longer possible to pass null to EmailAddressValidator.isValid(String):

java.lang.IllegalArgumentException: Implicit NotNull argument 0 of org/hazlewood/connor/bottema/emailaddress/EmailAddressValidator.isValid must not be null
	at org.hazlewood.connor.bottema.emailaddress.EmailAddressValidator.isValid(EmailAddressValidator.java)

I guess this is not intended because EmailAddressValidator.isValid(String, EnumSet<EmailAddressCriteria) still allows null for the first parameter, but isValid and isValidStrict do not.

The email validation doesn't use or need Jakarta.mail.

I know there is a convenient parser but I would either move that parser to a separate maven module or just make jakarta.mail
as <optional>true</optional>.

Also slf4j is not used anywhere that I could tell in src/main/java.

I assume it was or is used in src/test/java. Regardless I wouldn't expect a validation library to use or need logging.

(copy of: bbottema/simple-java-mail#31).

bbottema/simple-java-mail@8370db1#commitcomment-16375443

The following javadoc and code show what the default email validation strictness is set to:

    /**
     * The default setting is not strictly 2822 compliant. For example, it does not include the {@link #ALLOW_DOMAIN_LITERALS} criteria, which results in
     * exclusions on single domains.
     * <p>
     * Included in the defaults are: <ul> <li>{@link #ALLOW_QUOTED_IDENTIFIERS}</li> <li>{@link #ALLOW_PARENS_IN_LOCALPART}</li> </ul>
     */
    public static final EnumSet<EmailAddressCriteria> DEFAULT = of(ALLOW_DOMAIN_LITERALS);

However, I'm not sure what actually should be the default. Do we even need a default? What is its purpose?

Initially I thought a more strict-than-RFC-compliant default would be needed to make sure main stream services and servers can handle the more mundane email strings, rather than the exotic strings the RFC would allow.

What should be the default?

Hello! I wrote my own Java email address validation library, JMail, and I wanted to compare it to other implementations (including this one) to see how it stood up.

I tested a wide variety of email addresses using this library with the following line of code:

EmailAddressValidator.isValid(s, EmailAddressCriteria.RFC_COMPLIANT);

During this comparison I found some correctness issues with this library, as you can see on the table at this website: https://www.rohannagar.com/jmail/

For example, Joe Smith is considered valid with this library. Similarly, domain parts that start or end with the - character are considered valid when they should not be.

I wanted to bring this to your attention so you could potentially make any fixes or improvements, or maybe you can point out something wrong in my interpretation of the RFCs 🙂

Hello,
Based on the documentation I get the below JUnit failures when I would actually expect these tests to pass.

Attached you find a simple java maven project to replicate the above Junit test failures. My understanding is that I followed the documentation and, as per the documented examples, the JUnit tests should pass, however they all fail.

email-rfc2822-validator-junit-examples-fail.zip

How these tests should be modified in order to pass?

I tried the library on many mail addresses without problems but =?UTF-8?Q?Gesellschaft_f=C3=BCr_Freiheitsrechte_e=2EV=2E?= <[email protected]> seems to confuse EmailAddressParser. I have no if it is valid w.r.t. rfc2822, however..

Running a migration of and a user had registered with the domain pg&e.com. This passed my scrubbing using isValid(email) but failed during digestion due to json schema validator rejecting it. Switching to isValid(email, EmailAddressCriteria.DEFAULT) rejects the address as well. Skimming over the RFC I couldn't tell if this was allowed and why & was accepted.

The project is difficult to use since you use those proprietary @nonnull etc. annotations. Can you just remove them? Same goes for the findbugs/spotbugs import... It is fine to run it inside maven but to have such an import makes it difficult to use the lib at all (since though its transitive dependencies lots of others stuff is coming along and we need to really take care what is going into a project and what not...

I already did this once for simple-java-mail based on the original Les version, but with this successor I again want to separate the runtime configuration from the compiletime regular expression checks, so that the use of this class become more flexible.

For simple-java-mail I did this, so that the smtp library could perform the validation checks while the end-user was able to provide some critera config object to suit his needs.

When adding at attachment from a URL source (e.g. a pdf on S3) the name of the attachment is not honored. Instead of the specified name, the file name of the resource is used. The workaround is simple - wrap using a named datasource. Something simple like the following worked for me,

private static final class NamedDataSource implements DataSource {
  private final DataSource delegate;
  private final String name;

  NamedDataSource(String name, DataSource delegate) {
    this.delegate = requireNonNull(delegate);
    this.name = requireNonNull(name);
  }

  @Override public String getName() {
    return name;
  }
  @Override public String getContentType() {
    return delegate.getContentType();
  }
  @Override public InputStream getInputStream() throws IOException {
    return delegate.getInputStream();
  }
  @Override public OutputStream getOutputStream() throws IOException {
    return delegate.getOutputStream();
  }
}

• Java 1.6 is barely used anymore and officially not supported anymore. Time to upgrade.
• Javax Mail is also archived in favor of its successor Jakarta Mail. jakarta.mail:1.6.3 contains exactly the same as javax.mail:1.6.2 so it's a safe switch.
• Furthermore the static code analyses can be improved by applying @nullability annotations.
• Next, nowadays I automated releases to OSS Sonatype and subsequently Maven Central using CircleCI. This project can easily be upgraded for this.
• Finally, FindBugs is archived as well in favor of its active successor, SpotBugs. Time to upgrade that as well.