Description: ------------ when creating a message with a given charset, the content-type header appears like Content-Type: text/plain; charset=utf-8 (notice the newline). for some of our clients this creates problems, because the email-client will stop parsing headers, and thus the body will start with the charset definition. removing the $eol from $headers['Content-Type'] .= ";$eol charset=" . $this->_build_params['text_charset']; in strategic places in both mime.php and mimePart.php fixes this. looking at rfc 2045 i see : content := "Content-Type" ":" type "/" subtype *(";" parameter) ; Matching of media type and subtype ; is ALWAYS case-insensitive. for the syntax of the Content-Type: header. as near as i can figure this does not suggest a newline character, at least not after the semicolon.

What software has problem with this? Partially you're right. But you should read about folding in RFC5322. Also folding is used in all examples of RFC2231.

thanks for the pointers, it seems the format is indeed correct.. i can't reproduce the error myself, but i've gotten reports from multiple sources, all of whom said 'outlook' (which we don't use), allthough i've not heard a version. i'm asking one of the last people to report this to give me some more information. i'll report back asap.

for completeness, this is the main part of a mail that causes the problem : From www-data@desk.nl Wed Jul 7 12: 6:02 2010 Return-Path: <www-data@desk.nl> To: peter@desk.nl Subject: INK : Uw bestelling bij INK.nl MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Sent-From: ink.nl From: info@ink.nl Reply-To: info@ink.nl Message-Id: <20100707104517.4E746678007@yucan.desk.nl> Date: Wed, 7 Jul 2010 12:45:17 +0200 (CEST) X-UIDL: jPA!!$N6"!4R#"!%!/!! Status: RO Content-Length: 1189 Lines: 83

I've added a code to place charset parameter in first line of Content-Type header, if possible (the line is short). Now, I think we can close this requests as it's not Mail_Mime issue.