-
Notifications
You must be signed in to change notification settings - Fork 490
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Be more permissive in what we consider a valid email address to be #2998
Comments
In 8471c02 I added some tests to exercise this issue. |
We should also allow emails ending in regional domains. See #3754 for more info. |
Update of commons-validator fixes the issue. Comments were added to note the choice of 1.5 over 1.5.1 or 1.6 (errors were encountered with later versions and those versions did not provide any changes we needed). |
The signup filters now work but javax.mail throws errors when trying to send to those email addresses: [2017-07-19T09:47:54.731-0400] [glassfish 4.1] [WARNING] [] [edu.harvard.iq.dataverse.MailServiceBean] [tid: _ThreadID=52 _ThreadName=jk [2017-07-19T09:47:54.733-0400] [glassfish 4.1] [INFO] [] [] [tid: _ThreadID=52 _ThreadName=Thread-8] [timeMillis: 1500472074733] [levelV Interestingly, the new domain names like .cologne seem to be OK though I could not verify end-to-end. I have seen many posts online about this accents in email problem using Java and even set the jvm option: -Dmail.mime.allowutf8=true but that did not work. There may be a solution or workaround but it needs investigation. I don't think we should allow this until this is fixed unless we don't care whether we actually send email to users. |
Another potential issue to discuss is the current support for international email addresses and so the reliability of sending/receiving this mail. See: |
Thanks for the discussion about this post-standup. The benefits of allowing these additional email addresses is a big plus. I understand there is some risk of undelivered mail, but we'll see how widespread it is before investigating adding a whitelist/blacklist or some other solution. |
Sorry, I misspoke during the meeting earlier - there are still dots in these "new" email addresses; we are talking about a few new top-level domains added recently. Such as ".cologne". The complete address still looks like somebody@someaddress.cologne . |
Except that someone who enters a junk address knows that and does not expect email, whereas someone entering a valid international address would expect to receive mail and when they don't will open a support ticket. Also, you literally could not create an account with international characters before this change was made. Just saying. |
True. A better parallel is not somebody knowingly entering a bad address; but a user misspelling/making a typo in their address. Like if I enter loenid@hdmc.havrard.edu - I may be expecting to receive mail, but it's not going to work. |
@landreev yes, that's why we have the "verify your email address" feature. If the link we try to send them never reaches them they will hopefully realize they've supplied the wrong email address. More importantly, we don't want bad actors to be able to sign up with president@whitehouse.gov (some email address they don't actually control) and have the Dataverse installation spam the poor president. Right now there are still no consequences if you don't verify your email address, but in the future we'd like to make it so that if you don't verify your email address we don't email you (or the per person whose email you signed up with!). |
While working on #2512 and testing with random email addresses from the https://randomuser.me API, I observed that certain email addresses were treated as invalid. Examples include:
Is https://randomuser.me slipping us bad email addresses or is Dataverse being too strict about what is considered a valid email address?
The first three addresses above pass http://sphinx.mythic-beasts.com/~pdw/cgi-bin/emailvalidate but رونیکا.محمدخان@example.com does not. Locally, if I upgrade Validator – Commons Validator from 1.4.0 to 1.5.0, all the addresses above are considered valid. I'll push a test for this.
https://en.wikipedia.org/wiki/Email_address says "In addition to the above ASCII characters, international characters above U+007F, encoded as UTF-8, are permitted by RFC 6531, though mail systems may restrict which characters to use when assigning local parts."
Here's a screenshot of how a user can't be created because of an email address that doesn't pass validation:
How strict do we want Dataverse to be with regard to email addresses?
The text was updated successfully, but these errors were encountered: