I am running Exchange 2007 on Windows Server 2003 Enterprise x64 Edition SP2. This is the only Exchange server in our environment. Over the past few months I have been noticing that some external messages are getting stuck in the queue. First the user sending the message will recieve a delivery is delayed message. After two days a failed delivery message is sent. It is only a small number of domains that we cannot send messages. If one of these domains sends us a message, it is recieved. However if we try to reply the message is not sent. The same happens if we try sending a new message to them. The error in the queue reads "451 4.4.0 primary target IP address responded with "421.4.4.2 unable to connect."attempted failover to alternate host, but that did not succeed.Either there are no alternate hosts, or delivery failed to all alternate hosts." I have seen similiar issues on many forums but I cannot find a solution. Any help would be appreciated. Thank you. Delivery is delayed to these recipients or distribution lists: 'Deborah Wohlers' Subject: RE: email issue This message has not yet been delivered. Microsoft Exchange will continue to try delivering the message on your behalf. Delivery of this message will be attempted until 12/16/2009 9:05:58 AM (GMT-05:00) Eastern Time (US & Canada). Microsoft Exchange will notify you if the message can't be delivered by that time. _____ Sent by Microsoft Exchange Server 2007 Delivery has failed to these recipients or distribution lists: 'Deborah Wohlers'Microsoft Exchange has been trying to deliver this message without success and has stopped trying. Please try sending this message again, or provide the following diagnostic text to your system administrator. _____ Sent by Microsoft Exchange Server 2007 Diagnostic information for administrators: Generating server: btmail.bordentown.k12.nj.us dwohlers@lifetouch.com#550 4.4.7 QUEUE.Expired; message expired ## Original message headers: Received: from btmail.bordentown.k12.nj.us ([172.16.1.6]) by btmail.bordentown.k12.nj.us ([172.16.1.6]) with mapi; Mon, 14 Dec 2009 07:45:03 -0500From: Daniel Cumming <dcumming@bordentown.k12.nj.us>To: 'Deborah Wohlers' <dwohlers@lifetouch.com>Date: Mon, 14 Dec 2009 07:45:02 -0500Subject: RE: email issueThread-Topic: email issueThread-Index: AcpyxKOm2He9AwKRRd2PWYqoC2FTEgApFo0QMessage-ID: <B6DD812076F9CC4A80B586DAF723B84B0A6B803674@btmail.bordentown.k12.nj.us>References: <55116D8C382F1B4E879A05DE823667961C9612DC@exchlt2.LIFETOUCH.NET>In-Reply-To: <55116D8C382F1B4E879A05DE823667961C9612DC@exchlt2.LIFETOUCH.NET>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: yesX-MS-TNEF-Correlator:acceptlanguage: en-USContent-Type: multipart/related; boundary="_004_B6DD812076F9CC4A80B586DAF723B84B0A6B803674btmailbordent_"; type="multipart/alternative"MIME-Version: 1.0

I would suggest using the Mail Flow Troubleshooter found in the Exchange Management Console Toolbox.

What happens if you try to telnet to port 25 on lilfetouch.com's mail server from your Exchange server? Do you get an smtp banner?

On Mon, 21-Dec-09 19:33:40 GMT, Daniel Cumming wrote:wever if we try to reply the message is not sent. The same happens if we try sending a new message to them. The error in the queue reads "451 4.4.0 primary target IP address responded with "421.4.4.2 unable to connect."attempted failover to alternate host, but that did not succeed.Either there are no alternate hosts, or delivery failed to all alternate hosts." I have seen similiar issues on many forums but I cannot find a solution. Any help would be appreciated. Thank you. If you're getting a response code from the target server (which itappears that you are) then either the target server is too busy toaccept a connection or they have you in a block list (either apersonal one, or one for the entire domain).Since the domain lifetouch.com uses messagelabs as their ISP (or theirspam filter), and messagelabs uses (at this time) 13 MTAs for thatdomain, it's unlikely that the servers are all busy. I'd go with "theydon't want to talk to you" as the reaon you can't connect. resolve this is to contact your correspondant and askthem to have their admin fix the problem.---Rich MatheisenMCSE+I, Exchange MVP--- Rich Matheisen MCSE+I, Exchange MVP

I've found a few things that may be related. I am assuming that the address for the lifetouch mail server is mail.lifetouch.com. However I can't ping this address. Is there a way to find the mail server address of this domain? I also looked at a domain that I can send messages. For example I can ping mail.trianglelaptops.com. However I can't telnet to it via port 25. Below is the command I used. Does this mean that port 25 is being blocked somewhere?telnet mail.trainglelaptops.com 25

