Subject: # of folders

From: "Huynh Muoi" <[email-masked]>
Date: Wed, 21 Jan 2004 21:04:36 +0000

Dear Folks,

I am wring c-client to determine all the folders and sub-folders when 
logging into an account ...
Is there a simple API that I can you to determine this ? Or Can you let me 
know any way to
perform this task ?

Thanks,

Huynh Muoi

_________________________________________________________________
High-speed users—be more efficient online with the new MSN Premium Internet 
Software. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1

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

---

From: Mark Crispin <[email-masked]>
Date: Wed, 21 Jan 2004 14:03:27 -0800 (Pacific Standard Time)

On Wed, 21 Jan 2004, Huynh Muoi wrote:
> I am wring c-client to determine all the folders and sub-folders when logging
> into an account ...

You can do this with mail_list(NIL,NIL,"*"); the names will be returned
via mm_list() calls.  However, you'll find that you don't really want to
do that.  Many people have things other than mailboxes in their accounts,
and people also tend to have symlinks that make the graph much larger or
even loop.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: "Clive McDowell" <[email-masked]>
Date: Fri, 2 Apr 2004 09:53:12 +0100

Folks,

sorry this is mailbox format related rather than a c-client issue but I
thought this would be a good list to ask. We want to convert all the
inboxes on a Solaris 8 platform from standard unix to mbx format. There
are already a few inboxes in that format and our exim MTA is set up to
deliver to such inboxes if they exist. Is the best approach to use
mailutil for each user? e.g. 

mailutil move /var/mail/joesoap #driver.mbx/home/joesoap/INBOX

Are there any other options?

Thanks,

 Clive McDowell

Information Services
The Queen's University of Belfast

---

From: Sahil Tandon <[email-masked]>
Date: Sat, 3 Apr 2004 18:23:49 -0500

> Are there any other options?

AFAIK, if an emtpy mbx format INBOX exists in /home/$user/INBOX, an imap
connection to the server will cause the mbx driver to "automatically snarf" the
contents of /var/mail/$user -> /home/$user/INBOX.

Search comp.mail.imap for "advantages/disadvantages of mbox driver?" to read
some relevant posts by Mark Crispin, et al.

-- 
Sahil Tandon <[email-masked]>

---

From: Tim Nicholson <[email-masked]>
Date: Thu, 8 Apr 2004 10:37:49 +1000

I am using the c-client lbraries, and using some mbx format mailboxes.

Occasionally, usually after a system crash, I get corrupted mbx format 
mailboxes.

Is there a tool for repairing, or simple documentation on how to do so?

I can see the messages in the file, but get "Error opening or locking 
INBOX" messages
in the log files.

Using "mailutil copy" to try read the mailbox, I get an error like:

Unable to parse internal header at 13815331: 4Rgxf3J0BM5PembZO3ouNqzT778

Any ideas on how to fix this?

Thanks in advance,
Tim.

---

From: Mark Crispin <[email-masked]>
Date: Wed, 7 Apr 2004 18:03:10 -0700 (Pacific Daylight Time)

> Occasionally, usually after a system crash, I get corrupted mbx format 

I assume that you already are taking remedial action on whatever is 
causing those system crashes, including such things as using an 
uninterruptable power supply.

> Is there a tool for repairing, or simple documentation on how to do so?

Some people have written their own tools.  Here's information in the FAQ 
on what you need to know:
 	http://www.washington.edu/imap/IMAP-FAQs/index.html#7.15

> INBOX" messages in the log files.

That message is a catch-all from the POP3 server, and as you can expect 
isn't particularly useful.  Pine, the IMAP server, or (as you noticed) 
mailutil will provide better information.

> Unable to parse internal header at 13815331: 4Rgxf3J0BM5PembZO3ouNqzT778

This specific error is the most common encountered with a corrupt mbx 
format mailbox, and is covered in the IMAP FAQ including what to do.

Please let me know if you need any more help.

-- Mark --

---

From: David Lee <[email-masked]>
Date: Thu, 15 Apr 2004 17:50:32 +0100 (BST)

> contents of /var/mail/$user -> /home/$user/INBOX.

(Note: talking about "mbx" (without the 'o') format.)

