mailing list archives

I'm intrigued by the charts of email client capabilities on Wikipedia
(http://en.wikipedia.org/wiki/Comparison_of_e-mail_clients).  You'll
notice that almost all the clients claim to support IMAP4 (even the
ones which don't support STARTTLS, like Outlook :-).

There's a column in the Wikipedia chart labelled "Database, folders,
and customization" which purports to show which clients use IMAP
search.  I'm interested in knowing more about a fairly narrow topic:
which clients use IMAP search, and how they use it.  Is there such a
chart?  Or listing?  I'd be happy to put one together if folks want to
mail me contributions.

In fact, I'd like to make a version of this chart which calls out more
specifically IMAP features and usage, so that folks who want to use
IMAP mail services can have a better idea of which clients will be
most useful to them.  What should those features be?

Bill

On Tue, 20 Mar 2007, Bill Janssen wrote:
> I'm interested in knowing more about a fairly narrow topic:
> which clients use IMAP search, and how they use it.

Pine (and its sucessor, Alpine) makes extensive use of SEARCH: 
user-initiated searching, filtering/roles, and internal purposes.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

On Tuesday, 20 March 2007 at 12:48, Bill Janssen wrote:
> I'm intrigued by the charts of email client capabilities on Wikipedia
> (http://en.wikipedia.org/wiki/Comparison_of_e-mail_clients).  You'll
> notice that almost all the clients claim to support IMAP4 (even the
> ones which don't support STARTTLS, like Outlook :-).
> 
> There's a column in the Wikipedia chart labelled "Database, folders,
> and customization" which purports to show which clients use IMAP
> search.  I'm interested in knowing more about a fairly narrow topic:
> which clients use IMAP search, and how they use it.  Is there such a
> chart?  Or listing?  I'd be happy to put one together if folks want to
> mail me contributions.

mutt uses search for header, text and body, if the user doesn't use
regular expressions for those search components.

> In fact, I'd like to make a version of this chart which calls out more
> specifically IMAP features and usage, so that folks who want to use
> IMAP mail services can have a better idea of which clients will be
> most useful to them.  What should those features be?

Alexey used to maintain a chart listing a variety of IMAP clients and 
servers, and the extensions they supported.  If you go waay back in the 
list archives (circa 2001) you can probably find a reference to it, 
although I suspect it's long gone now.

You'll probably get a better answer to this next week (after people get 
back from IETF).

--lyndon

On Tue Mar 20 12:48:46 2007, Bill Janssen wrote:
> search.  I'm interested in knowing more about a fairly narrow topic:
> which clients use IMAP search, and how they use it.  Is there such a
> chart?  Or listing?  I'd be happy to put one together if folks want 
> to
> mail me contributions.

Polymer uses IMAP searches, typically either ad-hoc searching for 
flags, subject, body, to/cc/from, or allowing the user to define 
arbitrary IMAP searches. It supports ESEARCH (somewhat obviously) and 
will present the user with a dynamically updated view filtered by 
searches.

(As for other extensions, the simplest answer is "Yes").

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Here's a little-known fact about Apple Mail:  if you select SSL support
for IMAP, it actually will connect with SSL to the IMAP server, if and
only if the port is set to 993.  If you specify any other port to
Apple Mail, and check the SSL checkbox, it will connect in the clear,
and attempt to do STARTTLS.  If the server doesn't, in its
CAPABILITIES string, indicate STARTTLS, it will simply issue a LOGOUT
and disconnect.

Bill

> In fact, I'd like to make a version of this chart which calls out more
> specifically IMAP features and usage, so that folks who want to use
> IMAP mail services can have a better idea of which clients will be
> most useful to them.  What should those features be?

I've started a comparison chart.  My plan is to flesh this out with
the help of this list, then move it to the Wikipedia page on
"Comparison of email clients".  Ideally, each box that isn't "?"
should have a link to a reference that backs up the assertion.  I need
references on Thunderbird.

See <http://www.parc.com/janssen/transient/imapclients.html>.

Tell me what's wrong with it -- what columns and rows are missing.

Tell me more about specific features of specific clients.

Bill

Alexey's lists (apparently last updated August 2005) are at

http://www.melnikov.ca/mel/devel/Links.html

Mozilla, Thunderbird, and Outlook all support client initiated
searches.

Rick Block


Lyndon Nerenberg wrote:
>> In fact, I'd like to make a version of this chart which calls out more
>> specifically IMAP features and usage, so that folks who want to use
>> IMAP mail services can have a better idea of which clients will be
>> most useful to them.  What should those features be?
> 
> Alexey used to maintain a chart listing a variety of IMAP clients and 
> servers, and the extensions they supported.  If you go waay back in the 
> list archives (circa 2001) you can probably find a reference to it, 
> although I suspect it's long gone now.
> 
> You'll probably get a better answer to this next week (after people get 
> back from IETF).
> 
> --lyndon
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> https://mailman1.u.washington.edu/mailman/listinfo/imap-protocol

> Alexey used to maintain a chart listing a variety of IMAP clients and
> servers, and the extensions they supported.  If you go waay back in
> the list archives (circa 2001) you can probably find a reference to it, 
> although I suspect it's long gone now.

http://www.melnikov.ca/mel/devel/ServerReference.html

Lyndon Nerenberg writes:
> Alexey used to maintain a chart listing a variety of IMAP clients and 
> servers, and the extensions they supported.  If you go waay back in 
> the list archives (circa 2001) you can probably find a reference to 
> it, although I suspect it's long gone now.

http://www.melnikov.ca/mel/devel/Links.html

Arnt

> Alexey used to maintain a chart listing a variety of IMAP clients and 
> servers, and the extensions they supported.  If you go waay back in the 
> list archives (circa 2001) you can probably find a reference to it, 
> although I suspect it's long gone now.

Thanks.

Doesn't really say much about clients, though the list of which
clients support which authentication mechanisms is useful, if
out-of-date (no Thunderbird listing).

Bill

Lyndon Nerenberg writes:
> Alexey used to maintain a chart listing a variety of IMAP clients and 
> servers, and the extensions they supported.  If you go waay back in 
> the list archives (circa 2001) you can probably find a reference to 
> it, although I suspect it's long gone now.

http://www.melnikov.ca/mel/devel/Links.html

Arnt

On Tue Mar 20 20:35:03 2007, Lyndon Nerenberg wrote:
>> In fact, I'd like to make a version of this chart which calls out 
>> more
>> specifically IMAP features and usage, so that folks who want to use
>> IMAP mail services can have a better idea of which clients will be
>> most useful to them.  What should those features be?
> 
> Alexey used to maintain a chart listing a variety of IMAP clients 
> and servers, and the extensions they supported.  If you go waay 
> back in the list archives (circa 2001) you can probably find a 
> reference to it, although I suspect it's long gone now.
> 
> 
Servers are still done on melnikov.ca - I don't think clients ever 
were, other than SASL mechanisms supported.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

> See <http://www.parc.com/janssen/transient/imapclients.html>.
> 
> Tell me what's wrong with it -- what columns and rows are missing.
> 
> Tell me more about specific features of specific clients.

Actually, when I said "tell me", I really meant, "tell the list", so
that the messages in the archive can be quoted as links.

Bill

On Sat Mar 24 13:46:04 2007, Bill Janssen wrote:
> I've started a comparison chart.  My plan is to flesh this out with
> the help of this list, then move it to the Wikipedia page on
> "Comparison of email clients".  Ideally, each box that isn't "?"
> should have a link to a reference that backs up the assertion.  I 
> need
> references on Thunderbird.
> 
> See <http://www.parc.com/janssen/transient/imapclients.html>.
> 
> Tell me what's wrong with it -- what columns and rows are missing.
> 
> Tell me more about specific features of specific clients.

On this list, Polymer supports SEARCH, ESEARCH, NAMESPACE [1], IDLE, 
STARTTLS, SSL [2], MULTIAPPEND, UIDPLUS and IDLE [3].

I just updated 
http://svn.dave.cridland.net/svn/projects/infotrope/polymer/doc/techie-stuff.html 
which has a fairly complete annotated list.

1: NAMESPACE support has a bug, exposed by the UW-IMAP's handling of 
the MH inbox, where the prefix is NIL.
2: SSL support is pretty shaky. It's there, but quite possibly not 
fully working. The real problem is that Polymer cannot easily figure 
out a URL for message parts, and BURL servers cannot handle them 
anyway.
3: Polymer will handle asynchronous updates with or without IDLE, as 
well as dealing with pipelined commands executing out of order, as it 
happens. EXPUNGE is the only thing it's specifically trying to get 
out of IDLE.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

On Sat Mar 24 13:46:04 2007, Bill Janssen wrote:
> Tell me what's wrong with it -- what columns and rows are missing.

I'd be interested in seeing some Lemonade stuff, particularly "the 
Trio" - BURL/CATENATE/URLAUTH.

I suspect good extensions to list would be LITERAL+ and CHILDREN, 
because both are highly deployed, and will make client developers 
keener to have their client listed, although LIST-EXTENDED and BINARY 
might be more interesting to server developers.

SASL-IR, ACL, and QUOTA might also be interesting - the former has 
been an eternal draft for some time but has some deployment I think, 
and the latter two have reasonably high deployment in a "read-only" 
mode.

I can tell you that ACL is supported by Thunderbird in read-only 
mode, and CHILDREN is easy to spot in many clients for anyone with 
grep and the client binary.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

I've pushed an updated page, with some suggestions incorporated, data
folded in, and links to the appropriate RFC for each extension.

Anyone know where in IETF space the use of the IMAP protocol over SSL
is defined?  I see there's no "imaps" URI scheme in the registry.

Bill

On Tue, 2007-03-20 at 14:31 -0700, Bill Janssen wrote:
> > Alexey used to maintain a chart listing a variety of IMAP clients and 
> > servers, and the extensions they supported.  If you go waay back in the 
> > list archives (circa 2001) you can probably find a reference to it, 
> > although I suspect it's long gone now.
> 
> Thanks.
> 
> Doesn't really say much about clients, though the list of which
> clients support which authentication mechanisms is useful, if
> out-of-date (no Thunderbird listing).

What would you people think about having a generic IMAP Wiki
(wiki.imap.org)?

These kinds of lists won't be kept up-to-date if you have to email
someone to update them. Also there doesn't seem to be any place where to
easily find IMAP related information. There is a list of RFCs and
drafts, but that's about it. Searching the mailing list archives isn't
very fun.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20070321/9d69d1b0/attachment.sig>

Bill Janssen wrote:
>> See <http://www.parc.com/janssen/transient/imapclients.html>.
>>
>> Tell me what's wrong with it -- what columns and rows are missing.
>>
>> Tell me more about specific features of specific clients.
> 
> Actually, when I said "tell me", I really meant, "tell the list", so
> that the messages in the archive can be quoted as links.

If you want the archives to be usefully searchable you should collect 
the responses and then summarize to the list ;-)

> 2: SSL support is pretty shaky. It's there, but quite possibly not 
> fully working. The real problem is that Polymer cannot easily figure 
> out a URL for message parts, and BURL servers cannot handle them 
> anyway.

Dave, I don't think I understand this note.  What do URLs have to do
with IMAP SSL support?

Bill

> I'd be interested in seeing some Lemonade stuff, particularly "the 
> Trio" - BURL/CATENATE/URLAUTH.

Should this be one column?

Bill

On Mon Mar 26 18:57:11 2007, Bill Janssen wrote:
> I've pushed an updated page, with some suggestions incorporated, 
> data
> folded in, and links to the appropriate RFC for each extension.
> 
> 
Looks good. Polymer does CHILDREN, too. It uses LISTEXT in preference 
to CHILDREN if available, and uses LIST-EXTENDED in preference to 
LISTEXT/CHILDREN if that's available.


> Anyone know where in IETF space the use of the IMAP protocol over 
> SSL
> is defined?  I see there's no "imaps" URI scheme in the registry.

Indeed. It's non-standard. "imaps" was largely an interim solution 
used by some whilst waiting for STARTTLS (RFC2595, then later 
incorporated into RFC3501).

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

> What would you people think about having a generic IMAP Wiki
> (wiki.imap.org)?

Why not use Wikipedia?  Seems to be an IMAP page already:
http://en.wikipedia.org/wiki/Imap.  Might want to fix it or expand it.

Bill

On Mon Mar 26 10:06:09 2007, Bill Janssen wrote:
> > 2: SSL support is pretty shaky. It's there, but quite possibly 
> not > fully working. The real problem is that Polymer cannot easily 
> figure > out a URL for message parts, and BURL servers cannot 
> handle them > anyway.
> 
> Dave, I don't think I understand this note.  What do URLs have to do
> with IMAP SSL support?

Yes, it's not an obvious issue, really.

<imap://dwd@turner.dave.cridland.net/INBOX;UIDVALIDITY=1173455933/;uid=48931> 
is a URI pointing to a message (yours, as it happens). BURL (possibly 
in concert with GENURLAUTH to provide pawn-ticket authorization) can 
take this URL and use it as part of the source for a message. Polymer 
can bookmark messages in ACAP by using the URI, too, and actuating 
that bookmark (possibly on another machine) would then connect to 
port 143 on turner, do the STARTTLS/AUTHENTICATE shuffle, and present 
the message. So far, so brilliant.

<imaps://dwd@turner.dave.cridland.net/INBOX;UIDVALIDITY=1173455933/;uid=48931> 
is what Polymer would generate if it was using old-style SSL on a 
different port. This is because for bookmarks, configuration, and 
other internal message relocations, this is what's needed. 
Unfortunately, this scheme is non-standard, and might not work for 
GENURLAUTH or BURL - although Polymer can normalize URIs to a degree, 
it can't know that port 143 is equivalent to port 993 except for SSL 
negotiation, and there's no chance at all of ascertaining the correct 
non-SSL port for an "imaps" service running on an arbitrary port, 
hence things break.

The general rules of thumb are:

1) If you are a mail provider offering SSL, offer STARTTLS too, and 
try to migrate your customers toward it. You are risking medium-term 
breakage which is not apparent yet, but almost certainly will be, 
especially for mobile email markets which are likely to be key to 
your survival in the longer term.

