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 | |
Reporter | grangeway | Assigned To | dregad | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | won't fix | ||
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. | ||||
related to | 0014631 | closed | dregad | Email validation needs to be consistent |
related to | 0011978 | closed | dregad | 'user@localhost' not a valid email address. |
related to | 0017275 | closed | dregad | email matching within Mantis should follow html5 standard |
related to | 0017279 | closed | dregad | Email addresses validation and parsing is not consistent |
The thing is that fred@localhost is a perfectly valid address as per RFC5322 specification [1], and must therefore be allowed (see sections 3.4.1 and 3.2.3 for details): addr-spec = local-part "@" domain 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 [1] which I only just saw.
They were accepted before, their being rejected is only a very recent thing [2].
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.
That could be an option.
I disagree, this is exactly what I reverted - the PHP function rejects user@domain addresses [3] Note: it would appear that the regexp used by PHP filter_vars is apparently an old version of the one used in PHPMailer [4]
I can't believe you are suggesting to add a new config option ;-) [1] http://thread.gmane.org/gmane.comp.bug-tracking.mantis.devel/4985 |
|
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. |
|
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.
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" |
|