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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
