html formatted emails -- what's your take?

[dugawug]

hi everyone,
for a NPO i'm affiliated with, we're considering sending future emails out in HTML format.
i've read up about it and see a LOT of both people who recommend it and people who highly discourage it.

i wanted to get some feedback from the awesome people at PHPbuilder.

[LordShryku]

I'm a fan of multipart. Allow people with html capabilities to see it in html, text based readers with see the text. That's the way I do it on my intranet. If I had something like a sign up though, I'd probably present them with the choice of which they'd like to see...

[dugawug]

interesting...
how are these two things achieved though? pardon my ignorance...meaning, the sending in multipart format and managing a plain text or HTML preference?
hand coding or something a good bulk email program can take care of?

[LordShryku]

Well, the multipart I hand coded a function to handle it, but pear's mail mime (http://pear.php.net/manual/en/package.mail.mail-mime.php) looks good.

As far as the preferences, should be a simple flag stored in the database with the email addresses.

[dugawug]

wow, so the PEAR mail mime works by actually first checking for HTML/plain text compatibility and then giving the recipient what they can handle?

i guess a database stored preference could be programmed to override this? say they can handle HTML but still have text as a preference?

lastly, what about these people declaring HTML emails to be like the biggest threat to security imaginable?

[LordShryku]

Actually, the way multipart works is by sending you both versions of the email in one package. Your reader determines the way it should be displayed. So the same email message opened in mutt(text based) would look completely different if you opened it in evolution(html capable).

As far as security, that depends how you run your site. If you're the one sending the emails out, and you have no malicious intent and embed no script, well, you shouldn't have to worry. The end user should be the one worried about security, and there's things they can do to prevent malicious content. There's settings in most(all?) email viewers to specify if you want to see html emails as plain text, in essence, disabling script from being run. There's plugins to scan html messages for exploits. You could always just use a text based email reader. Lots of ways to secure yourself. A website that gives me the option of choosing to see it as plain text, instead of html would give a bit more of a warm-n-fuzzy feeling too. So someone who has html capabilities, but doesn't want to see it in html can just opt to get plain text emails instead.

[dugawug]

