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

[Jon Steinhart]

> > My first reaction here is, is this really a problem (since it's a 
> > non-trivial
> > amount of work) or is it an academic exercise?
> 
> Yes, I thought that would be. I guess the fact that previewing and
> message/attachment interspersing is not possible with attachment headers
> is not significant to you.

No, it's not.  What's important to me is to be able to view the list of
attachments, and then to be able to trust that the code will properly
attach them.
 
> The recent issue that David Levine had is probably a good example of
> the kinds of reasons that exist for looking at the MIMEd draft. I've
> certainly looked at it many times.

I'm not sure what issue you're referring to here, unless it's being able to
remove content-ids.  Personally, if I need to look at the mimed version for
debugging purposes, I'll mail myself a copy.  It seems like the solution to
David's issue is to add the option to suppress content-ids, not to manually
edit each draft.  Or, better yet, to avoid Microsoft products.

> 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 reports
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.

> > I would change it to get rid of
> > the whole mime-composition file thing.  I would change forw and repl so that
> > they build attachment headers instead of mime composition files.  Aha!  Now
> > 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'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 that
> > you're encapsulating and make it a single part of the new message; you don'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.

Jon