Subject: how to send MESSAGE/RFC822 content

From: Karsten Ballueder <[email-masked]>
Date: Wed, 10 Feb 1999 18:08:53 +0000 (GMT)

Hello,

I have a strange problem with the c-client lib, something that used to 
work (version 4.1 I think) and stopped after upgrading (I think my
current sources are based 4.2 or 4.3).

What happens?

I try to include a message as MIME content of type MESSAGE/RFC822 in a 
message and treat it exactly like a TEXT/PLAIN, i.e. I do something
like this:
   switch(type)
   {
   case TYPETEXT:
   case TYPEMESSAGE:
      bdy->type = type;
      bdy->subtype = (char *) fs_get(subtype.length()+1);
      strcpy(bdy->subtype,(char *)subtype.c_str());
      bdy->contents.text.data = data;
      bdy->contents.text.size = len;
      bdy->encoding = ENC8BIT;

This sends the message all fine, but when calling mail_free_body()
later, the library tries to delete the 
bdy->nested.msg
which is not filled in (while bdy->contents is and seems not to be
deleted).

Apparently there is some intention in this, as the relevant code
actually checks whether we have type MESSAGE/RFC822 before doing
so. Does this mean, I have to parse my message text and go through the 
whole process of building a body with subparts, etc just to include it 
in a mail?

Thank you very much in advance!
-- 
 Karsten Ballüder http://www.phy.hw.ac.uk/~karsten/ mailto:[email-masked]
 Physics Department, Heriot-Watt University, Edinburgh, EH14 4AS, Scotland
                     Tel. +44-(0)-131-4513068  Fax. +44-(0)-131-4513136
           "In a world without fences, who needs Gates?"  
-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Brenda Gates Spielman <[email-masked]>
Date: Thu, 11 Feb 1999 09:46:36 -0500

I have been tracking a similar problem using imap-4.4.   I have a test routine
which opens a mailbox, reads each message, and then closes the mailbox.   The
body  is fetched by a call to mail_fetchbody_full and then decoded with a call
to rfc822_base64.     If the test code does not free the content that was
returned by the call to mail_fetchbody_full, then there are blocks of unfreed
memory at the end of the program (i.e. massive memory leak).   If the test
program does free the content, then for each message of type MESSAGE/RFC822 an
invalid memory location is freed when closing with the calls:

     mail_gc (*imapHandle, GC_ELT|GC_ENV|GC_TEXTS);
    *imapHandle = mail_close_full (*imapHandle, CL_EXPUNGE);

I obtained the information about unfreed memory and improperly freed memory by
linking in a debug malloc library (dbmalloc).   I have also determined that the
error message is not being generated by a call to free with a null pointer.

---

From: Mark Crispin <[email-masked]>
Date: Thu, 11 Feb 1999 10:31:22 -0800 (PST)

On Thu, 11 Feb 1999 09:46:36 -0500, Brenda Gates Spielman wrote:
> I have a test routine
> which opens a mailbox, reads each message, and then closes the mailbox.
> The body  is fetched by a call to mail_fetchbody_full and then decoded with
> a call to rfc822_base64.  If the test code does not free the content that
> was returned by the call to mail_fetchbody_full, then there are blocks of
> unfreed memory at the end of the program (i.e. massive memory leak).

You are doing something wrong.  You MUST NOT free data that is returned by
mail_fetchbody().  Storage returned by mail_fetchbody() is returned at
mail_gc() or mail_close() time.

However, you ARE required to free data returned from rfc822_base64().  In
other words, you call mail_fetchbody(), save the returned pointer as btxt.
You then supply the btxt as input to rfc822_base64(), save the returned
pointer as rtxt.  You MUST NOT free btxt but you MUST free rtxt when you are
finished with it.

> If the test
> program does free the content, then for each message of type MESSAGE/RFC822
> an invalid memory location is freed when closing with the calls:
>

That is because you improperly freed c-client internal data.  I'm surprised
that you didn't get core dumps earlier from chasing bad pointers.

Also, there is absolutely no reason to call mail_gc() unless you want to
recover memory and still keep the stream open.  mail_close() does all
mail_gc() operations.  The only need for mail_gc() is on 640K DOS machines
where you have to free memory aggressively.

> >  Karsten Ball|der http://www.phy.hw.ac.uk/~karsten/
mailto:[email-masked]