php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #48201 wrong behaviour of imap_mail_compose()
Submitted: 2009-05-09 11:51 UTC Modified: 2020-10-12 14:06 UTC
Votes:3
Avg. Score:4.3 ± 0.9
Reproduced:1 of 2 (50.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: carsten_sttgt at gmx dot de Assigned:
Status: Verified Package: IMAP related
PHP Version: 7.3 OS: *
Private report: No CVE-ID: None
View Developer Edit
 [2009-05-09 11:51 UTC] carsten_sttgt at gmx dot de 
Description:
------------
Hello,

from my understanding, and if I read RFC2045-sec6.2, imap_mail_compose() is working in a wrong way. From RFC2045:
- With "binary", "8bit" and "7bit" no transforming is done.

- With "quoted-printable" and "base64", the data is transformed
  to 7bit, according to the selected encoding type.

The behavior from imap_mail_compose():
- with ENC7BIT no Content-Transfer-Encoding header is set
 (ok, that's the same. maybe correct)

- with ENC8BIT, the Content-Transfer-Encoding changes to
  "quoted-printable" and the data is transfomed (wrong)

- with ENCBINARY, the Content-Transfer-Encoding changes to
  "base64" and the data is transfomed (wrong)

- with ENCBASE64, the Content-Transfer-Encoding is "base64"
  and the data is transfomed (correct)

- with ENCQUOTEDPRINTABLE, the Content-Transfer-Encoding is
  "quoted-printable" and the data is transfomed (correct)

- ENCOTHER is imho not really useful (especially if I can't
  set the name (foo) in x-foo).

Then I've tried to set the value for the Content-Transfer-Encoding header on my own:
- with "binary", no Content-Transfer-Encoding header is set

- with "8bit" (or "7bit"), I have a segmentation fault (PHP crashes).

Regards,
Carsten



Reproduce code:
---------------
<?php
$data8bit = 'a german umlaut ?.';
$data7bit = 'just a text in us-ascii.';
$body = array();

$i = 0;
$body[++$i] = array(
    'type'    => TYPEMULTIPART,
    'subtype' => 'mixed'
);

$body[++$i] = array(
    'type'             => TYPETEXT,
    'charset'          => 'us-ascii',
    'encoding'         => ENC7BIT,
    'contents.data'    => $data7bit
);

$body[++$i] = array(
    'type'             => TYPETEXT,
    'charset'          => 'iso-8859-1',
    'encoding'         => ENC8BIT,
    'contents.data'    => $data8bit
);

$body[++$i] = array(
    'type'             => TYPETEXT,
    'charset'          => 'iso-8859-1',
    'encoding'         =>  ENCBINARY,
    'contents.data'    => $data8bit
);

$body[++$i] = array(
    'type'             => TYPETEXT,
    'charset'          => 'iso-8859-1',
    'encoding'         => ENCBASE64,
    'contents.data'    => $data8bit
);

$body[++$i] = array(
    'type'             => TYPETEXT,
    'charset'          => 'iso-8859-1',
    'encoding'         => ENCQUOTEDPRINTABLE ,
    'contents.data'    => $data8bit
);

$body[++$i] = array(
    'type'             => TYPETEXT,
    'charset'          => 'iso-8859-1',
    'encoding'         => 'binary',
    'contents.data'    => $data8bit
);

//$body[++$i] = array(
//    'type'             => TYPETEXT,
//    'charset'          => 'iso-8859-1',
//    'encoding'         => '8bit' ,
//    'contents.data'    => $data8bit
//);

echo imap_mail_compose(array(), $body);
?>


Expected result:
----------------
MIME-Version: 1.0
Content-Type: MULTIPART/mixed; BOUNDARY="62-22384-1241869364=:9856"

--62-22384-1241869364=:9856
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-Transfer-Encoding: 7BIT

just a text in us-ascii.
--62-22384-1241869364=:9856
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-Transfer-Encoding: 8BIT

a german umlaut ?.
--62-22384-1241869364=:9856
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-Transfer-Encoding: BINARY

a german umlaut ?.
--62-22384-1241869364=:9856
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-Transfer-Encoding: BASE64

YSBnZXJtYW4gdW1sYXV0IOQu
--62-22384-1241869364=:9856
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE

a german umlaut =E4.
--62-22384-1241869364=:9856
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-Transfer-Encoding: binary

a german umlaut ?.
--62-22384-1241869364=:9856--


Actual result:
--------------
MIME-Version: 1.0
Content-Type: MULTIPART/mixed; BOUNDARY="62-22384-1241869364=:9856"

--62-22384-1241869364=:9856
Content-Type: TEXT/PLAIN; CHARSET=us-ascii

just a text in us-ascii.
--62-22384-1241869364=:9856
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE

a german umlaut =E4.
--62-22384-1241869364=:9856
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-Transfer-Encoding: BASE64

YSBnZXJtYW4gdW1sYXV0IOQu

--62-22384-1241869364=:9856
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-Transfer-Encoding: BASE64

a german umlaut ?.
--62-22384-1241869364=:9856
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE

a german umlaut ?.
--62-22384-1241869364=:9856
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1

a german umlaut ?.
--62-22384-1241869364=:9856--

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-05-10 07:43 UTC] carsten_sttgt at gmx dot de 
> Please try using this CVS snapshot:

I have test the above with:
Version: 5.3.0RC3-dev Thu, 07 May 2009 13:08:08 +0000
Version: 5.2.10-dev Thu, 07 May 2009 11:42:06 +0100
(the latest binary snapshots which are available for VC6 x86 Thread Safe)

(and my normal PHP 5.2.9 VC6 x86 Thread Safe)

Can't test with:
Version: 6.0.0-dev Thu, 07 May 2009 11:30:12 +0000
because "php_imap.dll" is missing in the zip.
 [2009-05-10 16:39 UTC] jani@php.net 
Thanks for that. Just want to get the version info right. Just FYI, 
whenever you know that a bug exists in certain branch, please update the 
version also. And HEAD is not that necessary at the moment, we can be 
quite sure it exists there if it exists in PHP_5_3. :) I updated the 
versions now. Please do same in other reports from now on.
 [2009-05-10 16:40 UTC] jani@php.net 
This bug might be actually bug in c-client though..
 [2009-05-11 07:21 UTC] carsten_sttgt at gmx dot de 
> This bug might be actually bug in c-client though..

I guess it's more that PHP is just using rfc822_encode_body_7bit() to the whole message (topbod is including all bodies from each message part), instead of process each body part separately, according to the encoding which is set.  

rfc822_encode_body_7bit is forcing a 7bit transfer, and so ENC8BIT must switch to "quoted-printable".
 [2009-05-11 09:55 UTC] jani@php.net 
Patches are welcome. :)
 [2009-05-14 07:14 UTC] carsten_sttgt at gmx dot de 
Hi Jani,

first I must correct my description. Curious I have not seen this, because in "Actual result" you see what happens.
>> - with ENCBASE64, the Content-Transfer-Encoding is "base64"
>>   and the data is transfomed (correct)
>> 
>> - with ENCQUOTEDPRINTABLE, the Content-Transfer-Encoding is
>>   "quoted-printable" and the data is transfomed

must be:
- with ENCBASE64, the Content-Transfer-Encoding is "base64"
  and no transforming is done.
- with ENCQUOTEDPRINTABLE, the Content-Transfer-Encoding is
  "quoted-printable" and no transforming is done.

In summary we can say, the current behavior is:
- ENC7BIT: no header, no data encoding
- ENC8BIT: header switch to ENCQUOTEDPRINTABLE and data is
  automatically encoded with "quoted-printable" 
- ENCBINARY: header switch to ENCBASE64 and data is
  automatically encoded with "base64"
- ENCQUOTEDPRINTABLE: header set to ENCQUOTEDPRINTABLE and
  no data encoding. You must do the encoding yourself
- ENCBASE64: header set to ENCBASE64 and
  no data encoding. You must do the encoding yourself

- And I'm not be able, to use a real ENC8BIT/ENCBINARY as
  header and without this automatically data encoding.
- And there is also no info in the manual about the
  current behavior of this function. (also the list of
  available body params is not complete in the manual) 


>> - with "8bit" (or "7bit"), I have a segmentation fault
>>   (PHP crashes).

At the moment you have a crash with a wrong "encoding" and also with a wrong "type". This happens because an access to a not existent / initialized array key.


> Patches are welcome. :)

Well, to fix this possible crash is easy. Only I'm not sure, how to handle this problem. At the moment I'm printing a "Warning" and the function returns with "false". But it's also possible, to set the value in these cases to "x-unknown" and maybe print an additional "Notice".


To allow a real ENC8BIT, ENCBINARY, looks like a "little" bit more work...

Regards,
Carsten
 [2020-10-12 14:06 UTC] cmb@php.net
-Summary: wrong behaviour and crash with imap_mail_compose() +Summary: wrong behaviour of imap_mail_compose() -Status: Open +Status: Verified -PHP Version: 5.*, 6CVS (2009-05-09) +PHP Version: 7.3
 [2020-10-12 14:06 UTC] cmb@php.net 
> I guess it's more that PHP is just using
> rfc822_encode_body_7bit() to the whole message (topbod is
> including all bodies from each message part), instead of process
> each body part separately, according to the encoding which is set.

I think you're right, but I wouldn't change that long-standing
(mis-)behavior in stable versions.  Some code may easily rely on
this.  Maybe a bit late for PHP 8.0, but there shouldn't be a
problem to fix it for PHP 8.1.

> At the moment you have a crash with a wrong "encoding" and also
> with a wrong "type". This happens because an access to a not
> existent / initialized array key.

Indeed; I have filed that recently as bug #80216, so this part of
this ticket will be fixed soon.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 12:01:29 2024 UTC