Giter Site home page Giter Site logo

php-mime-mail-parser's People

Watchers

 avatar

php-mime-mail-parser's Issues

Fails to decode content encoding when "content-transfer-encoding" header does not contain value in all lower case

What steps will reproduce the problem?
1. Take an existing stored email in a file which is encoded in quoted-printable 
or base64 and parses correctly and find the "content-transfer-encoding" header.
2. Modify its value from "quoted-printable" or "base64" to "Quoted-Printable" 
or "Base64"
3. Parse the mail and display the part which is encoded

What is the expected output? What do you see instead?
You should see property decoded data. What you see instead is data still in 
it's quoted-printable or base64 encoding

What version of the product are you using? On what operating system?
MimeMailParser.class.php r16
PHP 5.3.2-1ubuntu4.5 with Suhosin-Patch (cli) (built: Sep 17 2010 13:49:46) 
Ubuntu 10.04.1 LTS
Linux 2.6.32-25-generic

Please provide any additional information below.
The RFC states that values for content-transfer-encoding are case insensitive : 
http://tools.ietf.org/html/rfc2045#section-6.1

I'm attaching a patch which fixes this problem by 'strtolower' the value before 
comparison to account for case insensitivity. It updated the private "decode" 
method. 

Original issue reported on code.google.com by gene.wood.temp on 21 Oct 2010 at 9:49

Attachments:

getAttachemnt reads the inline base64 decoded messages as attachment

What steps will reproduce the problem?
1. Send a email with text as base64 encode
2. try running get attachment
3.

What is the expected output? What do you see instead?
Each base64 segment is taken as attachment

What version of the product are you using? On what operating system?
r22

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 20 Mar 2012 at 7:38

Will not return email address when in format "name <user@domain>".

What steps will reproduce the problem?
Files are included to reproduce the error.

What is the expected output? What do you see instead?
I would expect the email address, or maybe an array with the name and email
address. Instead, it just returns the name.

What version of the product are you using? On what operating system?
Latest from trunk, (r15).

Please provide any additional information below.
None

Original issue reported on code.google.com by jbog91 on 31 Oct 2009 at 4:08

Attachments:

Wrong (encoded) attachment file name for at least windows-1251 encoding

What steps will reproduce the problem?
1. Try to save attachments (like explained here) 
http://code.google.com/p/php-mime-mail-parser/ form the attached file
2. Filenames extracted by the $Parser->getAttachments() are encoded like
=?windows-1251?B?0e+z4uC6IODt8eDs4ev8IF9fxO2z7/D/7e736uBfXyAo9fPk7ubts+kg?= 
=?windows-1251?B?6uXws+Lt6Oogwi7K7vH+6ikuLkpQRw==?=

3. To convert them to real filenames I used such a trick
After the code in the example:
    $filename = $attachment->filename;
I added:
    $filenamearr = imap_mime_header_decode($filename);
    $title = '';
    foreach ($filenamearr as $element) {
        $title .= iconv($element->charset,'UTF-8',$element->text);
    }
    $filename = $title;

This saves the filenames as expected.


What version of the product are you using? 
MimeMailParser.class.php    11.6 KB r21 Oct 22, 2010    eugene.emmett.wood
attachment.class.php    2.9 KB  r17 Aug 12, 2010    bucabay
Please provide any additional information below.

On what operating system?
Opensuse 12.1 (Linux)

Original issue reported on code.google.com by [email protected] on 25 Jan 2012 at 5:55

Attachments:

Empty Attachments when MimeMailParser.class located outside public_html

What steps will reproduce the problem?
1. Pipe your email with the script that parses it and saves the attachments to 
specific directory. The script is outside public_html and attachments are also 
saved outside public_html
2. Send email
3. Go to the directory and you'll see the empty attachments

What is the expected output? What do you see instead?
Files with their content. Empty Files

What version of the product are you using? On what operating system?
The newer version on Redhad

Please provide any additional information below.
It saves files alright when I have the class in public_html

Original issue reported on code.google.com by [email protected] on 16 May 2013 at 3:31

outlook msg attachments not saved

