Re: [exim] Problem - SMTP connector in Exchange 2003 sending…

Top Page
Delete this message
Reply to this message
Author: Richard.Hall
Date:  
To: oll
CC: exim-users
Subject: Re: [exim] Problem - SMTP connector in Exchange 2003 sending mail toExim 4.43
Oll,

On Fri, 8 Apr 2005, oll wrote:

> Hi,
>
> Just subscribed to this list to see if any of you guys have ever
> experienced this problem before?


Been there, done that, haven't even had time to get the photos printed on
the t-shirt yet ...

> We have an SMTP connector in our Exchange 2003 org that will route out
> mail that it does not find a recipient for for a certain domain. Let's
> call it domain.com


My problem was with an Exchange 2000 system, but I believe it's the same.

> So if no one in our Active Directory has the email address
> someone@??? it will route that mail out via this connector
> directly to an Exim mail server. It is running Exim 4.43 (that's what
> it says when I telnet to it).
>
>
> Not all mail is getting to it, that is the problem.
>
> Some mails are returned stating:
>
> Action: failed
> Status: 5.6.1
> Diagnostic-Code: smtp;554 5.6.1 Body type not supported by Remote Host


Yup, that's the one.

> This only tends to happen when a mail is forwarded through the
> connector when recieved by Exchange from certain web mail clients or
> programs.
>
>
> I've got a feeling this is a 7BIT/8BIT MIME problem


Your diagnosis is spot on, I think.

> so what I did on
> the SMTP connector was disable ESMTP (effectively saying HELO instead
> of EHLO) in the hope it would fix it and convert the mail correctly so
> that the Exim 4.43 mail server could recieve the mail.


No, you are tackling the problem too late :-(

> However it still isn't..
>
> Again this is only happening with certain mails. It all depends what
> format the message is recieved by Exchange it appears.
>
>
> Anyone ever had this before? Is this a shortfall with Exchange or Exim
> 4.43? Can it be fixed?


Yes. The former (IMHO). Yes.

This is (more or less) what I wrote at the time:-

> Googling around for "Body type not supported by Remote Host" fairly
> quickly leads to Microsoft KB 257569 at
>
>     http://support.microsoft.com/kb/257569

>
> entitled "How to turn off ESMTP verbs in Exchange 2000 Server and in
> Exchange Server 2003"
>
> My understanding of what is happening is
>
> - remote sender connects to Exchange and sends EHLO
> - Exchange responds, advertising various ESMTP extensions, and in
> particular 8BITMIME
> - the remote sender (probably another Exchange server) sends an 8-bit-mime
> message to Exchange (The example I have is in German, with typical
> German-accented 8-bit characters)
> - Exchange connects to Exim and sends EHLO
> - Exim responds but does _not_ advertise 8BITMIME. (It does not support it
> by default, and with good reason, as we are about to see)
> - Exchange is _supposed_ to convert the 8-bit message into a suitable 7-bit
> format. (I believe this is more than just a case of encoding 8-bit in
> 7-bit, though I am very hazy on the details, and have not yet had time
> to research it further.) However, it is unable to do so, so simply
> bounces the message back to the sender.
>
> KB 262128 has a little more info on the subject. Also the following from
> the Exim spec. may be useful:-
>
>                             ----- -----
> Option: accept_8bitmime
> Use:  main
> Type:  boolean
> Default:  false

>
> This option causes Exim to send 8BITMIME in its response to an SMTP EHLO
> command, and to accept the BODY= parameter on MAIL commands. However,
> though Exim is 8-bit clean, it is not a protocol converter, and it takes
> no steps to do anything special with messages received by this route.
> Consequently, this option is turned off by default.
>                             ----- -----

>
> Clearly Exchange is also not capable of acting as a protocol converter;
> yet it does advertise 8BITMIME by default.


To summarise

- once Exchange has accepted an 8BITMIME message, it is unable to pass it
on to a (standard) Exim server.

- so you have to prevent Exchange accepting it in the first place

- which you do by preventing it advertising 8BITMIME in response to an
EHLO from the remote sender.

Caveat 1: this was so recent that I haven't yet had confirmation from the
affected user that it actually works.

Caveat 2: you are simply pushing the problem one step further back up the
pipeline; if the original sender cannot send a non-8bitmime message in the
first place, you are stymied.

Caveat 3: Exchange also seems to advertise BINARYMIME; it may be that you
need to disable that as well.

HTH,
Richard