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 PROTECTED] 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 Imap-uw@u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw