On Sat, 28 Oct 2006, henckens wrote:
You were right, ipop3d and imapd behave identically, I just had
another case today with someone who had twice received a fairly
large (600 msgs) inbox using ipop3d and the outlook client.
600 messages is not particularly large for an mbx format file.
The only thing I noticed where the faults found with the 'mailutil
check' command as reported earlier.
"mailutil check" uses the same code (c-client library) as imapd and
ipop3d. The only difference is the level of reporting. POP3 protocol
has much less available to report problems than IMAP protocol or shell
tools such as mailutil.
I mentioned that our system is Redhat 4AS, but forgot to mention
that it is itanium (64-bit only), mabye a shot in the dark, but you
never know.
Well, one possibility is if you built the software in 64-bit mode. If
you did, try rebuilding it in 32-bit mode. The IMAP software is
currently untested in 64-bit mode, and I've heard reports of some
issues when it is built in 64-bit mode.
ouch, I have to install the 32-bit libraries first then, I was hoping
that I never needed them.
I examined the INBOX file and took the same file from a backup I
took a bit earlier, so I could compare.
The files are similar, but the latest file has a new UID on every message.
From the data you provided, the software detected the duplicate UIDs
and correctly reassigned a new UIDVALIDITY and new UIDs. That worked
properly; the question is how the problem happened in the first place.
I wonder if there was some sort of locking failure. Is NFS involved in
any way? Have you modified the software in any way? Did you obtain
the software directly from UW, or was it through a third-party?
If it is a third party distribution, please try the original UW
software. Some of these third party distributions have been "improved"
in ways that break the software, particularly in the locking code.
No NFS, and always get my sources from your ftp site :-)
We use postfix 2.3.3 with the '/usr/sbin/tmail $USER' as mailbox
delivery. But here is also some LMTP involved to amavisd-new and back.
There was also a multipart mime message here.
That shouldn't matter. At the level of message metadata, it doesn't
know multipart from single part, or even if there are any valid headers
at all.
OK, I will downgrade back to imap 2004 again and see if the complaints
stop, I think it's the only way to be sure where/what goes wrong and
when. Personally I hate 'intermittend' problems, things that don't
work at all are easier to fix.
best regards,
Andres
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
