I use the following function instead of imap_8bit when using PHP without the IMAP module, which is based on code found in http://www.php.net/quoted_printable_decode,and giving (supposedly) exactly the same results as imap_8bit,(tested on thousands of random strings containing lotsof spaces, tabs, crlf, lfcr, lf, cr and so on,no counterexample found SO FAR:)

AND you can force a trailing space to be encoded,as opposed to what imap_8bit does,which I consider is a violation of RFC2045,(see http://bugs.php.net/bug.php?id=35290) by commenting that one central line.

// !!!!!!!! // imap_8_bit does not encode x20 at the very end of a text, // here is, where I don't agree with imap_8_bit, // please correct me, if I'm wrong, // or comment next line for RFC2045 conformance, if you likeif (!($bEmulate_imap_8bit && ($i==count($aLines)-1)))

// finally split into softlines no longer than 76 chars, // for even more safeness one could encode x09,x20 // at the very first character of the line // and after soft linebreaks, as well, // but this wouldn't be caught by such an easy RegExp preg_match_all( '/.{1,73}([^=]{0,2})?/', $sLine, $aMatch );$sLine = implode( '=' . chr(13).chr(10), $aMatch[0] ); // add soft crlf's}

Code based on k dot kozlowski at enter dot pl but for UTF-8(the only problem i encounter is SUBJECT_ENCODED_TWICE on SPAM test with very long subject, but the same produce others MUA's)<?function header_quoted_printable_encode($string, $encoding='UTF-8') {

There is a bug in MS Exchange server, that improperly handles CRLFs. Seems like it converts both CR and LF into LF, so, instead of getting just a new line, you get TWO new lines.The header information is then improperly parsed by the e-mail client, and is usually viewed in the message body.

This can make custom-created headers unusable.

The only way I found to get around this is to go against RFC rules for header formatting, and use only \n for new lines.

Unfortunately I haven't been able to learn the version of Exchange server where this happened, but I have the feeling that it's not just the one I was unlucky to encounter.

This function appears to wrap lines in the middle of words, not just at whitespace, which upsets some versions of Outlook Express when used to format email body text. We've had more luck with this function:

By splitting lines up after 75 characters, the function's behaviour is complying to RFC2047 (http://www.ietf.org/rfc/rfc2047.txt) (which specifies a protocol for the representation of non-ASCII text in message headers), section "2. Syntax of encoded-words".

A so called 'encoded word' has the following format:

encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used.