Code Monkey home page Code Monkey logo

email-rfc2822-validator's People

Contributors

bbottema avatar chconnor avatar ebeeson avatar pascalschumacher avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

email-rfc2822-validator's Issues

The prefix "Xlint" for element "Xlint:all" is not bound.

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'

}

Investigate and possibly deprecate email-rfc2822-validator in favor of EmailValidator4J

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

`"atest"@example.com´ is parsed to `[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.

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

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

IllegalArgumentException when passing null to EmailAddressValidator.isValid(String)

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.

Consider making jakarata.mail as optional and make slf4j as scope test

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.

Javadoc regarding default setting for email validation contradicting code, but what it should be

(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?

Incorrect validation for a variety of emails

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 🙂

Brackets and Parens not parsed properly and API documentation / usage needs improvement

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

image

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?

RFC: is & valid in a domain?

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.

Remove proprietary annotations

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...

URLDataSource uses source data name

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();
  }
}

Update project to Java 1.7 and Jakarta Mail

  • 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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.