2) If you are a client developer, use STARTTLS wherever possible, and 
attempt to migrate users away from old-style SSL. STARTTLS support 
should be on by default and require no user-level configuration.

3) If you are a user, use SSL as a last resort for gaining 
encryption, and configure your client to use STARTTLS instead.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

On Mon Mar 26 18:00:52 2007, Bill Janssen wrote:
> > I'd be interested in seeing some Lemonade stuff, particularly 
> "the > Trio" - BURL/CATENATE/URLAUTH.
> 
> Should this be one column?

Yes, they're usually implemented as a trio. (Actually, a Quartet, 
since you also need UIDPLUS for it to be useful). Exceptions can be 
called out.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

On Mon, 26 Mar 2007, Dave Cridland wrote:
> 1) If you are a mail provider offering SSL, offer STARTTLS too, and try to 
> migrate your customers toward it.

Bravo.

> 2) If you are a client developer, use STARTTLS wherever possible, and attempt 
> to migrate users away from old-style SSL. STARTTLS support should be on by 
> default and require no user-level configuration.

Bravo!

> 3) If you are a user, use SSL as a last resort for gaining encryption, and 
> configure your client to use STARTTLS instead.

Bravo!!!

The sooner SSL-only clients are abolished, the happier I would be.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Mon Mar 26 17:43:34 2007, Mark Crispin wrote:
> The sooner SSL-only clients are abolished, the happier I would be.

Absolutely, but while it's previously been largely [perceived as] a 
matter of taste, there's a fairly nasty issue lurking when the 
IMAP/URLAUTH and ESMTP/BURL extensions are considered. (There's also 
similar-ish issues with MAILBOX-REFERRALS, but these are rarely 
implemented by clients - to the extent that Lemonade's "Forward 
Without Up^WDownload" Trio are probably more widely implemented now).

Polymer is no longer the only client to use the Lemonade Trio, and 
I'd not be too surprised to see a reasonable substantial number of 
clients implement it within a few months, now. Even if I'm wrong, and 
it remains a fairly specialized action, there's a cost - measured in 
real-world currency for many people - attached to this issue, and 
it's a pretty bad choice to alienate yourself from the mobile email 
market right now.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade