Recipients with unquoted commas
There is an issue that is hitting almost every customer who receives messages from other mail-systems.
Many applications send mails in the following format Doe, John <john.doe@acme.com>.
The comma is a delimiter for separating addresses in Notes.
So the correct address would be a quoted address "Doe, John" <john.doe@acme.com>.
If you reply to an unquoted address you can run into very odd unpredictable results because Notes treats the entry as separate addresses and will lookup the first part in your Domino directory.
Unquoted addresses with a comma are not really RFC compliant but some email applications send mail that way.
There is a notes.ini setting that I did not notice before even it is around since 7.0.2.
notes.ini RFC822StripUnquotedDelimiters=1 on your SMTP Server should avoid those issues and also helps for encoded sender names that contain umlauts and other special characters.
IMHO this setting should be default.
-- Daniel
Source:
SPR# JALS658T7S - Mail is parsed into two separate addresses on a reply/reply with history. This fix prevents splitting of RFC822 addresses caused by unquoted commas and semicolons. This fix requires setting the Notes.ini variable "RFC822StripUnquotedDelimiters=1".
- Comments [9]
1Oliver Regelmann 26.08.2013 15:09:11 Recipients with unquoted commas
One of the ugliest bugs of Domino I ever encountered. Has led multiple times to e-mails going to the wrong, partly external recipients.
But I always I understood this has to be set on the SMTP server (not the client). There's a remark about the server configuration document in
{ Link }
And this is currently not working for semi-colons: https://www-304.ibm.com/support/entdocview.wss?uid=swg1LO76264
2Daniel Nashed 26.08.2013 15:30:54 Recipients with unquoted commas
Oops you are correct. It's on the server side. There is a Wiki entry also stating it's for the server. The SPR document is not really specifiy about what happens.
I would say this is not a Domino bug more an interoperability issue.
"Garbage in, garbage out" -- IT principle. The data is wrong. If you have special chars you need quotes!
I have updated the blog post.
-- Daniel
3Daniel Nashed 26.08.2013 15:36:53 Recipients with unquoted commas
SPR #AJAS99PCNY states that semicolons do not work and there is no fix yet even in 9.0.
But in 95% of the cases the "special char" is a comma because of "lastname, firstname" or an umlaut.
-- Daniel
4Reinhard Fellner 29.08.2013 6:14:42 Recipients with unquoted commas
As stated, this is not a bug in IBM Domino, it's just strict RFC-compliant
5Daniel Nashed 29.08.2013 6:38:09 Recipients with unquoted commas
I would say the other side is not RFC compliant and Domino did not expect unquoted special charaters.
So I would say Domino expects RFC compliant behavior.
The best way is to be as RFC compliant for own created email/data etc and be as flexible as possible for email/data received from other systems.
Other systems often have their own intepretation of a RFC/standard. But in this case the other side is just missing the quotes which more looks like an oversight than a different interpretation.
-- Daniel
6Reinhard Fellner 30.08.2013 6:30:00 Recipients with unquoted commas
True and thanks for the info. We already set the parameter and tested it successfully
7Oliver Regelmann 30.08.2013 15:23:44 Recipients with unquoted commas
It IS a Domino bug. See this technote:
{ Link }
Quote: "The problem arose only in the case of special extended characters used in the From field. The reason is that these caused the sending system to convert the whole descriptive part into an ISO-8859-string which does not contain any spaces, commas or special characters. This phrase is used unquoted and makes the From field completely RFC-822 compliant."
8Daniel Nashed 02.09.2013 8:29:39 Recipients with unquoted commas
It's arguable if this is a bug when the comma occurs in the friendly name and it is not enclosed in quotes.
My point is more that this setting should be set by default to avoid the issue.
-- Daniel
9Jörg Asmussen 03.10.2013 9:16:55 Recipients with unquoted commas
Oliver's link suggests that it's a combination of international characters and commas in the same from field. What if it only contains commas, but no international characters?