What steps will reproduce the problem?
1. Make new mail in Outlook 2007
2. Drag one are more read messages into the new mail body
3. send to pipe

What is the expected output? What do you see instead?
I expected the MimeMailParser to save the attachments(.msg) the same way as 
other attachments

What version of the product are you using? On what operating system?
@version $Id$ 
on linux server

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 18 Mar 2013 at 3:19

Plain text attachments have random string added to the end

1. Send txt/csv (possibly other files are also affected)

What is the expected output? What do you see instead?
Random string is added to the last line, all look similar to this: 
´qýôï†ø�Î\çvÝÓ‡vq¦�Ù


Using r25 on ubuntu 12.10, php5.3


Original issue reported on code.google.com by [email protected] on 8 Jan 2013 at 6:06

attachment.class.php: __get() cannot be private

What steps will reproduce the problem?
1.  Read attachment streams.

What is the expected output? What do you see instead?
I receive an error regarding a completely unrelated class.

What version of the product are you using? On what operating system?
R16, Fedora 10, PHP 5.3.2

Please provide any additional information below.
The problem is that in attachment.class.php, line 126, __get() is private.
For some reason this doesn't produce a parsing error, even though __get() 
cannot be private or static.

Fix:  s/private function __get/public function get/ in attachment.class.php

Original issue reported on code.google.com by [email protected] on 3 Aug 2010 at 5:04

Inline Pictures Not Retrievable

If someone pastes a picture into an email and sends it there is no way to
access it.  $Parser->getAttachments() returns null. 
$Parser->getMessageBody('html') or 'text' returns everything without the
picture. Is this a bug that is known or being worked on?

Thanks!

Original issue reported on code.google.com by [email protected] on 21 Mar 2010 at 2:19

Patch for Error in MimeMailParser.class.php with quoted-printable encoding

hello,

>What steps will reproduce the problem?
Read an EML file with content-transfer-encoding = quoted-printable


>What is the expected output? What do you see instead?
when you get the attachment ($attachment->getContent()) you are getting 
additional chars.
The class is reading too much chars.


>What version of the product are you using? On what operating system?
Using r28/r17(attachment) on Linux.


>Please provide any additional information below.

there is a mistake with the comparison (< vs >).
i think with other encodings you don't have problem, because when decode them 
the additional chars are getting cutted, but not with quoted-printable.


can you confirm?


mfg Johannes

Original issue reported on code.google.com by [email protected] on 17 Apr 2014 at 4:48

Attachments:

getAttachement not working with email sent using thunderbird.

What steps will reproduce the problem?
I tried to parse the email sent through thunderbird 2.0.0.23 but i'm not
able to get the attachments out of that email. i can read other headers
through this script but getAttachment method is returning a empty array.
Please help me. I;ve attached a test email file along with the issue.

Original issue reported on code.google.com by [email protected] on 25 Oct 2009 at 2:50

Attachments:

Attachment name is not searched correctly

What steps will reproduce the problem?
email of the following format, excerpt:

Content-Type: application/vnd.openxmlformats...bla-bla;
    name="=?UTF-8?B?MTQw...bla-bla=?="
Content-Disposition: attachment
Content-Transfer-Encoding: base64

Here the file content starts...


What is the expected output? What do you see instead?
Expected output is the actual file name which is given on line #2. There is a 
random filename is coming out instead being generated by:

public function getAttachments() {
...
    $part['disposition-filename'] = md5(uniqid());
...


}

What version of the product are you using? On what operating system?
r27, Linux Ubuntu, PHP 5

Please provide any additional information below.
The file name do exists in the file just one line above the script is looking 
for.

Original issue reported on code.google.com by [email protected] on 6 Mar 2014 at 3:58

Error shown : Undefined index: content-transfer-encoding in /path/to/php-mime-mail-parser/MimeMailParser.class.php on line 193

What steps will reproduce the problem?
1. Set php error reporting to E_ALL ( error_reporting(E_ALL); )
2. Take an email with no content encoding defined (e.g. it has no 
'content-transfer-encoding' header)
3. Parse the email and display some part of it

