Giter Site home page Giter Site logo

rohannagar / jmail Goto Github PK

View Code? Open in Web Editor NEW
107.0 4.0 6.0 644 KB

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

Home Page: https://www.rohannagar.com/jmail

License: MIT License

Java 100.00%
java email validation emails library fast modern valid ip ipv6

jmail's Introduction

JMail

Maven Central Javadoc Coverage Status

A modern, fast, zero-dependency library for working with email addresses and performing email address validation in Java.

Built for Java 8 and up.

Try out the algorithm online!

Why JMail?InstallationUsageIP ValidationContributing

Why JMail?

JMail was built mainly because I wanted to tackle the complex problem of email address validation without using Regex. Along the way, JMail became a much better choice than other Java email validation libraries (such as Apache Commons Validator or Jakarta (Javax) Mail Validation) for the following reasons:

  1. JMail is more correct than other libraries. For example, both Apache Commons and Jakarta Mail consider first@[email protected] as a valid email address! It clearly is not, as it has two @ characters. JMail correctly considers this address invalid. You can see a full comparison of correctness and try it out for yourself online.

  2. JMail is faster than other libraries by, on average, at least 2x, thanks in part to lack of regex.

  3. JMail has zero dependencies and is very lightweight.

  4. JMail is modern. It is built for Java 8+, and provides many useful methods and data accessors.

Click here for a full report of the differences in correctness and speed between JMail and other libraries.

While JMail is more correct than other libraries, I cannot guarantee that it is 100% correct. Email RFCs are long and complex, and I have likely missed some specific details. Please open an issue if you find an incorrect validation result for a specific email (or even better, a pull request with a fix).

I also highly recommend that you send verification emails to user-provided email addresses. This is the only way to ensure that the email address exists and that the recipient wants that email address to be used.

Installation

Add this library as a dependency in your pom.xml:

<dependency>
  <groupId>com.sanctionco.jmail</groupId>
  <artifactId>jmail</artifactId>
  <version>1.6.2</version>
</dependency>

Or in your build.gradle:

implementation 'com.sanctionco.jmail:jmail:1.6.2'

Usage

Standard Email Validation

To perform standard email validation, use the static methods available in JMail. For example, to test validation:

String email = "[email protected]";

if (JMail.isValid(email)) {
  // Work with your email string
}

Or to enforce validation, throwing an InvalidEmailException on failure:

String email = "[email protected]";

try {
  JMail.enforceValid(email);
  
  // Work with your email string
} catch (InvalidEmailException) {
  // Handle invalid email
}

You can also retrieve the reason for validation failure with the validate method:

String email = "[email protected]"

EmailValidationResult result = JMail.validate(email);

if (result.isSuccess()) {
  // Use the email address
} else {
  FailureReason reason = result.getFailureReason();

  logger.error("Validating email address failed with reason: " + reason);
}

Custom Email Validation

JMail also provides an EmailValidator class that allows for much more customization of what constitutes a valid email address. You can require additional common validation rules, or supply your own. For example:

// In general, you should use JMail.strictValidator()
EmailValidator validator = JMail.strictValidator()
    // Require that the top-level-domain is ".com"
    .requireOnlyTopLevelDomains(TopLevelDomain.DOT_COM)
    // Require that the local-part starts with "allowed"
    .withRule(email -> email.localPart().startsWith("allowed"));

boolean valid = validator.isValid("[email protected]");
boolean invalidWithoutTld = validator.isValid("allowed@test");
boolean invalidWithoutDotCom = validator.isValid("[email protected]");
boolean invalidWithoutAllowed = validator.isValid("[email protected]");

The Email Object

JMail also includes an Email object that makes working with email addresses easier. The Email object has the following properties:

Property getter Description Example using test(hello)@(world)example.one.com
localPart() The local-part of the email address test(hello)
localPartWithoutComments() The local-part of the email address without comments test
domain() The domain of the email address (world)example.one.com
domainWithoutComments() The domain of the email address without comments example.one.com
domainParts() A list of the parts of the domain [example, one, com]
identifier() The identifier of the email address, if it has one. null
(For Admin <[email protected]>, it would be Admin)
comments() A list of the comments in the email address [hello, world]
explicitSourceRoutes() A list of explicit source routes in the address, if present []
(For @1st.relay,@2nd.relay:[email protected], it would be [1st.relay, 2nd.relay])
isIpAddress() Whether the domain is an IP address false
containsWhitespace() Whether the address contains obsolete whitespace false
isAscii() Whether the address contains only ASCII characters true
hasIdentifier() Whether the address has an identifier false
topLevelDomain() The TopLevelDomain of the email address, or TopLevelDomain.OTHER if it is unknown TopLevelDomain.DOT_COM

To create a new instance of Email from a string, use the tryParse(String email) method, either the default version or on your own EmailValidator instance:

Optional<Email> parsed = JMail.tryParse("[email protected]");

Optional<Email> parsed = JMail.validator()
    .disallowIpDomain()
    .tryParse("[email protected]");

Since tryParse(String email) returns an Optional<Email>, you can do some cool things, such as:

Use a default email address

String email = JMail.tryParse("invalidEmailString")
    .map(Email::toString)
    .orElse("[email protected]");

Send an email if the address is valid

