[#SVC-1144] replies to offline emails can't contain unicode

2. Second Life Service - SVC

replies to offline emails can't contain unicode

Created: 03/Jan/08 05:18 PM Updated: 01/Feb/10 01:40 PM

Component/s:

Internationalization

Affects Version/s:

None

Fix Version/s:

None

Time Tracking:

Not Specified

Issue Links:

Duplicate

This issue is original of duplicate:

~~SVC-4922~~ Answers to IM by mail do not allow 8-Bit characters - Bounces are generated

Relates

This issue Relates to:

SVC-810 Mail to IM gateway fails if nonstandard ascii characters used

SVC-391 llEmail and llHTTPRequest do not handle non-ASCII characters

SVC-412 Include "Content-Type: text/plain; charset=UTF-8" header in the messages forwarded from second life.

VWR-11942 [Search] It is not possible to retrieve results in Japanese in Search > Places.

SVC-229 Email into world does not work.

~~SVC-44~~ Replying to IMs received is not working

~~SVC-223~~ Replying to an offline IM does not work

This issue is related to by:

SVC-3717 Email from out of SL does not arrive with specific encoding.

~~SVC-4615~~ My e-mail address is "blocked" from SL

SVC-4059 Identify LSL external communications functions not supporting UTF-8

Linden Lab Issue ID:

DEV-19207

Description

« Hide

When you receive an IM while offline with "send offline IM to email" turned on, you get an email containing the IM from a specially formatted email address. You can reply to this IM and your email is sent as an IM response in-world. However, unicode characters are not handled properly by the email to IM gateway.

As far as I can tell, emails containing unicode are sent with the entire body encoded in base64. A content-encoding header in the email alerts an email client that the message is in base64, and that the data is in UTF-8. LL's IM to email gateway cannot decode these messages and silently drops them on the floor, as far as I can tell.

Trying to send unicode characters directly in a plain IM fails as well. Non-ascii characters show up as ?'s in the IM.

This probably makes the reply mechanism useless for chinese speakers and others whose emails cannot be transliterated well into English characters.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Gordon Wendt added a comment - 03/Jan/08 05:54 PM

I'm surprised this hasn't been brought up earlier considering the size of the Japanese community in SL which like Chinese, Korean, Cyrillic, and other non latin character set languages would have this issue.

[ Permlink | « Hide ]

Lex Neva added a comment - 03/Jan/08 06:17 PM

I am too! I'd appreciate if someone more familiar with unicode emails would test this out to be sure I'm not doing it wrong.

[ Permlink | « Hide ]

Alissa Sabre added a comment - 11/Feb/08 06:01 PM

I tested this issue and confirm that a reply email is not received by SL if it contains non-ASCII character.

I tried the following formats, and none of them were received:

charset=UTF-8, content-transfer-encoding: base64, contains some Japanese character.
charset=UTF-8, content-transfer-encoding: quoted-printable, contains some Japanese character.
charset=ISO-2022-JP, content-transfer-encoding: 7bit, contains some japanese character.
charset=UTF-8, content-transfer-encoding: quoted-printable, contains some Latin-1 (rhs ISO-8859-1) chracter.
charset=ISO-8859-1, content-transfer-encoding: quoted-printable, contains some Latin-1 character.

[ Permlink | « Hide ]

Lex Neva added a comment - 11/Feb/08 08:23 PM

Great! Thanks a lot for your help, Alissa.

[ Permlink | « Hide ]

BlckCobra Shikami added a comment - 14/Oct/08 01:21 PM

I found that german umlauts make eMail replies to IMs via eMail bounce reproducible. If I use the substitutes (ue instead of ü etc) the mail arrives properly.

[ Permlink | « Hide ]

Nock Forager added a comment - 23/Jan/09 09:07 AM

Now some changes being done.
You'll reveive error mail when you try to send UTF-8 massage from mail to IM.

You can notice something going wrong at least.

[ Permlink | « Hide ]

BlckCobra Shikami added a comment - 07/Sep/09 08:32 AM

This issue is open since januar 2008 and not the slightest sign that it will be fixed allthough it 's a very annoying thing.

I just debugged a scripted system for 3 hours because certain eMails did not reach the object. I finally figured out why: the eMail contained a german umlaut. Apparently those mails are rejected by the mail server.

There is a clear and simple repro:

case a) respond to an IM which went to your eMail using an umlaut like äüöüß
==> result: your mail is bounced back with an error message and you are unable to correct that and respond again because the one time eMail address from the original IM is invalidated.
case b) send an eMail to a scripted object which accepts mails and include an umlaut in your text.
==> result: eMail never arrives and you never get an error response from the mail server

[ Permlink | « Hide ]

Bibi Book added a comment - 01/Feb/10 01:40 PM

To reproduce: get IM to email. Answer using an "ß" (szet) or a german or danish vovel eg. I think nearly all languages but english will have such characters. After gettign the bounce, replace the character for example by "oe" and send again. if there is no 8 bit character, it will get through even if the header is the same (for 8 bit mail).

Mail header of answer always: Content-Type: text/plain; charset=ISO-8859-1

This is the text of the bounce I get:

"This is the mail system at host smtp1.agni.lindenlab.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<mailtoim@smtp1.agni.lindenlab.com> (expanded from
<za7ckwbbpupibefrkbsbygnsrhwdgqci6bo6uw2xtu5apaexchhbiym7sszdusze@im.agni.lindenlab.com>):
Command died with status 100: "/opt/linden/indra/tools/mailglue/mailglue
--grid=agni --system=im". Command output: Fault from
http://10.2.232.91:12035/xmlrpc/postmaster:
<fault><value><struct><member><name>faultString</name><value><string>Unable
to find method and parameter in
request.</string></value></member><member><name>faultCode</name><value><int>1000</int></value></member></struct></value></fault>"