Solved

slow incoming emails

Posted on 2011-02-22
3
246 Views
Last Modified: 2012-05-11
if the emails came 1 or 2 days later, do you check with your ISP or the source ISP- from the header, is it possible to deduct what is the problem?
0
Comment
Question by:anushahanna
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
3 Comments
 
LVL 76

Assisted Solution

by:Alan Hardisty
Alan Hardisty earned 200 total points
ID: 34956390
Analysing the headers is the only way to check why the emails are delayed.  They will provide the dates / times for all servers between the sender and you and pinpoint where the delay occurred.

If you would like to past a header into http://www.mxtoolbox.com/EmailHeaders.aspx - that should analyze them happily for you.

You then just need to interpret the output to see where the delay is.

Post a header if you need help.

Alan
0
 
LVL 7

Accepted Solution

by:
Vanguard_LH earned 300 total points
ID: 34957774
Be aware that the MXtool to trace through the Received headers has problems:

- If a spammer/phisher inserts bogus Received headers, this tool will trace through them giving you a false source for the message hence potentially invalid timestamping.  With internal routing within e-mail services, it isn't always easy to spot where the forged Received header(s) got inserted.

- It does not unbias the day for the timezone.  A Received header with a datestamp of "Tue, 15 Feb 2011 17:54:44 -0800" as the source followed by the next Received header with a datestamp of "Wed, 16 Feb 2011 01:54:44 +0000 (UTC)" get unbiased to UTC so both show for 01:54:44 UTC but they forget to change the day.  So it will look like the e-mail got delivered at the same time but a day later.  The e-mail that got transferred in less than a second shows it got sent on Tues and received on Wed which is not the case.

It's still a useful tool as long as you realize the day of the week may be wrong in what it reports.  You should be able to trace through the Received headers while unbiasing the timezones in each to figure out how long it takes between hops to deliver the message.  Headers get prepended to a message with each hop through a mail server, so you read the Received headers from bottom to top.  The topmost Received header is the one prepended by your receiving mail server.  The bottommost Received header is the one prepended by the sender's mail server.

E-mails should transfer within a few seconds unless an underpowered e-mail service was involved that, say, batched up their e-mails to send out every hour, or so.  A delay of a day or two would probably mean one of the mail servers was down, unresponsive, or unreachable (routing problems with slow/unresponsive hosts between the source and destination mail servers).  When tracing the Received header from bottom to top in the headers, the first large jump in delivery time is probably the major cause of delay.  Just be careful to note the timezones in the datestamps since some mail servers bias against UTC while others use their local timezone.  Also remember that the timezone reported by the mail server is for itself and not that of the sender when they chose to compose the e-mail (which is shown in the Date header).  For example, someone in the midwest USA with timezone -0600 using Hotmail's servers in the -0800 timezone will have Hotmail's timezone in the Received header and the sender's timezone in the Date header.  The Received headers are added by the mail servers.  The Date header is part of the *data* defined by the sender's e-mail client (it is part of the message composed by the e-mail client and sent during the DATA command).

You could post the headers of the problematic e-mail here for us to analyze.  Munge or star out any sensitive info, like usernames in e-mail address but leave the domains intact.  You want to hide the e-mail account, not the e-mail service provider which isn't a secret.  Make sure to check all headers for usernames as several may contain them, like From, To, Cc, Received, Reply-To, Sender, etc.  You could just show the Received headers and only their time and date values to let us trace through them but I suspect you could do that yourself.
0
 
LVL 6

Author Comment

by:anushahanna
ID: 34985980
thanks for the nice resource to check it out.
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

In this step by step procedure, you will come to know the details of creating an Outlook meeting in 2007, 2010, 2013 & 2016.
How to resolve IMCEAEX NDRs in Exchange or Exchange Online related to invalid X500 addresses.
This video shows how to remove a single email address from the Outlook 2010 Auto Suggestion memory. NOTE: For Outlook 2016 and 2013 perform the exact same steps. Open a new email: Click the New email button in Outlook. Start typing the address: …
Many of my clients call in with monstrous Gmail overloading issues with Outlook. A quick tip is to turn off the All Mail and Important folders from synching. Here is a quick video I made to show you how to turn off these and other folders in Gmail s…

691 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question