So I've been playing with IMAP lately, processing a folder of emails to process. It has been kind of interesting (to say the least).
Those of you who follow my CPAN uploads know I created Net::IMAP::Simple::NB, which is a subclass of Net::IMAP::Simple but using non-blocking I/O. The idea for that originally was to create a webmail system for AxKit2, but it was also fun learning how IMAP works.
There are some really interesting corner issues in IMAP that surprise me. For example an IMAP server is expected to be able to parse MIME messages, and be able to provide different components of the body as requested. This seems odd to me as frankly this should be a client task - surely this slows IMAP servers down? Also when you ask for the body structure it maps it in a very odd manner - though perhaps its useful for clients - there seems to be a lot of structure data there that isn't useful. There are some other odd choices too, like dates are provided as "DD-MON-YYYY" rather than the more ISO compliant "YYYY-MM-DD" format, and email addresses are provided pre-parsed, which means if your IMAP server gets it wrong you're screwed (though I guess that isn't too common).
On the other hand there are some nice things too, like IMAP provides most of its data in an S-expressions-like format, which is quite easy to parse in perl. The RFC is also not as horrible as I had once thought, so decoding various things is reasonably easy. On the other hand, it seems Net::IMAP::Simple is a bit too simplistic, in that it doesn't parse the output formats properly, and honestly doesn't have enough methods in it (I've added 8 methods just for my one simple app).
I'll have to consider contacting the author about patches. Though I'm unsure right now if I want to have too much to do with it in the long term.
Re:You should see how much fun the other side is ;
Matts on 2008-03-05T17:15:04
Nice!
Makes me seriously consider a full MTA suite using qpsmtpd + this...
