Thanks for the regex, but the problem isn't just emails. It's the other fields in the address book as well. E-mail validation is a know quantity and RC even has (client side) validation implemented. What the tickets (1485504 and 1463946) are using as examples are the problems caused by a name entry in a contact like: "Dave's Private Email". Right now the apostrophe trips up RC's sql prepare. However just escaping it may cause sendmail to trip up when trying to send a message to: "Dave's Private Email" dave@example.com.
So I'm working on a patch which will make it easy to attach a regular expression for validation to every contact field so that any character in any field which will cause problems gets rejected and characters which trip up the current prepare statement but are acceptable for use down the line will get escaped and stored.
I hope that clears things up.
Thanks, Ziba
Webmaster Team University of Michigan
gnul wrote:
Here is a perl-style regex that can be used to match all RFC-compliant email addresses (RFC 5322 and RFC 5321):
/^(([a-z]|\d|[!#$%*/?|^{}`~&'+=-_])+((.)?([a-z]|\d|[!#$%*/?|^{}`~&'+=-_]))*@(([a-z]|\d)+(-*([a-z]|\d))*.)+[a-z]+)$/
(it should be on a single line with no whitespace in case your mail client wraps it)
This cannot verify valid domain extensions (e.g. .museum (good) and .foo (bad) will both match this regex), but you really need a separate check with a lookup table if you want to be that extreme.
-gnul
On Wed, Oct 15, 2008 at 4:50 PM, till till@php.net wrote:
On Wed, Oct 15, 2008 at 6:08 PM, Ziba Scott ziba@umich.edu wrote:
Hi Till,
Thanks for the response. I'd like to just quote everything and stick it in the database, but ticket 1463946: http://trac.roundcube.net/ticket/1463946
Well, with no offense to Rich, but that ticket should not have been closed like that. As far as I know ' is allowed in the local part of an address. Even though if it's not a good idea - I mean, we could argue for hours what is and what is not a good idea. It should not be on us to decide for the user/administrator.
suggests that there is a set of characters that are undesirable to store and may cause difficulty sending mail to users with strange names.
Sorry, I think I mis-understood you earlier. We are talking about email addresses, I see that now. Not just the rest of the "profile" data, e.g. name etc..
Data should be properly quoted - no matter what.
Which puts us in the position of picking and choosing what should go into the database. And then without proper feedback to the user, they have to play a guessing game about what they can and cannot use. So how about something like:
1.) A server side match against a regex like: /^[a-zA-Z _-]*$^/ (I'll bet there's lots more characters people will want in there)
Yes, lots.
till+roundcube@whatever.com is valid too.
Think about the characters that some list servers allow.
As Charles said, the RFC is good point to start: http://en.wikipedia.org/wiki/E-mail_address#RFC_specification
Maybe we can take some BSD-licensed code from the Zend Framework: http://framework.zend.com/svn/framework/standard/trunk/library/Zend/Validate...
As you can see, email validation is sort of complex. ;-)
2.) On failure a message below the input box explaining that only such and such characters are allowed. (I'm not sure the transient nature of the existing error message display method is suitable for this task).
IMHO, a generic "invalid email address" is plenty. We don't need to confuse people with too much information.
What would be icing on top of that cake would be a client side (js) check which would change the color of the input box to a red outline if it has bad characters (or something like that).
You can put that in your template, use Jquery and attach a function to the appropriate events on the box.
Cheers, Till
Thoughts?
Thanks, Ziba
Webmaster Team University of Michigan
till wrote:
On Wed, Oct 15, 2008 at 5:18 PM, Ziba Scott ziba@umich.edu wrote:
When editing contacts, some invalid characters are not stripped or handled in some way. They make it all the way to the sql statement before things trip up. (Using a prepare statement thankfully prevents injecting a second statement. More details in: http://trac.roundcube.net/ticket/1485504)
I can work on a patch, but I'd appreciate some guidance first:
Should the backend explicitly validate the input against a regular expression? What is valid/invalid? How should the interface report bad characters and/or failed contact saves to the user?
Thanks, Ziba
Webmaster Team University of Michigan
I replied, let me know if this helps. :)
Thanks for all input!
Till
List info: http://lists.roundcube.net/dev/
List info: http://lists.roundcube.net/dev/