"+" is not a invalid symbol in emails

Aleksandersen · 2007-04-12 23:38:35

Hi,

The email validation function on the Textpattern contact page claims + is not a valid symbol in email addresses. I assume the form is provided trough Textpattern so this is a bug in Textpattern!

+ symbols are indeed valid in email address. (documentation)

(Edit: updated discussion topic. -Mary)

Last edited by Aleksandersen (2007-04-15 14:47:48)

squaredeye · 2007-04-12 23:41:57

I’ve had this issue on multiple sites (not just limited to TXP). I like to use gmails + solution so that I can see where spam is coming from and cut it out! I’d be for a fix on this issue, if only for others sake.

M

Aleksandersen · 2007-04-12 23:54:36

Yhea! That is mostly what I use it for too! My email provider lets me filter, redirect, and do lots of other stuff with + aliases! I use them all the time.

That is why I wanted to get this fixed in Textpattern…

Mary · 2007-04-13 01:47:13

Textpattern doesn’t have a contact form ability. That’s powered by a plugin.

Aleksandersen · 2007-04-13 06:10:00

How to report a bug in that plugin, then?

colak · 2007-04-13 09:06:57

depends on the plugin you use. If you use zem’s one report the bug where Mary has indicated

Mary · 2007-04-13 20:50:01

According to Ruud, his plugin uses a copy of code Textpattern has. Txp only uses it for setting up users, so that would explain why the problem hasn’t cropped up until now.

+ symbols are indeed valid in email address.

Here is where the problem lies. Lots of things are potentially valid, making the regular expression insane.

ruud · 2007-04-13 22:40:05

Yes, a regex that can match all possible RFC2822 addresses is insane, but if you leave out comment support, wrapping lines and exclude things like quoted local parts and exotic domain parts (like [1.2.3.4] and non-FQDN), that probably leaves a regex which can still be understood by more humans than just Jeffrey Friedl ;)

However, a regex that is a bit too strict does also have some advantages, because some of the valid characters that it currently excludes are so rarely used in email addresses, that rejecting them catches a lot of typos. Take for example: user#@example.com. It’s a valid email address, but if that was entered in a comment/contact form, it’s almost certainly a typo.

Perhaps instead of this (which allows some invalid addresses):

/^[\w._-]+@([\w-]+\.)+[\w-]+$/

this could be used:

/^[a-z0-9_+-](\.?[a-z0-9_+-])*@([a-z](-*[a-z0-9])*\.)+[a-z]{2,6}$/i

or, if you accept domains that start with a digit (which aren’t really valid, but do exist unfortunately):

/^[a-z0-9_+-](\.?[a-z0-9_+-])*@([a-z0-9](-*[a-z0-9])*\.)+[a-z]{2,6}$/i

Combine that with an MX/A-record check and make sure the length of the domain part is limited to 255 chars (and max 63 chars for (sub)domains) and it’s a very nice validity check. The local part should be at most 64 chars.

Last edited by ruud (2007-04-14 09:22:02)

zem · 2007-04-15 01:17:27

Perhaps instead of this (which allows some invalid addresses)

Are you able to post some examples please?

ruud · 2007-04-15 08:45:29

a.@example.com
user@ex_ample.com
user@example-.com

\w is locale dependent, which is why I avoid using it, because it can in some cases match characters outside [a-zA-Z0-9_]. Character codes greater than 127 (i.e. accented letters) are not legal in email addresses.

Hmm… interesting, rfc1912 states that domain names can have leading digit:

Allowable characters in a label for a host name are only ASCII letters, digits, and the `-’ character. Labels may not be all numbers, but may have a leading digit (e.g., 3com.com). Labels must end and begin only with a letter or digit. See [RFC 1035] and [RFC 1123]. (Labels were initially restricted in [RFC 1035] to start with a letter, and some older hosts still reportedly have problems with the relaxation in [RFC 1123].) Note there are some Internet hostnames which violate this rule (411.org, 1776.com).

Not tested, but an attempt to use positive lookahead assertions to check the various length limits:

/^(?=[^@]{1,64}@)[a-z0-9_+-](\.?[a-z0-9_+-])*@(?=.{,255}$)((?=[^.]{1,63}\.)[a-z0-9](-*[a-z0-9])*\.)+[a-z]{2,6}$/i

Some explanation:

/^
(?=[^@]{1,64}@)   // local part limited to 64 chars and...
[a-z0-9_+-]       // may not start...
(\.?[a-z0-9_+-])* // or end with a dot (nor contain 2 or more dots in a row)
@
(?=.{,255}$) // domain limited to 255 chars
(
  (?=[^.]{1,63}\.) // with each subdomain (label) limited to 63 chars and...
  [a-z0-9]         // may not start...
  (-*[a-z0-9])*    // or end with a hyphen
\.)+       // multiple subdomains allowed: sub2.sub1.domain.tld
[a-z]{2,6} // TLD currently (!) limited to 6 chars (museum), minimum 2 chars.
$/i // case-insensitive matching, otherwise I had to use a-zA-Z instead of just a-z.

Last edited by ruud (2007-04-15 09:35:45)

Textpattern CMS

Textpattern CMS support forum

#1 2007-04-12 23:38:35

"+" is not a invalid symbol in emails

#2 2007-04-12 23:41:57

Re: "+" is not a invalid symbol in emails

#3 2007-04-12 23:54:36

Re: "+" is not a invalid symbol in emails

#4 2007-04-13 01:47:13

Re: "+" is not a invalid symbol in emails

#5 2007-04-13 06:10:00

Re: "+" is not a invalid symbol in emails

#6 2007-04-13 09:06:57

Re: "+" is not a invalid symbol in emails

#7 2007-04-13 20:50:01

Re: "+" is not a invalid symbol in emails

#8 2007-04-13 22:40:05

Re: "+" is not a invalid symbol in emails

#9 2007-04-15 01:17:27

Re: "+" is not a invalid symbol in emails

#10 2007-04-15 08:45:29

Re: "+" is not a invalid symbol in emails

Board footer