InteractiveWebs Blog

Outlook hangs caused by PayPal messages template fault

In just the last few days, I have started experiencing some issues with Outlook when opening messages sent from PayPal.

This is happening with the recent versions of Outlook, including Outlook 2010 and Outlook 2007.

Some of the indications of the problem include.

• Outlook taking longer than normal to open.
• Outlook with “Reading Pane” on
• Outlook Stops Responding when clicking on an email from PayPal.
• If you wait a long time, it will come good, and even show the email message.
• If you are impatient and cancel out of outlook, your reading pane is gone when you next open it.

When loading Outlook you receive a message about and address: Contacting: \\102.112.207.net\b\ss\paypalglobal\1\G.4-NS

Background information

It appears that the cause of this is some malformed tracking cookies being sent from PayPal.

While it could be argued that Outlook should handle this invalid link much better than it does… We all know that Microsoft is responsible for Outlook, so really we should not expect too much in the way of “graceful error handling”. (After 20+ years of Windows system events, they still don’t have an online library of error codes and meanings.)

At the bottom of the message, there is a hidden tracking image. Instead of this image pointing to a web server, it is pointing to a non-existing network share. As it is pointing to a network share and not to a web server, Outlook’s “Internet picture blocking” functionality doesn’t kick in and tries to retrieve the content.

So what to do what to do?

First, I know for a fact that PayPal is aware of this issue, and while it is literally a 10 min fix for the right person, we know that finding the right person probably means contacting the dev team out of India that they hired last month, and asking them to fix their crap!

Oh I have been doing this too long!

Really… what to do!

1. Nothing… If you are patient when opening email messages from PayPal while this issue happens, then they will open.
2. Delete all recent messages from PayPal permanently form both your inbox and deleted items.
3. Turn off the reading pane in Outlook.
4. Turn your Outlook into plain text preview
   
5. Redirect the invalid call using a modification to hosts
   

   ---

   1. Start Notepad as an administrator.
      You can do this by right clicking on the Notepad shortcut in the Start Menu and choosing “Run as administrator”. If you don’t see this option, hold SHIFT while right clicking on it.
   2. Choose File-> Open… and open the following file;
      C:\Windows\System32\drivers\etc\hosts
   3. Add the following line at the bottom.
      127.0.0.1        102.112.2o7.net
   4. Save the file and close Notepad.

   
   4. Save the file.

6. This will basically route 2o7.net request back to your computer, which will reject it, allowing you to read your emails quickly and in peace once again.
   This fix will work on 32/64 bit versions of both Vista and Win 7

   ---

If you still have a problem

In Microsoft Windows, use the command ipconfig /flushdns to flush the DNS resolver cache. Open the command prompt and type the following:

C:>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.



Corporate solution for all computer clients at once

If you are in a corporate network, your system administrators can fix this for everyone at once by adding a Forward Lookup Zone (Primary Zone) for the 102.112.2o7.net domain. Then add an A host record without a name and have it resolve to 127.0.0.1.

After PayPal fix the issue.

The invalid link when fixed will not fix messages already sent with the issue. So unless you permanently delete message with the problem, you will see the trouble each time outlook references them for reading. This is because the reference is totally invalid, not just temporarily down.

One of the most common problems experienced by users of hosted email services is that they find they can only send email messages to their own domain.

For Example, if you have two hosted email addresses:

1. ted@mybusiness.com
2. john@mybusiness.com

You find that you can successfully send an email message from one user to another, but when you try to send to any other domain:

1. anything@hotmail.com

You find that the email messages do not send.

Solution

You need to enable “Authentication” in your configured email account settings. There are many client email programs, probably the most common is Outlook.

When you configure an new POP3 email account you normally end up with something that looks like this:

If you click on More Settings / Outgoing Server

and just tick the option to use the same settings as the incoming mail server.

This is all that is needed to enable outbound SMTP authentication.

Background

SMTP Servers (or email servers) are setup to need stop people using them for sending email messages. As strange as that sounds, if they were not setup this way, then anyone could SPAM the world using that email server.

To prevent users from abusing an Open Relay Mail Server, the administrators say that anyone wanting to send email messages from that server to any other server, will need a users name and pass. Almost always this is the same user and pass as the one needed to download your mail from that server.

This this need for user and pass is referred to as “Authentication” and is necessary on almost all servers, other than internet service providers who give you an internet connection. In that instance they authenticate you from your internet connection.

Why Can You Send to Your Own Domain?

Because Email Servers by nature will received email messages to addresses they host. This is part of the process necessary for email messages to be sent and received.