Is there any reason why "/var/mail/$user" (usually in trad. UNIX format)
cannot itself be in "mbx" format?  (Trying it as such seems not to work,
and this seems to be confirmed by the "docs/drivers.txt" description.)

It would be useful to us if our inboxes could continue to be in the
normal, non-home "/var/mail" area, but in (optional) "mbx" format.  Any
philosophical reasons why this (so it seems) is not possible?

Thanks in advance.

-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 334 2752                  U.K.                  :

---

From: Mark Crispin <[email-masked]>
Date: Thu, 15 Apr 2004 11:14:03 -0700 (PDT)

> and this seems to be confirmed by the "docs/drivers.txt" description.)

That's a good question!  Fortunately, there are good answers:

The spool directory is perceived by a large body of software to be "owned" 
by the traditional UNIX mail facility.  As such, there is all sorts of 
software which will happily append a traditional UNIX format message to a 
file in the spool directory without any check to see if, in fact, that 
file actually is a traditional UNIX format message.  The result is a 
corrupted mbx format mailbox.

You would think "shouldn't programs invoke sendmail, or at least pipe to 
/bin/mail or /bin/mail.local or whatever?"  Of course!  But all too many 
programs write directly because "it is more efficient that way."

Another technical issue is that using the spool directory for any other 
format breaks the capability of a user independently deciding to use 
another format.  Most software packages convert from traditional UNIX 
format to another format; arbitrary format conversion is clanky at best.

As for philosophical questions:

There are system management and privacy concerns for not having people's 
INBOX in a shared spool directory.

It is easier to administer quotas when the INBOX is co-located with the 
non-INBOX mailboxes.  It is perfectly reasonable to set the user's 
"mailbox directory" to be something other than the user's UNIX home 
directory, and many sites do this.

Anyone can obtain information about the size, last write, and last read of 
anyone else's INBOX in a shared directory.  This can be, in certain 
circumstances, extremely useful for bad guys.

-- Mark --

---

From: David Lee <[email-masked]>
Date: Mon, 19 Apr 2004 16:01:12 +0100 (BST)

> corrupted mbx format mailbox.

Fair enough, in those many environments where c-client is not the
exclusive access to the "/var/mail" area.

In our own case, with one local exception, only c-client things access the
"/var/mail/$user" area, and we already run with "env_unix.c"/"*sysinbox()"
adjusting to use a different, non-default path.  (For the record this is
"/var/mail/MN/$user" location where MN is uid-mod-100).

> programs write directly because "it is more efficient that way."

Agreed.  Our aforementioned "local exception" took this short cut, and
we're happy to regard that as our own problem of own own making that we
would need to sort out (and ought to anyway!).

> circumstances, extremely useful for bad guys.

But they are all independent of the format (UNIX v. mbx etc.) in that
"/var/mail" area, aren't they?

All we're really after is a way for the INBOX to continued to be in some
area that isn't the home directory, and the existing "/var/mail/.../$user"
seemed a reasonable thought.  (The only necessary change is to be "mbx"
rather than UNIX format.)

A further question: if the INBOX is in the home directory, and an incoming
message would take it over quota, what is _supposed_ to happen?

With a test account, I put an mbx format "INBOX" into the home directory
and arranged for that homedir to be almost up to quota.  I then delivered
some messages:

1. They delivered until the quota was exceeed, then backed up in
   "/var/spool/mqueue" with EX_TEMPFAIL:  that seems reasonable.

2. At the point where quota is exceeded, the "INBOX", previously OK, went
   corrupt.  Pine showed:
      Invalid UID 0000000b in message 11, rebuilding
   then a few seconds later:
      SELECT failed: Last message (at 274832) runs past end of file (291881 > 290816)
   That seems unreasonable.  The one that tips the quota-balance also
   seems to corrupt the file.

(imap-2002e, by the way.  And the home directories are on a NFS server, so
have to be NFS mounted onto the c-client email machines.)

--

---

From: Mark Crispin <[email-masked]>
Date: Mon, 19 Apr 2004 18:29:05 -0700 (Pacific Daylight Time)

> message would take it over quota, what is _supposed_ to happen?

