-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-05-04 at 09:17 -0500, Jim Flanagan wrote:

...

...

: 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).

Certainly not the MUA, but the whole server setup.

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.

No, you did not sent it. When ezmlm finds a problem sending to you (bounces) it sends a probe, a test email. It is this test email, I think, which failed. Search your logs. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEWhkEtTMYHG2NR9URAi9hAJ48WB1LSimplZQcm4J6ew8APBuDmQCdG5R/ /2V5/LjjMWBr9aPEwj6VuD0= =0Th2 -----END PGP SIGNATURE-----

On Thu, 4 May 2006, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Thursday 2006-05-04 at 09:17 -0500, Jim Flanagan wrote:

...

...

...

: 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).

Certainly not the MUA, but the whole server setup.

...

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.

No, you did not sent it. When ezmlm finds a problem sending to you (bounces) it sends a probe, a test email. It is this test email, I think, which failed.

Search your logs.

You will need to go back to 10-11 days before you received the EZMLM warning. EZMLM sends that message out 10 days after the event. If you want a good laugh, read the message in the context that it is telling what it will do if the message bounces, bearing in mind the first bounce started 10 days ago. -- Regards, | Lions District 201 Q3 Rob Unsworth | IT & Internet Chairman Ipswich, Australia | http://www.lionsq3.asn.au -------------------------------------------------

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Thursday 2006-05-04 at 09:17 -0500, Jim Flanagan wrote:

...

...

...

: 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).

Certainly not the MUA, but the whole server setup.

...

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.

No, you did not sent it. When ezmlm finds a problem sending to you (bounces) it sends a probe, a test email. It is this test email, I think, which failed.

I think it was the two messages 267899 and 268109 that failed. I don't think ezmlm ever got as far as sending a probe, because the warning Jim is asking about was delivered successfully. In the extract above 'I' refers to Suse's server and 'Remote host' refers to the server belonging to Jim (or his ISP). Specifically, it says that Jim's server objected to the content of message 267899 ('the first bounce message' mentioned in Jim's original message) which was from Kai Ponte on 15 April at 21:20 AFAICT. Ulf Rasch wrote:

It means that the message was rejected because the body text contained 8-bit text without the 8-bit MIME content encoding information. Nevertheless it is not recommended to has that option enabled on a general purpose mail server as it might block legitimate mail.

I think you're probably right here. I suspect Jim's server objected to some character in Kai's message and I think you're right that having a server configured to be so strict about what it accepts is probably asking for trouble.

If you didn't send this email in the first place then I guess someone is spamming with your email address.

I don't think there's any question of spamming, though. There's no suggestion anywhere that any of these messages are forged or have questionable content that I can see. Cheers, Dave

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 -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com

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. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com

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]; from= to= Apr 15 15:20:52 cammee postfix/smtpd[27154]: disconnect from lists.suse.de[195.135.221.131] ----------- I don't understand fully what this means, other than a curory understanding. To me it seems postfix rejected this message. There is not corresponding entry in /var/log/messages for this same date/time, unless that log uses UTC or another time zone. I do use amavisd-new, with clamav and freshclam. That puts many many messages in /var/spool/amavis/virusmail dir. I've since deleted them all for that time frame. Not sure why they are going in there, except that every one I've manually checked so far has a .gif file attached to it. I'm using spamassassin and cyrus sieve to filter the ones that don't get put in virusmail dir. Not sure what else you would need to see. Will be happy to supply more log info if you need it.

Sandy Drobic wrote:

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

OK Sandy, many many thanks for the good help. I've made that change to strict_8bitmime, and done nothing regarding srict_8bitmimie_body as it is not in the main.cf anyway. I guess I may get another ezmlm warning or two, from what happend 10 or so days ago, but that's not big deal, since this should allow current messages to pass thru. If I get any past this weekend I'll let you know, but I don't expect to. Again, many thanks, Jim F