Some names are not sanitised or quoted in Contact extension

[GiovanniSalmeri]

I think I discovered a little problem in Contact. In lines 90-91 $userName and $sitename are used to build an address as they are. The consequence is (for example) that if a comma is present the string is interpreted as two addresses, if a semicolon is present the string is interpreted as a "group" (but without a final colon it is invalid). I have done several tests and the consequence is that when this occurs in $userName the email is not at all delivered.

I see two possible solutions:

1. to sanitise the strings (as $senderName is in line 64), stripping the characters which cannot occur in a RFC2822 atom
2. to quote the strings, also following RFC2822 (but see the other little problem I am going to describe in another discussion)

[markseuffert]

Can you provide some example strings to reproduce the bug and to test with?

[GiovanniSalmeri]

Here are minimal examples:

Error in sending:
Author: Giovanni, Salmeri

No error, but is not delivered (by my sendmail):
Sitename: A beautiful: site

No error, is delivered, but with wrong From:
Sitename: A beautiful, site

Sorry for not providing them earlier!

[markseuffert]

Thank you for the bug report and your patience. I updated the contact extension as suggested, special characters will be removed from addresses. Here are some of the technical details. Addresses can be in one of two formats: [email protected] or Bear Björn <[email protected]>, without or with display name.

• Bear, Björn <[email protected]> becomes normalised to Bear Björn <[email protected]>
• Björn (Support) <[email protected]> becomes normalised to Björn Support <[email protected]>
• "Be, Ba, Bu Björn" <[email protected]> becomes normalised to Be Ba Bu Björn <[email protected]>

Quotes will be removed from the display name in the same way as other special characters. However, if this design turns out to be too restrictive we will be able to add support for quoted strings. With the new software design it's only a matter of which uses cases we want to support and then update the normalisation methods in the core.

Should be fixed now, please try it out.