I have an odd situation where some external meeting requests are being rejected. Exchange 2007 Sp1 and Outlook 2007 SP2 (2 situations below):External UserA sends a meeting request to Internal UserB.Internal UserB accepts meeting request and sends without adding a response.Internal UserB gets a #5.6.1 smtp;554 5.6.1 Body type not supported by Remote Host rejection notice.External UserA sends a meeting request to Internal UserB.Internal UserB accepts meeting request and chooses to add a note to the response before sending.Internal UserB sends the acceptance w/ note attached and it goes through to External UserA without any problems.When I look at message tracking in ExchangeI normally see the following EventId's:Submit STOREDRIVReceiveSTOREDRIVTransfer ROUTINGSend SMTPIn the instance of when I get a rejection it only has:Submit STOREDRIVReceiveSTOREDRIVAny ideas?

What version of Update roll-up you are? is this happens to only one particular user? I would ask you to check the Outlook settings on that machine? check for any delegate permission also check for the outlook rules. compare the Get-mailboxcalendarsettings of user in question with working user. Vinod |CCNA|MCSE 2003 +Messaging|MCTS|ITIL V3|

Rollup update 8 for SP1 is what I'm on.It is happening for all users on all machines, so that would rule out any delegate permissions our outlook rules.

Do you have any kind of Smart relay between Internet and Hub Server?Vinod |CCNA|MCSE 2003 +Messaging|MCTS|ITIL V3|

I've got a server in the DMZ with GFI MailSecurity 10 on it acting as a smarthost. GFI keeps telling me that I need to disable the 8bit MIME advertisements. I've done all of that with no luck.

I have an odd situation where some external meeting requests are being rejected. Exchange 2007 Sp1 and Outlook 2007 SP2 (2 situations below):Scenario 1:External UserA sends a meeting request to Internal UserB.Internal UserB accepts meeting request and sends without adding comments in the response.Internal UserB gets a #5.6.1 smtp;554 5.6.1 Body type not supported by Remote Host rejection notice.Scenario 2:External UserA sends a meeting request to Internal UserB.Internal UserB accepts meeting request and chooses to add acomment to the response before sending.Internal UserB sends the acceptance w/comments attached and it goes through to External UserA without any problems.When I look at message tracking in ExchangeI normally see the following EventId's:Receive @ the STOREDRIVTransfer for RoutingSend on Outbound SMTP ConnectorIn the instance where the meeting acceptance is being rejected all I see is that it is received @ the STOREDRIV only, no Transfer for Routing or Sending to the Outbound connector.Any thoughts?

What rollup are you on? You may also want to apply SP2 and test. Does this only affect one user? Or can you reproduce this on every meeting request for different internal users and different external users that are forwarded?

Hi Steve, Would you please help me gather following information? 1. The message header of NDR message 2. Entire NDR message 3. The SMTP log on the Send Connector (You need to enable logging on the Send Connector and reproduce the issue) Mike Shen TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com

I am on rollup 8 for sp1 for Exchange. Thing is, if I apply SP2 on my test network I don't really have a way to test the situation as it is not connected to the real world.The problem exists for all users and can be replicated across the board. Weird thing is...if an internal user or myself accepts a meeting request from an external user and I add a response before sending....it goes through and is delivered......sort of like there is some sort of formatting issue.

1. Message header of NDR:Received: from smarthost.gateway.mycompany.us () byemail.server.mycompany.us (172.x.x.x) with Microsoft SMTP Server id8.1.375.2; Fri, 28 Aug 2009 15:12:38 -0700From: <postmaster@smarthost.gateway.mycompany.us>To: userB@mycompany.usDate: Fri, 28 Aug 2009 15:10:34 -0700MIME-Version: 1.0Content-Type: multipart/report; report-type=delivery-status;boundary="9B095B5ADSN=_01CA24870E0B36A200000321smarthost.gateway.mycompany.us"X-DSNContext: 7ce717b1 - 1196 - 00000002 - 00000000Message-ID: <T18j7nqqK000000ef@smarthost.gateway.mycompany.us>Subject: Delivery Status Notification (Failure)Return-Path: <>X-GFI-SMTP-Submission: 1X-GFI-SMTP-HelloDomain: smarthost.gateway.mycompany.usX-GFI-SMTP-RemoteIP: 208.x.x.xX-MS-Exchange-Organization-SCL: 92: Entire NDRDelivery has failed to these recipients or distribution lists: userA@external.netThe e-mail system had a problem processing this message. Microsoft Exchange will not try to redeliver this message for you. Please provide the following diagnostic text to your system administrator. Diagnostic information for administrators: Generating server: smarthost.gateway.mycompany.us userA@external.net#< #5.6.1 smtp;554 5.6.1 Body type not supported by Remote Host> #SMTP# Original message headers: Received: from email.server.mycompany.us ([172.x.x.x]) bysmarthost.gateway.mycompany.us with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Aug2009 15:10:33 -0700x-gfi-me-message-id: <7D981CFC2562168800000060@REX>MIME-Version: 1.0Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: 7bitX-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325From: <UserB@mycompany.us>BCC:Return-Path: UserB@mycompany.usMessage-ID: <smarthostFaukyCKDkb9pPF0002174a@smarthost.gateway.mycompany.us>X-OriginalArrivalTime: 28 Aug 2009 22:10:33.0718 (UTC) FILETIME=[5CFC2160:01CA282C]Date: Fri, 28 Aug 2009 15:10:33 -0700 3.I'll need to turn on the logging and post this later.

Can you post the exact error from the message tracking log when it fails?

Hi Steve, Thanks for your response. From your information, I notice that the NDR message is generated by the smarthost.gateway.mycompany.us server. I assume that the server smarthost.gateway.mycompany.us is your smarthost server (GFI MailSecurity 10). The email.server.mycompany.us is your Exchange Server. If I am off-base, please let me know. Based on my research, the issue mostly occurs related to message format and remote SMTP server. For example, the message has Content-Transfer-Encoding value of Binary. Messages that have Content-Transfer-Encoding value of Binary can only be transferred between SMTP messaging servers that support and advertise the BINARYMIME and CHUNKING SMTP extensions as defined in RFC 3030. If the remote mail sever does not provide the BINARYMIME, the sender server may generate the error Body type not supported by Remote Host. Therefore, please let me know whether I understand the outbound mail flow correctly. email.server.mycompany.us (Exchange 2007)-> smarthost.gateway.mycompany.us (GFI MailSecurity)->External Mail Servers Please also let me know whether the issue occurs on all external domains or only when accept meeting request from specific external domain. In addition, I suggest you reproduce the issue: 1. Accepts meeting request and sends without adding a response 2. Accepts meeting request and chooses to add a note to the response before sending Then, please capture the two messages on the smarthost.gateway.mycompany.us to compare message format (eml). You can also open the eml file by notepad and post the messages here. Mike Shen TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com

Your assumption is correct. THe smarthost.gateway.mycompany.us is GFI MaiSecurity 10 and my exchange server is Exchange 2007. The mailflow assumption is correct as well.The issue does occur with every external domain and can be reproduced.Two questions....How do I go about capturing the messages on the gateway, and how do Igo about changing the BINARYMIME and CHUNKING SMTP extensions?It sounds like we're on the right track.

On Wed, 2-Sep-09 21:42:23 GMT, Andy David wrote:>Can you post the exact error from the message tracking log when it fails? I've seen VCALENDAR data rejected when the sender includes stuffthat's not in the RFC. I /think/ it's rejected with that 5.6.1extended status code.Of course I don't know if that's the problem. You have to enablecontent conversion logging before you get to see exactly what itdoesn't like if it's your server that's rejecting the email.---Rich MatheisenMCSE+I, Exchange MVP--- Rich Matheisen MCSE+I, Exchange MVP

Hi Rich,I am having the same issue with Vcalendara rejected by exchange server 2007. We are using Net.Mime.TransferEncoding.SevenBit in the header, and i think it is not converted to 7 bit and this is causing the problem. Do you know how to get past that?Thanks.Shakira NayeemComputool Corp.NY

