Protocol::IMAP::Client - client support for the Internet Message Access Protocol.
package Some::IMAP::Client;
use parent 'Protocol::IMAP::Client';
sub on_message { warn "new message!" }
package main;
my $client = Some::IMAP::Client->new;
$client->login('user', 'pass');
$client->idle;
There are two standard modes of operation:
For one-shot operation against a server that doesn't keep you waiting, other more mature IMAP implementations are suggested ("see also" section).
All requests from the client have a tag, which is a 'unique' alphanumeric identifier - it is the client's responsibility to ensure these are unique for the session, see the next_id method for the implementation used here.
Server responses are always one of three possible states:
with additional 'untagged' responses in between. Any significant data is typically exchanged in the untagged sections - the final response to a command is indicated by a tagged response, once the client receives this then it knows that the server has finished with the original request.
The IMAP connection will be in one of the following states:
State changes are provided by the state method. Some actions run automatically on state changes, for example switching to TLS mode and exchanging login information when server greeting has been received.
The Protocol::IMAP classes only provide the framework for handling IMAP data. Typically you would need to subclass this to get a usable IMAP implementation.
The following methods are required:
Optionally, you may consider providing these:
To pass data back into the Protocol::IMAP layer, you will need the following methods:
Instantiate a new object - the subclass does not need to call this if it hits configure at some point before attempting to transfer data.
Called when there's more data to process for a single-line (standard mode) response.
Called when we have multi-line data (fixed size in characters).
Process an untagged message from the server.
Fetch untagged message data. Defines the multiline callback so that we build up a buffer for the data to process.
Deal with an untagged response with a numeric prefix.
Parse the server greeting, and move on to the capabilities step.
Handle the change of state from 'connected' to 'not authenticated', which indicates that we've had a valid server greeting and it's time to get ourselves authenticated.
Depending on whether we're expecting (and supporting) the STARTTLS upgrade, we'll either switch to TLS mode at this point or just log in directly.
What to do when we've been authenticated and are ready to begin the session. Suggest the subclass overrides this to make it do something useful.
Check the server capabilities, and store them locally.
Virtual method called when we received a message (as the result of an untagged FETCH response).
Virtual method called when there's a new message available in one of the active mailboxes.
Virtual method called when we have capabilities back from the server.
Verify that we had a reasonable response back from the server as an initial greeting, just in case someone pointed us at an SSH listener or something equally unexpected.
Request capabilities from the server.
Returns the next ID in the sequence. Uses a standard Perl increment, tags are suggested to be 'alphanumeric' but with no particular restrictions in place so this should be good for even long-running sessions.
Add a command to the waitlist.
Sometimes we need to wait for the server to catch up before sending the next entry.
TODO - maybe a mergepoint would be better for this?
Generic helper method to send a command to the server.
Issue the LOGIN command.
Takes two parameters:
See also the authenticate command, which does the same thing but via Authen::SASL if I ever get around to writing it.
Check the mailbox status response as received from the server.
Send a null command to the server, used as a keepalive or server ping.
Issue the STARTTLS command in an attempt to get the connection upgraded to something more secure.
Issue the STATUS command for either the given mailbox, or INBOX if none is provided.
Issue the SELECT command to switch to a different mailbox.
Issue the FETCH command to retrieve one or more messages.
Issue the DELETE command, which will delete one or more messages if it can.
Issue an EXPUNGE to clear any deleted messages from storage.
Issue a DONE command, which did something useful and important at the time although I no longer remember what this was.
Switch to IDLE mode. This will put the server into a state where it will continue to send untagged responses as any changes happen to the selected mailboxes.
Returns true if we're in a multiline (fixed size read) state.
Set up any callbacks that were available.
