554 5.6.1 Body type not supported by Remote Host
EmailAdmin
format with a short message and sends it to external mail domains.
Originally, the e-mail was being delivered using a Domino SMTP relay server
which was working fine. A week ago we started using an Exchange 2003 SMTP
Relay server which forwards all outbound e-mails to our external ISA SMTP
server and now we are receiving NDR similar to the following for specific
e-mail domains...
The message contains a content type that is not supported
<server #5.6.1 smtp;554 5.6.1 Body type not supported by Remote Host>"
For one of the recipient domains we are experiencing the problem with, they
are using Symantec Mail Security for SMTP which forwards to their Exchange
2003 environment.
We did a few tests to try to figure out the problem. I was able to
successfully sent the e-mails from Outlook via the "Resend" option in the
NDR. We modified the application to send the e-mail using 7bit encoding and
it failed providing another NDR. This is what is in the logs on the ISA
server...
2006-05-30 20:01:56 xxx.xxx.xxx.xxx OutboundConnectionCommand SMTPSVC1
ourserver - 25 EHLO - tais-mlr-p02.tais.net 0 0 4 0 47 SMTP - - - -
2006-05-30 20:01:56 xxx.xxx.xxx.xxx OutboundConnectionResponse SMTPSVC1
ourserver - 25 - - 250+proxy.toshiba.com.mx+Hello 0 0 30 0 94 SMTP - - - -
2006-05-30 20:01:56 xxx.xxx.xxx.xxx OutboundConnectionCommand SMTPSVC1
ourserver - 25 QUIT - - 0 0 4 0 94 SMTP - - - -
It seems like the problem is the 8bit mime format and I've seen references
to the "How to turn off 8BITMIME in Windows 2000 and in Windows Server 2003
SMTP service - 262168" but I wasn't sure if this would resolve this issue.
Does anyone have an idea on how to resolve this issue?
By the way, our Domino server had 8bitmime disabled. With our new Exchange
environment, we have MIME set to Both and format is set to
Untranslated("ANSI").
Thanks in advance for any help provided.
AL
Andy David - MVP
You can create a SMTP connector for those domains you are having
problems sending mail to and check the "send HELO instead of EHLO" box
under the advanced tab of the connector and test.
EmailAdmin
Thanks for responding. Based on your recommendation, I'm guessing all I
have to do is use HELO rather EHLO to rid myself of this problem...is this
correct? My Exchange servers do not communicate with any external domains
except through my ISA (IIS SMTP enabled) server on the DMZ...I'm thinking I
can create a domain entry in IIS to use HELO. Does this sound right? Thanks
EmailAdmin
Update, I went ahead and created the domain document on the ISA IIS SMTP
server and I get the same error message except it says HELO. Any other ideas?
Rich Matheisen [MVP]
>We have an application that generates e-mail that contains a report in PDF
>format with a short message and sends it to external mail domains.
>Originally, the e-mail was being delivered using a Domino SMTP relay server
>which was working fine. A week ago we started using an Exchange 2003 SMTP
>Relay server which forwards all outbound e-mails to our external ISA SMTP
>server and now we are receiving NDR similar to the following for specific
>e-mail domains...
>
>The message contains a content type that is not supported
><server #5.6.1 smtp;554 5.6.1 Body type not supported by Remote Host>"
Your Exchange server advertises the "8bitmime" keyword -- turn it off.
How to turn off ESMTP verbs in Exchange 2000 Server and in Exchange
Server 2003 [257569]
Exchange accepts the message in 8-bit MIME format, but your ISP
doesn't use ESMTP or doesn't advertise the 8bitmime keyword. When
Exchange encounters this situation it creates the NDR instead of
converting the message to 7-bit MIME format.
If you don't accept messages in that format the sending application
won;t deliver them that way. Then, when you encounter a host that
can't handle 8bitmime it won't matter.
--
Rich Matheisen
MCSE+I, Exchange MVP
MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
Don't send mail to this address mailto:h.p...@getronics.com
Or to these, either: mailto:h.p...@pinkroccade.com mailto:melvin.mcp...@getronics.com mailto:melvin.mcp...@pinkroccade.com
EmailAdmin
Just to clarify, I don't have an ISP but my Exchange servers route outbound
e-mails to my W2K3 ISA Server with IIS SMTP enabled on the DMZ. Questions...
Is it better to turn off the 8bitmime on the W2K3 ISA server or the one
Exchange server that is doing the SMTP relay for my non-Exchange applications
(e.g., apps on UNIX server)?
Or if I have to change Exchange, do I have to turn off 8bitmime on all the
Exchange servers?
When you say that following (see below), if I turn off the 8bitmime on
either the Exchange SMTP server or the W2K3 ISA server, what happens to the
8bitmime e-mail that is sent from the application? Does it fail to deliver
or does it get converted? I guess what I'm asking is what happens when an
8bitmime e-mail hits a server that doesn't advertise 8bitmime?
"If you don't accept messages in that format the sending application
won;t deliver them that way. Then, when you encounter a host that
can't handle 8bitmime it won't matter."
One other thing, our developer changed the UNIX program to send it as 7bit,
but it didn't go thru to the recipient. Any ideas why?
------Boundary.20050106102315
Content-Type: text/plain; name="message.txt"; charset=US-ASCII
Content-Disposition: inline; filename="message.txt"
Content-Transfer-Encoding: 7bit
------Boundary.20050106102315
Content-Type: application/pdf; name="BillTo50131000.pdf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="BillTo50131000.pdf"
------Boundary.20050106102315
Thank you for your help.
Going crazy...
AL
Rich Matheisen [MVP]
>Just to clarify, I don't have an ISP but my Exchange servers route outbound
>e-mails to my W2K3 ISA Server with IIS SMTP enabled on the DMZ. Questions...
>
>Is it better to turn off the 8bitmime on the W2K3 ISA server or the one
>Exchange server that is doing the SMTP relay for my non-Exchange applications
>(e.g., apps on UNIX server)?
Turn it off on the Exchange servers. The ISA server shouldn't be
acting as a SMTP server, just a proxy.
>Or if I have to change Exchange, do I have to turn off 8bitmime on all the
>Exchange servers?
No, but it's usually better, for a consistency POV, to do so.
>When you say that following (see below), if I turn off the 8bitmime on
>either the Exchange SMTP server or the W2K3 ISA server, what happens to the
>8bitmime e-mail that is sent from the application?
Nothing. Your SMTP servers don't advertise 8bitmime so the sending
application shouldn't be sending messages in that format. That's the
purpose of advertising the capabilities in ESMTP keywords.
>Does it fail to deliver
>or does it get converted?
Neither should happen. The message should be sent in 7-bit MIME
format.
>I guess what I'm asking is what happens when an
>8bitmime e-mail hits a server that doesn't advertise 8bitmime?
You get the 5.6.1 error that you were asking about. :)
>"If you don't accept messages in that format the sending application
>won;t deliver them that way. Then, when you encounter a host that
>can't handle 8bitmime it won't matter."
>
>One other thing, our developer changed the UNIX program to send it as 7bit,
>but it didn't go thru to the recipient. Any ideas why?
What would happen if the SMTP relay server (Exchange, in this case,
but feel free to substitute sendmail, postfix, qmail, etc. as the MTA)
only accepted SMTP and not ESMTP? How would the message be sent in
that situation?
>------Boundary.20050106102315
>Content-Type: text/plain; name="message.txt"; charset=US-ASCII
>Content-Disposition: inline; filename="message.txt"
>Content-Transfer-Encoding: 7bit
Well, changing the encoding to 7bit without ensuring that the data
contains only 7-bit data won't work. :)
If you have a need to send 8-bit data then play it safe and use base64
encoding.
>------Boundary.20050106102315
>Content-Type: application/pdf; name="BillTo50131000.pdf"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment; filename="BillTo50131000.pdf"
>
>------Boundary.20050106102315
I doubt that a PDF file contains only 7-bit data.
EmailAdmin
ASCII Base64, rather than manually formatting the e-mail information.