Project

General

Profile

Actions

Bug #15054

closed

Gremlin: Insufficient email validation

Added by Thorsten Kahler over 18 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
-
Start date:
2005-10-14
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.3
PHP Version:
4.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

The RegEx used in t3lib_div::validEmail() will return true only in some rather homebred cases. The check in t3lib/jsfunc.validateform.js in function validateForm is even worse.

I'd suggest to use one of those rated with 4 of those very popular green bars ;-) at [1]. One of these should work in JS also. And at least they're all closer to the RFC 822 [2].

[1] http://www.regexlib.com/Search.aspx?k=email
[2] http://www.faqs.org/rfcs/rfc822.html

(issue imported from #M1606)


Related issues 4 (0 open4 closed)

Related to TYPO3 Core - Feature #15147: TCA: possibility to evaluate email fieldsClosed2005-10-22

Actions
Related to TYPO3 Core - Feature #17334: [Code] Improved t3lib_div::validEmail() satisfying RFC 3696ClosedChristian Kuhn2007-05-26

Actions
Related to TYPO3 Core - Feature #19466: use native filter_functions for validate and sanitizeClosedDmitry Dulepov2008-10-16

Actions
Has duplicate TYPO3 Core - Bug #16233: t3lib_div::validEmail() -> validation not complete?ClosedOliver Hader2006-06-13

Actions
Actions #1

Updated by Schmid Valentin over 18 years ago

Could you give an example of an email-address which doesn't work?

Actions #2

Updated by Thorsten Kahler over 18 years ago

False positives:

abc@def.ßcom
abc@....com

False negatives:
"abc" <>
abc@intranet

These examples are not tested, just constructed looking at the regex.

Actions #3

Updated by Martin Kutschker over 18 years ago

Thorsten, I think that your false negatives are invalid. While the first one is a valid recipient in a mail header it's nothing that should be tested in t3lib_div::validEmail(). First extract the contents between <> then test.

The second is valid per definitoin, but invalid for all practical cases. 99.99999% of all cases don't need mail addresses of internal networks.

The false positives are correct except the last one. It's indeed valid to use IP addresses. So a correct test would be to check either for an IPv4 address or a proper domain name.

Actions #4

Updated by Martin Kutschker about 18 years ago

This one doesn't work:

(NNNN = last part of disclosed phone number; A1 is an Austrian carrier)

Yes folks all these characters are allowed:

a-zA-Z\d!#$%&'*+\-/=?^_`{|}~

I don't care much about the back tick but I do care about the +

Actions #5

Updated by Martin Kutschker about 18 years ago

preg_match('/^[a-zA-Z\d!#$%&*=?^`\/{|}._~+-]+@(([A-Za-z0-9]+-)?[A-Za-z0-9]+\.)+[A-Za-z]{2,}$/',$email)

This allows all allowed characters for the local part and does reasonable checking for the domain part:

- must not start or end part (eg "foo-bar", not "foo-")
. must not be repeated ( eg "..")
tld contains only letters and must be at least two chars long

This one does not work with the following valid addresses

quoting:
abc""def@domain.tld
spaces:
abc def@domain.tld
full header:
foo bar <local@domain.tld>
IP:
abc
[123.34.2.34]

The full header is IHMO not needed as the calling code could extract the part within <..>. Quoting and IPs are rarely seen. The latter is easy to implement the former is a PITA. Spaces can accoring to the RFC be collapsed (so "abc def" is equivalent to "abcdef").

Actions #6

Updated by Wolfgang Klinger about 18 years ago

@Martin: the last one does not allow this valid E-Mail address:

Actions #7

Updated by Karsten Dambekalns about 18 years ago

Oh, and please don't forget things like
karsten@localhost

Those are valid, and I use them a lot while testing. (I didn't check whether they work, but they definitely should!).

Actions #8

Updated by Karsten Dambekalns about 18 years ago

In addition to me last comment, there's a lot more to learn about email addresses... From http://www.faqs.org/faqs/mail/addressing/:

The following are all legal and equivalent addresses for me:
< eli netusa . net >
<eli(jah)@netusa.net>
< eli(Elijah)@netusa(not associated with usa.net).net >
(Elijah) <eli
(dougs-home)netusa.net>
< eli (the raw IP for mail (and thus subject to change)) [204.141.0.25] >
< eli
(a subtler variation on the above) [204.141.25] >

<eli (Pogonatus (latin for <the bearded>)) (qz (pronounced (queasy) ) \
.little-neck (I did not want that, but RFC1480 required it) .ny (New \
F%
!: York) .us (USA) or ) netusa (Located on Long Island) . net> (Elijah)

Wow! ;)

Actions #10

Updated by Martin Kutschker about 18 years ago

Karsten, I know that the RFC allows very interseting formats. The problems is that a regexp that accepts all valid input is hard to write and certainly hard to reaf and therefore not maintainable.

I suggest we either don't use a solution with a single regexp (this is by noi means required) or support the most common sane address formats.

So forget about all thore mail header comments (the values brackets are comments!). Nobody uses them in real life in a header and nobody will enter them in a form when submitting his email address.

Spaces may be ignored as well, but we may support IP addresses: user@[127.0.0.1]. But again, for readbility I'd use two regexps to handle this.

Actions #11

Updated by Karsten Dambekalns about 18 years ago

Martin, the example with the very weird addresses were not meant to be implemented... :)

Of course we should make this redable and maintainable, so I'm all for using two (or more) regexps and whatever else is needed...

Actions #12

Updated by Andreas Bulling almost 17 years ago

Related to #0005688

Actions #13

Updated by Karsten Dambekalns over 15 years ago

Just to make sure potential synergy isn't lost:
http://forge.typo3.org/repositories/entry/package-flow3/trunk/Classes/Validation/Validator/F3_FLOW3_Validation_Validator_EmailAddress.php

But I just noticed that that one also misses "", so keep an eye on updates to that code. :)

Actions #14

Updated by Dmitry Dulepov over 15 years ago

See #19466

Actions #15

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF