Email subject line showing =?us-ascii?Q in front of actual subject

[SW]

Hi,
Currently, I am using Outlook Express and sometimes I will see "=?us-ascii?"
in front of my email acutal subject text. For example: "=?us-ascii?Test
e-mail?" If I highlight the email and view the preview, I will see the email
subject is only showing the actual email subject - "Test e-mail". Wondering
if anyone can help me to understand why or when Outlook Express is showing
"=?us-ascii?" in front of the actual subject text? However, if I use Outlook
2007 or hotmail to view the same email, I won't see it. So I am thinking
it's related to Outlook Express only?

[PA Bear [MS MVP]]

Windows version?

So you only see if you open the message and don't see it in the Preview
pane?

Open such a message and tell me what's selected here: View | Encoding

[VanguardLH]

SW wrote:

The =?<charset>?<encoding>?<encodedtext>?= is a means of UTF encoding
the content (i.e., to add Unicode support for e-mail which is
transmitted using ASCII characters). In this case, it was stupid to
"encode" the string using ASCII since ASCII is the base character set.
UTF is often used to encode a string using different characters sets
often but not always to support other languages.

http://en.wikipedia.org/wiki/Unicode_and_e-mail

http://tools.ietf.org/html/rfc2047

It appears that whomever is sending an encoded string in the Subject
doesn't understand the correct syntax as noted in RFC 2047. Since it is
screwed up, the e-mail client can't handle it. Of course, it's possible
you copied it incorrectly.

[Michael Santovec]

Whenever I've seen that, it's always been spam or a virus. And it's
because the spam or virus generating program screwed up the message
format.

Are any of those valid messages from your friends or family?

--

Mike - http://TechHelp.Santovec.us

"SW" <S...@discussions.microsoft.com> wrote in message
news:C7901068-3743-455C...@microsoft.com...

[SW]

The outlook express comes with Windows XP SP2.

> .
>

[SW]

Original message was sent by Microsoft Dynamic CRM 4.0 and the system does
support multi-language. I am really new to these email encoding or
decoding... just as a thought, if it is sender encoding issue, then why only
Outlook Express is showing this =?us-ascii?Q, but not Outlook 2007?

"VanguardLH" wrote:

> .
>

[SW]

These emails are sent from Microsoft Dynamic CRM 4.0. In fact, from myself
to myself as testing.

"Michael Santovec" wrote:

> .
>

[PA Bear [MS MVP]]

And my other 2 questions...?

[Michael Santovec]

You might want to start here then

http://msdn.microsoft.com/en-us/dynamics/crm/default.aspx

--

Mike - http://TechHelp.Santovec.us

"SW" <S...@discussions.microsoft.com> wrote in message

news:DEB2D97C-2EDE-41FB...@microsoft.com...

[VanguardLH]

SW wrote:

> "VanguardLH" wrote:

>
>> SW wrote:
>>
>>> Currently, I am using Outlook Express and sometimes I will see

>>> "=?us-ascii?" in front of my email acutal subject text. ...

>>> Wondering if anyone can help me to understand why or when Outlook
>>> Express is showing "=?us-ascii?" in front of the actual subject
>>> text? However, if I use Outlook 2007 or hotmail to view the same
>>> email, I won't see it.
>>

>> The =?<charset>?<encoding>?<encodedtext>?= is a means of UTF
>> encoding the content (i.e., to add Unicode support for e-mail which

>> is transmitted using ASCII characters). ... UTF is often used to

>> encode a string using different characters sets often but not always
>> to support other languages.
>

> Original message was sent by Microsoft Dynamic CRM 4.0 and the system
> does support multi-language. I am really new to these email encoding
> or decoding... just as a thought, if it is sender encoding issue,
> then why only Outlook Express is showing this =?us-ascii?Q, but not
> Outlook 2007?

There are 2 parameters in the syntax specified by the RFC: the character
set and the encoding scheme. If all that is actually needed is the
character set (so the e-mail client needs to know which one to use in
displaying the rendered or decoded version of the string), it can guess
or ignore the encoding scheme. OE is a 6-year dead program so it hasn't
been updated for a long time.

