Page 1 of 1

How to allow commas in address fields?

Posted: Tue Nov 13, 2007 11:27 am
by afwt
I have an odd problem with email addresses containing commas. I cannot use sender's name set to "CompanyName, Inc." because it has a comma in it.

I tried using commas in names for both FROM and TO, and they behave differently on different servers. The code (/Swift/Message/Headers.php:443) says that commas should be used in emails only if it is encoded. How should I encode these? I am simply using $to = new Swift_Address('email@address.com', 'CompanyName, Inc');

What should I wrap $name with in this case?

Posted: Tue Nov 13, 2007 3:05 pm
by John Cartwright
htmlspecialchars() I believe

Posted: Tue Nov 13, 2007 3:22 pm
by afwt

Code: Select all

htmlspecialchars(',') === ','
Nope, ain't that one. None of the native PHP functions (that I know of ) encode commas, that's why I asked... :-(

Posted: Tue Nov 13, 2007 3:37 pm
by John Cartwright
Interesting..

Perhaps a

Code: Select all

str_replace(',', ',', $input);
should work

Posted: Tue Nov 13, 2007 6:35 pm
by feyd
I doubt it's HTML entity encoding. URI style encoding would be my guess, but it could be basic escaping too.

Posted: Wed Nov 14, 2007 10:57 am
by afwt
It ain't neither of those. I don't know what else is there to try.... :-(

Posted: Tue Nov 20, 2007 12:30 am
by vanchuck
I also ran into this problem today.

I couldn't figure out a way to "encode" the comma in a way so that it would consistently show up as a comma in various email clients/webmail systems.

For me, when I tried to use an address like:

Code: Select all

new Swift_Address('address@testing.com', 'Dave Smith, Ph.D');
Swift would end up sending out the email to three recipients:
1) Dave
2) Smith
3) Ph.D <address@testing.com>

So the first two 'recipients' were just a name on a line by themselves, which my mail server would interpret as being for local users, (which would of course bounce unless it happened to match a user on my system!). I believe this could be considered as a bug.

Strangely enough, I also tried backslashing the comma and found that the email was sent to only one recipient, not 3 like above, except with the following quirks:
1) The space between 'Dave' and 'Smith' was gone in the above example
2) The backslash remained visible in the recipient address.

My solution was to just feed in the name surrounded by double-quotes when adding an address, and that worked fine. I don't exactly understand WHY that works though, since the 'getEncoded()' function runs on the Name value of the address properly and outputs the properly-quoted Name string, but I can't track down where that's being used later on in the Send procedure.

Posted: Thu Nov 22, 2007 7:05 pm
by Chris Corbyn
vanchuck wrote:

Code: Select all

new Swift_Address('address@testing.com', 'Dave Smith, Ph.D');
That should work, and if it doesn't it's a bug, not a missing feature. Is this really not working?

Posted: Sat Dec 01, 2007 12:56 pm
by afwt
Yes, I can also verify the same behavior, it sends out to 3 recipients. I use the exact same thing to create recipients.

While tracking it down, I printed out that $data->read() for headers in Swift::send(), and I could see that the string is already well formated:

From: "company1, inc." <email1@example.com>
To: "company2, inc." <email2@example.com>

I experienced this on multiple servers. Somewhere it changes From only, somewhere To only, somewhere both. Exim was used for sure in couple of instances, will try to remember what were the other ones.

I'm afraid this is related to MTA configurations, but it would be nice to know what needs to be changed, so we don't have to tweak the code.... If I tweak it in any way (adding quotes and what not), then Outlook/gmail/etc are showing the titles differently... :-(

Posted: Sat Dec 01, 2007 4:22 pm
by Chris Corbyn
I'll look into this shortly. My understanding at the time I implemented this was that those strings are correct (quotes around the name if it contains a comma). Perhaps I've misread part of the RFC. I'm currently in the process of building version 4 which is due out in Feb so there won't be many big updates to the trunk unless they are major. I'd probably consider this major however.