We have an internal report that is sent as an html email. The html contains a table and the first cell of each row in the table is an image.
The image is added like this:
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-ID: <image-0>
Content-Disposition: inline
and in the html part:
<td style="text-align:right; padding-left:10px" align="right"><img src="cid:image-0"></td>
This is made to work in gmail as it is viewed in gmail only. it works fine on my machine and as far as I know everyone else except one person has an issue in which some of the image are never displayed. All tricks about cleaning cache, refreshing, restarting do not help. It also seems to be consistently the same images that are not displayed. And they are "randomly" not showing. so it's not just at the start or end but just "randomly" in the table.
Therefore what could cause this? Is there some settings in gmail or even chrome affecting this? I was thinking some kind of size limit (as in kb of a specific image)?
EDIT:
turns out I'm affected too and other users as well. The images don't load consistently and refreshing will load different images and fail with others (race condition?). Even more the email displays fine in the gmail mobile application.
Related
We have a web admin panel in which the agents can see conversations with customers.
Those conversations are the result of importing normal emails thru an IMAP connection. We grab the "untouched" mailbox files and we store them in a database. Then we post-process the files to index by "from", "to", "date" and so on and so forth.
Up to here, okey. We can seek all the emails involved with a client and render them at will.
Then when the agent looks for a customer in the web admin panel and opens it, the full email conversation appears. And we display the HTML version of the email within an iframe (or the text version if the html version is not there). 90% of the customers send HTML.
What happens? Upon the agent opening the email in our web, the iframe loads the "full html" and renders it. This makes "remote loading" (images, sounds, styles if so, and whatever) to be downloaded. This allows customers to "track" if we opened the email by appending tracking id's to the assets (typical http://track.example.com/image.jpg?id=123456789)
I've tried the "sandbox" attribute of the iframe html tag with no luck (it still downloads the images).
Question
How can I programmatically tell the iframe to not load ANY remote content, and just render the initial HTML without any remote call?
Mozilla's iframe documentation listing all available attributes for the is here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe
If you look at "sandbox" there is no restriction specific to image or other includes, just restrictions on things like running JavaScript. There are no other attributes that would restrict images and includes.
To solve the problem of images and includes in your HTML you will need to filter the HTML either at the server before sending it or in the client after it arrives.
Server:
Before storing it into the database.
In the code that retrieves the HTML and returns it to the iframe.
Client:
Use AJAX to fill the iframe with the HTML, with code that filters a
response. With this approach you could also use a div instead of an
iframe if that works better for your layout.
If all of your users will use Chrome or Firefox, you could look at writing a browser extension
Sometimes the rendered display of an HTML email body is incorrect. Eg:
OC gmail is rendered correct
Mobile app gmail is rendered correct
Mobile web gmail is rendered incorrect
This problem occurred only on mobile web gmail.
HTML body has a <table> tag. In the incorrect case, this table tag is broken with part of <div> tag.
I tried several times in mobile web gmail. The first email displayed correctly
but the second email displayed incorrectly.
My question is: why this happen? How do I fix it?
It's been a while since this question was asked, but I ran across the same problem myself now in 2022.
First of course I looked for the error on our end and rebuilt html/css. However, I could not find the error, it seemed to happen completely randomly.
A completely identical email sometimes looked perfectly fine, sometimes it was rendered completely broken (this can also be seen by looking at the HTML code: clean code turned into a completely chopped up array of HTML code that was definitely not ours (especially early terminated HTML tables, heaps of "empty" snippets, etc).
Then, by chance, I noticed that this phenomenon does NOT occur if I permanently delete similar emails that are ALREADY in the trash (sic!).
I have been able to narrow down the problem even further: apparently GMail bundles messages, from the same domain and with the same subject line, even if they are in the trash (however, you do NOT see this directly in the inbox, but only when you are on the (broken) email in question and refresh by dragging down (mobile) - all of a sudden, all the trash messages are additionally visible at the top of this message).
I was able to fix the problem by always writing value into the subject line that does not match any other email. This avoids the incorrect bundling and the mails look flawless again.
Cost me a lot of nerves and half a day's work - maybe I can save this for someone with my contribution.
I have a html file (generated via knitr package in R). It has a image which is encoded as data uri so there is no need for image attachments. Here is the link to that sample.html
http://jsfiddle.net/ebwsozav/
Sending it as an attachment, hasnt been issue but now we want to send this html to be embedded into the content of the email.
Using mutt, mutt -e "set content_type=text/html" -- person#gmail.com < sample.html.
Upon opening the email, I realised that the image couldnt be seen, though the html tables and other content could be.
Screenshot attached here
I read that gmail blocks images.
Could this the reason and is there a way to circumvent this problem ?
Update
Outlook cant view it.
Gmail in Android not able to view.
But surprise,surprise
Gmail in iOS system is able to view the image.
I read that gmail blocks images.
Partially correct. Gmail filters data URIs from being displayed in its interfaces, but it allows you to download/forward the original message (including the data URI) to a mail client that doesn't filter it. It does block (all) images on messages flagged as spam.
is there a way to circumvent this problem ?
Not exactly. You have to either use a regular URL or attach the image. It is intended for there to be no way to use data URIs in their interface.
I am generating a pdf on the server that I would like browsers to attempt to open in-tab (those browsers that can do so) instead of downloading.
I was pretty sure that this is a matter of having or not having some header but I can't find it. Is it possible to control whether the user's browser displays or downloads your asset?
Acrobat Reader X have a checkbox under Edit > Preferences > Internet to enable or disable in-browser view, regardless of the status of the browser plugin.
If that check is ok, or you have a more recent version, you can check if the plugin is active in you browser, every browser have different plugin.
A fast check is to open a local pdf file in your browser, something like file://localhost/C:/dir1/.../file.pdf, if Adobe Reader have the right check and the plugin is working the file will be showed in the browser otherwise, even if it is a local file, the browser will ask a folder to download it.
So in my specific case I was sending the wrong content-type (thanks #admdrew for pointing me in the right direction) due to coding a constant wrong.
However, the answer is that there is indeed a header - at least when working with pdfs that will suggest to chrome at least whether it should open or download a file. This header is Content-Disposition. In my case setting it:
Response.Headers["Content-Disposition"] = #"attachment; filename="foo.pdf"
triggered a download, while omitting it triggered in-page opening.
In addition, the above link states
If this header is used in a response with the application/octet-
stream content-type, the implied suggestion is that the user agent
should not display the response, but directly enter a `save response
as...' dialog.
Though I found using Content-Type: application/pdf worked ok in both cases.
I've just encountered some weird behavior in Gmail that looks like some new kind of phishing attack. I got a couple shipment confirmations from Amazon today and there are these "Track Package" buttons (also I see "View Order" buttons on order confirmations) but when I click on them the page that gets opened is clearly not the correct shipper's web site.
Which looks fine but clicking on those buttons lead to bad pages. For example one of them goes to http://websro.correios.com.br. On the other it goes to USPS.com while the actual shipper (and correct link in the email body) goes to UPS.com.
I've looked at the source of the email and it all looks fine. There are no SCRIPT tags of any kind and no bogus links anywhere in the text (by which I also mean the HTML). The problem appears the same in Safari (6.1.1) and Chrome (31.0.1650.63). It looks normal in Mail (both Mountain Lion and iOS 5).
I couldn't figure out how such a button could get there and I found this feature for adding "registered" script actions to Gmail which is the only thing I can imagine would affect both Safari and Chrome.
When an order confirmation or parcel delivery email doesn't contain the necessary microdata to trigger the action, Gmail can still try to automatically extract the same information and show the button to the user as if the microdata was present.
Clearly this approach is less accurate than the one that relies on microdata, and it seems that in your case something went wrong with the automatic parsing.
No need to be worried about phishing though, as actions only show up for registered senders.