Joe Morris (NTM) wrote:
I just ran into a problem, for which I have found a workaround, but am wondering if anyone (you know who you are Sandy :-) ) can shed some additional light to actually fix the problem. The scenario is I am now relaying through the Exchange server at our HQ (their choice). There are some domains that are being rejected because of Body Type not supported by Remote Host. The problem seems to be because Exchange advertises 8bitmime (the fix I implemented was to discard the 8bitmime ehlo keyword from their smtp server). Evidently, the domains we are having problems with do not support 8bitmime. My understanding is when Postfix sees the Exchange server does support it, it converts the message, reported as 7 bit in the email client, to 8 bit based on the 8bitmime response code of Exchange. When Exchange relays the message, and finds the destination smtp server does not support 8bitmime, it bounces it back.
The correct solution would be for Exchange to convert the message from 8bit to 7bit, if the destination system does not announce support for 8bit. In any case, your solution is the only possible one for your situation, when you can neither reconfigure the Exchange server nor the destination server.
Since the message was 7 bit to start with, and telling Postfix to discard the 8bitmime ehlo response allows it to work, which is the problem? Should Postfix convert the message to 8bit? Is that the proper response to the 8bitmime ehlo response? Is the problem Exchanges non conversion to 7bit when the destination server does not support 8bitmime? IOW, they could configure Exchange to not advertise 8bitmime
Postfix does not convert any 7bitmime to 8bitmime, it merely converts 8bitmime to 7bitmime, if the destination server does not support 8bitmime. Though there was a bug recently in a perl module that amavisd-new uses (Net::Cmd 2.2.7), which caused ALL mail to be converted to UTF8 regardless of the encoding of the headers. It caused a lot of screams here in Germany because the problem immediately became apparent with the German "Umlaute" äüö etc.
and it would work. Telling Postfix to discard the response from their server also works, but it is in the smtp compatibility section of the Postfix docs, which lead me to believe it was added to allow Postfix to work in the presence of a broken smtp server. My fix is a workaround, which if the problem is in Exchange, will only mask the real problem. As a matter of interest, one of the domains we are having problems with, apparently because of a lack of 8bitmime support, is aol.com.
Your problem is, that you can only influence message handling on your outgoing server, so you have to choose the most compatible setting directly at the beginning of the transport chain. The exchange server doesn't seem to have problems with 8bit, but apparently can't convert the message when the remote server does not announce 8bit. So the mesage is bounced. Not very nice, but you do not lose the mail, at least. I had a similar problem last weekend when I set up my server to use amavisd-new as a smtp-proxy filter. For whatever reason the cyrus-users listserver is adding a "auth=<>" to the "mail from" command, which is no problem for Postfix but causes amavisd-new to (wrongly) reject the message. Postfix announces support for auth, and hands the connection over to amavisd-new, which does not seem to support auth correctly (smtp auth connections work, but not the auth extension in the "mail from" command. The only solution I found was to suppress the auth announcement in the ehlo response when the cyrus-users listserver connects. My post on the amavis list didn't get any replies, so for the moment it is the only solution. -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org