JMail.tryParse("[email protected]")
    .ifPresentOrElse(
        email -> myEmailService.sendTo(email.toString()),
        () -> log.error("Could not send email to invalid email"));

Get a normalized version of the email address

// Get a normalized email address without any comments
Optional<String> normalized = JMail.tryParse("admin(comment)@mysite.org")
    .map(Email::normalized);

// normalized == Optional.of("[email protected]")
// Get a normalized email address and strip quotes if the address would
// still be valid
Optional<String> normalized = JMail.tryParse("\"test.1\"@mysite.org")
        .map(e -> e.normalized(true));

// normalized == Optional.of("[email protected]")

Note: You can also set the -Djmail.normalize.strip.quotes=true JVM property to strip quotes when calling normalized() without parameters.

Additional Validation Rules

Disallow IP Address Domain

Although an email with an IP address in the domain is valid, these email addresses are often rejected from mail servers or only used for spam. You can require that your EmailValidator reject all emails with an IP address in the domain:

JMail.validator().disallowIpDomain();

Note: JMail.strictValidator() includes this rule automatically.

Require a Top Level Domain

Although an email address can be a local domain name with no TLD, ICANN highly discourages dotless email addresses. You can require that your EmailValidator reject all emails without a TLD:

JMail.validator().requireTopLevelDomain();

Note: JMail.strictValidator() includes this rule automatically.

Disallow Explicit Source Routing

Explicit source routing has been deprecated as of RFC 5321 and you SHOULD NOT use explicit source routing except under unusual circumstances.

JMail.validator().disallowExplicitSourceRouting();

Note: JMail.strictValidator() includes this rule automatically.

Disallow Reserved Domains

As specified in RFC 2606, some domains are reserved and should not be resolvable. Mail addressed to mailboxes in those reserved domains (and their subdomains) should be non-deliverable. You can require that your EmailValidator reject all emails that have a reserved domain:

JMail.validator().disallowReservedDomains();

Disallow Quoted Identifiers

If you want email addresses to only be the raw email address, use this rule. Adding this will invalidate addresses of the form John Smith <[email protected]>.

JMail.validator().disallowQuotedIdentifiers();

Require a specific common Top Level Domain

You can require that your EmailValidator reject all emails that have a top-level domain other than the ones you specify:

JMail.validator().requireOnlyTopLevelDomains(TopLevelDomain.DOT_COM);
JMail.validator().requireOnlyTopLevelDomains(
    TopLevelDomain.DOT_NET, TopLevelDomain.DOT_EDU);

Disallow Obsolete Whitespace

Whitespace (spaces, newlines, and carriage returns) is by default allowed between dot-separated parts of the local-part and domain since RFC 822. However, this whitespace is considered obsolete since RFC 2822.

You can require that your EmailValidator reject all emails that have obsolete whitespace.

JMail.validator().disallowObsoleteWhitespace();

Require a valid MX record

You can require that your EmailValidator reject all email addresses that do not have a valid MX record associated with the domain.

Please note that including this rule on your email validator can increase the amount of time it takes to validate email addresses by approximately 600ms in the worst case. To further control the amount of time spent doing DNS lookups, you can use the overloaded method to customize the timeout and retries.

JMail.validator().requireValidMXRecord();

// Or, customize the timeout and retries
JMail.validator().requireValidMXRecord(50, 2);

Require the address to be ASCII

Some older email servers cannot yet accept non-ASCII email addresses. You can require that your EmailValidator reject all email addresses that contain characters other than ASCII characters.

JMail.validator().requireAscii();

Bonus: IP Address Validation

Since validating email addresses requires validation of IP addresses, these IP address validation methods are exposed for your convenience!

Determine if an IP Address is Valid

String ipv4 = "12.34.56.78";

if (InternetProtocolAddress.isValid(ipv4)) {
  // Use address
}
String ipv6 = "2001:db8::1234:5678";

if (InternetProtocolAddress.isValid(ipv6)) {
  // Use address
}

Enforce an IP Address to be Valid

String ipv4 = "12.34.56.78";

try {
  InternetProtocolAddress.enforceValid(ipv4);
} catch (InvalidAddressException e) {
  // Failure
}
String ipv6 = "2001:db8::1234:5678";

try {
  InternetProtocolAddress.enforceValid(ipv6);
} catch (InvalidAddressException e) {
  // Failure
}

Validate and return the IP

String ipv4 = "12.34.56.78";

Optional<String> validated = InternetProtocolAddress.validate(ipv4);

// The validate() method allows for convenience such as:
String ip = InternetProtocolAddress
    .validate("notvalid")
    .orElse("0.0.0.0");
String ipv6 = "2001:db8::1234:5678";

Optional<String> validated = InternetProtocolAddress.validate(ipv6);

// The validate() method allows for convenience such as:
String ip = InternetProtocolAddress
    .validate("notvalid")
    .orElse("2001:db8::1234:5678");

Contributing

All contributions are welcome! Open issues for bug reports or feature requests. Pull requests with fixes or enhancements are encouraged.

Relevant RFCs: 822, 2822, 5321, 5322

jmail's People

Contributors

bowbahdoe avatar dependabot[bot] avatar elmolm avatar rohannagar 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  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

jmail's Issues

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.

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

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

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.

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

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.

StringIndexOutOfBoundsException

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;

}
}

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

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

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

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?

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

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.

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

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

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.

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

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

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.

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.

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.

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

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.