intouchsystems
asked on
cc field corrupt when receiving emails with umlaut characters
Hi
We current have an issue where when we send emails to one of our sister companies the cc field becomes corrupt at the receivers end when one of the email addresses contains for example a 'ü' character in the email address.
The cc field is appearing like this:
Cc: =?UTF-8?B?RMO8aHJrb3AgR2Vy aGFyZCA8ZH VlaHJrb3BA a295by5kZT 4sIg==?=@e xmf020-4.s erverdata. net; =?UTF-8?B?RUthc2hpd2FnaUBr YmUuY28udW siDQogPEVL YXNoaXdhZ2 lAa2JlLmNv LnVr?=@exm f020-4.ser verdata.ne t; =?UTF-8?B?PiwiaGFydWhpa28u aW51aUBrb3 lvLmRlIg0K IDxoYXJ1aG lrby5pbnVp QA==?=@exm f020-4.ser verdata.ne t; =?UTF-8?B?a295by5kZT4sSGly b3NoaSBTdX p1a2kgPGhp cm9zaGkuc3 V6dWtpQGp0 ZWt0?=@exm f020-4.ser verdata.ne t; =?UTF-8?B?Lm5sPixOYWthbmlz aGkNCiBOb2 J1eXVraSA8 bmFrYW5pc2 hpQGtveW8u ZGU=?=@exm f020-4.ser verdata.ne t; =?UTF-8?B?PixTdmV0bGFuYSBN dW1kemhpYW 4NCiA8c3Zl dGxhbmEubX VtZHpoaWFu QA==?=@exm f020-4.ser verdata.ne t; =?UTF-8?B?anRla3Qubmw+LFlU b21vY2hpa2 FAa2JlLmNv LnVrLEpIYX J0bGV5QGti ZS4=?=@exm f020-4.ser verdata.ne t; =?UTF-8?B?Y28udWssTFJpY2hh cmRzb25Aa2 JlLmNvLnVr ?=@exmf020 -4.serverd ata.net
Instead of the proper email addresses.
We are using Lotus Notes/Domino 8.5.2 and the recipient is using Exchange/Outlook 2007
Any help much appreciated!
We current have an issue where when we send emails to one of our sister companies the cc field becomes corrupt at the receivers end when one of the email addresses contains for example a 'ü' character in the email address.
The cc field is appearing like this:
Cc: =?UTF-8?B?RMO8aHJrb3AgR2Vy
Instead of the proper email addresses.
We are using Lotus Notes/Domino 8.5.2 and the recipient is using Exchange/Outlook 2007
Any help much appreciated!
intouchsystems--Use "ue" instead of ü.
The CC is not corrupt, it is encoded using UTF-8 character standard.
The issue is that it is not clear whether your email client sends it out with the CC field utf-8 encoded or whether it is the receiving side that does that.
Try including your other email address on one of the free email services, hotmail, gmail, yahoo, etc. and see if the CC field is also in UTF-8?
The other option if the recipient chooses to reply to all, is their CC field now displays all the readable email address or not?
In outlook, I think the user can check for the encoding of their client which might when set decode the UTF-8 encoded strings and convert them.
The issue is that it is not clear whether your email client sends it out with the CC field utf-8 encoded or whether it is the receiving side that does that.
Try including your other email address on one of the free email services, hotmail, gmail, yahoo, etc. and see if the CC field is also in UTF-8?
The other option if the recipient chooses to reply to all, is their CC field now displays all the readable email address or not?
In outlook, I think the user can check for the encoding of their client which might when set decode the UTF-8 encoded strings and convert them.
intouchsystems--The cc field you indicate is indeed hard to imagine and does not look like an email address
From where are you getting that address from? Is "@exmf020-4.serverdata.net " the correct domain address?
Is this what you are you entering it into the CC: field.? Where is the umlaut? If you have a more proper email address for that person, ener it manually into the CC: field--even with umlaut.
From where are you getting that address from? Is "@exmf020-4.serverdata.net
Is this what you are you entering it into the CC: field.? Where is the umlaut? If you have a more proper email address for that person, ener it manually into the CC: field--even with umlaut.
Adresses are Base64 encoded, and as far as I can see, using this site: http://coderstoolbox.net/string/ , many of them are incorrect. What mail client are you using, which application is producing these addresses?
I tried a similar umlaut-address to one of my own at Google, it comes in as "=?ISO-8859-1?Q?M=F6=EB=E4 =E7?=" . Which part in the chain translates the address I don't know (yet).
I tried a similar umlaut-address to one of my own at Google, it comes in as "=?ISO-8859-1?Q?M=F6=EB=E4
It's not that the addresses are incorrect, but they are not in RFC822 format as far as I can tell.
ASKER
Thanks for the replies..
We are typing the emails in correctly, and the email addresses themselves don't have a ü in them, but it is the names that are being picked up from various peoples address books that seem to be causing problems, for example one of the guys email address is : Dührkop Gerhard <duehrkop@companyname.de> - this is how it is being set in the cc field, the result in Outlook at the recipients end appears as : Cc: =?ISO-8859-1?Q?D=FChrkop_G erhard_=3C duehrkop=4 0companyna me=2Ede=3E ?=
We are typing the emails in correctly, and the email addresses themselves don't have a ü in them, but it is the names that are being picked up from various peoples address books that seem to be causing problems, for example one of the guys email address is : Dührkop Gerhard <duehrkop@companyname.de> - this is how it is being set in the cc field, the result in Outlook at the recipients end appears as : Cc: =?ISO-8859-1?Q?D=FChrkop_G
ASKER
Further to the above, the attachment shows how our Domino server is currently configured for outbound mail
Capture.JPG
Capture.JPG
> Cc: =?UTF-8?B?RMO8aH
> Cc: =?ISO-8859-1?Q?D=FChrkop
Please explain, is it UTF-8 or ISO 8859-1 ?
Can you check in Notes what exact mail addresses were used? See the addresses in the Document Properties.
> Cc: =?ISO-8859-1?Q?D=FChrkop
Please explain, is it UTF-8 or ISO 8859-1 ?
Can you check in Notes what exact mail addresses were used? See the addresses in the Document Properties.
Usually the Header data is not converted i.e. if the subject of an email is in a foreign non ASCII characters, it will appear with funny characters unless a specific choice was made by the recipient where that encoding map is set in their email client, when they reply to all, do the messages get through or does the now sender receive bounce back NDR for those ?UTF-8? or ?ISO-8859-1? encoded recipients?
ASKER
I have attached another screenshot. The top part is what someone at my organisation has emailed, the bottom part is how it appears at the recipients end.
I believe we are getting both UTF-8 and ISO 8859-1 errors, the last to be received was a UTF-8 error.
When the recipient tries to reply to the corrupt address it will not send.
Untitled.png
I believe we are getting both UTF-8 and ISO 8859-1 errors, the last to be received was a UTF-8 error.
When the recipient tries to reply to the corrupt address it will not send.
Untitled.png
The issue is not the label in the Sending client interface, but the actual content of the data.
i.e.
Cc: Firstname lastname; firstname lastname;
Does not shed light on what the email address is or how it is entered in the local address book.
note the Name of the first Cc recipient has the german U i think it is called umlaut.
It can be represented by a HIGH ascii in ISO-8859-1 it is represented as =FC
ASCII character 252.
To convert the =xy to the ascii code, x*16+y where y can be from 0-F (0-15)
i.e.
Cc: Firstname lastname; firstname lastname;
Does not shed light on what the email address is or how it is entered in the local address book.
note the Name of the first Cc recipient has the german U i think it is called umlaut.
It can be represented by a HIGH ascii in ISO-8859-1 it is represented as =FC
ASCII character 252.
To convert the =xy to the ascii code, x*16+y where y can be from 0-F (0-15)
Oh, there are some client that perform the translation/conversion of UTF or ISO for display, there are others, that only do it when replied and there are still others that do not make any changes.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I have set the field RFC822 phrase handling to use CN as sjef bosman recommended, I will report back with my findings
Eh? Why do you intend to accept your own answer?
ASKER
sorry, must have pressed the wrong button
Aaaah! Thanks!! :-))