As noted earlier, lifetouch.com is using MessageLabs. Their MX records are:20 cluster5a.us.messagelabs.com. [TTL=300] IP=216.82.250.51 (No Glue) [TTL=251] [US]10 cluster5.us.messagelabs.com. [TTL=300] IP=216.82.250.3 (No Glue) [TTL=251] [US]The MX records for trianglelaptops.com are:0 smtp.secureserver.net. [TTL=3600] IP=216.69.186.201 (No Glue) [TTL=300] [US]10 mailstore1.secureserver.net. [TTL=3600] IP=72.167.238.201 (No Glue) [TTL=300] [US]If you cannot telnet to port 25 on those servers from your Exchange server and get back an smtp banner, then you are being blocked, or ignored.

A few users have forwarded me the Exchange "Delivery Delayed" message. I am finding that all the messages that are delayed go through MessageLabs. However I called message labs and they told me they do not maintain their own blacklist. They told me I could check if my IP was on a blacklist by using http://www.mxtoolbox.com . I check using that site but my IP is not on any blacklists. But is does seem to have something to do with domains that use MessageLabs. Is there something else I could check?

Turn up your protocol logging, and get some smtp logs of the delivery failures to the problem domains, and send them to Message Labs. That should be enough for them to start troubleshooting the issue.

I agree with the friends above. You need to work with Message labs for this issue. Collect some failure smtp log and send to them.

I gave Message Labs a call this morning. Since our district doesn't use Message Labs they provided only limited support. They told me I would have to get one of the companies that is using message labs to call in and report the issue. I am going to give that a try and see how far I can get.

I am still looking into this issue as Message Labs wasn't much help. I made a list of domains that we cannot send email. So far I have 8 and they all use Message Labs. I found a site that gave me the MX records of the email addresses. I ran a tracert to the Message Labs mail servers. I pasted the results below. I am noticing that when it gets to between hops 15-20 it gives the message "reports: Destination net unreachable". However I am able to ping the 216.82.248.117 address. Could anybody tell me what this may mean?H:\>tracert cluster5.us.messagelabs.com Tracing route to cluster5.us.messagelabs.com [216.82.250.51]over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 172.16.1.10 2 1 ms 1 ms 1 ms btvircom.bordentown.k12.nj.us [208.39.161.65] 3 4 ms 3 ms 3 ms at-1-0-0-8-br01.snj.comcastcommercial.net [208.39.157.165] 4 3 ms 3 ms 3 ms ge-5-2-cr01.snj.comcastcommercial.net [208.39.157.65] 5 7 ms 7 ms 7 ms ge-12-0-cr01.phl.comcastcommercial.net [208.39.157.38] 6 17 ms 18 ms 17 ms te-1-4-0-7-702-cr01.newyork.ny.ibone.comcast.net [68.86.92.73] 7 20 ms 20 ms 20 ms pos-1-15-0-0-cr01.mclean.va.ibone.comcast.net [68.86.85.89] 8 23 ms 20 ms 20 ms pos-0-2-0-0-pe01.ashburn.va.ibone.comcast.net [68.86.86.70] 9 21 ms 20 ms 20 ms 192.205.37.41 10 91 ms 91 ms 91 ms cr2.wswdc.ip.att.net [12.122.84.82] 11 91 ms 90 ms 91 ms cr1.attga.ip.att.net [12.122.1.173] 12 91 ms 92 ms 91 ms cr2.dlstx.ip.att.net [12.122.28.174] 13 91 ms 92 ms 91 ms cr1.dlstx.ip.att.net [12.122.1.209] 14 91 ms 91 ms 91 ms cr1.phmaz.ip.att.net [12.122.28.182] 15 91 ms 90 ms 90 ms gar4.phmaz.ip.att.net [12.123.206.145] 16 91 ms 91 ms 91 ms 12.122.255.106 17 91 ms 92 ms 91 ms mdf001c7613r0004-gig-12-1.phx1.attens.net [63.241.130.174] 18 94 ms 93 ms 91 ms v100.r.t108.messagelabs.net [216.82.248.117] 19 v100.r.t108.messagelabs.net [216.82.248.117] reports: Destination net unreachable. Trace complete.Here are the mx records I have for Message Labs.cluster2.us.messagelabs.comcluster2a.us.messagelabs.comcluster3.us.messagelabs.comcluster3a.us.messagelabs.comcluster5.us.messagelabs.comcluster5a.us.messagelabs.comcluster7a.us.messagelabs.comcluster7b.us.messagelabs.comcluster7.us.messagelabs.comcluster8a.us.messagelabs.comcluster8.us.messagelabs.comcluster9a.us.messagelabs.comcluster9.us.messagelabs.com2

