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.
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:
High characters - characters with the following ordinal values 0..31,61,128..255
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
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.
Related
This document here: https://docs.sendgrid.com/api-reference/mail-send/limitations
States the following:
Unicode encoding is not supported for the from field.
The to.name, cc.name, and bcc.name personalizations cannot include either the ; or , characters.
So I tried a test email to see what happens. I put emojis in the From name, and I sent to a To name of "John,;;, Doe;". There was no error and the email was successfully delivered.
Am I misreading these limitations? I want to make sure that what I build is correctly validating what it sends to the API, but these limitations don't seem to be correctly stated.
While I don't know exactly what the limitations are within SendGrid, I would imagine those limitations were written for a reason. It may well be the case that SendGrid itself can handle each of those characters, but the mailbox you are sending to may not. Obviously the test email that you sent handled those characters too, but that may not be the case for all mailboxes and you could cause yourself delivery problems if you try to send messages that conflict with these stated limitations.
I would stick within the guidelines for the best possible outcome.
I'm working on an email project. For reasons that I will not go into here, doing quoted-printable encoding on long email messages is problematic in the customer's environment.
Doing base64-encoding on the HTML and text sections of the SMTP emails we are sending seems like a viable option. In testing it, it seems to work just fine in a couple test clients (like Gmail).
However I'm wondering if this will present any issues across different email clients. From reading the RFC specs, it looks like base64 is a compliant encoding for text sections, but it's unusual enough for text & html sections that I'd like to know if there will be any potential issues to consider.
Things that seem like problematic possibilities:
perhaps some older or less robust clients don't expect base64 in text or HTML email sections, and will fail to encode it
perhaps some email clients do a preview or search based on the raw content, so recipients would see base64 instead of the actual content
perhaps base64 could negatively influence deliverability/spam scoring?
Does anybody have experiences they can share? This seems like a good solution but I'd like to make sure I'm not missing something.
This is hard to answer -- yes, quoted-printable is used more often simply because it wastes less bytes (on a mostly-ASCII text) and because the raw text of the mail body part resembles the decoded output (on a mostly-ASCII text). There is nothing which forbids using base64 for the textual message parts, though.
This is pretty much an open question -- you cannot ever be sure that a MUA somewhere is not hopelessly broken to the extent of not showing anything. There's a lot of "perhaps" in there, and you're right -- but the problem is that you will never know. If it will make you sleep better, the following companies all use base64-encoded HTML in the marketing spam I'm receiving:
Mellanox
Alza.cz
Aukro.cz
Journal of Modern Physics
Any MUA which can display embedded images has to include a base64 decoder. It is definitely possible that a MUA might explicitly refuse to use that code for decoding text/plain and text/html, but in that case, you're just screwed anyway.
As a fun fact, one of these companies is happy to break the UTF-8 encoded subject at the byte boundary, inside a multibyte character, and encode both halves of the text in separate encoded-words (RFC2047 terminology here).
I got a request from my client that they want to add stars (★) to their email subject (They send these mails through the application we made as a part of bigger CRM for them).
I tried to send a test mail, and the email title is displayed nicely in my Gmail account, and I must agree with my client that it is eye catching, but what came to my mind is that this may be a spam magnet, so I googled about it but I can't find the actual "don't do this".
Generaly, my oppinion would be not to use it, but now I have to explain to the client why. My best explanation whould be there is a probability your emails will be treated as spam but I don't have the background for this statement.
Do you have any suggestions about what should I do?
The only information I could find is on the SpamAssassin page of how to avoid false positives. The only relevant part I found was this part.
Do not use "cute" spellings, Don't S.P.A.C.E out your words, don't put
str#nge |etters 0r characters into your emails.
SpamAssassin is a very widely used spam filtering tool. However, simply breaking one of the rules (strange characters) alone wouldn't get an email marked as spam. But combined with some other problems could lead to your email being considered spam. That being said, if your email is a completely legitimate business email, it's likely that few other rules are triggered, and using the special characters wouldn't create a huge problem. That being said, you should probably try out a couple test emails on SpamAssassin and a couple other spam filtering tools in order to come to a better conclusion on the emails you plan to send out.
Simply explain to your client as you have explained to SO: you stated that the star made it eye catching: this doesn't directly mean that it will be treated as spam, but you could explain how that concept COULD be considered spam.
If the star is part of their branding, however, this could be quite a nice way in which your client expresses themselves.
Spam emails are becoming more and more like what one would consider 'normal', so I think they have trial it internally, test the concept.
Talk it over with your client - there is going to be no basis in hard fact with things like this, purely social perception.
More and more retailers are using unicode symbols in their subject lines since a few months. Of course it's in order to gain more attention in cluttered inboxes. Until now, there has been absolutely no evidence that such symbols increase the likelihood of failing spam filter tests. However, keep in mind that rare symbols might not render (correctly) across all mail user agents. Especially keep an eye on Android and Blackberry smartphones, but also on Outlook. In addition, due to a Hotmail bug symbols will render much bigger in subect lines and in the email body within the web front end. In fact, they are beeing replaced by images. All in all, the star shouldn't make any problems. At least, if it's encoded correctly in the subject line. So, go for it.
I want my web app to send certain mails as HTML in order to include product images.
I could of course provide a text/plain alternative as well, but is it worth the effort in this day and age? Are there common mail clients that don't support text/html, do many people turn it off for some good reason (I suppose spam, bandwidth), are there other reasons such as decreasing the risk of being classified as spam?
I can theorize, but would be interested to hear if someone has statistics, experience or other insight to support or speak against going text/html only.
You are best to send both because:
It helps reduce your spam score, even more so if your text version has the same text and links as your HTML version. This is especially true on Outlook, where no text version almost guarantees it will go the Junk folder.
A lot of people do request a text version on the client-side. Some old Blackberries default to this setting, and Windows Mobile <= v5.
Provide both. HTML in email has a slew of security problems, so those that are security-minded tend to disable HTML email in favor of plain text. Also, reply quoting conventions are fairly well-establised for text/plain data and not for HTML, making meaningful discussions in pure-HTML mail threads ugly.
Since you do have control over the content of the message, please make the plain text version readable. Some MUAs tend to auto-create the text/plain part, and do a horrible job in doing so. So if your messages are intended for customers, make sure the text/plain part is formatted nicely so you do not alienate them.
I believe clients such as iOS mail use the text/plain version to preview the first couple of lines before the user opens the mail.
I think HTML only is OK, but it should be legible without images downloaded. Outlook and Gmail both block images by default to stop tracking and viruses.
You should always have a text/plain alternative. I don't have statistics, but I'm sure that a lot of people disable HTML emails. Including me, because I'm annoyed by all those product images and meaningless fancy newsletters.
Stats I found were that 90% of emails were viewed in html-capable email viewers. If you choose not to include an option for plain text, you could be losing out on 10% of your audience. On the other hand, a well designed html email could more than outperform the 10% loss, so it might be worth the trade off.
I am struggling to get both working on PHP with Hostgator, so I think I'm going to focus on the low hanging fruit (the 90% who view html emails) and not worry about the 10%. Like IE 7, there comes a point where you can no longer support all platforms.
Google does HTML email by default, this includes Google Apps for Business and Google Apps for Educations. Thus millions of Gmail users send and receive HTML email rather than plain text email. Not sure whether there are any better stats than that out there.
Aside from the visual splendor of HTML emails - links are the only thing keeping me from sending plain text emails. They are much simpler for users at times and reduce bandwidth by over 50%. However, forcing my users to copy/paste or (* shiver *) type the URL from the plain text email is not acceptable.
However, it seems like many services such as gmail and hotmail are converting URLs into HTML links. If that's true, then for some lighter emails I could finally switch to plain text (in certain cases) without bothering anyone.
Anyone know what percentage (or what systems or clients) convert text URLs into clickable links?
Some users access via the web (Hotmail/Yahoo/Gmail) while others use clients (Outlook/Thunderbird).
All email progams I know make links clickable, web-based and normal ones.
You should consider putting the links at the end of the mail, and use "[number]" to refer to them:
You should really visit PEAR[1] and friends, PHP[2]!
[1] http://pear.php.net/
[2] http://www.php.net/
That frees you from problems with longer URLs within the text, and it keeps the text readable.
You must not forget one simple fact and that is every mail client make this configurable. So I for one have the option of reading / sending html emails but I don't do that. So it's totally irrelevant how many mail clients support this, the relevant question is how many users have this enabled.