I am testing some HTML emails that I will be sending out to customers, and I have hit a problem when it comes to the images in Gmail.
The image I'm including in the email is sourced from the live website. All other email clients are loading up the images, but Gmail is giving me broken images.
I've worked out that the problem is due to the spacing in the image filenames. Gmail is converting the spaces to a "+".
e.g
https://www.test.com/files/a product image.jpg ---> https://www.test.com/files/a+product+image.jpg
I have tried to replace the image link spaces with %20 but gmail is still converting these to "+" and therefore breaking the image.
I understand that images ideally shouldn't have spaces in them, but the website contains thousands of products, and changing the filenames is not an option in this case.
Does anybody know the reason why Gmail would change a space to a + ? Or even better, a way to fix this problem?
Thanks
Luke
URL cannot contain spaces, those need to be encoded as + or %20. See RFC 1738
The space character is unsafe
and
All unsafe characters must always be encoded within a URL
I stumbled across this question due to an email marketing campaign that had been sent out by a client. Some of the images embedded in the email had spaces in the filenames and consequently, some email providers did not render them correctly in the email campaign. The client asked if I could somehow retrospectively fix it so they did not have to resend (a large recipient list)
So while this is a (very) late answer, it's still relevant
Interestingly Gmail adds a "+" sign, while other email providers (Outlook) allow the space and simply add the "%20" html percent encoding...
My fix: if you for some reason can't modify the original image file stored on the server to remove spaces, you could simply place a .htaccess rule to redirect the URL (on Apache server) as follows;
redirect 301 /images/staff/john+does.jpg https://example.com/images/staff/john%20does.jpg
When the recipient reloaded the email campaign, the broken images all loaded up :)
Related
In our web shop we email customers after each purchase. Up until now all emails displayed properly, but now, in some cases all links inside the email is displayed as doubled plain text. This is happening only to some customers, and I can not find anything about that issue and how to solve it.
Correct Display:
Incorrect Display:
NOTE 1:
I created HTML for that email. The link is wrapped with <a> tag, but when we inspect the incorrectly displayed email, the <a> is removed and only the text is present in the DOM.
NOTE 2:
This is only happening to some customers. We checked and they don't have any ad blocked enabled. Also, this is not browser related issue since they also tried to open email on different browsers.
This happens with Outlook.com and Outlook 365 environments. If the link does not have a http:// or https:// (or other) protocol, it will do this.
Therefore, ensure all your links use a protocol, i.e. ..., and NOT ...
Just in case anyone else winds up here ... we had a similar issue
Our HTML bulk-email (sent programmatically via Exchange) showed formatted correctly in SENT ITEMS, but arrived (when viewed in Outlook) somewhat broken. It was fine if we emailed to e.g. GMail / Hotmail, so probably only a problem with Outlook rendering.
The Outlook presentation was PLAIN TEXT and not Rich / HTML. Noticeable because "View Source" was greyed out. (The content, as sent, definitely had HTML / HEEAD / BODY etc. tags, and it validated OK at W3C - Outlook removed all such HTML tags - seems strange that Outlook decided to display in plain text and then remove all the, correctly coded, HTML tags)
Some, but NOT all, yyy tags displayed wrongly - in particular the tag https://www.example.com/ was what we, eventually, found had caused the email to render (in Outlook) as plain text - all HTML tags stripped and some LINKs rendered wrongly. That HTTPS link did render correctly, but others in the same email which were coded as www.link.com/MyPath rendered as
www.link.com/MyPath<https://www.link.com/MyPath>
same with mailto: links
Removing the HTTPS:// from within the <a href...>HTTPS://xxx</a> tag fixed the problem - took us a while to find though!
So basically it seems that the HREF property should include https:// and the value within the <a> tag should NOT
In checking an email that I am coding (a reply-type email that my server will send), I notice that the a tag hyperlinks in my code are not working in Outlook. They work elsewhere, but not Outlook.
I know very little about Microsoft products, but I can tell you that the place I'm seeing this is in the online outlook.com you view in a web browser.
The simplest link, such as this...
Click here
...is coming through like this in the rendered email:
[http:www.yahoo.com]Click here
AND, it is not a link. It's just text. It appears as though the program is disabling the links (possibly because it finds the email suspicious of phishing, even though I added the domain to my trusted emails)???
Anyone know what is happening or how I can work around this?
I don't see anything wrong with the code you've posted, but I do know that Outlook.com will do this to links when it doesn't recognize them as valid links to an external site. Look for hidden characters, "smart" quotes instead of plain quotes, etc. in the link.
You should put the target on the link.
Like this:
Click here
BACKGROUND:
Sitefinity CMS for my specific problem, but could be general too.
I have an email message which has an unsubscribe link in it like this:
To Unsubscribe: Click or copy paste the following link in your browser.
https://www.domain.com/unsubscribe?mailingList={|MailingList.Title|}&SubscriptionEmail={|Subscriber.Email|}
{|MailingList.Title|} and {|Subscriber.Email|} are sitefinity CMS subscriber fields. When I send out an email these two fields resolve to their respective values. Hence, the URL I get in an email is as following for example.
https://www.domain.com/unsubscribe?mailingList=mymailingList&subscriptionEmail=abc#xyz.com
The user can click on it and unsubscribe from the mailing list.
My Problem:
If the mailing list name has a space in it, the link that appears on the email is broken at the first occurance of the space(link the link shown below breaks immediately =my) and hence clicking it is like clicking a invalid URL.
https://www.domain.com/unsubscribe?mailingList=my mailing List&subscriptionEmail=abc#xyz.com
I dont understand why the space in the URL doesnt resolve to a %20.
My Trial:
I changed the order of the querystrings to see if it works(mailinglist was the last string originally, I put it in the middle)
I am fine if the URL does not get resolved into a link at all, just forcing the users to copy paste the entire URL. But, I was not able to do it as well.
I have read in microsoft forums that OUTLOOK resolves the spacing issue, when the URL is surrounded by < and > like this :
URL here:
But the URL doesnt even show up in the email just like it is not showing up here above this line.
Tested on OUTLOOK, GMAIL, YAHOOMAIL, MICROSOFT MAIL. The link is broken in all email clients.
Any suggestions on what is the best solution for this?
Here's an email template with HTML.
And I tried to copy it in web browswer and paste in Outlook 2007.
But it looks different because border="0" cellpadding="0" cellspacing="0" doesn't work in email.
For the worse, it varies from the each email system(Outlook, Gmail, hanmail...).
Is there any way to work HTML perfectly in every email system?
Thanks, always.
=======================
This is what it should be.
And this is from DAUM Hanmail,
and Gmail.
You see, Html Email has its pros and cons, and these might even vary with the email client too.
Here are some known limitations (some might nolonger be true though):
Large email bodies may not be sent to NotifyLink devices as HTML when Smart Retrieval is enabled (NotifyLink Enterprise Server: Contol Option Rules) or the body size is set to a limit that does not accommodate the email body size. The email will sent in plain text.
Forwarding an HTML email from the device results in the forwarded email showing the original message twice, once in plain text and once in HTML format, when viewed on Oracle Beehive v1.5.x, Scalix, Sun, and Zimbra mail servers.
Using the Retrieve or Retrieve All options will not retrieve a full HTML picture email. This may be due to a bug with the BlackBerry OS v5.0.
An HTML message viewed on the device that includes a phone number will not allow the phone number to be selected for dialing.
The bodies of messages sent using ActiveSync's SmartForward or SmartReply commands will always be in plain text format.
Body text that has been copied and pasted from a MS Word document into emails sent to the device in HTML format are cut off when the email has been sent from a Kerio mail server.
Read more here...
How to Code Html Email correctly
And More Here...
I am afraid that not all email clients render HTML emails in the same way. Even between different version of Microsoft Outlook there are several differences.
You may find interesting the next article
http://www.campaignmonitor.com/css/
Hope this helps.
We've got some HTML emails that get sent out that show email addresses our service has blocked. When viewing the email in Outlook (and presumably in other clients as well) these plain-text email addresses get turned into clickable links that would compose a new message to this address when clicked.
Is there a way to prevent this from happening? Perhaps a meta tag with a flag that would prevent Outlook from converting these into clickable links?
Most email clients strip out META tags, Javascript, and other types of code not necessary for email. Outlook is going to do what it wants with your email, so what you may want to do is wrap the addresses with your own anchor tag and use a blank HREF. Then, style the link to look like the rest of your text.
I think a better answer is to formulate anything that you think a mail client might try to generate a link for in a way that breaks up the string a bit like this: https://stackoverflow.com/a/7625887/470749