Jim Flanagan wrote:
Sandy Drobic wrote:
Jim Flanagan wrote:
Sandy Drobic wrote:
Jim Flanagan wrote:
Ulf Rasch wrote:
Jim Flanagan wrote: <snip>
>
: > 24.238.237.18 failed after I sent the message. > Remote host said: 550 Error: improper use of 8-bit data in > message body > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That should be the reason. Have a look at the settings of your MUA (email client).
Ulf
Hi Ulf,
I don't understand what you mean here. I did notice that part you quoted, but I don't know what it means. What bearing would my email client have on a message being bounced by apparently my server? These are not messages I've sent.
That would be typical for a Postfix/Cyrus setup where Cyrus would reject the mail when it is not correctly encoded, let's say, a subjectline with extended characters. Postfix has restrictions that will reject such mails.
strict_8bitmime strict_8bitmime_body
Check your mail log /var/log/mail for the error message and check the output of "postconf -n" for these settings.
Sandy Thanks everyone for the pointers. Yes, the test message did not bounce, but two of the original OP messages did. The same thing happened on some of the spamassassin list mails as well with the same error message.
postconf -n returns... strict_8bitmime = yes strict_rfc821_envelopes = no
No mention of strict_8bitmime_body listed.
I believe this is standard Suse postfix setup, I did not change this setting. I am using Cyrus IMAP, does this have any bearing on this matter?
Could be. You need to find out exactly which application has rejected the mail. Check your logs. Postfix logs to /var/log/mail as default, Cyrus to /var/log/messages.
Cyrus can also reject messages:
reject8bit: 0 If enabled, lmtpd rejects messages with 8-bit charac- ters in the headers. Otherwise, 8-bit characters are changed to 'X'. (A proper solution to non-ASCII characters in headers is offered by RFC 2047 and its predecessors.)
Do you use amavisd-new perhaps? That one could probably also reject mails in such a way. Without the log message that will tell exactly what application caused the rejection it is a bit difficult.
Will changing strict_8bitmime = no in /etc/postfix/main.cf (and postfix reload) likely fix this problem? Any repercussions with Cyrus?
I recommend to set "reject8bit: no" in /etc/imapd.conf. Though that still is no explanation for the rejection with the bad mail body mime encoding. That would only resolve bad header lines.
Also, if you have time, what is the purpose of making this setting to yes? I take it that it prevents malformed email of some sort. But what is the drawback to not having this check set to strict? What are the known sloppy email clients (er, Outlook Express??!!).
The sloppiest ones are probably web applications where sometimes some parts of created mails are not correctly encoded.
OK, I've made no changes to my config files so far. Searching logs I found the following in /var/log/mail...
------------ Apr 15 15:20:51 cammee postfix/smtpd[27154]: connect from lists.suse.de[195.135.221.131] Apr 15 15:20:51 cammee postfix/smtpd[27154]: A481F2FF14: client=lists.suse.de[195.135.221.131] Apr 15 15:20:51 cammee postfix/cleanup[27161]: A481F2FF14: message-id=
Apr 15 15:20:51 cammee postfix/cleanup[27161]: A481F2FF14: reject: mime-error improper use of 8-bit data in message body: ?In the last two years I have seen it go from, ?well let?s look at what from lists.suse.de[195.135.221.131];
Yes, that's the one we needed to find. I just looked up the restriction: ------------------------------------------------------- strict_8bitmime (default: no) Enable both strict_7bit_headers and strict_8bitmime_body. This feature should not be enabled on a general purpose mail server, because it is likely to reject legitimate email. This feature is available in Postfix 2.0 and later. strict_8bitmime_body (default: no) Reject 8-bit message body text without 8-bit MIME content encoding information. This blocks mail from poorly written applications. ------------------------------------------------------- So, now we know, why the mail was rejected. I suggest to remove the parameter from your setup. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com