Why, you might wonder, is this happening? Well, to be clear, this only happens when receiving an e-mail written in Gmail originally (a regular old fashioned link without the Gmail formatting added on works fine).
Google inserts an image after the link and that image URI does not contain a protocol (
https). It looks something like this:
Now, in a web browser, this will work just fine; the browser will use whatever protocol was used to load the page (usually
https these days).
In Outlook, however, this is interpreted as a Windows File Sharing link.
So, Outlook decides to try to access that address using Windows File Sharing (on port 445) and, rather than denying the request, Google just ignores it, and Outlook stops responding until it times out 30 seconds later. And Outlook does this every time you open the message.
If you forward the message, Outlook tacks on a
file protocol to the image URI:
And, of course, if the recipient has Outlook, he or she will experience the same issue (the
file protocol doesn't help; it just confirms that Outlook thinks it's a reference to a file accessible via Windows File Sharing).
This appears to be version agnostic - it's an issue with all versions of Outlook up to 2016.
There are two proposed "answers" to this question scattered across the Internet:
- Add a DNS entry to your hosts file to resolve ssl.gstatic.com to 127.0.0.1
- Turn off the automatic download of images in Outlook
These are not answers. These are workarounds that have big downsides:
- The DNS entry will solve the issue for Outlook... but prevent you from accessing any Google services via a web browser
- Turning off the download of images will solve the issue for Outlook, but is seriously annoying to anyone who trusts a lot of addresses so you don't have to manually choose to download/show images
Unfortunately, Google has no interest in fixing this image URI (even though it's the only image with a non-protocol URI - Gmail messages otherwise contain a ton of other images that all include the protocol), although it's understandable since the non-protocol version works fine in browsers.
Microsoft is in the same boat, claiming that they used the non-protocol version first to indicate Windows File Sharing links, so they won't fix it, either.
So nobody wants to fix the actual problem, which has been around for years!