E-mail sent to Gmail accounts delayed in queue until Transport Service is restarted

Ah, also:

Once this issue comes up again, get to the exchange box, and:

do cmd --> nslookup --> set type=mx --> gmail.com. This will give you a list of mail servers for gmail. Choose the one with the smallest preference (usually gmail-smtp-in.l.google.com), then type

telnet gmail-smtp-in.l.google.com 25

Are you getting a 220 response back? If not there might be something blocking your port. Then proceed to send an email from command line. The commands are:
HELO domainname
MAIL FROM: user@yourdomain.com
RCPT TO: user@gmail.com
DATA
SUBJECT: subjectname
Mainbodytext
.
QUIT

Does user@gmail.com actually receive this email?

1. No relay
2. No...incoming mail is filtered but not outgoing.
3. No errors
4. 451 Internal Error ...There's another error but I can't remember the number. Basically just saying the message is Delayed and will try again.
5. #550 4.4.7 QUEUE.Expired; message expired ##

Thank you.

The issue came back today. Here is the error in the Queue Viewer.
400 4.4.7 Message delayed

I did the other commands you mentioned each server timed out within 2 seconds.

No success, I will restart the Transport Service, then the problem will go away for another day.

Then we've made some progress. What this means is that for some reason some application or network device is blocking outgoing SMTP requests from your server to gmail's servers. Then when you reset the Transport Service for some reason this blocking gets reset.

Can you think of anything that might be blocking port 25 on your exchange box? An antivirus perhaps? A firewall?

Next time this happens, try telnet on port 25 for other mail servers, do you also get a timeout?

Update:

This problem has been very difficult to track down. However, I did stumble upon a possible solution and only time will tell if it works.

Google's Gmail uses greylist filtering (
http://en.wikipedia.org/wiki/Greylisting ). From what I understand, if Gmail doesn't have your domain in their whitelist, they deny the first message attempt. If the mail server responds back within 5 minutes, Gmail accepts the message.

Exchange defaults to 10 minutes between retry attempts. This is too long for Gmail.
So I set the Outbound Connection Failure Retry Interval to 5 minutes and the QueueGlitchRetryInterval setting in the EdgeTransport.exe.config file to 5 minutes.

There are other timing settings that I may need to modify, but I'm taking this in small steps.
A site that helped me in diagnosing this issue was http://www.mailservertest.net/
Now the odd thing I have yet to understand is that, why does the mail go through if I restart the Exchange Transport Service?

I hope you nailed it, but I honestly cannot see how this could happen... I use gmail too, and I always send test emails to my gmail accounts whenever I set up a mail server for the first time... I never had any problems, or delays in email delivery

Plus I've checked http://www.mailservertest.net, and my greylisting status is OK, and I've never changed the failure retry interval

Unfortuantely, The tweaks thus far are unsuccessful.
Gmail mail was once again stuck in the queue and wouldn't go through. Until, of course, I restarted the Exchange Transport service, then viola', everything when through fine.
Back to the drawing board.
Thanks for the feedback.

We seem to be having the same kind of issue. We have a Windows 2003 server with SP2 and exchange version 6.5 with SP2. When emails are sent to any gmail account they are hanging in the smtp queue. Some take 45 minutes while others take a full day. I was able to telnet and send mail while the issue was happening. I have verified we are not on any RBLs. I ran the test at http://www.mailservertest.net but so far I have not gotten any results. Also stopping and starting the smtp service does not help.

Just to update.
I had the service who manages our domain name to create a SPF record for our domain. That didn't help.
Still trying to resolve the issue.
 

I've been doing some research as well, and I just cannot find anything that hasn't already been suggested/tried here, and now there's two of you!!
 
Are your physically near each other? Could there be something wrong with the GMAIL server(s) near your area??
 
 
 

Checked DNS with SmtpDiag. Looks like everything connects ok.
Checking remote domain records.
Checking MX records using TCP: gmail.com.
Checking MX records using UDP: gmail.com.
Both TCP and UDP queries succeeded. Remote DNS test passed.
Checking MX servers listed for myusername@gmail.com.
Connecting to gmail-smtp-in.l.google.com [64.233.183.114] on port 25.
Successfully connected to gmail-smtp-in.l.google.com.
Connecting to gmail-smtp-in.l.google.com [64.233.183.27] on port 25.
Successfully connected to gmail-smtp-in.l.google.com.
Connecting to alt2.gmail-smtp-in.l.google.com [64.233.185.114] on port 25.
Successfully connected to alt2.gmail-smtp-in.l.google.com.
Connecting to alt1.gmail-smtp-in.l.google.com [209.85.143.114] on port 25.
Successfully connected to alt1.gmail-smtp-in.l.google.com.
Connecting to alt2.gmail-smtp-in.l.google.com [64.233.185.27] on port 25.
Successfully connected to alt2.gmail-smtp-in.l.google.com.
Connecting to alt1.gmail-smtp-in.l.google.com [209.85.143.27] on port 25.
Successfully connected to alt1.gmail-smtp-in.l.google.com.
Connecting to gsmtp183.google.com [64.233.183.27] on port 25.
Successfully connected to gsmtp183.google.com.
Connecting to gsmtp147.google.com [209.185.147.27] on port 25.
Successfully connected to gsmtp147.google.com.