E-mail clients guess at a lot of things in an e-mail. For example, a
URL string is just text yet many e-mail clients will make it a clickable
link. They parse the e-mail and something that looks like a URL string
gets special handling, even when reading in plain-text mode. There are
no things as clickable links sent in e-mail. Even for HTML-coded
messages, it is all text in the message and the tags indicate what is a
link but it is up to how the e-mail client renders that message to
determine if it will show the string as clickable.

Also, encoding is usually just "Q" (for quoted-printable format) or "B"
(for Base64 encoding). I haven't kept statistics on how many e-mails
had which type of encoding but I doubt Base64 gets used (it is primarily
used for encoding binary attachments in an e-mail). Well, that only
leaves the Q encoding so an e-mail client can probably safely default to
using that scheme. Yet, in a header, even quoted-printable format
doesn't make sense since physical wrapping for logical sentences could
produce a blank line and a blank line is the delimiter between the
header and body sections in an e-mail. In headers, the encoding
parameter isn't needed, probably gets ignored, so the e-mail client
won't use it if specified. From the RFC that I mentioned:

The "Q" encoding is recommended for use when most of the characters to
be encoded are in the ASCII character set; otherwise, the "B" encoding
should be used. Nevertheless, a mail reader which claims to recognize
'encoded-word's MUST be able to accept either encoding for any
character set which it supports.

So it looks like an e-mail client can guess the encoding scheme based on
the charset that was specified. No encoding scheme is required for
ASCII.

