Subject: [MORG] New draft at MORG: POP3 LIST+ Extension

From: Steffen Lehmann <[email-masked]>
Date: Thu, 03 Feb 2011 16:30:50 +0100

Hello,

there is a new draft at
http://datatracker.ietf.org/doc/draft-lehmann-morg-pop3listplus/
describing the "POP3 LIST+ Extension".

Although it is related to POP3 instead of IMAP, I have put it into MORG,
because MORG's goals are fitting best.

Comments and suggestions are solicited.

Steffen

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 04 Feb 2011 16:42:27 +0200

Hello all,

I'm writing to comment Steffen's draft related to POP3 LIST+ extension.

I would firstly ask whether allowing the LIST+ flags with no limited 
number of chars is acceptable?  So I propose to say that (in Section 3) 
'LIST+ flag MAY contain only 16-32 [?? - as you eant] characters' and 
appropriate changes to Appendix B.  Firstly, IANA just won't be able to 
maintain the registry with possibly endless number of values; moreover, 
aspiration to keep flags as short as possible does nt imply such 
unlimited lengths for them.

What is more, I propose to change the security considerations a bit in 
the following way: "Using LIST extended by LIST+ does not introduce any 
new security issues to it' or 'Using LIST extended by LIST+ is not more 
secure that its separate usage'.  It is not right that it does not raise 
any security issues.

