I wrote a library to perform some basic Imap functions. I saw some throughout the forum but they didn’t seem to work right for me. This can be used with Gmail, Yahoo, or your own shared hosting email setup (as long as you have server access). The main reason I wrote is pretty cool if I must say so myself I don’t have shell access on my server but I wanted people to be able to email me and have my PHP code take those emails and do stuff with them. Well without using a forward script, I’m using this library in a PHP cron job that checks for new mail and takes the date, subject, body, etc. from the email and store it in a database as I please. The functions I have right now are:

- connect()
- current_mailbox()
- msg_count()
- delete()
- mailbox_info()
- switch_mailbox()
- search()
- msg_list()

The functions are quite simple to understand but you will probably have to read up on the different flags that PHP’s Imap functions accept. Other than that, let me know if you have any problems. Enjoy!

http://www.gandylabs.com/ci/imap

hey, this is great work! and your docs are really spiffy

a few things you may want to ignore:
1) i don’t see any decoding in the class - assuming that is left as an exercise for the reader? guaranteed that is the first question you are going to get about this: “why does the subject of the email say =?UTF8?Q?my_subject_here?=”
2) i think you can cast an object to an array and the property names become keys - shorter code for the conversion routine

the imap_pop class on the wiki is focused more on POP functionality (built originally for a moblog) than IMAP so it’s good to see how you approached wrapping the pure IMAP functions. if you are interested, the imap_pop class at the wiki shows how to do attachments and decoding. there is also a utility there that will parse any header string into a nested array of ALL headers instead of just the ones the IMAP class decides you should have.

looking forward to seeing where you take this.

Thanks. I’ll look into the object->array conversion. As far as the decoding goes, there’s none needed. The only decoding that’s done is the “body” element when calling msg_list(). I take the actual body of the email instead of the entire body which includes the specific stuff.

you won’t need decoding if you are only getting emails that don’t have encoded subjects, address (personal component), and other header items.

see here: http://en.wikipedia.org/wiki/MIME in the section on Encoded-Word format for more detail.

cheers.

sophistry - 06 April 2009 03:11 PM

you won’t need decoding if you are only getting emails that don’t have encoded subjects, address (personal component), and other header items.

see here: http://en.wikipedia.org/wiki/MIME in the section on Encoded-Word format for more detail.

cheers.

Yeah the Imap functionality I’m using in PHP is parsing the properties without using the 822 decoding. Certain properties don’t get sent when parsing the headers with rfc822 such as flags, the message #, the size, and the Unix date. I figure those are more important. I’ll just make it an optional parameter.

actually it’s not RFC822, but RFC2047 i was referring to… as far as the encoded subject and personal component of the from address. get the library “out in the wild” (receiving messages from various people and email clients) and you’ll see what i am talking about.

but, i tend to over-engineer things like this! maybe the “don’t anticipate too much too soon” approach is better?

sophistry - 06 April 2009 04:12 PM

actually it’s not RFC822, but RFC2047 i was referring to… as far as the encoded subject and personal component of the from address. get the library “out in the wild” (receiving messages from various people and email clients) and you’ll see what i am talking about.

but, i tend to over-engineer things like this! maybe the “don’t anticipate too much too soon” approach is better?

Ohhh, I’ve already taken care of that. You can either use “fromaddress” index which simply returns the email address OR use the “from” index which is actually Another array with the following indexes: personal, adl, mailbox, and host.

yes, and sometimes the ‘personal’ array index is “Word-Encoded” per RFC2047 so you have to decode it using quoted_printable_decode() or base64_decode() - it will be one or the other if it is encoded. most of the time it won’t be encoded, but it’s safer to detect encodings and handle every personal field as if it is encoded.

the subject data has the same issue.

as a test (to show what i am talking about), use the CI email class to send yourself an email. the CI class encodes the subject in UTF8 quoted printable. when you pick it up with your regular email client (say outlook or whatever) the email client decodes it for you without asking. but in your IMAP class, if you don’t decode it, it is almost unreadable.

sophistry - 06 April 2009 02:51 PM

... this is great work! and your docs are really spiffy

+1

Good work Iverson.

Decoding should now be taken care of. Also, I’m now using PHP’s native ability to create an associative array of defined object accessible non-static properties. Thanks sophistry.

i think you misunderstood my suggestion about quoted_printable_decode(). i see you’ve added a class method _quoted_printable_encode() which does some limited transformation of urlencoded text (using str_replace()) and then runs a preg_replace() looking for “not newline chars” and replacing them with equals signs (some kind of word wrapping routine?). but, that code doesn’t make sense there. that’s the sort of thing you would do to prepare an email to send, not to receive… and the fact that it is named encode rather than decode? i’m not sure what issue the code solves at that point - it seems extra. is there something i am missing?

did you send yourself an email from the CI email lib and look at the source of the email to see the way the CI email lib prepares a quoted_printable encoded subject?