I got the same results as jvleigh221 except mine fail to connect to the last mail server gsmtp147.google.com.

Is there a way for us to exclude that mail server from our end to see if it causing the issue?

Just an update, This problem is ongoing.
I've tried a dozen "solutions" but still no resolution to this issue, except for the fact that I can restart the Transort Service and for a brief, very brief time all gmail will go to its destination.
Aggravating indeed.
 

We've just implemented a few other "fixes" and tweaks to our server and network, in hopes of resolving this issue.
Only time will tell. If the adjustments work, I'll post them to this thread.
 

It seems the following adjustment made the most difference in our case.
We have a managed Internet security appliance. It was the appliance that had our mail header misconfigured and thus, it was not being accepted by some mail servers.
I apologize wizzard, I must not have read your comment thoroughly enough. I notice now you did ask about anti-spam devices.
After correcting our mail headers on the appliance mail flow in all areas has improved significantly.
Thanks to all who took time to offer assistance.

Thank you for your help. I awarded you the total points. Even though the solution was not provided, the questions if I had answered them thoroughly would have led to the correct conclusion.

We have a similar issue as well.  Gmail would queue for days and it won't go out.  Sometimes, it goes all out without explanation.  

I want to know what appliance your using and how you changed the mail header configuration?

The only thing we changed on our mail enviornment is have the SMTP server behind a firewall and NAT that IP out to the internet.  That's when we started to see Gmail queue goes up w/o error codes.

SMTPDiag works fine on all MX records..

SMTP(Private IP)-->Firewall(NAT)-->Public IP address.

Telnet to port 25 is fine.

I restarted the SMTP virtual server a few times and I see that SOMETIEMS..it would sent it all out..but not all the time.

Any clues?

One thing I would suggest right away is to make sure your Firewall does not have Fixup enabled for SMTP. Fixup will alter your SMTP headers.
We were using a Proventia security device managed by ISS. When we asked them if their appliance could be altering our header, they found where the setting within their system was wrong and made the correction.
Since it's managed by ISS I do not know exactly where the change was made.
I hope this helps.

I checked the mail header and it is using the correct public IP address when sending out to the other domains.

I guess I will continue my search on this weird problem.

Thanks.

The Fixup doesn't alter IP addresses. Only the verbage of the header.
Normal banner
220 mail2.nwtraders.msft Microsoft ESMTP Mail Service

Fixuped banner
220 ****2************************************
I found a nice article on this subject at:
http://blogs.technet.com/pamal/archive/2008/06/23/cisco-fixup-and-smtp.aspx 

I experiment the same issue ..email stay in gmail.com in active state ..i restart the SMTP service ..it's goes away ...but  issue raise again after ...some email go tru ..and stop...Any solution you find ..after all your troubleshooting. thank !

Just make sure that if you telnet your mail server's external IP address you get the correct header.
Fixing the header helped our situation.
The mail header has to be consistant throughout your network as well as with the DNS host records.. If the MX record of the external IP address to your mail server is mail.yourserver.com then your header when telneting to your mail server's external IP should read 220 mail.yourserver.com.
That setting needs to be set in Exchange, any Firewalls (SMTP Fixup should be off), and any Security Appliances.
In our case, it was the security appliance that had a misconfigured mail header.
Hope this helps.

I recently just found the resolution to this issue in my environment. I am using dual checkpoint utm 570 firewalls w/messaging security.

After reading through numerous articles and forums I found it was a combination of anti-virus scanning on the firewalls as well as some DNS issues. I have cleaned up DNS and also inside of the checkpoint appliances i had a choice as to which directions i wanted to scan smtp emails. I choose to leave incoming emails as scannable but outgoing emails i turned off all scanning.

This has made the queues drop in half and it looks like now its just waiting for the Exchange Glitch resend to kick in for the 15 minute interval. I have frozzen and unfrozzen the queues as well as forced the connections but I had to wait for the queues to empty them selves.

since it was a production exchange server i was not too tempted to change registry keys (i dont feel like working all night should something happen) but it appears now all is fine.

Thanks to everyone on this site as this had the most insight to get me to my answer.

My fix of the problem was the network speed settings need to be the same at  100 Half across point A(Firewall DMZ) to point Z (DMZ-->Switch-->Nic on the server)

Before the network speed change, we experienced the same exact problem.  We called Microsoft and did all sort of traces...no solution provided by them.  

Check your setting and experiment with the Server NIC and the Firewall and Switch port.   There is something not right in between it.  Make them all the same speed and test.  There is some upstream miscommunication somewhere.

That worked for us with 100 Half and it has been smooth sailing.

Good luck.