Subject: message/rfc822 (the other direction)

From: Mike Macgirvin <[email-masked]>
Date: Tue, 25 May 1993 15:53:16 -0700 (PDT)

I got the type message/rfc822 stuff working very well on the incoming 
side (Many thanks Mark, many things got cleaned up as a result). Now I'm having
troubles going the other direction (building a multipart for sending which 
includes an rfc822 message).  I don't know the recommended way to do this, so 
please don't flame if I've overlooked something obvious, or I'm doing something
foolish. All I have to go on right now is from looking at Pine code and reading
Internal.DOC.   

	Anyway, I put together a new body part and fill in the envelope and 
type info such just as for any other attachment (which work fine). In this case
I have (part->body)->contents.msg.text point at the actual message text (a 
complete message w/header). This appears to be what Pine does. Other than that,
it's processed like any other attachment (which all work correctly). 
smtp_mail() is called on the top-level body, and any other parts are sent 
intact, while the rfc822 attachment always arrives devoid of contents.
	So, any clues as to what I've done wrong here?

---

From: Mark Crispin <[email-masked]>
Date: Thu, 27 May 1993 00:08:22 -0700 (PDT)

Hi Mike -

     The answer to your question is that the MESSAGE structure is used by the
MIME parser only (note the comment to that effect in mail.h in the definition
of the BODY structure at the contents union.

     In particular, body->contents.msg.text is something that is private to
the imap2 driver and MUST NOT be used by main programs.  The only things in
the MESSAGE structure that you may look at are the env and body pointers
(body->contents.msg.env and body->contents.msg.body).  The text and offset
members are private for various drivers (and I'll probably smash them together
in a union too since both are never used simultaneously).

     In order to send a MESSAGE attachment, you have to put it on body-
>contents.text like you would any other type of attachment.  See the routine
rfc822_encode_body() in rfc822.c for how this works.

     I will be the first to admit that this is ugly, hideous, and inconsistent
and I'll probably be reincarnated as a banana slug for doing it that way, but
it was easier to program that way, both in c-client and in the main programs.

     Probably I'll get reincarnated as a banana slug right next to a hungry
garter snake (or a fellow with a salt shaker) for this, but Internal.DOC is
way out of date (almost a year old).  I don't think there are very many lies
in it and certainly no egregious ones, but it is missing quite a bit that was
added or changed in the past year.  The only 100% reliable document right now
is the c-client sources, so when in doubt you should refer to them.

     I'll probably update Internal.DOC sometime after updating the IMAP2
protocol specification, which is a looming Urgent Problem.

-- Mark --

---

From: Mike Macgirvin <[email-masked]>
Date: Thu, 27 May 1993 07:23:14 -0700 (PDT)

>       In order to send a MESSAGE attachment, you have to put it
>  on body-contents.text like you would any other type of attachment. 
>  See the routine rfc822_encode_body() in rfc822.c for how this
>  works.

	Yes, I was tracing through yesterday, and found the reference in 
rfc822_encode_body(). You might do implementors a small favor by 
changing:

/* case MESSAGE:	*/	/* here for documentation */

	to "TYPEMESSAGE" so it's easier to grep. ;-) 
(Perhaps you've done this already). I might have found it long ago... 

>       I will be the first to admit that this is ugly, hideous,
>  and inconsistent and I'll probably be reincarnated as a banana
>  slug for doing it that way, but it was easier to program that
>  way, both in c-client and in the main programs.

	I agree it's ugly. 

>       Probably I'll get reincarnated as a banana slug right
>  next to a hungry garter snake (or a fellow with a salt shaker)
>  for this, but Internal.DOC is way out of date (almost a year
>  old).  I don't think there are very many lies in it and
>  certainly no egregious ones, but it is missing quite a bit
>  that was added or changed in the past year.  The only 100%
>  reliable document right now is the c-client sources, so when
>  in doubt you should refer to them.
>  
>       I'll probably update Internal.DOC sometime after updating
>  the IMAP2 protocol specification, which is a looming Urgent
>  Problem.

	I try to use the sources when I can, but not yet knowing them 
intimately, the fact that most function calls are through function pointers (I 
understand and agree with the reasons for doing this), it makes it difficult to
really find out the logic flow without single stepping (no fun). I find that 
the doc is, as you say, almost always correct; but we're left swinging a bit on
actually using the MIME interface. But this isn't a flame. As long as I can 
work through it somehow...

	But, I may have uncovered a bug "somewhere" in the client related to 
the rfc822 attachments. I haven't been able to pinpoint it yet. The scenario 
is, I build the body (with rfc822 attachment sitting in contents.text) and pass
it smtp_mail(). When it returns from that function, the msg.env pointer for the
attachment has been altered, i.e. is non-zero, but isn't a valid envelope. This
causes seg faults immediately afterward when mail_free_body() is called to 
de-allocate the entire body structure. I'm punting temporarily; going through 
the partlist and zeroing envelopes for rfc822 attachments before freeing the 
body.  This could cause me to be re-incarnated as a dodo bird, so I could use a
little help.

mike

---

From: Mark Crispin <[email-masked]>
Date: Thu, 27 May 1993 19:26:22 -0700 (PDT)

Mike -

     I take back what I told you before.  Use body->contents.msg.text for
attachments of type message.  I've changed the rfc822.c source to conform with
this.  It's cleaner all around.  The problem with mail_free_body() was the
final straw.  If you want to fix it in your own sources without getting the
latest version, make that ``case MESSAGE:'' comment be a real ``case
TYPEMESSAGE:'' conditional with a break in it (do *not* fall into the default
case -- this is a bugfix).

     Note that the message sending routines do not use the env or body members
of the MESSAGE structure; the entire message must appear as a char * string in
the text member (msg.text).

     It turns out that you're the first person who tried to use this code.
Pine has its own private code (using disk files), because it has to run on DOS
and can't use in-memory buffers the way the c-client code wants to.

     Please let me know if tonight's version on ftp.cac.washington.edu works
any better.

-- Mark --