I'm a software engineer at Box who also enjoys traveling and exploring. I'm passionate about many things, and writing good code is just one of them! View my website and blog here.
Check out my most popular open source library, JMail.
A modern and lightweight library for working with email addresses in Java
Home Page: https://www.rohannagar.com/jmail
License: MIT License
Is this bug report about an incorrectly validated email address?
If yes, what is the email address?
[email protected]
If no, please describe the bug
Additional context
I have added JMail into my project And I have passed a email address ([email protected]) which I have validated in my project using ( JMail.validator().requireValidMXRecord(); ) is giving me out put false which means it is invalid .but while I am using (https://www.rohannagar.com/jmail/) it is showing it as valid email address
E-Mail Address Validation on https://www.rohannagar.com/jmail/ seems broken, even [email protected]
gives The email address is invalid.
Is this bug report about an incorrectly validated email address?
If no, please describe the bug
When validating an email address in the following manner, the validation failure message is incorrect:
String invalidDomain = "[email protected]";
var result = javaJMail.validator().requireOnlyTopLevelDomain(TopLevelDomain.DOT_COM).validate(invalidDomain);
This returns a FailureReason.FAILED_CUSTOM_VALIDATION
. There should be a failure reason to match the validation here done on this domain. Perhaps a FailureReason.INVALID_TOP_LEVEL_DONAIN
would be appropriate.
Additionally, if passing my.email@example
to the above validation, it still returns the FAILED_CUSTOM_VALIDATION
reason. However, there is already an existing "MISSING_TOP_LEVEL_DOMAIN" that should be used here instead when used in conjunction with the requireOnlyTopLevelDomain()
, as this implies that a TLD is required.
Finally, as a side thought on this, it would be nice to be able to add a custom failure reason, perhaps along with the custom validator?
public EmailValidator withRule(Predicate<Email> rule, String failureReason);
Then, instead of these predicates being stored as a Set
, they could be stored as a Map along with their failure reason.
E Error ABC.DEF@GHI. (MNO)
index 0,length 0
java.lang.StringIndexOutOfBoundsException: index 0,length 0
at java.base/java.lang.String.checkIndex(String.java:3278)
at java.base/java.lang.AbstractStringBuilder.charAt(AbstractStringBuilder.java:307)
at java.base/java.lang.StringBuilder.charAt(StringBuilder.java:85)
at com.sanctionco.jmail.JMail.internalTryParse(JMail.java:374)
at com.sanctionco.jmail.JMail.tryParse(JMail.java:100)
at com.sanctionco.jmail.JMail.isValid(JMail.java:67)
at de.fk.email.TestJMail1.isValid(TestJMail1.java:20)
at de.fk.email.TestJMail1.main(TestJMail1.java:10)
E Error [email protected] .
index 0,length 0
java.lang.StringIndexOutOfBoundsException: index 0,length 0
at java.base/java.lang.String.checkIndex(String.java:3278)
at java.base/java.lang.AbstractStringBuilder.charAt(AbstractStringBuilder.java:307)
at java.base/java.lang.StringBuilder.charAt(StringBuilder.java:85)
at com.sanctionco.jmail.JMail.internalTryParse(JMail.java:374)
at com.sanctionco.jmail.JMail.tryParse(JMail.java:100)
at com.sanctionco.jmail.JMail.isValid(JMail.java:67)
at de.fk.email.TestJMail1.isValid(TestJMail1.java:20)
at de.fk.email.TestJMail1.main(TestJMail1.java:11)
public class TestJMail1
{
public static void main( String[] args )
{
isValid( "[email protected] (MNO)" );
isValid( "ABC.DEF@GHI. (MNO)" );
isValid( "[email protected] . " );
System.exit( 0 );
}
private static boolean isValid( String pInput )
{
try
{
if ( JMail.isValid( pInput ) )
{
System.out.println( "+ eMail " + pInput + " is valid" );
return true;
}
System.out.println( "- eMail " + pInput + " is not valid" );
}
catch ( Exception err_inst )
{
System.out.println( "\n\nE Error " + pInput );
System.out.println( err_inst.getMessage() );
err_inst.printStackTrace( System.out );
System.out.println( "\n" );
}
return false;
}
}
Is this bug report about an incorrectly validated email address?
If yes, what is the email address?
If no, please describe the bug
Let's consider something like:
InternetProtocolAddress.validateIpv4("1২7.0.0.1");
and it validates successfully. Looks like java is more lenient when it comes to numbers than I thought: invoking Integer.parseInt("1২7")
returns 127
( ২
is 2
in Bengali).
I suppose this example should not be considered a valid ipv4 (actually it affects ipv6 too) address?
Additional context
If a quoted localpart only contains a string that would be valid as an unquoted localpart, it would be useful to have an option to have normalisation return the localpart unquoted e.g. with the option enabled:
"test.1"@example.org
would normalise to [email protected]
"test..1"@example.org
would remain as "test..1"@example.org
(because consecutive .
can only appear in a quoted localpart)
The use case for this is detecting duplicate email addresses.
Is this bug report about an incorrectly validated email address?
If yes, what is the email address?
[email protected]
Reason given for failure is incorrect. Reason should be DOMAIN_PART_ENDS_WITH_DASH
but is ENDS_WITH_DOT
.
Is this bug report about an incorrectly validated email address?
If yes, what is the email address?
das-01 @ rediffmail.com
Is this bug report about an incorrectly validated email address?
If yes, what is the email address?
xyz@🚀.kz
If no, please describe the bug
Additional context
See also mailoji.com
And yes, as a tester I use my email address in this format purely to annoy companies that like to have my email address for no reason 😃.
Please describe the feature that you are requesting
Emails with a no service resource MX record (https://datatracker.ietf.org/doc/html/rfc7505) should be validated as false. for example [email protected]
Please describe the feature that you are requesting
Some email addresses have internationalized domain names. Mail servers are supposed to handle these by converting them to their ASCII equivalent, but some old mail servers may not be doing this. Therefore, it would be helpful if JMail can provide a way to get the ASCII equivalent email address of a parsed email address.
The goal is to create a method on the Email object that would return an ASCII/UTF8 only version, like so:
Email parsed = JMail.validator().tryParse("test@faß.de").get();
String asciiOnly = parsed.toAscii();
Additional context
https://gist.github.com/JamesBoon/feeb7428b3558d581c0459f7302bd9a5
Note that the IDN.toAscii()
method uses an out of date standard, IDNA2003. We need to implement the latest standard, INDA2008.
Hey Rohan,
In Simple Java Mail I started replacing the email library with JMail, but I noticed one principle that Simple Java Mail relies on that is not possible with JMail: the guarantee that once a value is passed in, it cannot change after that. And as a general principle, I think this important to have in any software design. To support my point I would like to remind you that many code checkers like Spotbugs (FindBugs)/Sonar etc. also complain if you just pass in say an array that can be mutated outside of the method it is passed in.
Would you please make EmailValidator
either immutable (the fluent/builder api returns a new instance on each call) or supporting clone()
so I can clone it in my own api?
Is this bug report about an incorrectly validated email address?
If yes, what is the email address?
1234567890123456789012345678901234567890123456789012345678901234+x@example.com
If no, please describe the bug
Additional context
I found the list from here
https://docs.blackberry.com/en/id-comm-collab/blackberry-athoc/blackberry-athoc/7_9/create-publish-alerts/email-format-validation/valid-email-address-examples
Is this bug report about an incorrectly validated email address?
If yes, what is the email address?
agadgf@fsaf
If no, please describe the bug
This returns true but should return false
ret = JMail.isValid("agadgf@fsaf");
Additional context
Is this bug report about an incorrectly validated email address?
If yes, what is the email address?
Joe Smith <[email protected]>
If no, please describe the bug
Additional context
Is this bug report about an incorrectly validated email address?
If yes, what is the email address?
If no, please describe the bug
Should e.g. 0127.0.0.1
be considered a valid address? Or even 0000000127.0.0.1
? Now it validates correctly - what do you think?
Additional context
Please describe the feature that you are requesting
It would be nice to be able to use JMail like the following:
String emailStr = "[email protected]";
JMail.validate(emailStr).ifValid(email -> {});
JMail.validate(emailStr).ifValidOrElse(email -> {}, failureReason -> {});
Additional context
Given the quite loose definition of the email standard forms, it could be useful to provide some sort of normalization of the Email object, to render it in a way that most people commonly recognize as a plain and bare email address.
That would be equivalent to stripping comments, optional parts, etc.:
email.localPartWithoutComments() + "@" + email.domainWithoutComments()
.
This feature could be useful for example when we not only want to validate the address as a mail recipient, but use it as some sort of identifier (for example in login systems).
Is there a changelog available? I'm not seeing a 'Wiki' page or other changelog page on the jmail github project or jmail site.
[An enhancement, not a bug]
Whenever an email fails to pass validation, no information is provided to the caller about what the problem was. Was there an invalid character in the domain? Were there multiple "@" characters? Was the "@" character missing? Was there no ending domain (part after the last dot?). Something else?
I recommend adding some way for the caller to get back a string that describes the problem. These descriptions are mostly available in the code in the form of comments ("email cannot be more than 320 chars", "email cannot start with '.'", "email cannot end with '.' or '-'", etc.) but not available to the caller. Ideally the descriptions would be understandable to a naive end user.
In comparison, https://github.com/lite2073/email-validator does a MUCH better job of providing a description of the exact cause of the problem, but that project is getting a bit stale.
There are 2 obscure extra properties that control the initial timeout and retries in JNDI.
com.sun.jndi.dns.timeout.initial
- the default is 1000
(ms)com.sun.jndi.dns.timeout.retries
- the default is 4
These go in the env
Hashtable passed to InitialDirContext
.
Currently, checking if an MX record exists for a domain like coolio.com
is super bad for performance. Since user input cannot be trusted, perhaps this could be configurable.
Awesome lib, btw. 💯
What a nice library you made, congratulations! I was wondering, what about adding an option to check that email domains have a valid MX record: at least one DNS record with an IP address?
This library is great! I would very much like to use it in a project I'm working on but I can't find any documentation that spells out each of the validation rules that it enforces. Do you have a list somewhere that I just missed?
Please describe the feature that you are requesting
I'd really like to use this library but the way I've imported other libraries to my project is by pasting in the .jar files
I'm not using Maven to build it, so the current "Installation" section for JMail doesn't work for me
Would it be possible to share the JAR files for running this?
Apologies if this is a silly question or if I'm missing something obvious, and/or there's another way to go about importing this library without needing JAR files
Additional context
I'm using Java 11, IDE is NetBeans 13, Apache Ant to build
Using JMail 1.3.2
to validate an email address ending with a "High Octet Preset" control character, e.g. JMail.isValid("[email protected]\u0081");
fails with:
java.lang.IllegalArgumentException: java.text.ParseException: A prohibited code point was found in the inputcom�
at java.base/java.net.IDN.toASCIIInternal(IDN.java:275)
at java.base/java.net.IDN.toASCII(IDN.java:123)
at com.sanctionco.jmail.JMail.isValidIdn(JMail.java:512)
at com.sanctionco.jmail.JMail.lambda$tryParse$0(JMail.java:119)
at java.base/java.util.Optional.filter(Optional.java:218)
at com.sanctionco.jmail.JMail.tryParse(JMail.java:119)
at com.sanctionco.jmail.JMail.isValid(JMail.java:67)
Caused by: java.text.ParseException: A prohibited code point was found in the inputcom�
at java.base/jdk.internal.icu.text.StringPrep.prepare(StringPrep.java:448)
at java.base/java.net.IDN.toASCIIInternal(IDN.java:273)
... 74 more
I guess that is not the expected behavior, or am I wrong?
By the way: Thank you very much for developing JMail! It is the best Java E-Mail validation library.
Based on a suggestion from Reddit:
This is actually cool stuff, if you add more logic to it and explanations - why an address is invalid. Needs more work but could be turn into a pretty great site/service.
Please describe the feature that you are requesting
Currently, calling the normalized()
method on an Email
object will return the address without any comments. Version 1.6 introduced the option to strip quotes if the address will still be valid after removal.
There are other things that would make the user experience much better. This feature is more suited for a major version upgrade so that defaults can be adjusted.
Improvements:
Name servers and resolvers must compare [domains] in a case-insensitive manner
. Add an option to disable..
(dot) characters from the local-part. Gmail allows any number of dot .
characters in the local-part of the address. Technically we could also have two .
(dot) characters in a row in the local-part for Gmail addresses. As an aside, an option could be added to the base JMail validation to allow two (or more) dots in a row.+
sign (or in rare cases a -
sign, or even more rare an arbitrary character), followed by characters, and the mail will be sent to the same address. Normalization should be able to optionally remove these, and users should be able to specify the separator character.Additional context
https://stackoverflow.com/a/9808332
https://support.google.com/mail/answer/7436150
https://en.wikipedia.org/wiki/Email_address#Sub-addressing
Library with interesting features: https://github.com/afair/email_address
Is this bug report about an incorrectly validated email address?
If yes, what is the email address?
\@
in mymail\@[email protected]
is valid
If no, please describe the bug
Additional context
Enhance JMail's email validation by providing specific failure reasons for each built-in rule, rather than using a generic CUSTOM_RULE_FAILURE message for all rule violations.
Is [email protected]
a valid e-mail address?
JMail says it is valid, but both Postfix
and Apache James
reject it. Resulting in:
javax.mail.SendFailedException: Invalid Addresses;
nested exception is:
com.sun.mail.smtp.SMTPAddressFailedException: 501 5.1.3 Bad recipient address syntax
at com.sun.mail.smtp.SMTPTransport.rcptTo(SMTPTransport.java:2064)
at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:1286)
when I use Java Mail to try to deliver it to these e-mail servers.
By the way: Thank you very much for providing JMail.
Is this bug report about an incorrectly validated email address?
If yes, what is the email address?
firstname_lastname\[email protected]
I maybe wrong but I think that RFC 822 disallows control characters in email addresses. Do newer RFCs allow them?
Sorry for using an issue for a question and thank you very much for providing JMail!
Please describe the feature that you are requesting
It seems to me that email servers / SMTP servers often (normally?) do not support non-ascii characters in local part or domain, even in countries where it is common with non-ascii characters in names (such as æ, ø, å in Norway).
It would be really nice with a feature for configuring non-ascii characters not to be valid.
E. g., "jø[email protected]" should fail.
Additional context
Is this bug report about an incorrectly validated email address?
If yes, what is the email address?
""@test.org
If no, please describe the bug
Additional context
Is this bug report about an incorrectly validated email address?
If yes, what is the email address?
@1st.relay,@2nd.relay:[email protected]
If no, please describe the bug
Address syntax
https://datatracker.ietf.org/doc/html/rfc822#section-6.1
Example of such address with explicit routes
https://datatracker.ietf.org/doc/html/rfc1711#section-7
Additional context
Not sure if this was superseded by newer RFCs
Using JMail 1.4.0
this test passes:
@Test
void test() {
assertTrue(JMail.isValid("a@b .com"));
assertTrue(JMail.isValid("a. [email protected]"));
}
Are these valid email addresses?
The first one lead to a javax.mail.internet.AddressException: Domain contains control or whitespace in string ''a@b .com''
when I try to use it with java mail.
By the way: Thank you very much for providing JMail. It is the best java libary to validate e-mail adresses! 👍
Is this bug report about an incorrectly validated email address?
If yes, what is the email address?
mymont@noыыыы
If no, please describe the bug
Additional context
This library should be a module for projects that want to use it as one in Java 9+
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.