rohannagar/jmail

A modern and lightweight library for working with email addresses in Java

jmail's Issues

E-Mail Address Validation on https://www.rohannagar.com/jmail/ broken

E-Mail Address Validation on https://www.rohannagar.com/jmail/ seems broken, even [email protected] gives The email address is invalid.

domain valition error while validating using mx records(JMail.validator().requireValidMXRecord();)

Is this bug report about an incorrectly validated email address?

• Yes

If yes, what is the email address?
[email protected]

• Invalid

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

Failure Reason incorrect

Is this bug report about an incorrectly validated email address?

• Yes
• No

If yes, what is the email address?
[email protected]

• Valid
• Invalid

Reason given for failure is incorrect. Reason should be DOMAIN_PART_ENDS_WITH_DASH but is ENDS_WITH_DOT.

Please either make EmailValidator immutable or support clone()

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?

Support for configuring non-ascii characters to be invalid

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

Option to validate MX record associated with email domains

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?

Make timeout configurable for DNS MX record lookup

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

Add ability to get the ASCII only version of an Email

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

bbottema/simple-java-mail#463

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.

Question: preceding zeros in IPv4 address

Is this bug report about an incorrectly validated email address?

• Yes
• No

If yes, what is the email address?

• Valid
• Invalid

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

Add documentation for all default validation rules

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?

Provide option to unquote localparts when normalising

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.

IPv4 validation allows non-standard digit characters

Is this bug report about an incorrectly validated email address?

• Yes
• No

If yes, what is the email address?

• Valid
• Invalid

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

Provide distinct failure reasons for each built-in rule and provide option for specifying custom failure reasons

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.

Does not work for email Ids containing spaces

Is this bug report about an incorrectly validated email address?

• [*] Yes
• No

If yes, what is the email address?
das-01 @ rediffmail.com

• Valid
• [*] Invalid

Add ValidationRule to disallow whitespace in the local-part and domain

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! 👍

invalid address returning true

Is this bug report about an incorrectly validated email address?

• Yes
• No

If yes, what is the email address?
agadgf@fsaf

• Valid
• Invalid

If no, please describe the bug
This returns true but should return false
ret = JMail.isValid("agadgf@fsaf");

Additional context

Validation reason is incorrectly called FAILED_CUSTOM_VALIDATION

Is this bug report about an incorrectly validated email address?

• Yes
• [ X ] No

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.

JMail does not handle quoted symbols

Is this bug report about an incorrectly validated email address?

• Yes
• No

If yes, what is the email address?

\@ in mymail\@[email protected] is valid

• Valid
• Invalid

If no, please describe the bug

Additional context

Valid email shown as invalid

Is this bug report about an incorrectly validated email address?

• Yes
• No

If yes, what is the email address?

12[e-mail]

• Valid
• Invalid

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

Add ifValid and ifValidOrElse methods to EmailValidationResult

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

Question: E-Mail Address with local part containing only slashes valid?

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.

IllegalArgumentException when validating email address ending with "High Octet Preset" control character

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.

When validation fails, provide a reason to the caller

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

Handle Quoted Identifier Emails

Is this bug report about an incorrectly validated email address?

• Yes
• No

If yes, what is the email address?

Joe Smith <[email protected]>

• Valid
• Invalid

If no, please describe the bug

Additional context

Add changelog file

Is there a changelog available? I'm not seeing a 'Wiki' page or other changelog page on the jmail github project or jmail site.

Improve email address normalization

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:

1. Make quote-stripping the default behavior, with an option to disable.
2. Lowercase all characters in the address by default. While technically email servers could treat the local-part of addresses as case-sensitive, this is not typical and not done by the major email servers (e.g. Gmail). Additionally, according to RFC Name servers and resolvers must compare [domains] in a case-insensitive manner. Add an option to disable.
3. Add an option to remove . (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.
4. Add an option to remove any sub-addressing or tagged-addressing. Many mail servers support adding to the end of the local-part a + 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

E-Mail address with local part containing CONTROL characters should be invalid

Is this bug report about an incorrectly validated email address?

• Yes

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!

Feature request: some sort of email normalization?

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

Create module-info.java for Java 9+ Projects

This library should be a module for projects that want to use it as one in Java 9+

Incorrect email

Is this bug report about an incorrectly validated email address?

• Yes
• No

If yes, what is the email address?
mymont@noыыыы

• Valid
• Invalid

If no, please describe the bug

Additional context

StringIndexOutOfBoundsException

• eMail [email protected] (MNO) is valid

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;

}
}

Improve website to describe what makes an email valid

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.

Support no service resource record for domains that accept no mail "Null MX"

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]

My valid emoji email address in the format xyz@🚀.kz is not tested valid

Is this bug report about an incorrectly validated email address?

• Yes
• No

If yes, what is the email address?
xyz@🚀.kz

• Valid
• Invalid

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

Empty quoted local-part should be valid

Is this bug report about an incorrectly validated email address?

• Yes
• No

If yes, what is the email address?

""@test.org

• Valid
• Invalid

If no, please describe the bug

Additional context

Include JAR files for download alongside GitHub Releases

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

Addressess with explicit source routing are not valid

Is this bug report about an incorrectly validated email address?

• Yes
• No

If yes, what is the email address?

@1st.relay,@2nd.relay:[email protected]

• Valid
• Invalid

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