Community Discussions and Support
problem with handling of comma separated last/given name

Good Morning Guys,

Compliments to all, especially to Olaf, Michael and Thomas R. Stephenson, which are always on duty for finding solutions. It's everytime a pleasure to use this forum and follow interesting therads like this. If I would have more time, I could read the whole day to learn .

Regards

Joerg

<p>Good Morning Guys,</p><p>Compliments to all, especially to Olaf, Michael and Thomas R. Stephenson, which are always on duty for finding solutions. It's everytime a pleasure to use this forum and follow interesting therads like this. If I would have more time, I could read the whole day to learn [I].</p><p>Regards</p><p>Joerg </p>

Hi,

Today we have experienced a little handling problem when creating a Reply to a received e-mail. In case the sender has set his real name additionally to his e-mail address and has separated his last name from his given name by a comma, then Pmail add the following string into the "To:" field of the reply e-mail form:

lastname, givenname <givenname.lastname@domain.tld>

When sending the e-mail, either Pmail or Mercury is creating two separate e-mails: One e-mail is being addressed to "lastname" and the other is being addressed to "givenname.lastname@domain.tld". The second address is correct and will be delivered but the first wrong address creates a Delivery Failure Notification to the postmaster. It seems Pmail or Mercury is searching for any commas because this punctuation mark is the separator for different addresses added within one "To:" or "CC:" box.

This behavior is reproducible also with the own Pmail address book. When creating a new entry at the address book and entering e.g. "lastname, givenname" (or something else comma separated) into the Name field and a valid e-mail address into the E-mail address field, Pmail creates also the following string into the To: field of a new e-mail:

lastname, givenname <givenname.lastname@domain.tld>

In our own address books we could avoid any comma separated entries at the name field, but when receiving such e-mails from the internet we couldn't do anything. How are you handling such things?

Brgds

Joerg

 

&lt;p&gt;Hi,&lt;/p&gt;&lt;p&gt;Today we have experienced a little handling problem when creating a Reply to a received e-mail. In case the sender has set his real name additionally to his e-mail address and has separated his last name from his given name by a comma, then Pmail add the following string into the &quot;To:&quot; field of the reply e-mail form: &lt;/p&gt;&lt;p&gt;lastname, givenname &amp;lt;givenname.lastname@domain.tld&amp;gt;&lt;/p&gt;&lt;p&gt;When sending the e-mail, either Pmail or Mercury is creating two separate e-mails: One e-mail is being addressed to &quot;lastname&quot; and the other is being addressed to &quot;givenname.lastname@domain.tld&quot;. The second address is correct and will be delivered but the first wrong address creates a Delivery Failure Notification to the postmaster. It seems Pmail or Mercury is searching for any commas because this punctuation mark is the separator for different addresses added within one &quot;To:&quot; or &quot;CC:&quot; box.&lt;/p&gt;&lt;p&gt;This behavior is reproducible also with the own Pmail address book. When creating a new entry at the address book and entering e.g. &quot;lastname, givenname&quot; (or something else comma separated) into the Name field and a valid e-mail address into the E-mail address field, Pmail creates also the following string into the To: field of a new e-mail:&lt;/p&gt;&lt;p&gt;lastname, givenname &amp;lt;givenname.lastname@domain.tld&amp;gt;&lt;/p&gt;&lt;p&gt;In our own address books we could avoid any comma separated entries at the name field, but when receiving such e-mails from the internet we couldn&#039;t do anything. How are you handling such things?&lt;/p&gt;&lt;p&gt;Brgds&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

