View Issue Details

IDProjectCategoryView StatusLast Update
0000518Main CAcert Websiteaccount administrationpublic2013-01-11 17:10
Reporterph3 Assigned To 
Status newResolutionopen 
PlatformMain CAcert WebsiteOSN/AOS Versionstable
Summary0000518: Valid E-Mail addresses with specal chars are rejected
DescriptionI tried to add a email address containing a '=' into the system and got this error message:
> Email Address given was invalid, or a test connection couldn't be made to your server, or the server rejected the email address as invalid
> Failed to make a connection to the mail server

According to my mailserver's log the server never go any connection. I think other chars then '=' may also be rejected.
Additional InformationSee the mailaddr(7) for more information or the RFC itself. Also in one of the RFCs (don't know the number but it's findable) you can find a regex that 100% conforms the RFC.
TagsNo tags attached.
Reviewed by
Test Instructions


has duplicate 0000714 needs work Valid local part gets rejected when adding new mail address to account 
related to 0000517 closed Can get any UUCP Style email address signed 
related to 0001097 closedNEOatNHNG Special characters which have no HTML-entities are not properly escaped 



2008-03-20 14:24

reporter   ~0001044

Last edited: 2008-03-20 15:02

This is by design...

From general.php:
if(preg_match("/^([a-zA-Z0-9])+([a-zA-Z0-9\+\._-])*@([a-zA-Z0-9_-])+([a-zA-Z0-9\._-]+)+$/" , $email)

It does not check for = as a valid character in $email when running "checkEmail()"

I'd suggest a patch to add = to the regex, given this is deemed valid. Perhaps even replacing the current regex with the one in the RFC.

Looks like this is the "proper" regex for e-mail address verification. Anyone care to proofread?


2008-03-20 15:27

reporter   ~0001045

Last edited: 2008-03-20 15:29

Here is my suggested replacement for the above regex...


This should also fix the fact that our current one allows e-mail addresses to end in "." which does not comply with the RFC

I'm not making a patch because I don't have the time to fully test the changes I've made. Hopefully, someone can do that for me. Thanks.

Some work should also be done on the end since it allows for domains to end in ._- as well as 0-9... I may work on it later as well.


2008-03-31 14:08

reporter   ~0001052

We should definitely allow any RFC822 mail address through - the '+' character in gmail addresses is another one that causes problems... albeit one we already handle well.


2009-04-19 22:46

administrator   ~0001373

I just tried to create an OpenPGP key with GnuPG and the email address , but GnuPG told me that the email address isn't valid.
Can you give examples for publically known and used email addresses with = in them?


2009-04-21 07:55

reporter   ~0001377

<quote src="manpage:mailaddr(7)">
       The local part ("eric") is often a user name, but its meaning is defined by the local software. Sometimes it is
       case sensitive, although that is unusual. If you see a local-part that looks like garbage, it is usually because
       of a gateway between an internal e-mail system and the net, here are some examples:


       (These are, respectively, an X.400 gateway, a gateway to an arbitrary internal mail system that lacks proper
       internet support, an UUCP gateway, and the last one is just boring username policy.)

The GnuPG thingy:
I will test this and may open a bug at GnuPG. Normally I have all all expoert/I-know-what-I-do/... flags set because of a lot reasons. Please test with --allow-freeform-uid


2012-05-28 17:32

reporter   ~0003017

Last edited: 2012-06-02 00:02

I can confirm this bug still exists.

Trying to join with an email address containing slash fails with "Email Address given was invalid, or a test connection couldn't be made to your server, or the server rejected the email address as invalid
Failed to make a connection to the mail server"

Additionally, there is a web backslash escaping problem for single quote: when you try an address with a single quote in it, the returned failed form incorrectly has backslashes added. (This only happens on and on the live server, but not on a server from the cacert-devel.git)

My test address was

Nastier addresses (with spaces, bracketed comments, backslashed double-quotes) are legal under RFC 5322. In my opinion they should be accepted

Issue History

Date Modified Username Field Change
2008-03-16 02:45 ph3 New Issue
2008-03-20 14:24 netsurf Note Added: 0001044
2008-03-20 14:25 netsurf Note Edited: 0001044
2008-03-20 15:02 netsurf Note Edited: 0001044
2008-03-20 15:27 netsurf Note Added: 0001045
2008-03-20 15:29 netsurf Note Edited: 0001045
2008-03-31 14:08 samj Note Added: 0001052
2008-10-14 14:36 ph3 Relationship added related to 0000517
2009-04-07 11:09 ph3 Relationship added has duplicate 0000714
2009-04-19 22:46 Sourcerer Note Added: 0001373
2009-04-21 07:55 ph3 Note Added: 0001377
2012-05-28 17:32 JonathanL Note Added: 0003017
2012-06-02 00:02 JonathanL Note Edited: 0003017
2013-01-11 17:10 Werner Dworak Relationship added related to 0001097