Home > Archive > PHP Programming > January 2005 > UIDL is not always the same, please help
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
UIDL is not always the same, please help
|
|
| WebRod 2005-01-26, 3:56 pm |
| Hi,
i use Net_POP3 from PEAR to get emails.
I realized today that the UIDL associated to an email is not always the
same!!
That's terrible.
I really need to find a way to download only NEW mails (and keep a copy on
the server).
How can I do that.
Help me please, it is very urgent and I can't fine a way if the UIDL is not
always the same!!
Any idea??
thanks
Rod
| |
|
|
> I realized today that the UIDL associated to an email is not always
the
> same!!
According to the relevant RFC...
"...The unique-id of a message is an arbitrary server-determined
string, consisting of one to 70 characters in the range 0x21
to 0x7E, which uniquely identifies a message within a
maildrop and which persists across sessions. This
persistence is required even if a session ends without
entering the UPDATE state. The server should never reuse an
unique-id in a given maildrop, for as long as the entity
using the unique-id exists."
So if your POP3 server does not persist UIDLs across sessions (it must
do so if it supports them at all), then it is not compliant and you
have a problem.
You will have to roll your own solution, which will involve using a
database to store information between sessions (yeah, you could use a
flat file but it would be painful.) You must simulate what the POP3
server should do for you by creating your own UIDL: a hash (MD5?) on as
much of the message as you can stomach - possibly the whole thing? -
and also handling collisions if two identical messages appear (although
the RFC suggest that you should manage this anyway, as servers are
slackly permitted to use message hashes as UIDLs.)
Next time you visit the same mailbox, rehash each message and compare
against your database.
---
Steve
| |
| Markku Uttula 2005-01-26, 3:56 pm |
| WebRod wrote:
> i use Net_POP3 from PEAR to get emails.
> I realized today that the UIDL associated to an email is not always
> the same!!
In that case the developer of the POP3-server has done a very bad job.
Following is from RFC-1939 (some parts ephasized by me):
<RFC1939>
The unique-id of a message is an arbitrary server-determined string,
consisting of one to 70 characters in the range 0x21 to 0x7E, which
*uniquely identifies a message within a maildrop* and *which persists
across sessions*. *This persistence is _required even if a session
ends without entering the UPDATE state_*. The server should never
reuse an unique-id in a given maildrop, for as long as the entity
using the unique-id exists.
</RFC1939>
> That's terrible.
Yes, and if what you say is correct, the developer of said mail server
should be procecuted and burnt in the village centre as an example for
others.
> I really need to find a way to download only NEW mails (and keep a
> copy on the server).
> How can I do that.
> Help me please, it is very urgent and I can't fine a way if the UIDL
> is not always the same!!
Are you *certain*, that the UIDLs are *not* the same for messages? As
I wrote in the earlier message, you can't be certain of the order the
UIDLs are displayed (that's why you should issue UIDL-command without
parameters to receive a full list of UIDLs in the mailbox and check
them one by one (by just looping through the list and comparing to
UIDLs that are known as "seen")).
--
Markku Uttula
| |
| Markku Uttula 2005-01-27, 3:55 am |
| Steve wrote:
> You will have to roll your own solution, which will involve using a
> database to store information between sessions (yeah, you could use
> a
> flat file but it would be painful.) You must simulate what the POP3
> server should do for you by creating your own UIDL: a hash (MD5?) on
> as much of the message as you can stomach - possibly the whole
> thing?
> - and also handling collisions if two identical messages appear
> (although the RFC suggest that you should manage this anyway, as
> servers are slackly permitted to use message hashes as UIDLs.)
>
> Next time you visit the same mailbox, rehash each message and
> compare
> against your database.
The solution provided negates the whole idea of having UIDs in
messages - at least I've believed the reason for providing them is
that the messages wouldn't need to be downloaded fully to determine
whether we want it or not.
Just thought to point that out :)
--
Markku Uttula
|
|
|
|
|