Comments (7)
The regex expressions come from another open source project,
http://code.google.com/p/emailaddress/source/browse/.
The problem is that the class has exploded over there so I would have to patch
our own version. Alas, regular expressions is not my specialty. Any thoughts on
how to fix this?
Original comment by b.bottema
on 9 Aug 2012 at 7:36
from simple-java-mail.
It looks like the email validator might move here (eventually): https://github.com/lhazlewood/jeav
from simple-java-mail.
Hmm, not anytime soon I'm afraid, considering the last commit was from 2011 and the validation logic was initially created in 2006. I see you're trying to get that to move. Good. Let's see.
from simple-java-mail.
Hmm, not anytime soon I'm afraid, considering the last commit was from 2011 and the validation logic was initially created in 2006. I see you're trying to get that to move. Good. Let's see.
True, I just thought I'd put in the link in case it's hard to find later on (in the hope that the migration does in fact happen at some point).
@bbottema What exactly did you mean by "the class has exploded" in #3 (comment)? (assuming you can remember what you meant back that far!) Perhaps just the mess of untested regexes? Since the code seems to be unmaintained anyway, it might be worth bringing it in, assuming it's worth keeping at all.
It looks like the performance problems were known even before the validator project was set up, and not likely to be fixed any time soon: http://leshazlewood.com/2006/11/06/emailaddress-java-class/comment-page-1/#comment_count
In any case, there's a school of thought that client code shouldn't even try to validate email addresses perfectly, for instance http://davidcel.is/posts/stop-validating-email-addresses-with-regex/. It's too easy to get it wrong and reject email addresses which are actually valid, before you even start worrying about things like catastrophic backtracking.
It's probably enough to check for @
or <somename> something@something
, and let the SMTP server worry about anything more sophisticated if need be. In view of the potential for erroneous rejections or performance problems and the general unmaintained and untested state of the validation library, I would suggest that Simple Java Mail shouldn't bother, or should at least make the address validation optional. (Or did I miss an option which already exists?)
Some users may care about RFC-compliant bodies, but not about 100% RFC compliant addresses. Personally, I would prefer a risk of letting a non-compliant address through (perhaps to be rejected by the SMTP server) over the risk of wasting hours of CPU.
from simple-java-mail.
What exactly did you mean by "the class has exploded" in #3 (comment)? (assuming you can remember what you meant back that far!) Perhaps just the mess of untested regexes? Since the code seems to be unmaintained anyway, it might be worth bringing it in, assuming it's worth keeping at all.
@seanf I think at the time it was impossible to easily update to a next version of a validation library, as their version had moved away too much. I think they were halfway switching between an overgrown regex version and doing it in native java without regex.
In any case, there's a school of thought that client code shouldn't even try to validate email addresses perfectly, for instance http://davidcel.is/posts/stop-validating-email-addresses-with-regex/. It's too easy to get it wrong and reject email addresses which are actually valid, before you even start worrying about things like catastrophic backtracking.
This is a valid point. The point was provide early detection and friendly errors. It's a balance between helping the end-user with a abstract friendly API layer and letting him deal with the technical depths of native libraries and errors. It's why simple-java-mail exists in the first place, but maybe we should draw the line at email validation, simply because we don't master the subject and it is completely untested.
I would suggest that Simple Java Mail shouldn't bother, or should at least make the address validation optional. (Or did I miss an option which already exists?)
Currently not, but it is worth adding. There is a way to configure the validation criteria, by simply setting it on a Mailer
instance. I will look into it.
Some users may care about RFC-compliant bodies, but not about 100% RFC compliant addresses. Personally, I would prefer a risk of letting a non-compliant address through (perhaps to be rejected by the SMTP server) over the risk of wasting hours of CPU.
I agree, the purpose of this library is to provide an easy way to handle complex mail bodies that behave consistently across the many email readers. Email validation is secondary to that. However, if there is a good library out there that properly validates email, I would still like a facility like that.
from simple-java-mail.
I turned off email address validation by default, with the option to turn it back on.
from simple-java-mail.
@seanf This library hopefully runs better: https://github.com/bbottema/email-rfc2822-validator
from simple-java-mail.
Related Issues (20)
- Order of attachments is lost when converting a MimeMessage to an Email HOT 4
- Make S/MIME algorithms configurable (signature algorithm for signing, key encapsulation and cipher algorithms for encryption) HOT 4
- [Enhancement] Expose finer-grained DKIM configuration through the builder api and disable 'l-param' by default HOT 12
- [bug] Fix parsing addresses from headers in EML files, like a Disposition-Notification-To with umlaut HOT 1
- Update outlook-message-parser dependency, which has improved support for X500 addresses
- [Bug] Message headers not treated with case insensitivity as per RFC, causing deviating headers to slip through the filters HOT 1
- Maxing out SMTP server concurrent connections HOT 1
- outlookMsgToEmail duplicates recipients if same name used for To and Cc HOT 1
- java.lang.NoClassDefFoundError: org/jacoco/agent/rt/internal_c13123e/Offline HOT 2
- [security] Update 3rd party dependencies to get rid of all currently known CVE issues HOT 2
- [enhancement+bug] Make EmailConverter API more consistent regarding Session parameter, don't use `Session.getDefaultInstance` anymore and fix bug where `emlToEmailBuilder` used `emlToMimeMessage` HOT 3
- How to create jakarta.mail.internet.MimeMessage without accessing the mailer session? HOT 3
- Update upstream dependency generic-object-pool, which solves a critical bug when there are exceptions during allocation HOT 1
- How to esclude embedded image in email HOT 2
- When reading .msg files the RTF converted to HTML is garbled in some cases where the appropriate charset is not detected properly HOT 6
- Bump smtp-connection-pool from 2.3.2 to 2.3.3 which improves performance and fixes a rare ConcurrentModificationException HOT 1
- [Bug] After converting Outlook .msg to EML, bullet lists have duplicate numbering HTML converted from RTF HOT 3
- Wrong sent date when parsing mail HOT 3
- [bug] error deallocating object already removed from the pool HOT 6
- Trying to add a application/x-xz; charset=binary (tar.xz) attachment ... HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from simple-java-mail.