I would also like to notice (I've already sent that to the author) that 
IANA considerations are not clear at all.  Therefore I propose (of 
course, formatted in appropriate way):

> 8. IANA Considerations
>
> 8.1. 'LIST+ Flags' Registry
>
> IANA is asked to create and maintain the 'LIST+ Flags' registry 
> following the guidelines below.
>
> The registry consists of two values: LIST+ flag and Reference.  They 
> are described below.
>
>   LIST+ flag - the text string, whose syntax is defined in Section 3.
>
>   Reference - the reference to the document that described the LIST+ flag.
>
> Initial values are given below; new assignments are to be made 
> following the 'IETF Consensus' policies [RFC 5226 - normative ref] (or 
> other policy, as you want)
>   LIST+ flag        Reference
> +-------------------+-------------+
> | +UIDL              | this doc.   |
>          etc.
>
> 8.2. LIST+ Registration in 'POP3 Capabilities' Registry
>
> IANA is asked a new keyword "LIST+" in the "POP3 Capabilities" 
> registry [reference to the reg.] using the template in Section 2 of 
> this document.
Finally, as editorial proposals: the places of Sections 1.1 and 1.2 
should be exchanged; the same as for sections 2 and 3 - this IMO will 
improve the readability of the document.

All the best,
Mykyta Yevstifeyev

03.02.2011 17:30, Steffen Lehmann wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 04 Feb 2011 20:43:01 +0200

> POP3 clients using the LIST command, and,
>    immediately followed, the UIDL command to get the Message Number,
>    Message Size and Unique-ID, of all messages of a mailbox, to see if
>    new messages have arrived.  On large mailboxes, holding hundreds or
>    thousands of mails, this causes serious resource consumption on the
>    server, and will prolong the duration a mailbox is hold in locked
>    state.  This situation is even stressed by the fact that POP3 clients
>    will usually poll a mailbox for new messages periodically in short
>    intervals.

I agree with the above, but

> Using the LIST+ Extension, a server has to scan through the mailbox
>    only for a single time, and can send the Message Number, Message Size
>    and Unique-ID in a more compact form to the client (as shown in
>    Appendix A.2.1).

I don't see this helping all that much with the server's resource
consumption or even much with the client's bandwidth consumption. The
server still has to look up all the sizes and UIDLs. In Appendix A the
client downloads 22% less.

Most of the time POP3 clients just poll an unchanged mailbox. It would
be possible to get a much more dramatic bandwidth improvement by being
able to tell clients that nothing had changed since the last time.
Here's an example of how it could work:

Client connecting for the first time:

   C: LIST +UIDL
   S: +OK 14758f1afd44c09b7992073ccf00b43d 3 messages, listing follows:
   S: 1 4536 7abcb6f4da22080e121f2824aef2be9a
   S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7
   S: 3 3828 2fe542ac6d1c29bb6a5161558f527e2e
   S: .

Client connecting the second time when there are no changes:

   C: LIST +UIDL +ID=14758f1afd44c09b7992073ccf00b43d
   S: +OK 14758f1afd44c09b7992073ccf00b43d No changes
   S: .

Client connecting the 3rd time when there are changes:

   C: LIST +UIDL +ID=14758f1afd44c09b7992073ccf00b43d
   S: +OK ddd2cae8a4a5ec890737d07adb537b99 4 messages, listing follows:
   S: 1 4536 7abcb6f4da22080e121f2824aef2be9a
   S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7
   S: 3 3828 2fe542ac6d1c29bb6a5161558f527e2e
   S: 4 3284 86519edbbe78d203c5c9618df50b21a7
   S: .

So, the client would just remember the value after the "OK". The server
can use whatever value it wants there, but one simple possibility would
be to just use a hash(all UIDLs).

This could be made to save more bandwidth by allowing server to send
only changes based on the given ID, such as:

   C: LIST +UIDL +ID=14758f1afd44c09b7992073ccf00b43d
   S: +OK ddd2cae8a4a5ec890737d07adb537b99 1 new message:
   S: 4 3284 86519edbbe78d203c5c9618df50b21a7
   S: .

Deleted messages could also be reported by adding more complexity.

> The +UNREAD Flag requests to add the number of whole days, since the
>    message was read for last time, to the extended scan listing.

What exactly is the "last read time" for a message? RETR time? When it
was marked as \Seen in webmail/IMAP?

---

From: Steffen Lehmann <[email-masked]>
Date: Sat, 05 Feb 2011 22:10:43 +0100

Hello Timo,

> client downloads 22% less.

To scan through all messages of a mailbox can be a time/CPU/memory
consuming task for a server on big mailboxes. Servers do this usually in
a loop. This could prevent the server to serve other client connections,
while running in this loop (it strongly depends of the server
implementation). Using LIST+, the server has to perform only one loop
over the mailbox instead of two, to provide the same information.

On big mailboxes, polled via slow connections (like Modem, ISDN/E1/BRI,
Mobile/GSM/GPRS, Packet Radio, etc.), it could be a "lot of wood" if the
server would save 22% output.

When I say "big" mailboxes, I speak of mailboxes with about 50.000
messages. In my company, a large ISP provider in Germany, there are
several customers having mailboxes as big as this.

> Deleted messages could also be reported by adding more complexity.

This is an interesting idea.
But doing it using the ID as proposed raises a couple problems:

Hashes are no unique value.

If this ID is a hash as proposed, the server has to compare its value
with that hash it is just generating inside the loop on every line.
Unfortunately, hash functions must be "finalized" to get the hash
function output. If the hash does't match, the server hash to start the
hash function again, and has to put in all data from the beginning up to
the current line into the hash function again. This would be overkill,
and makes using of a hash impractical for this purpose.

A better way would be, the client tells the sever the tuple of
message-number/UIDL of the very last message it knows. The server can
easily compare this two values with the message-number/UIDL tuple of
every message inside the loop, i.e.:

Client connecting for the first time:
   C: LIST +UIDL +AGE +UNSEEN
   S: +OK
   S: 1 4536 7abcb6f4da22080e121f2824aef2be9a 32 16
   S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7 30 0
   S: 3 3828 2fe542ac6d1c29bb6a5161558f527e2e 0 0
   S: .
The server has to send all messages, because of no message-number/UIDL
tuple was given. The client does also fetch the AGE and UNSEEN values
and stores it (these values are in units of days, so the client needs to
fetch them ony one time per day).

Client connecting the second time when there are no changes.
Client sends UIDL with a message-number/UIDL tuple of the last message:
   C: LIST +UIDL=3/2fe542ac6d1c29bb6a5161558f527e2e
   S: +OK
   S: 3 3828 2fe542ac6d1c29bb6a5161558f527e2e
   S: .
In this case, the server only sends the last message. The client can
easily determine that this message is already known, and ignore it.
Sending a non-empty list is necessary to indicate that there are still
messages in the mailbox, an empty list would indicate an empty mailbox.

Client connecting the 3rd time when a new message arrived,
(but no other changes):
   C: LIST +UIDL=3/2fe542ac6d1c29bb6a5161558f527e2e
   S: +OK
   S: 4 3284 86519edbbe78d203c5c9618df50b21a7
   S: .
Only the new message(s) will be listed.
4/86519edbbe78d203c5c9618df50b21a7 becomes the new tuple.

Client connecting the 4th time when message 3 was deleted
by another client:
   C: LIST +UIDL=4/86519edbbe78d203c5c9618df50b21a7
   S: +OK
   S: 1 4536 7abcb6f4da22080e121f2824aef2be9a
   S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7
   S: 3 3284 86519edbbe78d203c5c9618df50b21a7
   S: .
Former message 4 becomes message 3. The sever sends a complete list.
3/86519edbbe78d203c5c9618df50b21a7 becomes the new tuple.

Client connecting the 5th time when all messages were deleted
by another client:
   C: LIST +UIDL=3/86519edbbe78d203c5c9618df50b21a7
   S: +OK
   S: .
The server sends a complete list, which is empty in this case.

The following rules apply:
1. The server has to send a complete message listing in following cases:
- LIST command without +UIDL Flag,
- +UIDL Flag without parameter
- +UIDL Flag with parameter, but the server cannot find a message with
matching message-number/UIDL tuple. This happens if messages on the
server were deleted, resulting in renumbering of all messages above the
deleted message. Renumbering the messages invalidates the
message-number/UIDL tuples of all messages with message-numbers above
the delete message.

2. When client's message-number/UIDL tuple matches the one of server's
last message, the server just issues the last message. This indicates
that there are no changes in the mailbox.

3. If client's message-number/UIDL tuple matches with the one of any
message on the server, and this is not the last message, the server
issues all messages having message-numbers greater than the
message-number as indicated in the tuple (which are, in fact, all newly
arrived messages).

4. If the client receives a message listing whose first message-number
is one, or if the client receives an empty message listing, it MUST
consider this message listing as a "complete" message listing. All
messages known by the server are included in this message listing.

5. If the client receives a message listing whose first message-number
is greater than one, it MUST consider this message listing as a
"partial" message listing. The server should keep knowledge of all
messages it already knows, and should add knowledge of all messages it
does not already know.

Note:
The term "changes in a mailbox" means either message deletion or message
delivery. Changes in the values of the +AGE and +UNREAD Flags, or any
other meta data, cannot be monitored in this way.

Monitoring of message deletion would require a more sophisticated
approach. It has to create a context on the server, having an unique ID,
where the server can store information about the state of each client.
In IMAP, this state is represented by the client connection, but as with
POP3, clients usually disconnect immediately after information
retrieval, so the client connection cannot be used for this purpose.
IMHO, this would things make too complex. Because most of the time POP3
clients just poll an unchanged mailbox, the mechanism as proposed above
has already enough potential to reduce bandwith drastically.

> was marked as \Seen in webmail/IMAP?

I want to rename the +UNREAD Flag to +LASTREAD, and introduce another
Flag +FIRSTREAD. This offers more flexibility for POP3 client
developers, when they want to use these values as input for different
kinds of automatic message deletion processes.
The meaning would be:
  +FIRSTREAD: The time when the message was read for very first time
(when i.e. IMAP sets the \Seen flag)
  +LASTREAD: The time when the message was read the very last time.
In POP3, a message is to be considered as "read" after a successful RETR
command has been issued for that message. Reading a message with the TOP
command shall not mark a message as "read", even if all body lines were
read.

Steffen

---

From: Mark Crispin <[email-masked]>
Date: Sat, 5 Feb 2011 13:29:13 -0800 (PST)

On Sat, 5 Feb 2011, Steffen Lehmann wrote:
> consuming task for a server on big mailboxes.

This discussion is fascinating, but it begs the question:

If you care about such matters, why use POP3 and not IMAP?

POP3 does a certain specific task, and it does that task well.  POP3 was
never intended for any other task.

Each new extension (to either IMAP or POP3) creates new client/server
incompatibility paths.  You may think that you are staying on top of
things by implementing every extension, no matter how minimal the market
requirement.  You learn otherwise when your customers slam you over
interoperability problems that are fixed only by disabling the extension
in your product.

I can't help but thing that MORG has devolved into a group of people
desperate to stay on the gravy train of Building New Email Protocols,
never mind that the train has become increasingly irrelevant.

The more realistic only care about placing a veneer of "IETF approval" on
a private mechanism for their client/server products.  But then there are
the others, who live in a true Fantasy Land in which everybody will
presently implement all 69 random extensions.

This disease isn't confined to MORG either.  The entire IETF suffers from
it.  I am thoroughly enjoying the IPv6 debacle as it unfolds, and look
forward to many years of entertainment.

-- 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.

---

From: Steffen Lehmann <[email-masked]>
Date: Sun, 06 Feb 2011 09:48:07 +0100

> If you care about such matters, why use POP3 and not IMAP?

About 80% our customers are using POP3, 20% IMAP. The decision, whether
to use POP3 or IMAP, is not ours.

> never intended for any other task.

I think you have never seen a customer using POP3 tryig desperately
regain control over his mailbox when mailbox is under heavy load,
perhaps due to a mailbomb attack, or simply because the customer has
accidentally created an automatic mail responder ping-pong or a
mail-forward loop. The only remaining chance is to call the ISP and beg
for help. With POP3 - no chance.
As long as customers use POP3, for whatever reasons, we should try to
improve it, if possible.

> interoperability problems that are fixed only by disabling the extension

I (carefully) agree. But this can be avoided by well-engeneered
extensions and well-tested implementations.

> forward to many years of entertainment.

There is still a third group, trying honestly to improve things. Nobody
(nothing) is perfect.

Steffen

---

From: Mark Crispin <[email-masked]>
Date: Sun, 6 Feb 2011 09:54:48 -0800

> to use POP3 or IMAP, is not ours.

You are making a staggering assumption: that your customers' decision is
one to use POP3 vs. IMAP.

I submit that the vast majority of your customers don't decide in those
terms at all.  Rather, their decision is to use certain software, whether
due to comfort or inertia.  Often, other than to getting it to function,
they haven't spent much time in configurating their software.

Put another way: most of your customers don't know a POP3 from an IMAP
from a Bombastic Blurdybloop; and even if you told them they wouldn't
care.

You may be able to get some your customers to change the POP3/IMAP
checkbook in their software on the grounds that it will "improve
performance".  Your odds of success increase if you give them specific
instructions, with screen shots, on how to do it in their specific
software.

> regain control over his mailbox

You are making a second staggering assumption: that a person who has been
a professional in the email industry for over 30 years is somehow ignorant
of such matters.

> As long as customers use POP3, for whatever reasons, we should try to

This is the third staggering assumption: that by having IETF produce a
document, you will somehow achieve technological progress for your users.

It assumes that the vendors of client used by your users, and the vendor
of your server, all implement this extension; that these implementations
all interoperate; and that your users promptly upgrade to the new version
of their client software.

There are huge barriers in the way.  The greatest of these is that there
is no particular incentive for vendors to do it; and there are severe
disincentives to vendors.

Any extension to POP3 (or IMAP), no matter how trivial, requires hundreds
of hours of time in R&D and testing.  We're talking a great deal of money;
and a compelling business case has to be made for it.

Perhaps unlike you, I have dealt with getting engineering changes through
the likes of Microsoft, Google, and Apple.  The timeframe for getting
things through these guys is measured in years; and that is when there is
a compelling business case.  There is none here.

Nor do you particularly want them implementing your extension.  It is
virtually guaranteed that if they do it, it will be in a way that breaks
your other implementations.  Microsoft and Google especially are of the
attitude that their software constitutes the "standard"; and that if some
RFC disagrees it's a bug in the RFC.

You may get a "free software" implementation or two to implements it.
Even these are impacted by "it works fine with the competition"
bug/regression report caused by implementation incompatibilities.

> extensions and well-tested implementations.

Any talk about new POP3 extensions (and arguably also IMAP extensions) is
mental masturbation.

The only business case that exists for extensions any more is to foil an
attempt to bias competitive procurement in government purchases that
writes in a requirement for some obscure RFC.  I've seen RFPs that
stipulated RFC 748 compliance!

The end result of work on a POP3 extension is an obscure document, that
may make it to an RFC, that hardly anyone ever implemented and is
consigned to the scrap heap of history.  There is a large pile of such
documents in the IETF.  I wrote some, long ago.  The pile is growing.

Adding to the pile will not solve your problem.  You will presently be
forced to seek another (hopefully more effective) solution, and come to
realize that your work on this beautiful POP3 extension was a complete
waste of your time.

I am doing you a favor.  Feel free to disregard it.  You will learn either
sooner, or later.  The choice is yours.

-- Mark --

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

---

From: Steffen Lehmann <[email-masked]>
Date: Sun, 06 Feb 2011 20:21:40 +0100

> a professional in the email industry for over 30 years is somehow ignorant

I bed your pardon.

Steffen

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 6 Feb 2011 23:00:28 +0200

>> be to just use a hash(all UIDLs).
..
> Hashes are no unique value.

It wouldn't have to be a hash. It was just an example.

> message-number/UIDL of the very last message it knows.

A server implementation would be free to use that as the ID as well. It has one problem though: message UIDLs are not guaranteed to be always unique (even POP3 RFC mentions this), so this has the potential of missing changes in some situations. So I'd prefer that there was no enforcement of a specific format for the ID to allow more flexible server implementations. I doubt it's too much to ask for clients to store one extra string for it.

> command shall not mark a message as "read", even if all body lines were

Clients might become disconnected before RETR is complete. Server wouldn't then necessarily know if message was fully received by the client. Would that still be a successful RETR?

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 6 Feb 2011 23:06:06 +0200

> of their client software.

There's one other possibility also that doesn't involve changing the client: User installing a transparent local POP3 proxy that talks regular old POP3 (or IMAP) to the client but an extended protocol to the remote server. Of course there wouldn't be a whole lot of users doing this, but it's a possibility for some motivated ones.

---

From: Steffen Lehmann <[email-masked]>
Date: Wed, 09 Feb 2011 14:17:31 +0100

> A server implementation would be free to use that as the ID as well. It has one problem though: message UIDLs are not guaranteed to be always unique (even POP3 RFC mentions this), so this has the p…
I agree. Using an ID offers most flexibility regarding server's
implementation.

> Clients might become disconnected before RETR is complete. Server wouldn't then necessarily know if message was fully received by the client. Would that still be a successful RETR?

The server has, for my opinion, five options, when the
FIRSTREAD/LASTREAD values could be set:

1. After a  successful RETR command (just before the server sends the
terminating "." line).
2. After a  successful RETR command (just after the server has sent the
terminating "." line).
3. After a  successful RETR command, when the server receives the next
valid command,
4. After a  successful RETR command, when the server enters the UPDATE
state.
5. On behalf of the client, using any new "set" command.

All five options have a time window, each of different duration, when
something may happen, resulting in a FIRSTREAD/LASTREAD value not
representing the actual state.

Option 1:
- The client might crash before finishing message processing.
- The server might crash after it has updated the FIRSTREAD/LASTREAD
value, but before it has sent the terminating "." line.

Option 2:
- The client might crash before it has finished message processing.
- The server might crash after it has sent the terminating "." line, but
before it has updated the FIRSTREAD/LASTREAD value.

Option 3-5:
- It doesn't guarantee the client has read the message (the client could
have sent the next/QUIT/"set" command before finishing message
processing; PIPELINING could be used).
- The server might crash before the next command arrives.

