Back around 2004 I wrote a Perl emailer with MIME::Lite which has been working ever since then. Only now is the client trying to send HTML with it. The following code (trimmed down to the significant parts) properly sets all values. The HTML body is attached as text/html. Prior to the attachment the data clearly has no CR (CRLF, or LF). But after attaching it the HTML does have an embedded CR. This seems to be added after 1000 characters.
Unfortunately it's landing in the middle of a tag, thus breaking the tag which is rendering as a tag in the recipients email, rather than rendering entirely as formatted text: <BR> is displays as < BR>. And it's not breaking on the specific tag. I can change the tags and it always breaks around the same character position. I've read through the MIME::Lite code (with my very rusty Perl skills), but I don't see where it would be doing this split operation.
use MIME::Lite; # v3.030
my $bodyWithNoCR = "<html>" . ("x" x 1020) . "</html>";
my $mime_msg = MIME::Lite->new(
From => 'x@x.com',
To => 'x@x.com',
Subject => 'Subject',
Type =>'multipart/mixed')
or die "$!\n";
$mime_msg->attach(
Type => 'text/html',
Data => $bodyWithNoCR)
or die "$!\n";
my $bodyWithCR = $mime_msg->as_string;
It's not just as_string which shows this, the Net::SMTP dump shows the HTML split across lines, and this is reflected in the recipient's email client.
I know MIME::Lite is considered buggy. But my question is if this specific issue is recognized (preferably with a reference to a tracker ID). A response of "yes, I've seen that" is helpful but (respectfully) isn't enough to confirm for a fact that this is a known issue in old code. If I can find a tracker item for this issue then I'll know if I can look for a patch or if I need to suggest to the user that this specific code can't be used for this specific purpose.
Can anyone suggest alternative code for the attach() that might cause it to avoid whatever it is that's breaking up the block?
As to using other tools (an expected response), I rewrote this all with PHPMailer many years later for other clients, but the API is different and it would be a hassle for the client to retool to use that. I could also replace MIME::Lite with something else (as recommended by the maintainers) but on the old Linux box a requirement for a dependency chain might preclude loading anything more current. That said, alternative approaches with MIME::Lite are welcome.
Without a better solution at this time, the only workaround being considered (but not liked at all) is to build the HTML with embedded spaces from columns 980-1020, 1980-2020, etc, so that even if a CR is embedded, the whitespace isn't visible in the recipient's mail client. (Yeah, yuck!)
I believe this might have something to do with what's going on:
#------------------------------
#
# encode_8bit STRING
#
# Encode the given string using 8BIT.
# This breaks long lines into shorter ones.
sub encode_8bit {
my $str = shift;
$str =~ s/^(.{990})/$1\n/mg;
$str;
}