This is normal. I guess Messagelabs wants to hide them so you dont see their routers. I had a look of your own domain bordentown.k12.nj.us. Its MX record doesn't seem right. All ports seems blocked and the MX record doesn't return a valid IP address. Sure, you may using a fake one here. But if this is your real domain name, please check if this is what it should be.

Could you tell me what you see on my MX record that doesn't look right? What tool were you using to check the MX record? It shoud return 208.39.161.65 as the IP address and we are not using a fake one.

I am using the tool from this site: http://www.mxtoolbox.comIf put your domain bordentown.k12.nj.us there, The MX record show as btvircom.bordentown.k12.nj.us and IP show as 0.0.0.0

On Wed, 6-Jan-10 03:57:27 GMT, aha_tom wrote:>I am using the tool from this site: http://www.mxtoolbox.comIf put your domain bordentown.k12.nj.us there, The MX record show as btvircom.bordentown.k12.nj.us and IP show as 0.0.0.0 When I do a simple NSLOOKUP on their MX it returns the IP address208.39.161.68 as the MTA. The answer's non-authoritative, though.Using the MXToolbox site and looking for their MX also returns thecorrect address, now.Looks like they got it straightened out.---Rich MatheisenMCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I'm not sure what happened as I was also using mxtoolbox.com and it was displaying the correct 208.39.161.68 address.Does anyone have any further suggestions? I'm really at a loss here. I can't figure out we can't send to only Message Labs addresses. All other email works correctly. Also, these Message Labs users can successful send to us but if we reply we get the error message.

I am having a similar problem with this issue. All with Message Labs - Message Labs will not talk to me, the other companies don't tend to pursue it enough to get Message Labs to work on it. This is a Message Labs problem, we have been having this problem since early November 2009 - and no one will fix it. We have *no* problems with any other email domains, but ones that use Message Labs.

Jennifer,It sounds like you are having the exact same problem. I noticed the issue happening on our end around October 2009. I too have called Message Labs and they have instructed me to have one of the companies using their product to call in. But that really doesn't get me anywhere. We also have no problems at all emailing any other domains. One thing I found is that the message labs email servers appear to be on a blacklist. I checked a few of their addresses using mxtoolbox.com and they appear on a backscatter.org blacklist. But I don't think that should matter because if they were on a blacklist they wouldn't be able to send to me. Shouldn't I be able to send to them even if they are on a blacklist?If you find any further information please let me know because I am really stuck on this issue.

I don't the answer to whether you should be able to send to them, even if they are on a blacklist of some variety - as I do not know the specifics of how Message Labs feeds into the mix, other than the fact that when our system does a lookup for specific domains (lifetouch is one of them above, we have 2 other large organizations too that we cannot communicate with also), it passes through Message Labs. No one will help us either - however if I come up with an answer, any answer, I'll be sure to share.

On Wed, 6-Jan-10 19:54:22 GMT, Daniel Cumming wrote:>Jennifer,It sounds like you are having the exact same problem. I noticed the issue happening on our end around October 2009. I too have called Message Labs and they have instructed me to have one of the companies using their product to call in. But that really doesn't get me anywhere. We also have no problems at all emailing any other domains. One thing I found is that the message labs email servers appear to be on a blacklist. I checked a few of their addresses using mxtoolbox.com and they appear on a backscatter.org blacklist. But I don't think that should matter because if they were on a blacklist they wouldn't be able to send to me. Shouldn't I be able to send to them even if they are on a blacklist?If you find any further information please let me know because I am really stuck on this issue. Does your domain send its e-mail directly or through a smart host? Orfrom an IP address different to the one that receives your e-mail (seebelow)?I see there's another machine in your domain that sends email:208.39.161.70 mail1.bordentown.k12.nj.usI see that your domain doesn't publish any SPF data. I also see thatyour IP address (208.39.161.70) doesn't send a heck of a lot of email-- which means it may be flagged by reputation servers as"suspicious". Just /how/ suspicious depends on the methods used bythat service and how the consumers of the service decide to use thatinformation.I suspect that looking for problems with the address of the serverthat /receives/ your email (208.39.161.68) isn't going to much help.:-)http://www.trustedsource.org/query/208.39.161.70http://www.senderbase.org/senderbase_queries.detailip?search_string=208.39.161.70&which_others=%2F31Your sending volume seems to be a bit sporadic. That, too, can triggersome reputation services. The ones above both seem satisfied with yourreputation -- but they're not MessageLabs.---Rich MatheisenMCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks for the response. To clarify 208.39.161.68 is our Vircom anti spam appliance. All inbound and outbound mail passes through that box. The 208.39.161.70 address is our Exchange server. I have just put in a call to Vircom to verify that everything is configured properly. I am waiting for a call back. We did start using the Vircom product right around the same time as this problem started.

