php-general Digest 24 Sep 2013 10:38:18 -0000 Issue 8375
Topics (messages 322160 through 322170):
Re: No MIME-Type in "imap_fetch_overview()"
322160 by: Negin Nickparsa
322161 by: Negin Nickparsa
322166 by: Aziz Saleh
322168 by: Domain nikha.org
322169 by: Domain nikha.org
Re: Apache
322162 by: Domain nikha.org
322165 by: Ashley Sheridan
322167 by: Tamara Temple
322170 by: Arno Kuhl
Re: filesize() fails on file and works on it's copy (same permissions, same
directory)
322163 by: MichaÅ Kochanowicz
322164 by: MichaÅ Kochanowicz
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
I have read your mail twice and still I could not get what you want
exactly. can't get the structure of the email either although you
elaborate it in details.
you have said something about human rights that I couldn't understand why?
but if you want to get the type of files fetch the structure and then you
can use disposition string, find the "attachment" and then return the
array.
Sincerely
Negin Nickparsa
On Wed, Sep 18, 2013 at 3:27 PM, Domain nikha.org <m...@nikha.org> wrote:
> Hello all,
>
> im posting this here, because the bug report system of "php.net" is not
> right
> place for my problem. It's not a bug, but a wish - an I found there no
> "wishlist" option at all.
>
> I'm running my own webmail-client, written in PHP. It is stable, fast and
> pretty, showing the full power of the PHP imap section.
>
> Of course it presents paginated content lists for every mailbox the user
> may
> open. These lists tell him some usefull things about every mail actually
> listed:
> Sender, date, subject, size and (eventually) flags.
>
> All these things are nicely delivered by the function
> "imap_fetch_overview()"
> The same could be done by calling "imap_headerinfo()" for every single
> mail, but
> "fetch_overview" seems to be faster, because it does it at once for the
> whole
> batch.
>
> BUT NONE OF THEM returns any information about the MIME-Type of the mail!
>
> Since the user of my webmail client has the intrinsic, natural born an
> general
> human right to KNOW whether some mail in his mailbox has attachments or
> not, I'm
> forced to do very ugly things. My script calls additionally for every (!)
> actually listed mail "imap_fetchbody($connect, $msg_no, 0)" - where
> "$connect"
> holds the result of "imap_open()".
>
> That gives me the mail header, the script reads the line starting with
> "Content-Type:" and returns its content. Evaluating this against "mixed" or
> "alternative" we have finaly what we want: This mail has attachments! Or is
> written in HTML, what is even more we wanted!
>
> Works fine, but is ugly. First "fetch_overview" parses all mail headers,
> then
> they are fetched again to be parsed for the MIME-Type. I could just omit
> "fetch_overview" and read the headers by my own means, that whould be
> faster,
> but then I loose the size information, that is NOT (and cannot) be part of
> the
> mail header!
>
> If I want to have both, size and MIME-Type, and I WANT to have both,
> respecting
> the intrinsic, natural born and general human rights of my user, im must
> call
> both, "overview" and "fetchbody".
>
> My question is this: Is there a better solution? Or is there someone that
> knows
> someone among the PHP-Developpers to suggest them an improvement of the
> functions "imap_fetch_overivew()" and "imap_headerinfo()". Please, Please,
> add
> the MIME-Type to your fantastic object collections! BTW: It's really easy.
> Read
> the "Content-Type"-Line! Sorry...
>
> Hope, somebody has an idea,
> my regards,
>
> Niklaus
>
>
>
>
>
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
I have read your mail twice and still I could not get what you want
exactly. can't get the structure of the email either although you
elaborate it in details.
you have said something about human rights that I couldn't understand why?
but if you want to get the type of files fetch the structure and then you
can use disposition string, find the "attachment" and then return the
array.
Sincerely
Negin Nickparsa
On Wed, Sep 18, 2013 at 3:27 PM, Domain nikha.org <m...@nikha.org> wrote:
> Hello all,
>
> im posting this here, because the bug report system of "php.net" is not
> right
> place for my problem. It's not a bug, but a wish - an I found there no
> "wishlist" option at all.
>
> I'm running my own webmail-client, written in PHP. It is stable, fast and
> pretty, showing the full power of the PHP imap section.
>
> Of course it presents paginated content lists for every mailbox the user
> may
> open. These lists tell him some usefull things about every mail actually
> listed:
> Sender, date, subject, size and (eventually) flags.
>
> All these things are nicely delivered by the function
> "imap_fetch_overview()"
> The same could be done by calling "imap_headerinfo()" for every single
> mail, but
> "fetch_overview" seems to be faster, because it does it at once for the
> whole
> batch.
>
> BUT NONE OF THEM returns any information about the MIME-Type of the mail!
>
> Since the user of my webmail client has the intrinsic, natural born an
> general
> human right to KNOW whether some mail in his mailbox has attachments or
> not, I'm
> forced to do very ugly things. My script calls additionally for every (!)
> actually listed mail "imap_fetchbody($connect, $msg_no, 0)" - where
> "$connect"
> holds the result of "imap_open()".
>
> That gives me the mail header, the script reads the line starting with
> "Content-Type:" and returns its content. Evaluating this against "mixed" or
> "alternative" we have finaly what we want: This mail has attachments! Or is
> written in HTML, what is even more we wanted!
>
> Works fine, but is ugly. First "fetch_overview" parses all mail headers,
> then
> they are fetched again to be parsed for the MIME-Type. I could just omit
> "fetch_overview" and read the headers by my own means, that whould be
> faster,
> but then I loose the size information, that is NOT (and cannot) be part of
> the
> mail header!
>
> If I want to have both, size and MIME-Type, and I WANT to have both,
> respecting
> the intrinsic, natural born and general human rights of my user, im must
> call
> both, "overview" and "fetchbody".
>
> My question is this: Is there a better solution? Or is there someone that
> knows
> someone among the PHP-Developpers to suggest them an improvement of the
> functions "imap_fetch_overivew()" and "imap_headerinfo()". Please, Please,
> add
> the MIME-Type to your fantastic object collections! BTW: It's really easy.
> Read
> the "Content-Type"-Line! Sorry...
>
> Hope, somebody has an idea,
> my regards,
>
> Niklaus
>
>
>
>
>
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
What Niklaus wishes for is a way to detect if an email message contains an
attachment by just reading the headers (correct me if I am wrong).
This isn't really a PHP issue. In any language you can't really figure out
if an email has an attachment by just looking at the headers, you need to
check the body. You can try to infer by using the content-type or the size,
but that isn't 100% valid.
Aziz
On Mon, Sep 23, 2013 at 2:59 PM, Negin Nickparsa <nickpa...@gmail.com>wrote:
> I have read your mail twice and still I could not get what you want
> exactly. can't get the structure of the email either although you
> elaborate it in details.
>
> you have said something about human rights that I couldn't understand why?
> but if you want to get the type of files fetch the structure and then you
> can use disposition string, find the "attachment" and then return the
> array.
>
>
>
>
> Sincerely
> Negin Nickparsa
>
>
> On Wed, Sep 18, 2013 at 3:27 PM, Domain nikha.org <m...@nikha.org> wrote:
>
> > Hello all,
> >
> > im posting this here, because the bug report system of "php.net" is not
> > right
> > place for my problem. It's not a bug, but a wish - an I found there no
> > "wishlist" option at all.
> >
> > I'm running my own webmail-client, written in PHP. It is stable, fast and
> > pretty, showing the full power of the PHP imap section.
> >
> > Of course it presents paginated content lists for every mailbox the user
> > may
> > open. These lists tell him some usefull things about every mail actually
> > listed:
> > Sender, date, subject, size and (eventually) flags.
> >
> > All these things are nicely delivered by the function
> > "imap_fetch_overview()"
> > The same could be done by calling "imap_headerinfo()" for every single
> > mail, but
> > "fetch_overview" seems to be faster, because it does it at once for the
> > whole
> > batch.
> >
> > BUT NONE OF THEM returns any information about the MIME-Type of the mail!
> >
> > Since the user of my webmail client has the intrinsic, natural born an
> > general
> > human right to KNOW whether some mail in his mailbox has attachments or
> > not, I'm
> > forced to do very ugly things. My script calls additionally for every (!)
> > actually listed mail "imap_fetchbody($connect, $msg_no, 0)" - where
> > "$connect"
> > holds the result of "imap_open()".
> >
> > That gives me the mail header, the script reads the line starting with
> > "Content-Type:" and returns its content. Evaluating this against "mixed"
> or
> > "alternative" we have finaly what we want: This mail has attachments! Or
> is
> > written in HTML, what is even more we wanted!
> >
> > Works fine, but is ugly. First "fetch_overview" parses all mail headers,
> > then
> > they are fetched again to be parsed for the MIME-Type. I could just omit
> > "fetch_overview" and read the headers by my own means, that whould be
> > faster,
> > but then I loose the size information, that is NOT (and cannot) be part
> of
> > the
> > mail header!
> >
> > If I want to have both, size and MIME-Type, and I WANT to have both,
> > respecting
> > the intrinsic, natural born and general human rights of my user, im must
> > call
> > both, "overview" and "fetchbody".
> >
> > My question is this: Is there a better solution? Or is there someone that
> > knows
> > someone among the PHP-Developpers to suggest them an improvement of the
> > functions "imap_fetch_overivew()" and "imap_headerinfo()". Please,
> Please,
> > add
> > the MIME-Type to your fantastic object collections! BTW: It's really
> easy.
> > Read
> > the "Content-Type"-Line! Sorry...
> >
> > Hope, somebody has an idea,
> > my regards,
> >
> > Niklaus
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > PHP General Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
--- End Message ---
--- Begin Message ---
Negin Nickparsa am Montag, 23. September 2013 - 20:59:
> I have read your mail twice and still I could not get what you want
> exactly.
Sorry for my bad english!
What I want is, that the users of my webmail client can see at a glance,
if mails in their mailboxes have attachments or not. (Thats a human
right! But of course I was joking... It's simply nice to provide this
information and should be done)
> but if you want to get the type of files fetch the structure and then
you
> can use disposition string, find the "attachment" and then return the
> array.
Yes, I could do even that! But this is worse! Imagine, you do this in
the overview of the mailbox content! This can be hunderds of mails! My
script paginates this stuff in blocks of 16 (or something) mail headers,
but even then you have an huge overhead.
Why?
Because, first you must collect the sender and subject information. This
is done by "imap_fetch_overview()", parsing the mailheaders and grabing
some server data, like arrival date, size and flags.
Fine, but you still know nothing about attachments! You must do
something more. OK?
You whould run "imap_fetchstructure()", but sorry, that's the wrong time
and place. You will need this monster object only when the user _reads_
some specific mail. At the moment, we are not reading, but collecting
mails to present them in the mailbox overview.
My script modestly fetches the mailheaders again to read the
"Content-Type"-line. That's quite fast, works fine, but is stupid,
because this headers were fetched and parsed just before!
I ask you, and all PHP developpers: Why the hell this function does not
parse this line too? (a part of so much others of less importance) The
same is true for "imap_headerinfo()". And: of course this
"Content-Type"-line provides by far not the complete MIME-structure as
"imap_fetchstructure()" does, but, as said, we don't need this at the
moment.
The result is a script, that I self whould not describe as "good
practice" because of it's duplicated parsing of the same string, but I
found no other way yet.
That's my problem, you see?
Sincerely
Niklaus
--- End Message ---
--- Begin Message ---
Aziz Saleh am Montag, 23. September 2013 - 22:06:
> What Niklaus wishes for is a way to detect if an email message
contains an
> attachment by just reading the headers (correct me if I am wrong).
>
Yes, that's what I'm seeking :-)
> This isn't really a PHP issue. In any language you can't really figure
out
> if an email has an attachment by just looking at the headers, you need
to
> check the body. You can try to infer by using the content-type or the
size,
> but that isn't 100% valid.
>
That's like radio Eriwan: In principle you are right!
BUT: I want not show the whole MIME-structure in the mailbox overview!
That whould be absurd, and indeed could only be done by reading the
body.
Nevertheless we have in the primary header of any MIME compliant message
the line "Content-Type". (We have it also in the headers of the attached
parts, but that is not intresting now)
In this primary header (fetched by "imap_fetchbody($mailbox, $msg_no,
0)) the leading part of the MIME-type description can have only two
values: "text" or "multipart". Right? I'm sure you will never find other
values in the _primary_ header.
That's the first decision for your script. "text: no attachment",
"multipart: attachment". No matter the subtype-value after the slash,
you have what I want! And ONLY by looking on the header. And this ist
100% valid, because it follows logically from the imap- and MIME-rfc's.
About malformed messages violating the protocols we discuss next year,
you agree? :-)
You may evaluate the subtype after the slash. If the type is multipart,
you will find "mixed", "alternative", "related" or "digest", if the type
is "text", you will have "plain" or "html" as subtype.
May be there are more subtypes on the way, but all these are optional
for the primary job, a decent mailbox overview must do: tell the user,
whether there are attachments or not.
My own webmail client does this job pretty good, but it violates my own
standard of good practice. Whether "imap_fetch-overview()" nor
"imap_headerinfo" are reading the "Content-Type"-line while parsing much
other header lines of minor importance. My script must refetch the
mailheaders to do that! This is an ugly overhead I wish to avoid.
BTW: the "squirrelmail"-staff, leading in the PHP-webmail-world, just
ignores the whole imap-extension of PHP. Instead, they talk low level
with the server. But this way is a little bit too hard for me...
Therefore my pledge to all involved into the development of the fabulous
PHP framework, section imap:
Please ad the primary MIME-type to the objects returned by
fetch_overview and headerinfo! It's so ridiculous simple: read the
"Content-Type"-line in the primary mailheader as I must do afterwards,
only because you do not!
Niklaus
--- End Message ---
--- Begin Message ---
Tim Streater am Montag, 23. September 2013 - 12:56:
> On 23 Sep 2013 at 11:37, Domain nikha.org <m...@nikha.org> wrote:
>
> > The problem is the weak PHP upload mechanism!
>
> I'd have said the problem is weak metadata provision - overloading the
filename for other purposes.
>
> --
> Cheers -- Tim
>
You are right, but unfortunately filenames ARE metadata for Apache.
Would be better, if they were not, and just identifiers...
Niklaus
--- End Message ---
--- Begin Message ---
On Mon, 2013-09-23 at 20:36 +0200, Domain nikha.org wrote:
> Stuart Dallas am Montag, 23. September 2013 - 12:58:
>
> > And, honestly, who would have a PHP file per language? I think it's
> perfectly reasonable to not allow that, because duplicating PHP code
> across many files is an incredible stupid way to support multiple
> languages.
> >
> I agree!! Didn't even know, that this kind of faked language support
> exists...
>
> > "Some people run all their files through PHP" - true, but that doesn't
> mean they should, or that you, as a responsible web host, should be
> endorsing it.
> >
> > PHP developers should absolutely validate all content coming in from
> users in every possible way, but I would be highly dubious about
> trusting a host who gives the reason above for what I consider a lax and
> insecure Apache configuration. It's like saying they sliced your arm off
> with their chainsaw because it's made for cutting things, attempting to
> dodge all responsibility for having swung it in your direction!
> >
> OK, in principle, I also agree. But this case is very easy to handle.
> I'm simply running "str_replace()" against dangerous parts of uploaded
> filenames, ".php" for instance. After that, Apache in every
> configuration will just serve, and never execute user uploaded files.
> Remains the risk on the clients side, I must concede. Better solutions?
>
> Nice days,
> Niklaus
>
No, no, no! That is not a good stand-in for fundamental security
principles!
This is a better method for ensuring an image is really an image:
<?php
if(isset($_FILES['file']))
{
list($width, $height) = getimagesize($_FILES['file']['tmp_name']);
if($width && $height)
{
$source = imagecreatefromjpeg($_FILES['file']['tmp_name']);
$dest = imagecreatetruecolor($width, $height);
imagecopyresampled($dest, $source,
0, 0, 0, 0,
$width, $height, $width,
$height);
imagejpeg($dest, basename($_FILES['file']['tmp_name']));
}
else
echo "{$_FILES['file']['name']} is not a jpeg";
}
?>
<form enctype="multipart/form-data" method="post">
<input type="file" name="file"/>
<input type="submit" name="submit" value="submit"/>
</form>
Obviously it's only rough, and checks only for jpeg images, but that's
easy to alter. I've just tested this with a regular jpeg, the same jpeg
with PHP code concatenated onto the end (which still appears to be a
valid image to viewing/editing software) and a pure PHP file with a .jpg
extension. In the case of the first 2, a new jpeg is generated with the
same image and without the code. The third example just echoes out an
error.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Sep 23, 2013, at 1:36 PM, Domain nikha.org <m...@nikha.org> wrote:
> Better solutions?
One I have used, and continue to use in Apache environments, is place uploads
only in a place where they cannot be executed by turning off such options and
handlers in that directory. This is *in addition* to untainting files and names
of uploaded files.
--- End Message ---
--- Begin Message ---
On 23 Sep 2013, at 11:37, Domain nikha.org <m...@nikha.org> wrote:
> Tamara Temple am Montag, 23. September 2013 - 06:49:
>>
>> GoDaddy's default plesk-generated configuration for FastCGI-served
>> PHP
> files only looked to see if the file contained ".php" somewhere on
> it's path - i.e. it would happily execute 'malicilous.php.txt' as php
> code, even something ridiculous like 'malware.phpnoreallyiwantthistorun'.
>>
>
> Yes, looks stupid.
> But my service prodider wrote me this, I quote:
> ---QUOTE---
> This is because Apache offers features like language negotiation based
> on extensions, too -- the final extension doesn't always just specify
> the handler; it can specify other things. Apache can automatically
> pick a German-language script from these, for example:
>
> file.php.de
> file.php.en
>
> Whether this is a good idea or not is debatable. It's possible to set
> things up in a different way (using FilesMatch instead of AddHandler)
> to avoid this particular problem, but that breaks other things, so
> there's no perfect solution.
>
> More generally, the real problem is that scripts are looking at the
> final extension of uploaded files to decide whether they're safe or
> not, which is dangerous. They're simply assuming that a ".gif" file
> can't run a PHP interpreter, for example... which is usually true, but
> certainly not always: some people run all their files through PHP.
> ---END QUOTE---
This is somewhat daft. Yes, Apache offers this feature, but you don't need
to configure it to work will all extensions. I'd be curious to know what
their issue is with using FilesMatch, since that provides a way to disable
this behaviour. And, honestly, who would have a PHP file per language? I
think it's perfectly reasonable to not allow that, because duplicating PHP
code across many files is an incredible stupid way to support multiple
languages.
"Some people run all their files through PHP" - true, but that doesn't mean
they should, or that you, as a responsible web host, should be endorsing it.
> The problem is the weak PHP upload mechanism!
> As workaround my service provider tries to block suspicious filenames,
> but the PHP developpers themself should work on this severe security
> problem.
PHP developers should absolutely validate all content coming in from users
in every possible way, but I would be highly dubious about trusting a host
who gives the reason above for what I consider a lax and insecure Apache
configuration. It's like saying they sliced your arm off with their chainsaw
because it's made for cutting things, attempting to dodge all responsibility
for having swung it in your direction!
-Stuart
--
It seems this is the standard apache configuration, but that's no excuse.
Googling returned many results where this was described as a major security
threat
e.g. "Beware of the default Apache 2 config for PHP"
http://ilia.ws/archives/226-Beware-of-the-default-Apache-2-config-for-PHP.ht
ml
On that site the solution was to change AddHandler to AddType.
My service provider is going the FilesMatch route.
Cheers
Arno
--- End Message ---
--- Begin Message ---
W dniu 2013-09-23 10:06, Negin Nickparsa pisze:
regardless of you, saying they have same permissions I think they do not have
the same permission
The reason was 64-bit inode number. PHP can't stat() files with 64-bit nodes,
at lease on 32-bit system.
Regards
Michał
--- End Message ---
--- Begin Message ---
W dniu 2013-09-23 17:24, Tamara Temple pisze:
That is one whopping-big inode number — I am really out on a limb here, but is
this a 32-bit vs 64-bit issue?
You're right - 64-bit inode number was a cause. I had to add "inode32" mount
option (XFS).
Regards
Michał
--- End Message ---