What is the expected output? What do you see instead?
You would expect to see merely the part that you've displayed.
Instead, in addition to the part displayed is an error message like :

PHP Notice:  Undefined index: content-transfer-encoding in 
/path/to/php-mime-mail-parser/MimeMailParser.class.php on line 193

What version of the product are you using? On what operating system?
r16
PHP 5.3.2-1ubuntu4.5 with Suhosin-Patch (cli) (built: Sep 17 2010 13:49:46) 
Ubuntu 10.04.1 LTS
Linux 2.6.32-25-generic

Please provide any additional information below.
I've attached a patch which fixes this problem by doing an "array_key_exists" 
check before assuming that there is a 'content-transfer-encoding' header. In 
the absence of the header it passes an empty string to the private "decode" 
method so that no decoding occurs. 

Original issue reported on code.google.com by gene.wood.temp on 21 Oct 2010 at 9:58

Attachments:

Bounce back error keeps coming back

I keep getting the same error on the bounce back e-mail:

The following text was generated during the delivery attempt:

<br />
<b>Warning</b>:  Supplied argument is not a valid resource handle in 
<b>/home3/evpmpt/public_html/si/_mailingList/MimeMailParser.class.php</b> on 
line <b>82</b><br />
<br />
<b>Fatal error</b>:  Call to undefined function  mailparse_msg_create() in 
<b>/home3/evpmpt/public_html/si/_mailingList/MimeMailParser.class.php</b> on 
line <b>99</b><br />

----/----

I have php mailparse extension enable. What should I do?

Original issue reported on code.google.com by [email protected] on 2 Oct 2010 at 10:01

File Name Change

What steps will reproduce the problem?
1.Send any attachment with the same name

What is the expected output? What do you see instead?
The system should change the file name. The system overwrites existing files 
with the same name.  

Please provide any additional information below.
I added the following function to the system to fix the issue. I am still 
learning so the code may not be perfect, but it works great.

public function checkFileName($filename){
    $fullFileName = dirname( __FILE__ ).'/save_dir/'.$filename;
    if(file_exists($fullFileName)){
        $exists='1';$check='';
        $splitFile = explode('.',$filename);
        $count = count($splitFile);
        $counter = $count-1;;
        $piece = $splitFile[$counter];
        $file='';
        for($i=0;$i<$count-1;$i++){
            $file.=$splitFile[$i];
        }
        $i='1';
        while($exists='1'){
            $check = $file.'('.$i.').'.$piece;
            $name=dirname( __FILE__ ).'/save_dir/'.$check;
            if(!file_exists($name)){break;}
            else{$i++;}
        }
        $filename=$check;
    }
    return $filename;
}

Original issue reported on code.google.com by [email protected] on 24 Apr 2013 at 6:02

attachment filename decoding

attachments with mime encoded filename are not decoded.

What steps will reproduce the problem?
1. save an attachment with a decoded filename
2.
3.

What is the expected output? 
obtain the decoded attachment filename

What do you see instead?
the filename of attachment not decoded


What version of the product are you using? On what operating system?
the trunk version, on CENTOS 5.4 with php 5.2.11

Please provide any additional information below.

dump of attachment variable:
array(1) {
  [0]=>
  object(MimeMailParser_attachment)#3 (7) {
    ["filename"]=>
    string(66) "=?Windows-1252?Q?test_filename_test_=80_529=2C24.pdf?="
    ["content_type"]=>
    string(15) "application/pdf"
    ["content:private"]=>
    NULL
    ["extension:private"]=>
    NULL
    ["content_disposition"]=>
    string(10) "attachment"
    ["headers"]=>
    string(1) "J"
    ["stream:private"]=>
    resource(27) of type (stream)
  }
}

Original issue reported on code.google.com by [email protected] on 13 Nov 2010 at 3:57

unable to retrieve text body in presence of text attachment

What steps will reproduce the problem?
1. try to get the text body of email with a text file attached
2.
3.

What is the expected output? 
the text body of email

What do you see instead?
the content of attached file

What version of the product are you using? On what operating system?
trunk, on CENTOS 5.4 with php 5.2.11

