PEAR Bug Search Results

Mail_Mime: Bug 16847 [Open] Mail.php not found

brandonusa at gmail dot com — 2009-11-29T22:57:04+00:00

Mail_Mime Bug
Reported by brandonusa
2009-11-29T22:57:04+00:00
PHP: 5.1.6 OS: centOS 5.3 Package Version: 1.5.2

Description:
------------
I have centos 5.3 as my linux server. 
On centOS 5.3 First problem I ran into was the pear package was not up to date and I could only fix it via this command
 pear upgrade --force pear

then I did the pear install command
 pear install Mail_Mime-1.5.2

and after doing so 
I can see that mime.php is located in 
/usr/share/pear/Mail/mime.php

BUT I cannot find Mail.php anywhere in the server.
is Mail.php another library I need? I've googled around, I might have to resort to manual installation.


Actual result:
--------------
PHP Fatal error:  Class 'Mail' not found in /home/....

Mail_Mime: Bug 16846 [Open] /e modifier not allowed by suhosin

alec at alec dot pl — 2009-11-29T10:12:22+00:00

Mail_Mime Bug
Reported by alec
2009-11-29T10:12:22+00:00
PHP: Irrelevant OS:  Package Version: CVS

Description:
------------
When suhosin.executor.disable_emodifier option is enabled, use of /e modifier in preg_replace is not allowed. preg_replace_callback method must be used to prevent errors from suhosin.

Mail_Mime: Bug 16706 [Open] Incorrectly double-quotes RFC 2231-encoded parameter values

phil_g at pobox dot com — 2009-10-16T18:16:01+00:00

Mail_Mime Bug
Reported by asciiphil
2009-10-16T18:16:01+00:00
PHP: 5.2.5 OS: Debian GNU/Linux Package Version: 1.5.2

Description:
------------
When adding parameter values to MIME attachments (e.g. the "name" parameter for the "Content-Type" MIME header), if Mail_Mime determines that RFC 2231 encoding is necessary, it will still put the value in double quotes, which does not match the RFC 2231 spec.

I'm attaching a patch to mimePart.php that will only put in the quotes if the parameter is a "regular-parameter", according to RFC 2231's ABNF, and not if it's an "extended-parameter".

Mail_Mime: Bug 16623 [Open] When sending mails with attachments, the same boundaries are used

mk at digitaleprodukte dot de — 2009-09-17T17:36:14+00:00

Mail_Mime Bug
Reported by markusknaup
2009-09-17T17:09:05+00:00
PHP: 5.2.5 OS: Debian Lenny Package Version: 1.5.2

Description:
------------
I had problems, when attaching a file to an e-mail:

$mime = new Mail_mime("\n");
$mime->setTXTBody($txtBody);
$mime->setHTMLBody($htmlBody);

if (is_array($attachments)) {
	foreach($attachments as $attachment) {
		$mime->addAttachment($attachment["file"], 
$attachment["contentType"], $attachment["name"], 
$attachment["isFile"], $attachment["encoding"]);
	}
}

$mailBody = $mime->get($_build_params);
$mailHeaders = $mime->headers($mailHeaders);

$mail =& Mail::factory($this->backend, $this->backendParams);
		
$mail->send($this->recip, $mailHeaders, $mailBody);


In this use case the mail was sent, but nearly all webmailers and e-mail 
programs did not show the 
attachment(s). I analysed the source code of the sent e-mails and I saw 
that the same boundaries were used 
for different e-mail parts (here "_d188467fafaf9f24df2e4585a2d76019"):

To: [E-MAIL-ADDRESS]
Subject: [SUBJECT]
MIME-Version: 1.0
From: [ANOTHER E-MAIL-ADDRESS]
Content-Type: multipart/mixed;
	boundary="=_d188467fafaf9f24df2e4585a2d76019"
Date: Thu, 17 Sep 2009 17:37:41 +0200 (CEST)

--_d188467fafaf9f24df2e4585a2d76019
Content-Type: multipart/alternative;
	boundary="=_d188467fafaf9f24df2e4585a2d76019"

--=_d188467fafaf9f24df2e4585a2d76019
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"

[CONTENT]
--=_d188467fafaf9f24df2e4585a2d76019
Content-Transfer-Encoding: base64
Content-Type: text/html; charset="utf-8"

[CONTENT]
--=_d188467fafaf9f24df2e4585a2d76019--

--=_d188467fafaf9f24df2e4585a2d76019
Content-Transfer-Encoding: base64
Content-Type: application/pdf;
 name="file.pdf"; 
Content-Disposition: attachment;
 filename="file.pdf"; 

[CONTENT]
--_d188467fafaf9f24df2e4585a2d76019--


So, I wrote a simple (not optimal) workaround, but this should be fixed 
somehow in Mail_mime (if it is a bug):

$mailBody = $mime->get($_build_params);
$mailHeaders = $mime->headers($mailHeaders);

