Building A PHP-Based Mail Client (part 1)

In the following code an '@' preceeds the imap_open function call:

// open mailbox
$inbox = @imap_open ("{". $SESSION_MAIL_HOST . "/pop3:110}",
$SESSION_USER_NAME, $SESSION_USER_PASS) or header("Location:
error.php?ec=3");

I am unfamiliar with this. What does it do?

after the log in portion when i add the second part i get parsing error both setions belong in index.php?

correct?

the 'at' symbol preceding the function call prevents the interpreter from spitting out an error message on the page.

i think in this case the error message would say warning: could not establish stream line x

particularly bad if you''re trying to redirect, as it sends http headers along with the error.

you can in effect 'silence' many functions in php with the @, not just the imap functions

Hi, the article was a great introduction, but I had a few concerns.. First, if the user selects a message to be deleted on the Inbox page and, in the meanwhile, a new message arrives in his inbox ( or another client deletes a message or the user accidentally reloads the delete page for some reason due to some slow network response ), another message could inadvertently be erased instead ( or multiple messages might be erased ). Next, the current setup does not account for persistence in the sense that one can only view what is currently in one's inbox. People travelling tend to get large amounts of e-mail which they cannot afford to have clogging up their account on the mail server. What would be a good approach for introducing persistence here? Would storing the messages in a database table be feasible? or would something like storing the messages in files based on the message_id's be a better solution. This would also have much to do with the notion of attachments, etc. Also, how might one address the idea of HTML-encoded e-mails? i'd imagine some sort of parsing would need to be done to strip extras out of the e-mail in this case. Thanks for a nice article.

Very good to know!

Thank you for the explanation.

We've been sent a new source archive for this article. I suggest that if you have downloaded the source before 4:40 PM MST on Monday, January 7th, you download the new archive.

The new archive can be found "here":http://www.devshed.com/Server_Side/PHP/PHPMail/PHPMail1/mail.zip.

Thanks and sorry for the inconvenience.

anil has got some good points in the comment titled 'some potential fallacies':

1) it would be better to use messageIDs instead of message numbers (in case a user reloads the delete page accidentally).

2) how to have mail folders (maybe use a database?)

also, I would like to add:

3) how to distinguish read messages from unread ones, assuming we're using POP3 and not IMAP? (maybe use a database?)

4) how to improve performance time? i've had up to 7 second load times for the inbox if there are more than 20 messages there. i'm guessing that if you put the php files on the same machine that handles the email, then it would speed it up?

Hello Josh,

Nice article is this one.
Few things I would like to point out.

Firstly you have assumed that for email abc@xyz.com, xyz.com is the pop server. This is in most cases not TRUE. I guess we can ask user to enter pop server OR from the email We cant some MX record lookup and find out the pop server [ just like mail2web.com does. ]


Also, connecting to pop server every time list.php is called would be bit too much. What We can do is, when the script contacts the POP server first time, It would download all the messages and store it either in file or in db. For, one web mail project I did,I used files, but I think DB would be preferable, cause you can make table which has fields like to, from, date, remail i.e. all the mail properties and the mail body itself.

So after listing the mails, when user tries to read the mail, you just read the mail off the DB. We can also provide a refresh link by clicking on which, we would update the db with the latest state of the Mailbox.

I also found out that if PHP is not configured with IMAP support, the list.php would show blank page. It is because if imap_open function is not supported, it would result in Fatal error and script would exit immediately but as you have suppressed the error message one won’t come to know what happen. We can put up check using function_exists. [This is not all that necessary as we can safely assume the person trying to get this script running does have IMAP support !!!]

That’s it for now,
JD


url : http://www.jdk.f2s.com

email : jdk@f2s.com

Moderator at Devshed forums.
[ http://forums.devshed.com ]

There is a type-fault in the login file:

else
{
?>

you should delete "?>"

I think you are headed in the right direction for me, because I for one am not so "PERL-literate" when it comes to pattern matching regex functions. Perhaps you could include a basic explanation on that?

I am trying to develop a small script that can be CRON'ed (or tasked on NT that is...) to automatically log into the POP box, parse the days messages, and add what it matches to a database.

My problem is the pattern matching... is the body usually just stuck into one string handle and parsed with PHP's (fun) string functions?

Anyone wth any experience on this? Seems to be in demand on the other sites too (Although I am a big fan of Devshed ;)

Anxiously awaiting part two...

I'm not sure what you mean by persistence. Perhaps you could explain it a bit better. Your concerns are very reasonable, and I'd like to find a solution to them myself, but I don't think I fully understand the problem

Heya,
Yea, what I meant by persistence of information was the idea that the mail messages themselves would be stored somehow on the server.. i mean.. when one checks mail with something like Netscape Mail or Outlook, one has the option of specifying to "leave messages on server". So, if this feature is not implmented, one would continually see old mails that have previously been read and perhaps should be discarded, etc. The whole notion of persistence, therefore, is in this very feature of "retaining old messages" on the server. I hope this makes my point a bit clearer. Do post maybe as a follow up somehow about ways in which this might actually be done. Thanks,
-Anil.

I'm not sure writing a DB with a message list is a good idea. You're immediately imposing a requirement to update both the POP server and the local DB every time the mailbox state changes - which may end up degrading, rather than improving performance.

I don't think you can implement that here. Don't forget, with Netscape/Outlook, messages get downloaded to the local disk. With a Web-client, they are always read on the server - which (I think) is what you want.

Hi,
hmm... I don't think you quite understood what i was talking about. My point was along the lines of having a POP account checking capability on a service like hotmail or yahoo mail.. in these cases, the messages are retrieved from the pop server, stored on the web server ( or db, etc. ).. and then "reside" in the user's inbox until deletion. This deletion does not necessarily link to the deletion of the mail from the actual pop server's account. I hope this makes things clearer.