views:

299

answers:

2

For the past year at least now a good dozen or so of the users of my site have experienced odd characters showing up in the emails they receive. I've researched the issue numerous times and have pretty much written it off to be some sort of encoding issue on the users' end. That conclusion doesn't really sit quite right with me since I've never been able to replicate the issue.

The odd characters aren't really even characters, they're a series of characters which represent high characters such as periods. =2e, for instance, appears where ever periods should appear. Some other character string appears for each line end. According to what I've researched in the past, this type of encoding is fairly standard and is called Quoted Printable and only very old email software is unable to read it. Each time this occurs I ask the same old barrage of questions about the operating environment the affected user is working with and they are never using an older client so QP should be rendered correctly. There is seemingly no difference between a recipient affected by the issue and one which is not.

The emails that are affected are sent automatically by my web server and no special encoding is applied. Pretty standard sent from an ASP classic application using ASPMail by ServerObjects Inc.

Anyone have any ideas what could cause this, or am I corrected in assuming its an end-user encoding issue not rendering properly??


A little update on this...

I recently found out that if we are to send the mail from our server as plain text rather than HTML mail - the weird characters do not exist. This only occurs when HTML mail is sent.

A: 

I have come across this info on their site:


Some of our emails are getting equal signs at the end of lines in some messages. Why?
AspMail can encode high characters using a scheme where the = sign indicates a character to be decoded follow by the hex string value of the character to be encoded. This system of course assumes that the client can decode these characters (which most can). This is called quoted-printable encoding. The default for AspMail is not to use QP encoding. Things that trigger automatic QP encoding:

  1. High characters - characters with the following ordinal values 0..31,61,128..255
  2. Long lines of a message body (>255). You can turn wordwrap on to fix this case

Most clients are capable of handling QP encoding. If your client is not capable then you should upgrade your client or you must work within the above limitations to prevent the QP encoding from occuring.


So from what I understand from that is they are pinning it on the end user's client

Arch
Yeah I had come across that tidbit on ServerObject's website.I suppose the thing that gets me here is that the above explains the issue until you factor in how many people are affected as well as the clients they are using. I would expect that some of the newer mail software can decode QP. I would also expect only a minor amount of users to be experiencing the issue, not a dozen+.
Mark
Mark
Is it possible to get your hands on a mail account on one of the servers of the clients that are experiencing this issue so that you can send youself an email and do all the tests on it
Arch
A: 

We have this problem at work. Users will get odd characters, stripped characters, missing content, etc. Most of the time it is due to the email software. CSS in emails causes odd problems with Outlook and Gmail. We had one circumstance where an email was supposed to say, "Hello Bob" and it just said, "Hell Bob".

If the user gets their email forwarded from one account to another then chances are good they will get an email that was filtered by the forwarding account. So if Gmail strips out characters, where ever it forwards that email the recipient will get the stripped out characters.

We had other issues with our emailing service not merging the templates and data correctly but that doesn't seem to be the case here.

Wix
That's an interesting thought Wix. Email forwarding never crossed my mind. I'll ask around and see how many of the affected users are using email forwarding. I'm wondering if that's the case, and the first mail account is decoding it but forwarding to the second mail account as the original encoded mail in plain text.
Mark
Check out this site also. http://www.email-standards.org/acid-test/ shows what HTML tags popular email clients will strip out.
Wix