Hello Mark, No, not yet, I am going to test it on another machine first and will install it on the mail server if those are successfull. imap 2006b works like a rock on Tru64 Unix however, not a single problem there with about 2700 accounts :-)
best regards, Andres -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Crispin Sent: maandag 13 november 2006 19:04 To: Andres Henckens Cc: [email protected] Subject: RE: [Imap-uw] 2006b,c behaviour Did you try imap-2006c1? On Mon, 13 Nov 2006, Andres Henckens wrote: > Hello, > > I have reverted back to imap 2004g 2 weeks ago and it runs without any > problem. Has there been any bugfix the last few weeks that could have > affected my problem in a positive way ? > > best regards, > Andres > > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Mark Crispin > Sent: zaterdag 28 oktober 2006 23:27 > To: henckens > Cc: [email protected] > Subject: Re: [Imap-uw] 2006b,c behaviour > > 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. > > > 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. > > > 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. > > -- Mark -- > > http://panda.com/mrc > Democracy is two wolves and a sheep deciding what to eat for lunch. > Liberty is a well-armed sheep contesting the vote. > > _______________________________________________ > Imap-uw mailing list > [email protected] > https://mailman1.u.washington.edu/mailman/listinfo/imap-uw > -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
