Hi all,

By now you will have seen all of the changes in the repository related to
IMAP - most of this new functionality comes thanks to Jiri.

As this has been quite a large change, I have been working from his branches
on git hub, with a couple of rebases along the way, rather than requesting
that all patches are posted here - especially as the IMAP implementation,
albeit was functional, was quite limited in some respects ;-)

Anyway, the reason for my email is twofold as the functionality in the
repository is now feature complete:

1) Jiri has provided some tests as part of his work - which I am hoping to
commit over the next few days. However, all of the IMAP, POP3 and SMTP tests
are currently numbered 800 to 815 without any protocol segregation. This
makes it quite difficult for anyone adding tests to say SMTP without first
going through all 15 tests to establish what is IMAP, POP3 or SMTP related,
or to see if a test already exists / can be used as the basis for a new test
harness.

This isn't too much of a problem at the moment, and I am at fault here for
not adding tests for my POP3 enhancements last year, but I would like to not
only add Jiri's tests for the IMAP changes but fix the lack of POP3 tests as
well - as such the numbers will grow making the above more and more
difficult in time.

In summary, I would like to propose that the tests are numbered as follows:

800 to 849 - IMAP
850 to 899 - POP3
900 to 949 - SMTP

I don't think we will make use of 50 tests per email protocol anytime soon
but I would like to ask if anyone have any issues with me doing this?

2) The second part of my email is to provide a quick update and overview of
what can now be achieved using IMAP:

* Previously only message 1 could be read from a particular mailbox. This
has been enhanced through the support of additional properties specified in
the URL - thanks to syntax provided in RFC-5092, or through custom requests.
I have documented the following URL usage in the curl_easy_setopt page:

--url imap://mail.example.com/INBOX/;UID=1 - Selects the user's inbox and
fetches message 1

--url imap://mail.example.com/INBOX;UIDVALIDITY=50/;UID=2 - Selects the
user's inbox, checks the UIDVALIDITY of the mailbox is 50 and fetches
message 2 if it is

--url imap://mail.example.com/INBOX/;UID=3/;SECTION=TEXT - Selects the
user's inbox and fetches message 3 with only the text portion of the message

* In addition to retrieving an email it is also possible to transfer an
email to the server. This is achieved through IMAPs APPEND command and
simply utilising curl's existing mechanism for uploading data to a server:

--url imap://mail.example.com/OUTBOX -T email.txt

* Other commands can be issued, such as: LIST to list the sub-folders of a
mailbox; EXAMINE to see what emails exist in a mailbox; CREATE, RENAME and
DELETE to manipulate sub-folders, STORE to change the properties of an email
and others. Some examples are as follows:

--url imap://mail.example.com - Performs a top level folder list

--url imap://mail.example.com/INBOX - Performs a folder list on the user's
inbox

--url imap://mail.example.com -X "EXAMINE INBOX" - Performs a message list
on the user's inbox

--url imap:// mail.example.com/INBOX -X "CREATE Sub-folder" - Creates a
sub-folder within the user's inbox

--url imap:// mail.example.com/INBOX -X "RENAME Sub-folder My-folder" -
Renames the sub-folder within the user's inbox to my-folder

--url imap:// mail.example.com/INBOX -X "DELETE Sub-folder" - Deletes the
sub-folder within the user's inbox

--url imap:// mail.example.com/INBOX -X "STORE 1 +Flags \Deleted" - Deletes
message 1 from the user's inbox

--url imap:// mail.example.com/INBOX -X "STORE 1 +Flags \Seen" - Marks
message 1 in the user's inbox as read

As well as using the URL syntax to fetch a message it is also possible to
use the custom request mechanism to perform custom FETCH operations as well.
For example

--url imap:// mail.example.com/INBOX -X "'FETCH 1 BODY[TEXT]" will perform
the same operation as

--url imap:// mail.example.com/INBOX/;UID=1/;SECTION=TEXT

There is still a little bit of work to do around the custom request
mechanism which is purely implementation related - some of which I hope to
do before the release of curl v7.30.0 but some will have to wait for a later
version unfortunately :(

Thank you for your time and I'm sure if you have any questions, Jiri or I
are only an email away ;-)

Cheers

Steve

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-03-09