cURL / Mailing Lists / curl-library / Single Mail



From: Steve Holme <>
Date: Mon, 5 May 2014 19:06:27 +0100

On Mon, 05 May 2014, Dionysios Kalofonos wrote:

> > I also think we should try and address this for 7.38.0 - the release
> > after next assuming you and I have the time for it ;-)
> Ok, great!

I think the areas we need to look at are as follows:

* Fixed libcurl FETCH API (as you suggested in Option A)
* Change the LIST command be driven off CURLOPT_DIRLISTONLY
* Change current custom commands to be an override of LIST
* Implement custom command support for FETCH
* Implement custom command support for APPEND

The only thing I'm not 100% sure about in my own head is what to do with the
following URL for example:


Currently it will performs a LIST command, but Section 5 of RFC-5092
suggests (if I have understood it correctly) using it to perform a SELECT or
EXAMINE command.

When we expanded IMAP last year the curl tool didn't support multiple URL
requests using separate options (as per recently added --next) so it made
sense for the URL to do something that would be useful to the user. As such,
a URL including a mailbox but no FETCH or SEARCH options does make sense, at
the time, although it can be argued that a single URL can also perform the
same functionality. For example, if we change it to perform just a SELECT
command then:

imap:// --next imap://;UID=1

Would be the same as:


Which seems a little pointless on its own, however, it could be used to
periodically check the UID validity of a mailbox:


This is currently possible, but a FETCH would be issued afterwards. I.e.
it's only possible with:


Which would then:

* Issue the SELECT
* Check the UID validity
* Issue the FETCH of message 1 if the mailbox is still valid

I think I've just talked myself into changing the action for /INBOX into a
SELECT rather than being a LIST, as well, but I would be interested to know
yours and others views on this ;-)

Kind Regards

List admin:
Received on 2014-05-05