I have just converted a customer over to thier own Exchange 2003 server running on SBS 2003. They were using, and still have, POP3 accounts before. Everything seemed to go fine setting up the server and mailboxes and they are recieving mail fine. When sending to some people they get SMTP delay messages and then failures a day or 2 later. They can send to some people, like me, just fine. I get the message almost immediately everytime. They get the delays on some big domains like hotmail, yahoo and gmail. There is Reverse DNS record and SPF record setup and the utils at MX Toolbox say the domain looks fine. The domain name is belleharvest.com. As far as I can tell everything is setup correctly, I have upped the delay and retry times on the exchange server and it made no difference. I'm really out of ideas and not sure what to try next. Any help or advice is appreciated. Thanks

I'd be that they're on a subnet that's blacklisted or they're otherwise caught in the recipient's antispam web. On Tue, 17 Aug 2010 19:59:36 +0000, scs-04 wrote: > > >I have just converted a customer over to thier own Exchange 2003 server running on SBS 2003. They were using, and still have, POP3 accounts before. Everything seemed to go fine setting up the server and mailboxes and they are recieving mail fine. When sending to some people they get SMTP delay messages and then failures a day or 2 later. They can send to some people, like me, just fine. I get the message almost immediately everytime. They get the delays on some big domains like hotmail, yahoo and gmail. There is Reverse DNS record and SPF record setup and the utils at MX Toolbox say the domain looks fine. The domain name is belleharvest.com. As far as I can tell everything is setup correctly, I have upped the delay and retry times on the exchange server and it made no difference. I'm really out of ideas and not sure what to try next. Any help or advice is appreciated. > > > >Thanks Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

If that was the case woudn't the SMTP failure say something about being on a blacklist?? All each failure says is that it could not be delivered in the time limit specified.

On Wed, 18 Aug 2010 12:35:56 +0000, scs-04 wrote: >If that was the case woudn't the SMTP failure say something about being on a blacklist?? All each failure says is that it could not be delivered in the time limit specified. Not necessarily. If the receiving server sends a 4xx status instead of a 5xx status the error is transient and the message sending will be retried -- repeatedly, in that case -- until the message expires. Your SMTP protocol log would be the place to look if you want to see what's going on in the conversation between the two servers. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I've done some checking and our IP doesn;t seem to be listed on any RBL. Where exactly is the SMTP protocol log?? Also the SMTP failures have the 'error code' - belleharvest.com #4.4.7 Thanks

On Thu, 19 Aug 2010 12:02:32 +0000, scs-04 wrote: > > >I've done some checking and our IP doesn;t seem to be listed on any RBL. You're assuming that you can check every DNSBL and reputation server. That's a bad assumption. >Where exactly is the SMTP protocol log?? Typically, they're in the system32\logfiles directory -- assuming you've enabled logging on the SMTP virtual server (or however SBS decides to let you do it). >Also the SMTP failures have the 'error code' - belleharvest.com #4.4.7 4.4.7 is an extended status code. The status code would be the three digits just before that. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I'm not seeing any other codes in the failure message? This is all it shows: Could not deliver the message in the time limit specified. Please retry or contact your administrator. <belleharvest.com #4.4.7> Also the users seem to notice they get more delays and failures if the send to mutiple people. If they send to the same people indivduallly the message goes through fine. This seems very strange.

On Fri, 20 Aug 2010 15:20:44 +0000, scs-04 wrote: > > >I'm not seeing any other codes in the failure message? > > > >This is all it shows: > >Could not deliver the message in the time limit specified. Please retry or contact your administrator. > > <belleharvest.com #4.4.7> > >Also the users seem to notice they get more delays and failures if the send to mutiple people. If they send to the same people indivduallly the message goes through fine. This seems very strange. So you haven't look at the SMTP protocol logs to see what's going on? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

OK, I turned on the looging and looked at a some of the SMTP log files. What am I looking for? I don't really know what I am looking at. Here is some of the log file: 17:12:23 65.23.95.106 RCPT - 0 17:12:23 65.23.95.106 - - 0 17:15:35 187.38.3.253 EHLO - 250 17:26:20 187.38.3.253 TIMEOUT - 121 17:26:20 187.38.3.253 QUIT - 240 17:28:10 65.23.95.106 - - 0 17:28:10 65.23.95.106 EHLO - 0 17:28:10 65.23.95.106 - - 0 17:28:10 65.23.95.106 MAIL - 0 17:28:10 65.23.95.106 - - 0 17:28:10 65.23.95.106 RCPT - 0 17:28:10 65.23.95.106 RCPT - 0 17:28:10 65.23.95.106 RCPT - 0 17:28:10 65.23.95.106 - - 0 17:28:19 186.122.134.198 EHLO - 250 17:28:24 186.122.134.198 MAIL - 550 17:28:24 186.122.134.198 QUIT – 240 18:59:02 64.18.6.14 - - 0 18:59:50 65.55.37.88 - - 0 18:59:50 65.55.37.88 EHLO - 0 18:59:50 65.55.37.88 - - 0 18:59:50 65.55.37.88 MAIL - 0 18:59:50 65.55.37.88 - - 0 18:59:50 65.55.37.88 RCPT - 0 18:59:50 65.55.37.88 - - 0 18:59:50 65.55.37.88 BDAT - 0 19:00:24 64.18.2.177 HELO - 250 19:00:24 64.18.2.177 MAIL - 250 19:00:24 64.18.2.177 RCPT - 250 19:00:25 64.18.2.177 DATA - 250 19:00:25 64.18.2.177 QUIT - 240 19:02:23 65.23.88.71 - - 0 19:02:23 65.23.88.71 EHLO - 0 19:02:23 65.23.88.71 - - 0 19:02:23 65.23.88.71 MAIL - 0 19:02:23 65.23.88.71 - - 0 19:02:23 65.23.88.71 RCPT - 0 19:02:23 65.23.88.71 RCPT - 0 19:02:23 65.23.88.71 - - 0

On Wed, 25 Aug 2010 11:10:46 +0000, scs-04 wrote: >OK, I turned on the looging and looked at a some of the SMTP log files. What am I looking for? I don't really know what I am looking at. Here is some of the log file: I'd get more information into those logs. The default set of data doesn't really tell you very much. Note that there's no address after the RCPT or MAIL command, and no data after the EHLO. > >17:12:23 65.23.95.106 RCPT - 0 > >17:12:23 65.23.95.106 - - 0 The IP address 65.23.95.106 might be a spam filtering service you use. Or it may just be them spamming you with advertisements. >17:15:35 187.38.3.253 EHLO - 250 > >17:26:20 187.38.3.253 TIMEOUT - 121 TIMEOUT isn't good. But I don't know if youre sending TO that IP aor reveiving FROM it without more context (i.e. more data captured in the log). 187.38.3.253 doesn't accept connections on port 25 and it has no PTR record. The IP address, however, is located in Brazil and it's a source of spam: http://www.trustedsource.org/query/187.38.3.253 If you're trying to SEND to that IP address you probably aren't using Recipient Filtering on your Exchange server. What I'm NOT seeing on many of these is a DATA or BDAT command. If these are all inbound connections then I'd say you have some sort of network problem. Mismatched MTU sizes, fragmented IP packets, etc. can be a problem that yields symptoms like this. If you're using just a wired IP connection you should be able to send normal-sized packets without fragmenting them. This should work: ping <ip-address> -l 1472 -f This should not: ping <ip-address> -l 1473 -f If the ping with the 1472 length fails you can use ping with smaller packet sizes to find the length that works without fragmenting. You can then reduce your MTU size (or fix the problem). That may not be your problem . . . it's just a guess, but it's one problem that's a lot more common that you'd think. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

We are still having the sending problem. The first ping command you listed worked fine but the second failed. We are using recipient filtering but just filtering for reciepients not in the Active Directory. I have also changed the log so it shows more data. What should I be looking for?? Do you want me to post it here? I just don't want our sending and recieving email addresses to be listed. Thanks for any help

ALso, the MTU is set to 1500 on the LAN router.

On Thu, 2 Sep 2010 17:25:15 +0000, scs-04 wrote: >We are still having the sending problem. The first ping command you listed worked fine but the second failed. That's not a bad thing. >We are using recipient filtering but just filtering for reciepients not in the Active Directory. I have also changed the log so it shows more data. What should I be looking for?? Do you want me to post it here? I just don't want our sending and recieving email addresses to be listed. Based on the last bit of log file you posted I'd verify that the domains to which you're sending have MX records and that the IP address you're trying to send their mail to matches the IP address in the A records named in those MX records. After that you may be into using a network monitor to see what's going on with the connection. Does the three-way handshake complete? Do you receive an unexpected RST? Is the problem between the Exchange server and the firewall, or between the firewall and the receiving server? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Well I had someone at one of the Domains that keep failing send me a data capture using Wireshark. It seems out server keeps trying to 'resend' the same packet even though the recieving server says it has recieved it OK. So our server tries to resend it then the recieving server says it already has it. This happens a few times then the recieving server just gives up and times out. Does that make sense?

On Fri, 3 Sep 2010 12:29:27 +0000, scs-04 wrote: >Well I had someone at one of the Domains that keep failing send me a data capture using Wireshark. It seems out server keeps trying to 'resend' the same packet even though the recieving server says it has recieved it OK. So our server tries to resend it then the recieving server says it already has it. This happens a few times then the recieving server just gives up and times out. Does that make sense? How do you know it's your server that tries sending the packet again? When you compare their capture with one you run on your server, do you see the retransmissions? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I can tell by the IP address that it is coming from us. Yes it looks the same as the one run from our server. When I run the SMTP tests at mxtoolbox.com everything passes for our domain but it has warnings on the response time. Sometimes it can be over 5 seconds. I have replaced the cable between the internet modem and our router, flashed the firmware in our router, and updated the NIC drivers in our server. Anything else I can look into??

On Wed, 8 Sep 2010 13:25:25 +0000, scs-04 wrote: >I can tell by the IP address that it is coming from us. Yes it looks the same as the one run from our server. And you see this in a network monitor trace that you run? Does your server ever see the ACK sent by the other machine? >When I run the SMTP tests at mxtoolbox.com everything passes for our domain but it has warnings on the response time. Sometimes it can be over 5 seconds. I have replaced the cable between the internet modem and our router, flashed the firmware in our router, and updated the NIC drivers in our server. Anything else I can look into?? NIC firmware? Updating the tcpip.sys driver? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Yes, we can see the ACK. How do I update the tcpip.sys driver? thanks

On Mon, 13 Sep 2010 11:57:22 +0000, scs-04 wrote: >Yes, we can see the ACK. Okay, then do you see the retransmission of the packet that was ACK'd? >How do I update the tcpip.sys driver? If your system is upt-to-date with patches you shouldn't have to. Check the version number on the tcpip.sys file and see if it's something recent (e.g. 5.2.3790.4573). --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP