bbottema / email-rfc2822-validator Goto Github PK
View Code? Open in Web Editor NEWThe world's only Java-based rfc2822-compliant email address validator and parser
The world's only Java-based rfc2822-compliant email address validator and parser
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:
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();
}
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.