Joel Reicher wrote:
Are you using unix format mailboxes? Changing the format might fix this
problem, and will almost certainly make your server more efficient.
yes, the mailboxes are in unix flat file format. This was necessitated by some users still using pine/mutt/mail to
access their mail.
time stamp) is being rewritten to the current time instead of its
original value. This causes all the messages to have new UIDL values,
and so the POP client thinks that these are new messages. The field in
Is POP the only method of access to these mailboxes? Are none of these
Mac clients configured to use IMAP and you're not running a webmail
system either (which would almost certainly use IMAP)?
For the users in question, POP clients are the only means of access. There are a few that have multiple clients
connecting and checking the mail, but there are several notable examples of people who have never used command line
programs and only have one POP client configued.
Maybe something else has accessed the mailbox in the middle of a user's
session; are the users getting any errors about sessions disconnecting?
question is:
X-IMAP: 1213219525 0000000002
Although if the data is not stored in a placeholder message, the header
is named X-IMAPbase.
By "placeholder message" do you mean what is described here?
http://www.washington.edu/imap/IMAP-FAQs/index.html#6.14
If so, then it is correct that this change over time.
Yes, that is the "placeholder" message I was referring to. In mailboxes that have never been empty when the POP client
connected, the X-IMAP info is stored in the first message in the mailbox, which seems to be moved to the next message
when that first message is deleted.
Why is that correct to change over time? Do you mean the second field of the X-IMAP header to change? It was my
understanding that the second field is a strict counter of the last assigned X-UID number, and the first field was a
time stamp of when the "DO NOT DELETE" message was created. The POP server is using the two to create a single UIDL
(hex representations of both field concacted). Wouldnt changing the first field (which is what we are experiencing)
cause the same message to have two different UIDLs and thus confuse the client?
Mac Mail.app has a file called "MessageUidsAlreadyDownloaded3" Although this is a database file, the info can be seen in
a text editor and when a user reports a "duplicate download" error, I will see entries such as:
483184DF000078cf which corresponds to 1211204831 as the first field of
the X-IMAP header (in the mail box file)
and 30927 as the X-UID of the message in
question
The duplicated messages will appear again with a different time stamp (the first 8 digits of the UIDL) and the same last
8 digits. Such as: 485295EF000078cf When this happens, the client thinks its a new message and redownloads and
displays it.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