There are several things you should run down. First, check your outbound IP. This can be done by either sending yourself an email to an outside address like gmail and using our Header Analyzer tool on that message or sending an email to ping@mxtoolbox.com. This tool will perform the header analyzer on the message and return the results to whatever email address is on the reply-to address. Once you have your real outbound IP, run it through the blacklist check tool to make sure that it is clear. On another front I would suggest hopping on the Exchange server and performing a manual SMTP test using telnet. Start by connecting from the cmd prompt using 'telnet cluster5.us.messagelabs.com 25' and you should get a banner that looks similar to this Connected to cluster5.us.messagelabs.com (216.82.253.163). Escape character is '^]'. 220 server-10.tower-166.messagelabs.com ESMTP After you have connected, you can perform the SMTP commands to manually generate a message and you can see the responses they give - see http://www.mxtoolbox.com/csstatic/11079.html. My guess is that you are either being blocked by message by some global filter or that you are on the end users block list either by email address or somehow by content. You can test the content usually by sending a very dry email with no HTML and no signature with a very innocent body. Once you fidn the reason for the block you can either call ML back or I suggest contacting the recipient via other modes and let them bring it up. False positives should be treated very seriously especially when brought up by a paying customer. Please feel free to send any further question directly to support@mxtoolbox.com and we'll do what we can to help. Peter @MxToolBox

Thank you very much Peter. You instructions were detailed and I think it helped me identify a problem. As you instructed I sent an email to ping@mxtoolbox.com. The response email identified 208.39.161.70 as my outbound IP. That IP is not on any blacklists. However, at the bottom of the response email a message was displayed “Reverse DNS FAILED! This is a problem.”. In reading the description of the problem this sounds like this is what’s causing my issue. Recently we changed our anti spam appliance. We are now using Vircom. The Vircom server IP is 208.39.161.68. The FQDN of the Vircom box is btvircom.bordentown.k12.nj.us. Our Exchange server IP is 208.39.161.70. The FQDN of the Exchange server is btmail.bordentown.k12.nj.us. Our outgoing mail is send directly from our Exchange server. It is not passed through the Vircom box. All incoming mail is directed through the Vircom box. My question is how do I solve this issue? Do I need to call my ISP and if so what should I tell them?

On Wed, 13-Jan-10 16:32:21 GMT, Daniel Cumming wrote:>Thank you very much Peter. You instructions were detailed and I think it helped me identify a problem. As you instructed I sent an email to ping@mxtoolbox.com. The response email identified 208.39.161.70 as my outbound IP. I told you that last week. :-) You replied that all your email (in andout) was handled by the .68 address.>That IP is not on any blacklists. However, at the bottom of the response email a message was displayed ?Reverse DNS FAILED! This is a problem.?.I think that either you've made a change already or that the mxtoolboxtools need a checkup. Going right to their web site and using theirstuff finds a PTR that the .70 address that returns the name"mail1.bordentown.k12.nj.us".See this URL:http://mxtoolbox.com/SuperTool.aspx?action=ptr%3a208.39.161.70Your .68 address PTR record agrees with the"btvircom.bordentown.k12.nj.us" you cite below. See thei URL:http://mxtoolbox.com/SuperTool.aspx?action=ptr%3a208.39.161.68>In reading the description of the problem this sounds like this is what?s causing my issue. Just HAVING a PTR record for your IP address is usually sufficient.There are some sites that insist (against all common sense) that thename in the PTR must match the name used in the HELO\EHLO.>Recently we changed our anti spam appliance. We are now using Vircom. The Vircom server IP is 208.39.161.68. The FQDN of the Vircom box is btvircom.bordentown.k12.nj.us. Our Exchange server IP is 208.39.161.70. The FQDN of the Exchange server is btmail.bordentown.k12.nj.us.Not according to the PTR record for that address!>Our outgoing mail is send directly from our Exchange server. It is not passed through the Vircom box. All incoming mail is directed through the Vircom box. I think your problem is that your server is sendingbtmail.bordentown.k12.nj.us in the HELO\EHLO command and that there'sno "A" record in DNS for that name. In other words you're failing themuch more accurate FORWARD lookup using the name your server sends toidentify itself.Change that to mail1.bordentown.k12.nj.us and your reverse and forwardlookups will agree. If that's your problem, and there's no guaranteethat it is, then you'll be okay. Even if it's not, you'll be in a muchbetter position for getting your email accepted at many other places.>My question is how do I solve this issue? If this is your problem then making a simple change in your SMTPVirtual Server's configuration will make it all go away.>Do I need to call my ISP and if so what should I tell them? Nope. As a first step you just need to cure your server's multiplepersonality disorder. :-)---Rich MatheisenMCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

