Subject: Re: "pseudo messages" from ipop3d

From: lewst <[email-masked]>
Date: Wed, 15 Mar 2000 10:13:54 -0800 (PST)

Mark Crispin <[email-masked]> wrote:

> That internal message is used to implement POP3 and IMAP unique identifiers
> (UID).  Although there is another technique by which POP3 UIDs can be
> implemented, that technique is not suitable for IMAP.

And there is no way to move this internal message out of the user's Mailbox? 
If not, how about using the other technique for POP3 UIDs, and the internal 
message for IMAP?

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

---

From: Yiorgos Adamopoulos <[email-masked]>
Date: Wed, 15 Mar 2000 20:29:04 +0200

> If not, how about using the other technique for POP3 UIDs, and the internal 

Hi!

As I understand it, since mbox is a *single* file format, this information 
must be inside the mailbox and not some external file.  Having this as an 
external file, simply means that this is another format, and not mbox.

> implemented, that technique is not suitable for IMAP.

Which speaks for itself.  If Mark has the time, I would like to know the 
"why?" in more detail.
--
Yiorgos Adamopoulos, [email-masked]

---

From: Mark Crispin <[email-masked]>
Date: Wed, 15 Mar 2000 11:41:29 -0800 (PST)

> external file, simply means that this is another format, and not mbox.

Correct.  Moving mailbox data to a second file creates a whole set of new
problems.

> Which speaks for itself.  If Mark has the time, I would like to know the

All UIDs must be unique

IMAP UIDs consist of the mailbox name, a 32-bit integer which is constant for
the mailbox, and a 32-bit integer which is per-message.  Generally, most
people think of the IMAP UID as the per-message 32-bit integer.  This value
must be strictly ascending in the mailbox, a very useful property which makes
it possible to avoid downloading the entire UID map.

The per-mailbox 32-bit integer (called the "UID validity") should remain
constant, but if it ever changes, the new value must be larger.  Since the
uniqueness is the combination of the UID validity and per-message UID, it is
permitted to renumber the per-message UIDs.  This is what happens if something
happens to corrupts the UIDs, or if a mailbox is deleted then recreated.

To preserve the qualities of uniqueness and strict ascendency, UID validity
and the "last assigned UID" must be stored with the mailbox.  That is the
primary function of the pseudo-message.  It also holds such things as IMAP
keywords.

POP3 UIDs are a string of up to 70 printable (0x21 - 0x7e) ASCII characters.
There is no requirement for any sort of ordering.  The other technique that I
referred to is to use an MD5 checksum of the message text.

So, IMAP UIDs can be used as POP3 UIDs, but not the other way around.  IMAP
UIDs are implemented by the underlying c-client library, so the c-client based
POP3 server uses IMAP UIDs for POP3 UIDs.

The whole point of the c-client based POP3 server is to provide POP3 service
that interoperates with the IMAP service.  So, there is no chance of it ever
using the MD5 technique; the result would be even *more* cruft in the mailbox
since it would be "both and", not "either or".

If you don't care about interoperability with the IMAP service, then perhaps
some other POP3 server, such as Qualcomm's qpopper, is a better choice for
you.

This is an excellent example of why "which is better, ipop3d or qpopper?" type
questions are meaningless.  There is rarely an unconditional "better",
otherwise the world would be full of monopolies.  More often, it is a question
of "which is a better choice considering my needs?"

People move from qpopper to ipop3d all the time, because ipop3d turns out to
suit their needs better.  I imagine that Qualcomm sees people moving from
ipop3d to qpopper for the same reason.