• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 413
  • Last Modified:

E-mail being received up to 18 hours after it was sent

Hi,

Over the past few days, users have made comments on e-mails which have been delivered to them, but the 'sent' date and time are from the previous day. I have 2 examples:

1 - sent 20/04/2009 @ 17:15. Received - 21/04/2009 @ 11:18
2 - sent 20/04/2009 @ 16:31. Received - 21/04/2009 @ 14:31

I have run searches on Surfcontrol E-mail filter and they're shown as being received on the times that we received them.

Do you know of any issues which would cause this? It only happens a handful of times per month, but I want to find out if it's a problem our end or if it's externally with the senders.

I don't think it's our server as the e-mail filter is running fine and if any messages are isolated, I have to release them from the queue before a user gets them.

I'd appreciate any comments, ad if any of you have experienced this in the past.

Thanks in advance!
0
robsamuel2k8
Asked:
robsamuel2k8
  • 3
  • 3
1 Solution
 
jassavCommented:
This sounds like your ISP or external company is queuing mail. Have you spoken to them about this yet?

Also do you use an external company to scan your mail before it comes in? If so have you made any changes recently? I would speak to them first
0
 
abhaighCommented:
There is a connectivity problem soewere between the originating system and your own - this is causing mail to queue up for several hours before it is being delivererd

have you investigated the smtp headers to see the route the problematic mails have taken to get to you? The headers should also show you where the delay occured
0
 
robsamuel2k8Author Commented:
Hi,

Apologies for the delay in response - been a busy few days here. I've spoken to Skynet who we have our domain with and they seem to be getting 'message deferred' errors every now and again - which seems to affect messages which arrive 24 hours after being sent. Could you have a look at the text below and let me know your thoughts.

What could I do to resolve this error, as some of our consultants are receiving delayed e-mails.

As your server is the primary mx, emails to xxxxxxxxxx.com will only go to our servers if there is some sort of problem with yours. I can see the email from xxxxxxxxxxxx@sky.com coming in at 16:31 yesterday:

Apr 20 16:31:39 vulture sm-mta[85664]: n3KFVcO4085664:
from=<xxxxxxxxxxxxx@sky.com>, size=3469, class=0, nrcpts=1, msgid=<b55055a00904200830i503c52ep2e325afe21599ed8@mail.gmail.com>,
proto=ESMTP, daemon=MTA, relay=ey-out-1920.google.com [74.125.78.149]

After that, your server reset the connection as I can see several entries like the following:
Apr 20 16:55:29 vulture sm-mta[93770]: n3KFVcO4085664:
to=<ruth@xxxxxxxxxx.com>, delay=00:23:50, xdelay=00:00:00, mailer=esmtp, pri=123469, relay=[81.142.228.97], dsn=4.0.0, stat=Deferred: Connection reset by [81.142.228.97]

Apr 21 13:52:37 vulture sm-mta[3637]: n3KFVcO4085664:
to=<ruth@xxxxxxxx.com>, delay=21:20:58, xdelay=00:00:00, mailer=esmtp, pri=3633469, relay=[81.142.228.97], dsn=4.0.0, stat=Deferred: Connection reset by [81.142.228.97]

Until it was eventually delivered today at around 14:31:
Apr 21 14:31:05 vulture sm-mta[15375]: n3KFVcO4085664:
to=<ruth@xxxxxxxxxx.com>, delay=21:59:26, xdelay=00:00:00, mailer=esmtp, pri=3723469, relay=[81.142.228.97] [81.142.228.97], dsn=2.0.0, stat=Sent
(OK)

I look forward to your comments,

Thanks in advance,
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
abhaighCommented:
looks like they are greylisting at the receiver's end
0
 
robsamuel2k8Author Commented:
so, xxxx@sky.com is greylisting our server?? How can I ensure our server is not greylisted anywhere? On MXToolbox, we're not on any blacklists.
0
 
abhaighCommented:
you would have to ask their mail admins if they are

you can't - geylisting is an anti-spam technique implemented at the reciever's side that refuses the initial attempt at sending, forcing the sender to retry. It is effective because most spam engines aren't rfc compliant and will not re-queue a failed attempt for later

only way to find out if someone is greylisting is to ask them, after you start seeing delivery problems with their site
0
 
robsamuel2k8Author Commented:
Hi,

Thanks for the comment, that makes sense as the delays are only occuring with a handful of domains. We are also getting a handful of 554 errors from domains as well - would that relate to the same issue?

Especially after moving offices (and IP addresses), our old IP is probably listed with the majority of domains. I've had our SPF records updated and a thorough test on MX toolbox shows everything looks OK.

Are there any alternative sites to MX Toolbox which provide a facility to test?
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.

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now