>I think your problem is that your server is sendingbtmail.bordentown.k12.nj.us in the HELO\EHLO command and that there'sno "A" record in DNS for that name. In other words you're failing themuch more accurate FORWARD lookup using the name your server sends toidentify itself.Change that to mail1.bordentown.k12.nj.us and your reverse and forwardlookups will agree. If that's your problem, and there's no guaranteethat it is, then you'll be okay. Even if it's not, you'll be in a muchbetter position for getting your email accepted at many other places.I just changed the "Specify the FQDN this connector will provide in response t HELO or EHLO:" fields on the send and recieve connectors on my Exchange server from btmail.bordentown.k12.nj.us to mail1.bordentown.k12.nj.us. I am still getting the same error message in the queue. Does a certain amount of time for this change to take effect?

On Wed, 13-Jan-10 20:46:07 GMT, Daniel Cumming wrote:>>I think your problem is that your server is sendingbtmail.bordentown.k12.nj.us in the HELO\EHLO command and that there'sno "A" record in DNS for that name. In other words you're failing themuch more accurate FORWARD lookup using the name your server sends toidentify itself.Change that to mail1.bordentown.k12.nj.us and your reverse and forwardlookups will agree. If that's your problem, and there's no guaranteethat it is, then you'll be okay. Even if it's not, you'll be in a muchbetter position for getting your email accepted at many other places.I just changed the "Specify the FQDN this connector will provide in response t HELO or EHLO:" fields on the send and recieve connectors on my Exchange server from btmail.bordentown.k12.nj.us to mail1.bordentown.k12.nj.us. I am still getting the same error message in the queue. Does a certain amount of time for this change to take effect? No, not usually. The SMTP send log should show you what your server isdoing, so that should be pretty easy to check. If it's still sendingthe old name just recycle the transport service.As I said, there's no guarantee that this is the problem you're havingwith MessageLabs. All you're doing right now is tidying up you side ofthe transaction to eliminate potential problems.They, like everyone else, run their own e-mail servers in their ownway. If they (or their customers -- which use them as spam filters)don't like your e-mail and they don't want to tell you why, well,then, don't worry about it. If it's something that's business criticalthen contact people at the domain you can't send to. Use HotMail,Yaoo!, AOL, or any other free email service to send them e-mail andask what's going on. Pick up the phone and call the people you'resupposed to be dealing with and find out why they won't accept youremail.The point here is that e-mail isn't the only form of communication youhave at your disposal. There's still that good old telephone on yourdesk.---Rich MatheisenMCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

>>No, not usually. The SMTP send log should show you what your server isdoing, so that should be pretty easy to check. If it's still sendingthe old name just recycle the transport service.As I said, there's no guarantee that this is the problem you're havingwith MessageLabs. All you're doing right now is tidying up you side ofthe transaction to eliminate potential problems.They, like everyone else, run their own e-mail servers in their ownway. If they (or their customers -- which use them as spam filters)don't like your e-mail and they don't want to tell you why, well,then, don't worry about it. If it's something that's business criticalthen contact people at the domain you can't send to. Use HotMail,Yaoo!, AOL, or any other free email service to send them e-mail andask what's going on. Pick up the phone and call the people you'resupposed to be dealing with and find out why they won't accept youremail.The point here is that e-mail isn't the only form of communication youhave at your disposal. There's still that good old telephone on yourdesk.Thanks Rich. I recycled the transport service this morning but no luck. There are some Windows updates that require a restart of the server so I will do that tonight after hours. I don't think that will make a difference though. I have actually contacted one of the companies we are having problems sending email. I turned on SMTP logging on our Exchange server. I sent them the logs yesterday and they are going to pass them along to MessageLabs. They have opened a ticket with MessageLabs so hopefully they can resolve the issue. Unfortunately this problem inolves several companies that we need to send email. If the user can't resolve the issue with MessageLabs then I understand that there is not much more I can do on my end.

