|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0016894||mantisbt||public||2014-01-27 17:52||2015-04-29 13:19|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0016894: Don't allow invalid email addresses (e.g. fred@localhost) to be used when signing up|
|Description||Following commit https://github.com/mantisbt/mantisbt/commit/50d235ad101f61a6c6888316e827fd225ad4b9cd|
Mantis allows users to sign up with an email address such as fred@localhost, when email validation is enabled.
The expected behaviour should be that we reject this sort of email address when requiring a user to enter a valid email address.
|Tags||No tags attached.|
The thing is that fred@localhost *is* a perfectly *valid* address as per RFC5322 specification , and must therefore be allowed (see sections 3.4.1 and 3.2.3 for details):
addr-spec = local-part "@" domain
domain = dot-atom / domain-literal / obs-domain
dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
The last bit (dot-atom-text) says that there must be 1 or more chars followed by zero or more groups of ("." followed by 1 or more chars).
Maybe I was a bit fast in closing this. Reopening for for discussion following up on grangeway's message on the mailing list  which I only just saw.
> We *now* accept an email address such as fred@localhost
They were accepted before, their being rejected is only a very recent thing .
> we shouldn't accept non-routable email addresses if email validation is on.
I'm fine with that on principle, bearing in mind the fact that the domain part of the email is not of the form "domain.tld", does not in itself make the address invalid, or more specifically, not routable. Likewise, an address with a ".tld" part can be invalid if the server behind it is a mail server without an MX.
> If a user wants/needs to allow non-routable email addresses they can always turn off the validation functionality.
That could be an option.
> Given that PHP contains an api function to validate an email address, I believe we should make us of that function.
I disagree, this is exactly what I reverted - the PHP function rejects user@domain addresses 
Note: it would appear that the regexp used by PHP filter_vars is apparently an old version of the one used in PHPMailer 
> If not, I suggest we make a config option to allow users to choose to use the functionality provided within php itself, as opposed to a custom implementation.
I can't believe *you* are suggesting to add a new config option ;-)
 http://squiloople.com/2009/12/20/email-address-validation/ https://bugs.php.net/bug.php?id=49576
PLZ stick to RFC5322 indeed, we have a internal DNS with just names like "superserver" "wow" "itsfine".
The expected behavior should be that we accept this sort of email address when requiring a user to enter a valid email address. ;)
This is still something we need to look at -
If someone wants to require users to require a valid internet mail address, then fred@localhost is invalid. If you want to allow invalid internet addresses, then you can disable the email validation options.
> If you want to allow invalid internet addresses,
First of all, I'll repeat AGAIN that these address are VALID, they respect the RFC5322 specification. Just because the PHP team took the decision not to follow the RFC, does not make it right.
> then you can disable the email validation options.
No you can't. you still need to have addresses that your local SMTP server can process.
Reference read on address validation:
See PR https://github.com/mantisbt/mantisbt/pull/172
That should satisfy both grangeway's concerns and my/cor3huis requirement for fully RFC5322-compliant emails.
I've been looking at this a bit more, and RFC's/standards so whilst i'm not necessarily sure I agree with it, the 'standards' do seem to allow @localhost.
I'm going to raise a seperate bug report and put in a pull request over weekend to move the validation out of phpmailer and to follow what seems to be an agreed standard.
|Until then, this should remain open since there is a pull request with open discussion pending. If and when you do submit yours, we can compare them and decide which one should be implemented.|
Following discussion in PR https://github.com/mantisbt/mantisbt/pull/172, we agreed to switch to using HTML5 standard regex for validation, which allows for user@host type of addresses (i.e. without TLD)
Consequently, this issue is resolved as "won't fix"
|2014-01-27 17:52||grangeway||New Issue|
|2014-01-27 17:59||atrol||Relationship added||related to 0014631|
|2014-01-27 22:36||vboctor||Summary||Mantis allows invalid email addresses to be used by users when signing up e.g. fred@localhost => Dont' allow invalid email addresses to be used when signing up e.g. fred@localhost|
|2014-01-27 22:37||vboctor||Summary||Dont' allow invalid email addresses to be used when signing up e.g. fred@localhost => Don't allow invalid email addresses (e.g. fred@localhost) to be used when signing up|
|2014-01-28 01:23||dregad||Note Added: 0039204|
|2014-01-28 01:23||dregad||Status||new => resolved|
|2014-01-28 01:23||dregad||Resolution||open => won't fix|
|2014-01-28 01:23||dregad||Assigned To||=> dregad|
|2014-01-28 04:43||dregad||Assigned To||dregad =>|
|2014-01-28 04:43||dregad||Note Added: 0039208|
|2014-01-28 04:43||dregad||Status||resolved => feedback|
|2014-01-28 04:43||dregad||Resolution||won't fix => reopened|
|2014-01-28 05:13||cor3huis||Note Added: 0039212|
|2014-01-28 18:25||atrol||Relationship added||related to 0011978|
|2014-04-30 11:17||dregad||Status||feedback => resolved|
|2014-04-30 11:17||dregad||Resolution||reopened => won't fix|
|2014-04-30 11:17||dregad||Assigned To||=> dregad|
|2014-04-30 13:41||grangeway||Note Added: 0040194|
|2014-04-30 13:41||grangeway||Status||resolved => feedback|
|2014-04-30 13:41||grangeway||Resolution||won't fix => reopened|
|2014-04-30 20:10||dregad||Note Added: 0040195|
|2014-05-01 18:39||dregad||Note Added: 0040197|
|2014-05-01 18:39||dregad||Status||feedback => assigned|
|2014-05-01 19:04||grangeway||Note Added: 0040198|
|2014-05-01 19:04||grangeway||Status||assigned => resolved|
|2014-05-01 19:04||grangeway||Resolution||reopened => won't fix|
|2014-05-02 02:32||dregad||Note Added: 0040200|
|2014-05-02 02:32||dregad||Status||resolved => feedback|
|2014-05-02 02:32||dregad||Resolution||won't fix => reopened|
|2014-06-03 12:01||dregad||Relationship added||related to 0017275|
|2015-04-16 18:08||dregad||Relationship added||related to 0017279|
|2015-04-16 18:10||dregad||Status||feedback => resolved|
|2015-04-16 18:10||dregad||Resolution||reopened => won't fix|
|2015-04-16 18:10||dregad||Note Added: 0049424|
|2015-04-29 13:19||atrol||Status||resolved => closed|