Description: ------------ We experienced some mail injection attacks (http://securephp.damonkohler.com/index.php/Email_Injection) against forms using PEAR::Mail (and raw mail()). The problem is not the package itself, but the programmers who forget to sanitize the input. I wrote a small patch that tries to address the issue in PEAR::Mail. You can see it here (not very well tested, but works at the moment): http://andreas.ahlenstorf.ch/Mail.patch It looks at every value in the headers array and strips everything that comes after a character, that may be interpreted as header separator (eg. new line or carriage return). In the end, it's a general purpose solution (a.k.a. sledgehammer) to prevent the worst case (lots of spam). Additional checks to prevent bounces et al. can be performed later or somewhere else. I don't know how's your policy regarding protection against forged input, but I really think it's worth thinking about the inclusion of the patch or a similar solution, because PEAR::Mail's sensitivity for email injection is not obvious, above all for beginners. That comes from the API, that takes the headers as associative array where you don't expect that a value can become another header. Test script: --------------- <?php // "user supplied input" $reply_to = "att@cker.tld\nBcc:spam@victim.tld"; include('Mail.php'); $recipients = 'foo@owner.tld'; $headers['From'] = "website@owner.tld"; $headers['To'] = 'recipient@owner.tld'; $headers['Subject'] = 'Test message'; $headers['Reply-To'] = $reply_to; $body = 'Test message'; // Create the mail object using the Mail::factory method $mail_object =& Mail::factory('mail'); var_dump($mail_object->send($recipients, $headers, $body)); ?> Expected result: ---------------- Only email in the mailbox of recipient@owner.tld. Actual result: -------------- Email in the mailbox of recipient@owner.tld, spam@victim.tld and emails from AOL to our abuse address...

This looks pretty useful, but I'm not sure it belongs in the Mail class itself. I'm going to think about it a bit more, but I definitely want to include it somewhere in the package (either as an example in the documentation or in a set of utility functions).

At least the new "Zend_Mail" provides protection for this trick by default. will be nice if PEAR Mail can do the a similar thing.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.

function _sanitizeHeaders in Mail.php erase "boundary" in "Content-Type". Can not send a html mail in the sample, http://pear.php.net/manual/en/package.mail.mail-mime.example.php Expected result: ---------------- Content-Type: multipart/alternative; boundary--"=_29e435fcd1c17793cd33f23cc34b7c1e" Actual result: -------------- Content-Type: multipart/alternative; --=_29e435fcd1c17793cd33f23cc34b7c1e Adding a "return;" in front of the function is an emergency measure. function _sanitizeHeaders(&$headers) { return;

Thank you for your bug report. This issue has been fixed in the latest released version of the package, which you can download at http://pear.php.net/get/Mail