One of the companies we were having problems sending email to opened up a ticket with MessageLabs. Here is the response from MessageLabs. Regarding Parker McCay P.A. not being able to receive email from bordentown.k12.nj.us. It looks like we accepted the connection, then there was some sort of failure to reply on their end, the session hangs after our mail server sends the command regarding what protocols we support after which we disconnected after 4 minutes. Our support center technicians believe there may be an issue with the sending MTU size on their firewall or some sort of rule they're running. For us to investigate further we would need to see a tcptraceroute or packetdump from their end while trying to send through to us if that is possible. [aclark@server-7.tower-192.messagelabs.com:/var/log/smtp]: grep 24779877 @400000004b4e303d356205f4.s | tai64nlocal2010-01-13 20:38:08.440208500 24779877: *** session start ***2010-01-13 20:38:08.440570500 24779877: Remote IP: 208.39.161.702010-01-13 20:38:08.440590500 24779877: Message reference: server-7.tower-192.messagelabs.com!1263415088!24779877!12010-01-13 20:38:08.443068500 24779877: < 220 server-7.tower-192.messagelabs.com ESMTP2010-01-13 20:38:08.464123500 24779877: > EHLO mail1.bordentown.k12.nj.us2010-01-13 20:38:08.464134500 24779877: < 250-server-7.tower-192.messagelabs.com2010-01-13 20:38:08.464135500 24779877: 250-STARTTLS2010-01-13 20:38:08.464136500 24779877: 250-PIPELINING2010-01-13 20:38:08.464144500 24779877: 250 8BITMIME2010-01-13 20:42:08.463193500 24779877: *** session end *** 2010-01-13 20:38:10.801655500 43959299: *** session start ***2010-01-13 20:38:10.802114500 43959299: Remote IP: 208.39.161.702010-01-13 20:38:10.802115500 43959299: Message reference: server-10.tower-192.messagelabs.com!1263415090!43959299!12010-01-13 20:38:10.804903500 43959299: < 220 server-10.tower-192.messagelabs.com ESMTP2010-01-13 20:38:10.825968500 43959299: > EHLO mail1.bordentown.k12.nj.us2010-01-13 20:38:10.826000500 43959299: < 250-server-10.tower-192.messagelabs.com2010-01-13 20:38:10.826000500 43959299: 250-STARTTLS2010-01-13 20:38:10.826001500 43959299: 250-PIPELINING2010-01-13 20:38:10.826002500 43959299: 250 8BITMIME2010-01-13 20:42:10.828502500 43959299: *** session end *** -The MTU on our Cisco ASA is 1500 which is the default-There are no rules on the Cisco ASA that would prevent their server from connecting to us. All other email is accepted.

On Fri, 15-Jan-10 14:39:10 GMT, Daniel Cumming wrote:>>>One of the companies we were having problems sending email to opened up a ticket with MessageLabs. Here is the response from MessageLabs. >It looks like we accepted the connection, then there was some sort of failure to reply on their end, the session hangs after our mail server sends the command regarding what protocols we support after which we disconnected after 4 minutes. Our support center technicians believe there may be an issue with the sending MTU size on their firewall or some sort of rule they're running. For us to investigate further we would need to see a tcptraceroute or packetdump from their end while trying to send through to us if that is possible. A quick check would be to try pinging one of their MTA's from yourserver. If that works, try "ping <ip-address> -f -l 1473". That shouldwork. If it fails then there's a router between your server and theirserver that's fragmenting the packet. In that case, try a smallerpacket size, say, 1300.Once you find the maximum packet size, adjust your server's MTU or, ifit's your router that's the problem, fix the problem there. Otherwise,you might be able to either change the routing, or convince the entitythat owns the router that's fragmenting the packet to fix theirrouter.Wireshark is a nice network monitor if you want to investigatefurther.---Rich MatheisenMCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

A ticket has been opend with MessageLabs through one of the clients. Today I was speaking with message labs. In the SMTP send logs MessageLabs is saying that we are trying to connect to them through EHLO. They are telling me that is the problem and we need to force our server to connect through HELO. When we try to send mail MessageLabs has verified that they recieve and accept the connect. However they are saying there is some sort of failure to reply on our end. The session hangs after the MessageLabs server sends the command regarding what protocols they support after which they disconnect after 4 minutes. I can't find a way to force Exchange to connect through HELO and I really don't think this is the issue anyway. Any suggestions would be appreciated.

On Mon, 25-Jan-10 15:46:04 GMT, Daniel Cumming wrote:>A ticket has been opend with MessageLabs through one of the clients. Today I was speaking with message labs. In the SMTP send logs MessageLabs is saying that we are trying to connect to them through EHLO. They are telling me that is the problem and we need to force our server to connect through HELO. When we try to send mail MessageLabs has verified that they recieve and accept the connect. However they are saying there is some sort of failure to reply on our end. The session hangs after the MessageLabs server sends the command regarding what protocols they support after which they disconnect after 4 minutes. I can't find a way to force Exchange to connect through HELO and I really don't think this is the issue anyway. Any suggestions would be appreciated. Create a new Send Connector. Put into the "Address Space" tab thedomains that you're having a problem sending to.Once you've created that Send Connector use the "Set-SendConnector<connector-name> -ForceHELO:$true" to have it send HELO instead ofEHLO.---Rich MatheisenMCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