i see...i was reading this off this site (http://www.georgedillon.com/web/html_email_is_evil_still.shtml):

1. HTML e-mail is dangerous
If for no other reason, you should not send e-mail in HTML format because by doing so you are exposing your intended recipient(s) to the risk of catching a virus - a virus which you yourself may be unaware you have until you are told about it by someone you have infected (or until it alerts you to its presence by unleashing its payload).

Most of the fast-spreading internet-borne viruses propagate by automatically forwarding themselves to every address which they can find in your address book, and some even seek out every address in the body of every message in your inbox. Of course, they don't stop to ask your permission before doing this - the first symptom you'll spot is someone you've infected sending you an angry message saying you've given them a virus.

Unfortunatley the latest popular virus at the time of writing (k l e z) fakes the from address too, so you cannot warn (or accuse) unknowing senders of viruses, and you may also find yourself falsely accused.

But what has this to do with HTML mail?

For at least 3 years there have been viruses (namely Bubbleboy and kak.worm) which are triggered simply by viewing an HTML message in the preview pane of unpatched versions of Outlook Express. There are other ways of getting html functional email to automatically run code, by exploiting a vulnerability in the way the Internet Explorer engine (which Outlook and OE use to display HTML mail) handles IFRAMEs for example.

Since HTML can include scripts, HTML email is obviously more of a security risk than plain text, and the most recent viruses have made full use of this flaw.

[LordShryku]

Before I list the 7 points, I want one make one thing as clear as I can. It's RECEIVING HTML mail that's the problem. SENDING HTML mail will not hurt you (unless you are still using a metered dial up connection)

Again...the end user needs to be one concerned. And if possible, give them the choice. Maybe on the signup, make the default to be text-based, and give them the choice for html. The simple fact is that using html email is the same as looking at a website. The _web_ is full of bad stuff, and email is a part of that.

[dugawug]

gotcha,
i was just thinking more in terms of the recipients. of course, i don't want them getting viruses just b/c of my email. but it sounds like it's up to them for the most part to defend themselves? i mean, i doubt i'd be the only person sending these people HTML emails!

on another note, i just took Outlook and turned on "Read all messages as text" then went to an HTML message and it magically! turned into a nice text format with a link to the HTML version of the email.

so this would be an example of a message sent in multipart format or is this result standard?

if it happend b/c it's multipart, i wonder what a non-multipart HTML message would display like if it were a text only reader? would it just display the raw HTML you think?

[LordShryku]

That might not be multipart. Like I said, most reader's nowadays have that option built in. And yeah, a non-multipart would just shot the html markup. At least, that's my experience with mutt...

[dugawug]

oh, so it could be Outlook converting it to text, not the email being multipart....i see.

cool, you've been a super help LordShryku...definitely one of the most knowledgeable and helpful people on the forum.

last thing, so say i send multipart with PEAR mailmime.
(whats starting to be my conclusion after our talks)

would the logic flow work something like:

1. check database flag for email preference.
2. if html, send as multipart email (just in case they've turned HTML off)
3. if text, send simply as text
4. if none, send as multipart (or text to be safe)

i wouldn't want to just always just send as multipart, right?, in case they can read HTML but have a database preference for text?

well, anyway, i'll be getting into some coding soon.
thanks again

[LordShryku]

That sounds about right. If they pick text, just send text. If they pick html, you could just send html or send multipart, just in case. The 4th point will be a judgement call. Really up to you. I might play with the pear lib just to see if it outperforms my current script, which at this point, is a little old.

[dugawug]

cool,
well, i'm off to bed soon...no one else really chiming in on this thread, huh Shyrku?

one more idea to kick around:
a friend of mine works for a company that said they don't send HTML emails b/c they more often than not end up in "Bulk" or "Junk" mail folders by default?

sounds untrue to me...anyone else?

maybe it has to do with the MIME headers you include?
don't know much about this arena either though.

[LordShryku]

Well, I suspect Weedpacket will get in on this and contradict everything I said, but he knows mime much better than me, so that's ok. Plus most people are in bed, which is probably where I should be going soon.

As far as the junk or bulk email, there's probably a couple things to take in to consideration.

Your "From" address should be valid. A lot of filters check email orgins in the headers and if the from address doesn't match, it'll think the email is spam.

As far as most web email programs (hotmail, yahoo, etc), you'll probably have to test these out. I can't seem to wrap my brain around the logic of how some of those calculate what's spam and what's not. Of course, some you can't do anything about if you piss off the right person. I remember one of those just stopped delivering mail from gmail accounts, because they *might* be gmail invitations.

The filters on the users computers, you really can't do anything about. They manage those, and if they mark you as spam, well, that's their fault...

[LordShryku]

Just an update here:
Played with the pear package this morning, and while I can't see any performance gain, the syntax was pretty simple.
Here's the sample message I used...
<?php
ini_set('include_path', '/usr/local/lib/php/');
require_once('Mail.php');
require_once('Mail/mime.php');

$text = "Who's the mime-multipart buddha?\n--text version--";
$html = "
<html>
<body>
<h4>Who's the mime-multipart buddha?</h4>
<br />
--HTML version--
</body>
</html>";
$head = array('From' => 'Aaron Eft <nospam@gmail.com>', 'Subject' => 'Test message');
$mime = new Mail_mime("\n");
$mime->setTXTBody($text);
$mime->setHTMLBody($html);
$body = $mime->get();
$hdrs = $mime->headers($head);
$mail =& Mail::factory('mail');
$mail->send('nospam@gmail.com', $hdrs, $body);
?>

[The Chancer]

And a written multipart mailer...


<?php

//sendmailer test

$message="<html><head></head><body><h3>Foo</h3></body></html>";
$plaintext = "boo";
$to = array("ME" => "me@b.co.uk");
$sent=socketmail("Testing to me", "webmaster@home.com", $to, $subject, $message,$plaintext);
if ($sent==false){echo "There was an error somewhere...";}


function socketmail($fromName, $fromAddress, $toArray, $subject, $message,$plain) {
ini_set("sendmail_from", $fromAddress);
$handle = fsockopen ("127.0.0.1",25, $errno, $errstr, 30) or die("Could not talk to the sendmail server!<br/>$errno<br/>$errstr");
$rcv = fgets($handle, 1024);
echo $rcv."1<br />";
fputs($handle, "HELO {$_SERVER['SERVER_NAME']}\r\n");
$rcv = fgets($handle, 1024);
echo $rcv."2<br />";
while (list($toKey, $toValue) = each($toArray)) {
fputs($handle, "MAIL FROM:$fromAddress\r\n");
$rcv = fgets($handle, 1024);
echo $rcv."3<br />";
if (trim(substr($rcv,0,3))!='250')
{
return false;
exit;
}
fputs($handle, "RCPT TO:$toValue\r\n");
$rcv = fgets($handle, 1024);
echo $rcv."4<br />";
if (trim(substr($rcv,0,3))!='250')
{
return false;
exit;
}
fputs($handle, "DATA\r\n");
$rcv = fgets($handle, 1024);
echo $rcv."5<br />";
if (trim(substr($rcv,0,3))!='354')
{
return false;
exit;
}
fputs($handle, "MIME-Version: 1.0\r\n");
fputs($handle, "Subject: $subject\r\n");
fputs($handle, "From: $fromName <$fromAddress>\r\n");
fputs($handle, "To: $toKey <$toValue>\r\n");
fputs($handle, "Date: ".date('r')."\r\n");
fputs($handle, "X-Sender: <$fromAddress>\r\n");
fputs($handle, "Return-Path: <$fromAddress>\r\n");
fputs($handle, "Errors-To: <$fromAddress>\r\n");
fputs($handle, "X-Mailer: PHP - SocketMail\r\n");
fputs($handle, "X-Priority: 3\r\n");
fputs($handle, "Content-Type: multipart/alternative; boundary=\"NextPart_000_000A_01C3EE3F.867B1730\"\r\n");
fputs($handle, "\r\n");
fputs($handle, "This is a multi-part message in MIME format.\r\n");
fputs($handle, "\r\n");
fputs($handle, "--NextPart_000_000A_01C3EE3F.867B1730\r\n");
fputs($handle, "Content-Type: text/plain;\r\n");
fputs($handle, "charset=\"iso 8859-1\"\r\n");
fputs($handle, "Content-Transfer-Encoding: 7bit\r\n");
fputs($handle, "\r\n");
fputs($handle, chunk_split($plain) . "\r\n");
fputs($handle, "\r\n");
fputs($handle, "--NextPart_000_000A_01C3EE3F.867B1730\r\n");
fputs($handle, "Content-Type: text/html;\r\n");
fputs($handle, "charset=\"iso 8859-1\"\r\n");
fputs($handle, "Content-Transfer-Encoding: quoted-printable\r\n");
fputs($handle, "\r\n");
fputs($handle, chunk_split($message) . "\r\n");
fputs($handle, "\r\n");
fputs($handle, "--NextPart_000_000A_01C3EE3F.867B1730--\r\n");
fputs($handle, "\r\n");
fputs($handle, ".\r\n");
$rcv = fgets($handle, 1024);
echo $rcv;
if (trim(substr($rcv,0,3))=='250')
{
return true;
}
else
{
return false;
}
fputs($handle, "RSET\r\n");
$rcv = fgets($handle, 1024);
}
fputs ($handle, "QUIT\r\n");
$rcv = fgets ($handle, 1024);
//echo("$rcv<br>");
fclose($handle);
ini_restore("sendmail_from");
}
?>


<slightly amended from that in Code Critique...>

[dugawug]

thanks to you both for the multipart emailer examples.

any one with more ideas on how to avoid HTML emails from going right to a Junk folder?