eform will reject valid email addresses(?)

Trying to figure out why mail is not being sent, I read through the source code in eform.inc.php, and it appears to me that eForm does email address validation using an ad hoc syntax not obtained from the relevant Internet standards.



RFC822 says that the local part of an email address, i.e., the part to the left of the @ sign, is interpreted only by the receiving site. So the email validation done by eForm will reject some valid email address. As one common example, many mail systems allow so-called "plus addressing" which uses a + sign, and eForm will prevent this. As another example, many mail systems use a dot to separate first and last name in addresses such as [email protected]. I am sure there are many less common examples of valid email addresses that will also be rejected.

The following Wikipedia entry:

  http://en.wikipedia.org/wiki/E-mail_address

Says: "However, some mail servers violate RFC 5322, and the recommendations in RFC 3696, by refusing to send mail addressed to a user on another system merely because the local-part of the address contains the plus sign (+). Users of these systems cannot use plus addressing."

Rahul

In defense of eForm, almost all actual mail senders don’t conform to the standards and will filter out some technically legal addresses. This is partly because the regex expression to fully comply is several pages long and partly because certain legal addresses are often used by spammers.

SPForm uses the same preg_match expression as eForm.

You’re free to edit it or replace it with one of the *many* alternatives found on the web.

There are a number of them here: http://haacked.com/archive/2007/08/21/i-knew-how-to-validate-an-email-address-until-i.aspx

eForm allows for custom validation rules so you are not stuck. If you know the regex to validate the email format you need then you can add it (and post it for others)

I can certainly revise eForm to do a different kind of validation. In addition to making long-term maintenance harder, that also still leaves all the other MODx installations where the person installing MODx has no idea, unless he happens to be reading this forum topic, that incorrect validation is being done. As a result many people visiting many web sites will find their valid email addresses rejected.

Email address validation won’t stop spammers but will prevent valid email. Asking the person using a contact form to manually enter some specific string into his message body will stop most spammers.

Quote from: dev_cw at Jan 28, 2009, 01:00 PM

eForm allows for custom validation rules so you are not stuck. If you know the regex to validate the email format you need then you can add it (and post it for others)

For those of you who are masochistic enough to want to use a pcre regex, look in this:

http://cpansearch.perl.org/src/RJBS/Email-Valid-0.179/lib/Email/Valid.pm

Everybody else should just call the PHP function mailparse_rfc822_parse_addresses().

Quote from: crossconnect at Jan 28, 2009, 01:22 PM

...MODx installations where the person installing MODx has no idea, unless he happens to be reading this forum topic, that incorrect validation is being done. As a result many people visiting many web sites will find their valid email addresses rejected.

I think he has a point here. The standard email regex in eForm and SPForm should probably be updated to not check the syntax of the part before the @ sign, since that’s really not necessary and is currently incorrect. I’d just check that there is at least one character before the @ sign and leave it at that.

Personally I think it’s fine not to specify all of the valid domain extensions but just check the length as you do now, since I’d rather err on the side of allowing the email to be used than rejecting it (and they’ll just add more anyway, which would make updating the regex a pain).

It’s definitely easy to use a custom regex in eForm now (which is one of the many beauties of eForm), but most people won’t know how or bother to do so for email addresses.

I’d be glad to update SPForm if someone would suggest a good alternative test.

i agree with ZAP on this one. I hate not being able to use the + sign with my gmail email like [email protected]

That comes in very handy and I usually use my ’spam’ email account for those cause you never know. So I like the idea of (at least one character)@(at least one character).(2 or 3 characters)

Quote from: ChuckTrukk at Jan 29, 2009, 12:10 AM

So I like the idea of (at least one character)@(at least one character).(2 or 3 characters)

Actually the domain name expression has to be a bit more involved, since it needs to account for TLDs of up to six characters with no period (e.g., .museum, .travel) and country codes following a second period (e.g., .com.mx), as well as possible subdomains (e.g., mail.box.net). So technically if it just checked for a dot followed by 2 to 6 characters at the end of the address I guess that would work, as long as periods could be included in there. That wouldn’t take into account non-latin character (internationalized) email addresses, but I think that might be better left to a custom regex given how much it would complicate the expression.

Here are a number of regex expressions for validating email addresses, one of which would probably do the trick:
http://regexlib.com/DisplayPatterns.aspx?cattabindex=0&categoryId=1

Proposed validation algorithm:

• Look for the first @ sign in the email, scanning from right to left. LHS is everything to the left of this @ sign, and RHS is everything to the right of this @ sign.
• LHS must contain at least one character, else reject the email address.
• RHS must contain at least one dot not at the beginning or at the end, else reject the email address. If RHS begins with a dot, reject the email address. Ignore or remove any dot at the end of RHS.
• Do a DNS query for RHS. If we don’t get back at least one MX record, reject the email address.
• If we reach here, accept the email address as valid.

Reasons:

Cannot check LHS for validity, because only the final receiving site can decide what it will accept.

Any nontrivial check for RHS syntax could become obsolete. If not now, then later. But If you find an MX record, you know the RHS is valid. If you don’t find an MX record, then mail will fail anyway, regardless of RHS syntax.

Note: Strictly speaking, no dot is required in the RHS, since postmaster@com could be a valid email address for the postmaster for the COM zone, and so on. However, as a practical matter, this will never occur.

Note: The DNS query would require also installing something like the Net_DNS package.