Project

General

Profile

Actions

Defect #6088

closed

eMail in uncommon formats considered invalid

Added by Moritz Voss over 13 years ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Accounts / authentication
Target version:
-
Start date:
2010-08-09
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed
Affected version:

Description

Setting up an account with an eMail of format "" does not work when .domain is something like "mycompany-internal". Funny enough, fictional 3-letter-TLDs such as ".hgw" work, but as soon as it uses 4 or more letters, it fails.

Also, eMail of format "user@host" doesn't get accepte either, even though it could be delivered and could be resolved, technically.


Related issues

Related to Redmine - Defect #7917: Creating users via email fails if user real name containes special charsClosed2011-03-18

Actions
Related to Redmine - Defect #32793: Email address with Punycode top-level domain is not acceptedClosedJean-Philippe Lang

Actions
Related to Redmine - Defect #36969: EmailAddress regex matches invalid email addressesClosedGo MAEDA

Actions
Actions #1

Updated by Jean-Baptiste Barth over 13 years ago

I cannot reproduce exactly what you say :
  • OK: long TLD with dashes are not accepted
  • KO: I succeeded in registering with or even longer TLDs ; there's no limit on TLD length in fact
  • OK: email@host is not accepted

I don't think we should change this in core. I think email addresses should be valid internet email addresses for 99.9% people using Redmine. Do you have an example of a TLD with dashes inside ? If not I think we should close the issue as "won't fix", and you could modify regex on line 63 of app/models/user.rb for your specific case.

Actions #2

Updated by Moritz Voss over 13 years ago

Ah, sorry. TLD seems to work if it's only letters.

It doesn't work with an address like

... which is the format we use for our internal emails. Setting the search domain to .company-internal in /etc/resolv.conf doesn't really help because user@host is invalid, too (which it shouldn't be, according to RFC5322, p.17 and RFC 1034, p.10).
Email consists of local-part @ domain

BNF of a domain explicitly allows letters, digits and hyphens in every part, as long as the hyphen is not at the beginning or end.


<domain> ::= <subdomain> | " " 

<subdomain> ::= <label> | <subdomain> "." <label>

<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig-hyp> ::= <let-dig> | "-" 

<let-dig> ::= <letter> | <digit>
Actions #3

Updated by Moritz Voss over 13 years ago

Your call of course, to decide whether you wish to conform to the RFCs or not. There's a case for only allowing "common" internet email addresses, I understand.

Thanks for pointing out where to patch it for my local use here.

Actions #4

Updated by Jean-Baptiste Barth over 13 years ago

I think we have to be pragmatic. Same problem with mail addresses which should be case sensitive if we look at the RFCs, but almost no mail provider conforms to it.

Anyway, I shouldn't be the only one to decide, I'd like to hear other contributors (and maybe options for a clean workaround ?) before closing.

Actions #5

Updated by Felix Schäfer over 13 years ago

validates_email_format_of is a plugin/gem that implements validation of email addresses as per RFC 2822. This plugin being stable, I'd be in favor of using it instead of trying to use our own Regex (bad) or whatever else validation that we'd have to maintain and maybe extend each time someone has a problem with it.

Actions #6

Updated by Jean-Baptiste Barth over 13 years ago

Not a bad idea. I always hesitate to search a solution in plugins or gems since we're not very good at keeping them up-to-date. Dealing with old versions of redcloth or awesome_nested_set is a real pita when writing plugins or debugging the core. Anyway this one may not bring such flexibility issues...

Actions #7

Updated by Felix Schäfer over 13 years ago

Well, I haven't seen mail formats changing much in the last couple of years, so I think other than bug fixes (and even those should all be ironed out by now), I don't think this plugin will see much updates if at all.

Actions #8

Updated by Jean-Baptiste Barth over 13 years ago

Felix Schäfer wrote:

Well, I haven't seen mail formats changing much in the last couple of years

Ahah, don't make fun of me, it was just a thought. We just need some unit tests to ensure we don't break some addresses which used to work, and it's ok.

Actions #9

Updated by Felix Schäfer over 13 years ago

Jean-Baptiste Barth wrote:

Felix Schäfer wrote:

Well, I haven't seen mail formats changing much in the last couple of years

Ahah, don't make fun of me, it was just a thought.

That wasn't the intent :-)

We just need some unit tests to ensure we don't break some addresses which used to work, and it's ok.

Don't we already have tests for that?

Actions #10

Updated by Felix Schäfer over 13 years ago

  • Assignee set to Felix Schäfer

Felix Schäfer wrote:

Well, I haven't seen mail formats changing much in the last couple of years

I take everything back! 2 reasons:

  • the plugin while being pretty good isn't perfect: it for example only allows for TLDs with 2 to 6 chars, which is in no way a requirement, as well as assumes the domain name to have a dot in it, which isn't required either.
  • The global mail format has not changed (much), but the details have: host and domain names can be internationalized via IDN, and while they are translated to ASCII before the request is sent out, they are valid domain names while still in UTF-8, so a user might try to use one some day.

I'd be in favor of a third solution besides rolling our own Regex and using a thrid-party plugin: as in the end the mail-sending is done by ActionMailer/TMail, we should try to use their validation if possible.

Actions #11

Updated by Felix Schäfer about 13 years ago

  • Assignee deleted (Felix Schäfer)
Actions #12

Updated by Go MAEDA about 2 years ago

  • Related to Defect #32793: Email address with Punycode top-level domain is not accepted added
Actions #13

Updated by Go MAEDA about 2 months ago

  • Status changed from New to Closed
  • Resolution set to Fixed

Since r22332, Redmine uses URI::MailTo::EMAIL_REGEXP to check the format of email addresses and it supports broader formats of email addresses than it used to be.

I think this issue can be closed.

irb(main):001> EmailAddress.new(address: 'user@mycompany-internal').valid?
=> true
irb(main):002> EmailAddress.new(address: 'user@host.mycompany-internal').valid?
=> true
irb(main):003> EmailAddress.new(address: 'user@host').valid?
=> true
Actions #14

Updated by Go MAEDA about 2 months ago

  • Related to Defect #36969: EmailAddress regex matches invalid email addresses added
Actions

Also available in: Atom PDF