If delivery fails due to over quota, it is supposed to revert the file to 
its previous state by truncating the file to the pre-delivery size.

> have to be NFS mounted onto the c-client email machines.)

Are you saying that the mailbox file is accessed via NFS?  mbx format is 
not guaranteed to work via NFS.

-- Mark --

---

From: David Lee <[email-masked]>
Date: Tue, 20 Apr 2004 16:59:08 +0100 (BST)

> its previous state by truncating the file to the pre-delivery size.

OK.  Thanks.

> not guaranteed to work via NFS.

Indeed, that would be NFS access.  And our NFS settings for the homedir
are historically weak, allowing all sorts of attribute caching.  So I can
well believe that our corruption on this test account is because of that:
we're asking for trouble in such a context!  Indeed, leading up to this
test, we had anticpated that this might be a problem, but I forgot about
it in yesterday's reporting.  Sorry.

So for the moment you may safely regard that corruption report as our
local problem (nothing for you to worry about) almost certainly caused by
our local inappropriate NFS settings.

Just for interest, our "/var/mail" area (UNIX format inboxes) is also
NFS-mounted from the central NetApp fileserver onto the cluster of
front-end IMAP/POP/tmail/dmail servers (RH9; Solaris 8).  But here we have
very strong NFS arguments:  rw,noac,actimeo=0   and see no problems.
(I realise the IMAP distribution urges great caution with NFS in any email
context, but these systems (RH9, Solaris8, NetApp) seem to have good NFS
implementations, so with strong NFS arguments the combination seems OK.)

(But, to return to our scheduled programming, it would be nice if there
were the option of "/var/mail" accepting an "mbx" format!)

--

---

From: Shawn Walker <[email-masked]>
Date: Fri, 23 Apr 2004 13:37:32 -0500

I know there is a mail_append_full() that will upload a message to a 
folder, but the message has to be formatted into a string.

How can I use rfc822_output() or one of the rfc822_* functions to convert 
the ENVELOPE and BODY into a string with out having to create a SMTP 
stream?

Thanks,
Shawn

---

From: Mark Crispin <[email-masked]>
Date: Fri, 23 Apr 2004 11:53:11 -0700 (PDT)

On Fri, 23 Apr 2004, Shawn Walker wrote:
> How can I use rfc822_output() or one of the rfc822_* functions to convert the 
> ENVELOPE and BODY into a string with out having to create a SMTP stream?

You need to define a soutr_t function that will add a null-terminated 
string to an output stream.  To show you the concept, here is a sample
function (I don't advise actually doing this)

long mysoutr (void *stream,char *s)
{
   return *s ? (long) strcat ((char *) stream,s) : LONGT;
}

You can then do something like:
   rfc822_output (tmphdrbuf,env,body,mysoutr,(void *) msgbuf,NIL);

Note that tmphdrbuf has to be a large enough bigbuf to hold the entire 
header and msgbuf has to be a large enough bigbuf to hold the entire 
message.  There's no protection against buffer overflow here.

To avoid buffer overflow, a more sophisticated application would probably 
write to a tmpfile instead, and define a rfc822out_t function as well so 
as to avoid the call to rfc822_header() (and do rfc822_header()'s work 
manually).  Then do rfc822_encode_body_[78]bit() followed by 
rfc822_output_body().

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Fri, 23 Apr 2004 11:58:03 -0700 (PDT)

On Fri, 23 Apr 2004, Shawn Walker wrote:
> I know there is a mail_append_full() that will upload a message to a folder, 
> but the message has to be formatted into a string.

Now...as far as mail_append_full() arguments goes, note that it is not a 
char*, but rather a stringstruct.  That means that you provide functions 
which supply the data on demand.  So, you can build individual pieces of 
the message on the fly as needed by the stringdriver.

-- Mark --

---

From: Shawn Walker <[email-masked]>
Date: Fri, 23 Apr 2004 14:02:15 -0500

> the message on the fly as needed by the stringdriver.

I rather have c-client deal with all the ENVELOPE and BODY that contains 
everything about the message that has everything about the message I want 
to upload (attachments and embedded messages) and that I don't need to 
worry about trying to construct the message myself.