Below is a fix for the issue (for class.phpmailer.php in 1.2.0a3), there were a combination of several small bugs together:

* class.phpmailer.php Thu Jan 15 10:05:00 2009
--- class.phpmailer.php Sat Mar 28 01:55:55 2009
***** class PHPMailer {
* 1332,1340 **
$encoded = str_replace('='.$this->LE, "\n", trim($encoded));
}

! $encoded = preg_replace('/^(.*)$/m', " =?".$this->CharSet."?$encoding?\1?=", $encoded);
! $encoded = trim(str_replace("\n", $this->LE, $encoded));
!
return $encoded;
}

--- 1332,1339 ----
$encoded = str_replace('='.$this->LE, "\n", trim($encoded));
}

! $encoded = preg_replace('/^(.*)$/m', "=?".$this->CharSet."?$encoding?\1?=", $encoded);
! $encoded = trim(str_replace("\n", $this->LE." ", $encoded));
return $encoded;
}

***** class PHPMailer {
* 1384,1394 ****
}
while (strlen($chunk) > $length);

! $encoded .= $chunk . $this->LE;
}

  // Chomp the last linefeed

! $encoded = substr($encoded, 0, -strlen($this->LE));
return $encoded;
}

--- 1383,1393 ----
}
while (strlen($chunk) > $length);

! $encoded .= $chunk . "\n";
}

  // Chomp the last linefeed

! $encoded = substr($encoded, 0, -1);
return $encoded;
}

Sent the patch to PHPMailer as well
https://sourceforge.net/tracker/?func=detail&aid=2717658&group_id=26031&atid=385709

Fix in git master. Thanks.

Can you test this against phpmailer 5.0

Judging from 5.0 source code from here:
http://phpmailer.svn.sourceforge.net/viewvc/phpmailer/phpmailer/branches/5.0-dev/class.phpmailer.php?revision=263&view=markup

The problem is still there. No change in code in that area.

I've tested PHPMailer 5.0 against Mantis and I can confirm via Wireshark testing that the line termination of email header fields and line breaks within the message itself appear to be CRLF (correct according to RFC2822).

I'm unsure why there is a configuration option in PHPMailer 5.0 specifying LE as just LF... without the CR. It must have some other usage I haven't read into enough.

Basically all I'm saying is that every line within an email message (header and body) should be terminated with CRLF, not just LF.

Well, yes it is strange that LE can be configured, but that is not the problem of this ticket. The issue in this ticket is that because of
$encoded .= $chunk . $this->LE;

the following regexp

$encoded = preg_replace('/^(.*)$/m', " =?".$this->CharSet."?$encoding?\1?=", $encoded)

would match the string until the LF, causing the CR to be part of the final encoded chunk
=?utf-8?B?XXXXX"CR HERE"?=

and in addition it is better to place each encoded chunk on a separate line in the resulting subject header.

So in terms of phpmailer 5.0:

we need the
! $encoded = preg_replace('/^(.*)$/m', "=?".$this->CharSet."?$encoding?\1?=", $encoded);
! $encoded = trim(str_replace("\n", $this->LE." ", $encoded));
change, but not the 2nd part of the diff

I dont understand a couple of things:

a) why did you need to change the 2nd part (surely strlen(LE) for \n is 1 so that's the same, if someone is using \r\n would you not require -2?

b) why the addition of a space after the \n i.e. in the trim line i.e. doesn't that lead to extra whitespace?

All the changes are need,

a) First of all LE is \r\n. Second, the change in Base64EncodeWrapMB is in two lines:
! $encoded .= $chunk . $this->LE;
needs to be changed to
! $encoded .= $chunk . "\n";
and
! $encoded = substr($encoded, 0, -strlen($this->LE));
needs to be changed to
! $encoded = substr($encoded, 0, -1);

The reason to use "\n" here instead of $this->LE is that Base64EncodeWrapMB is only used internally in EncodeHeader and the output of Base64EncodeWrapMB is then processed using regexp - and those regexp (well at least on linux systems) don't work as meant if the output of Base64EncodeWrapMB contains \r\n. This what I show in my previous reply.

b) The space is a must, as all those lines are part of the Subject: header. For several lines to belong to one header they must start with a space or a tab. This is the MIME standard.