Unfortunately, there is no reliable option.

But the FIRSTREAD value could be used by clients to make a decision like
"don't retrieve messages which are marked as 'already read'". Using the
FIRSTREAD value in this manner could result in never-read messages (if
the server has updated the FIRSTREAD value, but the client crashed).
On the other hand, If a FIRSTREAD values was not updated due to a server
crash, and a client has a rule like "delete never-read messages after xx
days", this could delete a message, although this message was read.
Therefore, I think,  it would be better not to introduce a FIRSTREAD
value, and to leave the UNREAD value as it is.

With the UNREAD value, things are not this dramatic as with FIRSTREAD. I
prefer option 1. Option 1 ensures, that  the UNREAD value will be
updated in any case. Even if the server has updated the UNSET value, but
the client has never seen the message (i.e. due to a crash), the updated
UNREAD value indicates that someone is still interested in this message.

The text

"The +UNREAD Flag requests to add the number of whole days, since the
message was read for last time, to the extended scan listing."

should be changed to

"The +UNREAD Flag requests to add the number of whole days, since the
message was tried to read for last time, to the extended scan listing."

-- Steffen

---

From: Barry Leiba <[email-masked]>
Date: Wed, 9 Feb 2011 11:45:48 -0500

> because MORG's goals are fitting best.

