package Mail::IMAPClient; # $Id: IMAPClient.pod,v 20001010.1 2003/06/12 21:35:53 dkernen Exp $ $Mail::IMAPClient::VERSION = '2.2.7'; $Mail::IMAPClient::VERSION = '2.2.7'; # do it twice to make sure it takes =head1 NAME Mail::IMAPClient - An IMAP Client API =head1 DESCRIPTION This module provides methods implementing the IMAP protocol. It allows perl scripts to interact with IMAP message stores. The module is used by constructing or instantiating a new IMAPClient object via the L constructor method. Once the object has been instantiated, the L method is either implicitly or explicitly called. At that point methods are available that implement the IMAP client commands as specified in I. When processing is complete, the I object method should be called. This documentation is not meant to be a replacement for RFC2060, and the wily programmer will have a copy of that document handy when coding IMAP clients. Note that this documentation uses the term I in place of RFC2060's use of I. This documentation reserves the use of the term I to refer to the set of folders owned by a specific IMAP id. RFC2060 defines four possible states for an IMAP connection: not authenticated, authenticated, selected, and logged out. These correspond to the B constants C, C, C, and C, respectively. These constants are implemented as class methods, and can be used in conjunction with the L method to determine the status of an B object and its underlying IMAP session. Note that an B object can be in the C state both before a server connection is made and after it has ended. This differs slightly from RFC2060, which does not define a pre-connection status. For a discussion of the methods available for examining the B object's status, see the section labeled L<"Status Methods">, below. =head2 Advanced Authentication Mechanisms RFC2060 defines two commands for authenticating to an IMAP server: LOGIN for plain text authentication and AUTHENTICATE for more secure authentication mechanisms. Currently Mail::IMAPClient supports CRAM-MD5 and plain text authentication. There are also a number of methods and parameters that you can use to build your own authentication mechanism. Since this topic is a source of many questions, I will provide a quick overview here. All of the methods and parameters discussed here are described in more detail elsewhere in this document; this section is meant to help you get started. First of all, if you just want to do plain text authentication and your server is okay with that idea then you don't even need to read this section. Second of all, the intent of this section is to help you implement the authentication mechanism of your choice, but you will have to understand how that mechanism works. There are I of authentication mechanisms and most of them are not available to me to test with for one reason or another. Even if this section does not answer all of your authentication questions it I contain all the answers that I have, which I admit are scant. Third of all, if you manage to get any advanced authentication mechanisms to work then please consider donating them to this module. I don't quite have a framework visualized for how different authentication mechanisms could "plug in" to this module but I would like to eventually see this module distributed with a number of helper modules to implement various authentication schemes. The B's support for add-on authentication mechanisms is pretty straight forward and is built upon several assumptions. Basically you create a callback to be used to provide the response to the server's challenge. The I parameter contains a reference to the callback, which can be an anonymous subroutine or a named subroutine. Then, you identify your authentication mechanism, either via the I parameter or as an argument to L. You may also need to provide a subroutine to encrypt (or whatever) data before it is sent to the server. The I parameter must contain a reference to this subroutine. And, you will need to decrypt data from the server; a reference to the subroutine that does this must be stored in the I parameter. This framework is based on the assumptions that a) the mechanism you are using requires a challenge-response exchange, and b) the mechanism does not fundamentally alter the exchange between client and server but merely wraps the exchange in a layer of encryption. It particularly assumes that the line-oriented nature of the IMAP conversation is preserved; authentication mechanisms that break up messages into blocks of a predetermined size may still be possible but will certainly be more difficult to implement. Alternatively, if you have access to B, a utility included in the Cyrus IMAP distribution, you can use that utility to broker your communications with the IMAP server. This is quite easy to implement. An example, L, can be found in the C subdirectory of the source distribution. The following list summarizes the methods and parameters that you may find useful in implementing advanced autentication: =over 4 =item authenticate method This method implements the AUTHENTICATE IMAP client command as documented in RFC2060. If you have set the I parameter then the L method will call L instead of doing a clear text login, which is its normal behavior. If you don't want B to call B on your behalf then you can call it yourself. Instead of setting an I you can just pass the authmechanism as the first argument to AUTHENTICATE. =item Socket Parameter The I parameter holds a reference to the socket connection. Normally this is set for you by the L method, but if you are implementing an advanced authentication technique you may choose to set up your own socket connection and then set this parameter manually, bypassing the B method completely. =item State, Server, Password, and User Parameters If you need to make your own connection to the server and perform your authentication manually, then you can set these parameters to keep your B object in sync with its actual status. Of these, only the I parameter is always necessary. The others need to be set only if you think your program will need them later. =item Authmechanism Set this to the value that AUTHENTICATE should send to the server as the authentication mechanism. If you are brokering your own authentication then this parameter may be less useful. It is also not needed by the L method. It exists solely so that you can set it when you call L to instantiate your object. The B method will call L, who will call L. If B sees that you've set an I then it will call B, using your I and I parameters as arguments. =item Authcallback The I parameter, if set, should contain a pointer to a subroutine. The L method will use this as the callback argument to the B method if the I and I parameters are both set. If you set I but not I then the default callback for your mechanism will be used. Unfortunately only the CRAM-MD5 authentication mechanism has a default callback; in every other case not supplying the callback results in an error. Most advanced authentication mechanisms require a challenge-response exchange. After the L method sends " AUTHENTICATE \r\n" to the IMAP server, the server replies with a challenge. The B method then invokes the code whose reference is stored in the I parameter as follows: $Authcallback->($challenge,$imap) where C<$Authcallback> is the code reference stored in the I parameter, C<$challenge> is the challenge received from the IMAP server, and C<$imap> is a pointer to the B object. The return value from the I routine should be the response to the challenge, and that return value will be sent by the L method to the server. =item Readmethod The I parameter points to a routine that will read data from the socket connection. This read method will replace the B that would otherwise be performed by B. The replacement method is called with five arguments. The first is a pointer to the B object; the rest are the four arguments required by the B function. Note the third argument (which corresponds to the second argument to B) is a buffer to read into; this will be a pointer to a scalar. So for example if your I were just going to replace B without any intervening processing (which would be silly but this is just an example after all) then you would set your I like this: $imap->Readmethod( sub { my($self) = shift; my($handle,$buffer,$count,$offset) = @_; return sysread( $handle, $$buffer, $count, $offset); } ); Note particularly the double dollar signs in C<$$buffer> in the B call; this is not a typo! =item Prewritemethod The I, if defined, should contain a pointer to a subroutine. It is called immediately prior to writing to the socket connection. It is called by B with two arguments: a reference to the B object and the ASCII text string to be written. It should return another string that will be the actual string sent to the IMAP server. The idea here is that your I will do whatever encryption is necessary and then return the result to the caller so it in turn can be sent to the server. =back =head2 Errors If you attempt an operation that results in an error, then you can retrieve the text of the error message by using the L method. However, since the L method is an object method (and not a class method) you will only be able to use this method if you've successfully created your object. Errors in the L method can prevent your object from ever being created. Additionally, if you supply the I, I, and I parameters to L, it will attempt to call B and B, either of which could fail and cause your L method call to return C (in which case your object will have been created but its reference will have been discarded before ever having been returned to you). If this happens to you, you can always check C<$@>. B will populate that variable with something useful if either of the L, L, or L methods fail. In fact, as of version 2, the C<$@> variable will always contain error info from the last error, so you can print that instead of calling L if you wish. If you run your script with warnings turned on (which I'm sure you'll do at some point because it's such a good idea) then any error message that gets placed into the L slot (and/or in C<$@>) will automatically generate a warning. =head2 Transactions RFC2060 requires that each line in an IMAP conversation be prefixed with a tag. A typical conversation consists of the client issuing a tag-prefixed command string, and the server replying with one of more lines of output. Those lines of output will include a command completion status code prefixed by the same tag as the original command string. The B module uses a simple counter to ensure that each client command is issued with a unique tag value. This tag value is referred to by the B module as the transaction number. A history is maintained by the B object documenting each transaction. The L method returns the number of the last transaction, and can be used to retrieve lines of text from the object's history. The L parameter is used to control the size of the session history so that long-running sessions do not eat up unreasonable amounts of memory. See the discussion of L under L<"Parameters"> for more information. The L transaction returns the history of the entire IMAP session since the initial connection or for the last I transactions. This provides a record of the entire conversation, including client command strings and server responses, and is a wonderful debugging tool as well as a useful source of raw data for custom parsing. =head1 CLASS METHODS There are a couple of methods that can be invoked as class methods. Generally they can be invoked as an object method as well, as a convenience to the programmer. (That is, as a convenience to the programmer who wrote this module, as well as the programmers using it. It's easier I to enforce a class method's classiness.) Note that if the L method is called as an object method, the object returned is identical to what have would been returned if L had been called as a class method. It doesn't give you a copy of the original object or anything like that. =head2 new Example: Mail::IMAPClient->new(%args) or die "Could not new: $@\n"; The L method creates a new instance of an B object. If the I parameter is passed as an argument to B, then B will implicitly call the L method, placing the new object in the I state. If I and I values are also provided, then L will in turn call L, and the resulting object will be returned from B in the I state. If the I parameter is not supplied then the B object is created in the I state. If the B method is passed arguments then those arguments will be treated as a list of key=>value pairs. The key should be one of the parameters as documented under L<"Parameters">, below. Here are some examples: use Mail::IMAPClient; # returns an unconnected Mail::IMAPClient object: my $imap = Mail::IMAPClient->new; # ... # intervening code using the 1st object, then: # (returns a new, authenticated Mail::IMAPClient object) $imap = Mail::IMAPClient->new( Server => $host, User => $id, Password=> $pass, Clear => 5, # Unnecessary since '5' is the default # ... # Other key=>value pairs go here ) or die "Cannot connect to $host as $id: $@"; See also L<"Parameters">, below, and L<"connect"> and L<"login"> for information on how to manually connect and login after B. =cut =head2 Authenticated Example: $Authenticated = $imap->Authenticated(); # or: $imap->Authenticated($new_value); # But you'll probably never need to do this returns a value equal to the numerical value associated with an object in the B state. This value is normally maintained by the B module, so you typically will only query it and won't need to set it. B For a more programmer-friendly idiom, see the L, L, L, and L object methods. You will usually want to use those methods instead of one of the above. =head2 Connected Example: $Connected = $imap->Connected(); # or: $imap->Connected($new_value); # But you'll probably never need to do this returns a value equal to the numerical value associated with an object in the B state. This value is normally maintained by the B module, so you typically will only query it and won't need to set it. B For a more programmer-friendly idiom, see the L, L, L, and L object methods. You will usually want to use those methods instead of one of the above. =head2 Quote Example: $imap->search(HEADER => 'Message-id' => $imap->Quote($msg_id)); The B method accepts a value as an argument. It returns its argument as a correctly quoted string or a literal string. Note that you should not use this on folder names, since methods that accept folder names as an argument will quote the folder name arguments appropriately for you. (Exceptions to this rule are methods that come with IMAP extensions that are not explicitly supported by B.) If you are getting unexpected results when running methods with values that have (or might have) embedded spaces, double quotes, braces, or parentheses, then you may wish to call B to quote these values. You should B use this method with foldernames or with arguments that are wrapped in quotes or parens if those quotes or parens are there because the RFC2060 spec requires them. So, for example, if RFC requires an argument in this format: ( argument ) and your argument is (or might be) "pennies (from heaven)", then you could just use: $argument = "(" . $imap->Quote($argument) . ")" and be done with it. Of course, the fact that sometimes these characters are sometimes required delimiters is precisely the reason you must quote them when they are I delimiting. For example: $imap->Search('SUBJECT',"(no subject)"); # WRONG! Sends this to imap server: # Search SUBJECT (no subject)\r\n $imap->Search('SUBJECT',$imap->Quote("(no subject)")); # Correct! Sends this to imap server: # Search SUBJECT "(no subject)"\r\n On the other hand: $imap->store('+FLAGS',$imap->Quote("(\Deleted)")); # WRONG! Sends this to imap server: # [UID] STORE +FLAGS "(\Deleted)"\r\n $imap->store($imap->Quota('+FLAGS'),"(\Deleted)"); # CORRECT! Sends this to imap server: # [UID] STORE +FLAGS (\Deleted)\r\n In the above, I had to abandon the many methods available to B programmers (such as L and all-lowercase L) for the sake of coming up with an example. However, there are times when unexpected values in certain places will force you to B. An example is RFC822 Message-id's, which I don't contain quotes or parens. So you don't worry about it, until suddenly searches for certain message-id's fail for no apparent reason. (A failed search is not simply a search that returns no hits; it's a search that flat out didn't happen.) This normally happens to me at about 5:00 pm on the one day when I was hoping to leave on time. (By the way, my experience is that any character that can possibly find its way into a Message-Id eventually will, so when dealing with these values take proactive, defensive measures from the very start. In fact, as I was typing the above, a buddy of mine came in to ask advice about a logfile parsing routine he was writing in which the fields were delimited by colons. One of the fields was a Message Id, and, you guessed it, some of the message id's in the log had (unescaped!) colons embedded in them and were screwing up his C. So there you have it, it's not just me. This is everyone's problem.) =head2 Range Example: my %parsed = $imap->parse_headers( $imap->Range($imap->messages), "Date", "Subject" ); The B method will condense a list of message sequence numbers or message UID's into the most compact format supported by RFC2060. It accepts one or more arguments, each of which can be: =over 8 =item a) a message number, =item b) a comma-separated list of message numbers, =item c) a colon-separated range of message numbers (i.e. "$begin:$end") =item d) a combination of messages and message ranges, separated by commas (i.e. 1,3,5:8,10), or =item e) a reference to an array whose elements are like I through I. =back The B method returns a reference to a B object. The object has all kinds of magic properties, one of which being that if you treat it as if it were just a string it will act like it's just a string. This means you can ignore its objectivity and just treat it like a string whose value is your message set expressed in compact format. You may want to use this method if you find that fetch operations on large message sets seem to take a really long time, or if your server rejects these requests with the claim that the input line is too long. You may also want to use this if you need to add or remove messages to your message set and want an easy way to manage this. For more information on the capabilities of the returned object reference, see L. =head2 Rfc2060_date Example: $Rfc2060_date = $imap->Rfc2060_date($seconds); # or: $Rfc2060_date = Mail::IMAPClient->Rfc2060_date($seconds); The B method accepts one input argument, a number of seconds since the epoch date. It returns an RFC2060 compliant date string for that date (as required in date-related arguments to SEARCH, such as "since", "before", etc.). =head2 Rfc822_date Example: $Rfc822_date = $imap->Rfc822_date($seconds); # or: $Rfc822_date = Mail::IMAPClient->Rfc822_date($seconds); The B method accepts one input argument, a number of seconds since the epoch date. It returns an RFC822 compliant date string for that date (without the 'Date:' prefix). Useful for putting dates in message strings before calling L, L, etcetera. =head2 Selected Example: $Selected = $imap->Selected(); # or: $imap->Selected($new_value); # But you'll probably never need to do this returns a value equal to the numerical value associated with an object in the B state. This value is normally maintained by the B module, so you typically will only query it and won't need to set it. B For a more programmer-friendly idiom, see the L, L, L, and L object methods. You will usually want to use those methods instead of one of the above. =head2 Strip_cr Example: $Strip_cr = $imap->Strip_cr(); # or: $imap->Strip_cr($new_value); The B method strips carriage returns from IMAP client command output. Although RFC2060 specifies that lines in an IMAP conversation end with , it is often cumbersome to have the carriage returns in the returned data. This method accepts one or more lines of text as arguments, and returns those lines with all sequences changed to . Any input argument with no carriage returns is returned unchanged. If the first argument (not counting the class name or object reference) is an array reference, then members of that array are processed as above and subsequent arguments are ignored. If the method is called in scalar context then an array reference is returned instead of an array of results. Taken together, these last two lines mean that you can do something like: my @list = $imap->some_imap_method ; @list = $imap->Strip_cr(@list) ; # or: my $list = [ $imap->some_imap_method ] ; # returns an array ref $list = $imap->Strip_cr($list); B does not remove new line characters. =cut =head2 Unconnected Example: $Unconnected = $imap->Unconnected(); # or: $imap->Unconnected($new_value); returns a value equal to the numerical value associated with an object in the B state. This value is normally maintained by the B module, so you typically will only query it and won't need to set it. B For a more programmer-friendly idiom, see the L, L, L, and L object methods. You will usually want to use those methods instead of one of the above. =head1 OBJECT METHODS Object methods must be invoked against objects created via the L method. They cannot be invoked as class methods, which is why they are called "object methods" and not "class methods". There are basically two types of object methods--mailbox methods, which participate in the IMAP session's conversation (i.e. they issue IMAP client commands) and object control methods, which do not result in IMAP commands but which may affect later commands or provide details of previous ones. This latter group can be further broken down into two types, Parameter accessor methods, which affect the behavior of future mailbox methods, and Status methods, which report on the affects of previous mailbox methods. Methods that do not result in new IMAP client commands being issued (such as the L, L, and L methods) all begin with an uppercase letter, to distinguish them from methods that do correspond to IMAP client commands. Class methods and eponymous parameter methods likewise begin with an uppercase letter because they also do not correspond to an IMAP client command. As a general rule, mailbox control methods return C on failure and something besides C when they succeed. This rule is modified in the case of methods that return search results. When called in a list context, searches that do not find matching results return an empty list. When called in a scalar context, searches with no hits return 'undef' instead of an array reference. If you want to know why you received no hits, you should check C<$@>, which will be empty if the search was successful but had no matching results but populated with an error message if the search encountered a problem (such as invalid parameters). A number of IMAP commands do not have corresponding B methods. Instead, they are implemented via a default method and Perl's L facility. If you are looking for a specific IMAP client command (or IMAP extension) and do not see it documented in this pod, then that does not necessarily mean you can not use B to issue the command. In fact, you can issue almost any IMAP client command simply by I that there is a corresponding B method. See the section on L<"Other IMAP Client Commands and the Default Object Method"> below for details on the default method. =head1 Mailbox Control Methods =head2 append Example: my $uid = $imap->append($folder,$msg_text) or die "Could not append: $@\n"; The B method adds a message to the specified folder. It takes two arguments, the name of the folder to append the message to, and the text of the message (including headers). Additional arguments are added to the message text, separated with . The B method returns the UID of the new message (a true value) if successful, or C if not, if the IMAP server has the UIDPLUS capability. If it doesn't then you just get true on success and undef on failure. Note that many servers will get really ticked off if you try to append a message that contains "bare newlines", which is the titillating term given to newlines that are not preceded by a carrage return. To protect against this, B will insert a carrage return before any newline that is "bare". If you don't like this behavior then you can avoid it by not passing naked newlines to B. Note that B does not allow you to specify the internal date or initial flags of an appended message. If you need this capability then use L, below. =cut =head2 append_file Example: my $new_msg_uid = $imap->append_file( $folder, $filename [ , $input_record_separator ] # optional (not arrayref) ) or die "Could not append_file: $@\n"; The B method adds a message to the specified folder. It takes two arguments, the name of the folder to append the message to, and the file name of an RFC822-formatted message. An optional third argument is the value to use for C. The default is to use "" for the first read (to get the headers) and "\n" for the rest. Any valid value for C<$/> is acceptable, even the funky stuff, like C<\1024>. (See L for more information on C<$/>). (The brackets in the example indicate that this argument is optional; they do not mean that the argument should be an array reference.) The B method returns the UID of the new message (a true value) if successful, or C if not, if the IMAP server has the UIDPLUS capability. If it doesn't then you just get true on success and undef on failure. If you supply a filename that doesn't exist then you get an automatic C. The L method will remind you of this if you forget that your file doesn't exist but somehow manage to remember to check L. In case you're wondering, B is provided mostly as a way to allow large messages to be appended without having to have the whole file in memory. It uses the C<-s> operator to obtain the size of the file and then reads and sends the contents line by line (or not, depending on whether you supplied that optional third argument). =cut =head2 append_string Example: # brackets indicate optional arguments (not array refs): my $uid = $imap->append_string( $folder, $text [ , $flags [ , $date ] ]) or die "Could not append_string: $@\n"; The B method adds a message to the specified folder. It requires two arguments, the name of the folder to append the message to, and the text of the message (including headers). The message text must be included in a single string (unlike L, above). You can optionally specify a third and fourth argument to B. The third argument, if supplied, is the list of flags to set for the appended message. The list must be specified as a space-separated list of flags, including any backslashes that may be necessary. The enclosing parentheses that are required by RFC2060 are optional for B. The fourth argument, if specified, is the date to set as the internal date. It should be in the format described for I fields in RFC2060, i.e. "dd-Mon-yyyy hh:mm:ss +0000". If you want to specify a date/time but you don't want any flags then specify I as the third argument. The B method returns the UID of the new message (a true value) if successful, or C if not, if the IMAP server has the UIDPLUS capability. If it doesn't then you just get true on success and undef on failure. Note that many servers will get really ticked off if you try to append a message that contains "bare newlines", which is the titillating term given to newlines that are not preceded by a carrage return. To protect against this, B will insert a carrage return before any newline that is "bare". If you don't like this behavior then you can avoid it by not passing naked newlines to B. =cut =head2 authenticate Example: $imap->authenticate($authentication_mechanism, $coderef) or die "Could not authenticate: $@\n"; The B method accepts two arguments, an authentication type to be used (ie CRAM-MD5) and a code or subroutine reference to execute to obtain a response. The B method assumes that the authentication type specified in the first argument follows a challenge-response flow. The B method issues the IMAP Client AUTHENTICATE command and receives a challenge from the server. That challenge (minus any tag prefix or enclosing '+' characters but still in the original base64 encoding) is passed as the only argument to the code or subroutine referenced in the second argument. The return value from the 2nd argument's code is written to the server as is, except that a sequence is appended if neccessary. If one or both of the arguments are not specified in the call to B but their corresponding parameters have been set (I and I, respectively) then the parameter values are used. Arguments provided to the method call however will override parameter settings. If you do not specify a second argument and you have not set the I parameter, then the first argument must be one of the authentication mechanisms for which B has built in support. Currently there is only built in support for CRAM-MD5, but I hope to add more in future releases. If you are interested in doing NTLM authentication then please see Mark Bush's L, which can work with B to provide NTLM authentication. See also the L method, which is the simplest form of authentication defined by RFC2060. =cut =head2 before Example: my @msgs = $imap->before($Rfc2060_date) or warn "No messages found before $Rfc2060_date.\n"; The B method works just like the L<"since"> method, below, except it returns a list of messages whose internal system dates are before the date supplied as the argument to the B method. =cut =head2 body_string Example: my $string = $imap->body_string($msgId) or die "Could not body_string: $@\n"; The B method accepts a message sequence number (or a message UID, if the L parameter is set to true) as an argument and returns the message body as a string. The returned value contains the entire message in one scalar variable, without the message headers. =cut =head2 bodypart_string Example: my $string=$imap->bodypart_string( $msgid, $part_number , $length ,$offset ) or die "Could not get bodypart string: $@\n"; The B method accepts a message sequence number (or a message UID, if the L parameter is set to true) and a body part as arguments and returns the message part as a string. The returned value contains the entire message part (or, optionally, a portion of the part) in one scalar variable. If an optional third argument is provided, that argument is the number of bytes to fetch. (The default is the whole message part.) If an optional fourth argument is provided then that fourth argument is the offset into the part at which the fetch should begin. The default is offset zero, or the beginning of the message part. If you specify an offset without specifying a length then the offset will be ignored and the entire part will be returned. B will return C if it encounters an error. =cut =head2 capability Example: my @features = $imap->capability or die "Could not determine capability: $@\n"; The B method returns an array of capabilities as returned by the CAPABILITY IMAP Client command, or a reference to an array of capabilities if called in scalar context. If the CAPABILITY IMAP Client command fails for any reason then the B method will return C. =head2 close Example: $imap->close or die "Could not close: $@\n"; The B method is implemented via the default method and is used to close the currently selected folder via the CLOSE IMAP client command. According to RFC2060, the CLOSE command performs an implicit EXPUNGE, which means that any messages that you've flagged as I<\Deleted> (say, with the L method) will now be deleted. If you haven't deleted any messages then B can be thought of as an "unselect". Note again that this closes the currently selected folder, not the IMAP session. See also L, L, and your tattered copy of RFC2060. =head2 connect Example: $imap->connect or die "Could not connect: $@\n"; The B method connects an imap object to the server. It returns C if it fails to connect for any reason. If values are available for the I and I parameters at the time that B is invoked, then B will call the L method after connecting and return the result of the L method to B's caller. If either or both of the I and I parameters are unavailable but the connection to the server succeeds then B returns a pointer to the B object. The I parameter must be set (either during L method invocation or via the L object method) before invoking B. If the L parameter is supplied to the L method then B is implicitly called during object construction. The B method sets the state of the object to C if it successfully connects to the server. It returns C on failure. =head2 copy Example: # Here brackets indicate optional arguments: my $uidList = $imap->copy($folder, $msg_1 [ , ... , $msg_n ]) or die "Could not copy: $@\n"; Or: # Now brackets indicate an array ref! my $uidList = $imap->copy($folder, [ $msg_1, ... , $msg_n ]) or die "Could not copy: $@\n"; The B method requires a folder name as the first argument, and a list of one or more messages sequence numbers (or messages UID's, if the I parameter is set to a true value). The message sequence numbers or UID's should refer to messages in the currenly selected folder. Those messages will be copied into the folder named in the first argument. The B method returns C on failure and a true value if successful. If the server to which the current Mail::IMAPClient object is connected supports the UIDPLUS capability then the true value returned by B will be a comma separated list of UID's, which are the UID's of the newly copied messages in the target folder. =cut =head2 create Example: $imap->create($new_folder) or die "Could not create $new_folder: $@\n"; The B method accepts one argument, the name of a folder (or what RFC2060 calls a "mailbox") to create. If you specifiy additional arguments to the B method and your server allows additional arguments to the CREATE IMAP client command then the extra argument(s) will be passed to your server. If you specifiy additional arguments to the B method and your server does not allow additional arguments to the CREATE IMAP client command then the extra argument(s) will still be passed to your server and the create will fail, so don't do that. B returns a true value on success and C on failure, as you've probably guessed. =head2 date Example: my $date = $imap->date($msg); The B method accepts one argument, a message sequence number (or a message UID if the I parameter is set to a true value). It returns the date of message as specified in the message's RFC822 "Date: " header, without the "Date: " prefix. The B method is a short-cut for: my $date = $imap->get_header($msg,"Date"); =head2 delete Example: $imap->delete($folder) or die "Could not delete $folder: $@\n"; The B method accepts a single argument, the name of a folder to delete. It returns a true value on success and C on failure. =head2 delete_message Example: my @msgs = $imap->seen; scalar(@msgs) and $imap->delete_message(\@msgs) or die "Could not delete_message: $@\n"; The above could also be rewritten like this: # scalar context returns array ref my $msgs = scalar($imap->seen); scalar(@$msgs) and $imap->delete_message($msgs) or die "Could not delete_message: $@\n"; Or, as a one-liner: $imap->delete_message( scalar($imap->seen) ) or warn "Could not delete_message: $@\n"; # just give warning in case failure is # due to having no 'seen' msgs in the 1st place! The B method accepts a list of arguments. If the L parameter is not set to a true value, then each item in the list should be either: =over 4 =item > a message sequence number, =item > a comma-separated list of message sequence numbers, =item > a reference to an array of message sequence numbers, or =back If the L parameter is set to a true value, then each item in the list should be either: =over 4 =item > a message UID, =item > a comma-separated list of UID's, or =item > a reference to an array of message UID's. =back The messages identified by the sequence numbers or UID's will be deleted. If successful, B returns the number of messages it was told to delete. However, since the delete is done by issuing the I<+FLAGS.SILENT> option of the STORE IMAP client command, there is no guarantee that the delete was successful for every message. In this manner the B method sacrifices accuracy for speed. Generally, though, if a single message in a list of messages fails to be deleted it's because it was already deleted, which is what you wanted anyway so why worry about it? If there is a more severe error, i.e. the server replies "NO", "BAD", or, banish the thought, "BYE", then B will return C. If you must have guaranteed results then use the IMAP STORE client command (via the default method) and use the +FLAGS (\Deleted) option, and then parse your results manually. Eg: $imap->store($msg_id,'+FLAGS (\Deleted)'); my @results = $imap->History($imap->Transaction); ... # code to parse output goes here (Frankly I see no reason to bother with any of that; if a message doesn't get deleted it's almost always because it's already not there, which is what you want anyway. But 'your milage may vary' and all that.) The B object must be in C status to use the B method. B All the messages identified in the input argument(s) must be in the currently selected folder. Failure to comply with this requirement will almost certainly result in the wrong message(s) being deleted. This would be a crying shame. B In the grand tradition of the IMAP protocol, deleting a message doesn't actually delete the message. Really. If you want to make sure the message has been deleted, you need to expunge the folder (via the L method, which is implemented via the default method). Or at least L it. This is generally considered a feature, since after deleting a message, you can change your mind and undelete it at any time before your L or L. I The L method, to delete a folder, the L method, to expunge a folder, the L method to undelete a message, and the L method (implemented here via the default method) to close a folder. Oh, and don't forget about RFC2060. =cut =head2 deny_seeing Example: # Reset all read msgs to unread # (produces error if there are no seen msgs): $imap->deny_seeing( scalar($imap->seen) ) or die "Could not deny_seeing: $@\n" ; The B method accepts a list of one or more message sequence numbers, or a single reference to an array of one or more message sequence numbers, as its argument(s). It then unsets the "\Seen" flag for those messages (so that you can "deny" that you ever saw them). Of course, if the L parameter is set to a true value then those message sequence numbers should be unique message id's. Note that specifying C<$imap-Edeny_seeing(@msgs)> is just a shortcut for specifying C<$imap-Eunset_flag("Seen",@msgs)>. =cut =head2 disconnect Example: $imap->disconnect or warn "Could not disconnect: $@\n"; Disconnects the B object from the server. Functionally equivalent to the L method. (In fact it's actually a synonym for L.) =cut =head2 done Example: my $idle = $imap->idle or warn "Couldn't idle: $@\n"; &goDoOtherThings; $imap->done($idle) or warn "Error from done: $@\n"; The B method tells the IMAP server that the connection is finished idling. See L for more information. It accepts one argument, which is the transaction number you received from the previous call to L. If you pass the wrong transaction number to B then your perl program will probably hang. If you don't pass any transaction number to B then it will try to guess, and if it guesses wrong it will hang. If you call done without previously having called L then your server will mysteriously respond with I<* BAD Invalid tag>. If you try to run any other mailbox method after calling L but before calling L, then that method will not only fail but also take you out of the IDLE state. This means that when you eventually remember to call B you will just get that I<* BAD Invalid tag> thing again. =head2 examine Example: $imap->examine($folder) or die "Could not examine: $@\n"; The B method selects a folder in read-only mode and changes the object's state to "Selected". The folder selected via the B method can be examined but no changes can be made unless it is first selected via the L or L method to select it instead of trying something funky). Note that RFC2683 contains warnings about the use of the IMAP I command (and thus the L method and therefore the B method) against the currenlty selected folder. You should carefully consider this before using B on the currently selected folder. You may be better off using L or one of its variants (especially L), and then counting the results. On the other hand, I regularly violate this rule on my server without suffering any dire consequences. Your milage may vary. =cut =head2 message_string Example: my $string = $imap->message_string($msgid) or die "Could not message_string: $@\n"; The B method accepts a message sequence number (or message UID if L is true) as an argument and returns the message as a string. The returned value contains the entire message in one scalar variable, including the message headers. Note that using this method will set the message's "\Seen" flag as a side effect, unless I is set to a true value. =cut =head2 message_to_file Example: $imap->message_to_file($file,@msgs) or die "Could not message_to_file: $@\n"; The B method accepts a filename or file handle and one or more message sequence numbers (or message UIDs if L is true) as arguments and places the message string(s) (including RFC822 headers) into the file named in the first argument (or prints them to the filehandle, if a filehandle is passed). The returned value is true on succes and C on failure. If the first argument is a reference, it is assumed to be an open filehandle and will not be closed when the method completes, If it is a file, it is opened in append mode, written to, then closed. Note that using this method will set the message's "\Seen" flag as a side effect. But you can use the L method to set it back, or set the L parameter to a true value to prevent setting the "\Seen" flag at all. This method currently works by making some basic assumptions about the server's behavior, notably that the message text will be returned as a literal string but that nothing else will be. If you have a better idea then I'd like to hear it. =cut =head2 message_uid Example: my $msg_uid = $imap->message_uid($msg_seq_no) or die "Could not get uid for $msg_seq_no: $@\n"; The B method accepts a message sequence number (or message UID if L is true) as an argument and returns the message's UID. Yes, if L is true then it will use the IMAP UID FETCH UID client command to obtain and return the very same argument you supplied. This is an IMAP feature so don't complain to me about it. =cut =head2 messages Example: # Get a list of messages in the current folder: my @msgs = $imap->messages or die "Could not messages: $@\n"; # Get a reference to an array of messages in the current folder: my $msgs = $imap->messages or die "Could not messages: $@\n"; If called in list context, the B method returns a list of all the messages in the currenlty selected folder. If called in scalar context, it returns a reference to an array containing all the messages in the folder. If you have the L parameter turned off, then this is the same as specifying C<1 ... $imap-EL>; if you have UID set to true then this is the same as specifying C<$imap-EL("ALL")>. =cut =head2 migrate Example: $imap->migrate($imap_2, "ALL", $targetFolder ) or die "Could not migrate: $@\n"; The B method copies the indicated messages B the currently selected folder B another B object's session. It requires these arguments: =over 4 =item 1. a reference to the target B object (not the calling object, which is connected to the source account); =item 2. the message(s) to be copied, specified as either a) the message sequence number (or message UID if the UID parameter is true) of a single message, b) a reference to an array of message sequence numbers (or message UID's if the UID parameter is true) or c) the special string "ALL", which is a shortcut for the results of C("ALL")>. =item 3. the folder name of a folder on the target mailbox to receive the message(s). If this argument is not supplied or if I is supplied then a folder with the same name as the currently selected folder on the calling object will be created if necessary and used. If you specify something other then I for this argument, even if it's '$imap1-EFolder' or the name of the currently selected folder, then that folder will only be used if it exists on the target object's mailbox; if it does not exist then B will fail. =back The target B object should not be the same as the source. The source object is the calling object, i.e. the one whose B method will be used. It cannot be the same object as the one specified as the target, even if you are for some reason migrating between folders on the same account (which would be silly anyway, since L can do that much more efficiently). If you try to use the same B object for both the caller and the reciever then they'll both get all screwed up and it will be your fault because I just warned you and you didn't listen. B will download messages from the source in chunks to minimize memory usage. The size of the chunks can be controlled by changing the source B object's the L parameter. The higher the L value, the faster the migration, but the more memory your program will require. TANSTAAFL. (See the L parameter and eponymous accessor method, described above under the L<"Parameters"> section.) The B method uses Black Magic to hardwire the I/O between the two B objects in order to minimize resource consumption. If you have older scripts that used L and L to move large messages between IMAP mailboxes then you may want to try this method as a possible replacement. =head2 move Example: my $newUid = $imap->move($newFolder, $oldUid) or die "Could not move: $@\n"; $imap->expunge; The B method moves messages from the currently selected folder to the folder specified in the first argument to B. If the L parameter is not true, then the rest of the arguments should be either: =over 4 =item > a message sequence number, =item > a comma-separated list of message sequence numbers, or =item > a reference to an array of message sequence numbers. =back If the L parameter is true, then the arguments should be: =over 4 =item > a message UID, =item > a comma-separated list of message UID's, or =item > a reference to an array of message UID's. =back If the target folder does not exist then it will be created. If move is sucessful, then it returns a true value. Furthermore, if the B object is connected to a server that has the UIDPLUS capability, then the true value will be the comma-separated list of UID's for the newly copied messages. The list will be in the order in which the messages were moved. (Since B uses the copy method, the messages will be moved in numerical order.) If the move is not successful then B returns C. Note that a move really just involves copying the message to the new folder and then setting the I<\Deleted> flag. To actually delete the original message you will need to run L (or L). =cut =head2 namespace Example: my @refs = $imap->namespace or die "Could not namespace: $@\n"; The namespace method runs the NAMESPACE IMAP command (as defined in RFC 2342). When called in a list context, it returns a list of three references. Each reference looks like this: [ [ $prefix_1, $separator_1 ] , [ $prefix_2, $separator_2 ], [ $prefix_n , $separator_n] ] The first reference provides a list of prefices and separator charactors for the available personal namespaces. The second reference provides a list of prefices and separator charactors for the available shared namespaces. The third reference provides a list of prefices and separator charactors for the available public namespaces. If any of the three namespaces are unavailable on the current server then an 'undef' is returned instead of a reference. So for example if shared folders were not supported on the server but personal and public namespaces were both available (with one namespace each), the returned value might resemble this: ( [ "", "/" ] , undef, [ "#news", "." ] ) ; If the B method is called in scalar context, it returns a reference to the above-mentioned list of three references, thus creating a single structure that would pretty-print something like this: $VAR1 = [ [ [ $user_prefix_1, $user_separator_1 ] , [ $user_prefix_2, $user_separator_2], [ $user_prefix_n , $user_separator_n] ] , # or undef [ [ $shared_prefix_1, $shared_separator_1 ] , [ $shared_prefix_2, $shared_separator_2], [ $shared_prefix_n , $shared_separator_n] ] , # or undef [ [ $public_prefix_1, $public_separator_1 ] , [ $public_prefix_2, $public_separator_2], [ $public_prefix_n , $public_separator_n] ] , # or undef ]; Or, to look at our previous example (where shared folders are unsupported) called in scalar context: $VAR1 = [ [ [ "" , "/", ], ], undef, [ [ "#news", "." ], ], ]; =cut =head2 on Example: my @msgs = $imap->on($Rfc2060_date) or warn "Could not find messages sent on $Rfc2060_date: $@\n"; The B method works just like the L method, below, except it returns a list of messages whose internal system dates are the same as the date supplied as the argument. =head2 parse_headers Example: my $hashref = $imap->parse_headers($msg||@msgs, "Date", "Subject") or die "Could not parse_headers: $@\n"; The B method accepts as arguments a message sequence number and a list of header fields. It returns a hash reference in which the keys are the header field names (without the colon) and the values are references to arrays of values. A picture would look something like this: $hashref = $imap->parse_headers(1,"Date","Received","Subject","To"); $hashref = { "Date" => [ "Thu, 09 Sep 1999 09:49:04 -0400" ] , "Received" => [ q/ from mailhub ([111.11.111.111]) by mailhost.bigco.com (Netscape Messaging Server 3.6) with ESMTP id AAA527D for ; Fri, 18 Jun 1999 16:29:07 +0000 /, q/ from directory-daemon by mailhub.bigco.com (PMDF V5.2-31 #38473) id <0FDJ0010174HF7@mailhub.bigco.com> for bigshot@bigco.com (ORCPT rfc822;big.shot@bigco.com); Fri, 18 Jun 1999 16:29:05 +0000 (GMT) /, q/ from someplace ([999.9.99.99]) by smtp-relay.bigco.com (PMDF V5.2-31 #38473) with ESMTP id <0FDJ0000P74H0W@smtp-relay.bigco.com> for big.shot@bigco.com; Fri, 18 Jun 1999 16:29:05 +0000 (GMT) /] , "Subject" => [ qw/ Help! I've fallen and I can't get up!/ ] , "To" => [ "Big Shot ] , } ; The text in the example for the "Received" array has been formated to make reading the example easier. The actual values returned are just strings of words separated by spaces and with newlines and carriage returns stripped off. The I header is probably the main reason that the B method creates a hash of lists rather than a hash of values. If the second argument to B is 'ALL' or if it is unspecified then all available headers are included in the returned hash of lists. If you're not emotionally prepared to deal with a hash of lists then you can always call the L method yourself with the appropriate parameters and parse the data out any way you want to. Also, in the case of headers whose contents are also reflected in the envelope, you can use the L method as an alternative to L. If the L parameter is true then the first argument will be treated as a message UID. If the first argument is a reference to an array of message sequence numbers (or UID's if L is true), then B will be run against each message in the array. In this case the return value is a hash, in which the key is the message sequence number (or UID) and the value is a reference to a hash as described above. An example of using B to print the date and subject of every message in your smut folder could look like this: use Mail::IMAPClient; my $imap = Mail::IMAPClient->new( Server => $imaphost, User => $login, Password=> $pass, Uid => 1, # optional ); $imap->select("smut"); for my $h ( # grab the Subject and Date from every message in my (fictional!) smut folder; # the first argument is a reference to an array listing all messages in the folder # (which is what gets returned by the $imap->search("ALL") method when called in # scalar context) and the remaining arguments are the fields to parse out # The key is the message number, which in this case we don't care about: values %{$imap->parse_headers( scalar($imap->search("ALL")) , "Subject", "Date")} ) { # $h is the value of each element in the hash ref returned from parse_headers, # and $h is also a reference to a hash. # We'll only print the first occurance of each field because we don't expect more # than one Date: or Subject: line per message. print map { "$_:\t$h->{$_}[0]\n"} keys %$h ; } =cut =head2 recent Example: my @recent = $imap->recent or warn "No recent msgs: $@\n"; The B method performs an IMAP SEARCH RECENT search against the selected folder and returns an array of sequence numbers (or UID's, if the L parameter is true) of messages that are recent. =cut =head2 recent_count Example: my $count = 0; defined($count = $imap->recent_count($folder)) or die "Could not recent_count: $@\n"; The B method accepts as an argument a folder name. It returns the number of recent messages in the folder (as returned by the IMAP client command "STATUS folder RECENT"), or C in the case of an error. The B method was contributed by Rob Deker (deker@ikimbo.com). =cut =head2 rename Example: $imap->rename($oldname,$nedwname) or die "Could not rename: $@\n"; The B method accepts two arguments: the name of an existing folder, and a new name for the folder. The existing folder will be renamed to the new name using the RENAME IMAP client command. B will return a true value if successful, or C if unsuccessful. =cut =head2 restore_message Example: $imap->restore_message(@msgs) or die "Could not restore_message: $@\n"; The B method is used to undo a previous L operation (but not if there has been an intervening L or L). The B object must be in L status to use the B method. The B method accepts a list of arguments. If the L parameter is not set to a true value, then each item in the list should be either: =over 4 =item > a message sequence number, =item > a comma-separated list of message sequence numbers, =item > a reference to an array of message sequence numbers, or =back If the L parameter is set to a true value, then each item in the list should be either: =over 4 =item > a message UID, =item > a comma-separated list of UID's, or =item > a reference to an array of message UID's. =back The messages identified by the sequence numbers or UID's will have their I<\Deleted> flags cleared, effectively "undeleting" the messages. B returns the number of messages it was able to restore. Note that B is similar to calling C("\Deleted",@msgs)>, except that B returns a (slightly) more meaningful value. Also it's easier to type. =cut =head2 run Example: $imap->run(@args) or die "Could not run: $@\n"; Like Perl itself, the B module is designed to make common things easy and uncommon things possible. The B method is provided to make those uncommon things possible. The B method excepts one or two arguments. The first argument is a string containing an IMAP Client command, including a tag and all required arguments. The optional second argument is a string to look for that will indicate success. (The default is C). The B method returns an array of output lines from the command, which you are free to parse as you see fit. The B method does not do any syntax checking, other than rudimentary checking for a tag. When B processes the command, it increments the transaction count and saves the command and responses in the History buffer in the same way other commands do. However, it also creates a special entry in the History buffer named after the tag supplied in the string passed as the first argument. If you supply a numeric value as the tag then you may risk overwriting a previous transaction's entry in the History buffer. If you want the control of B but you don't want to worry about the damn tags then see L<"tag_and_run">, below. =cut =head2 search Example: my @msgs = $imap->search(@args) or warn "search: None found\n"; if ($@) { warn "Error in search: $@\n"; } The B method implements the SEARCH IMAP client command. Any argument supplied to B is prefixed with a space and appended to the SEARCH IMAP client command. This method is another one of those situations where it will really help to have your copy of RFC2060 handy, since the SEARCH IMAP client command contains a plethora of options and possible arguments. I'm not going to repeat them here. Remember that if your argument needs quotes around it then you must make sure that the quotes will be preserved when passing the argument. I.e. use C instead of C<"$arg">. When in doubt, use the L method. The B method returns an array containing sequence numbers of messages that passed the SEARCH IMAP client command's search criteria. If the L parameter is true then the array will contain message UID's. If B is called in scalar context then a pointer to the array will be passed, instead of the array itself. If no messages meet the criteria then B returns an empty list (when in list context) or C (in scalar context). Since a valid, successful search can legitimately return zero matches, you may wish to distinguish between a search that correctly returns zero hits and a search that has failed for some other reason (i.e. invalid search parameters). Therefore, the C<$@> variable will always be cleared before the I command is issued to the server, and will thus remain empty unless the server gives a I or I response to the I command. =cut =head2 see Example: $imap->see(@msgs) or die "Could not see: $@\n"; The B method accepts a list of one or more messages sequence numbers, or a single reference to an array of one or more message sequence numbers, as its argument(s). It then sets the I<\Seen> flag for those message(s). Of course, if the L parameter is set to a true value then those message sequence numbers had better be unique message id's, but then you already knew that, didn't you? Note that specifying C<$imap-Esee(@msgs)> is just a shortcut for specifying C<$imap-EL("Seen",@msgs)>. =cut =head2 seen Example: my @seenMsgs = $imap->seen or warn "No seen msgs: $@\n"; The B method performs an IMAP SEARCH SEEN search against the selected folder and returns an array of sequence numbers of messages that have already been seen (ie their I<\Seen> flag is set). If the L parameter is true then an array of message UID's will be returned instead. If called in scalar context than a reference to the array (rather than the array itself) will be returned. =cut =head2 select Example: $imap->select($folder) or die "Could not select: $@\n"; The B method (or L or L object methods for that. Generally, the I parameter should only be queried (by using the no-argument form of the B method). You will only need to set the I parameter if you use some mysterious technique of your own for selecting a folder, which you probably won't do. =cut =head2 Maxtemperrors Example: $Maxtemperrors = $imap->Maxtemperrors(); # or: $imap->Maxtemperrors($new_value); The I parameter specifies the number of times a write operation is allowed to fail on a "Resource Temporarily Available" error. These errors can occur from time to time if the server is too busy to empty out its read buffer (which is logically the "other end" of the client's write buffer). By default, B will retry an unlimited number of times, but you can adjust this behavior by setting I. Note that after each temporary error, the server will wait for a number of seconds equal to the number of consecutive temporary errors times .25, so very high values for I can slow you down in a big way if your "temporary error" is not all that temporary. You can set this parameter to "UNLIMITED" to ignore "Resource Temporarily Unavailable" errors. This is the default. =head2 Password Example: $Password = $imap->Password(); # or: $imap->Password($new_value); Specifies the password to use when logging into the IMAP service on the host specified in the I parameter as the user specified in the I parameter. Can be supplied with the B method call or separately by calling the B object method. If I, I, and I are all provided to the L method, then the newly instantiated object will be connected to the host specified in I (at either the port specified in I or the default port 143) and then logged on as the user specified in the I parameter (using the password provided in the I parameter). See the discussion of the L<"new"> method, below. =head2 Peek Example: $Peek = $imap->Peek(); # or: $imap->Peek($true_or_false); Setting I to a true value will prevent the L, L and L methods from automatically setting the I<\Seen> flag. Setting L<"Peek"> to 0 (zero) will force L<"body_string">, L<"message_string">, L<"message_to_file">, and L<"parse_headers"> to always set the I<\Seen> flag. The default is to set the seen flag whenever you fetch the body of a message but not when you just fetch the headers. Passing I to the eponymous B method will reset the I parameter to its pristine, default state. =cut =head2 Port Example: $Port = $imap->Port(); # or: $imap->Port($new_value); Specifies the port on which the IMAP server is listening. The default is 143, which is the standard IMAP port. Can be supplied with the L method call or separately by calling the L object method. =head2 Prewritemethod Specifies a method to call if your authentication mechanism requires you to to do pre-write processing of the data sent to the server. If defined, then the I parameter should contain a reference to a subroutine that will do Special Things to data before it is sent to the IMAP server (such as encryption or signing). This method will be called immediately prior to sending an IMAP client command to the server. Its first argument is a reference to the I object and the second argument is a string containing the command that will be sent to the server. Your I should return a string that has been signed or encrypted or whatever; this returned string is what will actually be sent to the server. Your I will probably need to know more than this to do whatever it does. It is recommended that you tuck all other pertinent information into a hash, and store a reference to this hash somewhere where your method can get to it, possibly in the I object itself. Note that this method should not actually send anything over the socket connection to the server; it merely converts data prior to sending. If you need a I then you probably need a L as well. =head2 Ranges Example: $imap->Ranges(1); # or: my $search = $imap->search(@search_args); if ( $imap->Ranges) { # $search is a MessageSet object print "This is my condensed search result: $search\n"; print "This is every message in the search result: ", join(",",@$search),"\n; } If set to a true value, then the L method will return a L object if called in a scalar context, instead of the array reference that B normally returns when called in a scalar context. If set to zero or if undefined, then B will continue to return an array reference when called in scalar context. This parameter has no affect on the B method when B is called in a list context. =head2 Readmethod This parameter, if supplied, should contain a reference to a subroutine that will replace sysreads. The subroutine will be passed the following arguments: =over 4 1. imap_object_ref - a reference to the current imap object 2. scalar_ref - a reference to a scalar variable into which data is read. The data place in here should be "finished data", so if you are decrypting or removing signatures then be sure to do that before you place data into this buffer. 3. read_length - the number of bytes requested to be read 4. offset - the offset into C into which data should be read. If not supplied it should default to zero. =back Note that this method completely replaces reads from the connection to the server, so if you define one of these then your subroutine will have to actually do the read. It is for things like this that we have the L parameter and eponymous accessor method. Your I will probably need to know more than this to do whatever it does. It is recommended that you tuck all other pertinent information into a hash, and store a reference to this hash somewhere where your method can get to it, possibly in the I object itself. If you need a I then you probably need a L as well. =head2 Server Example: $Server = $imap->Server(); # or: $imap->Server($hostname); Specifies the hostname or IP address of the host running the IMAP server. If provided as part of the L method call, then the new IMAP object will automatically be connected at the time of instantiation. (See the L method, below.) Can be supplied with the L method call or separately by calling the B object method. =cut =head2 Showcredentials Normally debugging output will mask the login credentials when the plain text login mechanism is used. Setting I to a true value will suppress this, so that you can see the string being passed back and forth during plain text login. Only set this to true when you are debugging problems with the IMAP LOGIN command, and then turn it off right away when you're finished working on that problem. Example: print "This is very risky!\n" if $imap->Showcredentials(); # or: $imap->Showcredentials(0); # mask credentials again =head2 Socket Example: $Socket = $imap->Socket(); # or: $imap->Socket($socket_fh); The I method can be used to obtain the socket handle of the current connection (say, to do I/O on the connection that is not otherwise supported by B) or to replace the current socket with a new handle (perhaps an SSL handle, for example). If you supply a socket handle yourself, either by doing something like: $imap=Mail::IMAPClient->new(Socket=>$sock, User => ... ); or by doing something like: $imap=Mail::IMAPClient->new(User => $user, Password => $pass, Server => $host); # blah blah blah $imap->Socket($ssl); then it will be up to you to establish the connection AND to authenticate, either via the L method, or the fancier L, or, since you know so much anyway, by just doing raw I/O against the socket until you're logged in. If you do any of this then you should also set the L parameter yourself to reflect the current state of the object (i.e. Connected, Authenticated, etc). =cut =head2 Timeout Example: $Timeout = $imap->Timeout(); # or: $imap->Timeout($new_value); Specifies the timeout value in seconds for reads. Specifying a true value for I will prevent B from blocking in a read. Since timeouts are implemented via the perl L operator, the I parameter may be set to a fractional number of seconds. Not supplying a I, or (re)setting it to zero, disables the timeout feature. =cut =head2 Uid Example: $Uid = $imap->Uid(); # or: $imap->Uid($true_or_false); If L is set to a true value (i.e. 1) then the behavior of the L, L, L, and L methods (and their derivatives) is changed so that arguments that would otherwise be message sequence numbers are treated as message UID's and so that return values (in the case of the L method and its derivatives) that would normally be message sequence numbers are instead message UID's. Internally this is implemented as a switch that, if turned on, causes methods that would otherwise issue an IMAP FETCH, STORE, SEARCH, or COPY client command to instead issue UID FETCH, UID STORE, UID SEARCH, or UID COPY, respectively. The main difference between message sequence numbers and message UID's is that, according to RFC2060, UID's must not change during a session and should not change between sessions, and must never be reused. Sequence numbers do not have that same guarantee and in fact may be reused right away. Since foldernames also have a unique identifier (UIDVALIDITY), which is provided when the folder is L a non-existing folder, then L