Another Exchange sending issue: "Could not deliver the message in the time limit specified."
Hello, I have another strange Exchange server issue.
When a specific sender domain is trying to send emails in to one of our clients the email never gets there.
The error they get is as follows:
The following recipient(s) could not be reached:
'user@recipientdomain.com' on 27/03/2007 12:09
Could not deliver the message in the time limit specified. Please retry or contact your administrator.
<senderdomain.com #4.4.7>
Whenever the senderdomainemails anyone else it works fine.
Whenever anyone else emails the recipientdomain it works fine. (so far as they know)
It just seems to be the combination of the senderdomain trying to send to the recipientdomain, even the other way round works fine.
I can't see anything wrong at our client's end and there is nothing obviously wrong at the sender's end since they have no other problems.
I've run out of things to check and I'd really appreciate any suggestions people may have on this.
Thanks,
Neil
March 30th, 2007 4:13pm
Neil, we are having the same situation. One particular client can not recieve our e-mail and produces NDR as you have desribed. We can receive their messages fine. Have you discovered anythign yet? Thanks.
Free Windows Admin Tool Kit Click here and download it now
April 3rd, 2007 5:29pm
This is generic message saying essencially that message was attempted to be sent but sending server is having trouble to communicate with recipient's server with no particular reason (that is there was not any explicit rejection, deny, etc.). So the server puts message in the queue and tries periodically send it till "retry time" is expired and server gives up. Why this happens? Well, if you know all the particular reasons why communication can be disrupted on Internet or even on particualr LAN youcertainly know the answer.
I have thesimilar issue and so far can not pinpoint the reason. Just now the person receives this messages when sending to the local group that included himself.
There might be a server issue that is having troubles communicating with other SMTP host and a combination of several other factors. One reason when wierd things like can happen when part of the communication traffic is getting blocked by firewall. Initial host-host contact was successfull but some (not all) SMTP commands were blocked. For instance the size of SMTP packet can exceed the packet size limit set on firewall and it is getting discarded, or specific SMTP commands can be blocked by those firewalls that have built -in SMTP filters. That is what I am leaning toward to for my specific situation - I have SonicWall firewall that it notorious (at least for me) for doing things like that. I guess it is time for ProctoCall AnalGazer.
Meanwhile it can be educational to lookat MS article # 905809 GOOD LUCK. I WOULD BE INTERESTED TO KNOW HOW ANYBODY RESOLVE THIS ISSUE. FOR THE BENEFITS OF HUMANITY AND FOR IT PROS PROSPERITY.
April 14th, 2007 5:13am
We had the same issue. We figured out that some receiving mail servers do a reverse lookup. Well our DNS had our email server setup as one ip but the firewall as another ip (and the firewall is the one ip the reverse lookups were looking at). So we just changed our firewall ip to the same ip as the email server and forwarded the port to our internal email server ip. Hope that helps!!
-MT
Free Windows Admin Tool Kit Click here and download it now
April 19th, 2007 11:25pm
Hi,
We are frequently recieved the same message and we can't give the right solution for this.
i am very happy if i got the right solutions.
Regards,
Siva
June 4th, 2007 3:26pm
Mark T is probably right. More and more postmastersuse reverse dnsnowadays. The problem with that is that receiving servers do not always generate an appropriatesmtp error like "421 Thingy refused your connection because your server did not have a PTR record" or "421 Thingy refused your connection because your HELO string did not match your PTR record". If the receiving server justbreaks the connection your server will be left in the dark as to the reasonwhy andkeeps trying.
I use reverse DNS in the weekends - blocks loads of junk (plm 80%).A bit draconic but what do you want? Doesn't stop all spam though.
If you use reverse DNS remember that there can be very good reasons why HELO strings don't match PTR records (migrations for instance). Don't send arrogant mails referring to RFC's (or worse www.rfc-ignorant.org) , it's not gentlemanly.
Bealways prepared to put a server on the whitelist if needed. Help your collegues,their lives aredifficult enough.
hhe
Free Windows Admin Tool Kit Click here and download it now
June 9th, 2007 4:25pm
Could not agree with you more. I have the same problem and the receiving end is known to have a Sonic Wall. Only certain messages
Problem in our case is only messages with a specific attachment and from a specific IP internally get rejected from the receiving side. Oddly enough if I copy the message from the Queue in our NY office to the Queue in our London office the message goes through probably because of the different IP. This is true while messages from the NY office WITHOUT the attachment also go through.
I really hate these kinds of issues. I know it is their firewall but I can't prove anything. Any suggestions are appreciated.
okok2007
October 19th, 2007 11:39pm
We have simillar problem in our environment and in the course ofmy research, I got to knowabout the Sender ID Framework Wizard but I have not tried it out.
Maybe u can find out more about it.
But my fear isthat you said that some users on your network can send mails.
Free Windows Admin Tool Kit Click here and download it now
March 11th, 2008 3:13pm
We too are having this problem and could use some help. One question I don't see here is how can I reduce the time it takes to get the failure notice? It currently takes 2 days. We would like to change this to 4 hours, but I can't seem to get an answer to that question.
Thanks in advance for any help.
Carmen
August 14th, 2008 9:43pm
We were having the same issue. What we found was Recipient's domain name was hosted by DNS Host A, They switched to DNS host B. DNS host A never deleted their Zone files. Sender's domain is hosted by DNS A. So when sending mail out, their DNS automatically hits the old zone file and never hits the recipients email server.
Free Windows Admin Tool Kit Click here and download it now
August 25th, 2008 8:18pm
Dear friend i have the same problem did u solve it ? Haw?
October 14th, 2008 3:15pm
Hi, we are also having the same issue. Strange thing, it is only happening on the user's using MS Outlook 2007. It is not happening for the users using MS Outlook 2003
Free Windows Admin Tool Kit Click here and download it now
October 17th, 2008 1:56pm
RGRonquillo,
Are your mailboxes running on Exchange 2007? This problem just started recently for us when we upgraded a few users to Outlook 2007. They never had problems sending to these clients before.
October 21st, 2008 11:57pm
Your message did not reach some or all of the intended recipients.
Subject: RE: test
Sent: 29/01/2009 12:03 PM
The following recipient(s) cannot be reached:
firstname lastname on 31/01/2009 12:18 PM
Could not deliver the message in the time limit specified. Please retry or contact your administrator.
<**.*****.com #4.4.7>One of our staff memebrs is getting this delivery message after two days. The recipient can send emails to this member but the sender cannot. He was able to do so when he was using office 2003 on xp. but sinse i've givien him office 2007, it's bringing this email. other users can send it to this recipient with out any problems.Reading above replies, i tend to think this might be related to office 2007? any help would be greatly appreciated.regards,chris
Free Windows Admin Tool Kit Click here and download it now
February 2nd, 2009 2:48am
Hi,All of the issues discussed can be caused by a multitude of issues, but here are some things to check:- Make sure you dont send e-mail with blank subject, this can be interpreted as spam by the remote host- Also e-mails sent entirely in capitals can also be interpreted as spam- Always try to have your rDNS match the send connectors reported server FQDN and your primary MX entry. If you cant do this (because you using broadband etc), configure a smarthost and use your ISP for mail delivery- Check that your IP address is not listed as open relay - try the Spam Test at www.dnsgoodies.com - Try a manual connection using telnet - http://support.microsoft.com/kb/153119- Ask the end recipient to whitelist your domainWith regards to Outlook 2003/2007, I cant think of any reason why the exchange client would make any difference to mail delivery. The issue is most likely relating to the path between your server and recipient.
February 2nd, 2009 9:05pm
Hi Rossm27,- Make sure you dont send e-mail with blank subject, this can be interpreted as spam by the remote host- I've tested this and all the mail that we send to this customer ahve a valid subject name- Also e-mails sent entirely in capitals can also be interpreted as spam- This is not the case- Check that your IP address is not listed as open relay - try the Spam Test at www.dnsgoodies.com - It is not listedI'm realy stuck with this issue. I've checked with my ISP that whether there is a reverse DNS entry for my mail server and it's there.Anymore ideas or anyone who had this problem before?thanksChris
Free Windows Admin Tool Kit Click here and download it now
February 4th, 2009 2:32am
Chris,I would check the rDNS yourself. On the DNS goodies page you will see the Reverse DNS tool. Pop in the public IP that your mail server sends its outgoing mail on.If the rDNS is correctly set up by your ISP, you will get a response of the FQDN of your mail server, for example mail.yourdomain.comAlso, in your public DNS entries for your domain name, the server mail.yourdomain.com should be listed as an MX.It is also worthwhile setting your exchange SMTP connector to report itself as mail.yourdomain.com.If your confident that the names match for reverse DNS, DNS MX and connector then I would move onto doing a telnet test, as described in the previous post.Ross
February 4th, 2009 3:27am
rossm27 said:
Chris,I would check the rDNS yourself. On the DNS goodies page you will see the Reverse DNS tool. Pop in the public IP that your mail server sends its outgoing mail on.If the rDNS is correctly set up by your ISP, you will get a response of the FQDN of your mail server, for example mail.yourdomain.comAlso, in your public DNS entries for your domain name, the server mail.yourdomain.com should be listed as an MX.It is also worthwhile setting your exchange SMTP connector to report itself as mail.yourdomain.com.If your confident that the names match for reverse DNS, DNS MX and connector then I would move onto doing a telnet test, as described in the previous post.RossYour reverse DNS won't always match. Any company that uses a hosted anti-spam provider such as mailfoundry will have an MX record that points to that anti-spam provider and the DNS / RDNS will point to their server nameand IP.So their MX might be - mx1.domain.com = IP address of hosted-antispamDNS - mailserver.domain.com = IP of mail serverRDNS - ip of mailserver resolves to domain name of mail serverAm I missing somthing here?
Free Windows Admin Tool Kit Click here and download it now
March 18th, 2009 10:37pm
We are getting the same error listed here. No-one in my office can send from our Exchange connected Outlooks to any users in only one domain. All other mail is fine and the users in the problem domain can send to us. The NDRs take at least two days to come
back.
I have looked through the Exchange SMTP logs at C:\WINDOWS\system32\LogFiles\SMTPSVC1 but there is no record of our attempts to send mails to this domain, although all other emails we send and receive are logged. It's like Exchange does not even bother
to attempt send them.
I am flummoxed and would welcome any pointers.
March 8th, 2011 10:49am