Re: [Nmh-workers] attach and automimeproc interactions

[Jon Steinhart]

> > > > Based on the recent emails, I am thinking about a small modification
> > > > to sendfile() in whatnowsbr.c.  This change would be to skip the test
> > > > for automimeproc if attach (in Whatnow(), would have to be made global)
> > > > is set.
> > > 
> > > I'm not entirely sure what you mean in code terms, but I'd much prefer it
> > > if automimeproc and attach were handled in the same place, and that this
> > > test could be an || of them.
> > 
> > That was my plan.
> 
> I've been thinking about this a little further. If I remember correctly,
> part of the reason the original MIME building was designed the way
> it was is so the user can inspect the draft after it has been MIMEfied.
> This is part of the "all power to the user" idea.
> 
> Ideally, the new attach mechanism should probably be made to fit into
> this scheme, though I don't know how much work that will be. I know it
> would mean the attachment processing shouldn't be done by send (or post),
> and I'm sure you had your reasons for doing it that way.
> 
> Cheers,
> 
>       - Joel

I don't have any first-hand knowledge of the original MIME building design.
It looks to me like a wart glued on to add support for something that wasn't
part of the world when the original design happened.

I see no reason to allow messages to be converted and viewed except maybe
for debugging.  I realize that many on this mailing list are mail geeks.

I do have first-hand knowledge of the new attachment code since I wrote it.
The goal was to allow non-geeks to send mail with attachments.  I think
that it met that goal, and all I'm trying to do here is to prevent the two
mechanisms from colliding in a previously unforseen way.

Jon