Normally, from what I've seen, the charset specified is something like
iso-8859-1 or utf-8. I haven't seen one with us-ascii as it would be
superfluous. My guess is that OE doesn't know how to handle a charset
that it doesn't know about (no e-mail client would) and us-ascii wasn't
considered for inclusion in their table of charsets because no encoding
is required (i.e., the =?...?= doesn't make sense if ASCII was used;
it's like saying you want the blue blue crayon). A whole slew of
charsets are defined at http://www.iana.org/assignments/character-sets;
however, being in the list doesn't mean an e-mail client supports all of
them. Since ASCII is the baseline character set, there is no point in
specifying that is the character set being used.

You probably ran into a bug in a long-dead program.

[Erik Almquist]

We suffered from this problem, too, until we started sending test emails from a blank email template with the subject 'Dog'. We gradually increased the complexity of the subject until we got this same error. To make a long story short, when an email template contained a subject of greater than 70 characters, the error appeared. We talked to our marketing department about it and they gladly agreed to reduce the subject's characters to fit this odd limitation. Please respond to this post if this workaround is applicable to your situation and if it works. Thanks.

> On Tuesday, November 17, 2009 11:58 PM SW wrote:

> Hi,
> Currently, I am using Outlook Express and sometimes I will see "=?us-ascii?"
> in front of my email acutal subject text. For example: "=?us-ascii?Test
> e-mail?" If I highlight the email and view the preview, I will see the email
> subject is only showing the actual email subject - "Test e-mail". Wondering
> if anyone can help me to understand why or when Outlook Express is showing
> "=?us-ascii?" in front of the actual subject text? However, if I use Outlook

> 2007 or hotmail to view the same email, I will not see it. So I am thinking
> it is related to Outlook Express only?

>> On Wednesday, November 18, 2009 1:21 AM PA Bear [MS MVP] wrote:

>> Windows version?
>>
>> So you only see if you open the message and do not see it in the Preview
>> pane?
>>
>> Open such a message and tell me what is selected here: View | Encoding
>>
>>
>> SW wrote:

>>> On Wednesday, November 18, 2009 1:42 AM VanguardLH wrote:

>>> SW wrote:
>>>
>>>
>>> The =?<charset>?<encoding>?<encodedtext>?= is a means of UTF encoding
>>> the content (i.e., to add Unicode support for e-mail which is

>>> transmitted using ASCII characters). In this case, it was stupid to
>>> "encode" the string using ASCII since ASCII is the base character set.

>>> UTF is often used to encode a string using different characters sets
>>> often but not always to support other languages.
>>>

>>> http://en.wikipedia.org/wiki/Unicode_and_e-mail
>>>
>>> http://tools.ietf.org/html/rfc2047
>>>
>>> It appears that whomever is sending an encoded string in the Subject

>>> does not understand the correct syntax as noted in RFC 2047. Since it is
>>> screwed up, the e-mail client cannot handle it. Of course, it is possible
>>> you copied it incorrectly.

>>>> On Wednesday, November 18, 2009 5:44 PM Michael Santovec wrote:

>>>> Whenever I have seen that, it is always been spam or a virus. And it is

>>>> because the spam or virus generating program screwed up the message
>>>> format.
>>>>
>>>> Are any of those valid messages from your friends or family?
>>>>
>>>> --
>>>>
>>>> Mike - http://TechHelp.Santovec.us

>>>>> On Thursday, November 19, 2009 2:19 AM SW wrote:

>>>>> The outlook express comes with Windows XP SP2.
>>>>>
>>>>> "PA Bear [MS MVP]" wrote:

>>>>>> On Thursday, November 19, 2009 2:55 AM SW wrote:

>>>>>> Original message was sent by Microsoft Dynamic CRM 4.0 and the system does
>>>>>> support multi-language. I am really new to these email encoding or
>>>>>> decoding... just as a thought, if it is sender encoding issue, then why only
>>>>>> Outlook Express is showing this =?us-ascii?Q, but not Outlook 2007?
>>>>>>

>>>>>> "VanguardLH" wrote:

>>>>>>> On Thursday, November 19, 2009 3:07 AM SW wrote:

>>>>>>> These emails are sent from Microsoft Dynamic CRM 4.0. In fact, from myself
>>>>>>> to myself as testing.
>>>>>>>
>>>>>>> "Michael Santovec" wrote:

>>>>>>>> On Thursday, November 19, 2009 1:50 PM PA Bear [MS MVP] wrote:

>>>>>>>> And my other 2 questions...?
>>>>>>>>
>>>>>>>> SW wrote:

>>>>>>>>> On Thursday, November 19, 2009 2:28 PM Michael Santovec wrote:

>>>>>>>>> You might want to start here then
>>>>>>>>>
>>>>>>>>> http://msdn.microsoft.com/en-us/dynamics/crm/default.aspx
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Mike - http://TechHelp.Santovec.us

>>>>>>>>>> On Thursday, November 19, 2009 4:54 PM VanguardLH wrote:

>>>>>>>>>> SW wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> There are 2 parameters in the syntax specified by the RFC: the character
>>>>>>>>>> set and the encoding scheme. If all that is actually needed is the
>>>>>>>>>> character set (so the e-mail client needs to know which one to use in
>>>>>>>>>> displaying the rendered or decoded version of the string), it can guess

>>>>>>>>>> or ignore the encoding scheme. OE is a 6-year dead program so it has not

>>>>>>>>>> been updated for a long time.
>>>>>>>>>>
>>>>>>>>>> E-mail clients guess at a lot of things in an e-mail. For example, a
>>>>>>>>>> URL string is just text yet many e-mail clients will make it a clickable
>>>>>>>>>> link. They parse the e-mail and something that looks like a URL string
>>>>>>>>>> gets special handling, even when reading in plain-text mode. There are
>>>>>>>>>> no things as clickable links sent in e-mail. Even for HTML-coded
>>>>>>>>>> messages, it is all text in the message and the tags indicate what is a
>>>>>>>>>> link but it is up to how the e-mail client renders that message to
>>>>>>>>>> determine if it will show the string as clickable.
>>>>>>>>>>
>>>>>>>>>> Also, encoding is usually just "Q" (for quoted-printable format) or "B"

>>>>>>>>>> (for Base64 encoding). I have not kept statistics on how many e-mails

>>>>>>>>>> had which type of encoding but I doubt Base64 gets used (it is primarily
>>>>>>>>>> used for encoding binary attachments in an e-mail). Well, that only
>>>>>>>>>> leaves the Q encoding so an e-mail client can probably safely default to
>>>>>>>>>> using that scheme. Yet, in a header, even quoted-printable format

>>>>>>>>>> does not make sense since physical wrapping for logical sentences could

>>>>>>>>>> produce a blank line and a blank line is the delimiter between the
>>>>>>>>>> header and body sections in an e-mail. In headers, the encoding

>>>>>>>>>> parameter is not needed, probably gets ignored, so the e-mail client
>>>>>>>>>> will not use it if specified. From the RFC that I mentioned:

>>>>>>>>>>
>>>>>>>>>> The "Q" encoding is recommended for use when most of the characters to
>>>>>>>>>> be encoded are in the ASCII character set; otherwise, the "B" encoding
>>>>>>>>>> should be used. Nevertheless, a mail reader which claims to recognize
>>>>>>>>>> 'encoded-word's MUST be able to accept either encoding for any
>>>>>>>>>> character set which it supports.
>>>>>>>>>>
>>>>>>>>>> So it looks like an e-mail client can guess the encoding scheme based on
>>>>>>>>>> the charset that was specified. No encoding scheme is required for
>>>>>>>>>> ASCII.
>>>>>>>>>>

>>>>>>>>>> Normally, from what I have seen, the charset specified is something like
>>>>>>>>>> iso-8859-1 or utf-8. I have not seen one with us-ascii as it would be
>>>>>>>>>> superfluous. My guess is that OE does not know how to handle a charset
>>>>>>>>>> that it does not know about (no e-mail client would) and us-ascii was not

>>>>>>>>>> considered for inclusion in their table of charsets because no encoding

>>>>>>>>>> is required (i.e., the =?...?= does not make sense if ASCII was used;
>>>>>>>>>> it is like saying you want the blue blue crayon). A whole slew of

>>>>>>>>>> charsets are defined at http://www.iana.org/assignments/character-sets;

>>>>>>>>>> however, being in the list does not mean an e-mail client supports all of

>>>>>>>>>> them. Since ASCII is the baseline character set, there is no point in
>>>>>>>>>> specifying that is the character set being used.
>>>>>>>>>>
>>>>>>>>>> You probably ran into a bug in a long-dead program.

>>>>>>>>>> Submitted via EggHeadCafe - Software Developer Portal of Choice
>>>>>>>>>> Nested IF Statement ? Excel 2007
>>>>>>>>>> http://www.eggheadcafe.com/tutorials/aspnet/195df521-46a8-4b2f-a6aa-dad1fb2c63d5/nested-if-statement--excel-2007.aspx

[Pat McRotch]

Doofus Eggheader.

"Erik Almquist" <ealm...@hirtlecallaghan.com> wrote in message
news:2010101315...@eggheadcafe.com...

[Jack Heine]

We discovered this issue on a code-generated e-mail with the subject line "Thank you for your donation " changing to "=?us-ascii?Q?Thank you for your donation ?=".

It is far less than 70 characters and none of the characters are out of the ordinary. Have you had any issues since?

>>>>>>>>>>> On Wednesday, October 13, 2010 3:21 PM Erik Almquist wrote:

>>>>>>>>>>> We suffered from this problem, too, until we started sending test emails from a blank email template with the subject 'Dog'. We gradually increased the complexity of the subject until we got this same error. To make a long story short, when an email template contained a subject of greater than 70 characters, the error appeared. We talked to our marketing department about it and they gladly agreed to reduce the subject's characters to fit this odd limitation. Please respond to this post if this workaround is applicable to your situation and if it works. Thanks.

>>>>>>>>>>>> On Wednesday, October 13, 2010 4:52 PM Pat McRotch wrote:

>>>>>>>>>>>> Doofus Eggheader.

>>>>>>>>>>>> Submitted via EggHeadCafe
>>>>>>>>>>>> Review of Redgate ANTS Performance Profiler 6
>>>>>>>>>>>> http://www.eggheadcafe.com/tutorials/aspnet/945b0f4a-55b9-4799-aaa3-bcbed4131446/review-of-redgate-ants-performance-profiler-6.aspx