Created attachment 40443 [details]
Example vcf

Still happening in 1.1.1.99

still happening in evolution-1.4.6.0.200403080631-0.snap.ximian.8.1, 
gnome2.4, suse9.0.

Still valid in 1.5.5.
Targeting for 2.1

Shouldn't we have an "email address" entry that filters properly? 

i don't think this one is important - if one enters a non-valid
address the mail just won't be sent to it.
there are many other more important UI issues than this one here.
therefore futuring, minoring priority.

still happening in 2.2, just need to check validation condition only for @ not
for  dot(.). 

type spaces in 'Type email address field' empty contact gets added in contact list

Can this get fixed now please?  I submitted this report six years ago!

Still valid in 2.11.5
Just check this... 

Created attachment 146701 [details] [review]
Check on email validity

This patch introduces an e_validate_mail_address() function in e-utils, where can be used also in other situations.
If the new address doesn't matches it is not added in the list, but it remains in the text box so to be corrected by the user; this way no explicit notification is required, because user is already alerted by the unusual behaviour.

Calling unusual behaviour alerting is something I would not ever use. Not here.
For me, I would expect not being the Add button sensitive if I've an invalid address entered in the text field. Not a bad idea of the public function for checking of email validity, though you are too strict. For example, I am able to enter a valid email address like this:
   John Black <john@black.at>
to the contact list, but not with your patch.

I would suggest to:
a) define a local function for validity checking
b) use for validity checking camel_internet_address_new with
   camel_address_decode (and possibly with camel_internet_address_get to ensure
   the email part had been read), instead of regex
c) make Add button sensitive based on the email validity, instead of "do
   nothing on error"

Please do not add restrictions to email addresses.  The RE proposed in the patch is far, far too restrictive.  Many email addresses allow extra characters like "+" etc. for example.  Also, you can send email to the guy in the office next door in your same domain with just a hostname and no domain, in which case there will be no "." on the email address.  It's just wrong for Evo to arbitrarily restrict the email address.

The only characters I can think of offhand that I'd be comfortable omitting from valid usernames in email addresses are "," and space.  Probably it would be OK to eliminate ";" as well since Microsoft mail clients often use that to separate email addresses, rather than ",".  For UNIX-style systems, usernames cannot have ":" but other systems might be more lax.  Also you can create email aliases on UNIX systems (not sure if ":" is a valid char in an alias).  Probably best to not restrict it.

So, an RE I would be comfortable with would be something like:

    ^[^;, \t]+@[-_.a-zA-Z0-9]+$

(note RFCs I've read don't allow underscores in hostnames but I've seen it many times).  You don't need to escape special chars inside character classes, BTW.  It might even be wise to make the hostname more liberal.

There is already something somewhere in Evo that does this check: in the new account creation wizard, the "Next" button is greyed out until you enter enough of an email address to be valid; it's very liberal (probably something like the above although I didn't check it in the code). Maybe that could be re-used or made more generic?

(In reply to comment #13)
> There is already something somewhere in Evo that does this check: in the new
> account creation wizard, the "Next" button is greyed out until you enter enough
> of an email address to be valid; it's very liberal (probably something like the
> above although I didn't check it in the code). Maybe that could be re-used or
> made more generic?

It's checking for '@' and some surrounding letters only, which is pretty simple way of doing the check. Such test will not work for your "addresses" without domain, though.

I'm not sure if you noticed, but this is only about Contact List, not the composer.

Why won't it work?  I just mean that the hostname part of the email can't be required to contain a ".".  When I use the wizard, it requires a "@" and any one character after it, then it's satisfied.  It doesn't need a ".foo" on the end.

My opinion is that Evo shouldn't restrict any legal email address, regardless of whether it's in the contact list or composer.  I'm willing to require the email list to contain "@" (in other words we don't need to support email addresses to other users on the local system... if you really want that you could just use "foo@localhost"), and we should try to avoid addresses which are using obviously invalid characters, but other than that...

Created attachment 152195 [details] [review]
Check on email validity

Here is a rework: the validation function is inspired by the one for the "New Account wizard", but also permits addresses in "Foo <foo@example.com>" form.
As discussed in mailing list ( http://mail.gnome.org/archives/evolution-hackers/2010-January/msg00016.html ) camel_address_decode() is not suitable for this kind of check.

(In reply to comment #15)
> My opinion is that Evo shouldn't restrict any legal email address

+1

(In reply to comment #16)
> Check on email validity

See bug 513438 comment 17: "user@localhost (hint, no dot) is a bloody valid email address. As can even be the plain 'user', without any host part."

Marking as duplicate of that ticket.

*** This bug has been marked as a duplicate of bug 513438 ***