Last modified: 2011-01-24 12:50:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T24449, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 22449 - MediaWiki should do validation of e-mail addresses
MediaWiki should do validation of e-mail addresses
Status: CLOSED FIXED
Product: MediaWiki
Classification: Unclassified
Email (Other open bugs)
unspecified
All All
: Normal minor (vote)
: ---
Assigned To: Antoine "hashar" Musso (WMF)
: upstream
: 26287 (view as bug list)
Depends on:
Blocks: 26676
  Show dependency treegraph
 
Reported: 2010-02-09 15:27 UTC by Mark Bergsma
Modified: 2011-01-24 12:50 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Mark Bergsma 2010-02-09 15:27:43 UTC
Currently MediaWiki doesn't seem to verify e-mail addresses entered by users, seeing as many e-mails get sent with addresses that don't even have an apostrophe (@). These e-mails go lost or end up in the wrong places without the user ever receiving a warning, as the mails cannot be bounced either.

MediaWiki should be doing a (better) job at verifying e-mail addresses. Ideally using a fully RFC2822 address checker with MX record verification, but we could at least check if the address contains an apostrophe.
Comment 1 Mike.lifeguard 2010-02-09 15:34:09 UTC
(In reply to comment #0)
> apostrophe (@)...
> at least check if the address contains an apostrophe.

apostophe = '
at symbol = @

couldn't help myself :(
Comment 2 Mark Bergsma 2010-02-09 15:45:02 UTC
Haha, right. I guess the dutch word 'apestaartje' (@) tricked me there. ;)
Comment 3 OverlordQ 2010-02-09 15:53:39 UTC
We[1] did a poor-mans e-mail validation which simply split at the @ and checked the host portion for MX/A, as regexs to check for valid addresses can[2] be pretty nasty[3].

1 - http://toolserver.org/~acc/
2 - http://toolserver.org/~overlordq/regex.txt
3 - http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html
Comment 4 Chad H. 2010-02-10 03:51:12 UTC
Cf the similar bug 959. As pointed out in comment #33, trying to check for full RFC compliance is both difficult and unnecessary. 

However, it's been pointed out that some simple sanity checks (length, obviously bogus characters) could at least be applied.
Comment 5 Tomasz Finc 2010-10-26 05:58:29 UTC
This would be especially nice since it's very easy to copy and paste an email address for a new user with extraneous markup such as 'Name <name@wikimedia.org>' which upon passwordless account creation will trigger a 'mailing error' and leave the user in a tricky state.
Comment 6 Brandon Harris 2010-10-26 06:12:03 UTC
So, I looked into this recently for an extension.  I've been running for years with a specific regex to check for email validity but it doesn't handle "everything".

The problem is all sorts of exceptions to four billion RFCs (such as allowing "+" characters, etc.).  The best I've seen is this: http://www.dominicsayers.com/isemail/ but it is pretty hard core.  I'm not sure if doing anything *less* is worthwhile.
Comment 7 Antoine "hashar" Musso (WMF) 2010-10-28 21:02:39 UTC
r75627 adds a very simple email validator helper. Does not enforce anything though.
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-10-28 23:17:58 UTC
HTML5 has a good real-world definition:

http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#valid-e-mail-address

It works out to something like

"^$username_char+@$domain_char+(\.$domain_char+)+$"

where

$username_char = [-a-zA-Z0-9!#$%&\'*+/=?^_`{|}~.];
$domain_char = [-a-zA-Z0-9]

I did some research on how overly restrictive this definition was in practice, using an older and more restrictive definition:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022220.html

It looks like it will be fine, at least for English users.  Almost none would be affected if we did some sanitization (e.g., to fix up stuff like "Foo" <foo@bar.example>).  I've been meaning to do some more testing on the databases to see if other languages might be affected more, but never got around to it.  If obviously bogus addresses are causing problems, then we may as well go ahead with it.  It's a pretty trivial change to get MediaWiki to reject these on the server side.
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-12-10 00:11:34 UTC
*** Bug 26287 has been marked as a duplicate of this bug. ***
Comment 10 Sam Reed (reedy) 2011-01-07 19:33:26 UTC
r75876, r75862, r75627 marked as resolved with this bug being tagged upstream and remote bug logged
Comment 11 Antoine "hashar" Musso (WMF) 2011-01-16 09:37:17 UTC
Marking bug as blocking MediaWiki 1.17 release tarball (bug 26676).
Comment 12 Mark A. Hershberger 2011-01-20 19:18:53 UTC
Reedy probably meant r75682, not r75862
Comment 13 Mark A. Hershberger 2011-01-20 19:26:25 UTC
Ashar, looks like you still have a FIXME on the code to get it to allow @localhost email addresses.  Might only want to allow that where people specifically request it.

Any idea if you can add that in the next week?
Comment 14 Antoine "hashar" Musso (WMF) 2011-01-20 22:07:52 UTC
It is on my TODO list, hopefully this week-end if time allow.
Comment 15 Antoine "hashar" Musso (WMF) 2011-01-21 18:03:08 UTC
I have altered the regexp so the second part is 0 to n elements instead of at least 1.

See: r80694

I am assuming this issue is fixed in MediaWiki regardless of the w3.org specification.
Comment 16 Antoine "hashar" Musso (WMF) 2011-01-22 00:08:28 UTC
Merged in 1.17 by Roan with r80722.
Comment 17 Aryeh Gregor (not reading bugmail, please e-mail directly) 2011-01-24 12:50:30 UTC
As it happens, a matching change was made in the HTML5 specification:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11225

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links