[Barry, as chair]
I'll add, for those who aren't aware, that Steffen approached the MORG
chairs to ask if it were appropriate to discuss this draft on the MORG
list, and we said that we think it is.  That does not mean that the
document will be picked up by the MORG working group, which is
wrapping up its work and is not likely to recharter.  But we think the
right people will see these messages on the MORG and APPSAWG lists.

[Barry, as participant]
I like this draft, and I think it would have been a useful extension
if presented years ago.  I'm not sure how useful it will be now; as
Mark has pointed out, it'll be hard to get implementations, and then
hard to get everyone to upgrade or change to server and client
versions that support it.

Most modern servers and clients support both POP and IMAP, and need no
changes to have users switch to IMAP (especially for the more involved
functions that are being discussed on the other thread.  I think it's
likely to be easier, when users need to use your servers as
large-scale message stores, with their clients holding local caches
and doing complex synchronization, to give those users instructions on
switching to IMAP, rather than to have them change their client
software (upgrade or switch entirely).  Reconfiguring for IMAP is a
few-minute task with little risk, and clear instructions for doing it
on the most popular clients can be published, minimizing the support
costs.

Further, switching users to IMAP is a much more robust solution than
trying to make POP into a sort of "IMAP light".  I *strongly* advise
against that, and suggest that the discussion going on in the other
thread is not useful.  But even this modest version, which is clever
and concise, and which makes perfect sense, is unlikely to be useful
in practice for several years, at least, and may well never get enough
deployment to be useful.

I'd feel much better if we saw a bunch of client and server
implementors post here and say that they'd implement this soon, if it
were standardized.  In particular, on the client side, unless this is
implemented in Outlook, Thunderbird, and Apple Mail (all three), I
think it's swimming upstream.

To the spec itself: as Mykyta says, the IANA considerations section
needs to be made into proper instructions to IANA, if this goes
forward.  I recommend that you not bother with that until we're more
certain that it will go forward... the IANA details can be filled in
later.

I see one technical point that I wonder about:
The combination of AGE and UNREAD *almost* tells you what you need to
know, I think.  If AGE > UNREAD, you know the message was downloaded,
perhaps on another client.  But if AGE == UNREAD, you aren't sure.  It
would be nice if that were clear.  Perhaps a special value of UNREAD
(such as "-1") would work to indicate that the message has never been
RETRieved.  (And, yes, as Timo points out, the spec should make it
clear what "read" means, even if it says that it's an implementation
choice.)

Barry

---

From: Mark Crispin <[email-masked]>
Date: Wed, 9 Feb 2011 09:05:33 -0800 (PST)

> in practice for several years, at least, and may well never get enough

Indeed.  There is little, if anything, technically wrong with this
document.  It is well written, and well thought-out.

It is simply (at least) 15 years too late.

Unfortunately, no matter how technically excellent a specification may be,
a specification that is too late is doomed to failure.

Barry is being kind in saying that it "is unlikely to be useful in
practice for several years, at least, and may well never get enough
deployment to be useful."  The reality is harsher.

-- Mark --

http://panda.com/mrc

---

From: David Bienvenu <[email-masked]>
Date: Wed, 09 Feb 2011 13:45:39 -0800

> think it's swimming upstream.
I've told Steffen that I'd be interesting in either adding support for this to Thunderbird, or helping someone else add it, since it should be relatively easy to add. 
Condstore-like capability would also be easy to add.

We still have a lot of POP3 users, despite our IMAP bias.

- David