Sandy Drobic wrote:
Joe Morris (NTM) wrote:
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.
But didn't the message have to be converted to 8 bit to be rejected by those domains we had trouble sending to , and whose servers do not advertise 8bitmime? I guess I was assuming they had to be since they were bounced. And they now work with 8bitmime keyword discarded. So am I wrong that, since the client says the message was 7 bit (Thunderbird), i.e. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit and it now goes through with only the change to what Postfix sees in the response codes from Exchange, that they had to be being converted to 8 bit somewhere. I do also run amavisd-new with virus and spam checking, so all the messages do also go through there. If Postfix doesn't convert 7 bit to 8 bit, how do they now work? I checked amavisd-new, and it also advertises 8bitmime. If it started off as a 7 bit encoded message, and it went through Postfix 2x and amavisd-new once, and discarding 8bitmime AFAIU should make Postfix convert the message to 7 bit, where could it have become an 8 bit message?
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.
I checked and I don't have that module installed. pin doesn't even list that module. But that got me to wondering if amavisd-new could be converting it. I had totally forgot about that one.
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.
Well, I am encouraged by the fact I actually understood most of that, and understand exactly what you did. I am learning. Your help as always has been much appreciated. -- Joe Morris Registered Linux user 231871 running openSUSE 10.2 x86_64 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org