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:
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.
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.
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 by your server as its configuration server, but that slight delay sounds AD related.
Knowing that using HELO works, I'd ask if there is something between your Exchange server and the other MTA that may be blocking the ESMTP keywords sent by MessageLabs (and, perhpas, other domains). I didn't see anything in your log files after the EHLO command from MessageLabs. I would have expected to see this sequence:
But there's no STARTTLS, PIPELINING or 8BITMIME in your log. Since your SMTP server never sees a response from its EHLO it just quits and retries 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 get nothing, the problem's on your side and whoever's providing your firewall/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 send a large attachment to another MTA and the size of the message exceeds the limit set by the other server you'll have to send megabytes of data to the other machine and it may send back an equally large NDR to your server. You won't be able to use TLS or any of the ESMTP stuff that makes email move faster (e.g. chunking and pipelining), either.
I'd still go with the 2nd Send Connector for the domains that give you a problem. --- Rich Matheisen MCSE+I, Exchange MVP
---
Rich Matheisen
MCSE+I, Exchange MVP
Marked as answer byDaniel CummingFriday, February 5, 2010 12:51 PM
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 it appears that you are) then either the target server is too busy to accept a connection or they have you in a block list (either a personal one, or one for the entire domain).
Since the domain lifetouch.com uses messagelabs as their ISP (or their spam filter), and messagelabs uses (at this time) 13 MTAs for that domain, it's unlikely that the servers are all busy. I'd go with "they don't want to talk to you" as the reaon you can't connect.
resolve this is to contact your correspondant and ask them to have their admin fix the problem. --- Rich Matheisen MCSE+I, Exchange MVP ---
Rich Matheisen
MCSE+I, Exchange MVP
Proposed as answer byElvis WeiWednesday, December 23, 2009 8:03 AM
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?
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.
Proposed as answer byElvis WeiWednesday, December 23, 2009 8:03 AM
Marked as answer byDaniel CummingWednesday, December 23, 2009 3:19 PM
Unmarked as answer byDaniel CummingWednesday, December 23, 2009 3:19 PM
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.3 9.157.165] 4 3 ms 3 ms 3 ms ge-5-2-cr01.snj.comcastcommercial.net [208.39.15 7.65] 5 7 ms 7 ms 7 ms ge-12-0-cr01.phl.comcastcommercial.net [208.39.1 57.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 [6 8.86.85.89] 8 23 ms 20 ms 20 ms pos-0-2-0-0-pe01.ashburn.va.ibone.comcast.net [6 8.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.24 1.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 unre achable.
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
When I do a simple NSLOOKUP on their MX it returns the IP address 208.39.161.68 as the MTA. The answer's non-authoritative, though.
Using the MXToolbox site and looking for their MX also returns the correct address, now.
Looks like they got it straightened out. --- Rich Matheisen MCSE+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.
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? Or from an IP address different to the one that receives your e-mail (see below)?
I see there's another machine in your domain that sends email: 208.39.161.70 mail1.bordentown.k12.nj.us
I see that your domain doesn't publish any SPF data. I also see that your 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 by that service and how the consumers of the service decide to use that information.
I suspect that looking for problems with the address of the server that /receives/ your email (208.39.161.68) isn't going to much help. :-)
Your sending volume seems to be a bit sporadic. That, too, can trigger some reputation services. The ones above both seem satisfied with your reputation -- but they're not MessageLabs. --- Rich Matheisen MCSE+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.
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.
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 and out) 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 mxtoolbox tools need a checkup. Going right to their web site and using their stuff 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.70
Your .68 address PTR record agrees with the "btvircom.bordentown.k12.nj.us" you cite below. See thei URL:
>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 the name 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 sending btmail.bordentown.k12.nj.us in the HELO\EHLO command and that there's no "A" record in DNS for that name. In other words you're failing the much more accurate FORWARD lookup using the name your server sends to identify itself.
Change that to mail1.bordentown.k12.nj.us and your reverse and forward lookups will agree. If that's your problem, and there's no guarantee that it is, then you'll be okay. Even if it's not, you'll be in a much better 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 SMTP Virtual 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 multiple personality disorder. :-) --- Rich Matheisen MCSE+I, Exchange MVP
---
Rich Matheisen
MCSE+I, Exchange MVP
>I think your problem is that your server is sending btmail.bordentown.k12.nj.us in the HELO\EHLO command and that there's no "A" record in DNS for that name. In other words you're failing the much more accurate FORWARD lookup using the name your server sends to identify itself.
Change that to mail1.bordentown.k12.nj.us and your reverse and forward lookups will agree. If that's your problem, and there's no guarantee that it is, then you'll be okay. Even if it's not, you'll be in a much better 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 is doing, so that should be pretty easy to check. If it's still sending the old name just recycle the transport service.
As I said, there's no guarantee that this is the problem you're having with MessageLabs. All you're doing right now is tidying up you side of the transaction to eliminate potential problems.
They, like everyone else, run their own e-mail servers in their own way. 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 critical then 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 and ask what's going on. Pick up the phone and call the people you're supposed to be dealing with and find out why they won't accept your email.
The point here is that e-mail isn't the only form of communication you have at your disposal. There's still that good old telephone on your desk. --- Rich Matheisen MCSE+I, Exchange MVP
---
Rich Matheisen
MCSE+I, Exchange MVP
>>No, not usually. The SMTP send log should show you what your server is doing, so that should be pretty easy to check. If it's still sending the old name just recycle the transport service.
As I said, there's no guarantee that this is the problem you're having with MessageLabs. All you're doing right now is tidying up you side of the transaction to eliminate potential problems.
They, like everyone else, run their own e-mail servers in their own way. 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 critical then 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 and ask what's going on. Pick up the phone and call the people you're supposed to be dealing with and find out why they won't accept your email.
The point here is that e-mail isn't the only form of communication you have at your disposal. There's still that good old telephone on your desk.
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.
-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 your server. If that works, try "ping <ip-address> -f -l 1473". That should work. If it fails then there's a router between your server and their server that's fragmenting the packet. In that case, try a smaller packet size, say, 1300.
Once you find the maximum packet size, adjust your server's MTU or, if it's your router that's the problem, fix the problem there. Otherwise, you might be able to either change the routing, or convince the entity that owns the router that's fragmenting the packet to fix their router.
Wireshark is a nice network monitor if you want to investigate further. --- Rich Matheisen MCSE+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 the domains 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 of EHLO. --- Rich Matheisen MCSE+I, Exchange MVP
---
Rich Matheisen
MCSE+I, Exchange MVP
>Create a new Send Connector. Put into the "Address Space" tab the domains 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 of EHLO.
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,context 2010-01-25T00:26:55.561Z,Internet Email,08CC6B6BA723A7DA,0,,195.245.230.51:25,*,,attempting to connect 2010-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,-,,Remote 2010-01-25T00:26:55.866Z,Internet Email,08CC6B6BA723A7DA,0,,85.158.136.83:25,*,,attempting to connect 2010-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,-,,Remote 2010-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 using is named "Internet Email" (it's in the "connector-id" column). Is that the new send connector? If not, then you're looking at the wrong connector in the log. Did you set the "Protocol logging level" on the connector to "Verbose"? Do you see the new connector name in the log? Is the address space on the connector populated correctly? --- Rich Matheisen MCSE+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.
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 by your server as its configuration server, but that slight delay sounds AD related.
Knowing that using HELO works, I'd ask if there is something between your Exchange server and the other MTA that may be blocking the ESMTP keywords sent by MessageLabs (and, perhpas, other domains). I didn't see anything in your log files after the EHLO command from MessageLabs. I would have expected to see this sequence:
But there's no STARTTLS, PIPELINING or 8BITMIME in your log. Since your SMTP server never sees a response from its EHLO it just quits and retries 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 get nothing, the problem's on your side and whoever's providing your firewall/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 send a large attachment to another MTA and the size of the message exceeds the limit set by the other server you'll have to send megabytes of data to the other machine and it may send back an equally large NDR to your server. You won't be able to use TLS or any of the ESMTP stuff that makes email move faster (e.g. chunking and pipelining), either.
I'd still go with the 2nd Send Connector for the domains that give you a problem. --- Rich Matheisen MCSE+I, Exchange MVP
---
Rich Matheisen
MCSE+I, Exchange MVP
Marked as answer byDaniel CummingFriday, February 5, 2010 12:51 PM
