Re: Mix format? must have? Project direction? [was Re: imap-2007b on SLES10SP1]

I don't see any reason why we all can't move the UW IMAP project over to 
SourceForge and continue working on it as a true open source 
development. I am very impressed that Mark dedicated so much of his time 
to it. Now it is our (collective) turn to start contributing to it.

-- 
*Bob Atkins * 
/President/CEO/

*DigiLink, Inc. <http://www.digilink.net>*
Business Inter-net-working
*/The Cure for the Common ISP!/*

	

Phone: (310) 577-9450
Fax: (310) 577-3360
eMail: bob <at> digilink.net

Linda Walsh wrote:
> Oscar del Rio wrote:
>> Jarmila Holcova wrote:
>>>  > I'm about to move mail server for 15000 users to a new server. The
>>>  > SLES10SP1 distribution contains imap-2004. I would like to use the
>>>  > newest version.
>>> The build is ok but I decided to use the rpm from the SLES 
>>> distribution in the end.
>>> What a coward am I!
>>> Thanks though.
>>
>> As Mark would say, IMAP-2004 is ancient and there were many 
>> features/fixes introduced since then.  For example, I don't think 
>> IMAP-2004 had "mix" format, which IMHO is a "must have" nowadays.
>> _______________________________________________
> Mix format?  Why is that a "must have" nowadays?
>
> Also, As for 2007'c', where would one obtain sources for it? I take it 
> that it was never actually officially released, but I
> seem to remember Mark saying it was "ready to go".
>
> As for other features/work -- does anyone know if another UW project 
> is picking
> up imapw?  It seems to be fairly widely used.
>
> It seems that Cyrus IMAP is the only open-source alternative available 
> that has
> any 'traction'?  I've been unwilling to abandon the "mbox" format 
> compatibility
> provided by IMAP -- though heaven knows, how many 3rd party open-source
> plug-ins don't handle the format (w/rt "From ") correctly all the time.
> Not sure I know of many that do.  I get "ribbed" by occasional mbox 
> chomping
> by Perl-scripts using CPAN modules and some derivations based on 
> Berkeley Mail
> 8.x -- like the 'Nail' version that provides Mail/mailx drop-in support.
> (Maybe that means I'm not 'ribbed' by chomping, but 'nailed'??)...
>
> Linda
>
> _______________________________________________
> Imap-uw mailing list
> Imap-uw <at> u.washington.edu
> https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
>

_______________________________________________
Imap-uw mailing list
Imap-uw <at> u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Re: Mix format? must have? Project direction? [was Re: imap-2007b on SLES10SP1]

In regard to: [Imap-uw] Mix format? must have? Project direction? [was Re:...:

> Mix format?  Why is that a "must have" nowadays?

If you're using UW IMAP, mix has some major advantages over both
traditional format and mbx.

> Also, As for 2007'c', where would one obtain sources for it? I take it
> that it was never actually officially released, but I
> seem to remember Mark saying it was "ready to go".

I think you're thinking of 2007b, as that was what was unreleased when
Mark was let go.

> As for other features/work -- does anyone know if another UW project is
> picking up imapw?  It seems to be fairly widely used.

The future is uncertain, but it seems highly unlikely that UW would be
the driving force behind UW imapd in a year's time.  If it's going to
continue to get future development, it probably has to come from some
other source.

> It seems that Cyrus IMAP is the only open-source alternative available
> that has any 'traction'?

I believe that is incorrect.  Cyrus is probably the best known
alternative, but I think dovecot is compelling, especially since it
apparently can index traditional format -- kind of a better (IMHO) mbx.
Mark also commented favorably on dovecot on this list.

There are other options as well.  In fact, there are a surprising number
of options.  Do a web search for the script "imapsync", download it, and
then look at the products its been tested with in its README.  That turned
up several free or open source IMAP implementations I had never heard of.
Several of them are definitely worth another look.

Tim

Re: Mix format? must have? Project direction? [was Re: imap-2007b on SLES10SP1]

> > As Mark would say, IMAP-2004 is ancient and there were many 
> > features/fixes introduced since then.  For example, I don't think 
> > IMAP-2004 had "mix" format, which IMHO is a "must have" nowadays.
> > _______________________________________________
> Mix format?  Why is that a "must have" nowadays?
...
> As for other features/work -- does anyone know if another UW project is 
> picking
> up imapw?  It seems to be fairly widely used.
> 
> It seems that Cyrus IMAP is the only open-source alternative available 
> that has
> any 'traction'?  I've been unwilling to abandon the "mbox" format 
> compatibility
> provided by IMAP -- though heaven knows, how many 3rd party open-source
> plug-ins don't handle the format (w/rt "From ") correctly all the time. 

Why are you sticking with mbox? IMAP storage involves metadata storage,
and by using mbox you are forcing imapd to embed the metadata as data,
which is awkward. Nor does uw-imapd index this format, so opening a
mailbox for the first time is slow.

http://www.washington.edu/imap/documentation/formats.txt.html

mix improves performance dramatically, partly because the different kinds
of (meta)data are stored in separate files, and so can be accessed with
different locking arrangements. Files are also kept small to make
modifications fast and backing up efficient.

http://www.washington.edu/imap/documentation/mixfmt.txt.html

> Not sure I know of many that do.  I get "ribbed" by occasional mbox chomping
> by Perl-scripts using CPAN modules and some derivations based on 
> Berkeley Mail
> 8.x -- like the 'Nail' version that provides Mail/mailx drop-in support.
> (Maybe that means I'm not 'ribbed' by chomping, but 'nailed'??)...

All the more reason to move away from mbox ASAP. imapd's snarfing
mechanism provides an excellent way to migrate. For example, you can
begin by rebuilding with CREATEPROTO=mixproto and then doing
mailutil create INBOX
as a user who does not already have an INBOX. The next time they access
INBOX the contents of their unix/mbox maildrop will be converted and
transferred to this new mix-format INBOX. Having changed CREATEPROTO will
also mean new mailboxes they create will be in mix-format.

Once you have convinced yourself this is working well enough, you can
use mixcvt to convert other existing mailboxes. Alternatively, you can use
mixcvt with the INBOX instead of creating it and letting snarfing do the
conversion. There are some differences in the results between these
approaches.

Cheers,

	- Joel
_______________________________________________
Imap-uw mailing list
Imap-uw <at> u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw