Re: [Nmh-workers] Should attachment header handling be in send?

[Joel Reicher]

> > The whole point of my emails is that I *do* intend to work on this, but
> > I'd like to get it right. While I'm on that point, though, could you tell
> > me where I should put this work? Bug reports with submitted patches and
> > patches on Savannah don't seem to be picked up.
> 
> That's great.  Thanks for contributing.  Since I'm not sure that this is a
> bug as opposed to a new set of features, I'd just check 'em in.  If bug repor
> ts
> don't seem to be working, please contact the Savannah admin.  I've done that
> in the past when things were clogged up on their end.  As far as I can tell,
> everything is set up correctly.

The bug reports (with patches) that I've done over the past couple of
months are certainly there, but nobody's picking them up. I'm pretty sure
it's not a Savannah problem. There are reports (with patches) from other
people that go back a year or two.

I wasn't assuming I'd be given CVS access, which is why I've been using
that mechanism.

> > > I would change it to get rid of
> > > the whole mime-composition file thing.  I would change forw and repl so t
> hat
> > > they build attachment headers instead of mime composition files.  Aha!  N
> ow
> > > that I'm rambling on here, I'd add a -attach option to other programs, or
> > > a single attach option as Oliver suggested earlier.  If the attach option
> > > is not set, things should work as they do today.  If it is set, then forw
> > > and repl should use attachment headers.
> > 
> > I'm happy to add that. How about something like if the attach command
> > in whatnow is given a number, it interprets it as a message number and
> > forwards a message rather than attaches a file? To save having two
> > different types of header, mhbuild/send could do the same thing. Attaching
> > a file that is a number would still be easy though, since you could
> > do something like ./123
> 
> This doesn't sound good to me.  I don't want to break the existing attach
> command format.  Also, attaching files is the main thing here to me, not
> forwarding messages.  My suggestion is to modify the forw and repl commands
> so that if a -attach option exists they add an attachment header with the
> name of the message being forwarded or replied to.  If that's not clear
> enough, what I'm suggesting is that
>       
>       forw 123
> 
> when the folder is my inbox make a message that begins with
> 
>       X-MH-Attachment: /home/Mail/jon/inbox/123
> 
> Of course, the X-MH-Attachment field name is whatever you specify.

I probably didn't make clear why I thought the magic I described would
be needed. Messages should be encpasulated in message/rfc822 parts, and
I don't like the idea of mhbuild or anything else trying to figure out that
a text file is in fact a message. So unless a second kind of header is
introduced, it needs to be done based on filename. How would you do
this?

> > > I'm a bit confused by the discussion of encapsulating a mime message in a
> > > mime message.  It's no big deal.  What you want is to take the message th
> at
> > > you're encapsulating and make it a single part of the new message; you do
> n't
> > > want to split it into parts and then put each part into the new message.
> > 
> > I also thought you'd say this. Perhaps I'm missing something, but I don't
> > see how you could reliably parse the headers of the message being
> > encapsulated, and you need to, because some of that must become headers
> > of the new message, such as To: and cc:. Some of it, however, can't be,
> > such as content-type, which might have to be changed to multipart as
> > a result of the attachments being done. The message body, of course,
> > is easy.
> 
> Not sure that I need to responed because you probably know what I'd say :)
> I wasn't talking about encapsulating the whole message, just the message
> body.  That's the behavior that I'd expect.  It's easy to split the body
> from the headers, and it's easy to encapsulate the body.  But in any case,
> I wouldn't bother.  I'd suggest that doing the above mentioned change to
> forw and repl would make it unnecessary.

Now I really think I'm missing something. :) I don't see that it's easy
to split the body from the headers if the message is already MIMEd, because
it might be a multipart message, or it might not, and so unless you want
to encapsulate all the headers too, and just copy the ones you know you
need to the new message, the headers of the old message need to be
parsed to know how to correctly encapsulate it.

Perhaps you're saying that the parsing of the original message's headers
is easy? That the MIME headers just need to be lifted out, leaving the
headers from which to create the new message, and then those extracted
MIME headers are used to encapsulate the original message?

Cheers,

        - Joel