HelloI am currently working on a similar issue, we found out that the following line is in the header of the email before it gets to Exchange 2007. Basically we used PipeLineTracing to get this information, we opened the eml fileand it has the following info.----boundary_79_8a506158-fe63-452e-932e-53ccd7a5b901Content-Type: text/calendar; method=REQUEST; name="meeting.ics"Content-Transfer-Encoding: sevenbitIf I change the "sevenbit" to "7bit", and replay the eml file in the pickup folder, the email goes through fine in exchange 2007.I have not yet verified if the sender actually is sending the email like this. We will see about that.Use Pipeline tracing on Exchange 2007 and get a copy of the email, open the original.eml file and see if yoeu see the same thing.To Use pipeline tracing, see following linkhttp://technet.microsoft.com/en-us/library/bb125018.aspxNima

On Thu, 8-Oct-09 19:35:30 GMT, Nima2010 wrote:>I am currently working on a similar issue, we found out that the following line is in the header of the email before >it gets to Exchange 2007. Basically we used PipeLineTracing to get this information, we opened the eml file>and it has the following info.>>----boundary_79_8a506158-fe63-452e-932e-53ccd7a5b901>Content-Type: text/calendar; method=REQUEST; name="meeting.ics">Content-Transfer-Encoding: sevenbit>ile in the pickup folder, the email goes through fine in exchange 2007.Indeed! "sevenbit" is not correct ("x-sevenbit" might work, though). From RFC2045:6.1. Content-Transfer-Encoding Syntax The Content-Transfer-Encoding field's value is a single token specifying the type of encoding, as enumerated below. Formally: encoding := "Content-Transfer-Encoding" ":" mechanism mechanism := "7bit" / "8bit" / "binary" / "quoted-printable" / "base64" / ietf-token / x-token These values are not case sensitive -- Base64 and BASE64 and bAsE64 are all equivalent. An encoding type of 7BIT requires that the body is already in a 7bit mail-ready representation. This is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the Content-Transfer-Encoding header field is not present.---Rich MatheisenMCSE+I, Exchange MVP--- Rich Matheisen MCSE+I, Exchange MVP

Do you know what kind of overhead/processing the Pipeline tracing might add to the server? I've got a pretty beefy machine, but you never know!?!

Not much, because you have to specify a particular email address that we will be tracing. so we are only capturing the email into NTFS from thatsender only.More update on this issue with "Sevenbit" ... this turned out to be a bug in .netframework libraries 2.x and 3.x and is not fixed yet.So for now we are trying to see if we can provide a workaround for the developer of the app.

Easy enought. I captured a couple messages and it produces the original.eml and about 7 other .emls. I looked in them all and they were all blank. Where do I look/what do I need to do to view the following info?----boundary_79_8a506158-fe63-452e-932e-53ccd7a5b901Content-Type: text/calendar; method=REQUEST; name="meeting.ics"Content-Transfer-Encoding: sevenbit

are you opening them in notepad? you should. search for seven in notepad once you open them

I just opened them in notepad and the encoding mechanism states that it is in binary. This is odd.Content-Type: application/ms-tnef; name="winmail.dat"Content-Transfer-Encoding: binary

On Fri, 9-Oct-09 22:59:47 GMT, Ex2K7Steve wrote:>I just opened them in notepad and the encoding mechanism states that it is in binary. This is odd.>>Content-Type: application/ms-tnef; name="winmail.dat">Content-Transfer-Encoding: binary For what reason were they failing? Messages are passed through contentconversion and there can be many reasons for that to fail.---Rich MatheisenMCSE+I, Exchange MVP--- Rich Matheisen MCSE+I, Exchange MVP

For those of you who are Exchange Administrators and have used Pipeline Tracing and confirmed that the Content-Transfer-Encoding is really set to Sevenbit, you need to contact the author of the application thatgenerates the email. They will need to work around this issue using free sample codes available like followinghttp://www.codeproject.com/KB/IP/MailMergeLib.aspxOr at least the above sample code can give them an idea on how to work around this. For the developerswho don't want to apply the workaround, they can simply not set this line in the email header at all. Becausethe default is 7bit anyways. So if your email does not even have this line, then Exchange will assume 7bit.You can try to completely remove the following line in your EML file captured by the trace, change the message IDby one number and replay the EML file in Pickup folder, you will see that Exchnage accepts the email fine.Content-Transfer-Encoding: SevenbitNima

I installed Rollup 9 for Service Pack 1 this morning and now the meeting requests are send without being rejected, but now when the recipient gets that acceptance it is just a blank email. Weird.