UBB.Developers Forums UBB.threads 7 Development How Do I? "[email protected]" a valid eMail address?

Hello all,

I've got one new user, who can't register. His eMail address is rejected as wrong. It's in the form "[email protected]". I never saw anything like this before, but it works for him.

Is this a valid eMail address? If yes, we need to change the verification in ubbt to let this pass through.

Guess it's valid if he says it's valid.

Best place to post this in in the bugs forum at InfoPop community.
http://community.infopop.net/2/OpenTopic?a=cfrm&s=729094322&f=8233088913

That's the best place for Rick to be sure he sees and corrects it to allow it for future versions.

just wanted to be sure if this is maybe not a valid address.

Link to the bug-report:
http://community.infopop.net/2/OpenTopic?a=tpc&s=729094322&f=6183028913&m=1343093196

Dunno for sure. I do know that every once and a while, a new email format that Rick didn't figure on pops up.

So many formats. Tough to be perfect in checking I guess.

Thanks.

The problem is that by default infopop set their systems to refuse anything that has a - or a . before the @. It is the same with opentopic, and I guess with ubb.

The majority of email systems recognise these type of addresses, but some big boys like the BBC do not - their email system will bounce these types as being invalid.

I am not sure if it complies with the guidelines for email addresses - but certainly the majority of servers will allow you to issue such email addresses, so I guess that threads & opentopic should allow them.

Interestingly I see that this thread does not have a subject in replies - did threads strip the subject automatically?

Yeah, I noticed that. Must be the quick reply.

I mentioned this as a bug two months ago or something like that. I even mentioned a quick fix to be a bit more standards compliant (which would let the above mentioned email be entered).

There is an RFC (used to be 822, but has been superceded by 2822) that clearly states what is allowed within an adress. In RFC 822 you could have any word-character and dot (.) as long as it doesn't begin or end with a dot. A word character is the normal english alphabet, upper and lower case, numbers as well as "-". So with the old RFC822 it is perfectly okay to end the mailbox part (before @) with -.

With RFC2822, which should now be used, even more characters are allowed. Basically any other alphabetic characters in the standard ASCII table (even foreign ones), as well as a bunch of separation characters: !#$%&'*+-/=?^_`{|}´~
You still can't begin or end with a dot though, but any of the above characters are OK.

Don't know how many mail servers comply with the new RFC though, since it was published in April 2001, but I'd say threads is as good a place as any to start using it.

I can write the regex needed to make it work with either RFC 822 or RFC 2822 depending of what might be best.

Gardener I'll admit that my reg expression ability needs much improvement so I would be greatfull if you would put one together for us based on the new RFC documentation.

Thanks!

Ok, I'll do that later tonight. I'm going over to some friends now, I'm going to get almost every episode of Stargate. Yay! =]

Note that with the new email verification feature in 6.2, strict checking of the email address syntax is less important.

And even if someone enters an email address that's RFC2822-compliant, that doesn't mean that it works, or that it's the right email address.

Maybe it would better to go back to a simpler check, e.g., "does it have an @?".

Very true Dave

This is one of the reasons I think that the the getmxrr() function could be used to validate emails in addition. This still wont stop users from trying to use someone else's email.

LoL does the getmxrr() function still exist?

Yeah, that might be best, no need for adding functionality that isn't really needed. I'll hold off writing the regex for now.

Not sure about the getmxrr(), never used it, but it might be a bit slow connecting to another server to check and it could happen that the server doesn't answer. It seems it doesn't work on the windows version of PHP.