Duplicate UIDLs bug?

[#1]

Two emailers I use fail to download several messages queued in each of my mailboxes. I mean they know there are, say, 200 msgs in a mailbox but only download headers and bodies for, say, 150. The rest of the messages are invisible (and these figures are not exaggerated).  The developer of one of the mailers investigated the problem and claims PN's server has a bug and issues duplicate UIDLs which confuses mailers if they download messages from multiple PN mailboxes. This explains why PN's webmail and mail2web don't have this problem -- they look at one mailbox at a time. The developer's mailer doesn't have this problem either if it is set up to look at a single PN mailbox. The two mailers have been working reliably with PN's server for ages. This only started happening a few days ago -- or that's when I noticed anyway. It sounds like a bug and the developer even sent me a debugging version of his mailer demonstrating the problem. Can someone please investigate this.
Michael

[#2]

Michael,
What mail client is this happening in?
I use Thunderbird and it's set to poll multiple PN mailboxes using IMAP and I've never noticed this problem. Nor have I ever come across similar reports of the same. our mail collection servers use Courier AFAIK.
I'll pose the question to our Net-Ops guys to see what their opinions are and get back to you.

[#3]

Can you post the offending emails headers with duplicate UIDLs so the PN developers have something to go on?
Its not something I have seen and I download emails from many mailboxes using Outlook Express.

[#4]

i had this happen once last week, i use standard down load on outlook express,  i now have thunderbird with imap,  on the offending e-mails all the items in the headers were identical, unfortunately i have now deleted it.

[#5]

Interestingly, the POP3 RFC has the following to say about UIDLs (emphasis mine)
UIDL [msg]
      Arguments:
          a message-number (optional), which, if present, may NOT
          refer to a message marked as deleted
      Restrictions:
          may only be given in the TRANSACTION state.
      Discussion:
          If an argument was given and the POP3 server issues a positive
          response with a line containing information for that message.
          This line is called a "unique-id listing" for that message.
          If no argument was given and the POP3 server issues a positive
          response, then the response given is multi-line.  After the
          initial +OK, for each message in the maildrop, the POP3 server
          responds with a line containing information for that message.
          This line is called a "unique-id listing" for that message.
          In order to simplify parsing, all POP3 servers are required to
          use a certain format for unique-id listings.  A unique-id
          listing consists of the message-number of the message,
          followed by a single space and the unique-id of the message.
          No information follows the unique-id in the unique-id listing.
          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.
          Note that messages marked as deleted are not listed.
          While it is generally preferable for server implementations
          to store arbitrarily assigned unique-ids in the maildrop,
          this specification is intended to permit unique-ids to be
          calculated as a hash of the message.  Clients should be able
          to handle a situation where two identical copies of a
          message in a maildrop have the same unique-id.

So, while UIDLs should be considered unique within one particular delivery session or mailbox, there should be no guarantee that this is so and the retrieval software should be able to handle the case of a duplicate message within one session having identical UIDLs
Across sessions (and checking two mailboxes means two sessions) UIDLs should not be considered unique.
B.

[#6]

Similar in the IMAP RFC:
2.3.1.1.        Unique Identifier (UID) Message Attribute
  A 32-bit value assigned to each message, which when used with the
  unique identifier validity value (see below) forms a 64-bit value
  that is permanently guaranteed not to refer to any other message in
  the mailbox.  Unique identifiers are assigned in a strictly ascending
  fashion in the mailbox; as each message is added to the mailbox it is
  assigned a higher UID than the message(s) which were added
  previously.

In this case they are guaranteed to be unique within the mailbox, but not cross-mailbox.
B.

[#7]

I've had several instances of Outlook Express refusing to display emails. The message appears in the list but gets a strikeout as soon as I access it. After that OE won't touch it.