Please provide any additional information below.

this occurs because the foreach cycle in getMessageBody() process every text 
part, and if more than one is present the last is returned.
Usually attachments come after the body, so for me a simple break; instruction 
at the end of cycle worked fine.

Original issue reported on code.google.com by [email protected] on 13 Nov 2010 at 4:45

Missing getAttachmentsAsStreams

What steps will reproduce the problem?
1. try running your example2.php on the any version later than r7.

What is the expected output? What do you see instead?
The code appears to be missing that handles attachments by stream, so I
have no idea what its supposed to do.

What version of the product are you using? On what operating system?
The latest version (r11) on RedHat Linux.



Original issue reported on code.google.com by [email protected] on 6 Nov 2009 at 1:55

The problem with base64 encoded text

What steps will reproduce the problem?
Try to parse a message like:
MIME-Version: 1.0
Received: by 10.231.28.9 with HTTP; Wed, 23 Feb 2011 09:23:40 -0800 (PST)
Date: Wed, 23 Feb 2011 22:23:40 +0500
Delivered-To: [email protected]
Message-ID: <[email protected]>
Subject: =?KOI8-R?B?9MXT1A==?=
From: =?KOI8-R?B?6czY0SDrz87P18HMxc7Lzw==?= <[email protected]>
To: [email protected]
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: base64

8NLJ18XJCj4+IMvByyDU2T86CiIiCicnCgouCi4KCi0tIApUaGFuayB5b3UsCklseWEuCg==


What is the expected output? What do you see instead?
Warning: fread() [function.fread]: Length parameter must be greater than 0 in 
/home/***/MimeMailParser.class.php on line 369

Fatal error: Call to private method MimeMailParser::decode() from context '' in 
/home/****.php on line 47

What version of the product are you using? On what operating system?
I guess r22, CentOS

This is an example of the email sent by Google. This particular example can not 
process your class. I think this is due to base64.


Original issue reported on code.google.com by [email protected] on 23 Feb 2011 at 6:28

Attachments are always assumed to be base64 encoded

What steps will reproduce the problem?
1. parse an email with a plain text attachment (like a CSV file, see
example email)
2. get the attachment stream, and echo it out. You get a lot of garbage.

What is the expected output? What do you see instead?
I'd expect the attachment not base64 decoded if the
content-transfer-encoding is not base64. What I see however is the result
of base64_decode'ing a plain text attachment : gookely gook (otherwise
known as garbage).

What version of the product are you using? On what operating system?
Checked out the trunk (revision 12).

To fix it :

Attached is the SVN diff of my changes...
And the email I was working with (modified to not contain sensitive data)
that highlighted this issue.

Note : 
I've only used the MimeMailParser by using the STDIN stream. So there is a
line which I commented because I'm not sure it was the right thing to do.

Original issue reported on code.google.com by [email protected] on 8 Oct 2009 at 6:08

Attachments:

Small attachments are not parsed correctly

What steps will reproduce the problem?
1. A mail with small attachments (< 2028 bytes)

Around line 405 in MimeMailParser.class.php:
if (($written+$write < $len )) {

I believe it should be:
if ($len - $written < $write) {

Original issue reported on code.google.com by [email protected] on 19 Jan 2010 at 7:56

Errors when multiple headers with same name.

What steps will reproduce the problem?
1. $Parser->getHeader('Received')
2. Most emails have several servers that receive the message and add this 
header.
3.

What is the expected output? What do you see instead?
I'd like to see an array of the Received headers. I currently get no output.

What version of the product are you using? On what operating system?
PHP 5.2

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 11 Mar 2011 at 12:19

(eml) with attachments not correct

What steps will reproduce the problem?
-- Parse .eml with attach

What is the expected output? What do you see instead?

-- Attach clean.

What version of the product are you using? On what operating system?

--latest Trunk Version, OS Windows 7

Please provide any additional information below.

attach, eml to parse

Extract XML, but add final line for example

------=_Part_8851775_15979806.1324787433504--

Original issue reported on code.google.com by [email protected] on 6 Jan 2012 at 8:58

Attachments:

Improvements to project

I have shared a customized MimeMailParse project. There are some issues that 
are solved due some changes applied, especially with attachments.

Feel free to check it, and get any code part you find interesting.

You can check it at:
https://github.com/JotaGil/CustomMimeMailParse

Really special tanks by this software, I have found so useful and interesting.

Jose Manuel Gil

Original issue reported on code.google.com by [email protected] on 24 Jul 2013 at 1:31

Call to undefined method MimeMailParser::setStream

I have mailparse and mbstring installed on my PHP5+ installation and yet I 
still cannot get it to work properly.

I get this error:

<br /> <b>Fatal error</b>:  Call to undefined method 
MimeMailParser::setStream() in <b>/home/texts/public_html/email/attach.php</b> 
on line <b>10</b><br />

I am using email piping and this is email.php
#!/usr/bin/php -q
<?php

/**
 * To run this example you need to pass in some input via STDIN
 */

require_once('MimeMailParser.class.php');

$Parser = new MimeMailParser();
$Parser->setStream(STDIN);

$to = $Parser->getHeader('to');
$delivered_to = $Parser->getHeader('delivered-to');
$from = $Parser->getHeader('from');
$subject = $Parser->getHeader('subject');
$text = $Parser->getMessageBody('text');
$html = $Parser->getMessageBody('html');
$attachments = $Parser->getAttachments();

// dump it so we can see
var_dump(
        $to,
        $delivered_to,
        $from,
        $subject,
        $text,
        $html,
        $attachments
);

?>

Original issue reported on code.google.com by [email protected] on 19 Oct 2014 at 4:48

Image Attachments not recognized

What steps will reproduce the problem?
1.Enter email with only image/jpeg attachment(s)
2.Call $Parser->getAttachments()
3.return is empty array

What is the expected output? What do you see instead?
Expect to see an image attachment, see an empty array instead



// the following snippet finds the image attachments

        /**
         * Returns the image attachments
         * @return Array
         */
        public function getImages() {
            $images = array();
            $types = array("image/jpeg");
            foreach($this->parts as $part) {
                $type = $this->getPartContentType($part);
                if(in_array($type, $types)) {
                    $images[] = new MimeMailParser_attachment("image", $type, $this->getAttachmentStream($part));
                }
            }
            return $images;
        }

Original issue reported on code.google.com by [email protected] on 26 Feb 2011 at 6:47

Does not decode headers according to RFC2047

What steps will reproduce the problem?
* Parse a message with a header (i.e. subject line) encoded according to
RFC2047

What is the expected output? What do you see instead?
* Expected output is the decoded subject line
* Instead, the subject line is passed through unencoded, i.e.
=?UTF-8?Q?stuff_A=C3=A5_B=E2=88=AB_C=C3=A7_D=E2=88=82_E?=
=?UTF-8?Q?=C2=B4_R=C2=AE_$=C2=A2?=

What version of the product are you using? On what operating system?
* Revision 15

Please provide any additional information below.
* Attached is a diff of my changes to properly decode the message headers
if they are encoded. The code is mostly copied from Pear's Mail_Mime class.
* This also fixes the issue where the message body is not decoded properly
based on its encoding type
* Also adds a function for retrieving the inline attachments

Original issue reported on code.google.com by aaron.parecki on 20 Mar 2010 at 10:44

Attachments:

Correct syntax for e-mails piped to script?

#!/usr/local/bin/php -q
<?php
// BEGIN MailParser******************************************
require_once('/home/birdymai/resources/library/MimeMailParser.class.php');

$path = 'php://stdin';
$Parser = new MimeMailParser();
$Parser->setStream(fopen($path, 'r'));

$to = $Parser->getHeader('to');
$sender = $Parser->getHeader('from');
$subject = $Parser->getHeader('subject');
$textbody = $Parser->getMessageBody('text');

Original issue reported on code.google.com by [email protected] on 4 Mar 2013 at 4:36

Attachments do not return file names

What steps will reproduce the problem?
1. Retrieve filenames via $attachments = $Parser->getAttachments();
2. or $Parser->getAttachmentsAsStreams();

What is the expected output? What do you see instead?
The file or stream, and the filename
Instead you just get the file, or stream, there is no way to deduce the 
filename or type.



Original issue reported on code.google.com by [email protected] on 2 Aug 2009 at 7:35

Message Body Headers are not accessible. And message body is always assumed to be 7bit encoded.

What steps will reproduce the problem?
1. Parsing an email where the message body has content-transfer-encoding =
quoted-printable. The body is not decoded.

What is the expected output? What do you see instead?
The most common character that is encoded with quoted-printable is the
newline character. It appears as '=20' in a quoted-printable encoded body
part. I would not expect to see this entity when echoing the message body part.

What version of the product are you using? On what operating system?
Latest on trunk. (R14)

Please provide any additional information below.


I have attaced a patch for this issue. The patch automatically decodes the
message body part depending on its encoding type. I have also provided a
public function to retrieve the message body headers.

Original issue reported on code.google.com by [email protected] on 15 Oct 2009 at 12:13

Attachments:

UTF-8 Decoding for disposition-filename

What steps will reproduce the problem?
1. using getAttachments to save attachements
2.
3.

What is the expected output? What do you see instead?
expect output is the correct filename ie: TEST.TXT
what is returned is: =?utf-8?Q?TEST.TXT?= (wich does not save on windows 
o'course)

What version of the product are you using? On what operating system?
Latest version on svn, reproduced on windows xp pro iis 5.1, php 5.2.12 nts

Please provide any additional information below.
i've changed the code in class.MimeMailParser.php in the function 
getAttachments() to check if a UTF-8 string is present: '=?utf-8?Q?' and then 
used the function imap_utf8($part['disposition-filename']) wich do the magic 
against the filename.
not sure if this is the best way but works for me!
ciao
Rob

Original issue reported on code.google.com by [email protected] on 28 Sep 2010 at 1:15

MimeMailParser::getAttachmentStream() should not use $part as reference

What steps will reproduce the problem?
1. Parse any mail with attachment
2. Use getAttachments() method
3. Try to read headers of retrieved MimeMailParser_attachment object

What is the expected output? What do you see instead?
You should get some headers while you always get none.

What version of the product are you using? On what operating system?
r26


The problem is because $part being passed by reference and gets overwritten 
here: 
http://code.google.com/p/php-mime-mail-parser/source/browse/trunk/MimeMailParser
.class.php#406

In fact $part should never be passed by reference - even in few other methods 
of MimeMailParser class. I can't see any reason for that.

Original issue reported on code.google.com by [email protected] on 26 Feb 2013 at 6:58

Make private functions protected.

If anyone wants to extend your class, using private methods makes it very hard. 
Your private methods should be protected methods. There's very little reason to 
use 'private' in general.

Original issue reported on code.google.com by [email protected] on 11 Jul 2011 at 8:26

rfc822 (eml) with attachments not correct

What steps will reproduce the problem?
1. Parse a mail with EML-Attachments which contain attachments (e.g. pdf's)
2. getAttachments() returns the EMLs and the attachments are in these.

What is the expected output? What do you see instead?
Not sure, but when I parse a mail i would like to display only the actual level 
(EML-Attachments). but here you become EMLs and their attachments at the same 
"level".

it were very useful to fix this

Original issue reported on code.google.com by [email protected] on 31 Aug 2011 at 3:41

problematic implementation of getMessageBody

posit: it's probably safe to assume that mailparser will always return the 
parts list in order. (1, 1.1, 1.2...)

given that, getMessageBody returns the body of the -last- matching part with 
the requested content-type.

this is probably not what most people expect.

even worse, mailparser seems to take a very simple single-part test email i 
have, but in addition to the 1.1, text/plain, it has added a 1.2, with zero 
length body, and also text/plain for no obvious reason (possible bug in 
mailparser? but i'm not an expert on the RFC)

for my own testcase, my single part text-only email, i would have expected 
getMessageBody to return the body.  instead, it returns an empty string because 
part 1.2 is also text/plain, and of length zero.

two possible fixes:

1. have getMessageBody return the first matching part

or

2. ignore any zero length body in the foreach.

for my own use, i did both.

and yes, it is a somewhat fuzzy request, asking for the "message body" from a 
multipart message, but these two changes might help.

Original issue reported on code.google.com by [email protected] on 9 Mar 2011 at 9:36

Decoding header mime

Hi,

Why don't you call something like iconv_mime_decode 
(http://fr.php.net/manual/en/function.iconv-mime-decode.php) before returning 
headers in the getHeaders method, because I'm getting stuffs like « 
=?iso-8859-1?b?QXBy6HM=?= midi jeux
 » using your lib.

Greg

Original issue reported on code.google.com by [email protected] on 15 Sep 2011 at 1:57

unable to retrieve attachments if content-disposition is not provided

What steps will reproduce the problem?

try to save the attachment of a mail without the content-disposition mime header

What is the expected output? What do you see instead?
to save the attachment, instead no attachments seems to be present.

What version of the product are you using? On what operating system?
i'm using the latest version on Linux with PHP 5.2.11


Please provide any additional information below.

For me worked the attached workaround on function getAttachments()



Original issue reported on code.google.com by [email protected] on 13 Feb 2011 at 7:53

Attachments:

Writing files not working.

What steps will reproduce the problem?
1. Retrieve attachments (as per example)
2. Write attachments to directory
3. -

What is the expected output? What do you see instead?
Attached file to be written to directory.
Files are not written.
No errors are generated.

What version of the product are you using?
Downloaded today (02-JUL-2014)

On what operating system?
Ubuntu 12.04LTS

Using this code to write files:
foreach($attachments as $attachment) {
  // get the attachment name
  $filename = $attachment->filename;
  $file_list .= $filename."<br>";
  // write the file to the directory you want to save it in
  if ($fp = fopen($save_dir.$filename, 'w')) {
    while($bytes = $attachment->read()) {
      fwrite($fp, $bytes);
    }
    fclose($fp);
  }
}

Original issue reported on code.google.com by jax.contine on 2 Jul 2014 at 8:50

Unable to parse attachment which are email added as attachment

Many Old version mail client add the previous emails as attachment with 
extension eml These attachments do not have any file name associated with it.

It throws and exception and exits

PHP Notice:  Undefined index: disposition-filename in MimeMailParser.class.php 
on line 245
PHP Fatal error:  Uncaught exception 'Exception' with message 'Could not create 
temporary files for attachments. Your tmp directory may be unwritable by PHP.' 
in MimeMailParser.class.php:448
Stack trace:
#0 MimeMailParser.class.php(247): MimeMailParser->getAttachmentStream(Array)
#1 email.php(125): MimeMailParser->getAttachments()
#2 {main}
  thrown in MimeMailParser.class.php on line 448

I m considering a patch whereby i provide a random file with extension eml in 
case disposition-filename is null

Original issue reported on code.google.com by [email protected] on 11 Feb 2012 at 1:49

No attachments

What steps will reproduce the problem?
1. parse a e-mail with attachments. Send of Outlook 2007
2.
3.

What is the expected output? What do you see instead?
A array with attachments. A array with the name of de attachment

What version of the product are you using? On what operating system?
r16, with the attachment class. CentOS with mailparse extension

Please provide any additional information below.

Original issue reported on code.google.com by [email protected] on 24 Sep 2010 at 1:19

getMessageBody may have unexpected behavior for emails with multiple parts with same requested mime type

If there is more than one part the a mime type of the requested type then
the code loops through and returns the last one in the list.  Is this
expected behavior?  At least with Apple Mail, when there is more than one
part of mime type 'text/plain', it seems that the first one is the one you
would want, not the last.  
I have attached a sample message that exhibits the behavior.  

The following code will reproduce:

<code>
$parser = new MimeMailParser();     
$parser->setPath('mail.txt');
$msg = $parser->getMessageBody();

echo "Message found: " . $message;  //should be 'Test message'
</code>

Original issue reported on code.google.com by [email protected] on 16 Apr 2010 at 11:04

Attachments:

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.