Our app servers have been switched to use a Recieve connector on our Exchange 2007 box as a smart host. There is one Send Connecotr on the Exchange 2007 that connects to our Exchange 2003 server which sends to the Internet. Now we are getting NDR's from on some of our outgoing mail with error (554 5.6.1 Body type not supported by Remote Host). Is this an issue where we need to send HELO instead of EHLO. I have changed that setting on the Exchange 2003 Internet Connector, but still ho luck. Does this need to be done on the 2007 box on the send connector, maybe Set-SendConnector -identity Send connector name -ForceHELO $true.Thanks for any advice.

Yes, you could. Try it and test. ( Which server is generating the error? the remote servers or the 2003?). SMTP Logging will tell you more.Alternatively, turn off the ESMTP advertising on the Exchange 2003 side and test:( This will force the 2007 server to send HELO to the 2003 server.)http://support.microsoft.com/kb/257569/How to turn off ESMTP verbs in Exchange 2000 Server and in Exchange Server 2003

Thanks. What would be the syntax to reverse the force HELO command if it doesn't work?

for the 2007 send connector?Just set it to $false.Set-SendConnector -identity Send connector name -ForceHELO $false

On Fri, 18-Dec-09 15:39:42 GMT, akg414s wrote:>Thanks. What would be the syntax to reverse the force HELO command if it doesn't work? You should only have to disable the 8bitmime keyword on the Exchange2003 server to fix this.---Rich MatheisenMCSE+I, Exchange MVP--- Rich Matheisen MCSE+I, Exchange MVP

Yep, but he apparently already did that.

Rich,What exactly needs to be done to disbale the 8bitmime keyword on the Exchange 2003 box. The 2003 box has the Internet mail connector and is listed as the send connector on the 2007 box.I'm confused by something. We've always allowed the app servers to connect directly to the Exchange 2003 as a smart host. We've never had any NDRs of this nature. Now, when we add the new receive connector on Exchange 2007 and point the app servers towards this connector as a smart host is when the problem begins. And this is only an issue with the app servers.

On Fri, 18-Dec-09 17:41:03 GMT, AndyD_ wrote:>Yep, but he apparently already did that. He did? I only saw where he said he changed the 2003 server to useHELO.That won't stop the 2003 server from advertising the 8bitmime keywordto the the 2007 server (or any other machine that sends EHLO). Andonce the 2003 server's accepted the message in that format it won'tdeliver it unless the receiving server advertises the 8bitmime keyword-- and it won't because his 2003 server only sends HELO!---Rich Matheisen MVP--- Rich Matheisen MCSE+I, Exchange MVP

Well, I thought you said you already did that on the 2003 connector?Set to send HELO instead of EHLOhttp://support.microsoft.com/kb/265293How to configure the SMTP connector in Exchange 200xhttp://support.microsoft.com/kb/294736When to create SMTP connectors in Exchange 2000 and later If you want to disable EHLO verbs on the 2007 receive connector, use http://technet.microsoft.com/en-us/library/bb125140.aspx Set-ReceiveConnectorI've already posted th elink on how to disable EHLO verbs on the 2003 SMTP Virtual Server:http://support.microsoft.com/kb/257569/How to turn off ESMTP verbs in Exchange 2000 Server and in Exchange Server 2003

The send HELO instead of EHLO was done on the 2003 box on the Internet Mail SMTP Connector (which may be the wrong place). Once I did that all the app servers mail was being returned. I went back and unchecked it and it went back to returning just some of the messages.

Ok, so check the link I posted earlier to disable 2003 advertising EHLO:http://support.microsoft.com/kb/257569/How to turn off ESMTP verbs in Exchange 2000 Server and in Exchange Server 2003It is interesting that this started when you began to relay off of the 2007 server. Why not create a 2007 send connector instead? Why the need to relay to the 2003 server?

On Fri, 18-Dec-09 19:18:26 GMT, akg414s wrote:m begins. And this is only an issue with the app servers. Well, there's lots to assume when dealing with these sorts ofproblems. The 1st assumption is that the 5.6.1 is the result of theE2K7 server sending to the E2K3 server which sends to some otherserver that rejects the message. If that's the situation then see thenext assumption:Assuming you start with the default value, change the value of themsExchSmtpInboundCommandSupportOptions value to 3503297 decimal:7697601(default) - 4194304(8bitmime) = 3503297 (0x3574C1)Now, if that assumption is incorrect, there's the possibility that themessage is rejected by the E2K7 server. That may be caused by the E2K7server paying more attention to the content of the email. For example,if your application sends email with a UUENCODE attachment, it may bethat the encoding is incorrect (e.g. the last line of the encoded datais an apostrophe instead of a back-tick). No matter what you do, shortrong and it should berejected.So, if you can be more specific about which server is rejecting themessage you'd get better assumptions. :-)Assuming (again) that it's the E2K7 server that's sending the 5545.6.1, you can enable "pipeline tracing"(http://technet.microsoft.com/en-us/library/bb125198(EXCHG.80).aspx)on the Hub Transport servers. Wait for a rejection and then go have alook at the trace information on the server.So, go find out which machine it is that's sending the 554 5.6.1 andsee if any of that helps.---Rich MatheisenMCSE+I, Exchange MVP--- Rich Matheisen MCSE+I, Exchange MVP

The first assumption is correct. I will try to make that change.

OK. After making the change, everything is working fine. I don't quite understand why, so if anyone has the time, I love to know the details.Thanks

On Mon, 21-Dec-09 14:50:00 GMT, akg414s wrote:>OK. After making the change, everything is working fine. I don't quite understand why, so if anyone has the time, I love to know the details.Thanks It happens because Exchange 2003 will not try to encode a message into7-bit MIME after it's accepted it in 8-bit MIME format. If the systemto which you're sending the email doesn't advertise the 8bitmimekeyword then Exchange has only two possibilities (per the RFCs):as undeliverable.---Rich MatheisenMCSE+I, Exchange MVP--- Rich Matheisen MCSE+I, Exchange MVP

Thanks Rich.I was seeing a lot of NDRs while advertising 8bitmine from the 2003 box. There must be quite a few systems out there not advertising 8bitmime. What is the standard or best practice for this? Why would you not adverise it?

On Mon, 21-Dec-09 16:52:31 GMT, akg414s wrote:>Thanks Rich.I was seeing a lot of NDRs while advertising 8bitmine from the 2003 box. There must be quite a few systems out there not advertising 8bitmime. There are.>What is the standard or best practice for this? Pretty much what they are for any email -- if you can't deliver it,don't say you can.>Why would you not adverise it? Many systems prefer to deal only with 7-bit format and to reduce theirPkeywords (if you turn on their Mail Guard stuff), even if the systembehind it does!And, along those same lines, why does Exchange 2003 advertise ESMTPkeywords to the world that should be kept within the confines of acompany's LAN? People usually say "oh, it's just email, SMTP can'thurt anything", forgetting that a bad implementation of a feature canbring down your mail system (cutting off your business from theoutside world). For a good example of that, refer to the problemcaused by advertising XEXCH50 a while back. ---Rich MatheisenMCSE+I, Exchange MVP--- Rich Matheisen MCSE+I, Exchange MVP