Re: [Nmh-workers] suppress Content-ID's with new mhbuild option?

[David Levine]

> > Nice.  Attach already takes the filename.  Options would need to
> > include mime-type, name, mode, description, and Content-ID.  Anything
> > else?  If there's too much, it would get unwieldy.
> > 
> > Any suggestion on how to associate the option values with the build
> > directive?  printf style?
> > 
> >   whatnow: -attach X-MH-Attachment='#%T; name="%N" <%C>[%D; %M] %F'
> > 
> >   whatnow? attach -mime-type=application/wierd -name=foo -mode=0x640 -descr
> iption="my app" -contentid="" /tmp/foo
> > 
> > If any value in the build directive isn't specified, it
> > would be determined automatically (using mhshow-suffix for
> > the mime-type as it is now, and getting the name from the
> > filename, and so on).
> > 
> > While that example has a lot of typing, its purpose is to
> > show all the options.  I expect to rarely specify options,
> > given a suitable build directive, such as '#%T; name="%N"
> > <>[] %F', with the mime-type and name usually determined
> > automatically.  I don't see a need to bother with mode or
> > description, and don't want contentid.
> > 
> > It might be possible to add support for Content-Disposition
> > here.
> 
> Um, gimme a break here.  Why not just use mhbuild mime-composition files?

I've been doing that for years, with help from emacs
functions and key definitions.  Even with that support, I
still made a copy-and-paste error last week.  And not the
first time.

> I added the attachment handling code so that non-geeks could send attachments
> .
> This is heading in the opposite direction.  How often are these cryptic
> arguments really going to be used?  How many other mailers care about this
> sort of stuff?  How many mail programs even look at this stuff?

While it may not be obvious :-), I want simple, as well.
And more foolproof.  But I also want configurable.  I know
that I would never use any of the command line options
above.  Maybe I should just not bother with them.

The one thing I do want to be configurable is the build
directive.  Again, it's not something that I'll change, so
it can go into my .mh_profile.  But, what's the best way to
communicate it (currently it has three pieces) to
make_mime_composition_file_entry ()?

> If you decide to make these additions, keep in mind that they have to be done
> in the send code, not in the whatnow code.  This is because the design of the
> attachment code was such that it would work independent of the user interface
> .
> In particular, I know people who have hacked mh-e to add attachment headers.

Got it.  It's easier given nmh's current state, as well.

David