Outlook 2010 - Contacting server for information

Question

When attempting to print an email that contains many embedded html links (Avis Rentals, SouthWestern Airlines, etc.), Outlook 2010 has a pop-up that reads "Contacting the server for information" where it sits for at least 15 minutes. (I know this has been
asked many times, but I've not found a solution.)
Details:
 - This error occurs when running through my firewall, or having the firewall disabled, or the DMZ, or connected directly to our ISP.
 - The time it takes for the Preview to appear is directly related to the number of links/images the email contains.  The more links I remove from the code, the faster it downloads (by faster, I mean it goes from 15 minutes to 10 minutes.)
 - Packet inspection shows Outlook (and Word, as they share an html engine), downloading the same links over and over.
 - I have tried this on Windows 7 (64 and 32), and Windows XP (64 and 32), running Office 2010 with Exchange 2010.  We did not have this problem until we installed Outlook 2010.
 - Tried Office 2010 SP1, but did not fix the problem.
 - Problem occurs to a lesser extent when tryng to forward the email - it takes about 2 minutes to forward.
 - Word Trust Center logging and Outlook Troubleshoot logging does not show anything.
 - Have tried Exchange Cached mode, disabling add-ins, having Outlook use html to connect to Exchange, Turning off Exchange to Outlook encryption, disabling Outlook Anywhere, removed all Add-ins,  etc.
Are there any other suggestions?  Is there an official fix? 

Answer 1

After working with Microsoft on this I am convinced the problem is with the images in the emails that fail.  We ran a trace and found that the images linked to were either
not available or improperly designed or both and Outlook retries every one.  You can cancel repeatedly (20x for airline itineraries) or block images using the registry kludge.  Ultimately, airlines and othersite using
imbedded images need to fix their emails and/or their sites.  Here is a trace and Microsoft commentary about a sample itinerary email:
Email Subject: eTicket Itinerary
This email is the itinerary and Outlook user is experiencing same issue while printing and forwarding this particular message
We gathered fiddler trace while reproducing this issue and below is what I found in fiddler trace
GET
http://uwebadmin/img/eTicket/Bullets/dot_Small.gif
502
Fiddler - DNS Lookup Failed (text/html)
GET
http://uwebadmin/img/eTicket/Bullets/dot_Small.gif
502
Fiddler - DNS Lookup Failed (text/html)
GET
http://uwebadmin/img/eTicket/Bullets/dot_Small.gif
502
Fiddler - DNS Lookup Failed (text/html)
Outlook was trying to connect to the above URL (highlighted in yellow) and was failing. Outlook tried connecting to this 88 times.
Try to browse the above URL in a browser
http://uwebadmin/img/eTicket/Bullets/dot_Small.gif  and the DNS will not able to resolve this for you.
The key factor in the delay we are seeing is a 1x2.gif image.  In your first sample  email labeled “eTicket Itinerary”; this HTML code contains  88 of these images in
the body.  The original message was designed like a web page, and apparently the web designer felt they couldn’t trust the browser to handle cell spacing and non-breakable spaces, and decided to use a transparent 1x2 pixel GIF image instead.  So
any place in the message they wanted to enforce a space, they used an image.  This is very bad for Office 2010, since each of these will require an Office Art (OART) shape and an explicit download of the image to include in the forwarded (or printed)
email.  In addition, the server has placed the image on a share that is not supporting HTTP 1.1 OPTIONS verb, which eats up valuable time as the server bounces back an error on every image collection. 
Simply put, Outlook and Word 2010 are not web browsers.  Each image is considered separate from any other (a unique link).  This is unlike a web browser which treats images
like a pool of resources and will reuse the same one over and over if two tags share the same link path.  So whereas a browser only needs to pull the image once, we will pull it for every image.  In addition, given this scenario we don’t guarantee
rendering of content designed for web pages and not email.  This is clearly web page designed. 
In my opinion the use of images for spacing is a very pre-1998 rendering methodology, and extremely inefficient for modern HTML, but is clearly done for old browsers that didn’t support
explicit table layout.  While the company might have wanted to render that way, it makes for an awful email content experience, since users cannot easily select or edit such non-space “spaces”. In addition, to attach each to the file would bulk up the
email since each image would attach unique.  Bottom-line, the problem is due to the content itself.  It was not designed correctly for use as email (or should I say, in any email you would edit, or plan to view outside a web browser).
Why we don’t see the performance hit when originally opening the email;   It’s been explained because we can download images in the background (it is asynchronous). 
But to forward or print, we have to pull the images synchronously
because we need the downloads to complete before we can proceed to the next step.  So the reason it only occurs on those specific HTML web sites is by  design. 
I wanted to recap and  let you know up front, least two of the results from the repro steps are “by design”. 
1) Using images for spacing; e.g. 1x2.gifs totalling 88 images in the body.
2) Each image is downloaded independent and not shared from resource pool, making just collection of images a slow task (by design given the email).
This explains why other HTML emails don’t exhibit this same performance hit by using more modern HTML designs.
 - Microsoft tech