Subject: Announcing: UW IMAP toolkit 2000 Release Candidate 7

From: Mark Crispin <[email-masked]>
Date: Wed, 20 Sep 2000 16:20:22 -0700 (PDT)

UW IMAP toolkit 2000 Release Candidate 7 is now on available on:
	ftp://ftp.cac.washington.edu/mail/imap.tar.Z

There are a few minor bugfixes to this version from RC6.  The most
important of these is on UNIX systems without a /dev/urandom; the
SSL-enabled version of c-client would leave behind an empty temporary file
on /tmp or /var/tmp.

There is one major new feature: references threading.  In addition to
orderedsubject threading (which has been there for some time), the UW IMAP
toolkit now has true threading via References/In-Reply-To, using the
algorithm in the IMAP THREAD Internet Draft and described by Jamie
Zawinski in http://www.jwz.org/doc/threading.html .  This is compatible
with the references threading that was recently added to Cyrus imapd.

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: David Lee <[email-masked]>
Date: Wed, 18 Oct 2000 15:50:10 +0100 (BST)

On Wed, 20 Sep 2000, Mark Crispin wrote:

> [...]

Thanks.  We are at the point where we need to revise our imap (and
imap-utils), so it would make sense for us to migrate, if possible, to
imap-2000. 

1. Are there any further events planned for the next week or so?  (Such
as RC8 or the official release?)

2. Should we move imap-utils at the same time?

More generally:

Our performance is being badly hit by mail software calling initgroups() 
for our 1000+ entry NIS groups map.  I have just tweaked our sendmail
config with "confDONT_INIT_GROUPS", which made a great improvement.  But
we still have imapd, popd and tmail which (I'm fairly sure) are also
calling initgroups().  My guess is that this is unnecessary, and I'm
thinking of producing a patch so that "initgroups()" can be bypassed
(using some sort of "#define" mechanism at build time).

I'd rather do it through a system-wide runtime config file, but there
doesn't seem to be such a mechanism (except one hedged around with all
sorts of dire warnings!).

Any thoughts?  (If it's a bad idea, tell me; if it's useful, I'll keep the
list informed of the patch.) 

Another point: why is imap-utils separate?  Given that it is so intimately
bound to the main imap software, why not just bundle it?  Its "Z" file is
a mere 66 KB, compared to the main 2102 KB.  Indeed, in another message,
you mentioned that it was vital to use compatible versions, so bundling
would greatly help to ensure this. 

Thanks for your continued provision of the great software.

-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/~dcl0tdl            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :

---

From: Mark Crispin <[email-masked]>
Date: Wed, 18 Oct 2000 08:35:58 -0700 (PDT)

> as RC8 or the official release?)

There will probably be an RC8, because it looks likely that there will be
another Pine prerelease before the release of Pine 4.30.

> 2. Should we move imap-utils at the same time?

Sounds like a good idea.

> (using some sort of "#define" mechanism at build time).

If you depend upon group access working (e.g. for shared mailboxes), then you
need the initgroups().  Otherwise, you can turn it off as you suggest, but
please remember that you broke group access (so don't send me a bug report
about it later!).

Sooner or later, there will be mechanisms to make group access more useful
with IMAP.  You'll have to decide whether to do without the facility, or solve
the problem in some other way.

I'm a little bit surprised to hear that anyone is able to use NIS+ and get
reasonable server performance.

> bound to the main imap software, why not just bundle it?

I've thought about it, particularly for tmail and dmail.  The problem is that
a great deal of effort had to go into aggressive portability in the main IMAP
toolkit.  Somewhat less portability effort went into the imap-utils, and that
needs to be fixed before they could be bundled.

They're UNIX-only; I would not feel happy with bundling unless (at least) I
made them work on Win2K.  It'd be easier to fix some, harder to fix others.

Then there's all the old UNIX ports.  There are still systems out there that
don't have ANSI C compilers.  I didn't write some of the imap-utils, and those
programs don't follow the rules necessary to feed through the unansi program
properly.  Fortunately, this problem is rapidly heading into extinction.

It probably will happen, eventually; but it can't happen yet.

> Thanks for your continued provision of the great software.

Thank you for the nice words.

---

From: David Lee <[email-masked]>
Date: Thu, 19 Oct 2000 16:53:01 +0100 (BST)

> another Pine prerelease before the release of Pine 4.30.

Thanks.

> please remember that you broke group access (so don't send me a bug report

Thanks for alerting me to the shared mailbox thing.  We don't (yet) use
that, but if any patch is to be generally useful, I must remember this.

Presumably shared mailboxes require initgroups() from the reader programs. 
But would tmail need it?  (That is, can tmail (on the one hand) and the
reader programs (on the other) be treated independently, or is their use
of initgroups() intimately tied together?) 

> the problem in some other way.

Thanks. A run-time config file would be useful.  The present mechanism
("docs/imaprc.txt" mentions "/etc/c-client.cf" and "~/.imaprc") is hedged
around with dire warnings.  Any chance of a facility that is safe (or as
reasonably safe as such things can be) for other sites to use? 

> reasonable server performance.

Our groups info is in NIS, not NIS+ .  And performance is exactly the
local issue that started this thread! 

> made them work on Win2K.  It'd be easier to fix some, harder to fix others.

??  If they are UNIX only, presumably the minimum necessary for
compatibility is a Win2K install procedure (whatever that may be) that
politely informs the user: "Not yet supported".  That's no worse than the
present, and considerably safer for compatibility, isn't it?

--

---

From: "Andrej Borsenkow" <[email-masked]>
Date: Thu, 19 Oct 2000 20:12:57 +0400

> reasonably safe as such things can be) for other sites to use?

I'm using /etc/c-client.cf and ~/.imaprc for years. Believe me, reasons for
these dire warnings are not technical. OTOH there is very little documentation
(existing one is more description than explanation), so you'll have to
sometimes check sources for precise effects of parameters.

> present, and considerably safer for compatibility, isn't it?

dmail and tmail have #include <sysexits.h>. On our system this file is not in
standard search path (and I do _not_ want to add it's location to search path)
so I have to manually copy it and adjust (t|d)mail.c. How it for a
compatibility problem? :-))

-andrej

---

From: Mark Crispin <[email-masked]>
Date: Thu, 19 Oct 2000 10:11:23 -0700 (PDT)

On Thu, 19 Oct 2000 20:12:57 +0400, Andrej Borsenkow wrote:
> these dire warnings are not technical.

I know that clever hackers like you are always going to use the power user
facilities like this.  The problem is that for every clever hacker, there's
1000 ordinary folks who are best off avoiding things that can hurt them.

Sites *have* burned themselves badly with ill-considered use of these files
(including lost mail).  Almost always, it's someone who didn't really need to
use them, but felt that he had to have them.  I get the bug reports.  If I'm
lucky, they admit to the mistake; more often, I get to waste a few hours
finding it out.

Someone who really, really, knows what he's doing can use these files to
advantage.  Nevertheless, "even monkeys fall from trees" sometimes.  I'm one
of them; I once burnt myself with those files!

On another note, folks, RC8 is out.  There are just a few minor changes from
RC7.  Hopefully it'll be the last one.