>Create a new Send Connector. Put into the "Address Space" tab thedomains that you're having a problem sending to.Once you've created that Send Connector use the "Set-SendConnector<connector-name> -ForceHELO:$true" to have it send HELO instead ofEHLO.I tried creating a new send connector as described. I also tried applying the "Set-SendConnector<connector-name> -ForceHELO:$true" command to the current sent connector. The Exchange server still appears to be using EHLO. Does this change take effect immediatly? Below is an example from the most current log.#Software: Microsoft Exchange Server#Version: 8.0.0.0#Log-type: SMTP Send Protocol Log#Date: 2010-01-25T00:26:55.561Z#Fields: date-time,connector-id,session-id,sequence-number,local-endpoint,remote-endpoint,event,data,context2010-01-25T00:26:55.561Z,Internet Email,08CC6B6BA723A7DA,0,,195.245.230.51:25,*,,attempting to connect2010-01-25T00:26:55.744Z,Internet Email,08CC6B6BA723A7DA,1,172.16.1.6:1748,195.245.230.51:25,+,,2010-01-25T00:26:55.866Z,Internet Email,08CC6B6BA723A7DA,2,172.16.1.6:1748,195.245.230.51:25,<,220 server-10.tower-33.messagelabs.com ESMTP,2010-01-25T00:26:55.866Z,Internet Email,08CC6B6BA723A7DA,3,172.16.1.6:1748,195.245.230.51:25,>,EHLO mail1.bordentown.k12.nj.us,2010-01-25T00:26:55.866Z,Internet Email,08CC6B6BA723A7DA,4,172.16.1.6:1748,195.245.230.51:25,-,,Remote2010-01-25T00:26:55.866Z,Internet Email,08CC6B6BA723A7DA,0,,85.158.136.83:25,*,,attempting to connect2010-01-25T00:26:55.973Z,Internet Email,08CC6B6BA723A7DA,1,172.16.1.6:1749,85.158.136.83:25,+,,2010-01-25T00:26:56.095Z,Internet Email,08CC6B6BA723A7DA,2,172.16.1.6:1749,85.158.136.83:25,<,220 server-4.tower-36.messagelabs.com ESMTP,2010-01-25T00:26:56.095Z,Internet Email,08CC6B6BA723A7DA,3,172.16.1.6:1749,85.158.136.83:25,>,EHLO mail1.bordentown.k12.nj.us,2010-01-25T00:26:56.095Z,Internet Email,08CC6B6BA723A7DA,4,172.16.1.6:1749,85.158.136.83:25,-,,Remote2010-01-25T00:26:56.095Z,Internet Email,08CC6B6BA723A7DA,0,,193.109.254.3:25,*,,attempting to connect

