PHP: imap_headers

imap_headers

me at _spam_koenpasman dot nl
31-Jul-2005 10:41


A reaction to consult at pmkmedia dot com:



The negative results you are getting are due to your usage of microtime(). microtime() returns a string like this:

0.52234000 1122834868



First, the microseconds, then a space, and then a Unix Timestamp. A function like this corrects this:

<?php

function getmicrotime() {

    list($usec, $sec) = explode(' ', microtime());

    return ((float)$usec + (float)$sec);

}



$first = getmicrotime();



/* code.. */



echo 'parsetime: '.(getmicrotime()-$first);

?>



Then you won't get any negative parsetimes.

leo at blue-straggler dot com
12-Mar-2005 07:24


Inspection of TCP/IP packets traffic confirms that the imap_headers function causes at least PHP4.2.1 / Apache 1.3.24 / IMAP c-Client Version 2001 / Win2000) to retrieve complete messages, not only their headers. Leos Ondra

koas at karontek dot com
11-Jan-2005 08:29


When we started running a PHP script in our server that uses this function the server antivirus started throwing warnings about viruses found in files like c:\winnt\temp\message2 



This is likely the antivirus founding virus in the attachments of the messages the function downloads. So we're inclined to think this function downloads the whole message, then parses it.

consult at pmkmedia dot com
13-Apr-2004 07:42


RE: jemore at n0spam dot m6net dot fr (13-Nov-2003 11:17)



A fallacious assertion, to be sure. 



PMK Media ran an indicative test with a POP3 server and script on separate physical servers and indeed physical locations - the script in California and the mail server in Virginia (at least, presumably closer to the East Coast - Sprint Earthlink DSL). 



The test code:

<?

    // connect to pop3 server first, then:

    $time = microtime();

    $headers = imap_headers($mbox);

    $timediff = microtime() - $time;

    echo "Time taken: ".$timediff;

    // disconnect...

?>



The page was refreshed several times to obtain average data.



With 2 small messages (total 4367 characters, 2 messages on the server):

Time taken: 0.12 (max, first run) 

Time taken: 0.08 (average)



After sending a 2.8 megabyte attachment (total 3947423 characters, 3 messages on the server):

Time taken: 0.16 (max, first run)

Time taken: 0.11 (average)



The increase in execution time was 0.02 seconds. This would indicate a transfer rate of about 150 MB per second had attachments indeed been fetched. 



A test on the theory that message bodies are downloaded was also conducted. Ten large messages were sent (200K each, 211590 characters) and the script above was executed after the first message and again after all ten. No messages were deleted during the course of the test:



After sending one 200K message (total 4159013 characters, 4 messages on the server):

Time taken: 0.25 (max, first run)

Time taken: 0.18 (average)



After sending ten 200K messages (total 6063323 characters, 13 messages on the server):

Time taken: 0.57 (sometimes -0.43)



The results are surprising - suggestions on why there is a negative time there? Perhaps the way the interpreter handles floating point arithmetic or fetches the time. Notice that 1-(the negative value) is within the range of positive values that are produced. 



In any case, no discernable delay exists after fetching these message headers, and definitely not the two orders of magnitude premised in message bodies or attachments being transferred.



Verily, imap_headers() does exactly and only what it claims to do.



PMK Media

http://www.pmkmedia.com

jemore at n0spam dot m6net dot fr
13-Nov-2003 02:17


You have to notice that the imap_headers() function will download the whole messages, body (and attachements) included, and save them in a temporary directory before processing. I was hoping that this function will download only headers, but with pop3 it doesnt act like this.

imap_headers

Description