On Tue, Apr 02, 2002 at 11:15:20AM -0800, Randall Gellens wrote:
> At 9:52 AM -1000 4/1/02, Clifton Royston wrote:
> >Some knowledgeable admins have suggested that the flag to disable
> >qpopper writing UIDLs back to the file is a performance benefit,
> >because it reduces disk I/O (at the cost of CPU) and most modern
> >systems are I/O bound not CPU bound. I haven't tried this out, because
> >when I make this change I think it means everyone who leaves mail on
> >our server would get it all downloaded again. (Then again, maybe
> >that's a *good* thing. Heh.)
>
> When UIDs are written into the mail spool they are calculated using a
> hash of the message headers and a random component, to ensure
> uniqueness. When UIDs aren't written into the spool they need to be
> generated the same each time, so there can't be a random element.
> Thus, after making the switch pre-existing messages in the spool will
> have UIDs that contain a random element, while new messages won't.
> So there shouldn't be a problem with downloading old mail again.
Ah, so it continues to use the existing UIDs if present in the spool?
That's very good news. In that case, maybe I can consider doing this
transition.
> However, there is a greater chance of duplicate UIDs, which means
> that potentially some messages might not get downloaded (since they
> seem to be the same as an earlier message to the client).
If the hash is reasonably robust, like an MD5, there should be a
vanishingly small chance of this. There also should never be two
messages with the same message ID, unless there is a problem in the
mail system where they originated; perhaps concatenating a hash of the
total headers and a hash of the message ID alone would reduce the odds
further?
-- Clifton
--
Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED]
"What do we need to make our world come alive?
What does it take to make us sing?
While we're waiting for the next one to arrive..." - Sisters of Mercy