A comma has to be masked in addressfields, if it is not used for seperating two mailaddresses. So the sender of this mail or his mailclient (I think it's Outlook or Webmailer of Exchange:-() should ensure, that the FROM looks like:

"lastname, givenname" <givenname.lastname@domain.tld>

 There's no chance to handle ... if you don't recognize it during answering, the risk may be you send the message to not wanted receipient (if you have activated automatic addresscompletion in Pegasus). In other case you get an internal errormail from Pegasus.

bye   Olaf

 

&lt;p&gt;A comma has to be masked in addressfields, if it is not used for seperating two mailaddresses. So the sender of this mail or his mailclient (I think it&#039;s Outlook or Webmailer of Exchange:-() should ensure, that the FROM looks like:&lt;/p&gt;&lt;blockquote&gt;&lt;p&gt;&quot;lastname, givenname&quot; &amp;lt;givenname.lastname@domain.tld&amp;gt;&lt;/p&gt;&lt;/blockquote&gt;&lt;p&gt;&amp;nbsp;There&#039;s no chance to handle ... if you don&#039;t recognize it during answering, the risk may be you send the message to not wanted receipient (if you have activated automatic addresscompletion in Pegasus). In other case you get an internal errormail from Pegasus.&lt;/p&gt;&lt;p&gt;bye &amp;nbsp; Olaf&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

Hi Olaf,

Understood, thanks.

But why the Pmail address book does not add comma separated names enclosed in quotation marks when using it for a new e-mail? Please try and create a coma separated new entry within the address book. Then mark this entry and push the button "send message". The coma separated  name will be taken over into the "To:" field without quotation marks.

greetings

Joerg

&lt;p&gt;Hi Olaf,&lt;/p&gt;&lt;p&gt;Understood, thanks.&lt;/p&gt;&lt;p&gt;But why the Pmail address book does not add comma separated names enclosed in quotation marks when using it for a new e-mail? Please try and create a coma separated new entry within the address book. Then mark this entry and push the button &quot;send message&quot;. The coma separated&amp;nbsp; name will be taken over into the &quot;To:&quot; field without quotation marks.&lt;/p&gt;&lt;p&gt;greetings&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;

Hallo Jörg,

let's say it that way: much time has passed by since David did the last great rework on adressbook. I noticed this inconvenience many years ago and decided not to include any comma in the aliasfield of any addressbook. Didn't know, that it won't even work as exspected if the aliasname is already in quotationmarks. Quotationmarks at that point is nothing that I can tell my users here ...

bye   Olaf

P.S. You're already fallen to coma? Is it that  precarious? [;)]

 

&lt;p&gt;Hallo J&ouml;rg,&lt;/p&gt;&lt;p&gt;let&#039;s say it that way: much time has passed by since David did the last great rework on adressbook. I noticed this inconvenience many years ago and decided not to include any comma in the aliasfield of any addressbook. Didn&#039;t know, that it won&#039;t even work as exspected if the aliasname is already in quotationmarks. Quotationmarks at that point is nothing that I can tell my users here ...&lt;/p&gt;&lt;p&gt;bye &amp;nbsp; Olaf&lt;/p&gt;&lt;p&gt;P.S. You&#039;re already fallen to coma? Is it that&amp;nbsp; precarious? [;)]&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

Mahlzeit Olaf,

No, this issue is presently not a problem for us. Until now nobody from my users has ever used comas for separating entries within the alias filed of the system address book or any local address book. I have checked it only after experiencing problems with a reply message as descibed above.

But the sender (from the internet) of this message told me, that my e-mail client is not able to handle standard e-mail headers and he is sending messages in form:

lastname, givenname <givenname.lastname@domain.tld>

for so many years without encountering problems from other recipients. What should I say. Has anybody an idea where to adjust Outlook to send standard conform e-mails where the real name is enclosed in quotation marks? may be I could give him a hint.

So far.

Schönen Nachmittag

Joerg

&lt;p&gt;Mahlzeit Olaf,&lt;/p&gt;&lt;p&gt;No, this issue is presently not a problem for us. Until now nobody from my users has ever used comas for separating entries within the alias filed of the system address book or any local address book. I have checked it only after experiencing problems with a reply message as descibed above.&lt;/p&gt;&lt;p&gt;But the sender (from the internet) of this message told me, that my e-mail client is not able to handle standard e-mail headers and he is sending messages in form: &lt;/p&gt;&lt;p&gt;lastname, givenname &amp;lt;givenname.lastname@domain.tld&amp;gt; &lt;/p&gt;&lt;p&gt;for so many years without encountering problems from other recipients. What should I say. Has anybody an idea where to adjust Outlook to send standard conform e-mails where the real name is enclosed in quotation marks? may be I could give him a hint. &lt;/p&gt;&lt;p&gt;So far.&lt;/p&gt;&lt;p&gt;Sch&ouml;nen Nachmittag&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;

My fingers nearly were not able to press the mousebutton while pointer was on Outlook-Symbol ... *uff* *pressed* [;)]

The problem occurs, if the realnamepart of FROM is encoded (so most english users won't recognize that problem, because for non-encoded FROM Pegasus writes quotationmarks arround the realname). So ... the sender has a non-ASCII-character in his realname. Realname is encoded and Pegasus doesn't write the missing quotationmarks. So sender must write his Name in his mailboxconfiguration in Outlook in quotation marks or change to <givenname lastname>.

bye   Olaf

 

&lt;p&gt;My fingers nearly were not able to press the mousebutton while pointer was on Outlook-Symbol ... *uff* *pressed* [;)]&lt;/p&gt;&lt;p&gt;The problem occurs, if the realnamepart of FROM is encoded (so most english users won&#039;t recognize that problem, because for non-encoded FROM Pegasus writes quotationmarks arround the realname). So ... the sender has a non-ASCII-character in his realname. Realname is encoded and Pegasus doesn&#039;t write the missing quotationmarks. So sender must write his Name in his mailboxconfiguration in Outlook in quotation marks or change to &amp;lt;givenname lastname&amp;gt;. &lt;/p&gt;&lt;p&gt;bye &amp;nbsp; Olaf&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

[quote user="FJR"]The problem occurs, if the realnamepart of FROM is encoded (so most english users won't recognize that problem, because for non-encoded FROM Pegasus writes quotationmarks arround the realname). So ... the sender has a non-ASCII-character in his realname. Realname is encoded and Pegasus doesn't write the missing quotationmarks. So sender must write his Name in his mailboxconfiguration in Outlook in quotation marks or change to <givenname lastname>.[/quote]

This issue is known and has been forwarded to David Harris some time ago, but his reading of the RFC regarding this issue is the complete opposite of mine and he wanted to ask its author for judgement (before 4.63 was released). No results of this so far, so it looks like I need to remind him of it again ...

&lt;p&gt;[quote user=&quot;FJR&quot;]The problem occurs, if the realnamepart of FROM is encoded (so most english users won&#039;t recognize that problem, because for non-encoded FROM Pegasus writes quotationmarks arround the realname). So ... the sender has a non-ASCII-character in his realname. Realname is encoded and Pegasus doesn&#039;t write the missing quotationmarks. So sender must write his Name in his mailboxconfiguration in Outlook in quotation marks or change to &amp;lt;givenname lastname&amp;gt;.[/quote]&lt;/p&gt;&lt;p&gt;This issue is known and has been forwarded to David Harris some time ago, but his reading of the RFC regarding this issue is the complete opposite of mine and he wanted to ask its author for judgement (before 4.63 was released). No results of this so far, so it looks like I need to remind him of it again ...&lt;/p&gt;
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

[quote user="FJR"]

The problem occurs, if the realnamepart of FROM is encoded (so most english users won't recognize that problem, because for non-encoded FROM Pegasus writes quotationmarks arround the realname). So ... the sender has a non-ASCII-character in his realname. 

[/quote]

Moin, moin,

That's right, the sender has a mutation caracter in his real name. Here the "From:" field of this e-mail (real last name changed because of data protection)

From: =?iso-8859-1?Q?Krause=2C_J=F6rg?= <Joerg.Krause@domain.tld>

Greetings

Joerg

[quote user=&quot;FJR&quot;]&lt;p&gt;The problem occurs, if the realnamepart of FROM is encoded (so most english users won&#039;t recognize that problem, because for non-encoded FROM Pegasus writes quotationmarks arround the realname). So ... the sender has a non-ASCII-character in his realname.&amp;nbsp; &lt;/p&gt;&lt;p&gt;[/quote]&lt;/p&gt;&lt;p&gt;Moin, moin,&lt;/p&gt;&lt;p&gt;That&#039;s right, the sender has a mutation caracter in his real name. Here the &quot;From:&quot; field of this e-mail (real last name changed because of data protection) &lt;/p&gt;&lt;p&gt;From: =?iso-8859-1?Q?Krause=2C_J=F6rg?= &amp;lt;Joerg.Krause@domain.tld&amp;gt;&lt;/p&gt;&lt;p&gt;Greetings&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;

[quote user="idw"]This issue is known and has been forwarded to David Harris some time ago, but his reading of the RFC regarding this issue is the complete opposite of mine and he wanted to ask its author for judgement (before 4.63 was released). No results of this so far, so it looks like I need to remind him of it again ...[/quote]

David finally agrees with me but believes this requires a bigger overhaul of his MIME parser.

&lt;p&gt;[quote user=&quot;idw&quot;]This issue is known and has been forwarded to David Harris some time ago, but his reading of the RFC regarding this issue is the complete opposite of mine and he wanted to ask its author for judgement (before 4.63 was released). No results of this so far, so it looks like I need to remind him of it again ...[/quote]&lt;/p&gt;&lt;p&gt;David finally agrees with me but believes this requires a bigger overhaul of his MIME parser.&lt;/p&gt;
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

[quote user="idw"]

David finally agrees with me but believes this requires a bigger overhaul of his MIME parser.

[/quote]

Hi Michael,

That means that sender's e-mail client works correctly and only Pmail is presently not able to handle such special Real Names in the FROM section of an e-mail like below, isn't it?

From: =?iso-8859-1?Q?Krause=2C_J=F6rg?= <Joerg.Krause@domain.tld>

 

Joerg

[quote user=&quot;idw&quot;]&lt;p&gt;David finally agrees with me but believes this requires a bigger overhaul of his MIME parser.&lt;/p&gt;&lt;p&gt;[/quote]&lt;/p&gt;&lt;p&gt;Hi Michael,&lt;/p&gt;&lt;p&gt;That means that sender&#039;s e-mail client works correctly and only Pmail is presently not able to handle such special Real Names in the FROM section of an e-mail like below, isn&#039;t it?&lt;/p&gt;&lt;p&gt;From: =?iso-8859-1?Q?Krause=2C_J=F6rg?= &amp;lt;Joerg.Krause@domain.tld&amp;gt;&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;

Hmm ... in RFC822 on page 46 there is an explicit hint:

specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-

                 /  "," / ";" / ":" / "\" / <">  ;  string, to use

                 /  "." / "[" / "]"              ;  within a word.

I don't know if in some other RFC there is an option, that comma mustn't be quoted, if adressfield is encoded. Perhaps IDW knows. Fact is, that Outlook handels it the other way.

bye   Olaf

 

&lt;p&gt;Hmm ... in RFC822 on page 46 there is an explicit hint:&lt;/p&gt;&lt;pre&gt;specials = &quot;(&quot; / &quot;)&quot; / &quot;&amp;lt;&quot; / &quot;&amp;gt;&quot; / &quot;@&quot; ; Must be in quoted- / &quot;,&quot; / &quot;;&quot; / &quot;:&quot; / &quot;\&quot; / &amp;lt;&quot;&amp;gt; ; string, to use / &quot;.&quot; / &quot;[&quot; / &quot;]&quot; ; within a word.&lt;/pre&gt;&lt;p&gt;I don&#039;t know if in some other RFC there is an option, that comma mustn&#039;t be quoted, if adressfield is encoded. Perhaps IDW knows. Fact is, that Outlook handels it the other way. &lt;/p&gt;&lt;p&gt;bye &amp;nbsp; Olaf&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;

[quote user="FJR"]Hmm ... in RFC822 on page 46 there is an explicit hint:[/quote]

RFC 2047 is the proper one here, and I'm too lazy to elaborate, sorry.

&lt;p&gt;[quote user=&quot;FJR&quot;]Hmm ... in RFC822 on page 46 there is an explicit hint:[/quote]&lt;/p&gt;&lt;p&gt;&lt;a href=&quot;http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&amp;amp;letsgo=2047&amp;amp;type=http&amp;amp;file_format=txt&quot; mce_href=&quot;http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&amp;amp;letsgo=2047&amp;amp;type=http&amp;amp;file_format=txt&quot; target=&quot;_blank&quot;&gt;RFC 2047&lt;/a&gt; is the proper one here, and I&#039;m too lazy to elaborate, sorry.&lt;/p&gt;
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

[quote user="FJR"]

specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-

                 /  "," / ";" / ":" / "\" / <">  ;  string, to use

                 /  "." / "[" / "]"              ;  within a word.

[/quote]

That's right, Olaf. But who of an ordinary e-mail user should know that special fact? They type anything into the Real Name field of their e-mail client and trust that the program would claim any signs/characters which are not in compliance with RFC.

Joerg

[quote user=&quot;FJR&quot;]&lt;pre&gt;specials = &quot;(&quot; / &quot;)&quot; / &quot;&amp;lt;&quot; / &quot;&amp;gt;&quot; / &quot;@&quot; ; Must be in quoted- / &quot;,&quot; / &quot;;&quot; / &quot;:&quot; / &quot;\&quot; / &amp;lt;&quot;&amp;gt; ; string, to use / &quot;.&quot; / &quot;[&quot; / &quot;]&quot; ; within a word.&lt;/pre&gt;&lt;p&gt;[/quote]&lt;/p&gt;&lt;p&gt;That&#039;s right, Olaf. But who of an ordinary e-mail user should know that special fact? They type anything into the Real Name field of their e-mail client and trust that the program would claim any signs/characters which are not in compliance with RFC.&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;

[quote user="idw"]RFC 2047 is the proper one here, and I'm too lazy to elaborate, sorry.[/quote]

OK - did not read all relevant. [:$] May be this (from chapter 6.2) is the relevant paragraph:

   Decoding and display of encoded-words occurs *after* a

   structured field body is parsed into tokens.  It is therefore

   possible to hide 'special' characters in encoded-words which, when

   displayed, will be indistinguishable from 'special' characters in the

   surrounding text.  For this and other reasons, it is NOT generally

   possible to translate a message header containing 'encoded-word's to

   an unencoded form which can be parsed by an RFC 822 mail reader.

If I don't missunderstand. in our example with encoded comma the mailclient should be aware, that decoded comma is a special character due to RFC822 and has to be masked or addressheaders have to be handled in a way, that using for creating a mail (i.e. by answering) will not result in unwanted addressing of mails.

&lt;p&gt;[quote user=&quot;idw&quot;]&lt;a href=&quot;http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&amp;amp;letsgo=2047&amp;amp;type=http&amp;amp;file_format=txt&quot; mce_href=&quot;http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&amp;amp;letsgo=2047&amp;amp;type=http&amp;amp;file_format=txt&quot; target=&quot;_blank&quot;&gt;RFC 2047&lt;/a&gt; is the proper one here, and I&#039;m too lazy to elaborate, sorry.[/quote]&lt;/p&gt; &lt;p&gt;OK - did not read all relevant. [:$] May be this (from chapter 6.2) is the relevant paragraph:&lt;/p&gt; &lt;pre&gt; Decoding and display of encoded-words occurs *after* a structured field body is parsed into tokens. It is therefore possible to hide &#039;special&#039; characters in encoded-words which, when displayed, will be indistinguishable from &#039;special&#039; characters in the surrounding text. For this and other reasons, it is NOT generally possible to translate a message header containing &#039;encoded-word&#039;s to an unencoded form which can be parsed by an RFC 822 mail reader.&lt;/pre&gt; &lt;p&gt;If I don&#039;t missunderstand. in our example with encoded comma the mailclient should be aware, that decoded comma is a special character due to RFC822 and has to be masked or addressheaders have to be handled in a way, that using for creating a mail (i.e. by answering) will not result in unwanted addressing of mails. &lt;/p&gt;

[quote user="FJR"]

[quote user="idw"]RFC 2047 is the proper one here, and I'm too lazy to elaborate, sorry.[/quote]

OK - did not read all relevant. [:$] May be this (from chapter 6.2) is the relevant paragraph:

If I don't missunderstand. in our example with encoded comma the mailclient should be aware, that decoded comma is a special character due to RFC822 and has to be masked or addressheaders have to be handled in a way, that using for creating a mail (i.e. by answering) will not result in unwanted addressing of mails.
[/quote]

Please use references from RFC5322 which replaced 2822 which replaced 822 many decades ago. RFC322 is from much later time frame than the RFC2047 too.

The comma is covered in "specials" and still remains for SMTP messages. Handling  under MIME is a whole different subject and not all message are even MIME today still. Only a fraction of email messages have encoded header line portions. They are also not a problem in raw form but when problems begin is when displayed after decoding.

[quote user=&quot;FJR&quot;]&lt;p&gt;[quote user=&quot;idw&quot;]&lt;a href=&quot;http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&amp;amp;letsgo=2047&amp;amp;type=http&amp;amp;file_format=txt&quot; mce_href=&quot;http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&amp;amp;letsgo=2047&amp;amp;type=http&amp;amp;file_format=txt&quot; target=&quot;_blank&quot;&gt;RFC 2047&lt;/a&gt; is the proper one here, and I&#039;m too lazy to elaborate, sorry.[/quote]&lt;/p&gt; &lt;p&gt;OK - did not read all relevant. [:$] May be this (from chapter 6.2) is the relevant paragraph:&lt;/p&gt;&lt;p&gt;If I don&#039;t missunderstand. in our example with encoded comma the mailclient should be aware, that decoded comma is a special character due to RFC822 and has to be masked or addressheaders have to be handled in a way, that using for creating a mail (i.e. by answering) will not result in unwanted addressing of mails. [/quote]&lt;/p&gt;&lt;p&gt;Please use references from RFC5322 which replaced 2822 which replaced 822 many decades ago. RFC322 is from much later time frame than the RFC2047 too.&lt;/p&gt;&lt;p&gt;The comma is covered in &quot;specials&quot; and still remains for SMTP messages. Handling&amp;nbsp; under MIME is a whole different subject and not all message are even MIME today still. Only a fraction of email messages have encoded header line portions. They are also not a problem in raw form but when problems begin is when displayed after decoding. &lt;/p&gt;

[quote user="FJR"]If I don't missunderstand. in our example with encoded comma the mailclient should be aware, that decoded comma is a special character due to RFC822 and has to be masked or addressheaders have to be handled in a way, that using for creating a mail (i.e. by answering) will not result in unwanted addressing of mails.[/quote]

Exactly, that's it.

&lt;p&gt;[quote user=&quot;FJR&quot;]If I don&#039;t missunderstand. in our example with encoded comma the mailclient should be aware, that decoded comma is a special character due to RFC822 and has to be masked or addressheaders have to be handled in a way, that using for creating a mail (i.e. by answering) will not result in unwanted addressing of mails.[/quote]&lt;/p&gt;&lt;p&gt;Exactly, that&#039;s it.&lt;/p&gt;
			Michael
--
IERenderer's Homepage
PGP Key ID (RSA 2048): 0xC45D831B
S/MIME Fingerprint: 94C6B471 0C623088 A5B27701 742B8666 3B7E657C

[quote user="idw"]

This issue is known and has been forwarded to David Harris some time ago, ...

[/quote]

 

OK guys, then I think we got it. It seems Pmail is able to encodes the comma, but do not handle it in the right way for follow-up operations like forwarded or replied e-mails which contain e.g  a comma in the Real Name section of the FROM: field.

Greetings und schoenen Feierabend

Joerg

[quote user=&quot;idw&quot;]&lt;p&gt;This issue is known and has been forwarded to David Harris some time ago, ... &lt;/p&gt;&lt;p&gt;[/quote]&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;&lt;p&gt;OK guys, then I think we got it. It seems Pmail is able to encodes the comma, but do not handle it in the right way for follow-up operations like forwarded or replied e-mails which contain e.g&amp;nbsp; a comma in the Real Name section of the FROM: field.&lt;/p&gt;&lt;p&gt;Greetings und schoenen Feierabend&lt;/p&gt;&lt;p&gt;Joerg &lt;/p&gt;

> They are also not a problem in raw form but when problems begin is when displayed after decoding.

There is no problem in the display however since the name. including the comma, is not enclosed in quotes there is a problem when you do a reply and do not manually add the quotes.  Again, if the name string was not encoded WinPMail would have added the quotes.

&lt;div&gt;&amp;gt; They are also not a problem in raw form but when problems begin is when displayed after decoding.&lt;/div&gt;&lt;div&gt; &lt;/div&gt;&lt;div&gt;There is no problem in the display however since the name. including the comma, is not enclosed in quotes there is a problem when you do a reply and do not manually add the quotes. &amp;nbsp;Again, if the name string was not encoded WinPMail would have added the quotes.&lt;/div&gt;&lt;div&gt; &lt;/div&gt;

Hallo Jerry,

[quote user="Jerry Wise"]Handling  under MIME is a whole different subject and not all message are even MIME today still. Only a fraction of email messages have encoded header line portions.[/quote]

Reads a little bit as if you are thinking, the fraction of MIME-addressheaders is very small. OK - I believe that's true for your mailbox. But come to europe (there are some native english speaking people on a little island indeed, but they are minority - sorry guys [;)]) and your mailbox will hold about a third to half of that headers. And I'm not talking about Russia, China, arabic States with completely different letters ... only "small" Europe with mostly latin letters (with some specialities). My international contacts are mostly restricted to Europe.

cheers    Olaf

 

&lt;p&gt;Hallo Jerry, &lt;/p&gt;&lt;p&gt;[quote user=&quot;Jerry Wise&quot;]Handling&amp;nbsp; under MIME is a whole different subject and not all message are even MIME today still. Only a fraction of email messages have encoded header line portions.[/quote]&lt;/p&gt;&lt;p&gt;Reads a little bit as if you are thinking, the fraction of MIME-addressheaders is very small. OK - I believe that&#039;s true for your mailbox. But come to europe (there are some native english speaking people on a little island indeed, but they are minority - sorry guys [;)]) and your mailbox will hold about a third to half of that headers. And I&#039;m not talking about Russia, China, arabic States with completely different letters ... only &quot;small&quot; Europe with mostly latin letters (with some specialities). My international contacts are mostly restricted to Europe.&lt;/p&gt;&lt;p&gt;cheers &amp;nbsp;&amp;nbsp; Olaf&lt;/p&gt;&lt;p&gt;&amp;nbsp;&lt;/p&gt;
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Cancel
Delete
Pending draft ... Click to resume editing
Discard draft