SiT! Bugs - SiT!
View Issue Details
0001044SiT!inbound emailpublic2010-01-19 09:082011-06-04 16:02
3.90beta1Current GIT 
0001044: Issues with special characters in email addresses
Having discussed this before at length, it has come to our knowledge that characters may be used in email addresses, and it seems to be more and more the case. For internet based providers these are generally not allowed (like hotmail), but it seems in the commercial domains, the rules are more relaxed.

According to RFC 3696 and errata we found this:
The local-part of the e-mail address may use any of these ASCII characters:

    * Uppercase and lowercase English letters (a-z, A-Z)
    * Digits 0 to 9
    * Characters ! # $ % & ' * + - / = ? ^ _ ` { | } ~
    * Character . (dot, period, full stop) provided that it is not the first or last character, and provided also that it does not appear two or more times consecutively.

We have had one customer with a ' in his address, and even though the email now imports correctly (thanks to Ivan's changes to the inbound email script), the further steps like creating the case from the holding queue failed.

I propose that we have a look at this as it may in future become an issue ..
as a temporary workaround i am writing a line into the inbound script for this one guy's email address, but if there are more it will become unmanageable.

I will try to find exactly where the issue is occurring in the creation process as it was not me that created the case.
No tags attached.
Issue History
2010-01-19 09:08nicdevNew Issue
2010-01-19 10:31ivanNote Added: 0002290
2010-01-19 10:31ivanStatusnew => confirmed
2010-02-20 11:59nicdevNote Added: 0002398
2010-03-14 19:04ivanNote Added: 0002696
2010-03-14 19:07ivanTarget Version => 4.0
2010-05-18 18:52nicdevNote Added: 0003158
2010-05-18 18:53nicdevNote Edited: 0003158bug_revision_view_page.php?bugnote_id=3158#r156
2010-12-18 15:47ivanNote Added: 0003507
2010-12-18 15:53ivanNote Added: 0003508
2010-12-18 16:21nicdevNote Added: 0003509
2010-12-18 16:21ivanStatusconfirmed => assigned
2010-12-18 16:21ivanAssigned To => ivan
2010-12-18 16:56ivanNote Added: 0003511
2010-12-19 11:31ivanNote Added: 0003512
2011-02-14 13:21ivanTarget Version4.0 => 3.90beta1
2011-06-04 16:02ivanNote Added: 0003833
2011-06-04 16:02ivanStatusassigned => resolved
2011-06-04 16:02ivanFixed in Version => Current GIT
2011-06-04 16:02ivanResolutionopen => fixed

2010-01-19 10:31   
I wasn't aware we still had these issues, but I agree that we need to do some extensive testing around this and make sure that all possible combinations work fine. It would help a lot to have some test cases, some example email addresses that are known to fail.

You haven't specifically mentioned but I assume that this is an issue for incoming email only?
2010-02-20 11:59   

Yes this is incoming mail issues. I rememeber the guy had a ' in his address.

I need to be at work next week to send an example email.
2010-03-14 19:04   
Tested this with the current Git 4.x branch and the ridiculous email address of


And the tempincoming table held no email address, so yes, somewhere along the line we still have a problem with this.
2010-05-18 18:52   
(edited on: 2010-05-18 18:53)

This also affects Outgoing email, will have to encode all address fields for inbound and outbound email.

We also had an email address with an '&'

2010-12-18 15:47   
If there are issues with outgoing email separate bug reports need to be logged.
2010-12-18 15:53   
Inbound email addresses containing & (ampersand) seem fine to me, testing with 3.63 pre-release (r6800)
2010-12-18 16:21   
Thanks Ivan, I will log another bug for outgoing ;)

When you imported the email, did it show correctly in the holding queue? Meaning did it "find" the contact and put it in the blue part of the list (known contacts)?
2010-12-18 16:56   
r6815 adds a workaround
2010-12-19 11:31   
Yes it shows correctly in the holding queue (with an ampersand in the address). It's not possible to fully test the insane test data address !#$%&'*+-/=?^_`{|} because another bug means you can't configure that to be a contacts address.
2011-06-04 16:02   
Fixed the last part of this in Git 1785753