0

Both web & DB servers are running Windows Server 2008 R2.

They are instances in the same datacenter at Amazon EC2.

I changed both servers from central to eastern time zone using the windows GUI.

I rebooted both servers.

In order to send via SMTP, emails are added to a Sql Server table.

The email sender iterates through each email in that table and does an SMTP send via Amazon SES, very simple stuff.

The emails that are sent are being delayed for between 10 and 30 minutes.

Here is the date on the email (from "show original" in gmail)

Date: Thu, 8 Nov 2012 11:35:36 +0000

Here is the SMTP receive section

Received: by 10.68.124.162 with SMTP id mj2csp417441pbb;
        Thu, 8 Nov 2012 03:57:44 -0800 (PST)
Received: by 10.224.52.200 with SMTP id j8mr11428239qag.95.1352375864002;
        Thu, 08 Nov 2012 03:57:44 -0800 (PST)
Return-Path: <0000013adfcdc93a-78222340-70f0-4520-94db-b8d28352947a-000000@amazonses.com>
Received: from a192-147.smtp-out.amazonses.com (a192-147.smtp-out.amazonses.com. [199.255.192.147])
        by mx.google.com with ESMTP id cz18si716858qeb.10.2012.11.08.03.57.43;
        Thu, 08 Nov 2012 03:57:43 -0800 (PST)

As you can see, there is no mention of a delay, like you might see if it were being punished for spam-potential or something. The first mention of a datetime by an email server is 22 minutes past when the SMTP transaction occurred.

Any ideas here? 20 minute delays are pretty bad for these deployment

Brian Webster
  • 1,123
  • 1
  • 18
  • 39

1 Answers1

0

A soft reboot may not do the trick here.

This problem can require a hard reboot.

If you are using Amazon EC2, actually stop the impacted instances, then start them back up (don't forget to re-attach elastic IP's).

My assumption is that this causes the underlying virtualization software to re-cache time related information for your instances.

Brian Webster
  • 1,123
  • 1
  • 18
  • 39