multipart email weirdness ... did i do this right?

[theinfamousmielie]

Hi all,

 

Trying to make a multi-part email. In general it's fine, but i've also been running it through SpamAssassin (and others) to make sure it comes out all clean and shiny ... or as clean and shiny as possible. Here's the code, and i'll explain the problem afterwards.

 

<?php
// IN CLASS  FILE (as a part of two functions, which work okay on their own):
// ====================
$this->AddHeader("Content-Type", "multipart/mixed; boundary=\"AuroraMail-Mixed-" . $this->MailKey . "\""); // writes to $this->Headers

$this->Headers = trim($this->Headers);
$this->Headers .= $this->EndOfLine . $this->EndOfLine;


// IN MAIN FILE
// ====================
$sep = $Mail->MailKey;  // Key generated randomly, this works fine
$sep2 = sha1("dvd.jpg"); // excuse the dodgy naiming of variables, hhehe
$image1 = chunk_split(base64_encode(file_get_contents('dvd.jpg')));

$Mail->Body = <<<EOBODY
--AuroraMail-Mixed-{$sep}
Content-Type: multipart/alternative; boundary="AuroraMail-Section-{$sep}"

--AuroraMail-Section-{$sep}
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

In summary, we should be giving serious consideration to image-blocking and what we can do about it. It’s natural and reasonable why people disable them, but with the right approach we can improve the experience for our subscribers

I have setup SA 3.1 under FC4, which is working quite well. However, one type of message that still gets through is a series of mails that are made up of no text other than a varying subject, then a picture, which is black text on white, which looks exactly like an ordinary email. Obviously SA can't read the message since it is an image, but is there a way to make a rule that blocks a mail where there is an image only, no text?

So we’ve created a structurally-sound template, we’re preparing to send our email to a permission-based list of subscribers and we’ve taken steps to see our list email-address into the address books of the said subscribers. There are still a number of people on our lists who will intentionally block images, and therefore we should account for that scenario.

--AuroraMail-Section-{$sep}
Content-Type: multipart/related; boundary="AuroraMail-SubSection-{$sep}"

--AuroraMail-SubSection-{$sep}
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<h2>Hello!</h2>
<p>In summary, we should be giving serious consideration to image-blocking and what we can do about it. It’s natural and reasonable why people disable them, but with the right approach we can improve the experience for our subscribers</p>
<p>I have setup SA 3.1 under FC4, which is working quite well. However, one type of message that still gets through is a series of mails that are made up of no text other than a varying subject, then a picture, which is black text on white, which looks exactly like an ordinary email. Obviously SA can't read the message since it is an image, but is there a way to make a rule that blocks a mail where there is an image only, no text?</p>
<p>So we’ve created a structurally-sound template, we’re preparing to send our email to a permission-based list of subscribers and we’ve taken steps to see our list email-address into the address books of the said subscribers. There are still a number of people on our lists who will intentionally block images, and therefore we should account for that scenario.</p>

<img src="cid:AM_IMG_{$sep2}">

--AuroraMail-SubSection-{$sep}
Content-Type image/jpeg; name="dvd.jpg"
Content-Transfer-Encoding: base64
Content-ID: <AM_IMG_{$sep2}>
Content-Disposition: inline; filename="dvd.jpg"

{$image1}

--AuroraMail-SubSection-{$sep}--

--AuroraMail-Section-{$sep}--

--AuroraMail-Mixed-{$sep}--
EOBODY;
?>

 

 

That should cover it. Here's the thing. The mail sends fine. Everything works, and if i add on an attachment too, it works perfectly. The problem is actually linked with SpamAssassin, as well as the RFC guidelines possibly. Maybe someone has run into this:

 

According to SpamAssassin, i have the following problem: MISSING_MIME_HB_SEP

 

According to SpamAssassin, there is a need for a blank line inbetween the headers and the message ... but there is!! But this isn't where it's weird ... the moment i take out the entire 'image attachement', the problem goes away, or if i change:

 

<?php
--AuroraMail-SubSection-{$sep}
Content-Type image/jpeg; name="dvd.jpg"
Content-Transfer-Encoding: base64
Content-ID: <AM_IMG_{$sep2}>
Content-Disposition: inline; filename="dvd.jpg"

{$image1}

--AuroraMail-SubSection-{$sep}--
?>

 

to

 

<?php
--AuroraMail-SubSection-{$sep}

Content-Type image/jpeg; name="dvd.jpg"
Content-Transfer-Encoding: base64
Content-ID: <AM_IMG_{$sep2}>
Content-Disposition: inline; filename="dvd.jpg"

{$image1}

--AuroraMail-SubSection-{$sep}--
?>

 

the problem goes away ... but then the image doesn't show. Catch 22!

 

Does anyone have any ideas? Is my formatting correct?

 

I've spent several hours pondering this, it's frustrating me to no end.

 

By the way, all my end-of-line characters are /n, as the script sits on a linux box.

 

[MadTechie]

MISSING_MIME_HB_SEP  = Missing serperator line between MIME HB (header and body)

i normally concat stings.. and don't use heredoc..

 

maybe try

$Mail->Body = <<<EOBODY
--AuroraMail-Mixed-{$sep}
Content-Type: multipart/alternative; boundary="AuroraMail-Section-{$sep}"/n/r

[theinfamousmielie]

regrettably, that doesn't work.

 

I don't normally use heredoc either, but for this particular form, it is just neater and easier to read and does the job.

 

I'm just trying to understand why, when there is clearly a blank line between the header and the body (i output to see the results in a var_dump of sorts) ... i've provided a link to the relevant portion here ... it's a vardump in <pre></pre> tags.

 

http://www.digiworks.co.za/xSandbox/testmail4.php - blue is the output of the controller BEFORE the body is parsed, and the green is the contents of $Mail->Body

 

 

Any thoughts?

[MadTechie]

oops

/n/r should be \n\r

[theinfamousmielie]

correct. hehe. But it still doesn't work i see the 'extra' line that's been added now ... it appears as two blank lines now.

 

surely it's something arbitrary and silly! A hefty chunk of the world uses SpamAssassin on their apache servers and really i can't afford to drop 2.5 points

 

 

[MadTechie]

the only thing i could suggest if create a small test email.. start at the minimum and build up until you find the cause..

maybe add extra lines to everything.. as SpamAssassin is open source it can be a pain to get support for

[theinfamousmielie]

i did that ... started with basics. Everything fine until i added the image section

 

<?php
--AuroraMail-SubSection-{$sep}
Content-Type image/jpeg; name="dvd.jpg"
Content-Transfer-Encoding: base64
Content-ID: <AM_IMG_{$sep2}>
Content-Disposition: inline; filename="dvd.jpg"

{$image1}

--AuroraMail-SubSection-{$sep}--
?>

 

technically, the mail works fine. I receive it fine, it just gets a 5.7 spam rating ... without the image, it gets 3! Since this is supposed to be attached to website contact forms, i'd really like it if mailservers wouldn't block simple non-spam website enquiries

 

I think it's a spamassassin problem though, i guess i'll have to try find a way to get to them to find out exactly what it's expecting and why what i have isn't registering. I find it very strange that the error disappears when that image section is removed ... it isn't a header! THAT is what's confusing me, and that is why i think there's something wonky with spamassassin. Oh well.

 

I seem to run into problems like this a lot

 

Thanks for your help mate, i've put it on notify if you think of anything else don't hesitate, hehe.