Great!
The below text answers most my questions. Maybe it shuld be included in the dokumentation :-) Becose I could not find out for what purpos the pseudo messages was ther. That might decres the ranting about them too :-)
I'm resorting mail with formail + procmail and I was wandering if i shuld preserv the pseudo message even when the mailbox is rebuild with much different contents (possably empty - I do move all read mail from inbox to varius destination). The answer is Yes then - becouse the pseudo message is about new messages uid, and have nothing directly to do whith the curent messages. Good.
But It's one thing that still wories me. Do they have to be the first message in the file?
I curently
mv mbox .mbox.old
cat /dev/null >> mbox
sleep 1
formail-procmail stuf (that will put the pseudo message back and maybe more messages)
rm .mbox.old
Ther is a risk that something can deliver to mbox before the pseudo message is written back.
The sleep is to make it likly that any progressing dilivery to mbox finish befor I start reading, but it also increes the risk that somthing manage to deliver a mesage before the pseudo message.
I could .lock the mbox first... but then i would lock out my own procmail... right?
Sounds a bit problematic. So I want to know if it at all is a problem first... do the pseudo message need to be the first message?
Mark Crispin wrote:
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.