On Mon, 25-Jan-10 17:05:31 GMT, Daniel Cumming wrote:>>Create a new Send Connector. Put into the "Address Space" tab thedomains that you're having a problem sending to.Once you've created that Send Connector use the "Set-SendConnector<connector-name> -ForceHELO:$true" to have it send HELO instead ofEHLO.I tried creating a new send connector as described. I also tried applying the "Set-SendConnector<connector-name> -ForceHELO:$true" command to the current sent connector. The Exchange server still appears to be using EHLO. Does this change take effect immediatly? Below is an example from the most current log.#Software: Microsoft Exchange Server#Version: 8.0.0.0#Log-type: SMTP Send Protocol Log#Date: 2010-01-25T00:26:55.561Z#Fields: date-time,connector-id,session-id,sequence-number,local-endpoint,remote-endpoint,event,data,context2010-01-25T00:26:55.561Z,Internet Email,08CC6B6BA723A7DA,0,,195.245.230.51:25,*,,attempting to connect2010-01-25T00:26:55.744Z,Internet>Email,08CC6B6BA723A7DA,1,172.16.1.6:1748,195.245.230.51:25,+,,2010-01-25T00:26:55.866Z,Internet Email,08CC6B6BA723A7DA,2,172.16.1.6:1748,195.245.230.51:25,<,220 server-10.tower-33.messagelabs.com ESMTP,2010-01-25T00:26:55.866Z,Internet Email,08CC6B6BA723A7DA,3,172.16.1.6:1748,195.245.230.51:25,>,EHLO mail1.bordentown.k12.nj.us,2010-01-25T00:26:55.866Z,Internet Email,08CC6B6BA723A7DA,4,172.16.1.6:1748,195.245.230.51:25,-,,Remote2010-01-25T00:26:55.866Z,Internet Email,08CC6B6BA723A7DA,0,,85.158.136.83:25,*,,attempting to connect2010-01-25T00:26:55.973Z,Internet Email,08CC6B6BA723A7DA,1,172.16.1.6:1749,85.158.136.83:25,+,,2010-01-25T00:26:56.095Z,Internet Email,08CC6B6BA723A7DA,2,172.16.1.6:1749,85.158.136.83:25,<,220 server-4.tower-36.messagelabs.com ESMTP,2010-01-25T00:26:56.095Z,Internet Email,08CC6B6BA723A7DA,3,172.16.1.6:1749,85.158.136.83:25,>,EHLO mail1.bordentown.k12.nj.us,2010-01-25T00:26:56.095Z,Internet>Email,08CC6B6BA723A7DA,4,172.16.1.6:1749,85.158.136.83:25,-,,Remote2010-01-25T00:26:56.095Z,Internet Email,08CC6B6BA723A7DA,0,,193.109.254.3:25,*,,attempting to connect It should be effective pretty quickly. The send connector you're usingis named "Internet Email" (it's in the "connector-id" column). Is thatthe new send connector? If not, then you're looking at the wrongconnector in the log. Did you set the "Protocol logging level" on theconnector to "Verbose"? Do you see the new connector name in the log?Is the address space on the connector populated correctly?---Rich MatheisenMCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

I was having trouble creating the new send connector correctly so I forced HELO again on my main send connector. That resolved the issue! I guess the change wasn't immediate. I'm not sure why this happened all of the sudden, because I haven't made any major configuration changes to the Exchange server since we upgraded to 2007. I guess it's possible that MessageLabs changed the way they handle incoming messages. "Set-SendConnector<connector-name> -ForceHELO:$true"Above is the command I used which Rich suggested. I would say it took about 5-10 minutes to take effect.My final question would be is there any downside to forcing my Exchange server to use HELO over EHLO?Thanks to everyone for all of their help, especially you Rich!

On Mon, 25-Jan-10 19:11:47 GMT, Daniel Cumming wrote:>I was having trouble creating the new send connector correctly so I forced HELO again on my main send connector. That resolved the issue! I guess the change wasn't immediate. I'm not sure why this happened all of the sudden, because I haven't made any major configuration changes to the Exchange server since we upgraded to 2007. I guess it's possible that MessageLabs changed the way they handle incoming messages. "Set-SendConnector<connector-name> -ForceHELO:$true"Above is the command I used which Rich suggested. I would say it took about 5-10 minutes to take effect.Close enough to "immediate" for me. :-)I don't know on which DC your change was made, and which DC is used byyour server as its configuration server, but that slight delay soundsAD related.Knowing that using HELO works, I'd ask if there is something betweenyour Exchange server and the other MTA that may be blocking the ESMTPkeywords sent by MessageLabs (and, perhpas, other domains). I didn'tsee anything in your log files after the EHLO command fromMessageLabs. I would have expected to see this sequence:telnet 195.245.230.51 25220 server-12.tower-33.messagelabs.com ESMTPehlo XXXXX.com250-server-12.tower-33.messagelabs.com250-STARTTLS250-PIPELINING250 8BITMIMEBut there's no STARTTLS, PIPELINING or 8BITMIME in your log. Sinceyour SMTP server never sees a response from its EHLO it just quits andretries later.The sort of situation is typical of "E-Mail Security" devices that"protect" you from ESMTP (for what reason, I don't know).You might try "telnet 195.245.230.51 25" from your server, send a"EHLO mail1.bordentown.k12.nj.us" and see what comes back. If you getnothing, the problem's on your side and whoever's providing yourfirewall/SMTP proxy/Spam filtering is probably to blame.>My final question would be is there any downside to forcing my Exchange server to use HELO over EHLO?Thanks to everyone for all of their help, especially you Rich! There are downsides, but none of them fatal. If, for example, you senda large attachment to another MTA and the size of the message exceedsthe limit set by the other server you'll have to send megabytes ofdata to the other machine and it may send back an equally large NDR toyour server. You won't be able to use TLS or any of the ESMTP stuffthat makes email move faster (e.g. chunking and pipelining), either.I'd still go with the 2nd Send Connector for the domains that give youa problem.---Rich MatheisenMCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP