Subject: [Imap-uw] mailutil double count, 2004f comments

From: Tim Mooney <[email-masked]>
Date: Wed, 31 Aug 2005 17:33:04 -0500 (CDT)

A few comments:

- It appears that mailutil double counts every message when doing a
   "check", at least for mbx-format mailboxes:

sh-2.05$ /usr/local/sbin/mailutil check INBOX
0 new message(s) (14 unseen), 16 total in INBOX
sh-2.05$ grep -a '..-...-.... ' INBOX
31-Aug-2005 16:30:27 -0500,31268;000000000000-000024b1
31-Aug-2005 16:21:43 -0500,5709;000000000000-000024b2
31-Aug-2005 16:19:59 -0500,3387;000000000000-000024b3
31-Aug-2005 15:14:17 -0500,2939;000000000000-000024b4
31-Aug-2005 16:41:33 -0500,6001;000000000001-000024b5
31-Aug-2005 16:54:08 -0500,3062;000000000000-000024b6
---------------Our Most Asked for Offers---------------
31-Aug-2005 16:57:37 -0500,3161;000000000000-000024b7
31-Aug-2005 17:06:21 -0500,4782;000000000000-000024b8

Red Hat's pine (4.44) on this system correctly says there are 8 messages
in INBOX, 7 unseen.  mailutil is from the 2004c1 distribution, but I just
built 2004f today and the same thing happens.  These aren't messages that
haven't been garbage-counted or something like that -- there are only 8
messages in that INBOX.

- I see 2004f is out as of a few days ago, but the IMAP Information Center
   web page doesn't mention it or 2004e.

- It's cool that 2004f includes experimental support (not enabled by
   default) for SSL alternate names.  I tried building it, and it looks
   like it requires a newer version of OpenSSL than the standard ssl_unix.c
   requires.  On Red Hat 2.1AS, which includes (a probably heavily
   modified) OpenSSL 0.9.6b, the standard ssl_unix.c builds fine but the
   experimental one won't:

osdep.c: In function `ssl_start_work':
osdep.c:417: `sslclientcert_t' undeclared (first use in this function)
osdep.c:417: (Each undeclared identifier is reported only once
osdep.c:417: for each function it appears in.)
osdep.c:417: parse error before `scc'
osdep.c:419: `sslclientkey_t' undeclared (first use in this function)
osdep.c:435: `scc' undeclared (first use in this function)
osdep.c:443: `sck' undeclared (first use in this function)

I don't know if that's possible to fix or even whether it's worth anyone's
time to investigate, but I thought it might be a useful note for the
documentation.

- It would be really helpful if mailutil supported some kind of a "what
   version am I?" argument, so it would be possible to interrogate it and
   find out what version of the imap toolkit it came from.

Tim
-- 
Tim Mooney                              [email-masked]
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Tim Mooney <[email-masked]>
Date: Wed, 31 Aug 2005 17:36:03 -0500 (CDT)

> haven't been garbage-counted or something like that -- there are only 8

I meant "garbage-collected".  Sorry about that.

Tim

---

From: Mark Crispin <[email-masked]>
Date: Wed, 31 Aug 2005 15:48:36 -0700 (Pacific Daylight Time)

>  "check", at least for mbx-format mailboxes:

Did you modify the software in any way?

In particular, did you modify the sysinbox() routine to point to the 
mbx-format INBOX?  If you did, don't do that.

>  web page doesn't mention it or 2004e.

Both 2004e and 2004f are patch-only releases.  2005 will be the next major 
release, unless it gets to January in which case it'll be 2006... :-)

>  requires.

Hmm.  It looks like it needs the imap-2005 version of mail.h.  Oh well

If you really want to play with it, I'll send you the definitions of 
sslclientcert_t and sslclientkey_t; otherwise, wait until imap-2005 comes 
out.

>  find out what version of the imap toolkit it came from.

Starting in imap-2005, mailutil announces its version in its help text.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Tim Mooney <[email-masked]>
Date: Wed, 31 Aug 2005 18:10:50 -0500 (CDT)

> mbx-format INBOX?  If you did, don't do that.

That is exactly what was done, to support home directory mail delivery
on our IMAP servers.  Our sysinbox() in env_unix.c looks like:

char *sysinbox ()
{
   char tmp[MAILTMPLEN];
   if (!sysInbox) {              /* initialize if first time */
#if defined(KERDAP)
     sprintf(tmp, "%s/INBOX", myHomeDir);
#else
     sprintf (tmp,"%s/%s",MAILSPOOL,myusername ());
#endif
     sysInbox = cpystr (tmp);    /* system inbox is from mail spool */
   }
   return sysInbox;
}

and we are compiling with KERDAP defined.  I probably already know
the answer to this, but I have to ask: do you have a recommendation for
a better method of having all of the imap suite (imapd, dmail, mailutil,
et. al.) have both INBOX and all users folders relative to the user's home
directory?

> sslclientcert_t and sslclientkey_t; otherwise, wait until imap-2005 comes out.

We can wait.

> Starting in imap-2005, mailutil announces its version in its help text.

Excellent, thanks.

Tim

---

From: Mark Crispin <[email-masked]>
Date: Wed, 31 Aug 2005 16:14:30 -0700 (Pacific Daylight Time)

On Wed, 31 Aug 2005, Tim Mooney wrote:
> on our IMAP servers.

That's completely unnecessary and (as you noticed) counter-productive.

sysinbox() should always point to the traditional UNIX mail spool.  It's 
perfectly alright if there is no traditional UNIX mail spool.  What you 
don't want is for sysinbox() to point to something other than the 
traditional UNIX mail spool.  The bogus double count in mail_status() 
(which is what mailutil reported) is only the tip of the iceberg of what's 
wrong when you make sysinbox() point to a home directory INBOX.

> I probably already know

Since you are using mbx format, that's already the case without you having 
to do anything.  mbx format INBOX is always in the user's home directory.

-- Mark --

---

From: Tim Mooney <[email-masked]>
Date: Wed, 31 Aug 2005 18:25:10 -0500 (CDT)

In regard to: Re: [Imap-uw] mailutil double count, 2004f comments, Mark...:

> Since you are using mbx format, that's already the case without you having to 
> do anything.  mbx format INBOX is always in the user's home directory.

When we started with this scheme, we were still using traditional UNIX
"From " style folders.  We converted to MBX about 18 months ago.

We'll have to do some testing, especially with dmail, but hopefully we
can just get rid of this patch now that we're using MBX exclusively for
delivery to the INBOX.

Thanks for the clarification.

Tim