DNN SMTP Settings

DNN Websites have the ability to configure in the host settings an SMTP server. When a DNN email is generated from the DNN website, it will attempt to send mail through this SMTP server.

In order that your DNN website can successfully send the email, the SMTP server must allow the email message to be received. Typically this is done in one of four ways.

1. The SMTP server is configured for Open Relay (This should NEVER be done unless you have an external firewall blocking all external SMTP connections. Otherwise your mail server will become a spam server within hours)
2. SMTP Authentication – Typically SMTP servers are configured to allow users with a valid username and password to authenticate themselves. Once they have been authenticated, they can communicate email messages through the SMTP server. This is the same way most ISP’s work their mail servers. The idea is that only users who are customers of the ISP will allow email to be sent from their SMTP servers.
3. Selective Open Relay. The administrator of the SMTP server can also allow Open Relay (same as 1 above) from selective IP addresses. Any communication from an IP address that is configured to allow open relay will be accepted by the SMTP server.
4. Local Host – If your website has it’s own SMTP server configured, typically it will allow email message to be sent form it’s self.

To correctly configure your DNN SMTP settings, you need to understand what method of communication has been configured in the SMTP server you are trying to set DNN to access.

Here is the process you would configure from above.

1. Enter the IP address or valid domain name for the SMTP server, nothing more to do if open relay is allowed. (Still not recommended)
2. Enter the IP address or valid domain name for the SMTP server, and the valid user name and password as would be used to communicate with the SMTP server. This is where you get to use the user name and password setting in DNN.
3. Ensure that the SMTP administrator has allowed the IP address your DNN website uses to have open relay status. Then just enter the IP address or domain name of the SMTP server in your DNN host settings.
4. Configure your DNN host settings to have “localhost” in the DNN SMTP server settings are.

Problems.
There can be some issues that get confusing with the different methods.

1. Open relay mail servers will be attacked by spammers very quickly. They are always on the lookout for mail servers that they can abuse. It is never recommended to have your mail server on the internet and in open relay. Additionally your mail server will be blacklisted by other mail servers if found to be in open relay.
2. SMTP Authentication  can still be restricted to certain IP addresses. Many ISP’s will allow you only to use their mail servers while you are a client of their AND connecting to their mail server from an IP address they own. So thing will work in your Email applications while you are connecting to the internet via their dialup or high speed connection, but as soon as you move away from a connection provided by them, you will not be allows to connect to their servers, let alone Authenticate.
3. Even if your ISP has allowed relay from the address that your mail server is run form, there may be a firewall or block on the normal port that the SMTP servers are typically configured to use. Port 25. If a firewall exists between your web server and the mail server, it must be configured to allow traffic over port 25.
4. You may have web server configured with an SMTP server on the same system. Yet have it be blocked over port 25 for outbound communications. Some ISP’s block port 25 to curb the flow of virus email messages. You need to be sure that your ISP that provides connection to the internet for your web and SMTP server is not blocking port 25.

How to get really confused.
Often mail servers will allow you to send email messages to email addresses on that SMTP server, even though they do not allow you to send mail out. So if you have a web application configured to send email to yourself, and the SMTP settings you use in the DNN host settings are for the SMTP server that runs the same email address you will have success.
Yet when you change the email address in the web application, you can no longer send email, and the web application appears to fail. This is still an SMTP configuration error on your website. You will need to find a method above to solve the issue.

Podcast Discussing This:

I’m finding the AOL process really really annoying. We have been trying to clear up blacklist and reputation problems with a new IP range that was previously abused.

AOL have some tools that pretend to help. What you need to know is this.

1. Ensure your mail server IP has a RDNS – so when you do an NS lookup on the IP address it will show a name, like smtp.interactivewebs.com

2. Setup an email account like abuse@ or postmaster@  that domain. Make sure you get that mail.

3. Ensure that you verify with AOL that you are the admin for that RDNS lookup name. That is by submitting a ticket called Feedback Loop here: http://postmaster.aol.com/SupportRequest.FBL.php

4. Wait till they verify your Feedback Loop. AKA. that you are getting mail on that domain.

6. Use this link: http://www.mxtoolbox.com/SuperTool.aspx?action=mx%3aaol.com
to work out the IP of an AOL mail server.

7. Work out what code error is given when you try to connect from your mail server using Telnet. Follow these instructions. http://support.microsoft.com/kb/153119 but use the IP address and port 25 of the AOL mail server from step 6 above.

8. Look at the error result and compare it to this page: http://postmaster.aol.com/Postmaster.Errors.php

9. Follow the support request process from that page, to submit a ticket to have them fix things up.

Easy as that.!

Imagine if we had to do that crap for every email domain in the world. This was a recent blog from AOL about their update:

http://postmaster-blog.aol.com/2011/05/05/general-update/

We are in the process of automating email problem report resolution. This is a mid-term project, and is being implemented in stages on a queue-by-queue basis. (Ex: Each unique error code type represents a different queue, as do feedback loop and whitelist requests. http://postmaster.aol.com/Postmaster.Errors.php )
The last couple of months were spent migrating our sundry ticketing systems onto one common platform — essentially readying a back-end for the front-end logic flow that you will interface with. We are excited to finally be addressing the part of this project that will offer, in most cases, immediate resolution to your issues.
We are starting with router-level queues, the first of which will be RTR:BB errors. I will post on our progress as we push the code into production, along with what ticket submitters should expect with the automated process specific to the queue addressed. If you are seeing problems with the queues in transition, please comment on that particular blog post, and we’ll take a look.
Meanwhile, our Postmaster staff will continue handling every ticket we receive.
Thanks for your patience and support during this transition!

1. Good that you are improving things. Sucks that your process is so stupid in the first place. An example of how frigging annoying I am finding things.
We at: http://www.interactivewebs.com have been forced by a chapter 11 of an upstream provider to move all our servers to a new IP range.
First thing we did was to setup RDNS and check mail reputation (on all the major Black Lists, and senderbase.org). What we found was that the IP range has been abused. So we set about cleaning that up.
Naturally we checked AOL, and found that the IP was "undisclosed" reputation. Helpful Right… NOT!
But it does not show AOL was listing it.
So we move and fire up services. THEN and only then do we find out that AOL does have the address on a BL and mail cannot be delivered.
How about tools that work, and a process that works to allow proper checking/de-listing.
The ironic part of dealing with your 1990 process, is that it really does not work as well as other systems. AOL users get more spam than many other reputable spam systems. There is even free spam software services that do better.
So why stick with such a lame process, when the end result is HEAPS of false positives?

We have discovered a rather annoying email problem this week. Because of a closure of a data centre we have used for over 10 years, we have been forced to pickup our servers and move them over to a new data centre. As annoying and as much work as this is, we have found one particular issue with the change of our primary email servers over to a new IP.

In recent years, there has been a new emergence of spam email fighting systems. Cisco is using it’s power of basically routing almost every bit of data on the internet to directly monitor IP addresses real time. They call this senderbase.org and is part of their IronPort spam scanning service.

We have had our email servers running for years with a “Good” reputation on this service.

However when we move the IP to a new block, we have found that almost instantly, the IronPort services rank us as “poor” due to the fact that they monitor days / weeks / months of average email sent from the address. When we instantly move to a new address that last month did no email, and start blasting email galore through one IP. Bang we are canned.

In the past this has not been a big issue. But in Australia, our primary telco has recently been pushing an email spam service that relies heavily on this service. So we are finding that loads of Australian businesses are blocking our email services. The solution has been to relay through some other email services, but that is time consuming and fiddly, as we still have to leave the majority of email running through the new IP so that it develops a “good” reputation on the IronPort services.

Wouldn’t it be nice if the support people at IronPort answered emails for support to move the reputation of an old IP address over to a news one!

- Update- Since we wrote this. We have been in contact with the senderbase support people who have ranked us a “Good”. It took 3 email messages and 7 days, but they did finally assist.

As it turns out, this ranking is one of the most important aspects of running a valid email server. It is a shame they do not have a more transparent method of making the requests for review. We still cannot work out exactly what the cause of the poor ranking was. There is the possibility that it way by association with the network owner who would appear to deserve a ranking of poor.

Understanding non-delivery reports

NDR or Non Delivery Reports are potentially a great way of telling a user that they made a typo with an email address and that the email could not be delivered. In a 1999 world, this would be fine.

However we are in a world now where email servers are flooded with spam, and lots of it, replying to every junk email that is hitting all the imaginary email addresses on your server (support@, admin@ help@ etc) is not a good idea, and it causes what is known as backscatter. To avoid this back scatter of invalid email delivery from your server it is recommended that you turn off your Non Delivery Reports NDR.

To do this in Exchange 2003 you need to perform the folloing:

1. Open Exchange System Manager

2. Expand Global Setting and Click on Internet Message Formats

3. In the right hand pane, double click the “Default” name or whatever domain you have configured.

4. Click on the Advanced Tab and uncheck the option for Allow non-delivery reports

5. Ok and you are done!