// Workaround, because, if attachments exist the same boundary is used 
for several e-mail parts
if (sizeof($this->attachments) > 0) {
	preg_match("/boundary=\"(.[^\"]*)\"/e", $mailHeaders["Content-
Type"], $boundary);
	$boundary = $boundary[1];
	$bounderyNew = $bounderyNew;
	$mailHeaders["Content-Type"] = 
preg_replace('/boundary="(.[^"]*)"/', 'boundary="' . $bounderyNew . 
'"', $mailHeaders["Content-Type"]);
	$mailBody = preg_replace("/^\-\-" . $boundary . "/s", "--" . 
$bounderyNew, $mailBody);
	$mailBody = preg_replace("/" . $boundary . "--$/s", $bounderyNew 
. "--", $mailBody);
	$mailBody = preg_replace("/" . $boundary . "--(\s*)--" . $boundary 
. "/s", $boundary . "--$1--" . 
$bounderyNew, $mailBody);
}

$mail =& Mail::factory($this->backend, $this->backendParams);


This changes the boundary of the toplevel e-mail parts.

Mail_Mime: Bug 16539 [Open] Long headers break mime body display

jskibbie at schawk dot com — 2009-08-19T20:15:09+00:00

Mail_Mime Bug
Reported by skibster
2009-08-19T20:15:09+00:00
PHP: 5.1.2 OS: 10.3.9 Package Version: 1.5.2

Description:
------------
If the To header is set in a mixed message text/html, and the header is 
longer than 998 characters, the email body is displayed as the source 
text instead of as HTML.

According to RFC 2822, there is a method for 'folding' long headers. This 
should be implemented to avoid this issue.

Test script:
---------------

	
    
    '.$headers['Subject'].'
    
	
	
	
	
	    A Low Resolution PDF is ready for review.


	    This is the link


	
	
	
	
';

$mail_object =& Mail::factory('smtp', $params);
$mime = new Mail_mime($crlf);
$mime->setTXTBody($textMsg);
$mime->setHTMLBody($htmlMsg);
$mailGetParam["text_encoding"] = "7bit";
$mailGetParam["html_encoding"] = "quoted-printable";
$mailGetParam["html_charset"] = "ISO-8859-1";
$body = $mime->get($mailGetParam);
$hdrs = $mime->headers($headers);
$mailResult = $mail_object->send($headers['To'], $hdrs, $body);
?>

Expected result:
----------------
An email that has a properly formatted To and Subject and the body 
looks like this:

A Low Resolution PDF is ready the review.

This is the link  

(where the link is an HTML anchor tag).

Actual result:
--------------
An email that has no "To" or "Subject", and the body is raw source.

Received: from smtp.example.com ([127.0.0.1]) by 
some.smtp.example.com with Microsoft SMTPSVC(6.0.3790.3959);
	 Wed, 19 Aug 2009 13:44:12 -0500
Received: from localhost ([10.26.26.168]) by some.smtp.example.com 
with Microsoft SMTPSVC(6.0.3790.3959);
	 Wed, 19 Aug 2009 13:44:12 -0500
MIME-Version: 1.0
From: JSkibbie@schawk.com
Bcc:
Return-Path: JSkibbie@schawk.com
Message-ID: 
X-OriginalArrivalTime: 19 Aug 2009 18:44:12.0052 (UTC) 
FILETIME=[0B381540:01CA20FD]
Date: 19 Aug 2009 13:44:12 -0500

To: 
jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskib
bie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@
schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@scha
wk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.co
m,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jsk
ibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie
@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@sch
awk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.c
om,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,js
kibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbi
e@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@sc
hawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk
.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,
jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskib
bie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@
schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@scha
wk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.co
m,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jsk
ibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie
@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@sch
awk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.c
om,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,js
kibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbi
e@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@sc
hawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk
.com,jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,
jskibbie@schawk.com,jskibbie@schawk.com,jskibbie@schawk.com,jskib
bie@schawk.com,jskibbie@schawk.com
From: jskibbie@schawk.com
Subject: This is the Subject
Reply-To: jskibbie@schawk.com
X-Mailer: PHP 5.x
Content-Type: multipart/alternative;
	boundary="=_522c61ee6f7504b0b1319875c844a01a"
Return-Path: jskibbie@schawk.com
Message-ID: 
X-OriginalArrivalTime: 19 Aug 2009 18:44:12.0207 (UTC) 
FILETIME=[0B4FBBF0:01CA20FD]
Date: 19 Aug 2009 13:44:12 -0500

--=_522c61ee6f7504b0b1319875c844a01a
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-8859-1"

A Low Resolution PDF is ready for review.

Please use this link download a compressed archive of the PDF file:

http://thisisthelink.com
--=_522c61ee6f7504b0b1319875c844a01a
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="ISO-8859-1"



	
    
    This is the Subject
    

  
	
	
	
	
	    A Low Resolution PDF is ready for review.


	    This is the link


	
	
	
	

--=_522c61ee6f7504b0b1319875c844a01a--

Mail_Mime: Bug 16493 [Open] The charset for the headers cannot be set

bernd at oliverklee dot de — 2009-08-04T17:14:35+00:00

Mail_Mime Bug
Reported by boernd
2009-08-04T17:14:35+00:00
PHP: 5.2.5 OS: Ubuntu Package Version: 1.5.2

Description:
------------
Currently the only way of setting the charset for the headers is to call the get function of the mime class. It would be better to be able to set the charset separately since sometimes you need to manage the headers before calling get.

Mail_Mime: Bug 16363 [Open] Charset for multipart/related unset. Suggest setting using head_charset.

leonard-php-bugs at ottolander dot nl — 2009-06-23T00:21:04+00:00

Mail_Mime Bug
Reported by leonardjo
2009-06-22T15:52:18+00:00
PHP: Irrelevant OS: irrelevant Package Version: 1.5.2

Description:
------------
When creating multipart/related parts no charset is set in the (part)header. I suggest using the _build_params['head_charset'] for this.

--- mime.php.000	2008-02-19 18:56:36.000000000 +0100
+++ mime.php	2009-06-22 16:34:43.000000000 +0200
@@ -505,6 +505,7 @@ class Mail_mime
     function &_addRelatedPart(&$obj)
     {
         $params['content_type'] = 'multipart/related';
+        $params['charset']      = $this->_build_params['head_charset'];
         if (is_object($obj)) {
             return $obj->addSubpart('', $params);
         } else {

Mail_Mime: Bug 15888 [Verified] attachment name/filename header lacks semicolon separator

alec at alec dot pl — 2009-08-25T09:00:32+00:00

Mail_Mime Bug
Reported by alec
2009-02-10T07:44:01+00:00
PHP: 5.2.8 OS:  Package Version: 

Description:
------------
Now:
Content-Disposition: attachment;
 filename*0*="UTF-8''very long long long filename filename filename foo bar"
 filename*1*="boo baz bang";

Should be:
Content-Disposition: attachment;
 filename*0*="UTF-8''very long long long filename filename filename foo bar";
 filename*1*="boo baz bang";
 

Test script:
---------------
      

Expected result:
----------------
      

Actual result:
--------------

Mail_Mime: Bug 15320 [Analyzed] attachment charset is not set in Content-Type header

alec at alec dot pl — 2008-12-27T00:21:32+00:00

Mail_Mime Bug
Reported by alec
2008-12-16T07:45:34+00:00
PHP: 5.2.8 OS:  Package Version: CVS

Description:
------------
patch: http://trac.roundcube.net/changeset/2154

Mail_Mime: Bug 14780 [Open] Content-Type: Multipart/alternative is not set correctly.

poon dot fung at gmail dot com — 2008-12-08T04:31:22+00:00

Mail_Mime Bug
Reported by pf
2008-10-12T17:05:18+00:00
PHP: 5.2.6 OS: Windows XP Package Version: 1.5.2

Description:
------------
If you call Mail_mime::headers() before Mail_mime::get(), no content type header is set. A work around for simple message is to include content-type in header list when calling Mail_mime::headers(). 

But for a multipart message, it is not possible to get message boundary to construct 'content-type: multipart/alternative; bournary="???"'. There is a simple solution that has not been document. First call Mail_mime::get() to get message body. This call also update message headers. Then call Mail_mime::headers() to get headers.

Mail_Mime: Bug 14597 [Open] Factory with smtp and Mime gets email wrong

richard at everything4it dot co dot uk — 2008-09-04T15:07:32+00:00

Mail_Mime Bug
Reported by rvwilliams
2008-09-04T15:07:32+00:00
PHP: 4.4.4 OS: Debian Etch Package Version: 1.5.2

Description:
------------
The email created by the code below wrongly includes the Content-Type and Content-Transfer-Encoding lines so is never recognized as HTML.  Change the Factory from 'smtp' to 'mail' and the email is correct by of course not sent via the supplied $host.

Test script:
---------------
function new_mail($from,$to,$subject,$html,$host,$username,$password){
	ini_set("include_path", ":"."/usr/share/php/");
	require_once "Mail.php";
	require_once "Mail/mime.php";
	$headers = array ('From' => $from,
	'To' => $to,
	'Subject' => $subject);
	$message=new Mail_mime();
	$message->setHTMLBody($html);
	$body=$message->get();
	$headers=$message->headers($headers);
	$mail =& Mail::factory('smtp',array ('host' => $host,'debug'=>true,'port'=>2525,'auth' => true,'username' => $username,'password' => $password));
	$mail1 = $mail->send($to, $headers, $body);
	if (PEAR::isError($mail1)) {
		die("" . $mail1->getMessage() . "");
	} else {
		return(true);
	}
}

Expected result:
----------------
I expect to see this:
Position: b a-Africa_Fact_Book_(tmr)_-_Name: a c-Company_Name: c chosen: North Africa d-Address: d e-Postcode: e f-Country: f g-E-mail: g g-Web: h h-Phone: i 
What I actually see is this:
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


Position: b
a-Africa_Fact_Book_(tmr)_-_Name: a
c-Company_Name: c
chosen: North Africa
d-Address: d
e-Postcode: e
f-Country: f
g-E-mail: g
g-Web: h
h-Phone: i

 

Actual result:
--------------
DEBUG: Recv: 220 cmsinfo.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Thu, 4 Sep 2008 20:50:27 +0100 DEBUG: Send: EHLO localhost DEBUG: Recv: 250-xxxxxx.com Hello [91.192.192.107] DEBUG: Recv: 250-TURN DEBUG: Recv: 250-SIZE DEBUG: Recv: 250-ETRN DEBUG: Recv: 250-PIPELINING DEBUG: Recv: 250-DSN DEBUG: Recv: 250-ENHANCEDSTATUSCODES DEBUG: Recv: 250-8bitmime DEBUG: Recv: 250-BINARYMIME DEBUG: Recv: 250-CHUNKING DEBUG: Recv: 250-VRFY DEBUG: Recv: 250-X-EXPS GSSAPI NTLM LOGIN DEBUG: Recv: 250-X-EXPS=LOGIN DEBUG: Recv: 250-AUTH GSSAPI NTLM LOGIN DEBUG: Recv: 250-AUTH=LOGIN DEBUG: Recv: 250-X-LINK2STATE DEBUG: Recv: 250-XEXCH50 DEBUG: Recv: 250 OK DEBUG: Send: AUTH LOGIN DEBUG: Recv: 334 VXNlcm5hbWU6 DEBUG: Send: c3R1ZGVudA== DEBUG: Recv: 334 UGFzc3dvcmQ6 DEBUG: Send: Mll3Mk1MY24= DEBUG: Recv: 235 2.7.0 Authentication successful. DEBUG: Send: EHLO localhost DEBUG: Recv: 250-xxxxxx.com Hello [91.192.192.107] DEBUG: Recv: 250-TURN DEBUG: Recv: 250-SIZE DEBUG: Recv: 250-ETRN DEBUG: Recv: 250-PIPELINING DEBUG: Recv: 250-DSN DEBUG: Recv: 250-ENHANCEDSTATUSCODES DEBUG: Recv: 250-8bitmime DEBUG: Recv: 250-BINARYMIME DEBUG: Recv: 250-CHUNKING DEBUG: Recv: 250-VRFY DEBUG: Recv: 250-X-EXPS GSSAPI NTLM LOGIN DEBUG: Recv: 250-X-EXPS=LOGIN DEBUG: Recv: 250-AUTH GSSAPI NTLM LOGIN DEBUG: Recv: 250-AUTH=LOGIN DEBUG: Recv: 250-X-LINK2STATE DEBUG: Recv: 250-XEXCH50 DEBUG: Recv: 250 OK DEBUG: Send: MAIL FROM: DEBUG: Recv: 250 2.1.0 admin@xxxxxx.com....Sender OK DEBUG: Send: RCPT TO: DEBUG: Recv: 250 2.1.5 keithw@xxxxxx.com DEBUG: Send: DATA DEBUG: Recv: 354 Start mail input; end with . DEBUG: Send: MIME-Version: 1.0 From: CMS Email Administrator To: keithw@xxxxxx.com Subject: Africa Fact Book Registration (tmr) Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Position: b a-Africa_Fact_Book_(tmr)_-_Name: a c-Company_Name: c chosen: North Africa d-Address: d e-Postcode: e f-Country: f g-E-mail: g g-Web: h h-Phone: i . DEBUG: Recv: 250 2.6.0  Queued mail for delivery DEBUG: Send: QUIT DEBUG: Recv: 221 2.0.0 xxxxxx.com Service closing transmission channel

Mail_Mime: Bug 14529 [Open] basename() problem with utf-8

alec at alec dot pl — 2008-08-20T02:29:50+00:00

Mail_Mime Bug
Reported by alec
2008-08-20T02:29:50+00:00
PHP: 5.2.6 OS:  Package Version: CVS

Description:
------------
basename function is not utf-8 safe and there're known issues with it. See comments on http://php.net/manual/en/function.basename.php

Mail_Mime: Bug 14390 [Open] attachments not correctly escaped

brother at bsnet dot se — 2008-07-25T22:04:37+00:00

Mail_Mime Bug
Reported by brother
2008-07-22T15:05:32+00:00
PHP: 5.2.6 OS: Debian GNU/Linux Sid Package Version: CVS

Description:
------------
I've got an text file (a .po-file to be precise) with a ' (apostrophe) in it. 
When reading the file with the code in the area for test script  the file read ends at the first ' and the attachment is incomplete.

----

brother@zond:~$ file Desktop/translation/sent/080721/krb5.po 
Desktop/translation/sent/080721/krb5.po: UTF-8 Unicode English text, with very long lines


brother@zond:~$ pear version
PEAR Version: 1.7.1
PHP Version: 5.2.6-2
Zend Engine Version: 2.2.0
Running on: Linux zond 2.6.24-1-amd64 #1 SMP Thu May 8 03:30:20 UTC 2008 x86_64 

Test script:
---------------
$mime->addAttachment($basedir."sv.po", 'text/plain');

Expected result:
----------------
The file should be added with correctly escape in use.

Actual result:
--------------
not applicable

Mail_Mime: Feature/Change Request 14232 [Open] RFC2231: Improve tspecials encoding in _buildHeaderParam()

alec at alec dot pl — 2008-07-26T08:45:54+00:00

Mail_Mime Feature/Change Request
Reported by alec
2008-06-25T01:27:13+00:00
PHP: 5.2.6 OS:  Package Version: CVS

Description:
------------
According to RFC2231/2047 special characters ie. ', ", etc. (in RFC's named 'tspecials') must be encoded like other non-ascii characters.

Mail_Mime: Feature/Change Request 13969 [Open] Patch to stream attachments to counter memory issues

till at php dot net — 2008-05-26T07:32:23+00:00

Mail_Mime Feature/Change Request
Reported by till
2008-05-23T14:38:47+00:00
PHP: 5.2.5 OS: any Package Version: 1.5.2

Description:
------------
Here is a link to a patch which one of our users supplied us with. It also contains a patch against Mail_mime to add the possibility to stream attachments because when you read larger attachments into the memory, you constantly run into the memory_limit:

http://public.lanl.gov/jbarbuc/patches/roundcube/

Let me know if I can help to apply this.

Mail_Mime: Feature/Change Request 13962 [Open] Improve Multiple header support

hiroaki dot kawai at gmail dot com — 2008-05-24T02:27:26+00:00

Mail_Mime Feature/Change Request
Reported by kawai
2008-05-23T01:27:58+00:00
PHP: Irrelevant OS: Irrelevant Package Version: 1.5.2

Description:
------------
Current 1.5.2 have a problem when we want to pass a multiple headers that has the same header name like 'Received:'.


Mail_mimeDecode serves the header as an array if the mail has multiple header.

Test script:
---------------
decode();

$mime = new Mail_mime();
$r = $mime->txtHeaders($mail->headers);
var_dump($r);


Expected result:
----------------
string(184) "MIME-Version: 1.0
recieved: TX-POST id zwr1333; Fri, 23 May 2008 12:41:40 +0900 (JST)
recieved: TX-POST2 id far123dp; Fri, 23 May 2008 12:41:35 +0900 (JST)
from: sample@example.jp
"


Actual result:
--------------


Warning:  preg_match() expects parameter 2 to be string, array given in D:\apache\front\libphp\Mail\mime.php on line 927

string(61) "MIME-Version: 1.0
recieved: Array
from: sample@example.jp
"

Mail_Mime: Bug 13641 [Open] iconv_mime_encode seems to work different/errorious than the build in logic

jan dot slabon at setasign dot de — 2008-12-27T14:08:13+00:00

Mail_Mime Bug
Reported by janslabon
2008-04-10T11:11:58+00:00
PHP: 5.2.5 OS: Linux / Gentoo Package Version: 1.5.2

Description:
------------
When using the iconv_mime_encode function with a long subject several email clients (or the email servers?) will destroy the header if they include own header lines.

We could reproduce this on web.de and on a lotus notes server.

If we use "ignore-iconv" => true in the build_params the error didn't occurs.

Test script:
---------------
require_once('Mail/mime.php');
$mime =& new Mail_mime("\n"); 

$subject = 'âThis is a long textâ and will force the subject to be on several lines.';

$build_params = array(
    "html_charset" => "UTF-8",
    "text_charset" => "UTF-8",
    "head_charset" => "UTF-8"
);
$body = $mime->get($build_params);

$hdrs = $mime->headers(array('Subject' => $subject));
print_r($hdrs);

$build_params["ignore-iconv"] = true;
$body = $mime->get($build_params);

$hdrs = $mime->headers(array('Subject' => $subject));
print_r($hdrs);

Actual result:
--------------
To: xxx.xxx@xxx.de
Subject: =?UTF-8?Q?=E2=80=9CThis=20is=20a=20long=20text=E2=80=9D=20and?=
X-MIMETrack: Itemize by SMTP Server on XXXXX/XXXX/XXX(Release 7.0.3|September 26, 2007) at
09.04.2008 17:14:56,
                Serialize by Notes Client on XXX XXX/AAAA/BBB(Release 6.0.1CF1|March
04, 2003) at 09.04.2008 17:22:45,
                Serialize complete at 09.04.2008 17:22:45
From: XXX@XXX.XXX.de
Date: Wed, 9 Apr 2008 17:14:56 +0200
Message-ID: 

=?UTF-8?Q?=20will=20force=20the=20subject=20to=20be=20on=20several=20li?=
=?UTF-8?Q?nes.?=
MIME-Version: 1.0

Mail_Mime: Feature/Change Request 13468 [Assigned] Add option to fetch http:// images/stylesheets

walter at php dot net — 2008-03-22T17:05:14+00:00

Mail_Mime Feature/Change Request
Reported by walter
2008-03-22T16:54:13+00:00
PHP: Irrelevant OS:  Package Version: 1.5.2

Description:
------------
An increasing number of MUA's defaults to *not* fetching remote images in HTML email.

It could be a useful feature if Mail_mime could optionally search a HTML part for any http:// assets referenced, fetch them by HTTP, attach them to the message and rewrite the HTML part.

Mail_Mime: Bug 13467 [Assigned] Wrong PHP Version listed in dependencies

cipri at php dot net — 2008-03-22T10:57:49+00:00

Mail_Mime Bug
Reported by cipri
2008-03-22T10:57:17+00:00
PHP: Irrelevant OS: Irrelevant Package Version: 1.5.2

Description:
------------
The PEAR website and the package.xml list different required PHP versions. Also since Mail_Mime depends on other packages, we need to also look at their requirements.

Mail_Mime: Bug 13444 [Open] problem in multipart mail with txt, html and images

smailbox2005-mac at yahoo dot it — 2008-07-06T04:54:36+00:00

Mail_Mime Bug
Reported by sbaldiss
2008-03-20T06:43:52+00:00
PHP: 4.3.4 OS: irrilevant Package Version: 1.5.2

Description:
------------
I have a problem like bug #9725...
Sending a mail with txt part, html part and images generate a email with only html part visible (mail client Apple Mail)
the structure of generated mail is:

Content-Type: multipart/related;
   Content-Type: multipart/alternative;
       text version
       html version
   images

I think that the correct order is:
Content-Type: multipart/alternative;
   txt version
   Content-Type: multipart/related;
       html version
       images

I suggest to correct the mime.php at line number 706 with this code:
case $html AND !$attachments AND $html_images:
          if (isset($this->_txtbody)) {
		$message =& $this->_addAlternativePart($null);
                $this->_addTextPart($message, $this->_txtbody);
		
		$ht =& $this->_addRelatedPart($message);
                $this->_addHtmlPart($ht);
		
		for ($i = 0; $i < count($this->_html_images); $i++) {
			$this->_addHtmlImagePart($ht, $this->_html_images[$i]);
		    }
            } else {
		$message =& $this->_addRelatedPart($null);
                $this->_addHtmlPart($message);
		
		for ($i = 0; $i < count($this->_html_images); $i++) {
			$this->_addHtmlImagePart($message, $this->_html_images[$i]);
		    }
            }
            break;

Test script:
---------------
$crlf = "\n";
require_once('Mail/mime.php');
require_once('Mail.php');
$mime = new Mail_mime($crlf);
$hdrs = array('Subject'=>'title', 'From'=>'email@example.com');

$mime->setTxtBody('hello world');
$mime->setHTMLBody('');
$mime->addHTMLImage('hello.jpg', 'image/jpeg', 'hello.jpg');

$body = $mime->get();
$hdrs = $mime->headers($hdrs, TRUE);

Expected result:
----------------
A email with the structure:
Content-Type: multipart/alternative;
   txt version
   Content-Type: multipart/related;
       html version
       images

Actual result:
--------------
A email with structure:
Content-Type: multipart/related;
   Content-Type: multipart/alternative;
       text version
       html version
   images

Mail_Mime: Bug 13032 [Open] Incorrect Boundary For Multi Par w/Attchment

derek at a--i--m dot com — 2008-01-31T18:46:11+00:00

Mail_Mime Bug
Reported by aimitservices
2008-01-31T18:46:11+00:00
PHP: 5.2.5 OS: Gentoo Linux Package Version: 1.5.2

Description:
------------
When creating a multi part email message with HTML and Text alternative, with an attachment.  The mimePart.php file is creating the same boundary for the multi part/alternative and the attachment boundary.  This causes most web mail clients to not display, or allow the attachment to be downloaded.

I could not find any direct references to this bug, so I apologize if this is a duplicate.

Test script:
---------------
	$mime = new Mail_mime("\r\n");
	
	$mime->setHTMLBody($htmlMsg);

	
	$mime->setTXTBody($txtMsg);

$mime->addAttachment($fileName.".pdf", "application/pdf", "CompletionCertificate.pdf", true, 'base64', 'inline');

$msg = $mime->get();
$hdr = $mime->headers(....);

$mailer = MAIL::factory("mail");

$mailer->send($to, $hdr, $msg);

Expected result:
----------------
The message should display in HMTL or Text depending on the users mail client and preference, and should allow the user to download the attachment.  What happens in most web mail clients (stand alones such as Thunderbird, seem to work fine) is both the text and html are displayed and the attachment cannot be downloaded.

Actual result:
--------------
Not sure if this is the right box to put this , but.  
I actually edited the mimePart.php file and got the boundaries to create as expected.  On line 243 there is this line:
srand((double)microtime()*1000000);

This was causing the random boundary to be the same.  As of PHP 4.2, srand is no longer needed.  I would suggest adding version check line and only calling srand if < 4.2.

In my case, I just commented the line out, and my emails started to work as expected.

Mail_Mime: Bug 12914 [Open] PHP5 doesn't accept subjects containing \n in Function mail()

joliver at gmx dot at — 2008-01-15T21:03:37+00:00

Mail_Mime Bug
Reported by joliver
2008-01-15T21:03:37+00:00
PHP: 5.2.0 OS:  Package Version: 1.5.2

Description:
------------
PHP5 doesn't accept subjects containing \n in Function mail() any more.

"Subject of the email to be sent. Caution: This must not contain any newline characters, or the mail may not be sent properly."

However Mail_Mime splits long subjects (especially with encoded special characters the subects becomes longer than 75 characters very soon).

Result: no mail is sent at all.

Your comment in mime.php:

//determine the maximum length of such strings.
//75 is the value specified in the RFC.

As far as i've seen that's only a suggestion in RFC. Longer lines in mailheaders are perfectly valid, too. So please provide an option to turn off linebreaks in subjects.

It seems that subjects containing \r\n are still accepted by mail() in PHP5. However postfix strictly requires \n

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447074

Mail_Mime: Bug 12716 [Open] Invalid Content-Transfer-Encdoing on multipart messages

joel at panacea dot null dot org — 2007-12-18T00:26:22+00:00

Mail_Mime Bug
Reported by jjr
2007-12-18T00:26:22+00:00
PHP: Irrelevant OS: UNIX Package Version: 1.5.2

Description:
------------
An email generated by Mail_Mime had the following headers.

...
MIME-Version: 1.0
From: 
Content-Type: multipart/alternative;
        boundary="=_90be54e8dab1de0e2d340c1331fbc037"
Content-Transfer-Encoding: quoted-printable
...

According to
http://tools.ietf.org/html/rfc2045#section-6.4
this is in error. From the RFC:
   Certain Content-Transfer-Encoding values may only be 
used on certain
   media types.  In particular, it is EXPRESSLY FORBIDDEN 
to use any
   encodings other than "7bit", "8bit", or "binary" with 
any composite
   media type, i.e. one that recursively includes other 
Content-Type
   fields.  Currently the only composite media types 
are "multipart" and
   "message".  All encodings that are desired for bodies 
of type
   multipart or message must be done at the innermost 
level, by encoding
   the actual body that needs to be encoded.


Please include
francois@getup.org.au
in followups since while I noticed the problem, Francois 
is managing the system.

Mail_Mime: Bug 12628 [Open] Extra newline causes invalid Mime, breaks GMail

ceo at l-i-e dot com — 2008-05-01T09:46:46+00:00

Mail_Mime Bug
Reported by richardlynch
2007-12-06T11:09:19+00:00
PHP: 4.4.7 OS: Gentoo Package Version: 1.5.2

Description:
------------
An extra newline in the main "Content-type:" header right before the boundary= bit makes for invalid MIME according to this Mime Lint tool:
http://www.apps.ietf.org/msglint.html

Gmail fails to display the message and shoves all the content into an "noname" attachment.

Gmail *hates* extra newlines and *hates* \r\n in the headers :-(

A sample message output is provided in "Test script:"

The actual PHP code is pretty much lifted verbatim from the example on php.net so I won't bore you with it.


Test script:
---------------
Delivered-To: richardlynchchicago@gmail.com
Received: by 10.142.48.18 with SMTP id v18cs64351wfv;
        Thu, 6 Dec 2007 07:01:10 -0800 (PST)
Received: by 10.100.214.15 with SMTP id m15mr6875501ang.1196953270369;
        Thu, 06 Dec 2007 07:01:10 -0800 (PST)
Return-Path: 
Received: from mail.complaints.com ([74.201.1.7])
        by mx.google.com with ESMTP id 36si556094nzk.2007.12.06.07.01.04;
        Thu, 06 Dec 2007 07:01:10 -0800 (PST)
Received-SPF: fail (google.com: domain of sagacitydev@mail.complaints.com does not designate 74.201.1.7 as permitted sender) client-ip=74.201.1.7;
Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of sagacitydev@mail.complaints.com does not designate 74.201.1.7 as permitted sender) smtp.mail=sagacitydev@mail.complaints.com
Date: Thu, 06 Dec 2007 07:01:08 -0800 (PST)
Message-Id: <47580eb4.240b240a.3257.ffffb848SMTPIN_ADDED@mx.google.com>
Received: by mail.complaints.com (Postfix, from userid 1001)
	id 76F084AC25C; Thu,  6 Dec 2007 09:01:05 -0600 (CST)
To: "Richard Lynch" 
Subject: Re: Test Complaint
MIME-Version: 1.0
From: "Complaints.com" 
Reply-to: "Complaints.com" 
Content-Type: multipart/alternative;

	boundary="=_9748ed5ba1974422fcf5f37c5b12b7d0"
Message-Id: <20071206150105.76F084AC25C@mail.complaints.com>
Date: Thu,  6 Dec 2007 09:01:05 -0600 (CST)


--=_9748ed5ba1974422fcf5f37c5b12b7d0

Content-Transfer-Encoding: 7bit

Content-Type: text/plain; charset="ISO-8859-1"




Dear Richard Lynch;

Thank you for emailing us your Complaint.

You must visit this URL to finish:
https://post-dev.complaints.com/manage.php/9613e6684e4fa50d3b3b183ba8e65111

By emailing your message to Complaints.com you agree to the Terms/Privacy of Complaints.com
http://www-dev.complaints.com/terms_privacy.htm

-- 
Complaints.com - consumers in control

--=_9748ed5ba1974422fcf5f37c5b12b7d0

Content-Transfer-Encoding: quoted-printable

Content-Type: text/html; charset="ISO-8859-1"






Dear Richard Lynch;

Thank you for emailing us your Complaint.

You must visit this URL to finish:


https://post-dev.complaints.com/manage.php/9613e6684e4fa50d3b3=

b183ba8e65111



By emailing your message to Complaints.com you agree to the Terms/Privac=

y of Complaints.com


http://www-dev.=

complaints.com/terms_privacy.htm






--=20

Complaints.com - consumers in control

--=_9748ed5ba1974422fcf5f37c5b12b7d0--

Expected result:
----------------
I'd like to see that extra blank line before the boundary= in the headers gone so that the message is compliant, assuming the Lint tool is correct.

When I take it out, the Lint tool is much happier.

More importantly, I just want GMail users to be able to actually read the messages Mail_Mime generates.

Right now, I can't really use Mail_Mime because the boss uses gmail, so he goes to test the system, and kablooey. :-(

I had hoped this was all fixed in 1.4.0 as discussed in the last two notes of this bug report (which is two separate issues):
http://pear.php.net/bugs/bug.php?id=30

But it would seem that either an extra \r\n has crept back in, or there's just one too many \n in there, and it's yet another separate newline issue that freaks out the very brittle Gmail.

YOU ROCK!!!

PS
I've asked GMail support to lighten up and accept the not-quite-valid Mime, but I don't really expect that to yield results.

Mail_Mime: Bug 12551 [Open] dots on their own line sometimes not encoded

fsteen at premierit dot com — 2007-11-30T07:21:54+00:00

Mail_Mime Bug
Reported by frasersteen
2007-11-29T10:37:40+00:00
PHP: 5.2.3 OS: Linux Package Version: 1.5.2

Description:
------------
When a message is formatted in such a way that it creates a single line with a ".", this signals end of message and truncates it.

Whem trying to send batches of emails this prevents more than a single truncated email to leave.

Test script:
---------------
From email body:
>>
....positive result=
.
Women shown to by....
<<

Mail_Mime: Bug 12466 [Open] wrong text_encoding or text_charset in get()

carsten_sttgt at gmx dot de — 2007-11-17T04:25:47+00:00

Mail_Mime Bug
Reported by cwiedmann
2007-11-17T04:25:47+00:00
PHP: 5.2.4 OS: Irrelevant Package Version: CVS

Description:
------------
In the $build_params for Mail_Mime::get():
  text_encoding = Default is 7bit
  text_charset  = Default is iso-8859-1
That's not possible, because ISO-8859-1 is a 8bit encoding.

At the moment I have no patch, because I need a direction to do this:
- setting text_encoding to "8bit"
- setting text_encoding to "quoted-printable"
- setting text_charset to "US-ASCII"

An additional feature:
In case of setting text_charset to an other value then "US-ASCII", the class should also be smart enough, to change the text_encoding from "7bit" to "8bit" or "quoted-printable" automatically (if text_encoding is not set).

Regards,
Carsten

Mail_Mime: Bug 12456 [Assigned] srand() causing complication on hardware with broken clock

jonlogic at gmail dot com — 2009-03-23T17:00:08+00:00

Mail_Mime Bug
Reported by jonl
2007-11-15T14:44:35+00:00
PHP: 5.2.4 OS: Linux 2.6 Package Version: 1.5.2

Description:
------------
Mail/mimePart.php, function encode():

srand((double)microtime()*1000000);
$boundary = '=_' . md5(rand() . microtime());

My development server has a slow/stale clock due a broken SMI implementation (see http://lists.us.dell.com/pipermail/linux-poweredge/2004-July/015554.html) so microtime() often returns the same value across multiple microsecond.

Therefore, the "randomness" of $boundary depends on rand() to return different values during successive iterations of encode().

However, rand() is returning the same value (probably due to this same hardware interrupt problem affecting microtime())

This is causing a problem with multiple encodings within the same message.  For example, a message containing plaintext, HTML and a file attachment should have 2 different boundary strings like this:
"
MIME-Version: 1.0
From: MY_EMAIL_ADDRESS
Subject: Test message: Thu, 15 Nov 07 14:31:10 -0500
Content-Type: multipart/mixed;
        boundary="=_fb952fbfe782713c888ca0ab55c41f19"


--=_fb952fbfe782713c888ca0ab55c41f19
Content-Type: multipart/alternative;
        boundary="=_72d79573e8e611e59014b59ee526ad5f"


--=_72d79573e8e611e59014b59ee526ad5f
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-8859-1"

This is the plaintext body.
--=_72d79573e8e611e59014b59ee526ad5f
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="ISO-8859-1"

This is the HTML body.
--=_72d79573e8e611e59014b59ee526ad5f--

--=_fb952fbfe782713c888ca0ab55c41f19
Content-Transfer-Encoding: base64
Content-Type: text/plain;
 name="TestFile1.txt";
Content-Disposition: attachment;
 filename="TestFile1.txt";

Q29udGVudHMgb2YgVGVzdEZpbGUxLnR4dAo=
--=_fb952fbfe782713c888ca0ab55c41f19--
"

But (intermittently) the message has the same boundary strings for both levels of encoding like this:
"
MIME-Version: 1.0
From: MY_EMAIL_ADDRESS
Subject: Test message: Thu, 15 Nov 07 14:31:12 -0500
Content-Type: multipart/mixed;
        boundary="=_25b8085bab879c9b936de3ad92f5bee3"


--=_25b8085bab879c9b936de3ad92f5bee3
Content-Type: multipart/alternative;
        boundary="=_25b8085bab879c9b936de3ad92f5bee3"


--=_25b8085bab879c9b936de3ad92f5bee3--

--=_25b8085bab879c9b936de3ad92f5bee3
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-8859-1"

This is the plaintext body.
--=_25b8085bab879c9b936de3ad92f5bee3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="ISO-8859-1"

This is the HTML body.
--=_25b8085bab879c9b936de3ad92f5bee3--
"

Removing the call to srand() (in the line prior) stops this intermittent and problematic behavior:
//srand((double)microtime()*1000000);

And the PHP manual says that since PHP 4.2.0, srand() no longer needs to be called prior to rand() as rand() now automatically seeds the generator.

Mail_Mime: Bug 12429 [Open] Attachments with long files names are causing difficulty

2007-11-19T05:44:59+00:00

Mail_Mime Bug
Reported by erdqwjw
2007-11-12T08:33:58+00:00
PHP: 5.2.2 OS: Apple OSX 10.4.10 Package Version: 1.5.2

Description:
------------
Hi,
Â Â 
Attachments with long files names are causing difficulty 
with a wide range of receiving MUAs.
Â 
// $fname = $caseDir . "/" . $shortfname;
// $dotpos = strrpos($realname, ".");
// $ext = strtolower(substr($realname,$dotpos+1));
Â 
// $mime->addAttachment($fname,$mime_types[$ext],$realname);
Â 
It seems that because I am using base64 encoding mail_mime 
is deciding to limit the whole of the mime part's data to 64 
chars per line, incuding the mime part's header. Header 
attributes are also separated by lines.
Â 
This causes problems with someÂ MUAs which loose track of the 
attachment's file extension, and (even though it has a mime-
type) decide they don't know what to do with it and default 
to text.
Â 
Here is a Mail_Mime 1.5.2 excerpt:
Â 
--=_ca502c3561ab4710bb5472d957a3e454
Content-Transfer-Encoding: base64
Content-Type: application/pdf;
name*0="UH and xxxxx Group Plc Mutually Disclosing XUHO 0609 
09 11 2007."
name*1="pdf";
Content-Disposition: attachment;
filename*0="UH and xxxxx Group Plc Mutually Disclosing XUHO 
0609 09 11 2"
filename*1="007.pdf";
Â 
JVBERi0xLjIKNCAwIG9iago8PC9UeXBlIC9QYWdlCi9QYXJlbnQgMyAwIFIK
L1Jlc291cmNlczw8
Â 
Â 
The Apple mail client does something similar:
Â 
--Apple-Mail-1--340428939
Content-Transfer-Encoding: base64
Content-Type: application/pdf;
x-unix-mode=0644;
name=UH and xxxxx Group Plc Mutually Disclosing XUHO 0609 09 
11 2007.pdf
Content-Disposition: inline;
filename*0="UH and xxxxx Group Plc Mutually Disclosing XUHO 
0609 09 11 2007.";
filename*1=pdf
Â 
JVBERi0xLjIKNCAwIG9iago8PC9UeXBlIC9QYWdlCi9QYXJlbnQgMyAwIFIK
L1Jlc291cmNlczw8
Â 
However, Eudora on Windows XP does this:
Â 
--=====================_-1519325078==_
Content-Type: application/octet-stream; name="UH and xxxxx 
Group Plc Mutually Disclosing XUHO 0609 09 11 2007.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="UH and xxxxx 
Group Plc Mutually Disclosing XUHO 0609 09 11 2007.pdf"
Â 
JVBERi0xLjIKNCAwIG9iago8PC9UeXBlIC9QYWdlCi9QYXJlbnQgMyAwIFIK
L1Jlc291cmNlczw8
Â 
In this case the mime part's header lines are not broken at 
64 chars. All the header attributes appear on one line. The 
filename appears unbroken, and there don't appear to be any 
problems with the receiving MUAs.
Â 
Examples in RFC2046 - whilst not dealing with long filenames 
- seem to adopt this way of doing things. Whilst RFC2047 
talks about a 75 char limit on 'encoded-words' in headers I 
am not sure these are encoded words. 
Â 
Not sure if this is a bug, but it seemsÂ MUAs have difficulty 
dealing with multiline headers and/or split attribute 
values.
Â 
Are their any plans to address this issue?
------------------------------------------------
Â 
BillÂ Worthington
Â 
Dr. W J Worthington
STRI - the Science and Technology Research Institute
University of Hertfordshire
PO Box 109, College LaneÂ 
Hatfield
Hertfordshire
AL10 9AB
T: +44 (0)1707 286077
F: +44 (0)1707 286079
E: mailto:W.J.Worthington@herts.ac.uk
W:Â www.i10.org.uk/bill_worthington

Mail_Mime: Feature/Change Request 12411 [Open] Support RFC 2047 standard for non-ascii characters as attachment filename.

bmdevelopment at gmail dot com — 2007-11-09T03:16:44+00:00

Mail_Mime Feature/Change Request
Reported by bmdevelopment
2007-11-09T02:58:32+00:00
PHP: 5.2.4 OS: FreeBSD 6.2-RELEASE #0 Package Version: 1.5.2

Description:
------------
Currently when you attach a filename with non-ascii characters, such as Japanese, the name of the file itself is encoded according to the format in RFC 2231. This is the newer preferred format and works with email clients such as Thunderbird. However, email clients, such as Outlook and Outlook Express, do not support the newer RFC 2231, but only the older, deprecated RFC 2047.

Due to most clients using Outlook and Express, I had to add this support so that they were able to receive attachments with Japanese filenames.

I realize that RFC 2047 is old and basically no good, but I could not rely on MS to update Outlook anytime soon. So, I am submitting this patch to add RFC 2047 support. Hopefully, it can be used and reviewed by others.

The change basically adds another parameter to the addAttachment function that should either be '2047' or '2231' (default). This parameter is kept and eventually passed through to the _buildHeaderParam function in mimePart.php. Here, if the standard is 2047 I encode the filename accordingly. I've taken most of the code for converting to 2047 from _encodeHeaders function in mime.php and made slight modifications.

I think that is about it. This patch is working fine for me now. Please feel free to use, correct and improve it and add it to the code base if necessary. 



Test script:
---------------
HTML version of email. HTML ÆoÂ[ÆWÆâ¡Æâ âÃºâ{ÅÃª';
$file = 'test,test,test,test,test,test,ÆeÆXÆg,âÃâÂ·âÃ,âÃºâ{ÅÃª';
$crlf = "\n";
$hdrs = array( 'From' => 'test@test.com', 'Subject' => 'ÆeÆXÆg â°ÃâÃ¨');

$mime = new Mail_mime($crlf);

$mime->setTXTBody($text);
$mime->setHTMLBody($html);
$mime->addAttachment($file, 'text/plain', 'âYâ¢Â2047.csv', false, 'base64', 'attachment', 'UTF-8', '', '', '2047');
$mime->addAttachment($file, 'text/plain', 'âYâ¢Â2231.csv', false, 'base64', 'attachment', 'UTF-8', '', '', '2231');
$mime->addAttachment($file, 'text/plain', 'âYâ¢Â____.csv', false, 'base64', 'attachment', 'UTF-8');

$params['head_encoding'] = 'base64';
$params['text_encoding'] = 'base64';
$params['html_encoding'] = 'base64';
$params['head_charset'] = 'UTF-8';
$params['text_charset'] = 'UTF-8';
$params['html_charset'] = 'UTF-8';
//do not ever try to call these lines in reverse order
$body = $mime->get($params);
$hdrs = $mime->headers($hdrs);

$mail =& Mail::factory('mail');
$mail->send('ktanaka@bluemetrix.com', $hdrs, $body);
?>


Expected result:
----------------
The test script contains Japanese characters inline and is encoded in UTF-8. Hopefully, the characters are not destroyed when submitting.

Using the test, you can send yourself a mail with attachments having Japanese filenames - one filename using 2047 and two using 2231. As you will notice, Outlook and Outlook Express will not correctly display the filenames in the 2231 format, which is currently the only format supported in Mail_mime.

Mail_Mime: Bug 12216 [Verified] Incorrect Mail_mime::headers() behaviour (russian text, utf8)

kg at pingwincheg dot net — 2009-08-25T07:05:41+00:00

Mail_Mime Bug
Reported by chewie
2007-10-10T06:36:31+00:00
PHP: 5.2.4 OS: linux Package Version: 1.5.2

Description:
------------
Hello, 
I have an script which sends emails with Mail/mime.php.

I need to send mails with russian text and russian subject in utf8.
When I am trying to pass array with headers (it contains subject), in the result I am getting empty value for subject,
but when I am working with english text in utf8, it shows value normally.

Test script:
---------------
 'Регистрация'
);

var_dump($hdrs);

$hdrs = $mimeObject->headers($hdrs);

var_dump($hdrs);

?>


Expected result:
----------------
array
  'MIME-Version' => string '1.0' 
  'Subject' => string 'Регистрация'
  'Content-Transfer-Encoding' => string 'quoted-printable' 
  'Content-Type' => string 'text/html; charset="utf8"' 


Actual result:
--------------
array
  'MIME-Version' => string '1.0' 
  'Subject' => string '' 
  'Content-Transfer-Encoding' => string 'quoted-printable' 
  'Content-Type' => string 'text/html; charset="utf8"'

Mail_Mime: Bug 11238 [Analyzed] From address encoding

lasse at novicell dot dk — 2008-12-27T13:05:06+00:00

Mail_Mime Bug
Reported by cederstrom
2007-06-06T08:34:00+00:00
PHP: 5.2.1 OS: FreeBSD Package Version: 1.4.0

Description:
------------
When the From name contain a danish char Ã¦,Ã¸ or Ã¥, then the sending fails with the error "Validation failed for: =?ISO-8859-1?Q?Test=F..."

If I change the 'From'=>"TestÃ¸ TestÃ¥ " into 'From'=>"Test Test " it works fine.

Also if I change it into 'From'=>"TestÃ¸ TestÃ¥", and add the "" after the $mime->headers(..) line it also works fine.

The error was not in version 1.36.

Test script:
---------------
 "TestÃ¸ TestÃ¥ ",	'Subject' => "Example");
	$mime = new Mail_mime($crlf);
	$mime->setTXTBody("Very short email!");

	//do not ever try to call these lines in reverse order
	$body = $mime->get();
	$hdrs = $mime->headers($hdrs);

	$mail =& Mail::factory('mail');
	$err = $mail->send("lasse@novicell.dk", $hdrs, $body);
	print_r($err);
?>


Expected result:
----------------
The mail to be sent.

Actual result:
--------------
PEAR_Error Object - containing a validation error.

Mail_Mime: Feature/Change Request 10884 [Assigned] Provide easy way to set build params

cipri at php dot net — 2007-06-21T14:30:22+00:00

Mail_Mime Feature/Change Request
Reported by cipri
2007-04-29T07:06:37+00:00
PHP: 5.1.6 OS: Fedora Core 6 Package Version: 1.4.0RC4

Description:
------------
Mail_Mime should provide an easy way to set the build parameters.

Mail_Mime: Feature/Change Request 10438 [Assigned] function for encoding of given string

uhlar at fantomas dot sk — 2007-05-25T17:19:37+00:00

Mail_Mime Feature/Change Request
Reported by fantomas
2007-03-21T05:15:03+00:00
PHP: 4.4.4 OS: any Package Version: 1.3.1

Description:
------------
Hello, it would be nice to provide a simple function that would mime-encoded string from provided string, charset and encoding.
There are many PHP scripts which already do their job, but they send mails with invalid MIME headers, and rewriting them to create mail using object interface of this package would be  too much work.
Providing simple function to encode provided string would help  coders very much to make their mail RFC compliant and not tagged as spam due to invalid header encoding.
The function could look like

Mime_Encode(string[, encoding[, charset]])

where encoding would be auto (smallest result) quoted-printable or base64, and charset could be detected from current locale settings.

Mail_Mime: Feature/Change Request 3729 [Verified] Support for signed messages

maarten at xolphin dot nl — 2008-03-22T22:15:52+00:00

Mail_Mime Feature/Change Request
Reported by xolphin
2005-03-07T07:17:53+00:00
PHP: Irrelevant OS: Irrelevant Package Version: 

Description:
------------
I added support for signed messages using openssl_pkcs7_sign. Unfortunatly you have to use temporary files when working with openssl_pkcs7_sign. If anybody else has a better solution I would like to hear it.

An encryption routine can be made the same way like this, if you need any help, please let me know. I don't know if this is the right package for encryption and signing of messages, but I thought it would be the most logical.

Reproduce code:
---------------
Changed code:
  http://www.xolphin.net/mime.diff

Example use:
($Customer and $PDFDocument are a DataObjects)

$header['To'] = $Customer->Email;
$header['From'] = 'test@example.com'; 
$header['Subject'] = 'Signed message';

$mime = new Mail_mime("\n");
$mime->setTXTBody($Customer->Message);
do
{
  $mime->addAttachment($PDFDocument->PDF, 'application/pdf', 'Document ' . $PDFDocument->DocumentName, 'base64' );  
}
while ($PDFDocument->Fetch());

$sign_directory = '/var/www/admin/certificates/mail';

if ($filename_signed = $mime->getSignedMessage(
   $header, 'certificate.pem', 'instantssl.pem',
   $sign_directory, 'password'))
  {
    exec(ini_get('sendmail_path') . ' < ' . $filename_signed);
  }