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
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers